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

["Roni Even (A)" <[e-mail]>]

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