<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
[I'm sending this to ecn-sane 'cos that's where I detect that this
concern is still rumbling.<br>
I'm also sending to tcpm@ietf 'cos there's a question for TCP
experts just before the quoted text below.<br>
And tsvwg@ietf is where it ought to be discussed.]<br>
<br>
Now that the IPR issue with L4S has been put to bed, one by one I am
going through the other concerns that have been raised about L4S.<br>
<br>
In the IETF draft that records all the pros and cons of different
identifiers to use for L4S, under the "ECT(1) and CE" choice (which
is currently the one adopted at the IETF) there was already an
explanation of why there would be vanishingly low risk of any
harmful consequences from CE that was originally ECT(0) being
classified into the L4S queue:<br>
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06#page-32">https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-06#page-32</a><br>
<br>
Re-reading that, I have found some things unstated that I had
thought were obvious. So I've spelled it all out long-hand in the
text below, which is now in my local copy of the draft and will be
in the next revision unless people suggest improvements/corrections
here.<br>
<br>
<b>Q#1:</b> If this glosses over any concerns you have, please
explain. <br>
Otherwise I will continue to consider that this is effectively a
non-issue, which is the conclusion everyone in the TCP community
came to at the time the L4S identifier was chosen back in 2015.<br>
<br>
<b>Q#2: </b>The last couple of lines are the only part I am not
sure of. Do most of today's TCP implementations recover the
reduction in congestion window when they discover later that a fast
retransmit was spurious? There's a note at the end of the intro to
rfc4015 saying there was insufficient consensus to standardize this
behaviour, but that most likely means it's done in different ways,
rather than it isn't done at all.<br>
<br>
<br>
Bob<br>
<br>
<br>
======================================<br>
<br>
<pre> Risk of reordering classic CE packets: Classifying all CE packets
into the L4S queue risks any CE packets that were originally
ECT(0) being incorrectly classified as L4S. If there were delay
in the Classic queue, these incorrectly classified CE packets
would arrive early, which is a form of reordering. Reordering can
cause TCP senders (and senders of similar transports) to
retransmit spuriously. However, the risk of spurious
retransmissions would be extremely low for the following reasons:
1. It is quite unusual to experience queuing at more than one
bottleneck on the same path (the available capacities have to
be identical).
2. In only a subset of these unusual cases would the first
bottleneck support classic ECN marking while the second
supported L4S ECN marking, which would be the only scenario
where some ECT(0) packets could be CE marked by a non-L4S AQM
then the remainder experienced further delay through the
Classic side of a subsequent L4S DualQ AQM.
3. Even then, when a few packets are delivered early, it takes
very unusual conditions to cause a spurious retransmission, in
contrast to when some packets are delivered late. The first
bottleneck has to apply CE-marks to at least N contiguous
packets and the second bottleneck has to inject an
uninterrupted sequence of at least N of these packets between
two packets earlier in the stream (where N is the reordering
window that the transport protocol allows before it considers
a packet is lost).
For example consider N=3, and consider the sequence of
packets 100, 101, 102, 103,... and imagine that packets
150,151,152 from later in the flow are injected as follows:
100, 150, 151, 101, 152, 102, 103... If this were late
reordering, even one packet arriving 50 out of sequence
would trigger a spurious retransmission, but there is no
spurious retransmission here, because packet 101 moves the
cumulative ACK counter forward before 3 packets have
arrived out of order. Later, when packets 148, 149, 153...
arrive, even though there is a 3-packet hole, there will be
no problem, because the packets to fill the hole are
already in the receive buffer.
4. Even with the current recommended TCP (N=3) spurious
retransmissions will be unlikely for all the above reasons.
As RACK [I-D.ietf-tcpm-rack] is becoming widely deployed, it
tends to adapt its reordering window to a larger value of N,
which will make the chance of a contiguous sequence of N early
arrivals vanishingly small.
5. Even a run of 2 CE marks within a classic ECN flow is
unlikely, given FQ-CoDel is the only known widely deployed AQM
that supports classic ECN marking and it takes great care to
separate out flows and to space any markings evenly along each
flow.
It is extremely unlikely that the above set of 5 eventualities
that are each unusual in themselves would all happen
simultaneously. But, even if they did, the consequences would
hardly be dire: the odd spurious fast retransmission. Admittedly
TCP reduces its congestion window when it deems there has been a
loss, but even this can be recovered once the sender detects that
the retransmission was spurious.
</pre>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
________________________________________________________________
Bob Briscoe <a class="moz-txt-link-freetext" href="http://bobbriscoe.net/">http://bobbriscoe.net/</a></pre>
</body>
</html>