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

[Wesley Eddy <[e-mail]>]

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.