Changing TCP congestion control in NSC at runtime

[Chris Facchini]

Hi,

I would like to change the TCP congestion mechanism (in NSC) in the
middle of a simulation.
So, I modified the example script 'tcp-nsc-lfn.cc' by adding the
following line:
Simulator::Schedule (Seconds (runtime/2.0), &Config::Set, "/NodeList/
*/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_congestion_control",
StringValue ("vegas"));

which should force all nodes to adopt the Vegas algorithm at "runtime/
2" seconds.
The resulting trace, however, is identical to the trace I get when I
run the original script.

Am I going wrong somewhere, or is it impossible to switch the TCP
congestion algorithm at runtime?
If it is impossible, how could how achieve a similar effect?

Best,
Chris

[Chris Facchini]

A little update.
Hope it will help others.

> So, I modified the example script 'tcp-nsc-lfn.cc' by adding the
> following line:
>   Simulator::Schedule (Seconds (runtime/2.0), &Config::Set, "/NodeList/
> */$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_congestion_control",
> StringValue ("vegas"));
>

> Am I going wrong somewhere, or is it impossible to switch the TCP
> congestion algorithm at runtime?

Using Config::Set on the nsc stack (like in the example above) will
trigger a call to sysctl.
Sysctl actually sets the variable in question. However, as far as I
understood, it affects any connection created *after* the instant in
which the setting happened.
I've tested this behavior when trying to dynamically change
net.ipv4.tcp_congestion control (which eventually calls <nsc>/<linux>/
kernel/sysctl.c:sysctl_string()) and net.ipv4.tcp_sack (which ends up
calling <nsc>/<linux>/kernel/sysctl.c:sysctl_data()).

> If it is impossible, how could how achieve a similar effect?

This question remains open :)

Chris

[Tom Henderson]

Can you clarify what you want to have happen? Do you want to change
congestion control of active sockets, or is it adequate to change the
algorithm for all subsequently created sockets?

[Chris Facchini]

Hi Tom

On Nov 19, 4:46 pm, Tom Henderson <t...@tomh.org> wrote:
> Can you clarify what you want to have happen?  Do you want to change
> congestion control of active sockets, or is it adequate to change the
> algorithm for all subsequently created sockets?

What I wanted to do was to change the congestion control of active
sockets.
Now, however, I am more interested in changing singular parameters of
active sockets (here for additional information:
http://groups.google.com/group/ns-3-users/browse_thread/thread/d0ee28cd2578dc9
).

Best,
Chris

[Tom Henderson]

On Nov 19, 8:03 am, Chris Facchini <c.facch...@gmail.com> wrote:

> active sockets (here for additional information:http://groups.google.com/group/ns-3-users/browse_thread/thread/d0ee28...
> ).
>

Chris, I wanted to point you to some more related work that might give
you some ideas. David Wei wrote the TCP-Linux module for ns-2:
http://netlab.caltech.edu/projects/ns2tcplinux/ns2linux/tutorial/index.html

See, in particular, "Change parameters of Linux congestion control
modules in TCP-Linux simulations". Maybe by looking at how that is
implemented, you might get an idea of how to do it in nsc, since David
used the underlying Linux code. In linux, the congestion control is
governed by a structure of function pointers (tcp_congestion_ops) so I
don't know whether there might be a way to dynamically repoint to a
different struct.

- Tom

[Chris Facchini]

On Nov 19, 5:23 pm, Tom Henderson <t...@tomh.org> wrote:
> Chris, I wanted to point you to some more related work that might give

> you some ideas.  David Wei wrote the TCP-Linux module for ns-2:http://netlab.caltech.edu/projects/ns2tcplinux/ns2linux/tutorial/inde...

Based on what I understood, TCP-Linux defines some structures that are
convenient for accessing the parameters of TCP congestion control
algorithms, namely cc_param_list and cc_list (ns/tcp/linux/ns-linux-
util.h).
I have the feeling that such structure are initialized when calling
module_init() (in ns/tcp/linux/ns-linux-c.h). Said macro, through a
chain of function calls, eventually calls record_linux_param() which
(I suppose) sets the parameters that can be later adjusted.
Though there is no such thing in nsc, I'd say it might be feasible to
do something similar.

The key point is another, I think. TCP congestion algorithms (and
parameters in general) can be set from ns-2 scripts through
LinuxTcpAgent::command (tcp-linux.cc). You need, however, a "tcp
instance" on which to invoke it.

So, maybe a basic question is: how can be "tcp instances" be accessed
from the simulation script in ns-3?
I guess such "tcp instances" correspond to NscTcpL4Protocol objects.
Do you agree?
In such case, how could I get a hold of it, for example starting from
an Application instance?

Best,
Chris