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

[Sebastian Moeller <[e-mail]>]

Hi Gorry,

more below.

> On Nov 14, 2019, at 19:50, G Fairhurst <[e-mail]> wrote:
> 
> 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.

	[SM] Well , since CE is already in use, re-defining it comes with the issue of non-compatibility with parts of the existing internet. It seems much easier to avoid undesired negative interactions with rfc3168 compliant network nodes by keeping the original meaning of CE. But since a [weaker | faster | non-1/sqrt(p)] type signal is desired for explicit congestion notification an additional signal level seems worth to spend one ECN code point on. (It is not that the L4S approach would conserve that ECN codepoint). SCE seems to be compatible with the existing internet. 
	To my knowledge the only known issue of contention is L4S' proposed redefinition of the ECN code-points which makes L4S and SCE incompatible. Since L4S seems to be currently aimed for deployment at the ISP customer boundary, I would propose for the duration of both the L4S and SCE experiments to mandate an "access network MUST make the use of L4S/SCE type AQMs configurable by the end-customers" (what I mean is if an ISP deploys any one the customer needs to be able to shut it off), that way end-users have the choice which interpretation of ECT(1) they prefer. 
	Yes, that will not be perfect future proof way to deploy any of these, but how about getting real world data in to show that universal deployment of any of the alternatives is justified and desirable?

Best Regards
	Sebastian


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