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

[Sebastian Moeller <[e-mail]>]

Hi Bob,



> On Mar 29, 2021, at 02:12, Bob Briscoe <[e-mail]> wrote:
> 
> Jonathan,
> 
> I was trying to tease apart the merits of the L4S + DSCP approach for a /single/ network that you were proposing. So I'd like to go back to before the point where Koen sent the thread off in a different direction (to do with the merits of a DSCP for end-to-end signalling).
> 
> Although David started this thread, I don't think he had a detailed proposal. And I think Sebastian's  proposal is slightly different from yours (using the DSCP as a classifier at an L4S AQM, which I think is unnecessarily restrictive).

	[SM] Again I note, that my sketch does not seem to have been read... and still there is time for an unqualified side remark... I am still open to a discussion, please engage.


> I'd like to take one step at a time and focus on your approach first. Inline tagged [BB]...

	[SM] Conceptually, if you manage  to "shoot" down Jonathan's more detailed and comprehensive proposal, you still need to tackle mine because of its much smaller and more targeted scope... I gues your time your decision with what to engage...

> 
> 
> On 25/03/2021 16:58, Jonathan Morton wrote:
>>>>> Can someone explain for the record how using a DSCP as an L4S identifier would solve the CE ambiguity problem?
>>>> It doesn't.  It only allows containing the resulting harm to participating networks, thereby protecting (most) innocent bystanders.  It's enough, I think, to conduct a field experiment to discover just how bad the problem really is in practice.
>>>> 
>>>> This is predicated on the notion that the L4S-ID DSCP(s) are bleached or dropped at the participating networks' border, and in the case of border bleaching, that L4S endpoints interpret CE marks *not* carrying the L4S-ID DSCP as per RFC-3168 or RFC-8511.
>>> [BB] it depends on a string of leaps of faith (LoFs).
>>> Specifically:
>>> 
>>> LoF (1) The receiver somehow feeds back the arriving DSCP to the sender, which would require new IETF work in QUIC, TCPM, RTCP, etc. The only use-case to justify DSCP feedback would be to make this L4S-ID DSCP idea work. And this work hasn't started anywhere yet. That's not just a leap of faith. It's a leap into the abyss.
>> Are you arguing here that the current L4S design is so thoroughly baked into existing standardisation work and/or implementations that not even minor changes can be made?  It sounds very much like it to me, and that is very troubling for the prospect of making L4S safe to deploy beyond an Option 1 (completely isolated) context.
>> 
>> In any case, I have already shown you a way to feed back the presence or absence of a particular DSCP.  Simply refrain from emitting the special DSCP, except on the initial SYN, unless you received the appropriate special DSCP on all valid packets received on the connection.  That gives you a very easy way to switch the connection into "Classic mode" if it strays outside the approved path.
> 
> [BB] 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.

	[SM] I begin to think that adopting L4S ID's without accompanying protocol IDs might not have been the most productive ad efficient move.

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

	[SM] I beg to differ, L4S protocols like TCP Prague require specific feed-back from the receiver, so a TCP sender for example is not free to use TCP Prague on a half link unless the receiver agreed to it, that seems different from other TCP CCs. Sure the reverse path is not technically forced to use TCP Prague, but that seems academic. 
	Or let me ask, are you really proposing end-points should only negotiate L4S signaling in uni-directionally, and which direction would you recommend? I smell a stawman...

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

	[SM] Pardon? For the only existing L4S protocol TCP Prague to work both sides are expected to negotiate AccECN, with TCP Prague being the only existing consumer of AccECN as far as I can tell (with a very weak definition of existence)...


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

	[SM] Yes, because normally this is not required, but an AQM normally does not check whether a packet carries ECT(0) or ECT(1) when deciding between setting CE or drop either, so why is a change on the end-host side unacceptable, given that you need a new protocol anyway, since mo existing protocol fulfills the L4S protocol requirements (this very much includes the "best" of the lot, TCP Prague).


> b) This currently would only be useful to make the L4S DSCP scheme work.

	[SM] Again, so is differentiating between EXT(0) and ECT(1) at the AQM level.


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

	[SM] How about to negotiate that with the affected WGs first instead of jumping to conclusions, just because these conclusions are convenient for you? Sidenote, the same argument can be made about using ECT(1) as "classifier", both the ECN bits and the DSCP bits sit in the same layer and in both cases we expect the protocol layer to interact with them in some fashion.

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

	[SM] No, both ends need to cooperate for an L4S CC (by virtue of the AccECN requirement and the other protocol requirements), but there is no need for them to use the Prague CC in both directions. But the fact that cooperation is needed will allow to introduce the DSCP based additional layers.


> d) This also means that a scalable CC cannot be tested with a Classic CC in the reverse direction.

	[SM] Well then, I am sure we could relax Jonathan's proposal to split out the two directions. But I severely doubt that L4S is going to be all that helpful unless both the forward and reverse ACK traffic are handled by L4S AQM, otherwise the reverse path jitter is going to pretty much destroy the jitter reduction that L4S in the forward path delivered... unless one naively assumed an uncongested reverse path.

