Re: [tsvwg] Gorry Fairhurst Individual thoughts on choosing whether/how to advance ECN work.

[Sebastian Moeller <[e-mail]>]

Hi Gorry,


> On May 25, 2020, at 09:46, Gorry Fairhurst <[e-mail]> wrote:
> 
> Hello,
> 
> On 24/05/2020 13:37, Sebastian Moeller wrote:
>> Hi Gorry,
>> 
>> On 24 May 2020 10:01:33 CEST, Gorry Fairhurst <[e-mail]> wrote:
>>> On 24/05/2020 05:21, Jonathan Morton wrote:
>>>> I think I'll leave Paul and Sebastian to comment further in this
>>> vein.
>>>>   - Jonathan Morton
>>> If you decide to comment more, could you please finish that very
>>> quickly
>>> - the WG has decided to work on L4S.
>> [SM] On the danger of stating the obvious, that decision to work on L4S makes it quite important to highlight and discuss all the pain-points of the current L4S design, implementation and drafts. Unless I misunderstand what "work on L4S" is supposed to entail...
>> 
>> 
>>> There are topics that the WG needs to address, and I think this
>>> discussion is not helping the WG make progress.
>> [SM] For better or worse, this WG will be held partially accountable, for L4S meeting it's claims, so I consider discussion of those claims, with the eventual goal of finally de-hyping the draft text, pretty on-topic and relevant for the mailing list.
>> 
>> BUT, since that is so obvious that I assume I must be misunderstanding your point, so please show me where/how.
>> 
>> 
>> 
>> Best Regards
>>         Sebastian
>> 
>>> Gorry
> 
> I think it would be more normal to discuss or provide comments on a specific section of a document.

	[SM] Well, I have tried and cited critical sections of the RFC where implemented reality and claim differ in the past only to receive basically silence on the mailing list. 


> If there are claims there, then maybe these do need to be looked at -

	[SM] This reads as if you would doubt that there are claims in the RFC drafts, is that really your position? I appreciate your attempts at keeping an objective perspective here, but that seems a bit too much.


> it's not uncommon that the text around performance/merits in a spec need to be reviewed before a document completes WGLC.

	[SM] Fair enough. Now, I can not help wondering, why we should only consider doing such corrections and toning-down after basically adopting the drafts, given that these overly optimistic/unrealistic performance predictions and safety assessments* might well have influences the choices voiced in the consensus process.
 	

Best Regards
	Sebastian


*) Assessments is a strong word, "hopes" is a better description to L4S approach to safety/security, indicating a lack of actual testing under adversarial traffic patterns:

https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-11#page-21:
"Where the interests of users or flows might conflict, it could be
   necessary to police traffic to isolate any harm to the performance of
   individual flows.  However it is hard to avoid unintended side-
   effects with policing, and in a trusted environment policing is not
   necessary."

https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-06:
"Like the Classic service, the L4S service relies on self-constraint -
   limiting rate in response to congestion.  In addition, the L4S
   service requires self-constraint in terms of limiting latency
   (burstiness).  It is hoped that self-interest and standardization of
   dynamic behaviour (especially flow start-up) will be sufficient to
   prevent transports from sending excessive bursts of L4S traffic,
   given the application's own latency will suffer most from such
   behaviour.

   Whether burst policing becomes necessary remains to be seen.  Without
   it, there will be potential for attacks on the low latency of the L4S
   service.  However it may only be necessary to apply such policing
   reactively, e.g. punitively targeted at any deployments of new bursty
   malware."


> 
> Gorry
> 
>