Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

[Gorry Fairhurst <[e-mail]>]

I agree Ingemar, 

This really  is not a new topic, and the WG should only be revisiting this if there is a new requirement - the design to allow the traffic to be DSCP-marked was not taken without thought and  visibility.

... If an operator wishes to do this internally, that’s fine and they can use a private DSCP to do just that.

Gorry

> On 24 Mar 2021, at 07:35, Ingemar Johansson S <ingemar.s.johansson=[e-mail]> wrote:
> 
> Hi Steve, David + others
> 
> I believe that it is good to refer back to 
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14#appendix-B.4 
> before taking this discussion further.
> 
> /Ingemar
> 
> 
>> -----Original Message-----
>> From: tsvwg <[e-mail]> On Behalf Of Steven Blake
>> Sent: den 24 mars 2021 06:53
>> To: Black, David <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>> 
>>> On Mon, 2021-03-22 at 19:30 +0000, Black, David wrote:
>>> Following up on Pete's comment:
>>> 
>>>> Along these lines, there is nothing stopping anyone from using DSCP
>>>> (as an appropriate risk control within participating ASs), to
>>>> perform experiments to reproduce issues that can be demonstrated in
>>>> the lab.
>>> 
>>> That is a commendable approach, particularly as it is effectively
>>> recommended by RFC 4774 (Specifying Alternate Semantics for the
>>> Explicit Congestion Notification (ECN) Field) - see Section 3 [1], and
>>> take note that RFC 4774 is a BCP (Best Current Practice) whose author
>>> was the late Sally Floyd.  It may be time for the WG to reconsider the
>>> L4S approach of using alternate ECN semantics without qualification by
>>> DSCP, at least to run experiments on actual networks.
>>> 
>>> My 0.02 is that an Experimental RFC that used a DSCP to signal the L4S
>>> ECN semantics (in participating networks) could have been published at
>>> least 2 years ago.
>> 
>> I agree wholeheartedly (as I have said multiple times in the past).
>> 
>> As it stands, the -l4ops draft puts a burden on operators who are minding
>> their own business to evaluate and potentially make operational changes to
>> their network to avoid potential disruptions to their network performance,
>> for the benefit of someone else's experiment. That is not appropriate IMHO
>> nor is it necessary when an alternative (DSCP
>> isolation) is available.
>> 
>> 
>> Regards,
>> 
>> // Steve
>> 
>> 
>> 
>