April Log Book Entries

<=March May=>

5/4

I think I have narrowed down the important TCP versions. Have talked with Jim, and he seems to think this list is okay. Have to look further just to be sure, but basically

Tahoe - RFC 793 TCP + Jacobson's algorithms + Karns and Nagles and SWS
Reno - Tahoe + Reno fast recovery
New Reno - Reno + new Reno Fast Recovery
SACK - A bit hazy here, u have Reno + SACK, but then some papers, mainly sally floyd, talks about SACK being for Reno AND new Reno. Seems SACK implementation for the sender is rather loose, as long as the mechanism uses SACK blocks from the receiver to save on retranmissions in some way, it can be seen to be a proper SACK sender mechanism. Looks like I may have to make something, or just use the scheme mentioned in Sally Floyd's paper.
LFN - Window Scaling, PAWS and RTTM Long Thin Pipes - Not sure about this one, its New Reno, SACK and increased initial window (not much change, to 2-3 segs) but much of this stuff is covered about, just placed together in different combos. Dunno if include this one.
ECN - ECN TCP, can be used with any TCP versions it seems, as long as TCP reacts to a congestion marked incoming segment "as if" the segment is lost to reduce sending rates. How to do this ?
Vegas - New Reno + some novel stuff to overcome implementation problems of normal Jacobson, mainly the coarse grain timer. Also measures throughput to adjust cwnd instead. Some papers disagree that improvements are from the new cwnd adjustment mechanism, but mostly from the fast retranmssion due to the coarse grain timer.

Also regarding the Plug and Play, Jim suggests a state map approach of some type after I told him I had no luck in attempting to find some common ground that links all TCP flow control algorithms so I can devise a "abstract" type of flow control algorithm. Have to think more about this and study the TCP algorithms some more.

10/4

Have started designing the simulator structure - after reading some articles what how current simulators are structured, I think I will follow what they do and use a TCP stack like structure. Seems natural and saves me the trouble of designing a simulator structure that's flexible and customizable. So I will use a layered structure. All the TCP simulation mechanism can be stuck in the TCP Layer, the bottom layers can be abstracted to form some layer that generates traffic conditions, while the higher app layers can be used to simulate applications ? or maybe I take it off ?

Anyway, using this structure, I think I can get onto working out the actual core engine of the simulator and leave the TCP simulation plug and play stuff and traffic generation stuff till later.

Gonna use Java to do this simulator, not only do I have experience in it, it has good GUI libraries and runs of a virtual machine which allows the simulator to be run anywhere - being a simulator I am not too tight on processing speed and power so I can probably get away with it.

Thinking of using a discrete event serial model, was considering allowing parallel via java threads but that brings up all types of synchronization problems. Also no point really, the flow control operations are inherently serial algorithms and even if they are allowed to operate in parallel it doesn't do any benefit.

Anyway, starting to program now, read up some more on java threads and such. If I am using a serial model I probably just use one thread to drive the entire engine. The GUI will probably use its own threads though. Need to experiment.

17/4

Designed three engine components - since TCP is event driven anyway, with RFC 793 basing all its recommended algorithm implementation as event handlers, gonna base my simulator engine around being event driven. Events will be represented as objects which are queued in a event queue object, a timer engine type object then increments a time counter and executes the event objects queued up as time increments. Provided that each qevent has a reference their own event handler in the TCP layer or the traffic layer, this engine model should be general enough to handle any type of event I can program into it. So this structure should be okay.

Anyway, need to firm up all the methods for each class and experiment with the settings to see whether the speed is okay. But so far it looks good.

25/4

The engine should pretty much be done, the scheduling of events work in the event queue and the timer engine runs at a good constant pace to dispatch those events. Gonna implement the TCP Layer next.

After reading a lot of the RFCs, the way I am going to approach it is to implement the basic version of RFC 793 first and try to get the handshake stuff working under robust conditions before I implement segment retransmissions. All the other TCP versions to be simulated will be built on top of that basic version. Since RFC 793 phrases all its algorithms in the form of event handlers, I am going to implement TCP as a series of event handlers in the TCP Layer. Those event handlers will trigger when events are dispatched by the timer engine. So TCP will react when the user issues a primitive, which will schedule an event for execution, and in turn cause an event handler to activate in the TCP layer. TCP then self reacts as it generates more events that triggers more handlers, and so on.

After talking with Jim, this seems okay. But I honestly still don't know how to do the plug and play thing for the TCP layer though, after reading all the algorithms I am quite sure now that trying to define some "common" tcp flow control component is futile as virtually anything can be a flow control algorithm - there are no established or standardized operations or a "interface" definition that can be used as a basis of abstraction. I also gave Jim's suggestion of a state map approach a whirl, after thinking a bit about it conceptually it would work. I am a bit hesitant though, the thought of defining state maps and making up states to implement algorithms seems a bit clumsy to me, I mean all the algorithms defined in RFCs are done via pseudo code, anyone trying to implement a version of TCP into the simulator will have to make up a state map and transitions. This is not easy to do. But I will try it after I get the basic TCP version working.