Sam’s Network Simulation Cradle Blog

ns-2 has some basic web traffic models that seem to be a SURGE implementation. Coding wise they are a bit nasty, with callbacks to OTcl from C++ everywhere. I imagine that has a significant performance impact? But lets ignore that, it isn’t critical.

The models seem to work fine with the normal one-way TCP, but get some nasty errors when using FullTcp.

0.100090: FullTcpAgent::recv(_o659): bad ACK for our SYN:  [24:2.1>0.1] 
(hlen:40, dlen:0, seq:1002, ack:2, flags:0x18 (<PSH,ACK>), salen:0, reason:0x0)
0.100120: FullTcpAgent::recv(_o660) got packet lacking ACK (state:3):  [29:0.1>2.1] 
(hlen:40, dlen:0, seq:2, ack:0, flags:0x0 (<null>), salen:0, reason:0x0)

While I often try and stay away from the FullTcp-based models, I see it as a requisite when:

1. We are doing bidirectional data transfer – the request has a size too!
2. The unidirectional TCP models don’t segment data over packets properly. Each data packet is always full size. So if the MSS is 1000 and you want to send 1001 bytes, you end up sending two full size packets. This seems quite ridiculous to me and makes it very hard to control the presented load on the network.

So I wrote my own SURGE based model in C++ for ns-2. I stayed away from OTcl. It seemed to be working fine, then I wanted to add the functionality of actually doing a connection establishment for every page and object. Or at least every page. Connecting is easy, it is the disconnecting that is annoying. The API is not exposed to C++ and then the entire process seems very buggy. I just want my FullTcp agent to disconnect properly and reset itself so it may be re-used for the next connection. But no, trying to get the combination of FINS correct seems to be very hard. I don’t know what the FullTcp agent is doing, but it looks very wrong. A way to get around this problem is just to keep allocating new TCP objects whenever a new connection is required. This is how the other model works as far as I know. Seems like a silly solution when you could just reuse the existing stuff.

This was supposed to be an easy activity I would have coded up quickly this morning. It is now almost 2pm and I don’t have a good answer.

Someone should get some real world network stacks that work properly, and put them in a network simulator. Wouldn’t that be a good idea!

Enough of the non-CS related stuff for now.

A paper on statistical distributions for traffic generation in simulation. Well, talks about generating self-similar traffic in network simulation and compares some methods.

Just some stuff as I sit back after a days cricket and drink a bottle of cheap Sauvignon Blanc.

Interesting paper with, at very least, some good quotes: Simulation studies of Gigabit ethernet versus Myrinet using real application cores

The last sentence of this paper is quite classic: Simulation and Evaluation for a Network on Chip Architecture Using Ns-2. Quotation: “However, generating message traffic synthetically, corresponding to real applications is an important but hard open problem.”

Some random thoughts: Perhaps there is something to be drawn from earlier ATM work here, surely researchers would have gone through a similar process designing ATM switches? Cambridge would be the place with the knowledge about such… Found lots of papers on “on-chip switched interconnects”. Maybe that is another area we can draw some knowledge from.

ISCC looks like a vaguely interesting conference.

Problem statement: In my distributed simulation program, I have the problem of keeping the clients synchronised with the server: the clients and the server share a directory hierarchy which contains files that describe a number of simulations.

Previous solution: Previously I had written some code to integrate with subversion. So when you connect as a client, you run svnversion . to figure out what version you are and send that information in your “hello” message. The server checks this, and if it is older than server’s revision, the client is told to update its repository. The client runs an svn update, then attempts to reload its python code. The most important bit is that the simulations are now up to date, or in sync, with those on the server.

One problem with this is that the client machines need subversion installed. Subversion isn’t quite ubiquitous yet, so this is a very real problem. The second is that you need network access for the subversion client and said subversion client needs to be able to authenticate with the server. In the past this has been OK due to the setup of the machines I was working with. However, these two problems are very real and you can’t always get around them easily.

New solution: I no longer care about updating the python code for the simulation client running, this isn’t liable to change (it has existed for some time now and I hardly ever change it) and it already has versioning for the protocol. I concentrate instead on making sure the simulations are up to date. Conceptually, doing this is very easy:

1. Client is sent the name of a simulation to run by the server (as before).
2. Client md5sums all files pertinent to the simulation and sends back a list of (file, md5sum) tuples.
3. Server checks this against its own files. If it matches, it sends back a “md5sum OK” message, else it finds the files that don’t match, gzips them, and sends them back in (file, gzipped file, umask, digest) tuples.
4. If the client receives an “OK” message, it notes that this simulation is in sync, and requests another simulation.
5. If the client receives a list of files, it saves them locally into its directory hierarchy. It is able to check their integrity by the digest sent back, but in practice I don’t bother. It then requests another simulation.

