Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?

[Sebastian Moeller <[e-mail]>]

Dear Bob
 
more below in-line, prefixed with [SM2]
 
 

Gesendet: Donnerstag, 29. Oktober 2020 um 15:53 Uhr
Von: "Bob Briscoe" <[e-mail]>
An: "Sebastian Moeller" <[e-mail]>, "Ingemar Johansson S" <ingemar.s.johansson=[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Ingemar Johansson S" <[e-mail]>
Betreff: Re: Aw: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?
Sebastien,

On 29/10/2020 08:51, Sebastian Moeller wrote:
> Hi Ingemar,
>
> more below in-line, prefixed with [SM]
>
>
>
> Gesendet: Donnerstag, 29. Oktober 2020 um 07:58 Uhr
> Von: "Ingemar Johansson S" <ingemar.s.johansson=[e-mail]>
> An: "Bob Briscoe ([e-mail])" <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: "Ingemar Johansson S" <[e-mail]>
> Betreff: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?
>
> Hi
> I agree with the statement below. If one take 5G access as example, the bearer concept and the scheduling mechanism will for the vast majority of use cases prevent that one “user” cause harm to others.
> [SM] What makes you believe that cross-user unfairness is the only rationale for queue-protection? Unless 5G will mandate that L4S services need to be opt-in/configurable by the end-user, considering queue-protection only between users seems rather haphazard. AND the same flawed rationale against queue protection will also hold for the intended roll-out of L4S aas part of low latency DOCSIS at CMTS, as these already implement a per-user traffic shaper to keep each user to her/his contracted speeds. Thus it should not be mandatory to implement queue protection.

[SM]
 
        [SM2] that should have been BB, I believe?
 
I'm afriad this discussion about fairness between users is
immediately going off in two different directions from where the thread
started.
* It's about per-flow (5-tuple) not per-user (see email to Ingemar just
now).
 
        [SM2] Yes, I agree, and I tried to argue such.
 
 
* And it's about latency policing, not rate policing. We coined the term
'queue protection' to have a term that was distinct from rate policing,
because we found that when we used the term 'latency policing', many
people assumed we meant some variant of rate policing.
 
        [SM2] I believe that queue protection as mandated by docsis, does both. By ensuring that non-responsive flows exit the L4S fast queue the standard-queue is more likely to get its appropriate share of transmission slots. Unlike you I do not pretend that latency and rate are orthogonal to each other at least not on small timescales...
 
 

>
> [SM] Given the development of the L4S drafts in this WG I am confident, that in the end you will get your way, after all L4S is getting away with promising no starvation for non-L4S flows without properly defining what starvation is suposed to mean in this context*. That said, IMHO mandating implementation (but not activation by default) of queue protection methods seems like a prudent hedge against future misbehaviour of L4S AQM.

[BB] From this I take it that you haven't really understood the original
email, which said it's not even possible for the IETF to mandate queue
protection, given it will often be separately implemented. The IETF
doesn't write RFCs that mandate how operators build their whole systems.
 
        [SM2] I wonder why you believe that the IETF can then rquire that implementers of L4S aware protocols actually follow the requirements you lay out in your internet drafts? Anybody deploying an L4S compatible AQM surely can be bothererd to make sure that AQM has a knob to enable some sort of queue protection (we are stillnot talking about enabling that on default, and hence this is orthogonal to any other queue protection scheme an operator might want to use). I would say, that the IETF is in a position to require such things, especially since the implementers here want something special from the IETF, the right to re-define what the ECN CE and ECT(1) code points mean, internet-wide. 
Now, if L4S would not introduce a real danger of starving non-L4S traffic to a trickle, you might have a point. But the reason for requesting a mandatory queue protection mechanisms is simply that L4S as currently designed and implementd has abysmal sharing behvior and is easily gamed. If you would propose the remove the requirement for implementing queue protection by implementing something with better worst case sharing behaviour in the core L4S design, I am all for dropping queue protection then. But I do not believe that is what you offer.
 
Best Regards
        Sebastian
 

Other aspects of this email go-off topic in other directions, so I'll
stop here.


Bob

> Given that L4S has not yet been proven to work over the internet at all (who ever believes it has been shown, please post a link to the test results and an explanation why those tests were braod enough to cover sufficiently many relevant real-world conditions), mandating the existence of such circuit-breaker features like queue protection should be a clear "conditio sine que non".
>
> *) Here, again my proposeal for the meaning of starvation in the context of AQMs: if a flow receives less than 1/8 (three orders of magnitude in base2) of its _intended_ share of the link#s capacity it is starved. "Intended share" allows for conscious rate limiting of flows based on secondary properties to allow traffic engineering and traffic shaping (to the point of even allowing starvation of flows, if that starvation is intentional, like e.g. for flows participating in a DOS attack).
> Best Regards   Sebastian
>
>
> /Ingemar
>
>
>> You will recall that I and others have argued against QProt being
>> mandatory to implement using arguments about incentives. That is still
>> the main argument, which I can summarize if necessary, but that's not
>> the purpose of this email.
>
>> Here. I want to add another argument that is about modularity. In the
>> latest revision of the l4s architecture you will find seven examples
>> listed of how queue protection could be implemented (eight if you count
>> the null case of no protection):
>> https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-07#section-8.2
>> Only two have the queue protection integrated with the AQM. Five use
>> distributed arrangements, with characterization of the traffic
>> congestion located remote from the bottleneck queues that are being
>> protected.
>
>> For a distributed solution, when a developer implements an L4S AQM in
>> one box, it doesn't even make sense for the IETF to mandate that she
>> must implement queue protection wI take it ith it. In a distributed approach,
>> queue protection would be an independent module running on a different box.
>
>> The only way that would make sense would be if the IETF was writing a
>> normative standard for a complete traffic control system. Then we would
>> be telling operators what to do, not implementers. System standards are
>> usually the territory of the ITU, or the broadband forum, etc. The IETF
>> is usually expected to specify component parts - protocols, algorithms -
>> "Do one thing and do it well".
>
>

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