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

[Martin Duke <[e-mail]>]

Hi Jake,

First, thanks to Bob for the RFC 6040 reference. That cleared my confusion
about the tunnel problem up right away.

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?

Martin

On Tue, May 19, 2020, 13:13 Holland, Jake <[e-mail]> wrote:

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