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

[Sebastian Moeller <[e-mail]>]

Hi Gory,


> On Mar 24, 2021, at 14:57, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 24/03/2021 13:53, Black, David wrote:
>>> The interaction with DSCPs was revisited in 2018
>>> (draft-briscoe-tsvwg-l4s-diffserv-00), after RFC8311 enabled such a
>>> deployment experiment using ECT(1).  That which explains how the two
>>> approaches interact, how they can be arranged to complement each other
>>> and in which cases one can stand alone without needing the other.
>> My recollection is that this draft was not taken forward due to lack of interest at the time.
>> 
>> Thanks, --David
> 
> True, the discussion of Diffserv goes has to date gone in cycles - with few (if any) operators stepping-up and saying that they would like to deploy L4S with a DSCP.

	[SM] Could you clarify please, if there is zero interest by operators to participate in the L4S experiment if DSCPs will be required, or requiring DSCPs will be a (potential) hurdle for an internet wide deployment of L4S? 
	Side-question, if you are asked between two options with the same benefit for you, which would you select the one requiring more effort to implement or the easier one? In other words is relative convenience of deployment for operators really the ideal yard-stick for selecting safety mechanisms?
	As much as I personally dislike the overloaded ECT(1)/CE design of L4S, for running an experiment, guarding the current design with an additional layer of DSCP to assure that unwitting bystanders are not affected by the experiment, seems like a way forward to starting an experiment, without completely re-opening the "classifier" question.
	And if I understand the L4S position correctly, all reasonable tests that do not require real networks have been exhausted, and hence further testing needs to be performed on lie networks, and a guard DSCP would allow exactly that.
	What a guard DSCP would not easily allow is internet-wide roll-out of the L4S network bits, but given that the experiment has not been run yet and hence no feed-back from the acquired data back into design and implementation has been possible, such a deployment would seem probably a bit premature today, no? 

Best Regards
	Sebastian



> 
> Gorry
> 
>> 
>> -----Original Message-----
>> From: tsvwg <[e-mail]> On Behalf Of Gorry Fairhurst
>> Sent: Wednesday, March 24, 2021 8:47 AM
>> To: Pete Heist; [e-mail]
>> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> So injecting a little more history here.
>> 
>> Some previous discussions are:
>> 
>> The earliest discussion of L4S in the IETF that I recall was in 2015.
>> When discussing, it was known that RFC4774 would allow experimentation
>> with a diffserv domain (e.g., as in RFC 6660), but the practicalities of
>> deploying an end-to-end Internet transport required an RFC to use a
>> method that was not protected by a DSCP. The discussion on whether the
>> ECN Plus a Diffserv Codepoint (DSCP) was also noted in the appendix of
>> draft-briscoe-tsvwg-ecn-l4s-id-00 in 2015.  R
>> 
>> Tradeoffs that lead to using ECT(1) were described in the proposal to
>> the AQM working group in draft-briscoe-aqm-dualq-coupled-00 in 2015.
>> 
>> The interaction with DSCPs was revisited in 2018
>> (draft-briscoe-tsvwg-l4s-diffserv-00), after RFC8311 enabled such a
>> deployment experiment using ECT(1).  That which explains how the two
>> approaches interact, how they can be arranged to complement each other
>> and in which cases one can stand alone without needing the other.
>> 
>> Gorry
>> 
>> On 24/03/2021 11:01, Pete Heist wrote:
>>> I'll just add to the sentiment that I think the use of DSCP is still
>>> worthy of consideration. Beyond the use of a single DSCP on all
>>> traffic, there may be other alternatives that address at least some of
>>> the concerns in B.4.
>>> 
>>> Pete
> 
>