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

[Gorry Fairhurst <[e-mail]>]

On 24/03/2021 15:04, [e-mail] wrote:
> Hi Gorry,
Hi
> My take was that a CDN or content owner might be interested in L4S and start experiments without asking operators for co-operation.

Sure. So in this case, bottlenecks in that operator network could then 
receive ECT(1) traffic and not expect this.

> Then innocent bystanders may get hit and a specified DSCP might allow for protection.

The bystanders are those impacted by a "CE-marking from a non-L4S 
router" that is congested, but where the other traffic responds using L4S.

Is this any different to the first operator not forwarding the ECT(1) 
codepoint?

I do wonder if this proves a real problem whether the community might 
deprecate CE-marking of ECT(0) in non-L4S devices, I wonder in future 
how much hardship this would cause, especially if L4S were to be widely 
deployed.

> An operator testing L4S is likely able to find an environment where L4S doesn't create harm. A DSCP isn't required for such an experiment and if the operator desires to use one, standardization isn't a requirement, I guess.
True, if an operator really wanted to use a DSCP, they could use a 
private one. I think that operator would be better likely to decide to 
differentiate on the ECN codepoint.
>
> Regards,
>
> Ruediger

Thanks,

Gorry

> -----Ursprüngliche Nachricht-----
> Von: tsvwg <[e-mail]> Im Auftrag von Gorry Fairhurst
> Gesendet: Mittwoch, 24. März 2021 14:57
> An: Black, David <[e-mail]>; Pete Heist <[e-mail]>; [e-mail]
> Betreff: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>
> 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.
>
> 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
>