TcpTahoe and TcpReno removed? , and TCP when path lengths change

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

TcpTahoe and TcpReno removed? , and TCP when path lengths change

Ben Newton
Can someone help me understand why TcpTahoe and TcpReno were removed from
ns-3 in the latest release.  Was it because they weren't a good fit for the
changes in the API, or because they're no longer really used, or something
else.

Also, I have a high-capacity network simulation and a routing protocol that
can adapt quickly to changes in the physical topology.  Unfortunately, when
the there is a change in the path length for a flow, this causes packets to
arrive out of order, and produces duplicate acks.  This in turn causes TCP,
which assumes the cause is congestion, to shorten the congestion window,
causing a drop in throughput.

Does anyone have a suggestion on how to get a high-rate flow to be able to
succeed in this environment?   How does multipath handle this?  Any
suggestions would be appreciated.

Thanks,
    Ben
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TcpTahoe and TcpReno removed? , and TCP when path lengths change

Natale Patriciello
On 18/02/17 at 11:50, Ben Newton wrote:
> Can someone help me understand why TcpTahoe and TcpReno were removed from
> ns-3 in the latest release.  Was it because they weren't a good fit for the
> changes in the API, or because they're no longer really used, or something
> else.

Hi Ben,

The difference between NewReno, Tahoe, and Reno is only in the part that
goes after the reception of the 3rd duplicated ACK and the complete
recovery, or an RTO. So, to make a long story brief, to advance the TCP
implementation we (but in reality it was me, so you know who to blame)
decided to have one Fast Recovery phase for all the algorithm, like
Linux. Now, I have in mind to separate it again, and to insert this
phase in the congestion control again. In reality, I have everything in
mind (a thesis of a student gave me some ideas) but no time to do it..
if someone wants to take this job, he/she will be more than welcome. The
objective is to bring back these two, very old and unused, congestion
control (but for research they could be good to show the things in the
'90 :]).

> Also, I have a high-capacity network simulation and a routing protocol that
> can adapt quickly to changes in the physical topology.  Unfortunately, when
> the there is a change in the path length for a flow, this causes packets to
> arrive out of order, and produces duplicate acks.  This in turn causes TCP,
> which assumes the cause is congestion, to shorten the congestion window,
> causing a drop in throughput.

Can I ask what routing protocol is ? Because I have done a very similar
work to yours, maybe you can get some ideas from there [1].

> Does anyone have a suggestion on how to get a high-rate flow to be able to
> succeed in this environment?   How does multipath handle this?  Any
> suggestions would be appreciated.

Multipath TCP handles the path diversity at the endpoint
(such as 5G/WiFi), not inside the network. For your problem, I would
suggest to try out SACK, which enhances the recovery phase, which is
currently in ns-3-dev. You can also try BBR, which will probably be the
standard for the future, but right now it is only in the Linux kernel.
Generally, I would suggest to try out DCE if you are not researching at
the TCP level. Their implementation is years ahead.


Have a nice day

Nat


[1] http://ieeexplore.ieee.org/abstract/document/7763187/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TcpTahoe and TcpReno removed? , and TCP when path lengths change

Ben Newton
Natale,
   Thank you for your quick response.  I appreciate the explanation about
the removal of Tahoe and Reno.  I assumed the reason was something like
that.

As for the routing protocol, I'm using a new Geographic Routing protocol
I've developed similar to GOAFR+, but handles dynamic topologies and uses
local topology info, etc.   Thank you for the reference. I'll take a look
at it.

I'll also look into BBR and DCE.

Does DCE add to the simulation time?

Thanks,
  Ben


On Sat, Feb 18, 2017 at 1:32 PM, Natale Patriciello <
[hidden email]> wrote:

> On 18/02/17 at 11:50, Ben Newton wrote:
> > Can someone help me understand why TcpTahoe and TcpReno were removed from
> > ns-3 in the latest release.  Was it because they weren't a good fit for
> the
> > changes in the API, or because they're no longer really used, or
> something
> > else.
>
> Hi Ben,
>
> The difference between NewReno, Tahoe, and Reno is only in the part that
> goes after the reception of the 3rd duplicated ACK and the complete
> recovery, or an RTO. So, to make a long story brief, to advance the TCP
> implementation we (but in reality it was me, so you know who to blame)
> decided to have one Fast Recovery phase for all the algorithm, like
> Linux. Now, I have in mind to separate it again, and to insert this
> phase in the congestion control again. In reality, I have everything in
> mind (a thesis of a student gave me some ideas) but no time to do it..
> if someone wants to take this job, he/she will be more than welcome. The
> objective is to bring back these two, very old and unused, congestion
> control (but for research they could be good to show the things in the
> '90 :]).
>
> > Also, I have a high-capacity network simulation and a routing protocol
> that
> > can adapt quickly to changes in the physical topology.  Unfortunately,
> when
> > the there is a change in the path length for a flow, this causes packets
> to
> > arrive out of order, and produces duplicate acks.  This in turn causes
> TCP,
> > which assumes the cause is congestion, to shorten the congestion window,
> > causing a drop in throughput.
>
> Can I ask what routing protocol is ? Because I have done a very similar
> work to yours, maybe you can get some ideas from there [1].
>
> > Does anyone have a suggestion on how to get a high-rate flow to be able
> to
> > succeed in this environment?   How does multipath handle this?  Any
> > suggestions would be appreciated.
>
> Multipath TCP handles the path diversity at the endpoint
> (such as 5G/WiFi), not inside the network. For your problem, I would
> suggest to try out SACK, which enhances the recovery phase, which is
> currently in ns-3-dev. You can also try BBR, which will probably be the
> standard for the future, but right now it is only in the Linux kernel.
> Generally, I would suggest to try out DCE if you are not researching at
> the TCP level. Their implementation is years ahead.
>
>
> Have a nice day
>
> Nat
>
>
> [1] http://ieeexplore.ieee.org/abstract/document/7763187/
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TcpTahoe and TcpReno removed? , and TCP when path lengths change

Natale Patriciello
On 18/02/17 at 02:09, Ben Newton wrote:
[cut]
> I'll also look into BBR and DCE.
>
> Does DCE add to the simulation time?
>

Hi Ben,

I'm not completely sure about what you're asking, but DCE is fully
integrated in the simulator (it means that you can use the time you
wish, i.e., real time or simulated time).

Unfortunately, it is not included by default in ns-3-dev. For more
informations, please look here:
https://github.com/libos-nuse/net-next-nuse

Nat
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TcpTahoe and TcpReno removed? , and TCP when path lengths change

Tom Henderson-2
In reply to this post by Ben Newton
On 02/18/2017 11:09 AM, Ben Newton wrote:
>
> I'll also look into BBR and DCE.

Ben, I believe that BBR patches are only for Linux kernel 4 series,
which DCE does not yet support (upgrading DCE support is one of our
suggested summer projects, by the way, if there are any takers).

- Tom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TcpTahoe and TcpReno removed? , and TCP when path lengths change

Tom Henderson-2
On 02/20/2017 06:46 AM, Tom Henderson wrote:
> On 02/18/2017 11:09 AM, Ben Newton wrote:
>>
>> I'll also look into BBR and DCE.
>
> Ben, I believe that BBR patches are only for Linux kernel 4 series,

To perhaps clarify this further, the net-next-sim sim-ns3-dev-branch
suggests support for version 4.1 (in the Makefile), but BBR patches
depend on version 4.9 or later.

- Tom
Loading...