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

[Sebastian Moeller <[e-mail]>]

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