I don't quite understand.
TCP congestion control works according to the end to end principle.
The server sends data and the client receives data and confirms this with an ACK or NOACK - then the server adjusts its sending behavior.
Therefore the congestion control on your devices has only influence on the own upload behavior.
The congestion control on the Internet server can not be changed
A router in between does nothing at all, it only forwards the packets (layer 3).
Congestion control works on layer 7
The congestion control could still play a role if you use VPN on the router - but this is more theoretical nature - because VPN usually runs over UDP
In a normal network where the internet traffic is simply forwarded by the router the congestion control on the router does not play a role at all - there are only two endpoints (the internet server and your end device).
Joined: 16 Nov 2015 Posts: 6410 Location: UK, London, just across the river..
Posted: Wed Jun 29, 2022 9:02 Post subject:
-did you do the test i was talking about ?
-did you see any difference...? (i did)...
-are there lost/delyed packets when torrenting (DL).. not the upload im talking about...
-what happens when there are lost packets when torrenting?
-is there a lost packets when you download...any files form internet, especially large ones..?
-is there a lost packets when you browsing and load a heavy pages and so on...?
-what if the router has many clients and lots of traffic as well some tons of lost packets on heavy WAN load...which is the normal TCP/IP stuff...?
Does TCP congestion control plays a role there, lost/delayed packets...??
I do know how TCP congestion works..according to what i read from the link I posted or wikipedia article..is there anything more to be said here..
and yes VPN is mostly UDP, so no relation with TCP congestion rules..unless you use it via TCP...
and yes TCP congestion on router level does change the server settings..in order to improve the connection flow
if this will continue...I have to pull the Joker card and split the thread... _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55179 WAP
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55460 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55460 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55363 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Last edited by Alozaros on Wed Jun 29, 2022 11:32; edited 1 time in total
Nope I have not tested because I have not understood it properly as I said.
If the torrent client runs on the router then it also uses the congestion control of the router for the upload.
If the torrent client is running on your PC then it uses your PC's congestion control for the upload.
In both cases it uses the congestion control of the internet server for the download.
How the congestion control works I already told you.
The server sends TCP data to the client and the client confirms the arrival with ACK (acknowledgment) or a faulty transmission with NOACK (
No Acknowledgement) or there is a timeout
Thereupon the server adjusts its sending behavior and sends slower if necessary.
You can also read everything on Wikipedia.
There is clearly explained that the TCP congestion control works according to the end-to-end principle.
And that the server/sender is ALWAYS responsible for the congestion control algorythms.
Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself. There are several variations and versions of the algorithm implemented in protocol stacks of operating systems of computers that connect to the Internet.
Joined: 16 Nov 2015 Posts: 6410 Location: UK, London, just across the river..
Posted: Wed Jun 29, 2022 10:59 Post subject:
ho1Aetoo so, you admit that TCP CC could be related with torrent and dl/up speeds and control (packet loss /delay), and that there is a difference upon using different TCP congestion c settings...
Than why is all that mocking about...
We both know what TCP congestion is for, we both know how it works..but you are mocking about, what i said and you didn't do the torrent test.. witch i used to express my experience and results...
so, do the test and come back if you have anything else to say to improve the talk on the subject... _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55179 WAP
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55460 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55460 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55363 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
I don't mock about it.
I was just explaining to you how TCP congestion control works.
And I still don't understand which scenario to test exactly.
You said something about "in both cases".
I can vividly assure you that TCP congestion control only works on the Server/sender side.
And when you download, you are the receiver, not the sender.
So you can configure any congestion control you want on your router or PC - it won't affect your download at all.
But if you have a totally shitty asymmetric DLS line then we both know that the upload affects the download.
Since the uplink capacities are maxed out at times (1Mbit upload i in relation to 16 hehe) and can therefore also block the download, this has at most indirectly something to do with the TCP congestion control.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Wed Jun 29, 2022 17:05 Post subject:
The thread has been split, applied congestion control on a re-transmission via sender thommy181 where clearly there is an open loop situation and now the choke packet has been sent.
So now we have a leaky bucket and flow can remain constant.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Wed Jun 29, 2022 17:25 Post subject:
dplettner wrote:
thommy181 wrote:
I'm dont touch this better. On my device was 4096 always. I'm never touch this settings. It's puzzling why that big value is there as default.
I have never touched this either. On my Netgear R7800 it is set to 32768. Perhaps the firmware sets it based on the speed of the CPU?
Consider that torrenting is a very resource intensive process where encrypted torrents are concerned, so if you have push bike you may wanna lower the number to something manageable if there is any congestion happening, and picking an algorithm to manage the situation.
Joined: 16 Nov 2015 Posts: 6410 Location: UK, London, just across the river..
Posted: Thu Jun 30, 2022 6:28 Post subject:
ho1Aetoo wrote:
I don't mock about it.
I was just explaining to you how TCP congestion control works.
And I still don't understand which scenario to test exactly.
You said something about "in both cases".
I can vividly assure you that TCP congestion control only works on the Server/sender side.
And when you download, you are the receiver, not the sender.
So you can configure any congestion control you want on your router or PC - it won't affect your download at all.
But if you have a totally shitty asymmetric DLS line then we both know that the upload affects the download.
Since the uplink capacities are maxed out at times (1Mbit upload i in relation to 16 hehe) and can therefore also block the download, this has at most indirectly something to do with the TCP congestion control.
Yep you are correct on the system level OS is taking control of the congestion control......but on my Win 7 this is disabled...same for Win 10...or my Linux...
and yes i do have ISP aggregated shitty line of 200Mbit local country peering + 60 Mbit worldwide internet... _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55179 WAP
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55460 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55460 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55363 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Just a quick comment again.
You cannot deactivate the TCP congestion control, neither under Windows nor under Linux.
If you set the congestion control to "none" (congestionprovider=none) under Windows 7 or 10, the built-in TCP congestion control is used, and this is NewReno for the Windows non-server versions.
Every computer has and needs its own TCP congestion control.
my Windows 7 ctcp is set to none...
and TCP CC is using the router side i believed..
not much point/logic to set it to none and than to use the default one...isn't it ?
congestion provider - One of the following values:
none: Use the built-in standard congestion control algorithm.
ctcp: Use the add-on Compound TCP congestion control algorithm.
default: Restore the selected provider to the system default.
on Win 10 there is no ctcp config like in win 7, but because of the delivery guarantees of TCP there is no way to disable congestion control completely. win 10 "netsh int tcp set global congestionprovider=none"
On the router TCP CC serves its local congestion WAN to LAN or local clients.. services ("transmission") if you look at the torrents, they open a hole in local firewall Win firewall(specific port) and on the router side as those related, established connections are permited...and then connection is direct, so i had a believe those use the router TCP CC and therefore i could see the difference between using Vegas, BBR, Cubic or Westwood or others...
So far my best results ware Vegas, Cubic/BBR where there is BBRv2 nowadays..that I've not seen around or tested...
At the end of the day i may had a glitch from a high proton beam...as a results...or whatever... _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55179 WAP
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55460 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55460 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55363 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Last edited by Alozaros on Thu Jun 30, 2022 14:40; edited 1 time in total
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu Jun 30, 2022 15:27 Post subject:
@alozaros, Microsoft's logic is beyond reproach , to be fair you have to have some type of CC and they assume most ppl just plug the WAN cable to the back of the machine and back then (Windows Vista/7) they weren't far from the truth and still in many parts of the world they are close to it.