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

[Ingemar Johansson S <[e-mail]>]

Hi Sebastian+Jonathan + others

See inline [IJ] 
/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: den 28 mars 2021 17:13
> To: Ingemar Johansson S <[e-mail]>
> Cc: Pete Heist <[e-mail]>; Kyle Rose <[e-mail]>; C. M.
> Heard <[e-mail]>; Jonathan Morton <[e-mail]>;
> De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-
> labs.com>; tsvwg IETF list <[e-mail]>
> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
> 
> Hi Ingemar,
> 
> 
> > On Mar 27, 2021, at 21:00, Ingemar Johansson S
> <[e-mail]> wrote:
> >
> > Hi Pete, Kyle, Charles, Sebastian, Jonathan CC others
> >
> > I have followed this discussion for a while now.
> > It is possible in a 5G system to set up traffic filters that include 5-tuples and
> DSCP + more, so what you propose is possible.
> 
> 	[SM] Excellent news, thanks for this information.
> 
> 
> > But with that said, I don’t at all see that this needs standardization and why
> this would be needed as part of the L4S work.
> 
> 	[SM] A guard DSCP would need to be unambiguously agreed on by all
> participants (or rather a PHB, different DSCPs could take that role). IMHO a
> standards document is exactly the place to lay down the "law" on how to do
> this. And in addition the L4S-ops ID/RFC should spell this out in detail to
> facilitate such an approach. I wonder how issues affecting interoperability
> between entities are regulated on the 3GPP world, but I naively assume that
> this is handled in standards documents, no?
[IJ] Like said before by others, if DSCP would have been this easy to use, then we would have had this discussion. Operators can use DSCP in L4S experiments but that of course requires that they see a specific benefit with this. So far I have not seen anybody except you fighting so hard for this and that should tell a little about the magnitude of the problem you are trying to solve.  

> 
> 
> > In addition, your  intended purpose with such an guard DSCP is quite likely
> to be met with confusion among 3GPP operators as there is no evidence of
> RFC3168 AQM in 5G systems.
> 
> 	[SM] Hmm, I am puzzled why you see it a problem to explain in detail
> to them what risk an unguarded L4S deployment will carry, but let me help
> you out here. As long as 3GPP operators can guarantee that L4S packets
> never ever leave their domain, they are already free to use what ever
> method they want, the do not need the IETF's blessing to use L4S. I assume
> however, that data packets carried over 3GPP member networks, might
> "occasionally" actually get sent to end-hosts outside of the operators
> network. It is that second case in which containment/informed consent
> becomes important. Why, because L4S traffic (as seen in TCP Prague)
> behaves considerably different under a number of conditions quite common
> on the existing internet, like:
> a) running rough-shod over other glows in shared rfc3168 queues,
> b) introducing a hitherto unseen level of RTT bias which will significantly
> change the sharing behaviour between short RTT (i.e. eyeball<->CDN) and
> longer RTT flows, with RTT distributions over the internet well within the
> range from single low double digits, to well above 100ms this is an important
> change that might require operator opt-in.
> c) introducing an inherent disadvantage for existing standards compliant
> traffic versus the new comer, which also might require operator opt-in.
> 
> Especially b) and c) seem like POLICY issues, that operator will likely not
> accept getting dictated from an RFC, but consider to be under their sole
> direction?
[IJ] See below about the use of the ECT(1) code point