Whenever a simulation is started, the clients are alerted of possible new simulations. They then clear their cache of simulations they believe to be up to date.

This works nicely because the files that describe a simulation are fairly small and we don’t care too much about efficiency of the network protocol. A lot of the time this runs over LANs anyway.

So?

Now, the point of this article isn’t to describe the above per se, that is nothing special. It is like a very stunted rsync algorithm that sucks big time.

The cool thing, is that coding the above in Python was so incredibly easy! The standard library does all the things like md5 and gzip. And I already had a framework set up in my system based upon the asyncore/asynchat modules. So plugging this all in was so very easy. I made a few typos and small logical errors, but a bit of testing ironed these out and it all goes now.

Thanks Python!

So if we are to simulate some random optical switch, what sort of simulation scenarios do we want to understand how this switch works and scales?

In designing simulations it is interesting to compare and contrast such a switch to a traditional electronic switch. Such electronic switches are commodity devices these days and are fairly well understood. My current thoughts are that we need to have a good idea of the differences between such an electronic switch and an optical switch. This will allow us to do several things:

• Reason about results
• Create simulations that show/test the perceived differences

I’m sure there is more to write here but that is an alright start.

Right, so my optical simulation stuff is basically going.

In an attempt to debug it, I thought I would generate a NAM trace. Due to the high bandwidths encountered, the NAM trace ended up being 2GB for just 5 seconds of traffic.

I fixed NAM so it understood nanoseconds first. Then tried using it. Not much use. The output window was hopelessly cluttered by the buggy LAN drawing. So I thought, “I’ll hack the file so it just draws normal nodes, instead of special LAN stuff.”

The problem: I need to edit a 2GB text file. I tried in this order:

vim, emacs, nedit, nano, kedit

They all failed, to cut a long story short. I think the way to do this is extract the part of the file you care about, edit it, then compose the original file back together somehow. In the end I tried using sed, which kind of worked, but was too much hassle to use to do the editing I wanted.

When simulating with the LAN stuff in ns-2 (the wireless stuff uses some of the same structure too), the physical layer is simulated with the Phy class. This had a bandwidth_ field which I naturally assumed was the bandwidth for the physical layer!

Nope. Looks like the actual bandwidth_ used is in the Mac class. I spent quite some time playing around with the bandwidth stuff in my new physical layer and was wondering why it wasn’t effecting the simulation at all. Put in quite some debug code and went about chasing red herrings.

Thank you ns-2.

Seems to be like the bandwidth should be in the Phy. I’m going to have to make my own Mac sometime soon anyway, so I have the choice which bandwidth parameter to use!

Wavelength striping and reassembly is working in Phy/SwiftPhy. The logic used to do reaasembly will need revisiting, need to check how this works in the real thing.

Delay set in the newSwift function or via SwiftNode set delay_ foo sets the delay_ variable of the LL (link layer). The delay_ in the Channel (or really Channel/SwiftChannel) seems to be 0.

Mac/Simple is possibly what we want to begin with. It just sends a packet if it can and receives a packet if it can. Basically, it handles serialising the packet and dropping any packets that come in when in the process of serialising. This is worth revisiting at a later point, but it sounds good so far.

Changing MAC from Mac/802_3 to Mac/Simple increased the RTT by a couple of ms. That shouldn’t happen! …….. Mac/Simple sucks, it adds a huge jitter in when sending to try and avoid collisions – it was over a millisecond on my 1Gb or 800Mb link, not sure which. Even when hacked to have no jitter, it is still 500us slower than Mac/802_3. Haven’t investigated why yet, and I see no reason to – I might as well go ahead and start implementing my own MAC (was going to eventually anyway). To begin with it will be even simpler than Mac/Simple. Actually, just simple Mac will do for now.

Why isn’t Phy::recv virtual?!?!?!?

I’m going to have to hack it so it is.

Step 1

• Implement a framework that allows multiple wavelengths (virtual links) from a node connected to a switch.
• Make it so we can tune the bandwidth (800Mb/s to begin with) and propogation delay (this one will be rather tiny)

I needed some way to organise my notes again. So I turned back to my trusty blog. Since I’m working on optical networking related stuff, I thought I’d even call the category Optical Networking.

At the moment I’m looking over a journal publication titled, “Labeled Optical Burst Switching for IP-over-WDM Integration.” This was written back in 2000. It states “one major challenge is the current lack of optical random access memory.” You can say that again! In fact, we are looking at a completely bufferless network in the work I’m doing.

The next challenge is stated so: “Another major challenge is the stringest requirement for synchronization, both between multiple packets arriving at different input ports of an optical switching fabric, and between a packet’s header and its payload.”