Re: [tsvwg] Update to Position Statement on ECT(1)

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

Hi Jake, tsvwg,

If we're thinking of alternate encodings, it seems to me that there are three theoretically possible:

A) Jake's encoding: ECT(0) as 1/p, CE as RFC3168
 Advantages and disadvantages as mentioned already.


B) As A), but with ECT(0) and CE switched.
This retains the classification properties of L4S (both 1/p marked and unmarked packets classify as low latency) but doesn't resolve the ambiguity of CE versus RFC3168, and therefore doesn't obviously provide a benefit.

C) ECT(1) as 1/p, CE as RFC3168

Without a classifier, this has the problems with tunnels etc that people have mentioned.

However it occurs to me that the ECT(1) (and CE) could still be used as a classifier in the following way:
Have the Prague sender premark 50% of packets with CE, in an order known to the receiver (eg, alternating).
The L4S AQM and the RFC3168 would then only be able to mark different packets, so  the receiver can then determine with good confidence whether any CE marked packet was 'originally' ECT(1), and if so, it must have been marked by a RFC3168 
AQM. (At this point the sender should revert to RFC3168 and stop sending premarked CE packets).

This has the advantage of over A) that the classification signal is not lost after the first bottleneck. However it has the same problem with tunnels, and I can see some additional issues:

 Both the RFC3168 and L4S congestion signals would be degraded.  For RFC3168 this degradation would be only until the RFC3168 AQM was detected, which under conditions of congestion should be with a well defined probability per RTT. It is not obvious how much a 50% loss of bandwidth for the 1/p signal would weaken the latency 

Middleboxes which rewrite tcp (eg, by changing packet boundaries) would cause problems. Work would be required to check that they can be detected reliably.

Although the classification would be preserved across L4S AQMs, conditions of an L4S AQM followed by an RFC3168 AQM (or vice versa) could cause some congestion marks to be "undone". However this could only occur until the RFC3168 AQM was detected. IT woudl not be caused my multiple AQMS of the same type.

CE has up till now been a fixed point (no transitions away from CE) so there may be other network elements which are surprised by transitions away from it.

Anyway, hope that is of interest.

(I will not be taking a  position on the consensus call, as I do not currently work in networking and don't have time to do the necessary due diligence).

Alex





On Friday, May 8, 2020, 8:51:26 PM GMT+1, Holland, Jake <jholland=[e-mail]> wrote: 

Hi tsvwg,

As promised in my original position statement[1], if I substantially changed
my views on the ECT(1) question I would post an update.

It has come to my attention that a technical fix is possible for my safety
concerns with "ECT(1) as an input" by changing the signaling scheme.

Although I still stand by all my claims in the original position statement,
the existence of a safe signaling scheme that uses ECT(1) as a network input
has changed my conclusion on the input/output question.

New position:
- I slightly prefer ECT(1) as an input (with qualifiers, given below)

(Note that this position should not be taken as an endorsement of L4S's
safety as currently proposed.)

The new signaling scheme that drove my change of position is this:

- ECT(1) is set from sender after negotiating endpoint support
- On-path devices change ECT(1)->ECT(0) to signal low levels of congestion
- On-path devices continue to use CE, as in RFC3168, to signal high levels
  of congestion, resulting in a required multiplicative decrease response.

Under this scheme, for any path with a single AQM that's dualq, ECT(1)
remains a very good classifier for that AQM.  Since this covers most
relevant paths that aren't within a controlled environment like datacenters,
it has a low downside.

Under this scheme, ECT(0) becomes the 1/p signal for dualq+TCP Prague, and
CE becomes the 1/sqrt(p) signal from the classic queue if the LL queue
overflows, and results in multiplicative decrease from the sender.

This would make L4S compatible with RFC 3168 without relying on a fragile
classic queue detection algorithm, so it would address my safety concerns.

As with all available signaling schemes, I acknowledge that this approach
is not perfect, and comes with tradeoffs.  A few of the known tradeoffs
would include (with thanks to Bob, Koen, and Kyle for explaining some of
these to me offline):
- existing tunneling decapsulation specs would often lose non-CE signals
- the existing accecn spec would often lose non-CE signals
- For paths with multiple AQMs, the classifier partially loses integrity in
  later AQMs when earlier AQMs are loaded.  (Note also the worse downside
  that increasing deployment of new AQMs potentially reduces the fidelity
  further.)

In spite of the downside from these tradeoffs (and the work that would be
necessary to fix the specs and their deployment to capture the most value
from L4S), a signaling scheme with the backward compatibility that this
approach provides is what would make the key difference between a safely
deployable L4S and not, IMO.

As I said, I still stand by my previous claims.  In particular, I still
believe that DSCP is a reasonable and appropriate classifier for L4S
traffic at this stage of its maturity.

However, I also acknowledge that there's value in getting a quicker wide
deployment, as long as it can be done safely.  Since I believe ECT(1) with
the above signaling scheme can do so, I now think it's as reasonable a
choice as DSCP, but carries substantial benefits.

Since this approach would give almost the same benefits as "ECT(1) as
output", and also provides a classifier that can serve dualq's needs well
in most of the deployment scenarios, "ECT(1) as input" is my current
preference, because of my new belief that it can be made compatible
with RFC 3168 queues and still mostly get the classification job done.

I remain opposed to moving L4S forward in a way that's not compatible with
RFC 3168 queues, as it's currently proposed.

I also remain skeptical that it's possible to get the classic queue
detection working robustly, I think that's probably a dead end. And I
have become more skeptical of the viability of the queue protection
mechanisms mentioned, because those seem to require access to the layer 4
packet contents, which has been flagged as too hard to be practical.

So I remain skeptical of the safety stories told so far for the current
L4S proposal, because it has no MD fallback signal except loss or detection.

Best,
Jake

PS: I also have some mostly-supportive comments on Kyle's remarks about
the input/output question that might be relevant.  Thread is here and should
soon get a new message:
https://mailarchive.ietf.org/arch/msg/tsvwg/VhgCiE9dF6F2Z-eN9wkpeVG2LX0/

[1] Jake's original position on ECT(1):
https://mailarchive.ietf.org/arch/msg/tsvwg/Zrk7Up6g9BwfnJLjKD44K0riAg4/