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

["Scheffenegger, Richard" <[e-mail]>]

Martin, group,


AccECN is not tied to RFC3168 (and quite the opposite, it tries to be as
impartial to the specifics of when/why packets were marked in whichever
way).

Therefore the Packet-CE counter (you refer to it as PCE, while the draft
refers to the (full) counter as cep [from CE_packet] is incremented
regardless of which packet arrives with the CE mark (control, data,
retransmission, ...).

Similar for the Byte-CE counter (BCE, in the AccECN draft ceb from
CE_bytes). As only TCP payload bytes arriving with the CE mark would be
accounted, the behavior as expected in the discussion below is already
implicitly available when using AccECN.


There may be some ambiguity, as AccECN doesn't strictly require an
immediate ACK on a CE (only that the next packet after a received CE
mark has to convey the changed CE-related counters), but in the general
case, AccECN would allow and support such a detection scheme.

Best regards,
    Richard



Am 12.12.2020 um 00:22 schrieb Martin Duke:
> 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]
> <mailto:[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
>     <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]
>     <mailto:[e-mail]>> wrote:____
>
>         On Fri, Dec 11, 2020 at 11:51 AM Martin Duke
>         <[e-mail] <mailto:[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 ____
>