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

[Jonathan Morton <[e-mail]>]

> On 25 Mar, 2021, at 7:54 pm, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> If using DiffServ is considered as a widely deployable technique on the internet, then we should simply use DiffServ as the "input" L4S identifier and use SCE as the congestion "output". I don't think we need more complex experimental schemes, especially if they end up needing a final DiffServ codepoint anyway even after the experiment (like in Jonathan's proposal).
> 
> As such it would be the perfect marriage of both L4S and SCE. So an AQM can only mark SCE if it has the DiffServ L4S-id and can protect and isolate the L4S-SCE flows from flows not responding to the SCE marks (in a DualQ or FQ, or any other scheme detecting presence of non-L4S flows).

That's certainly an interesting idea, and one that we have at least partly considered as part of developing SCE.

In the SCE context, DSCP would be used first as an experiment protection mechanism (if the WG decided that was necessary), and then as a way to handle some of SCE's relatively few failure modes that exist when deployed *without* a DSCP.  It would not be necessary to use DSCP as a containment mechanism, only an enabler.  Some details below.

> This was one of the options that was considered before and which would be the simplest solution involving DiffServ.
> 
> The question was and still is if DiffServ "is" the perfect wedding proposal for Internet wide traffic. How many more hurdles do we need for deploying scalable and smooth congestion control (which is I assume the common goal of both L4S and SCE).
> 
> Main question is: Is the risk (pushing away Classic flows on a RFC3168 ECN bottleneck after tens of seconds) worth the extra deployment obstacles (practically making its deployment as constrained as an end-to-end managed service).

First let me clear up a small point:  SCE's typical failure mode is the opposite to L4S's typical failure mode.  When the two inadvertently end up in the same queue and managed by the same AQM instance, L4S squashes the RFC-3168 traffic, but SCE would be the one that gets squashed by RFC-3168 in the same scenario (if and only if the AQM is SCE enabled).

This clearly changes the risk profile, since the risk is now to the involved participants in SCE, rather than to the innocent bystanders obeying existing specifications.  This makes the risk much easier to manage when it arises, and we can legitimately engage in exercises which reduce that risk (as a performance enhancement in specific scenarios) but don't eliminate it entirely - and there is actually some incentive to do so, because the risk is not externalised.

That is where the DSCP comes in.  Using the DSCP, the sender advertises that it understands SCE, while traffic not carrying the DSCP might not.  An SCE-aware middlebox can use that as extra information when distinguishing flows from each other, and thus avoid placing SCE traffic in the same queue as non-SCE traffic.  That's not the only strategy possible, but an illustrative one; we can discuss others later.

At a non-SCE middlebox, there is no need for it to understand or react to the DSCP.  SCE transports react to the CE marks that RFC-3168 AQMs produce in the same way as conventional traffic, so there is no incompatibility.  This also makes losing the DSCP en route relatively safe, even if an SCE-aware AQM is encountered subsequently.

> If the answer is yes, then we should define a DiffServ codepoint that identify L4S and only use SCE for those. If the risk is assumed minimal and comparable with other experimental CCs (see ICCRG https://datatracker.ietf.org/meeting/109/materials/slides-109-iccrg-the-great-internet-tcp-congestion-control-census-00) then we live with the (small?/controlled?) impact.
> 
> I understood the latter had the biggest support in the input/output vote during the previous interim. I think if L4S flows are not used for long time downloads (non-application-limited flows), the impact is minimal and a 3168 detection and fallback would never be needed. It also was known that Classic bottleneck detection would be a challenge, but I think Asad/Bob showed that a (maybe not 100% perfect, but already) very good implementation is possible if needed for the problem conditions that are known then. These could be used (experimented with) when using L4S for downloads.
> 
> So bottom-line question: Who believes an end-to-end DiffServ solution is realistically deployable???

It is well-known that DSCPs get altered in various ways across general Internet paths.  What matters here is whether losing the DSCP indicating L4S or SCE support is fail-safe.

In current L4S it is not fail-safe, because the receiver doesn't know (and can't tell the sender) what type of AQM applied the mark.  The DSCP schemes that Sebastian and I described are capable of being fail-safe if correctly implemented.

In SCE, it is inherently fail-safe since the receiver and sender both know what type of AQM applied the marks.

> Second sub question: who believes L4S is a bigger risk than all other CCs "experiments" on the Internet??

L4S in its current form has the same risk profile as DCTCP, which is explicitly classified as NOT suitable for deployment on the Internet, because it is so much more harmful to AIMD traffic than most of the other experiments out there.  With good DSCP protection, that could be improved to an RFC-4774 Option 2 standard, but I think not to Option 3.

I note that some other very aggressive TCPs that predated CUBIC are also not considered suitable for deployment (I suspect their RFCs have been retired, but haven't checked).  By contrast, most other congestion controls currently in development are either closely tied to datacentre technology and are thus naturally restricted to that environment, or are going to considerable lengths to compete reasonably with the status quo, especially CUBIC, or even to behave like low-priority scavengers.

 - Jonathan Morton