Re: [tsvwg] continuing consensus check from virtual meeting

[Dave Taht <[e-mail]>]

On Mon, May 10, 2021 at 10:17 AM Wesley Eddy <[e-mail]> wrote:
>
> In the virtual interim, during discussion of
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4sops/ we asked as
> chairs:
>
> Does the group agree that with these guidelines available, that L4S will
> be suitable for experimentation in parts of the Internet?
>
> Looking at both the webex hand-raise and the chat response, there was a
> mixed response, though approximately 2-3x as much volume of support for
> this statement as there was disagreement with it. Some not supporting
> clarified as saying that they thought it should be isolated from
> non-participating networks, or that "coexistence must be ensured".
>
> If you were unable to participate in the meeting, or otherwise want to
> expand on this, more inputs on this are welcome.

I was busy at the 802.11 meeting today and was unable to attend.

If there was a way to register my permanent opposition to

1) the use of ECT(1) as a queue selector
2) the repurposing of CE to mean a multi-bit gradual signal rather than RFC3168

I'd like to use that in the future and for future votes.

I note there are a great number of others that have left this room,
and were it possible
to merely register their opposition in this way it would save on
everyone's time.

I have been thinking I would propose a mild revision to RFC3168 that
would say, that
upon receipt of a CE or SCE signal a transport SHOULD consider recent
RTT inflation
and attempt to adjust the pacing rate to suit. BBR trusts its model
more than markings
at present, with good reason.

I only reluctantly support use of any form of ECN at all, and
preferably only on closed loop, non
internet systems (like data centers and spacecraft).

It is the loss of RFC3168 style CE dramatic drop functionality over
long (world-girdling) paths for internet traffic, inherent in losing
it as a signal, that bothers me most. Thus SCE seems better,
with a guard DSCP chosen that falls into the wifi VI queue,  but I am
not impressed by the results there thus far either, and in particular
the wifi model they  are presently using is very inaccurate for the
actual behavior of 2 or more wifi stations.

PS I will try to work on a summary of the issues I think
insurmountable to an internet scale
experiment of these 2 L4S requirements.

PPS I have been out trying to get real world data on dscp and ecn
passthrough on various large networks of late. Tidbit:
linode<->starlink dscp and ecn marks survive. More news after
the paper is published.

PPPS I would like at some point to discuss how "queue protection" is
supposed to work. There is quite a lot to L4S that might prove
worthwhile. Are there any open source examples of this at this point?

>
>


-- 
Latest Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/

Dave Täht CTO, TekLibre, LLC