Re: [tsvwg] Review comments on a careful read of the L4S ID

[[e-mail]]

Gorry,

Thanks. I don’t think that any content or network provider interested in the L4S queue management has to wait for standards bodies. But to see, whether L4S is a useful queue management mechanism, a transport protocol is required, as well as end points correctly interpreting the L4S ECN marking behaviour. And transport then needs to react to that in an appropriate way.

Experimental deployment of L4S without an adapted transport for any kind of pilot looks pointless to me.

Reading RFC3168, I see

      * The sender receives the TCP ACK with ECN-Echo set, and reacts to
        the congestion as if a packet had been dropped.

Looking into draft-ietf-tsvwg-ecn-l4s-id-15, I find:



   As a condition for a host to send packets with the L4S identifier

   (ECT(1)), it SHOULD implement a congestion control behaviour that

   ensures that, in steady state, the average duration between induced

   ECN marks does not increase as flow rate scales up, all other factors

   being equal.  This is termed a scalable congestion control.  This

   invariant duration ensures that, as flow rate scales, the average

   period with no feedback information about capacity does not become

   excessive.  It also ensures that queue variations remain small,

   without having to sacrifice utilization.



   With a congestion control that sawtooths to probe capacity, this

   duration is called the recovery time, because each time the sawtooth

   yields, on average it take this time to recover to its previous high

   point.  A scalable congestion control does not have to sawtooth, but

   it has to coexist with scalable congestion controls that do.



   For instance, for <example Transport> the average recovery time is always half a round

   trip (or half a reference round trip), whatever the flow rate.



   As with all transport behaviours, a detailed specification (probably

   an experimental RFC) will need to be defined for each congestion

   control, following …. [RFC5033<https://datatracker.ietf.org/doc/html/rfc5033>].  In addition it will need to

   document these L4S-specific matters, specifically the timescale over

   which the proportionality is averaged, and control of burstiness.

   The recovery time requirement above is worded as a 'SHOULD' rather

   than a 'MUST' to allow reasonable flexibility when defining these

   specifications…..

It is not appropriate to blame the authors of L4S for the evolution of the Internet which causes some of the constraints, all transport developers are obliged to respect today. I still note that I can’t yet walk away and implement a transport making fair use of L4S in the full Internet environment of today, whereas I am able to request adaptation of one transport protocol at least using RFC3168. If I’m wrong, those operating pilot deployments in productive environments may speak up (I also don’t expect results, the fact that there’s a test is sufficient). I personally am interested in a mechanism delivering the properties promised by L4S, if it allows for a smooth migration.

Regards,

Ruediger




Von: tsvwg <[e-mail]> Im Auftrag von Gorry (erg)
Gesendet: Samstag, 8. Mai 2021 19:15
An: C. M. Heard <[e-mail]>
Cc: TSVWG <[e-mail]>
Betreff: Re: [tsvwg] Review comments on a careful read of the L4S ID

See below


On 8 May 2021, at 16:15, C. M. Heard <[e-mail]<mailto:[e-mail]>> wrote:

On Fri, May 7, 2021 at 11:22 PM Gorry Fairhurst  wrote:
[GF] You seem to keep arguing in a direction that would result in
obsoleting RFC3168 before we progress L4S, but I don't agree this
ordering is needed. The proposal I see is that the deployment takes
place and then the IETF has the option to decide what happens next.

Seeing the word ***deployment*** instead of the word ***experiment***
in the last sentence above,  I have to agree with Sebastian on this point.

Mike Heard

Well, I think that the purpose of an EXP RFC is to allow initial deployment, and to gain useful experience and then to understand any changes that are  needed to the Spec.

Nobody needs a RFC to do an experiment within their own controlled network. Anyway, this is what I will call  the “alternate ECN semantics RFC” already allows using a private DSCP.

I also know that In many cases, EXP specs do not result in any useful deployment, and that also is a risk.

Gorry