Re: [tsvwg] L4S and the detection of RFC3168 AQMs

[Martin Duke <[e-mail]>]

Excellent, thank you for the reminder. So the L4S sender could interleave
some ECT(0) marked pure ACKs (or retransmissions of the last acknowledged
byte) and hope that the PCE counter increases without corresponding
increases in BCE.

The AccECN spec might need to be updated to specify that these should be
reported in PCE even though they are not 3168 compliant.

Scheduling these probes might not exactly be trivial, but if they are
temporally correlated with ECT(1)->CE marks, this would be highly
suggestive, yes?

On Fri, Dec 11, 2020 at 3:03 PM Black, David <[e-mail]> wrote:

> In which case, RFC 8311 Section 4.3 allows experimental usage of ECN with
> such packets (https://tools.ietf.org/html/rfc8311#section-4.3).
>
>
>
> Thanks, --David
>
>
>
> [EXTERNAL EMAIL]
>
> My understanding of 3168 is that only in-window data packets are marked
> ECT(0). A zero-length segment is a equivalent to a pure ACK, which is not
> marked.
>
>
>
> On Fri, Dec 11, 2020 at 12:09 PM C. M. Heard <[e-mail]> wrote:
>
> On Fri, Dec 11, 2020 at 11:51 AM Martin Duke <[e-mail]>
> wrote:
>
> This falls under the "much easier to do in other transports" category,
> where I could just send a PING or HEARTBEAT marked ECT(0) to test the queue
> in mid-connection, without affecting the latency of anything that matters.
> But in the TCP case, I'm not sure how to resolve Bob's second objection
> (running ECT(0) for a long time would be unacceptable).
>
>
>
> Could zero-length TCP segments be used instead of PING or HEARTBEAT?
>
>
>
> Mike Heard
>
>