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

["C. M. Heard" <[e-mail]>]

On Fri, May 8, 2020 at 12:42 PM Holland, Jake wrote:

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

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

Thank you for presenting this idea. If the details can be worked out it
looks very promising.


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

Yes, combinations marked (**) below would have to changed from RFC 6040:

            +---------+------------------------------------------------+
            |Arriving |            Arriving Outer Header               |
            |   Inner +---------+------------+------------+------------+
            |  Header | Not-ECT | ECT(0)     | ECT(1)     |     CE     |
            +---------+---------+------------+------------+------------+
            | Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
            |  ECT(0) |  ECT(0) | ECT(0)     | ECT(0) (**)|     CE     |
            |  ECT(1) |  ECT(1) | ECT(0) (**)| ECT(1)     |     CE     |
            |    CE   |      CE |     CE     |     CE(!!!)|     CE     |
            +---------+---------+------------+------------+------------+


Similar changes would be needed for draft-ietf-tsvwg-rfc6040update-shim and
draft-ietf-tsvwg-ecn-encap-guidelines.

Clearly, the need to get such changes deployed would be a barrier to
barrier to adoption.

- the existing accecn spec would often lose non-CE signals
>

Actually, I would go farther and say that something rather different from
the existing AccECN draft would be needed. AccECN provides accurate
feedback of the number of CE marks observed. Under the proposed scheme L4S
would need to getting accurate feedback of the number of ECT(0)
(pre-congestion / some congestion) marks. AccECN would need to be
re-worked to provide both that and, in addition, either the existing
ECE/CWR handshake or something else that performs the equivalent function.
The most obvious solution would be to repurpose NS and one or  more
currently reserved flag bits (or use other ideas from RFC 7560 Sec 5.2) and
leave ECE/CWR unchaged. I note in passing the SCE proposal would have to do
something along the same lines (though AFAICT that has not yet been fully
fleshed out).


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

If I understand what is being said, this is because ECT(0) would become
ambiguous, as it can appear either on an L4S packet with a pre-congestion
marking, or a non-L4S packet.  Doesn't the same issue exist with the
current L4S proposal for CE-marked packets?

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

+1


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

Actually, it seems to me that this approach would yield exactly the same
congestion signaling capability as using ECT(1) as a  pre-congestion / some
congestion mark. All that has been done is to reverse the role of ECT(1)
and ECT(0) compared to what the SCE draft and RFC 6040 envisioned. In other
words:

      +-----+-----+
      | ECN FIELD |
      +-----+-----+
         0     0        Not-ECT
         0     1        ECT(1) - L4S/SCE Capable AND No Congestion
         1     0        ECT(0) - Some Congestion OR RFC 3168 ECN Capable
         1     1        CE


Jake, you said that the three issues discussed above -- tunnels, AccECN,
and multiple AQMs in the path are "a few of the known tradeoffs." What are
the others?

Mike Heard