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

[Sebastian Moeller <[e-mail]>]

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?


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

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

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