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

[Bob Briscoe <[e-mail]>]

Martin,

On 18/05/2020 23:11, Martin Duke wrote:
> Jake,
>
> I'm intrigued by this discussion of the ECT(1)->ECT(0) proposal, as 
> something that could definitively solve the safety concerns. I'll make 
> two unrelated points:
> 1) If the current L4S proposal is in need of an MD signal, there's 
> always dropping the packet.  Although packet loss is bad, maybe some 
> drops at the end of slow start is the tradeoff we have to make to get 
> low latency. Implementations really concerned about loss can be less 
> aggressive during slow start.
> 2) Clearly, there is no AccECN signaling problem for ECT(1)->ECT(0) 
> for QUIC, and for TCP paths where the option gets through. It this is 
> an issue of the three ACe bits, I think one codepoint in ACE would be 
> sufficient to indicate that a CE mark was received, which IMO would 
> trump whatever other feedback is in that header.. Unless there's some 
> sort of performance cliff in not being able to encode 7 ECT(0) marks, 
> this seems like a non-problem

[BB] I don't know how you get to one codepoint in ACE being enough for 
CE. The whole idea of AccECN is to be robust to ACK loss and thinning. 
If it was as simple as you make out, we could have sorted out this 
problem snip-snap and all be home in time for tea.

As we all try to remove more and more latency, we are all going to find 
that the problems get harder and harder - little details matter a lot. 
Without really solid feedback precision, you lose the consistent latency 
of L4S.

Richard Scheffenegger and I designed a 4-3-1 codepoint scheme for ACE at 
one point (4 for CE, 3 for ECT(1) and one for Not-ECT). See 
https://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-03#section-3.2.1 
Table 3. However, it was removed because it was "jack of all trades, 
master of none." By trying to cover all the codepoints, it didn't give 
sufficient robustness to any.

Even using all 8 values of the 3-bit counter for feeding back just one 
codepoint is on the edge of what is needed today. I sometime liken the 
ACE part of AccECN to a "stalking horse" - i.e. a vehicle that works for 
today, while also acting as a platform to get the larger AccECN Option 
deployed for the longer term - when the ACE field might have become too 
small for the possible future level of ACK thinning on some paths.

In fact, over the years {1} that we've been trying to get AccECN 
standardized, you will find all sorts of weird and wonderful compressed 
encodings, but in the end, as well as inadequate robustness, arguments 
for simplicity took precedence. Not just because complexity breeds bugs 
(which is not an insignificant consideration for TCP), but also because 
the semantics of ACE also have to be supported by segmentation offload 
hardware.

When, I highlighted the problems with tunnelling that the ECT1->0 scheme 
has, I only hinted at these problems with TCP, because I thought 
incompatibility with tunnelling should be a sufficient argument.

In summary, if you think deploying a change to IP is easy, you've 
probably not absorbed the full breadth of the problem.


Regards



Bob

{1} Since Oct 2005: 
https://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-00#section-4.1

>
> Martin (as an individual)
>
> On Sun, May 10, 2020 at 5:09 PM Holland, Jake 
> <jholland=[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Mike,
>
>     From: "C. M. Heard" <[e-mail] <mailto:[e-mail]>>
>     > Yes, combinations marked (**) below would have to changed from
>     RFC 6040:
>     ....
>     > 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.
>
>     Yes.  I think in a recent thread I heard it confirmed that current
>     tunnel
>     handling of these is kind of spotty today, specifically:
>
>       > as an endpoint we'll be dealing with weird inconsistencies
>     that basically
>       > never fully understood anything beyond "don't lose CE marks"
>     and maybe
>       > "loss is acceptable in confusing cases", if we're lucky.
>
>       [BB] See reply to Dave Taht just now, which pretty much confirms
>     what
>       you've just said.
>
>     that's from here:
>     https://mailarchive.ietf.org/arch/msg/tsvwg/QudqLu1RTQZCVnS4HNf8jnZ_kIY/
>
>     (I think the Dave Taht reply he was referencing was this one:
>     https://mailarchive.ietf.org/arch/msg/tsvwg/2ElPK72IiFg2gHJZ_rLMUKTDfCI/
>     )
>
>     I'm beginning to think the reason I've come down differently than the
>     L4S team on the judgement call for this approach being better, in
>     light
>     of the state of tunneling encapsulation deployments, might boil
>     down to
>     a disagreement over the answer to a question like:
>       Which is better:
>       - losing the safety response of MD from a loaded classic queue, or
>       - losing some of the reliability on the low-latency response
>     when there
>         is a dualq on-path?
>
>     I'm beginning to think we might be stuck with one of those options for
>     tunneled paths until tunnel decap implementations can be widely
>     upgraded
>     in deployment, however this lands.
>
>     > - 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).
>
>     Agreed, I think a different feedback than AccECN would be smarter
>     if the
>     ECT(1)->ECT(0) approach goes forward, and I like the NS reflection
>     approach
>     that SCE's implementation started with.  (Although it might lose
>     fidelity
>     from some ack aggregation responses, I'd expect usually that the
>     marking
>     rate maintains proportionality on the low-congestion signal, and
>     where that
>     fails, the standard ECE response is at least reliable, so it
>     covers the
>     safety considerations the same way as classic marking.)
>
>     However, I also think for anyone who disagrees, other viable
>     approaches
>     for the feedback might be possible.  But in that direction, I do think
>     it probably would need to differ from AccECN.  This would of
>     course need to
>     be nailed down in the end, though I didn't get into it in the
>     first email.
>     But the potential complexity here is one of the reasons I rate the
>     suggestion as perhaps a major architectural change for L4S.
>
>     I tend to think that the per-ECT(0) reflection in NS is the best way,
>     but I don't think it would change the rest of the argument if that
>     position
>     turned out wrong.
>
>     > - 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?
>
>     Yes, but the L4S specs go over this and walk through the reasoning for
>     why they landed on classifying CE into the LL queue, and the net
>     result
>     in that case is  that the ECT(1)->CE marking strategy that L4S
>     currently
>     follows will keep the 1/p packet signals in the LL queue for the later
>     hops.
>
>     (The potential problems were mostly limited to mis-classified marked
>     classic traffic, which will tend to be fewer in number and also less
>     severe given that the flow is slated to back off anyway, plus a
>     review of
>     the main implementations suggested they wouldn't be doing
>     double-backoffs
>     if the CE packet was out of order, IIRC.)
>
>     It might be better to phrase this not as "loses integrity", but
>     rather as
>     "might systematically increase the latency experienced" for the
>     1/p signal,
>     since when there are multiple dualqs in line, those packets (but
>     not others
>     from L4S flows) will land in the classic queue on the later
>     dualqs.  This
>     is arguably a worse downside than the classification failure from
>     putting
>     CE-marked classic traffic in the LL queue.
>
>     > 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
>
>     Yes, that's my understanding.  I think the whole proposal can
>     reasonably be
>     summarized as "SCE with the bits flipped".
>
>     > 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?
>
>     These are all the ones I know of yet, but I think Bob and Koen
>     might have
>     some others they already know.  I'm not sure I got the whole story
>     yet.
>
>     Thanks for your comments.
>
>     Best regards,
>     Jake
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/