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

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi SCE'ers,

I don't think this is a personal battle, nor a competition or an attempt to stop/block competition. I just want to call for using common sense. It is the role of IETF to come to consensus and make sure that there is a common way forward. We also cannot let individual users of cars decide if they want to drive left or right on the roads, or pick their favorite color to stop on traffic lights.

Releasing two simultaneous experiments on the same code point with largely the same goals will likely result in the code point becoming useless.

On the other hand, I think the evolutional analogy is a good approach. If the Internet is the existing ecosystem and the new ECN codepoint we select is the gene combination, we need to make sure that we select the fittest one, that gets the best chances to survive and flourishing (that users want to use and that replaces the existing codepoint). Releasing 2 in parallel that will rather kill each other is not what we want, right?

I also don't think that coupling or blocking the future of Low Latency ECN on technologies, that have been proven hard to adopt in the industry, is a better strategy.
Related to long adoption times, rfc3168 got the opportunity of about 20 years to get adopted, FQ got I guess 10 years to get adopted, and for both I see no real/general Telco industry (silicon) adoption.

That's why I see only the SCE-FQ dependency as a real adoption-show stopper. Believe me that getting support for ECN in silicon is already a challenge, you don't want to additionally put FQ on the plate (or should I say wafer) as well...

Obviously in circumstances where FQ is beneficial or FQ and ECN is easy to implement or is already implemented, L4S is a very simple upgrade. I think it would be very useful to have an L4S-FQ draft for this. Volunteers?

Regards,
Koen.


-----Original Message-----
From: Sebastian Moeller <[e-mail]> 
Sent: Thursday, November 14, 2019 7:40 PM
To: De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>
Cc: Rodney W. Grimes <[e-mail]>; [e-mail]
Subject: Re: [tsvwg] Requesting TSVWG adoption of SCE draft-morton-tsvwg-sce

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