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

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,


> On Mar 28, 2021, at 21:01, Ingemar Johansson S <[e-mail]> wrote:
> 
> 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.

	[SM] Getting an experiment with known negative side-effects grated by the IETF does not hinge upon "ease of use" or convenience to the experimenter. If you have a better proposal how to secure/contain L4S for the duration of the experiment, I am all ears. Just not bothering for the safety of the existing internet however, is IMHO not an option, sorry.


> 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.  

	[SM] Or about the lack of fore-sight in those that think deploying existing L4S without any safe guards onto the existing internet. I have a pretty clear prediction about how the L4S experiment is going to proceed unless properly contained, and I want to save us all unnecessary hassle to post-hoc explain how this WG could allow such unfinished engineering to be released upon the rest of the internet... I am a bit puzzled, that after all the data that clearly shows L4S already failing hard in the lab, you consider an "experimental" deployment without any safety mechanisms as advisable...

> 
>> 
>> 
>>> 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. 

	[SM] Yes, are you willing to put a number on that, and more importantly, are you willing to hold the L4S experiment until that point? I do not consider that to be a proposal that is on the table, not from you, not from the rest of team L4S, nor the wider WG. So let's please come back to the concrete proposal how to get your experiment started, okay?


> 
>> 	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. 

	[SM] Nobody is stopping you from sending patches e.g. to the Linux kernel mailing list, so if you consider this to be an important point, you now the address to send your patches to. The power to resolve that catch22 is in your hand, which is to say, it is not a catch 22 situation at all.

> 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.

	[SM] Ironically, this argument comes as response to a concrete proposal how to get the L4S experiment air-borne. Maybe you re-rad my proposal and come back to the discussion without the assumption I would be out to get you/L4S? This is about how to contain the predicted fall-out of the experiment to those parties that have accepted that fall-out might happen and (hopefully) are prepared to clean up if something goes wrong. You know, really just standard cautious engineering practices.

@chairs, what am I to make out of the fact, that none of the L4S proponents seems to find the time to actually read my modest sketch of a proposal and discuss it on its merits?
Against my better judgment about the quality and readiness of L4S, I am trying hard to build a bridge, and all I receive in return is gross generalizations...


Best Regards
	Sebastian


> 
>> 
>> 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