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

["Holland, Jake" <[e-mail]>]

Hi Gorry,

At the time of that design decision, we were still promised that
a solution to the 3168 interop problem would be forthcoming, but
that seems to have fallen through as not tractably implementable
and is now proposed to be handled chiefly by operational
considerations, in light of the poor performance of the proposed
algorithms in lab testing.

That change in scope over the course of that discovery merits a
re-evaluation of the design decisions that compromise on safety
considerations, IMO.

(Though it's still listed as a requirement in A.1.4 of l4s-id
and references provided as though it's a reasonably well-solved
problem, so maybe I'm misunderstanding the outcome of some of
the discussions since November 2019?  I'm not clear on whether an
update is planned to that section...)

Anyway, I believe we saw a call or 2 for further discussion of this
question in comments from several people in the last year.

I'll agree this is not a new topic, and that it would be great if
anyone who wants to comment would read through B.4 of l4s-id to
refresh their memory and spend some effort speaking to the points it
raises, but I also think there's a fair bit of unexplored discussion
space here that's worth re-opening if the "fallback on classic ecn"
requirement is to be dropped or weakened.

Best regards,
Jake


On 3/24/21, 1:29 AM, "Gorry Fairhurst" <[e-mail]> wrote:

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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-14*appendix-B.4__;Iw!!GjvTz_vk!He0Lu9NS80YwQ0QKP_9uL9JSDpboI_ZjeH98P87VfX06JeFArdwFisa8UcOXx0U$  
> 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
>> 
>> 
>> 
>