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

[Bob Briscoe <[e-mail]>]

Can someone explain for the record how using a DSCP as an L4S identifier 
would solve the CE ambiguity problem?



Bob

On 22/03/2021 19:30, 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.
>   
> Thanks, --David (as a TSVWG co-chair, but not claiming to speak for other co-chairs)
> [1] https://datatracker.ietf.org/doc/html/rfc4774#section-3
>
> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Pete Heist
> Sent: Monday, March 22, 2021 4:04 AM
> To: Livingood, Jason
> Cc: [e-mail]
> Subject: Re: [tsvwg] L4S drafts: Next Steps
>
>
> [EXTERNAL EMAIL]
>
> Hi Jason, one comment below...
>
> On Sat, 2021-03-20 at 15:08 +0000, Livingood, Jason wrote:
>>> The lab studies have shown
>> IMO the challenge with lab studies is that there are a lot of variables
>> that are artificial and/or the test environment or test traffic does
>> not fully reflect reality (production). 10 or 15 years ago I would have
>> been very focused on extensive QA testing and an elaborate lab test
>> environment. These days its more how to do controlled testing directly
>> in the production network, with a controlled/minimized blast radius in
>> case of problems, easy/quick rollback, rapid code/config iteration.
>>
>>> far from a promising system that might be ready for a field trial,
>>> one that shows worrying failure modes that primarily affect innocent
>>> bystanders.
>>>   What we're asking for is a system that at least behaves reasonably
>>> under lab conditions, chosen to represent realistic challenge
>>> scenarios likely to occur in the real world.  Only then can we have
>>> any confidence that L4S will not cause problems anywhere and
>>> everywhere that it is deployed.
>> Only one way to find out - test it in a real production experiment with
>> appropriate risk controls.
> 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.
> Here are a few: https://github.com/heistp/l4s-tests/
>
> It would be nice if someone took the time to set up some production
> gear with fq_codel built into it, like routers and/or WiFi access
> points, and test various kinds of real-world traffic, through tunnels
> and not. One could combine traffic to L4S servers within the
> experimental network, along with conventional traffic to anywhere on
> the Internet. That seems like a useful step before starting an
> Internet-wide experiment. Perhaps even better would be to fix what
> safety issues are known so that they can't occur in the first place.
>
> Regards,
> Pete
>
>>   The status quo seems to suggest years more debate without (IMO)
>> sufficient data. An alternative is a controlled production experiment,
>> appropriately risk-managed, between willing participants. I see no
>> downside to allowing that to occur via experimental RFC. We're setting
>> the bar at the proposed standard or standard level, which I think is
>> incorrect. I would say instead enable the experiment to accelerate the
>> learning & improvement & drive data-driven decisions.
>>
>> Jason
>>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/