[Ns-developers] Summer of Code nsc/ns-3 integration status, week 04

[Sam Jansen]

2008/5/19 Florian Westphal <fw at strlen.de>:

> Hello everyone,
>
> During last Tuesdays IRC meeting it was suggested that I send
> Summer of code ns-3/NSC status reports to the mailing list instead of
> mailing them to Sam, so here it is...
>
> During last week I finally got two of the examples
> (tcp-large-transfer and tcp-point-to-point) to work.
> By 'to work' I mean that you'll get a proper trace file, including
> handshake, data transfer and connection shutdown.
> The tcp-large-transfer looks a little bit odd at first
> (dupacks, retransmits,...), but I'm sure this is caused by ns-3 rather
> than NSC (tail drop?).


It's probably overflowing the NIC queue. We can talk some other time about
correct NIC <-> stack interactions, its fairly low priority to get things
working. For things to work like a real stack, there needs to be some
feedback from the driver to the stack. This is accomplished by
if_send_finish() in NSC.



> In any case, all data appears to be
> sent/received correctly.  I've uploaded two traces here
> (nsc 0.3.0, Linux 2.6.18):
>
> http://www.strlen.de/nsc/tcp-large-transfer-0-1.pcap.bz2


I had a look at this; it looks good.


> <http://www.strlen.de/nsc/tcp-large-transfer-0-1.pcap.bz2>
> http://www.strlen.de/nsc/tcp-large-transfer-2-1.pcap.bz2


> Basically, at the moment, my ns-3-nsc repo[1] is a single hack fest held
> together with a soldering iron and lots of duct tape...
> The NSC glue is spread all over tcp-socket.cc and tcp-l4-protocol.cc.
> This has major disadvantages:
>
> 1. There are two TCP/IP headers: One added by ns-3, one by NSC
>
> This prompts yet another kludge (pcap-writer.cc skips the first 40
> bytes, otherwise the generated trace files are useless)
> Even worse: This increases packet size by 40 bytes.
>
> 2. Active sabotage in ns-3s TCP stack (i.e. everything is redirected to
> NSC)
>
> 3. The endpoint can accept() the connection, but leaks its listening
> socket.
> Now, I've already looked at TcpSocket::CompleteFork, but I'd rather not
> go down this road because I very much doubt that the current approach
> is the right thing.
>
> Rather, I'd like to take three steps back and try to figure out
> how this should be implemented properly, so that it will at least
>
> a) have a good chance to (eventually) get merged into ns-3
> b) avoid all the 'two tcp headers' hassle
>
> Since from ns-3s point of view NSC is essentially a black box that
> sends/receives user data and IP packets, I think that the NSC glue
> should live in separate classes, namely
>
> a) an "nsc-ipv4" implementation that basically sits next to
> ipv4-l3-protocol.cc
> b) a "nsc-socket.cc" that provides the needed socket API wrappers.
>

Exactly. I guess nsc-socket.cc would be the wrapper around NSC's
INetStreamSocket class and the other .cc file would wrap the stack itself?


>
> Comments? Thoughts?
>

Now that you have experience at getting it all working, I'd encourage you to
sketch out a design of integration and share it with this list for
discussion. You've probably realised that the actual amount of glue code to
make NSC work is rather small, but there are quite a few details to get
right to make the design sensible.


>
> Thanks,
>        Florian
>
> [1] http://hg.strlen.de/cgi-bin/hgwebdir.cgi/ns-3-nsc/
>