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

[Martin Duke <[e-mail]>]

Well this all seems very promising!

Does anyone have the bandwidth to write something down? Should there be a
separate draft that articulates the design? Would this replace the current
Prague approach?

Martin

On Tue, Feb 9, 2021 at 3:09 PM Bob Briscoe <[e-mail]> wrote:

> Richard,
>
> First, thank you for reviving this thread, because it brought Alex's
> last posting (in Dec) to my attention. I'll respond to that separately
> (probably mañana, as it's getting late).
>
> Pls see inline tagged [BB]...
>
> On 09/02/2021 11:05, Scheffenegger, Richard wrote:
> > 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).
>
> [BB] Also, in case people aren't aware: an L4S sender using TCP MUST
> negotiate the use of Accurate ECN TCP feedback with its peer. So I think
> there's no case where a transport would not provide feedback for Alex's
> idea.
>
> >
> > 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.
>
> [BB] ...only if the data receiver supports sending the AccECN TCP Option
> (optional) and the new TCP Option traverses the path successfully and
> the data sender supports reading the TCP Option (optional).
>
> Nonetheless, if any of these three is not the case, it might still be
> possible to work out whether a CE marking was on a probe packet...
>
> The ACK that carries the CE packet counter also carries an ACKno (and
> possibly SACK options). When a zero-sized probe is sent, it won't elicit
> an ACK on its own (TCP doesn't ACK pure ACKs). But if the probe is CE
> marked, when the data receiver ACKs subsequent data packet(s), the CE
> packet counter will include any CE marking on the probe. It seems that
> doesn't help, because the data sender cannot tell whether the CE mark
> was on the data packets or the probe. But if the counter ever increases
> by more than the number of data packets covered by the ACK, the probe
> must have been marked as well.
>
> That sounds like having to wait quite a time for the possibility of all
> packets together being marked. But there might be a more deterministic
> way by use the same trick that keep alive probes use...
>
> That is, send a zero-sized probe with SEG.SEQ = SND.NXT-1. Being out of
> window, each of these probes would immediately elicit a pure ACK from
> the receiver. This might cause problems alongside the other regular
> ACKs, because I think these might look like Dup ACKs (when the trick was
> invented for keepalives, this wasn't a problem 'cos there were no other
> data packets being ACK'd). However, it's possible the sender can work
> out that they are not Dup ACKs, given it knows it sent a probe.
>
> (I'm not totally certain of my facts here - we'd need a TCP expert to
> confirm - Richard?)
>
>
> Bob
>
> >
> >
> > 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.
>
> [BB]
>
>
> >
> > 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 ____
> >>
> >
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>