Re: [tsvwg] path forward on L4S issue #16

[Sebastian Moeller <[e-mail]>]

Hi Wes,

Sure Global dscp traversal might not be a reality right now.
BUT that did not stop the introduction of the NQB internet draft that in essence tries to standardize a PHB/dscp that is pretty much the missing L4S dscp*. 
AND there are currently no data backing up the assertion that L4S will actually be useful in long-haul paths to beginn with**. For the only tested use case, essentially short RTT low hop count CDN to end user path, dscp traversal will not be a showstopper, just look at the rationale in the NQB draft.
And given the status of the NQB draft, this might reach maturity/publication well before the L4S drafts, so the appropriate L4S PHB will be defined although it is claimed that dscp will not work, anybody else seeing a disconnect here?
So instead of trying to optimize for universal roll-out maybe it would behoofe the L4S effort to aim a bit lower and gain some real world experience first, like walk before you run? 



Regards
        Sebastian



*) Currently the NQB draft excludes capacity seeking flows, but could be amended to allow such flows, if they use 1/p congestion signaling. As far as I can tell NQBs reason for existence is to have a method to have endpoints steer non ECT(1)-flows into potential LL-queues along the path. Such a method is also hinted at in one of the L4S drafts, so in spite of RSVPs being declared insufficient in all likelihood they will be used in the L4S ecosystem.

**) Testing with a single netem instance giving a constant delay of X milliseconds is not a realistic test of a high RTT high hop-count path, it is rather a test of a condition exceedingly rare in the real world, high RTT low hop count... I have been asking for realistic tests for some while now, and am beginning to assume that the lack of data might be an indication that the current L4S implementation and design simply does not cope well with the requested realistic conditions. With the existing testing harness used for the supporting papers testing the realistic scenarios I laid out in past emails should have been relative easy. I for one an done with giving L4S the benefit of the doubt.

On 23 June 2020 06:39:18 CEST, Wesley Eddy <[e-mail]> wrote:
>Hi Rod, I didn't say any of the things you're asking about; only that 
>DSCP global traversal does not appear viable to depend on in the near
>term.
>
>
>On 6/23/2020 12:27 AM, Rodney W. Grimes wrote:
>> Hello Wes,
>>
>> Excuse me, but L4S itself even defined DSCP as one of the
>> alternative mechansims to ECT(1).  Are you saying we should
>> remove those alternatives from the draft?
>>
>> Further on several occasions David Black, and others have asserted
>that
>> DSCP is a viable path forward for L4S.
>>
>> How are these solutions suddenly not to be included in the
>considerations
>> of what may be a way to address Issue #16?  These are solutions that
>> can be used today, though the global traversal is not a requirement
>> for them to be used, and they are infact being used to conduct SCE
>> experimentation.  I find it unsettling that L4S proponets would not
>> consider this as a way to produce data that might influence the WG.
>>
>> No comments inline,
>> Regards,
>> Rod
>>
>>> Hi Rod, I just have a short comment from what I have seen as the WG
>>> interests.
>>>
>>> I have not noticed much interest in DSCP global traversal,
>especially
>>> from the parties that would need to support it.? Since that is also
>>> explicitly against the DiffServ architecture that incorporates
>>> re-marking, suggesting it is a rather big change to all of how
>DiffServ
>>> has been defined, unless I misunderstand.? I believe any activity or
>>> proposals on global DSCP traversal are very interesting and totally
>fine
>>> to discuss, but can't be a gate for L4S.
>>>
>>>
>>> On 6/19/2020 11:14 PM, Rodney W. Grimes wrote:
>>>> Jake,
>>>> 	Thank you for spending the time to collect this
>>>> detailed summary.
>>>>
>>>> 	I believe you left out: (adding one to your last one and listing)
>>>>
>>>>    7.  Use a DSCP to seperate the experiment, leaving ECT(1) and CE
>as
>>>>        currently specified in the L4S draft.
>>>>
>>>>    8.  Use a DSCP to classify the traffic as L4S and leave ECT(1)
>unused,
>>>>        altering CE semantics.
>>>>
>>>>    9.  Use a DSCP to classify the traffic, and use ECT(1) as a 1/p
>signal,
>>>>        leaving CE semantics in place.
>>>>
>>>> 10.  Dropping L4S as over promising and short delivering with
>complexity
>>>>        that almost certainly sets it up for a failed deployment.
>>>>
>>>> Note that in all 4 of these solutions bleaching is unlikely to be
>>>> used if there are problems, and the experiment is rather trivial to
>>>> terminate if there are problems.  These also keep ECT(1) avaliable
>>>> for a future non-experiment version of L4S should the experiment
>work,
>>>> or something else should it fail.  7 to 9 can even be started today
>>>> without an IETF consenses and some real operational data created.
>>>>
>>>> On the side, IMHO, the work going into L4S would be better spent
>addressing:
>>>> a)  DSCP global traversal
>>>> b)  ack thinning being underspecified such that it creates protocol
>>>>       problems.  Specifically the fact it tosses out changes in
>reserved
>>>>       bits by thinning packets with different bit values.  This was
>>>>       identified years ago and left as a problem, it needs cleaned
>up.
>>>> c)  Revision to RFC6040 and other tunnel related drafts to clear
>>>>       the issues there.  Again, identified years ago and left to
>clean
>>>>       up.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.