TCP Reno is same as TCP NewReno in ns3?

[Vineet]

Hi All,

I am trying to use TCP Reno as network cross-traffic in one of my simulations. The congestion window profile suggests that Reno exhibits window inflation during fast recovery (as shown in figure below), which is a feature of NewReno protocol. Is there a justification for this or am I being oblivious to something?

 

Thanks in advance!

Cheers,
Vineet

[Natale Patriciello]

On 01/09/16 at 01:48am, Vineet wrote:
> I am trying to use TCP Reno as network cross-traffic in one of my
> simulations. The congestion window profile suggests that Reno exhibits
> window inflation during fast recovery (as shown in figure below), which is
> a feature of NewReno protocol. Is there a justification for this or am I
> being oblivious to something?

Hi,

your mail isn't mutt-friendly, so for me it's hard to answer to your
question.

Reno was removed some time ago from the ns3 mainline, so we are talking
about deads. Anyway, window inflation *is* part of Reno. You can find
the NewReno specifications in RFC 6582 (a good read). To our readers, I
extract the important part here:

"""
This document describes a modification
to the fast recovery algorithm in RFC 5681 that incorporates a
response to partial acknowledgments received during fast recovery.
We call this modified fast recovery algorithm NewReno.
"""

in which is clearly stated which is the improvement between Reno and New
Reno, and that it is only a different Fast Recovery algorithm.

Nat

[Vineet Gokhale]

Hi Nat,

Thanks for your response! Sorry for the earlier unclear description.

I agree that the difference in the two protocols (Reno and NewReno) lies only in the fast recovery algorithm. I understand that during fast recovery, NewReno manages to squeeze in some more packets into the network by inflating the congestion window by one packet for every ack arrival. On the other hand, Reno stays shuts off temporarily (in terms of new transmissions) throughout fast recovery. But the congestion window profile extracted from ns3 for Reno indicates a window variation that is similar to that of NewReno during fast recovery. Is it not supposed to look like this?

as opposed to the one below?

Thanks in advance!

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/ratWchTH1nA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+unsubscribe@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Natale Patriciello]

On 01/09/16 at 03:28pm, Vineet Gokhale wrote:
> Hi Nat,
>
> Thanks for your response! Sorry for the earlier unclear description.
>
> I agree that the difference in the two protocols (Reno and NewReno) lies
> only in the fast recovery algorithm. I understand that during fast
> recovery, NewReno manages to squeeze in some more packets into the network
> by inflating the congestion window by one packet for every ack arrival. On
> the other hand, Reno stays shuts off temporarily (in terms of new
> transmissions) throughout fast recovery. But the congestion window profile
> extracted from ns3 for Reno indicates a window variation that is similar to
> that of NewReno during fast recovery. Is it not supposed to look like this?

No! There's nothing correct in what you have written, I'm sorry for
being rude but I don't know how I can write it differently.

Shut off temporarily through Fast Recovery ? I don't know your sources,
but this is totally wrong. You have the RFC for :

TCP -------------
Fast Recovery | --> Reno
Fast Retransmit ---
New Reno edit to Fast Recovery

and nowhere is stated that Fast Recovery shuts down the transmission.
Please read again the RFC, on which 5681 is the most important for you.

Nat