Re: [Bloat] [Ecn-sane] [tsvwg] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Mikael Abrahamsson <swmike@swm.pp.se>]

On Thu, 21 Mar 2019, Jonathan Morton wrote:

> Now, when you have a 6000-channel router, I expect it starts with some 
> very simple and fast device to direct packets in *approximately* the 
> right direction, where some other piece of hardware deals with some 
> subset of the total port count.  Let's say you have a 1Gbps+ link to a 
> 64-line cluster.  Immediately the problem of providing FQ on each of 
> those lines is more tractable; you can give each one 1024 queues and 
> AQMs, the same as fq_codel, for a quite manageable total of 65536, and 
> it's not so hard to build hardware that can keep up with 1Gbps traffic 
> these days.

I don't know the actual cost of having a high queue number router, I just 
know that to currently buy these in the market there is something around a 
magnitude difference in cost of buying something with 8 queues per port or 
128k queues per port.

The PON OLT is sometimes a smallish device that might need to be 
temperature hardened and required to be low power, because it's sitting in 
a roadside cabinet or something. The problem here is that you're asking 
for a major re-design of how this is done to a group of people that don't 
have on the radar that what you're talking about is a serious problem to 
solve.

As you said in an earlier email, we're in stupid large FIFO territory a 
lot of the time, and even configuring WRED on existing equipment properly 
would be a big improvement for the end users, and not even this is done.

I am attending my first BBF meeting ever. Just to give an example of how 
networks are often built by the largest operators, you can look at 
http://www.ieee1904.org/events/2014_06_workshop/s2_alter_access.pdf slide 
"TR-156 and TR-200: GPON and EPON access"

In this case, queueing might happen at so many places along the packet 
path and different encapsulations that it's really really hard (and 
costly) to change things to do proper FQ. If we look at the BNG->eth 
egg->OLT->ONT->RG packet path, typically queueing might happen at the BNG, 
but in case of high usage you might have queueing in the OLT->ONT, and the 
OLT just isn't looking into the PPPoE payload to be able to do FQ there.

I might not agree with how these people decide networks should be built, 
but that's unfortunately the way things look in a lot of cases. Telling 
them to just do "FQ, how hard can it be?". Typically, the answer is "hard, 
for a multitude of reasons".

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se