S.claus
Regular Contributor
I could probably be corrected here, but unless the server doing the sending of the traffic, is using an appropriate congestion control algo, I don't see how your home router, or even desktop PC, will benefit from a router running a funky congestion control algo, unless the router is doing the connection on your behalf, and no, that !=NAT
The packet has already made it to your device, and regardless of congestion control, has already made it all the way accross the internet to your CPE. The CPE's job is to forward/de-NAT the packets from the original server. I fail to see the use of fq_codel and such in a client router, since the packet has already arrived at the router. Perhaps, for uploading, it might make a difference, but only if the sending device is using an approriate congestion control algo, which, again has nothing to do with the router's ability to forward/NAT packets.
For received packets, thinking that "if my router has got got fq_codel" , is giving you an advantage is an utter misnomer. The router is blindly forwarding packets. It has arrived on your port. Dropping it would be silly.
The CPE/Router is basically just a dumb pipe, NAT-ing and de-NATing packets thare are received. The only thing it can control is the transmit queue.
From our perspective, we will either drop the packet if it exceeds the inbound, or outbound rate limit, or your fibre line may have dropped it, due to the rate limit having been reached on the physical layer.
So what is the point of messing around with congestion control, or TCP algo's on a CPE/Router, when it's job is to simply forward the packet to your LAN ? Unless you router is doing a TCP level "proxying" of a connection, it's meaningless...
A router that has congestion control algo's builtin is meaningless, if it's just forwarding packets. The TCP contract is between the server and the client at the end of the day. Not the router and the server/client.
Buffers are a different thing, but that does != congestion control.
Bottom line, you might have better results using a congestion control algo on your desktop, but we, as an ISP will still forward the RAW packets based on the agreed upon rates. So it's not a router/ISP issue. But an application/desktop stack issue.
(Unless proven otherwise )
Is this statement correct or how can I respond ?
The packet has already made it to your device, and regardless of congestion control, has already made it all the way accross the internet to your CPE. The CPE's job is to forward/de-NAT the packets from the original server. I fail to see the use of fq_codel and such in a client router, since the packet has already arrived at the router. Perhaps, for uploading, it might make a difference, but only if the sending device is using an approriate congestion control algo, which, again has nothing to do with the router's ability to forward/NAT packets.
For received packets, thinking that "if my router has got got fq_codel" , is giving you an advantage is an utter misnomer. The router is blindly forwarding packets. It has arrived on your port. Dropping it would be silly.
The CPE/Router is basically just a dumb pipe, NAT-ing and de-NATing packets thare are received. The only thing it can control is the transmit queue.
From our perspective, we will either drop the packet if it exceeds the inbound, or outbound rate limit, or your fibre line may have dropped it, due to the rate limit having been reached on the physical layer.
So what is the point of messing around with congestion control, or TCP algo's on a CPE/Router, when it's job is to simply forward the packet to your LAN ? Unless you router is doing a TCP level "proxying" of a connection, it's meaningless...
A router that has congestion control algo's builtin is meaningless, if it's just forwarding packets. The TCP contract is between the server and the client at the end of the day. Not the router and the server/client.
Buffers are a different thing, but that does != congestion control.
Bottom line, you might have better results using a congestion control algo on your desktop, but we, as an ISP will still forward the RAW packets based on the agreed upon rates. So it's not a router/ISP issue. But an application/desktop stack issue.
(Unless proven otherwise )
Is this statement correct or how can I respond ?