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

["[e-mail]" <[e-mail]>]

Martin, Bob, all,
I am happy for these ideas to be taken forward by Bob or anyone else  - unfortunately I am unlikely to have time to contribute, as I am not working on networking at present.  As such I don't have any opinions on what is the appropriate doc.

best,
Alex


On Thursday, February 11, 2021, 12:29:45 AM GMT, Bob Briscoe <[e-mail]> 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]> 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/
> 
> 
> 


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