Re: [tsvwg] FW: New Version Notification for draft-white-tsvwg-l4sops-00.txt

[Sebastian Moeller <[e-mail]>]

Hi Greg,

section 4&5:

"4.  Operator of a Network

   While it is, of course, preferred for networks to deploy L4S-capable
   high fidelity congestion signaling, a network operator who has
   deployed equipment in a likely bottleneck link location (i.e. a link
   that is expected to be fully saturated) that is configured with an
   RFC3168 FIFO AQM can take certain steps in order to improve rate
   fairness between classic traffic and L4S traffic."


[SM] I beg to differ, it is far from clear whether it is generally preferred for networks to deploy  L4S-capable high fidelity congestion signaling unless the L4S team finally coughs up the long requested tests over something else than the one thing we know this would work, the low hop-count short RTT path from close CDNs to end-users. 


"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."

[SM] Quick poll, does anybody know of equipment configurable to that degree? So is this a REALISTIC option or are we enumerating theoretical possibilities here? I fear it is the latter but would love to be wrong.


"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"

[SM] Please correct me if I am wrong, but that sems likely to introduce gratuitous re-ordering of packets in true rfc3168 flows, just like the main L4S design?


   "Option 2:

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

   o  Queue #1: ECT1 & NotECT packets - ECN disabled

   o  Queue #2: ECT0 & CE packets - ECN enabled

   o  Outcome

      *  ECT1 treated as NotECT

      *  Flow balance for the 2 queues the same as in option 1"

[SM] This seems the safer option regarding potential re-ordering, and that fact shoud be explicitly mentioned, no?

"4.4.  ECT1 Tunnel Bypass

   Using an RFC6040 compatibility mode tunnel, tunnel ECT1 traffic
   through the RFC3168 bottleneck with the outer header indicating Not-
   ECT.

   Two variants

   1.  per-domain: tunnel ECT1 pkts to domain edge towards dst

   2.  per-dst: tunnel ECT1 pkts to dst"

[SM] Hrm, IMHO there are only two rationally defensible tunnel designs with regards to ECN psiible, either always copy to out on en- and copy to inner on de-capsulation, or never do so (basically ECN-opaque and ECN-transparent tunneling) all the other clever recommendations of the past lead us into the mess that we are in today. This proposal would be going in the opaque tunneling direction, except it seems to advertize doing this differentially for ECT(1) and ECT(0) which I consider being part of the problem, not of the solution.

"4.5.  Disable RFC3168 ECN Marking

   While not a recommended alternative, disabling RFC3168 ECN marking
   eliminates the fairness issue.  Clearly a downside to this approach
   is that classic senders will no longer get the benefits of Explict
   Congestion Notification.

4.6.  Re-mark ECT1 to NotECT Prior to AQM

   While not a recommended alternative, remarking ECT1 packets as NotECT
   ensures that they are treated identically to classic NotECT senders.
   However, this also eliminates the possibility of downstream L4S
   bottlenecks providing high fidelity congestion signals."


[SM] I appreciate that this list both of the ultima-ratio solutions with their immediate consequences, but without any bias which of the two is less despicable.


"5.  Researchers

5.1.  Detection of Classic ECN FIFO Bottlenecks

   TODO: Describe active testing methods, in-band or out-of-band, that
   can distinguish FIFO from FQ."

[SM] IMHO this will need to take care to explicitly elaborate which heuristics come with which failure modes. Also this needs to acknowledge that FQ can ameliorate the issue, but at least in ist stochastic version is not a full solution.


"5.2.  End-to-end measurement of L4S vs. Classic performance

   TBD"

[SM] Funny, that, as far as I can tell there is quite a lot of that still on the TODO list for team L4S ;)


Many thanks for starting this

Best Regards
	Sebastian

> On Jul 30, 2020, at 13:05, Greg White <[e-mail]> wrote:
> 
> TSVWG members-
> 
> I've posted a rough draft of Operational Guidance for L4S deployment.  This is not much more than an outline at this point, and is almost certainly incomplete even at that, so please read it with that in mind. 
> 
> -Greg
> 
> 
> From: "[e-mail]" <[e-mail]>
> Date: Thursday, July 30, 2020 at 4:53 AM
> To: Greg White <[e-mail]>
> Subject: New Version Notification for draft-white-tsvwg-l4sops-00.txt
> 
> A new version of I-D, draft-white-tsvwg-l4sops-00.txt
> has been successfully submitted by Greg White and posted to the
> IETF repository.
> 
> Name:		draft-white-tsvwg-l4sops
> Revision:	00
> Title:		Operational Guidance for Deployment of L4S in the Internet
> Document date:	2020-07-30
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-white-tsvwg-l4sops-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-white-tsvwg-l4sops/
> Htmlized:       https://tools.ietf.org/html/draft-white-tsvwg-l4sops-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-white-tsvwg-l4sops
> 
> 
> Abstract:
>   This is an early, work-in-progress draft - a start at getting some of
>   the ideas from the mailing list and email exchanges on paper.
> 
>   This draft is intended to provide guidance to operators of end-
>   systems, operators of networks, and researchers in order to ensure
>   reasonable fairness between L4S and Classic flows sharing a single-
>   queue RFC3168 bottleneck link.  This draft identifies opportunites to
>   prevent and/or detect and resolve fairness problems in such networks.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
>