What's new

Help responding to my ISP network engineer.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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 ?
 
We would need to know what the previous conversation was to understand what he is responding to.
 
  1. Other user- Thumbs up cake/fq codel
  2. Me-I get slightly better results with cake
  3. Other user-Yeah, all depends what you trying to use it for. Reminds me a bit of old token-ring that had consistent arbitration for everyone especially on the bulk classes.It get complex as its not nice to voice which still requires PFIFO.
  4. ISP network engineer- “response above”
 
Hello,

What do you want to achieve with the response to the ISP "network engineer" ?

For what it's worth, the way I personally see it
* You don't need "support" from your ISP to enable Cake, fq_codel or others on your end of the network.
* There is not much chance you would be in contact with those really managing/designing the network.
* There is not much chance you will manage to change this gentleman opinion

bufferbloat.net is an interesting reference site

Best regards
W.
 
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.
Is this statement correct or how can I respond ?
Yikes - that whole response (if I'm reading it correctly as a cut/paste of an email from him to you, Santa) smacks of belligerent arrogance to me
he is assuming that the ISP's CPE/Router isn't being used as a simple gateway (bridge) with authentication (and packet control) happening on our Merlin routers with cake. The ISP probably provisions their equipment and doesn't think they'll be challenged on that provisioning, or have the customer disable/disregard it. (it actually may be a breach of their ToS, so be careful how you proceed.) If it's not, they should realize youre simply buying access from them, thank you very much.
if that kind of response makes them quiet and consider other possibilities (give them a bit of a helmet fire and attitude adjustment), you've won.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top