July Log Book Entries

<=June August=>

2/7

Jacobson's Congestion Control is now working totally. Going to move onto the Reno implementation next. This is going to require a bit of thought as to where modules are inserted. Add to the fact that Reno is built on by new reno, SACK.... etc.

3/7

Got the algorithms for each Reno module planned. Implementing it now. Since Reno builds on Jacobson's modules I will have to use them too. Hope I didnt make any mistakes in Jacobson's modules.

4/7

Looks good, Reno is going into fast recovery, inflating cwnd when dup acks as required when 3 dup acks are received. Looks like new Reno is next. Going to start drafting and converting the New Reno algorithms into modules.

5/7

Finishing off the algorithms for the new Reno implementation. Hopefully this would work okay when implemented. Going to start converting this into Java code now.

7/7

Finishing off the Java code for new Reno. Testing is going to be more intense, since new Reno builds on Reno which builds on Jacobson. Really hope no errors are in either of those, as this would make a mess of things.

9/7

After some hard debugging, I finally got new Reno working, especially with the persist timer and the other TCP shutting down their receive window in the middle of fast recovery. Argh. Next is SACK TCP. This is going to take MAJOR work as the sender side mechanisms are underfined.

10/7

Argh, I think I have designed an adequate SACK sender side mechanism. SACKed segments are removed from the retransmission queue. In fast recovery, unSACKed segments on the retransmission queue are retransmitted first before new segments. Going to use Sally Floyd's Pipe variable to prevent excessive retransmissions.

12/7

So much programming. I think this is almost the highest number of modules implemented for a Flow Control algorithm so far. Going to start testing now. Going to test each module individually before integrated. Just too much room for error in this one.

14/7

My eyes. Finally got SACK to work after all those errors with the damn SACK blocks in segments. I think there are no errors involved, and everything seemed to look good. But no time to waste, going to hit ECN TCP next. Drafting the algorithms into Java code modules now.

15/7

Finished doing ECN. The ECN TCP algorithm is surprisingly simple and its pseudo code was not too difficult to implement. Only problem was that you cant have both Reno and ECN reducing the congestion window in 1 go. This requires an assumption of where Reno modules are placed. I think the way I did thinks with the wrap around is okay. Testing now.

16/7

Finished testing ECN. Not many errors to correct and now works. Next up is LFN TCP. Out of the 3, I am not sure whether window scaling should be implemented as modules. I mean, doesnt seem to teaching users much about what is going on.

17/7

Finished drafting code for LFN TCP add-ons. Going to start testing LFN RTTM and LFN PAWS. I am not implementing LFN window scaling in module form. Instead I will enforce that in the GUI by allowing users to enter a higher window size then the max 65535 allowed. The GUI can then round the user's input to an appropriate value.

18/7

Finished LFN debugging. Really simple actually. The last TCP variant, Vegas, should now be implemented. This is a big one though. May take some type. But the algorithm is clearly defined so I should be okay. Going to draft the modules now.

20/7

Finished drafting the Vegas modules. Going to start testing, with Slow Start, Congestion avoidance first. Going to use some experimental parameters for a and b and g thresholds just to test the mechanics. I will worry about other the real values used for the Simulator later.

21/7

Finished testing most of Vegas. Even tested it with the retransmission timer granularity for its fast retransmit. Hard to get vegas fast retransmit to work thought, very rarely does it prompt a faster retransmit, usually Reno kicks in before Vegas does. Anyway, this means the TCP Layer development is mostly finished. Going to start designing the real traffic generators now.

22/7

The loss generator super class is mostly designed. I am going with the earlier idea for keeping track of the average loss rate and then scaling the probability used to test for a loss burst. This job will be split into 2 plugins to allow extendability. A dampener and a loss probability scaler plugin. Going to test it.

25/7

The loss generator super class works okay now, the loss probability does self adjust over time so losses produced do converge with the user set average. Pre generated losses are also stored so the delay generator can check for close losses and scale up delays as required. Going to start thinking about the delay generator super class now.

27/7

The delay generator is more tricky then I thought. Most established empirical models only measure the magnitudes of delay. I can just sample from these distributions, but how do I produce bursty delays ? bursts have to be user defined too no doubt. Maybe I can employ something similar to the loss generate and generate delay burst lengths. Then i scale delays inside this burst length with similar magnitudes to produce bursts.

May work, who knows?

29/7

Delay generator mechanics pretty much finalized. The control mechanism keeps track of the average delay produced and scales delay bursts up or down as required. The factors used to scale each delay burst then defines how "bursty" delays are. I have produced some sample data using this scaling process and this seems to work. The user has control over the characteristics of the bursts produced, and also the lengths of each delay burst on average. Going to have to implement and test the actual delay generator super class now.