> e) Requiring a 2-ended deployment greatly reduces the chances that any flow will use L4S.

	[SM] Bt you do that already, with TCP Prague, sorry. And you absolutely NEED to, you are trying to establish a new communication signal, so you need to coordinate all three: sender, receiver and signal (path). This not a logical argument to make, especially not in the context of an experiment.


> 
> Let's say there are 10 million hosts on a network participating in the L4S experiment. Even once 10,000 hosts deploy L4S with your DSCP scheme, they will still find 9.99M hosts without L4S support.

	[SM] If the L$S requirements include the DSCP as mandatiry element, these 10 million end-hosts will naturally acquire the necessary capability when they enter the experiment. This is also why it is essential to bake this into the design and implementation BEFORE beginning wide-scale deployment.
	You are already facing exactly that situation by the way, by virtue of only having a fig-leaf protocol in TCP Prague...


> In your scheme, both ends have to support L4S, which is a probability of 1 in a million (1 in 1000 squared) that any particular flow will support L4S. That makes the deployment incentives awful. And it's not such a great experiment either with so little L4S traffic.

	[SM] Sorry, again, since protocols need to take active steps to gain L4S compliance already, this is not a changed when an additional DSCP component gets added to the signaling mechanism.... 

> 
> Because AccECN for TCP is still being held back, we will anyway have this 2-ended deployment problem over TCP. But we don't want to unnecessarily create a 2-ended deployment over the other transports (QUIC, RTCP, etc).

	[SM] Convenience should not trump safety, but that is effectually what Koen and you are bringing as argument. In all honesty, if the interest in L4S will not survive the addition of a DSCP layer to make the design save, then I would humbly propose that the interest in L4S was not sincere enough to begin with. 

> 
>>> 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.
> 
> [BB] 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. Specifically:

	[SM] Easy, during the experiment a participating network AS agreed to bleach the L4S DSCP at its diffserv boundaries, unless the other side agreed by SLA/TCA/verbal contract/whatever to knowingly accept that DSCP and follow the L4S requirements. This very much includes the end-points. Endpoint need to opt in as well, but they need to do this more or less already, since they would need to deploy L4S capable/compliant protocols to participate in the testing to begin with. My spider-sense how ever tells me, that you very much plan to enroll end-points into the experiment without first asking for consent....
	Could you please elaborate on L4S' official position on this, are end points expected to participate willingly and by active opt-in, ior are you envisioning end-point getting volunteered, say by their ISP without active consent?


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

	[SM] Easy, it end points need to actively opt-in to the L4S experiment, an ISP supplying end customers could easily interpret the combination of the L4S-DSCP and ECT(1) (if that is still part of the proposal) as implicit decision for requesting L4S treatment if possible. But that place, ISP <-> enduser is special in that regards, for boundaries between commercial entities, like CDNs something like an SLA/TCA should e required (as these exist at hese boundaries anyway, unlike at the end-user <-> ISP boundary).

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

	[SM] Same argument, if the ISP it self participates in the experiment it might simply pass the DSCP to the end customer, as there still needs to be a protocol at the receiving end to actually turn that DSCP into an L4S signal (in communication it matters how a reciver interprets a message). Or the ISP could allow endusers to toggle their L4S preference in the on-line customer center that many ISPs already seem to use for other self-serv customization.

