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

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

Hi Martin,

New responses with <JH2></JH2>

From: Martin Duke <[e-mail]>
Date: Tuesday, May 19, 2020 at 10:21 AM

To me, the problem with loss as the only (viable) MD signal is the existing devices that don’t drop until well after exceeding reasonable fairness bounds from an unresponsive flow, so for TCP Prague to maintain compatibility with classic queues, it would still need a successful classic queue detection mechanism.

I probably misunderstood. I thought the desired signal was a MD signal in the low-latency queue. Yes, for 3168 queues you'd have to essentially treat ECT(1) as Not-ECT. So that may not be a productive direction.

<JH2>
As I understand it, this is the current L4S MD signal if the LL queue overflows into the low latency queue and has congestion there.

I agree this works as far as it goes, but the safety problem that seems to need an MD signal is the interaction with existing queue implementations that know nothing about L4S, and have a pre-existing interpretation of ECT(1).

(Even for FQ, the interaction is very poor, but shared queues is where the poor interaction is arguably a major safety concern.  Mostly nobody seems to care much about the occasional hash collision in FQ that would have the same problem, because most FQs are 1024 slots, so after birthday paradox considerations it’s only 1/32 or so of the competing flows.)

Anyway, if there was sufficiently good consensus that these classic queues are irrelevant, then deprecating them responsibly is a potentially viable way forward, but that’s not what any of the current BCPs or standards say today, I think.
</JH2>


Good catch -- soon after I sent this, I thought, "what about CWR". The problem with using a second codepoint is that the sender signal then pre-empts the feedback signal -- fine for functionally half-duplex connections, but not generally. I can see a few ways out of this:

1) Take another TCP header reserved bit so that we can keep CWR and the 3 bits for ACE. (Ugh)
2) Come up with a heuristic to stop sending ECE, obviating CWR.
3) Come up with a heuristic to mix packets with CWR and ACE as needed depending on counter activity.
Though I'll defer to Bob on the issues of re-engineering ACE -- it sounds like he's been through all the permutations.

<JH2>
My conclusion that it seemed workable to me came with the assumption that #3 would be pretty straightforward.

You don’t need very many CWRs, and it might be possible to clean up the specs a bit about when exactly they should be sent (like maybe they’re only appropriate when there’s a MD event, and maybe they shouldn’t be sent for linear reductions during a fine-tuning response, now that we’re contemplating such a thing).

So I was thinking for bidirectional traffic that has the newly suggested ACE signaling (with a codepoint for ECE and CWR, plus 6 count slots), you could just put CWR at the top priority, so the (only occasional) CWR would overrule either a latched ECE that’s still in progress or one of the fine-tuning signal slots, for the occasional packet reporting an MD event.  (The logic from 3168 still holds here: if CWR is on a data packet and the data packet is lost, you’ll still get an MD response, so it doesn’t need to be reliable like ECE, and the counter makes it so skipping a packet doesn’t lose the fine-tuning signal, since it’s no worse than thinning the acks would have been.)

I do worry a bit whether a 6-count is enough to detect rollover well, but like with the ESCE approach for reflecting the fine-tuning signal, losing some accuracy is acceptable if we have a reliable MD signal, so I think it’s probably ok.

I wouldn’t say no to #1 either, even if only to increase the ACE count and still keep a 2-codepoint signal for the non-counting signals.
</JH2>


I guess I don't understand the tunneling problem. If we have a mark that demands MD, that trumps feedback about low-latency fine tuning, does it not?

<JH2>
As tempting as it is to just answer “yes, of course”, I’ll acknowledge it’s not quite so clear-cut.  (And I feel like you might not be alone in not understanding this facet of the problem yet, so thanks for asking about it.  It hasn’t been very easy to follow.)

The issue as I understand it is that tunnels as they stand today can only export the CE signal, period.  (At best.  That’s if they’re RFC6040-compliant.  If we want to carry 2 signals, we’d need to obsolete RFC 6040 with a decapsulation algorithm that carries 2 signals instead, and update a lot of tunnel endpoints, hence a decade-long rollout before most tunnels have it.)

The L4S proponents have argued persistently that it’s not necessary to respond to a classic CE signal with MD, and that the value gained from the fine-tuning signal is key to the L4S value proposition, and therefore that the fine tuning should be carried in CE, regardless of the interactions with classic queues.

And it’s also fair to note that RFC 8311 introduced some significant question as to whether a mark from a classic queue now demands an MD response, so now it’s sort of a judgement call about whether we can get “effective congestion control” without honoring such a signal in the MD way that the classic queues are expecting.

So I think it’s an open question at this point about what constitutes a reasonable outcome when MD is not the response to a classic queue’s CE signal.

Some of that depends on whether you think the classic queue detection can be made successful, since it provides an alternative MD response that’s not a direct response to a CE signal from the classic queue.  (There are currently some differing opinions on how likely this is to work in practice, just in case it wasn’t complicated enough yet.)

I of course have my opinions, but I don’t know of an established consensus here, and to me it seems like the main crux of the debate over safety properties of L4S, at this point.
</JH2>