May Log Book Entries

<=April June=>

1/5

I have converted most of the stuff in RFC 793 into pseudo code form that is suitable for implementation into the TCP Layer. The event handlers for the hand shake procedure also have being implemented seems to work well now, after some initial bugs with the simultaneous situations. Going to code the rest of the pseudo code from RFC 793 into the TCP layer of the simulator next. This is gonna take a quite a bit of debugging. I am a bit scared of coding the sending procedures for forming segments for the SEND primitive, as that is a huge part of flow control.

A bit of good news though, after seeing Jim and talking to him about the TCP basic version implementation, it seems that I probably wont have to bother about the TCP receive primitive as I can assume instant data delivery to the application layer. Probably should have figured that out myself, as the receive primitive has nothing to do with flow control, everything it does takes place after the data has arrived.

Also started reading up papers on how packet loss and propagation delay is modeled. Jim told me that one of the main things he expects from the traffic generators is that the losses AND the delay are going to have to be "bursty" and that their burstiness characteristics will have to be controllable somehow by the user AND that losses and delay be correlated. Also wants a type of control mechanism to ensure that the delay/loss produced randomly by the simulator matches that specified by the user. In addition he also wants a plug and play mechanism for the traffic generators too. Looks like a bit of work will await me in the transmission layer.

Jim also specified to me the general components of loss and delay. While losses are relateively simple (just a loss rate that produces losses in bursts), the delay is the difficult one, the delay has wild variation due to it mainly being the sum of all the queueing delays on the routers between the sender and the receiver. From the sound of this I will probably have to forget about using any structured process to generate delays and go straight for some type of stochastic model. Have to read up more on delay though.

The traffic generation layer is gonna be complex, not only do I have to implement the models used to generate delay, but also a plug and play mechanism for generators as well as some type of correlation mechanism between the loss/delay generators. Icky.

7/5

I need sleep. But the basic version of TCP seems to work okay now. Went through all the pseudo code event handlers and converted them into java code form first. Then started running tests and debugging parts of the handlers. Heaps of bugs to be worked out, many of which was because the pseudo code didn't covert into java that well. I also had to design functions which seemed easy to specify in the pseudo code, but was hell to implement in real code, mostly the segment receiving mechanism and the mechanism used to advance the window base.

Had a heap of trouble debugging the sending and retransmission mechanisms, nearly drove me up the wall - I had this mysterious problem where the RTO calculated values will go into some sort of negative feedback cycle and strangle the simulator by queueing endless segments for send. Took me ages before I found out it was not a bug, but because Karn's algorithm was not implemented and this was an actual problem with early versions of TCP. figures.

Anyway, not that the timers work and the event handlers for the basic version seem okay, have to start thinking heavily about the traffic generation layer as well as the plug and play mechanism. Have to do heavy reading to sketch out some type of model for both.

Good news though, while I went through all that coding, I was thinking possible I can do a simpler coding model for the plug and play mechanism. Instead of doing some weird format to allow flow control algorithms to be plugged in, instead I would abstract TCP event handlers to form code blocks, kinda like lego blocks. These blocks can be modeled as abstract classes that are executed linearly kinda like BASIC on the old computers. Users can then insert blocks in and pull blocks out. That should give freedom to the user as well as providing a general plug and play mechanism. Works well for event handlers too, as I can structure an event handler as a bunch of code blocks.

13/5

Being collating and consolidating all the reading material related to the fields for this project. Gonna start the literature review on this and I have started drafting it. Defined 3 main fields for the review, the TCP versions to be implemented, the traffic models for simulation and simulator structure. I think that covers most of the background for the simulator.

Being working on that plug and play model and on paper it looks like it would work. The best thing is that all the flow control algorithsm in the RFCs are in pseudo code form so they should be easy to convert into code blocks that can be inserted into existing handlers in the simulator. The event handlers I just coded for the RFC 793 basic TCP version should also be easy to convert into this form, all I have to do is cut and paste the java code into these blocks with a few adjustments, so it should be okay. Based on this idea I should be able to start structuring the actual classes used in the TCP Layer itself.

Thinking of doing 3 classes for this, a TCP control block that holds status data just like how real TCP has one, a class that holds and organizes the code blocks into event handler sets so it can receive incoming events and trigger the appropriate set, and finally the blocks themselves. Also needs some type of loading mechanism to load the handlers into the simulator. Going to have to work on that.

16/5

Come up with ideas for the traffic generation layer. From all the papers I have read while doing the literature review about modeling delay and loss on the internet, it seems that the empirical evidence points to a fact that losses causes high delay, but high delay does not necessarily mean loss. So if I generate the losses first and then scale the subsequently generated delay upwards if a loss is generated, then I can obtain a correlation that is independent of the mechanisms used to actually generate the loss and delay. This also leaves the plug and play mechanism also free in the traffic generation layer as I can plug in different models that generated delay and loss differently, and still maintain the correlation mechanism.

Of course the delay/loss generators still have to be implemented. From what I have read, the loss are mostly generated by "bursty" models that model burst length given that a loss happens, or whether a loss occurs at any given time - bursty behaviour then happens by keeping track of previously generated losses and increasing the loss probability for future trials if losses have occurred in the pass. So to implement these models, I will have to find some way of using both types of models.

Delay models are different though, delays are mostly modeled by statistical distributions, ARMA statistical processes or mathematically complex self similar processes. But from what I have read, particularly Paxson's paper on his FFT method of generating approximate self similar traffic, these models are pretty much processing power and time intensive, the faster approximate methods are also unsuitable as they only work if the entire series being generated is in memory. This probably wont work for a Java simulator, as we dun have infinite memory here. The ARMA models may be possible, but the constants for that model are worked out from statistically processing real internet traces and seems a tad troublesome to use for a student playing around to deal with. So my prime candidates for delay generation seems to be statistical distributions like the Gamma distribution. Probably have to read more, but this seems to be the case right now.

Also have to come up with ideas on how a control mechanism can be implemented for both generators though. Particularly something that works for both delay and loss. Urgh.

20/5

Finished the lit review mostly. The exams are coming up but I will take what time I can do work on the project. The classes for the TCP Layer for the plug and play interface are pretty much firmed up. Going to have a TCP control block class, a TCP event handler class that manages all the code blocks and the code blocks forming the event handlers themselves. Need to start to code this and convert all my existing TCP event handlers for the TCP basic version into this module format. Shouldn't be difficult.

On the issue of the delay generators, after talking with Jim, it seems that my guess about the delay generators are pretty much correct. Self similar processes will suck too much processing power to be useful and the faster approximate processes will just cause memory shortages. He thinks the distributions should be okay.

For the loss models I also had a inspiration on how both models can be used, I can just use a method that models burst lengths. Then I just run the loss burst model that models losses at a given give until I get a non loss, and return that as the loss burst length. This should allow both types of loss models to be used.

Still, the control mechanism for both traffic generator types still have to be worked out. I think I have a few ideas on the loss generators, obviously, the probability for a loss burst to occur should be modified over time to ensure that the number of losses generated matches the loss rate entered by the user. So the control mechanism just has to keep a running average of losses and adjust the loss burst rate as necessary.

Probably can apply that idea to the delay, keep a running average of delays and then scale the delays up or down as required to ensure that the real average delay matches that specified by the user.

Oh well, have to concentrate on the exams first. Probably wont do the control mechanisms for the generators until I actually implement the generators themselves. I can just have placeholders currently inserted into the traffic generation layer for testing the plug and play TCP layer . Once I finish the plug and play mechanism and implementing all the different TCP versions, then I will tackle the traffic generators. That seems like a task for the holidays.