> 
> Please don't answer this here. Instead, please address the specific examples below (a/b/c), to keep the discussion concrete

	[SM] Why? These conceptual issues could be answered on the same conceptual level (see my response 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.
> 
> [BB] It is good practice to read someone else's email right through before you start answering it.
> Here, you are telling me what I told you further down this email, but without responding to the follow-on point I made about this (find "l4sops" below).
> 
>> 
>> 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.
>> 
>>> LoF (3) That's before we get to all the other reasons for why using two fields (ECN and Diffserv) as a classifier would rarely work for those who /do/ want to use L4S (in Appx B.4 of ecn-l4s-id already pointed to on this thread).
>> I do not accept Appendix B.4 to be a valid set of arguments against using DSCP for this purpose.  If nothing else, it does not appear to consider any form of the two-DSCP scheme I recently described.  I would encourage you to give it a serious, principled consideration.
> 
> [BB] I am trying to first understand the single DSCP approach you appear to be describing here. But I will not be able to understand you if you don't explain how your approach will work in the examples I give at a/b/c below.
> 
> And no-one is going to write your idea into a working group draft unless you individually address each of the criticisms of DSCP-based schemes in Appx B.4.

	[SM] Bob the issue with B.4 is it contains gems like"
"Not end-to-end (host-network):  Very few networks honour a DSCP set
      by a host.  Typically a network will zero (bleach) the Diffserv
      field from all hosts.  DSCP bleaching would turn an L4S ECN packet
      into a Classic ECN packet."

And one part of the DSCP proposals is to explicitly restrict accidental E2E transmission of L4S signals unless the full network path considered itself L4S aware... In other words B.4 is explicitly written from the perspective of the taken decision, to post-hoc make this seem like the only viable choice.


> You cannot seriously expect to be granted a free pass to ignore all the problems with DSCPs by simply pronouncing that every one of the arguments is invalid.

	[SM] True any DCSP proposal should be measured in how it achieves its explicit goals. The same is true for all RFC/ID including the L4S drafts, where, to repeat my self, there still are considerable differences between what is promised in the UIDs and what is actually delivered as seen in actual test data.


> 
> Now, please address the a/b/c points below.
> 
>> 
>>> Now let's see how realistic LoF (2) is by putting this DSCP idea to the test - by hiding these needles in each type of haystack:
>>> 
>>> a). Upstream:
>>> Imagine a FIFO RFC3168 AQM in the queue of a home router in the upstream direction. An L4S client sends L4S packets through this AQM, which marks some as CE. Then the network participating in the L4S experiment delivers them, with the L4S-ID DSCP intact, to an on-net server. But the CE markings were RFC3168 not L4S.

	[SM] In that case the end-user is expected either to disable the rfc3168 component of that AQM and opt-into using L4S, or to make the opposite decision. Once you embrace informed consent and active opt-in, such issues simply disappear. If however you think you know better than the end-user and decide to set policy for their network by force, the onus is on you to make sure that observable behaviour does not regress. The fact that you consider this situation a potential problem at all ring all sorts of alarm bells on my side, but at least is consistent with the overall approach of L4S towards risk management (which I do not endorse).


>>> 
>>> b) Downstream:
>>> Consider an RFC3168 AQM in the network of a corporate site or campus network receiving traffic from a connected L4S-participating network. Or perhaps on the access into a data centre connected to the participating L4S network. Same problem; the DSCP says its L4S, but the CE was RFC3168.

	[SM] Nope, by admitting the L4S DSCP and passing it on, the network essentially will have declared that it will deal with the consequences/fall-out of L4S signaling. Again active opt-in trumps accidental interoperability questions any day. Active consent will not automatically fix all interoperability questions, but it will make sure that involved parties are conscious of the fact and places the responsibility explicitly at that place/entity that can actually take active measures to contain potential issues. One solution could be simply, assure no rfc3168 is still in use (or have those simply treat ECT(1) like NotECT), the L4S-ops draft contains a few of those issues, and anybody opting in ot the L4S experuiment can be well expected to read that ID, no?


>>> 
>>> c) Within:
>>> Consider an RFC3168 AQM within the network participating in the L4S experiment. Same problem. The participating network delivers the packet with the L4S-ID DSCP intact, but the CE marking is RFC3168, not L4S.

	[SM] Nope, the onus is on the participating network to either not let this happen, or deal with its consequences any way it sees fit.


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

	[SM] But an L4S flow traversing a non-paticipating network that employs an rfc3168 might well interpret CE without DSCP as classoc ECN signal and respond appropriately, which should be better than a interpreting as a drop (think ABE).


>> 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.
> 
> [BB] 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.

	[SM] Yes, but for 6 years you did not manage to find a solution for the rfc3168 conundrum, which indicates that the trade-of agreed on 2015 simply is not viable either. So maybe another trade-of needs to be found, preferably one that does not trade in others' safety for L4S' convenience?

> 
> Here, we are putting your idea for using a DSCP to the test.

	[SM] Well, really you are trying hard to tear this down, I see exactly zero attempts to propose what Jonathan's proposal would need in addition to make it operationally equivalet to what you have converged upon...


> 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.
> 
> 
>>>> I refer you also to my recent post titled "L4S, DSCP, and RFC-4774 Option 2" in which I give a more detailed explanation of a two-DSCP proposal.  The short version is that a version of L4S using that scheme would have *some* positive confidence whether or not they were receiving L4S or conventional marking, without the need for heuristic probing or monitoring.
>>> This requires the same 3 leaps of faith as above.
>> No, it does not.  I encourage you to re-read that and carefully absorb my explanation of how it works.  I think you will find the exercise very enlightening.
> 
> [BB] Let's stick to one scheme at a time for now.

	[SM] Yes, preferably my much more restricted and targeted proposal, please. You get to do your experiment quicker, and we get the failure result quicjer and the whole thing can bu forgotten earlier.

QUESTION: has anybody discussed the current design with its massively increase in RTT bias with T1-ISPs that mainly deal in long-range transit? I might be wortwile getting ther opinion, on whether we should prioritize even more bandwidth for short range connections than TCP in FIFOs already does? (I will put this into ne thread as well, down here it will just be ignored).

Best Regards
	Sebastian


> 
> 
> 
> Bob
> 
> 
>> 
>>  - Jonathan Morton
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>