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

[Martin Duke <[e-mail]>]

Hi Jake,

Sorry for a not-very-carefully composed email!

On Mon, May 18, 2020 at 7:56 PM Holland, Jake <[e-mail]> wrote:

> Hi Martin,
>
>
>
> Thanks, I think it’s an interesting direction also, and I’m glad to get
> some discussion on it.  Here’s hoping it turns out useful, or at least
> informative.
>
> be less aggressive during slow start.
>
>
>
> <JH>
>
> 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.

>
>
>
> 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
>
>
>
> <JH>
>
> I’m not sure I follow this suggestion.
>
>
>
> If you’re imagining a “latch-on” behavior like ECE that waits for CWR from
> sender before moving along, I think the sender no longer has a CWR if
> they’ve negotiated ACE, so they can’t respond in a way that turns off the
> latch.  But if you’re just using 1 packet with 1 codepoint to indicate “CE
> observed”, you’ll miss the report of CE observed at sender if the ack
> bearing that signal is dropped or thinned or whatever, so I think neither
> of those would work.
>
>
>
> But I guess you could maybe use 1 codepoint for a latched-on ECE and
> another codepoint for CWR, and still have a 6-slot counter for the ECT(0)
> signal (which is superseded by the ECE codepoint while active).
>

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.

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?