[tsvwg] Options for improving L4S safety

["[e-mail]" <[e-mail]>]

If we're now discussing ways to make L4S more safe, it seems to me that it might be useful to attempt to enumerate all the
possibilities. I think there are a few that have not been previously mentioned; most have difficulties, but perhaps some of the experts here can a way forward:


1) As frequently mentioned, if L4S marks were distinguishable from RFC3168 marks, L4S endpoints would be able to react more appropriately. 
Since the group is now persuing ECT(1) as network input, this approach is currently without an codepoint, although there has been some speculation that DSCP could be used as an output. This is sufficient for safety, but perhaps it is not necessary. However the 'safe by construction' 
attributes are obviously attractive. 

2) RFC3168 detection, as proposed by Bob's working paper. The immediate difficulty seems to be in defining a set of test cases sufficient to convince the group.

3) Change DUALQ such that marks from a DUALQ can be more easily distinguished from RFC3168 marks.
I raise this as a possibility in order to see if any aspect of "safe by construction" can be incorporated into the RFC3168 detection scheme.
I can see two possibilities:
 a) DUALQ to never mark certain packets, comprising a known,  substantial % of packets.
 b) DUALQ redefined to always mark consecutive packets from a flow

Both of these have their difficulties. 

In case a), if a CE were observed on one of the forbidden packets, then it could be assumed to be RFC3168 and fallback should occur. If the % of forbidden packets were known, and these are independent RFC31680 CE marking, then the statistics of when fallback should occur will only be determined by the rate of RFC3168 CE marking. I think this would get us a lot closer to 'safe by construction', as we can decide if the tail distribution of fallback time looks okay. It would be necessary to see how much this degrades the L4S congestion signal.

In case b), if a lone CE were observed then it would be clear an RFC3168 AQM was present, and fallback would occur. The statistics of this are more complicated because they depend on the rate of DUALQ marking as well as RFC3168 marking, since the proportion of RFC3168 marks masked by L4S marks is less obvious. It would be more obvious if DUALQ marking were capped at 50 or 75% instead of 100%. I don't know 
how that would affect the L4S goals.

Both of these have the advantage that the mechanism for detecting RFC3168 AQMs is simple and predictable. Unfortunately there are other obstacles. 

In the case of a), it would seem to require some codepoint that could be used as another input to the IP layer, to inform DUALQ which packets are forbidden. If those were easy to find, we wouldn't be having this whole discussion. So we are left looking for one that, for some reason, couldn't be used for the L4S  ID, but could be used here. There are a few options, with various difficulties:

i) In previous work, it's been proposed to use an IPv6 destopt as a network input (rfc7837). I'm not sure if that was ever deployed, and obviously it only works for ipv6.
ii) The LSB of TTL. The sender could modulate the LSB of TTL. Although the actual value would not be be visible at the AQM, it's probably had some constant subtracted from it. So if the AQM refrains from marking when TTL.0==1, the receiver could work out fairly swiftly whether the constant offset was odd or even. However, this would not work inside tunnels as the inner TTL is not propagated to the outer on encapsulation
iii) The LSB of payload length (or, the 3rd LSB of payload length). This has the distinct disadvantage that modulating payload length might not be possible just in the TCP implementation, but also involve the application layer. The 3rd LSB could be modulated by adding TCP options, but those might be intefered with by middleboxes. 

The difficulty of b) is more obvious - it requires DUALQ to be flow aware, even more so that FQ, since binning would not be sufficient. It wouldn't need to keep the flow state very long (just long enough to mark the next packet) but I would guess this is still too much.

The open question here is whether there is any such modification of DUALQ that doesn't have the above difficulties.
There might be ways to modify the statistics of DUALQ marks to make them more distinguishable  from RFC3168 marks, without requiring either another input or FQ.  This brings me to:

c) We could change the marking function to in introduce a discontinuity, so that the L queue never adopts a marking rate between 0% and (say) 20%. (It would still be linear between 20% and 100%).  There would still need to be a region when 0% marks occur. This is a bit odd, but it still makes good use of the available bandwidth of ECN, and conveys the same signal, so I guess it should still be scalable. With such a modification, if a lone CE mark was observed on a flow, it would be highly likely that it came from an RFC3168 AQM. However it's much less obvious (to me at least) how to write down P(RFC3168 is present | marks seen), and even less obvious what the statistics of fallback time would be  (since it would depend on how much time the DUALQ spent in the 0% marking region), although I suspect it would be a lot better than in 2). The DUALQ linkage, along with prague, would need adaption. It may prove complicated around the discontinuity region. Nevertheless this seems most in line with the spirit of the L4S design. The other issue is whether it is possible to build up a queue in both an DUALQ AQM and an RFC3168 AQM at the same time on the same path. If this was a significant possibility, the DUALQ marks at the >20% regime would would obscure the RFC3168 marks. But this state of affairs would need to persist otherwise fallback would occur when only the RFC3168 AQM was the bottlebeck.

Obviously, modifying DUALQ would be an annoyance to vendors who have already implemented it in silicon, but perhaps less of one than other options...

4) Modifying networks containing RFC3168 AQMs

Obviously this category has the disadvantage that operators not deploying L4S need to take action, but David has indicated that it may be acceptable.

Here we have
 a) Bleaching ECT(1)
 b) Modifying RFC3168 AQMs to be aware of ECT(1)

a) Has the problem that it will cause deployment problems for this and any other use of ECT(1), but has the advantage that it requires an operator to act only on the perimeter of their network
b) Requires an operator to inspect and possibly modify  every device  on their network.


Probably here it would be necessary to have a suite of options depending on what RFC3168 AQMs the operator thinks they might have, eg
c) if you know you have no RFC3168 AQMs, no action required

One option which occurs to me is to 
d) provide operators a way to signal that their network doesn't yet support L4S. What's not obvious to me is:
 i) since that requires tcp prague and all other L4S transport implementations to adhere to it, will operators trust it? Possibly they would up to the point that some transport implementation implements it incorrectly.
 ii) what's a suitable way of probing for support?

Alex