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

["Holland, Jake" <[e-mail]>]

Hi Martin,

> Jake, I like your frame of the interesting trade-off between losing the L4S signal and losing the 3168 signal. However, let me add yet another concern about ECT1->0: by design, packets so marked may arrive *much* later than neighbors not marked, which means they are likely to be declared lost anyway. Do you see this as a problem, or post bottleneck is the latency difference likely small?


My take is that this basically happens only in a dualq (leaving aside other causes of reordering), and the classic portion of a dualq is not a deep dumb fifo, but rather a ordinary PIE AQM with a good delay response like normal classic PIE AQMs.  So the time difference that’s added by a single such queue is what you’d expect from a normal classic PIE AQM, if you have multiple loaded links (which by the way we’ve seen argued is quite uncommon, at least when L4S proponents are supporting the notion that mis-classifying classic CE-marked packets isn’t a problem).

According to the same charts, such a PIE queue tends to vary from up to what looks like about 5ms at near the median to about 50ms at the 5 9’s level:
https://datatracker.ietf.org/meeting/105/materials/slides-105-tsvwg-sessa-5-l4s-presentation-00.pdf#page=2

This time difference is well below RTO, but could easily hit a fast rexmit from dupacks if the L4S endpoint isn’t using RACK, or if it is using RACK it could reasonably at the higher end fall outside the RACK reordering window if it’s a short enough path, since the reordering window at min_rtt/4, according to https://tools.ietf.org/html/draft-ietf-tcpm-rack-08#section-8.3.  (And of course this can cascade if there are multiple queues, so at, say, 10-15 such loaded bottlenecks when the first one gets a high-fi mark, you might be able to make it start to bump into RTO.)

However, IIRC previous review found that a fast retransmit in a modern linux would get retroactively fixed up to be a non-loss signal when the late ack arrives, though you could end up with some extra traffic generated when it happens.

So to me the reordering issue doesn’t look offhand like a likely stopper for this, though it’s certainly awkward when there’s multiple loaded paths in sequence and this is a clear downside for this signaling strategy, regardless of whether people agree that the MD signal is the more important of the 2 signals to keep in tunneled paths.  The similar worry over classic CE reordering got a lot of discussion IIRC, but I think the resolution concluded that it wasn’t a big problem.  However, I think this would be somewhat worse, and could also get some similar discussion, even if this otherwise looks like a worthwhile path.

Caveat emptor: this is all off-the-cuff reasoning, I haven’t tested any of this of course.  Just laying out the line of reasoning as I understand it, but if anybody ever tests this, it could reasonably show out problems I haven’t thought of.  I do think it would be potentially quite a bit of reordering sometimes in paths with multiple dualqs.

Best,
Jake