Re: [tsvwg] Reasons for WGLC/RFC asap

[Pete Heist <[e-mail]>]

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.

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