> 
>  I guess you might direct confused operators to the tsv mailing list, where we
> can discuss such issues and patiently will explain the risk of the L4S
> experiment as well as possible mitigation strategies.
> 
> 
> >
> > I only see that this discussion goes at length to protect classic ECN enabled
> traffic in the possible cases where network nodes implement RFC3168 AQMs
> (or FQ-CoDel) and omits the fact that these are eventually either upgraded
> or replaced over time.
> 
> 	[SM] Well, if you are wiling to WAIT with the L4S experiment UNTIL
> these are upgraded and/or replaced that sounds like a viable plan... if
> however you want an earlier experiment, maybe come up with a counter-
> proposal for a mitigation strategy that will also allow willing parties to
> participate in the experiment without force-recruiting those parts of the
> internet into the experiment that have not opted in. I do not claim my sketch
> is complete or without challenges, or that it the best possible
> mitigation/containment strategy, but so far we only have two proposals on
> the table, and mine seems less ambitious (and I believe fixing L4S' issues for
> good, like in Jonathan's proposal would be better, I see no way forward,
> where L4S proponents will agree to that, fallacy of sunk cost and all)...
> 
> 
> > IANA already lists ECT(1) as intended for experimental purposes only so I
> would say that it is a bad idea long term to continue to claim ECT(1) for
> RFC3168 AQMs.
> 
> 	[SM] If the RFCs are changed that is a valid stance for the future, but
> will not help with legacy deployment, will it?  Then again, if you are willing to
> give notice now and wait for, say, a decade for deployments to change to the
> new mode, I see no issue with that. But then that would mean the L4S
> experiment would need to wait just as long (no objections from my side ;) ).
[IJ] Even legacy equipment is upgraded every once in a while or gets replaces because it gets too old or just breaks down. 

> 	To repeat, my proposal of using a guard DSCP only serves the
> purpose of allowing an L4S experiment in live production networks in the
> near future. If L4S aims for the long game with deployment in 10 years, we
> are probably better off with actually fixing its trouble spots for good ;)
[IJ] Collected answer to all the above. All I see is that this RFC3168 AQM is brought up repeatedly, when prompted about the possibility that even RFC3168 AQMs can be updated (the obvious first step is to make these follow https://www.iana.org/assignments/dscp-registry/dscp-registry.xml ) , it is only met with all kinds of arguments like we don't do this until L4S is deemed safe for deployment and we wont allow the experiment to happen until [TSVWG formally says whatever...], this is probably as close to a catch 22 situation that you can get in IETF. 
This is to me just smokes and mirrors with FUD as a main ingredient and it is getting harder and harder to keep  a serious discussion.

> 
> Best Regards
> 	Sebastian
> 
> 
> >
> > /I
> >
> > From: tsvwg <[e-mail]> On Behalf Of Pete Heist
> > Sent: den 27 mars 2021 14:33
> > To: tsvwg IETF list <[e-mail]>
> > Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
> >
> > ...
> >
> > On Fri, 2021-03-26 at 08:54 -0400, Kyle Rose wrote:
> > On Fri, Mar 26, 2021, 8:30 AM De Schepper, Koen (Nokia - BE/Antwerp)
> <[e-mail]> wrote:
> > I understood the goal of your proposal. But before diving into the details of
> a DiffServ-based proposals, I'm taking a step back asking: Is using DiffServ an
> option at all.
> >
> > Why wouldn't it be? The point of the proposal AIUI is to require networks
> to take action to explicitly opt-in to this experiment. Given the DiffServ
> bleaching that occurs by default at network boundaries, operators that take
> no action will not find themselves ambushed by novel behavior.
> >
> > I agree- the topic of this thread is the use of a guard DSCP for experiment.
> Sorry if I contributed to mixing in other possible uses early on.
> >
> > This approach allows for experimenting with ECT(1) as a classifier in a safe
> (contained, time-limited) way, thus allowing a path toward universal
> deployment (i.e., removing the DSCP guard) if the experiment is successful
> without requiring standardization and rollout of end-to-end DiffServ. And it
> does so (a) without permanently burning the ECT(1) code point if the
> experiment fails, and (b) in an opt-in manner that greatly reduces the
> potential for unintended side effects on classic traffic.
> >
> > This seems to me like the obvious path toward consensus on an
> experimental deployment aimed at gathering real-world experience without
> first committing to something unproven.
> >
> > Although an RFC isn't technically required to do this, it should still serve to
> codify how DSCP should be used and treated, and also to raise visibility as a
> sanctioned IETF experiment. After a successful experiment at "operator
> scope" (if that terminology captures it, but the larger the better), it should be
> easier to justify and start an experiment at Internet scope.
> >
> > I also think that with codepoint space this tight, it's not just about verifying
> safety, but also effectiveness. I feel the same way even for proposals that
> fall under RFC4774 Option 3 ("Friendly Coexistence with Competing Traffic").
> >
> > Pete
> >
> > Kyle