Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

[Ingemar Johansson S <[e-mail]>]

Hi

I don't believe that it is a good idea to add yet another ECN experiment at
this stage.  I tried to formulate my arguments below as well and
non-provocative as possible. If the language appears blunt, then blame it on
my 8 years old kid level English. 

I have for a while advocated the role of L4S as enabler for low latency
packet transport in 3GPP standardized access. Lately it seems like that
Sisyphus ball is perhaps a little bit easier to push up the hill, but
admittedly it is far too early to uncork the champagne bottle, attempts to
promote ECN have failed before. 
5G-AIS (Advanced Interactive Services)  is one work item in 3GPP where L4S
can be a useful tool to  reach the goal of low e2e latency and the big
benefit is that we get 5G network nodes to interact well with transport
protocols devised and standardized in the IETF (TCP and QUIC among others).
There are other use cases such as remote control where L4S will come in
handy. 

You may recall that there have been a lot of initiatives over the years with
protocol additions that are suggested to add interaction between network
nodes and endpoints with explicit rate recommendations, either inband in TCP
headers or by means of some other out of band signaling mechanism, none of
these initiatives have fared well AFAIK.  My argument is here that L4S can
provide with a generic signal that can solve most (if not all) of the
challenges that the more transport protocol specific mechanisms sought to
solve, and that with much less concerns as regards to challenges with e2e
encryption of transport headers etc. Additional work such as paced chirping
etc. can further help to enhance the solutions.
 
Now, say that the WG adopts SCE as well, this means that any SDO outside
IETF will have to choose between two alternatives and the likely outcome is
that none is chosen, simply because the solution space is now completely
fragmented, in the worst case ECN becomes a dead end.  And with that
situation it becomes necessary to find other technical solutions that enable
low latency, after all we still have the wish to enable support for low
latency.   

Before somebody starts to say that 3GPP, or any other SDO for that matter,
should not dictate how IETF should work, you are absolutely right!, that is
not the intention. 
I write this as an individual with a strong interest in e2e solutions that
scale well, don't cost an arm and a leg to implement, have a chance to
become widely used, and gives good end user experience.  I don't want to
change IETFs decision process, but want to point out the risk I see if the
WG decides to adopt another ECN experiment that is largely incompatible with
the existing L4S experiment. 

/Ingemar


