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

[Bob Briscoe <[e-mail]>]

Martin, Alex, list,

Towards a write-up, here's the way I see Alex's ideas being used for 
out-of-band testing (in contrast to Alex's thoughts, which were for 
in-band testing).

First a reminder of Alex's first idea for a DualQ Coupled AQM (idea A1):
* Make it mandatory for a DualQ Coupled AQM not to mark ECT0 packets, so 
Classic ECN AQMs without L4S support are distinguishable as the only 
AQMs that mark ECT0.

Second a reminder of Alex's second idea for an FQ-L4S AQM (idea A2):
* always marks ECT1,
* but it drops rather than marks ECT0 packets if there has been any 
(recent) ECT1 in the same flow.
* If there hasn't been any ECT1 in a queue, it just marks ECT0 classically.

==Out of band test==
A test server would fill the path with ECT0 until it's getting a strong 
congestion signal (CE or loss), then it would switch a low fraction (say 
5%) of packets to ECT1. The table below then shows the various patterns 
of marking that might occur and what can be concluded about the 
bottleneck. An empty cell means "don't care".

For completeness, I've included all the invalid cases too (explained 
below the table).
If the table is unreadable without HTML email, see 
https://bobbriscoe.net/projects/latency/DisableECT0_OOB_TruthTable.pdf
which also includes the full Truth Table.

All ECT0 	95% ECT0 	5% ECT1 	
drop 	mark 	drop 	mark 	drop 	mark 	Bottleneck queue behaviour
 >0 	0 	>0 	0 	>0 	0 	Tail-drop or Non-ECN AQM (FQ or FIFO)

	>0 	
	>0 	
	>0 	Classic ECN AQM (FQ or FIFO)

	>0 	
	>0 	
	~100% 	FQ-L4S AQM without A2

	>0 	>0 	0 	
	>0 	FQ-L4S AQM with A2
 >0 	0 	>0 	0 	
	>0 	DualQ L4S AQM
*All possible invalid experiment runs*
0 	0 	
	
	
	
	Uncongested

	
	0 	0 	
	
	Uncongested

	
	
	
	0 	0 	Uncongested

	
	
	>0 	
	0 	ECT0 but no ECT1 marking yet

	>0 	
	
	
	0 	ECT0 but no ECT1 marking yet

	0 	
	>0 	
	
	No ECT0 marking until ECT1 starts


Terminology:

  * congestion mark = CE
  * congestion indication = drop or CE


So that I could check the design of the experiment, I wrote out all the 
possible 2^6 combinations of congestion outputs and crossed off the ones 
that represented each valid output pattern. Then I kept adding invalid 
cases until all the output combinations were crossed off. This led to 
the following invalid cases where an experiment run has to be aborted:

  * If no congestion indication (drop or marking) can be induced on an
    ECT0 packet, either before ECT1 packets are introduced or after, the
    run has to time out;
  * Whether or not there are congestion indications on any ECT0 packets,
    a run has to eventually time out if there is never a congestion
    indication on an ECT1 packet;
  * If any ECT0 packet has been marked, a run has to eventually time out
    if no ECT1 packet is ever marked;
  * If no ECT0 packet is marked before ECT1 packets are introduced, but
    an ECT0 packet is marked after, the run has to abort.


Cheers


Bob

On 11/02/2021 00:22, Bob Briscoe wrote:
> 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 Briscoehttp://bobbriscoe.net/

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