Subject: [tcpm] Clarification on NewReno vs Reno

From: Yuchung Cheng <[email-masked]>
Date: Mon, 13 Mar 2017 15:24:48 -0700

Over the past years, I have seem many people in both academia and
industry citing NewReno as a congestion control which really confuses
me. I would like to attempt to ask a clarification from list.

AFAIK, NewReno is NOT a congestion control. It is an improvement to
loss recovery in the absence of SACK support, per the abstract in
RFC6582

"""    ... in the absence of SACK. This document describes a specific
   algorithm for responding to partial acknowledgments, referred to as
   "NewReno".  This response to partial acknowledgments was first
   proposed by Janey Hoe.  This document obsoletes RFC 3782.

"""

In a nutshell, NewReno simply retransmits the next unacked packet when
SND.UNA advances. Using NewReno impacts the congestion control which
can be either Reno, Cubic, etc. But it is not a congestion control by
itself. In Linux NewReno is used only if SACK is not supported which
is rare.

Reno in contrast is the standard AIMD defined by RFC5681.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 13 Mar 2017 16:13:37 -0700

Hi Yuchung,

This seems to be a rather philosophical question to me. So, I am not very
sure if we can gain something from this..

In my personal view, congestion control in TCP is "infer network status
based on feedback info, adjust amount of packet transmissions  based on it"
I think what newreno does fit this. It uses partial acks as feedback to do
some controls.
Hence, it looks congestion control to me. But, it's just my personal view
and can be different from yours.

Thanks,
--
Yoshi

On Mon, Mar 13, 2017 at 3:24 PM, Yuchung Cheng <[email-masked]> wrote:

> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>

---

From: Michael Welzl <[email-masked]>
Date: Tue, 14 Mar 2017 09:03:41 +0100

Hi Yuchung,

I'm completely with you - I noticed the same mis-use and found it annoying. However, I have meanwhile given in and also use "NewReno" in papers. There are two reasons:

1) I once had a reviewer point out that we worked with the old Reno instead of NewReno, because I used the name "Reno" in a paper. I know that's a horrible reason, but pragmatically I don't want to risk paper failure because of a reviewer who makes that mistake.
Of course I wouldn't write truly wrong things into a paper on that basis, but saying "NewReno" instead of "Reno" strikes me as harmless... misleading, indeed, and somewhat annoying, but what can we do when people don't get it. Blame the name! It should have been "TCP with partial ACK support", or something like that.

2) When I write something like "We did tests on FreeBSD, choosing newreno congestion control", then that's actually correct because that's the name given to the default Reno-type CC. in FreeBSD's pluggable congestion control. The name isn't really wrong either, it really does implement NewReno, but it's a bit awkward as a naming choice (could have just as well been "TCP Reno with SACK support and Limited Transmit and ABC and the following spurious timeout detection / recovery algorithms and ... and ..." ). Oh well.

My suggestion is to accept that Reno is now called NewReno, because Reno is old and NewReno is new.

Cheers,
Michael

> On 13 Mar 2017, at 23:24, Yuchung Cheng <[email-masked]> wrote:
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 14 Mar 2017 15:57:51 +0000

>> When I write something like "We did tests on FreeBSD, choosing newreno congestion control", then that's actually correct because that's the name given to the default Reno-type CC
This is true of Windows as well - code as well as the config surface.

-----Original Message-----
From: tcpm [mailto:[email-masked]] On Behalf Of Michael Welzl
Sent: Tuesday, March 14, 2017 1:04 AM
To: Yuchung Cheng <[email-masked]>
Cc: [email-masked] Extensions <[email-masked]>; [email-masked]
Subject: Re: [tcpm] [iccrg] Clarification on NewReno vs Reno

Hi Yuchung,

Cheers,
Michael

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 14 Mar 2017 10:20:46 -0700

Thanks for the replies: now I know why people use NewReno it's b/c of
implementation misnomer.