Re: [tsvwg] L4S operational guidance draft

[Sebastian Moeller <[e-mail]>]

Well, since you asked...

I believe that in parts this document still is way to enthusiastic, eg.:

"4.2 Configure Non-Coupled Dual Queue


   Equipment supporting [RFC3168] may be configurable to enable two
   parallel queues for the same traffic class, with classification done
   based on the ECN field.

   Option 1:

   o  Configure 2 queues, both with ECN; 50:50 WRR scheduler

   o  Queue #1: ECT1 & CE packets - Shallow immediate AQM target

   o  Queue #2: ECT0 & NotECT packets - Classic AQM target

   o  Outcome

      *  n L4S flows and m long-running Classic flows

      *  if m & n are non-zero, get 1/2n and 1/2m of the capacity,
         otherwise 1/n or 1/m

      *  never < 1/2 each flow's rate if all had been Classic

   This option would allow L4S flows to achieve low latency, low loss
   and scalable throughput, but would sacrifice the more precise flow
   balance offered by [I-D.ietf-tsvwg-aqm-dualq-coupled]. "


One of the big ticket items for L4S IMHO is exactly that the dualQ does a terrible job at maintaining a "more precise flow balance" between the different queues. I understand that this document will be mostly written by L4S proponents and hence be positive towards L4S, but unless we call a spade a spade, this will not actually help real world operators to make the L4S experiment any safer.



"4.1 Configure AQM to treat ECT1 as NotECT


   If equipment is configurable in such as way as to only supply CE
   marks to ECT0 packets, and treat ECT1 packets identically to NotECT,
   or is upgradable to support this capability, doing so will eliminate
   the risk of unfairness."


This should present at least some research whether existing deployed RFC3168 AQMs actually allow that level of configuration, because otherwise this leads to unrealistic scenarios like expecting the network operator to bleach ECT(1) before AQM action and restoring it after the AQM is done with no real proposal where to store the state in the interim. In short that seems like a rather theoretical proposition, until and unless it has been shown that deployed AQM can be trivially configured as proposed. If is is realistic, by all means add it, but if this is as purely a theoretical option as it appears to me the draft would be better without presenting this option.



I certainly miss the "what to do on catastrophic failure" section, that explains that ISPs making special amends for the L4S experiment can follow to un-do all of this when it becomes clear that the experiment failed (when not if...))

Best Regards
	Sebastian



> On Nov 16, 2020, at 19:31, Wesley Eddy <[e-mail]> wrote:
> 
> In today's meeting, it was mentioned that the L4S operational guidance draft is part of the "safety case" for advancing other L4S drafts.  It's not as mature as the other docs yet (e.g. there are several"TODO" portions), but we want to understand if people think it's going in the right direction and will be suitable for this purpose as it's sketched, or what else should be added/changed/etc.
> 
> This is on the agenda for Wednesday's meeting.
> 
> So, if you have bandwidth, please check out the L4S operational guidance draft prior to the Wednesday meeting, so that we can get a better sense of how to proceed:
> 
> https://datatracker.ietf.org/doc/draft-white-tsvwg-l4sops/
> 
>