Re: [Ecn-sane] [tsvwg] Comments on L4S drafts

["Scharf, Michael" <Michael.Scharf@hs-esslingen.de>]

One comment, also with no hat on...

> -----Original Message-----
> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Black, David
> Sent: Friday, July 19, 2019 10:06 PM
> To: Wesley Eddy <wes@mti-systems.com>; Dave Taht <dave@taht.net>; De
> Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-
> labs.com>
> Cc: ecn-sane@lists.bufferbloat.net; tsvwg@ietf.org
> Subject: Re: [tsvwg] [Ecn-sane] Comments on L4S drafts
> 
> Two comments as an individual, not as a WG chair:
> 
> > Mostly, they're things that an end-host algorithm needs
> > to do in order to behave nicely, that might be good things anyways
> > without regard to L4S in the network (coexist w/ Reno, avoid RTT bias,
> > work well w/ small RTT, be robust to reordering).  I am curious which
> > ones you think are too rigid ... maybe they can be loosened?
> 
> [1] I have profoundly objected to L4S's RACK-like requirement (use time to
> detect loss, and in particular do not use 3DupACK) in public on multiple
> occasions

... and I have asked in public to remove the RACK requirement, too.

> because in reliable transport space, that forces use of TCP Prague,
> a protocol with which we have little to no deployment or operational
> experience.  Moreover, that requirement raises the bar for other protocols
> in a fashion that impacts endpoint firmware, and possibly hardware in some
> important (IMHO) environments where investing in those changes delivers
> little to no benefit.  The environments that I have in mind include a lot of data
> centers.  Process wise, I'm ok with addressing this objection via some sort of
> "controlled environment" escape clause text that makes this RACK-like
> requirement inapplicable in a "controlled environment" that does not need
> that behavior (e.g., where 3DupACK does not cause problems and is not
> expected to cause problems).

Also, note that the work on RACK is ongoing in TCPM. While there seems to be plenty of deployment expertise, it is perfectly possible that issues will be discovered in future. And we are pre-WGLC in TCPM, i.e., even the specification of RACK could still change.

In general, listing in one experiment requirements on the outcome of another ongoing experiment is a bad idea and should be avoided, IMHO. I have also mentioned this in the past and will not change my mind so easily. Historically, the IETF has good experience with bottom-up modular protocol mechanisms and running code instead of top-down architectures.

Michael