Re: [tcpm] [tsvwg] sce vs l4s comparison plots?

[Toke Høiland-Jørgensen <[e-mail]>]

Dave Taht <[e-mail]> writes:

> "[e-mail]" <[e-mail]> writes:
>
>> (see below)
>>
>> On Monday, November 11, 2019, 12:19:26 AM GMT, Dave Taht
>> <[e-mail]> wrote: 
>>
>> Cool. If only the dsl and cable worlds had adopted this! it allows for
>> much smarter handling of packet delivery higher in the stack at the
>> cost
>> of one interrupt's worth of standing queue. Without BQL we wouldn't be
>> scaling linux past 10GigE today.
>>
>> I keep hoping *switches* will start doing bql, also.
>>
>> [AB] at the CO end (ie downstream) my understanding (which may be out
>> of date) 
>> is that DSL ICs usually punt queuing to a switch IC. There's a
>> standard (G999.1) which exists
>> solely to enable this (it provides per-subscriber backpressure over
>> ethernet). So, switches doing
>> BQL is exactly what would be required for dsl to do BQL (in the
>> downstream direction).
>
> Given that a lot of stuff has moved to a purer software solution,
> slicing, sdn, etc, including switching, I can imagine this would
> move more into software, also - if folk were still producing new
> dsl gear.
>
> One thing that has always been unclear to me is where
> dsl subscriber software rate limits are enforced.

Generally either by forcing the DSL modem to sync up at a rate no higher
than that which the customer has bought; or (more often these days I
think) on a completely separate box that does shaping (or policing) in
the network.

I've seen small ISPs build such boxes using Linux and HTB - and Jesper
and I have been helping a few doing it right (scaling across CPUs, and
using FQ-CoDel on the leaves).

-Toke