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

[Sebastian Moeller <[e-mail]>]

Hi Greg,

my comments for sections 1 & 2 below (more will follow):

"1.  Introduction

   In the majority of network paths, including paths where the
   bottleneck link utilizes packet drops (either due to buffer overrun
   or active queue management) in response to congestion, as well as
   paths that implement a 'flow-queuing' scheduler such as fq_codel or
   Cobalt, and those that implement dual-Q-coupled AQM, L4S traffic
   coexists well with classic congestion controlled traffic."

[SM] This description ignores the birthday paradox issue that Pete Heist demonstrated. A misbehaving L4S will cause less havok there but it is not without side-effects on stochastic flow queueing systems, we might as well acknowledge that, no?

"   On network paths where the bottleneck link implements a shared-queue
   (FIFO) with an Active Queue Management algorithm that provides
   Explicit Congestion Notification signaling according to RFC3168, it
   has been demonstrated that when a set of long-running flows
   comprising both "Classic" congestion controlled flows and L4S-
   compliant congestion controlled flows compete for bandwidth, the
   classic congestion controlled flows may achieve lower throughput when
   compared to the L4S congestion controlled flows.  This 'unfairness'
   between the two classes appears to be more pronounced on longer RTT
   paths (e.g. 50ms and above) and/or at higher link rates (e.g. 50 Mbps
   and above)."

This is rather cautious I would use more drastic terms, the observed unfairness approaches starvation of the non-L4S flows and this text makes it sound like it is a minor almost theoretical concern.

"  The root cause of this unfairness is that RFC3168 does not
   differentiate between packets marked ECT0 (used by classic senders)
   and those marked ECT1 (used by L4S senders), and provides an
   identical congestion signal (CE marks) to both classes, whereas the
   two classes respond differently to that congestion signal."

How about keeping causality intact and frame this as a consequence of L4S redefining what CE means. There are reasons for doing that, but this text leaves it unclear who caused this problem (or rather the text implicates rfc3168, which IMHO violates temporal causality).

"The result is that the
   classic senders respond to the CE marks provided by the bottleneck by
   yielding capacity to the L4S flows.  While this has not been
   demonstrated to cause starvation of the classic flows, the resulting
   rate imbalance can be a cause of concern."

Mmmh, http://sce.dnsmgr.net/results/ect1-2020-04-23-final/l4s-s2-twoflow/l4s-s2-twoflow-ns-cubic-vs-prague-codel1q_20ms_-160ms_tcp_delivery_with_rtt.svg
pretty much demonstrated starvation and that is with TCP-Prague with rfc3168 detection. 


"2.  Per-Flow Fairness

   There are a number of factors that influence the relative rates
   achieved by a set of congestion controlled flows sharing a queue in a
   bottleneck link.

   TODO: discuss startup & convergence times, short flows, RTT-
   unfairness, differences in deployed CC algorithms, etc.

   TODO: also mention that flow sharding is commonplace, so per-flow
   fairness does not imply per-application fairness"


This obviously needs flashing out before one can meaningfully comment, but regarding the last section, you realize that application not the relevant classification for intermediate nodes? I would assume that for an ISP a (potentially weighted) per-end-host fairness would be the exact tool to avoid sharding as work-around... This is obviously not a new idea or comment, so if you opt for elaborating on fairness, please also include known remedies. Or better avoid that discussion here altogether.


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