TCP Tahoe only? ns-3 questions

[Justin P. Rohrer]

I have a couple of questions regarding the TCP implementation in
ns-3. Setting aside the NSC project for a moment, it appears that the
only TCP variant currently available is Tahoe? Are there plans for
other variants (New Reno, CUBIC, Vegas, etc) in the future?

My interest is in generating HTTP transactions over TCP connections,
but so far I have not been able to figure out how to do bi-directional
data transfer over a single TCP connection. Is there an example of
how to do this or has it not yet been addressed?

Regarding the NSC project, is the intention to have that replace the
TCP code in the built-in internet stack for all but the simplest
transport-layer simulations, or are both approaches going to receive
equal development emphasis going forwards? Would I be better off
looking at the NSC for a solution for doing bi-direction data flow
over a single TCP connection?

Thank you for your input.

Justin P. Rohrer
The University of Kansas

[Raj Bhattacharjea]

On Nov 21, 12:02 pm, "Justin P. Rohrer" <roh...@gmail.com> wrote:
> I have a couple of questions regarding the TCP implementation in  
> ns-3.  Setting aside the NSC project for a moment, it appears that the  
> only TCP variant currently available is Tahoe?  Are there plans for  
> other variants (New Reno, CUBIC, Vegas, etc) in the future?
>

This is correct, Tahoe is presently the model used. There are plans
however to port the GTNetS implementation of Reno and New Reno into
ns-3. As far as other variants, as far as "native" implementations go
(those not related to NSC), there are no immediate plans.

> My interest is in generating HTTP transactions over TCP connections,  
> but so far I have not been able to figure out how to do bi-directional  
> data transfer over a single TCP connection.  Is there an example of  
> how to do this or has it not yet been addressed?

Bi-directional data transfer is in fact possible with the current TCP
model. As far as HTTP goes, I started down this road myself some
months back. In particular, please see the two following changesets
of my experimental branch:
http://code.nsnam.org/raj/ns-3-dev-http/rev/b017f1ef51fc
http://code.nsnam.org/raj/ns-3-dev-http/rev/497d9c551235

This is as close to an example as you will find currently. I will
take some time to add a bidirectional TCP example to the codebase
soon.

>
> Regarding the NSC project, is the intention to have that replace the  
> TCP code in the built-in internet stack for all but the simplest  
> transport-layer simulations, or are both approaches going to receive  
> equal development emphasis going forwards?  Would I be better off  
> looking at the NSC for a solution for doing bi-direction data flow  
> over a single TCP connection?
>
> Thank you for your input.
>

The NSC support in ns-3 is NOT intended as a replacement for the
native TCP models. The intention is to support both equally. The
"native" models are more readable and more easily modified than the
actual Linux/BSD kernel code. I always imagined people doing research
into new TCP models would work with the native style models before
developing a full blown patch to the Linux kernel. The NSC code is
for those who want to perform more "real-world" simulations using real
implementations of existing transport protocols, instead of those
wanting to simulate new experimental protocols.

That said, the bi-directional data flow should be equally easy using
either NSC or the ns-3 models. The basic idea would be to just call
"send" on whichever socket you please, in a way which is consistent
with your application model.

You can do a quick bidirectional test by just scheduling "send" at
different points in time on the two sockets, i.e. ScheduleNow
(Send,s1,"How are you?",...), Schedule(delay,Send,s2,"Fine, thanks,
and you?",...); In this case you should see data and acks coming and
going in both directions.

To implement some kind of message/response semantics, you could do the
following (similar to what I do in my ns-3-dev-http branch):
* Create, bind, and listen a server socket.
* SetRecvCallback on server socket to something that will read/parse/
react appropriately your application level semantics.
* Create, bind, and connect a client socket to the server IP/port.
* SetConnectCallback on the client socket to something which will send
the first message on connection success and begin the application
layer message exchange.
* SetRecvCallback on the client socket to something that will read/
parse/react appropriately your application level semantics.

Two sockets with the right callbacks in those places should chatter
back and forth.

Create, bind, and connect a client socket to the server IP/port

[Asifuddin]

I was going through the patch and examples.
I have added the patch and used the example program.It worked
perfectly.
I was wondering why the patch has not been added in the latest
release.
Is the patch not complete or is there any wrong with it ?

Thank you

Asifuddin




On Nov 25, 5:03 pm, Raj Bhattacharjea <rbhattachar...@gmail.com>
wrote:

> On Nov 21, 12:02 pm, "JustinP. Rohrer" <roh...@gmail.com> wrote:
>
> > I have a couple of questions regarding the TCP implementation in  
> > ns-3.  Setting aside the NSC project for a moment, it appears that the  
> > only TCP variant currently available is Tahoe?  Are there plans for  
> > other variants (New Reno, CUBIC, Vegas, etc) in the future?
>
> This is correct, Tahoe is presently the model used.  There are plans
> however to port the GTNetS implementation of Reno and New Reno into
> ns-3.  As far as other variants, as far as "native" implementations go
> (those not related to NSC), there are no immediate plans.
>
> > My interest is in generating HTTP transactions over TCP connections,  
> > but so far I have not been able to figure out how to do bi-directional  
> > data transfer over a single TCP connection.  Is there an example of  
> > how to do this or has it not yet been addressed?
>
> Bi-directional data transfer is in fact possible with the current TCP
> model.  As far as HTTP goes, I started down this road myself some
> months back.  In particular, please see the two following changesets

> of my experimental branch:http://code.nsnam.org/raj/ns-3-dev-http/rev/b017f1ef51fchttp://code.nsnam.org/raj/ns-3-dev-http/rev/497d9c551235

[Raj Bhattacharjea]

On Dec 28 2008, 5:21 pm, Asifuddin <asif4...@gmail.com> wrote:
> I was going through the patch and examples.
> I have added the patch and used the example program.It worked
> perfectly.
> I was wondering why the patch has not been added in the latest
> release.
> Is the patch not complete or is there any wrong with it ?

The changes I made are very much incomplete and untested. I don't
even know if the code produces standards compliant HTTP, (i.e. I'm not
sure the request/response formats are correct).

I would like to see any work you have been completing with HTTP, and
would gladly provide comments and could help you move forward on
merging any useful code into the next ns-3 release.