Re: [tsvwg] Reasons for WGLC/RFC asap

[Gorry Fairhurst <[e-mail]>]

On 19/11/2020 16:22, Pete Heist wrote:
> Hi Koen,
>
> Rather than thinking of this as advantages and disadvantages to 
> waiting, I see it as an engineering process. It was decided earlier 
> this year that the L4S proposal has enough support to continue, so 
> we're on that path now. Part of that decision, as I understood it, 
> also recognized that there are valid safety concerns around 
> compatibility with existing AQMs, and some solution needs to be devised.
>
> RFC3168 bottleneck detection was added to TCP Prague, which appears to 
> be difficult to do reliably when there is jitter or cross-flow 
> traffic, and it has since been disabled in the reference 
> implementation. The l4s-ops draft was started, but isn't complete yet 
> and may need WG adoption as part of a LC. We can then decide how 
> effective the proposed mitigations are against the risks and prevalence.
>
> To start a WGLC now would circumvent that earlier recognition that a 
> safety case needs to be made. Meanwhile, since testing showed that 
> tunnels through RFC3168 FQ AQMs are a straightforward path to unsafe 
> flow interaction, along with other issues relative to the goals, it 
> doesn't seem like the engineering process is done just yet.
>
By the way, I liked your data - and it helped me a lot to look at this, 
thanks very much for doing this.

It would help me if you clarify what you mean by  "unsafe" - to me 
"safety" relates to traffic unresponsive to drop, as in CBR traffic, 
etc. I've not understood how CE-marked traffic can erode safety, but 
maybe I missed something?

I'm not sure why "tunnels have crept in here. There have always been 
side-effects with classification (and hence scheduling), but I don't see 
new issues relating to "tunnels" with ECN.

I'm not commenting on when the Chairs think a WGLC will provide useful 
information, we'll say that in due course.

Best wishes,

Gorry

> Regards,
> Pete
>
> On Wed, 2020-11-18 at 10:31 +0000, De Schepper, Koen (Nokia - 
> BE/Antwerp) wrote:
>>
>> Hi all,
>>
>> To continue on the discussions in the meeting, a recap and some extra 
>> thoughts. Did I miss some arguments?
>>
>> Benefits to go for WGLC/RFC asap:
>>
>>   * There is NOW a big need for solutions that can support Low
>>     Latency for new Interactive applications
>>   * The big L4S benefits were a good reason to justify the extra
>>     network effort to finally implement ECN in general and AQMs in
>>     network equipment
>>   * Timing is optimal now: implementations in NW equipment are coming
>>     and deployment can start now
>>   * Deployment of L4S support will include deployment of Classic ECN
>>     too! So even for the skeptics among us, that consider that the
>>     experiment can fail due to CCs not performing to expectations, we
>>     will fall back to having Classic ECN support
>>   * Current drafts are about the network part, and are ready and
>>     stable for a very long time now.
>>   * Only dependency to CCs in the drafts are the mandatory Prague
>>     requirements (only required input/review from future CC
>>     developers: are they feasible for you)
>>   * We have a good baseline for a CC (upstreaming to Linux is blocked
>>     by the non-RFC status)
>>   * Larger scale (outside the lab) experiments are blocked by
>>     non-RFCs status
>>   * It will create the required traction within the CC community to
>>     come up with improvements (if needed at all for the applications
>>     that would benefit from it; applications that don’t benefit from
>>     it yet, can/will not use it)
>>   * NW operators have benefits now (classic ECN and good AQMs) and in
>>     the future can offer their customers better Low Latency
>>     experience for the popular interactive applications
>>   * When more L4S CCs are developed, the real independent evaluation
>>     of those can start
>>
>> Disadvantages to wait for WGLC/RFC:
>>
>>   * We’ll gets stuck in an analysis paralysis (aren’t we already?)
>>   * Trust in L4S will vanish
>>   * No signs that we can expect more traction in CC development;
>>     trust and expectations of continuous delays will not attract
>>     people working on it, as there will be plenty of time before
>>     deployments are materializing
>>   * Product development of L4S will stall and die due to uncertainty
>>     on if L4S will finally materialize
>>   * Product development of Classic ECN will stall and die due to
>>     uncertainty on how L4S will finally materialize
>>
>> What are the advantages to wait? Do they overcome these disadvantages?
>>
>> Regards,
>>
>> Koen.
>>
>