> From: "Roni Even (A)" <[e-mail]>
> To: G Fairhurst <[e-mail]>, "[e-mail]"
> 	<[e-mail]>
> Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE
> 	draft-morton-tsvwg-sce
> Message-ID:
> 	<6E58094ECC8D8344914996DAD28F1CCD23DBDCEB@DGGEMM506-
> MBS.china.huawei.com>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> Inline
> 
> > -----Original Message-----
> > From: tsvwg [mailto:[e-mail]] On Behalf Of G Fairhurst
> > Sent: Thursday, November 14, 2019 8:51 PM
> > To: [e-mail]
> > Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-
> > tsvwg-sce
> >
> > I think we could do better to keep the discussion focussed on why the
IETF
> > would need an additional level of signal (aka
> > ECT(0)->SCE->CE->Loss) and whether this has implications on existing
RFCs
> > and the chartered work.
> [Roni] I think this is one  way to look at it but in my view I think that
the
> SCE/L4S usage is a hint that we need to look at a more general way to
extend
> the ECN/CC information to allow for more congestion information and
> learning the path characteristics to allow for other extensions in the
future
> >
> > Gorry
> >
> > On 15/11/2019, 02:39, Sebastian Moeller wrote:
> > > Hi Koen,
> > >
> > > given the list of open issues with L4S components adopting this draft
> seems
> > pre-mature:
> > >
> > > 1) peaceful coexistence with 1/sqrt(p) traffic at short RTTs with
L4S's
> > preferred dual queue AQM (dualQ), IMHO this is a show stopper unless the
> > aim is to give L4S style traffic an (unfair) bandwidth advantage.
> > >
> > > 2) peaceful coexistence with rfc3168-compliant ECN using AQMs (TCP
> > > Prague)
> > >
> > > Given the duration of the L4S project's development so far, it seems
> > optimistic that these issues will be solved and robustly stress tested
any
> time
> > soon.
> > >
> > > In that light in incompleteness and given that evolution works best
> > > under selective pressure and competition I think SCE should be allowed
> to
> > progress to RFC status on its own merits IMHO both proposals should
(once
> > show stoppers for safe operation on the internet are fixed) be given a
fair
> > chance to prove themselves as robust reliable and effective. Trying to
> > dispose of valid competition by appeal to the editors strikes me as an
> indirect
> > admission that one's own solution might be inferior...
> > >
> > >
> > > Best Regards
> > >
> > >
> > >
> > >
> > >> On Nov 14, 2019, at 18:04, De Schepper, Koen (Nokia -
> > BE/Antwerp)<[e-mail]>  wrote:
> > >>
> > >> Hi all,
> > >>
> > >> I think it will be a very bad idea to start now an additional
experiment
> > which conflicts with the ongoing adopted drafts. We need to make sure
> that
> > the initial work can be finalized and that we don't self-undermine the
> > ongoing successful initiative with a second proposal which has a lesser
> scope
> > and no industry adoption.
> > >>
> > >> L4S work might not be very visible on the mailing list (because of
the
> > industry context), but there is traction with first product
availabilities to be
> > announced next year. CableLabs standardized L4S in LLD, and vendors are
> > working on this. Nokia has demonstrated L4S integration in its WiFi
Beacons
> > at BBWF19, which will be available Q1 next year, and other products will
> > follow. I'm sure these are not the only examples.
> > >>
> > >> On the other hand, the main concern about SCE is still not solved: I
see
> no
> > solution for the problem that SCE works only for FQ_x.
> > >> I also see no solution for SCE to work next to and without
interfering
> with
> > the ongoing L4S initiative.
> > >>
> > >> If we want to achieve low latency on the Internet, we need to bundle
> the
> > effort and maximize the chances for success of the most promising
> solution.
> > No solution is perfect by the way, and we should stop trying to expect
> > perfection too.
> > >>
> > >> I hope from a network vendor's perspective that we can finalize the
> > network drafts. The DualPI2 implementation is stable, seems we need to
> get
> > some agreement on the wording of the drafts and we need to find a
> > compromise on the TCP-Prague requirements between what application
> > developers think is feasible and safe enough/likely to happen. The
> > application/service provider's motivation will be higher than that of
> network
> > vendors to get a deployable TCP-Prague implementation (they for sure
> have
> > already solutions ready to try out and experiment with). Let's focus on
this,
> > instead of creating diversions...
> > >>
> > >> Koen.
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: tsvwg<[e-mail]>  On Behalf Of Rodney W.
> Grimes
> > >> Sent: Thursday, November 14, 2019 2:50 PM
> > >> To: [e-mail]
> > >> Subject: [tsvwg] Requesting TSVWG adoption of SCE
> > >> draft-morton-tsvwg-sce
> > >>
> > >> Hello tsvwg list members,
> > >>
> > >> It is our intent to ask for adoption by the TSVWG of
draft-morton-tsvwg-
> > sce (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01) during the
> > IETF/106 Singapore TSVWG session.
> > >>
> > >>
> > >> The TSVWG chairs have provided the following guidelines for this
> > adoption request:
> > >>
> > >> (1) The WG chairs want to see interest in SCE technology beyond the
> draft
> > authors in order to adopt the SCE draft.   This will include surveying
the
> room
> > in Singapore (e.g., who has read this
> > >> draft?).
> > >>
> > >> (2) Coexistence of the L4S and SCE experiments is a concern that will
> need
> > to be addressed by the WG if the SCE draft is adopted, and hence is in
> scope
> > for discussion of this adoption request ..  In particular, absence of a
> > coexistence plan (e.g., to deal with the different uses of the ECT(1)
> > codepoint by L4S and SCE) is not an automatic barrier to WG adoption of
> the
> > SCE draft.
> > >>
> > >> (3) The TCPM WG chairs have indicated TCPM WG willingness to
> consider
> > complementary TCP work needed to complete SCE functionality.  In
> > particular, draft-grimes-tcpm-tcpsce is likely to be inc luded in the
TCPM
> > Singapore agenda for Friday morning.
> > >>
> > >>
> > >> Regards,
> > >> --
> > >> Rod Grimes
[e-mail]
> > >>
> 
> 
>