Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

[Bob Briscoe <[e-mail]>]

Sebastian,

On 09/03/2021 12:37, Sebastian Moeller wrote:
>> On 08/03/2021 22:19, Pete Heist wrote:
> [...]
>>> IMO, fq_codel isn't ideal in this situation. When there actually is
>>> congestion to manage, flow-fairness means that one user can dominate
>>> the queue with many flows, which is exactly one of the problems we'd
>>> like to avoid. Host fairness could improve on this, or better yet,
>>> member fairness using the member database, as members can have more
>>> than one IP/MAC. But, fq_codel is what's available now, and generally
>>> usable enough in this case to get started with AQM.
> [...]
>
>
>
>> On Mar 9, 2021, at 01:25, Bob Briscoe <[e-mail]> wrote:
> [...]
>> PS. I agree it's v strange for an ISP to share capacity between its members by how many flows they are using.
> [...]
>
>
>
> I just want to note two things here:
>
> a) even without a flow queueing AQM on the bottleneck, sharding works to get a higher part of the capacity since TCP tends to be more or less fair to itself
>
> b) most ISP put a lid on games like that by simply also enforcing (policing or shaping) each users aggregate capacity to numbers mentioned in the contract...
>
> So fq_codel, while by no means ideal here, does not really make thinks worst that the status quo, it is just that sharding can make pure flow fairness regress to less equitable sharing between classes other than flows.

[BB] You seem to be using "the status quo" to mean TCP sharing out the 
capacity between users. But that has never been the status quo - since 
even before TCP congestion control was invented in 1988 per-customer 
scheduling has been the norm for public ISPs {Note 1}. Irrespective of 
access technology , whether DSL, DOCSIS cable, PON, mobile, satellite, 
etc. They all share downstream capacity between customers at a node that 
is either at the head of the bottleneck access link, or logically 
limited to match the capacity of the customer's bottleneck access link.

You might be able to turn a few debating somersaults and claim that the 
problem is the absence of a per-customer scheduler, not the presence of 
an FQ scheduler where this scheduler would normally sit. If that allows 
you to sleep at night, you're welcome to live in your Alice through the 
Looking Glass world.


{Note 1}: I can't immediately find evidence from the late 1980s of this. 
All I can find is Appx B of TR-059 
<http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=6924A1B1458AE2F6FEF15047BC95A7EC?doi=10.1.1.176.7875&rep=rep1&type=pdf> 
from the DSL Forum, but that was only 2003 when QoS was added after 
Diffserv was standardized. The closest I can get to something older is 
the second half of RFC970 written in 1985, which was an early step 
towards per-customer scheduling. You can skip over the first half that 
is trying to solve an early form of bufferbloat that predated TCP 
congestion control. Alternatively, I'm sure many people on this list 
will be able to confirm that per-customer scheduling has 'always' been 
the norm.

> For a cooperative use case, something like a per-member QFQ instance that equitably shares capacity between members with an fq_codel inside each of the QFQ classes seems like a better fit, no?

Well, once you've got the per-member scheduling, an AQM in each member's 
FIFO would suffice. But you can have your FQ-CoDel in there instead if 
you must.

When a node is serving a few thousand members, you don't want to 
unnecessarily have a thousand or so queues per member as well - at least 
not if you can achieve similar performance without them.

For instance, BT's network architect set me the task of simplifying BT's 
QoS architecture, because even 5 queues per customer was considered to 
be the main cause of system complexity. See Section 3.1.2 of this 
report: 
https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-public1.pdf



Bob

>
> Best Regards
> 	Sebastian

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/