How to choose between Cake and Adaptive\Flex QoS

[coxhaus]

I agree you can do some smoothing to inbound traffic. You just cannot control it. You need to make QoS decisions based on that. There are lots of ways to apply QoS and no one way is right. The other side is there are lots of ways to apply QoS badly. Just because you can do it does not mean you should.

 

[Tech9]

You'd be surprised I think.

I know it works, to some extent. Most people expect magic to happen just because few QoS options are available, forgetting about:

No one is worried about bufferbloat from the router toward the LAN.

don't expect miracles from consumer products.

and ending up here:

never-ending tinkering that eats up your life

...testing what the mystery box CTF, Runner, Flow Cache, etc. does on the way, because home routers need it.

The chainsaw is fat pipe (FTTH) and fat packet processing (x86). And there is no bufferbloat. I want online bufferbloat tests gone because many people do never-ending tinkering for no reason whatsoever. Some don't need QoS at all. Some may need it in 1% use cases.

 

[Morris]

In my small world of QoS, download is a lost cause because by the time the router has possession of the download packet, it has already traversed your ISP link whether you delay it, send it or drop it. It’s too late. You can only control what you send, not what you receive.

No one is worried about bufferbloat from the router toward the LAN.

It is not bufferboat that is the issue inbound to your LAN, it is the saturation of the link that prevents streaming from working properly that drives the need for inbound QOS

 

[dave14305]

It is not bufferboat that is the issue inbound to your LAN, it is the saturation of the link that prevents streaming from working properly that drives the need for inbound QOS

Since it is a link upstream from the router, what control is the router really exerting on the traffic flows it is receiving from the internet? Cake might have ECN enabled to help, but the traffic has already congested the ISP link. Isn't the best you can do to slow down your ACKs on the upload? I'm going to run for a week with just having cake on the upload direction, shaping 23 Mbit and no cake on WAN ingress. Let's see if I notice any problems.

In my case (on OpenWrt), the LAN interface is running fq_codel, so for download I will get some flow fairness without the overhead of shaping 500 Mbit.

 

[Morris]

Since it is a link upstream from the router, what control is the router really exerting on the traffic flows it is receiving from the internet? Cake might have ECN enabled to help, but the traffic has already congested the ISP link. Isn't the best you can do to slow down your ACKs on the upload? I'm going to run for a week with just having cake on the upload direction, shaping 23 Mbit and no cake on WAN ingress. Let's see if I notice any problems.

In my case (on OpenWrt), the LAN interface is running fq_codel, so for download I will get some flow fairness without the overhead of shaping 500 Mbit.

Besides slowing down ACK which works quite well, it can send source squinch and also drop packets which is like pulling the emergency break on a train. It stops fast and requires some time till movement starts again. I don't have experience to predict what will happen.

 

[Tech9]

It stops fast and requires some time till movement starts again

This will only increase the latency. The moment it starts moving, the same issue will happen.

 

[Morris]

This will only increase the latency. The moment it starts moving, the same issue will happen.

No, because it is not for all flows. Only high bandwidth flows such as downloads are slowed. This improves latency for lower bandwidth flows such as video, voice and most games. It is a super simple way to prioritize traffic.

 

[Tech9]

You can't do that by dropping packets. Everything UDP will be lost, everything TCP will be re-transmitted, eventually. As explained above, once the packet has already arrived, it's too late. It already used the available bandwidth. You can drop it if you like, it will waste more bandwidth to arrive again. It's not so super simple. If it is to you, please write a new DropQoS script and we'll test it.

 

[Smokey613]

I do not have the “large” pipe like a lot of people do but since switching over to my current setup things work very good. The ER7206 just chugs along with default firewall settings. No QoS at all. I have NexDNS IPs issued out to clients via the dhcp sevice. The wifi service on the pair of ”old” eero pro units is trouble free and roaming works perfectly as does guest networking even in Bridge mode.

Now I just concentrate on playing with my Plex server and all it’s toys.

 

[Tech9]

What happened to ER605, @Smokey613?

 

[Morris]

You can't do that by dropping packets. Everything UDP will be lost, everything TCP will be re-transmitted, eventually. As explained above, once the packet has already arrived, it's too late. It already used the available bandwidth. You can drop it if you like, it will waste more bandwidth to arrive again. It's not so super simple. If it is to you, please write a new DropQoS script and we'll test it.

UDP based applications do retries at a higher level. Not an issue.

Dropped packets are only for bandwidth hogs. There is no issue stopping packets as the QOS process starts slowing the hogs when the sponge that is configured in the form of slightly less than maximum throuput is reached. When the link saturates, that is when lots of packets are lost, everything slows down and streaming goes bad

 

[Tech9]

I don't understand what you are talking about, @Morris. Are you still talking about QoS of something else?

 

[Morris]

I don't understand what you are talking about, @Morris. Are you still talking about QoS of something else?

I agree, you do not understand how and why Cake QOS functions with regulars to layer 3, 5 and 7

 

[Tech9]

No, I sad I don't understand what are you talking about. Sorry.

 

[Morris]

No, I sad I don't understand what are you talking about. Sorry.

I agree again. You code well so you should be able to learn what is necessary to understand what no wrote

 

[Tech9]

I don't code. I don't have sponges in my firewall, I don't know what setting is source squinch, I don't drop nor stop packets as train emergency brakes. You have to point me to the sources using this terminology first so I can take a look. Doesn't sound to me like networking related.

 

[Morris]

I don't code. I don't have sponges in my firewall, I don't know what setting is source squinch, I don't drop nor stop packets as train emergency brakes. You have to point me to the sources using this terminology first so I can take a look. Doesn't sound to me like networking related.

The sponge is the 10% difference in bandwidth. I guess you did not understand that as you don't code.

Source Squinch is part of TCP. It is a flag

You don't drop packets, Cake drops packets when slowing ACK and Source Squinch don't work

 

[Tech9]

Source Squinch

Are you talking about ICMP Source Quench mechanism?

 

[Morris]

ICMP is not part of TCP. It is separate IP protocol. ICMP source squelch tells the target host to stop sending ALL flows to the destination while TCP source squelch is per flow. While I was talking about TCP, UDP can also play a role.

 

[Tech9]

Source, please. I want to read the original. Quench, Squinch, Squelch... screech? Thank you!