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

[Sebastian Moeller <[e-mail]>]

Hi Gory,

I think these are different issues. To my knowledge the WG never discussed using DSCPs to at least guard L4S signaling DURING the experiment, 

To recap:


   Cons:

   Consumes DSCP pairs:  A DSCP is by definition not orthogonal to
      Diffserv.  Therefore, wherever the L4S service is applied to
      multiple Diffserv scheduling behaviours, it would be necessary to
      replace each DSCP with a pair of DSCPs.


Given that during the experiment we expect willingly participating networks that actually are prepared to measure and monitor L4S behavior, employing two DSCPs will not be a blocker.




   Uses critical lower-layer header space:  

Seems to apply to ECT(1) as well.




   Not end-to-end (host-network): 
and
   Not end-to-end (network-network):  


In the context of the experiment this is exactly part of what makes DSCPs a useful safety mechanism, as we can hope for little leakage of L4S signalling unless all participating nodes have been made L4S-aware, exactly what seems appropriate for an experimental roll-out, no?

      Local-use DSCP:  
and
      Recommended standard DSCP:  

Are not relevant at all, and seem to indicate a confusion between PHB and DSCP on the part of the writers of said paragraphs.


   Not all tunnels:  

Again for an experiment, it seems a big enough task to start out with not handling all tunnels. After all L4S is building a speed-way between near data sources and data consumers so the amount of to-be-expected tunneling will be relative small. And in all honestly, the not-all-tunnels argument ALSO applies to ECT(1), so not a unique con.


   ECN hard in some lower layers::  

Again, the primary roll-out of L4S AQM will probably be close to the edges, that is close to data sources and data destinations, it is IMHO quite likely that both ends "speak" mostly IP so this con should not stop initial experiments.


   Hard to distinguish Classic ECN AQM:  
In the scope of the experiment with willingly participating networks, that could simply be ruled out a-priori and hence should be a no issue for an experiment.


   Could migrate to e2e:  

This is not even a cogent con of using DSCP as identifier. I propose that we delete that from the draft completely.


IMHO this section of the draft is not at odds with requiring that an L4S experimental roll-out is guarded behind a DSCP to make sure that only parties that know what they are getting themselves into will participate. In fact a number of these "cons" are IMHO actual "pros" for requiring a DSCP.


Best Regards
	Sebastian



> On Mar 24, 2021, at 09:28, 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://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
>>> 
>>> 
>>> 
>> 
>