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

[Florian Westphal]

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?). 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
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.

Comments? Thoughts?

Thanks,
	Florian

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