Re: [tsvwg] Adoption call for draft-white-tsvwg-l4sops - to conclude 24th March 2021

[Sebastian Moeller <[e-mail]>]

Hi Jason,

thanks.

> On Mar 25, 2021, at 17:53, Livingood, Jason <[e-mail]> wrote:
> 
> On 3/25/21, 11:16 AM, "tsvwg on behalf of Sebastian Moeller" <[e-mail] on behalf of [e-mail]> wrote:
>>   just to ridicule me, what kind of L4S experiments are you keen to start?
> 
> [JL] Testing L4S on an E2E basis from the WLAN-based client all the way to the app provider on the other end. No particular details defined other than that -

	[SM] Given that you work for a big ISP that has many industry partners, certainly also in the content business, why do you need an RFC status to start such experiments, especially, if, as you indicate below, you know how to isolate such experiments from causing harm? If you ask me these two claims do not add up fully yet, sorry. 

> this is pretty early stage stuff but seems like the next logical step for this type of technology.

	[SM] I had expected there to be somewhat more precise plans with clearer hypothesis to test. I also assumed, that the DOCSIS world would start mass deployment of L4S network bits (under the name of low latency docsis) the moment the IETF ratifies the L4S RFCs, given for how long LLD is already advertised and marketed. 
	But I am happy if I a plainly wrong and the cable industry is planning a careful, experiment-driven staged test and deployment instead. Let's see which of the two alternatives will play out. ;)

> 
>> Will you share the data and inform the WG about the nature and outcome of said experiments?
> 
> [JL] I would think so - we have previously done so with DNSSEC, IPv6, DoH, etc.

	[SM] Excellent, I welcome that. After asking here in the list for some time now, that parties that support L4S show which data convinced them to do so, I am looking forward to that data, whenever it will be ready.


> 
>> What mechanisms do you intend to employ to restrict the experiment to consenting adults^W^W knowing and willing partners?
> 
> [JL] TBD as plans are worked out. But companies that operate infrastructure at scale are naturally focused on risk management of new technology testing & deployment, so I don't think there is cause for alarm in your part if that is what you are getting at.

	[SM] Mmmh appeal to authority? Really, I am willing to trust you personally, and do not expect malice here. But that does not fill me with confidence that your containment plans are ready for action tomorrow.

> 
> [JL] BTW, if you know of anyone willing to develop code changes to AQM implementations in OpenWrt to handle ECT1-marked packets according to the L4S semantics, let me know as that seems something worth technically exploring as a related matter (noting that I chair a grants fund at my work that does underwrite open source dev and other applied research).

	[SM] In all honesty, thanks, but before I convince anybody to work on that, I want to see data first that this is a good idea to do in the first place. Especially, is that change safe, and does this actually realize improvements for more than L4S' design sweet spot, the short RTT low-hop-count fast lane between eyeballs and near-by content. 
	Don't get me wrong I will not stop anybody doing that, but I will not actively work towards that goal until and unless I am convinced that this offers an improvement for the whole internet. And I am not interested in expediting/speeding up short RTT flow at the expense of longer RTT flows, but that is what L4S currently does.

Sidenote:, the best way of getting any capability into OpenWrt is to have your feature accepted and included into the mainline Linux kernel, then it will percolate into OpenWrt automatically.


Best Regards
	Sebastian