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

[Ingemar Johansson S <[e-mail]>]

Hi Jonathan, Sebastian

If you update Cake, please consider to add the possibility to distinguish
between the ECT(0) and ECT(1) codepoint. A first reasonable step is to make
the algorithm ignore the ECT(1) codepoint. This is brought up in section 5.1
in the L4S opt draft and also suggested by Tom Henderson.

Regards
Ingemar

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Jonathan Morton
> Sent: den 9 mars 2021 14:53
> To: Sebastian Moeller <[e-mail]>
> Cc: tsvwg IETF list <[e-mail]>; [e-mail]
> Subject: Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-
> deployment-observations-02.txt
> 
> > On 9 Mar, 2021, at 2:37 pm, Sebastian Moeller <[e-mail]> wrote:
> >
> > 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.
> 
> This is true IMHO.  FQ still has a significant advantage here, in that
latency
> effects are still isolated between flows; sparse flows, which are
typically
> more latency-sensitive, are not affected by the various saturating flows
> rushing past them on all sides.  That would not necessarily be true with a
> single queue.
> 
> > 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?
> 
> This is similar in effect to what Cake can be configured to do.  Cake does
it by
> weighting the delivery rate of individual flows to produce a constant
total
> weight per host.
> 
> Since this seems to be a fairly common use case for ISPs, I'm considering
> writing a qdisc specialised to do it efficiently.  This could be a drop-in
> replacement for an fq_codel or HTB+fq_codel deployment, assuming the
> device needing it is running a new enough kernel.
> 
>  - Jonathan Morton