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

[Jonathan Morton <[e-mail]>]

> On 29 Mar, 2021, at 3:12 am, Bob Briscoe <[e-mail]> wrote:

> There is no L4S design 'baked in' to existing standardization work. L4S is on the experimental track, and designed to build /on/ ECN feedback in existing standards track IETF transport protocols. Specifically QUIC, RTCP and TCP.

Well, in that case it should still be feasible to improve L4S' design and implementation before deployment.  Of course, the longer you spend resisting any and all efforts to suggest such improvements, the narrower that window of opportunity gets before the whole WG just gives up in disgust and refuses to publish.

> An L4S congestion control acts at the sender in one direction. The other direction might use a completely different congestion control. This is outlined in l4s-arch, but it's no different from the architecture of any CC. For instance, if Cubic is acting in one direction, you can have Vegas or BBR or whatever in the other.

That is indeed a case that would be problematic for the two-DSCP scheme as I presented it.  I think you could salvage it by adding explicit feedback of the relevant information to AccECN.  Or, for the purposes of the experiment, require that L4S signalling be used in both directions or not at all.  Or - and this is my preferred option - switch to a non-ambiguous signalling scheme where these complications are far less necessary.  Your choice.

Using a single DSCP would be adequate for preventing L4S traffic originating within the participating network from escaping it, provided the appropriate filtering is actually implemented at the network border.  It would prevent, for example, L4S endpoints in two *different* participating networks from accidentally making an L4S connection over the non-participating path between those networks.  But it would not prevent L4S endpoints from being set up outside the participating network entirely and communicating with each other over unprepared networks.  It does have the virtue of being very easy to set up.

> You are proposing that, in a connection between host X and host Y, if X sends using a scalable CC, it has to set both ECT(1) and a defined L4S DSCP. Then when peer Y sends, it has to set the same DSCP on the packets it sends to X. There are a number of problems with this:
> a) There is no reason or need for peer Y to know anything about L4S.

If a host is participating in an L4S-TCP transport connection then *of course* it needs to know about L4S, if nothing else to be able to provide the correct feedback.  Maybe that is different for QUIC et al.

> So how does it know to set this DSCP? A host doesn't normally even check what the incoming DSCP is.

Not reflecting the DSCP as required by the experimental protocol would indicate that it's not participating in the experiment.  That should be a strong indicator to the sender that it must switch out of L4S mode immediately.

> b) This currently would only be useful to make the L4S DSCP scheme work. So it would seem unlikely to be adopted in any of the busy WGs working on these transport protocols. Particularly given it's unorthodox architecture (overloading a L3 protocol with an additional L4 meaning)

Protecting an "alternate ECN" scheme with a DSCP is explicitly called out as a possibility in published RFCs.  The fact that is hasn't actually been done before should not be a barrier in itself.

> c) You seem to be assuming (or perhaps requiring) that the peer at one end of a connection can only use a scalable CC if the other peer also uses a scalable CC.
> d) This also means that a scalable CC cannot be tested with a Classic CC in the reverse direction.
> e) Requiring a 2-ended deployment greatly reduces the chances that any flow will use L4S.

That last one is not an argument.  We explicitly *want* to limit use of L4S signalling to connections where both endpoints know what's going on.

>>> LoF (2) There are no FIFO RFC3168 AQMs a) upstream of the participating network, b) downstream of it, or c) within it (see details below).

>> Incorrect.  Remember that when using a DSCP as a containment mechanism, it is assumed (as I spelled out previously) that the borders of the network at least bleach that DSCP, and may even block traffic carrying it.  That's how containment works.  So if the L4S traffic crosses a border of the participating network, it automatically switches to Classic mode and there is no more problem with RFC-3168 AQMs on any part of the path.
> 
> The a/b/c examples I gave (still below) solely involved /customers/ attaching to a single ISP participating in the L4S experiment. If an L4S network bleaches at the border where its own customers attach, how can any L4S traffic ever enter or leave the network? I'm not understanding you.

Obviously.

In your scenario, the customers are clearly within the participating network as defined by the border at which filtering of the DSCPs occurs.  Which means that any RFC-3168 equipment those customers happen to use, and the consequent effects, are automatically part of the experiment.

I hope you have plans to inform and educate those customers of what ill effects are possible, how to opt out of the experiment to avoid any possible ill effects, and how to inform relevant people about ill effects they might observe in practice during the experiment.

> Specifically:
> * at the first IP hop controlled by the L4S network, if it bleaches the L4S DSCP from attached L4S sending customers, how does any L4S traffic ever enter the network?
> * at the last IP hop controlled by the L4S network, if it bleaches the L4S DSCP before forwarding to attached customers, how does any host ever receive L4S traffic?
> 
> Please don't answer this here. Instead, please address the specific examples below (a/b/c), to keep the discussion concrete.

Please don't deliberately misunderstand me for the sake of argumentation.  Instead please re-read points 1 and 2 below from my earlier reply, in light of the brief clarification above.

>> Which leaves open two scenarios where an RFC-3168 could be encountered without crossing a border:
>> 
>> 1: Within the participating network.  But all RFC-3168 AQMs are supposed to have been removed from such a network before L4S was deployed on it.  So either the onus is on the network operator (who is at least an "interested observer") to deal with the problem, *or* the RFC-3168 AQM is present specifically for the purpose of experimentation, eg. to find out how the combination with L4S traffic really works in the real world.
> 
>> 2: The path runs entirely outside the participating network.  This implies that two communicating L4S endpoints were deployed outside the experimental network, which would violate the spirit of the experimental deployment and should not be allowed.  The two-DSCP scheme I outlined in my other post specifically attempts to detect and protect against this eventuality.

>>> In this last case, the L4S-paticipating network has to use techniques like those in l4sops to make sure any FIFO RFC3168 AQMs don't mark ECT(1). That's no different to if ECT(1) alone was the identifier.

>> Thank you for confirming that you understand that using ECT(1) alone as the identifier suffers from all of these problems.  That was a big sticking point over the past two years, and I'm glad we can now get past that.
> 
> We identified these potential problems before we brought L4S to the IETF, and at the very first ad hoc meeting about L4S (Prague Jul 2015), we proposed that this should be on the list of requirements that would need to be solved.

Okay, so why have you not solved it in the intervening time?

> Here, we are putting your idea for using a DSCP to the test. So please address the point about how an L4S-participating network still has to use the techniques in l4sops, whether it adds a DSCP or not.

My point is that l4s-ops as currently written doesn't solve the problem at hand.  I'm trying to suggest things that should go into either l4s-ops or the core design of L4S, in order to solve the problem.  I'm a problem solver, you see.

 - Jonathan Morton