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

[Bob Briscoe <[e-mail]>]

Martin,

Greg and I spoke about this very question earlier in the week.

At minimum, we could write all the details covered in this thread into 
the tech report about Classic ECN AQM Fallback that Asad & I prepared 
earlier. "We" might mean Alex or me, or someone else? I would be happy 
to either ACK Alex or include him as a co-author - if he was willing.

I feel that would be more appropriate than an IETF draft at the mo, at 
least while it's not implemented or tested. Then the IETF drafts 
(l4sops, ecn-l4s-id, dualQ, etc.) could give a brief outline of the 
idea, while referring out for fuller details.

In that tech report, there is already a section on ideas for the design 
of active tests, which it says have not been implemented or tested. It 
would be published on arXiv as a new version, which is suitable as an 
archival ref.

Then, as Alex suggests, we would need to update the dualQ draft.
As Alex pointed out, not supporting ECT0 can later be reversed (e.g. if 
the L4S experiment later moves to PS), whereas supporting ECT0 from the 
start, them removing it later would miss the opportunity to provide 
certainty. This is the part I like most.

We would also have to not make ECT0 support the default in the reference 
Linux implementation of the DualQ.


Bob

On 10/02/2021 18:37, Martin Duke wrote:
> 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] 
> <mailto:[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]>
>     >> <mailto:[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]>
>     >>     <mailto:[e-mail] <mailto:[e-mail]>>> wrote:____
>     >>
>     >>         On Fri, Dec 11, 2020 at 11:51 AM Martin Duke
>     >>         <[e-mail]
>     <mailto:[e-mail]> <mailto:[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/
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/