Subject: [tcpm] rfc8312bis: use of the term 'AIMD'

From: Bob Briscoe <[email-masked]>
Date: Wed, 15 Sep 2021 14:17:42 +0100

Lars, Lisong, Vidhi and co-authors,

Sorry. in the process of trying to close off the recent github issues, I 
noticed one editorial point that is prevalent throughout the document:
I think the terms 'AIMD TCP' and AIMD-friendly are inappropriate and 
would be better replaced with just 'Reno' and 'Reno-friendly', for these 
reasons:

  * AIMD describes a broad class of CC algorithms with any α and β, but
    in the Cubic draft it is always used to describe (α=1, β=0.5), which
    would surely be more specifically described as just 'Reno'.{Note 1}
  * Although Reno was only defined within the TCP wire protocol, the
    core of the algorithm is agnostic to the wire protocol, as witnessed
    by the brevity of the diffs for the variants in SCTP, etc.
  * 'Reno' would be a better (at least adequate) word to describe the
    variants in SCTP, TFRC, QUIC etc, while avoiding unnecessarily
    confusing use of the word 'TCP'.
  * On the current Internet, Cubic is very often in its 'TCP-friendly'
    mode {2}. So Cubic is very often running as an AIMD algorithm.
    Therefore I find it *really* confusing when Cubic is described as if
    it is 'other than AIMD'. People really should not think of the Cubic
    algorithm as pure Cubic mode - that creates really really bad
    intuition about how the Internet is working.

{1}: New Reno is primarily about retransmission, and only peripherally a 
congestion control difference.
{2}: See https://arxiv.org/pdf/2107.01003.pdf#page.4 for data by country 
between RIPE Atlas probes and the main global CDNs. Note however that 
the purpose of that study was to set the parameters of an AQM, so it 
assumes AQM-like queue delay. For tail-drop buffers (still unfortunately 
widespread), Cubic will more often get into true Cubic mode, at least 
for long flows. But for short and medium flows that do not have time to 
fill tail-drop buffers, this data is still likely to be relevant.

Sorry again for raising an issue after WGLC. But this terminology is 
definitely wrong, and I definitely wouldn't want it to set a precedent.

Bob

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

---

From: Neal Cardwell <[email-masked]>
Date: Wed, 15 Sep 2021 10:57:17 -0400

On Wed, Sep 15, 2021 at 9:18 AM Bob Briscoe <[email-masked]> wrote:
> Sorry. in the process of trying to close off the recent github issues, I noticed one editorial point that is prevalent throughout the document:
> I think the terms 'AIMD TCP' and AIMD-friendly are inappropriate and would be better replaced with just 'Reno' and 'Reno-friendly', for these reasons:

I very much agree with Bob's remarks; I'd like to put in a second vote
for replacing 'AIMD TCP' and 'AIMD-friendly' with 'Reno' and
'Reno-friendly'. The latter terms are more precise (implying specific
constants for the AIMD mechanism), and nicely agnostic to transport
protocol.

best regards,
neal

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 15 Sep 2021 15:18:01 +0000

Hi,

> constants for the AIMD mechanism), and nicely agnostic to transport

we did change terminology before (https://github.com/NTAP/rfc8312bis/issues/38), but I have no issue changing it again. Opened https://github.com/NTAP/rfc8312bis/issues/108.

Thanks,
Lars

---

From: tom petch <[email-masked]>
Date: Wed, 15 Sep 2021 15:48:34 +0000

From: tcpm <[email-masked]> on behalf of Bob Briscoe <[email-masked]>
Sent: 15 September 2021 14:17

<tp>
OK as long as you put [RFCxxxx] after Reno; I know exactly what AIMD is, Reno I have to look up to remind me of the details.

Tom Petch

  *   AIMD describes a broad class of CC algorithms with any α and β, but in the Cubic draft it is always used to describe (α=1, β=0.5), which would surely be more specifically described as just 'Reno'.{Note 1}
  *   Although Reno was only defined within the TCP wire protocol, the core of the algorithm is agnostic to the wire protocol, as witnessed by the brevity of the diffs for the variants in SCTP, etc.
  *   'Reno' would be a better (at least adequate) word to describe the variants in SCTP, TFRC, QUIC etc, while avoiding unnecessarily confusing use of the word 'TCP'.
  *   On the current Internet, Cubic is very often in its 'TCP-friendly' mode {2}. So Cubic is very often running as an AIMD algorithm. Therefore I find it *really* confusing when Cubic is described as if it is 'other than AIMD'. People really should not think of the Cubic algorithm as pure Cubic mode - that creates really really bad intuition about how the Internet is working.

{1}: New Reno is primarily about retransmission, and only peripherally a congestion control difference.
{2}: See https://arxiv.org/pdf/2107.01003.pdf#page.4 for data by country between RIPE Atlas probes and the main global CDNs. Note however that the purpose of that study was to set the parameters of an AQM, so it assumes AQM-like queue delay. For tail-drop buffers (still unfortunately widespread), Cubic will more often get into true Cubic mode, at least for long flows. But for short and medium flows that do not have time to fill tail-drop buffers, this data is still likely to be relevant.

Sorry again for raising an issue after WGLC. But this terminology is definitely wrong, and I definitely wouldn't want it to set a precedent.

Bob