March Log Book Entries

16/3

Started thinking about what is involved in making a TCP simulator. Highlighted the fact that emphasis is on flow control - the simulator will be a teaching/demonstration tool and so visualization is IMPORTANT.

Main requirements are to simulate the traffic conditions and different TCP variants. The traffic conditions are mainly 3 factors

RTT or propagation delay

Need some type of statistical model to do this, or some type of generator.

Packet loss (% or something)
Some type of average rate with "bursty" characteristics ?!
Bandwidth, transmission speed of the link

Plain value of some type

Aside from that, must also simulate different TCP variants. What TCP variants to simulate needs to be looked at.

21/3

TCP variants - the sheet gave three examples, but from me talking with Jim its clear that more are needed. Obviously the 3 he mentioned, namely

Reno
New Reno
Long Fat Pipes

must be included. Will have to do research on all possible TCP variants and pick out the main ones which he, as a lecturer who may use such a teaching tool, should be included.

Also the visualization of the simulator - precisely what aspects are should be visualized ? End to End packet dynamics ? packet by packet operations ? What does this mean precisely ? Obviously special emphasis is placed on FLOW CONTROL, but what precisely is this ? Some special component in all TCP variants? Or just some common name for something? Will have to look up.

24/3

Did some research on TCP variants, apparently all "official" TCP versions are listed as RFC standards. Research will start off RFC 793 which defines the base TCP version. This RFC has all the basic algorithms on TCP. Apparently, if you want something to be "TCP", it has to conform to the basics of RFC 793 or the more updated RFC 1122. Will have to dissect these RFCs and see what makes TCP tick.

Also packet to packet dynamics, if people want to LEARN flow control, then some visualization or packet behavior that's visualized will have to be included.

Possibilities - packets flying across the screen ? slowly ? fast ? their speed based on flow control ? what about other info ? windows ? what's important ?

27/3

Did some research and listed the TCP extensions which build off RFC 793. May have to weed out a lot of this cause they may not be significant, stuff include

RFC 896 - Nagle
RFC 1106 - R. Fox
RFC 1122 - Jacobson stuff here - apparently this guy's stuff is big. Commonly used in many TCPs. Have to read his congestion avoidance paper. Anyway lists "official" TCP requirements.
RFC 1072 - Long Fat Pipes
RFC 1110 - Big window TCP problems?
RFC 1263 - TCP harmful extensions? - Maybe this points out stuff I shouldn't include
RFC 1323 - Jacobson's high performance extensions… official LFN specifications, seems LFN is not a TCP but just a few additions.
RFC 1337 - Time Wait Assasinations in TCP !?!??! Hmmm is this important? Nobody else seems to mention this much.
RFC 1379 - TCP for transactions, maybe important, but need to talk to Jim bout this, cause it seems not much flow control in it, the whole scheme is about saving info for small connections to shrink the handshake. Probably wont include.
RFC 2018 - SACK TCP, this may be important, seems to cut down on retransmissions a lot, or so it claims, have to look at it a bit more.
RFC 2415- Studies on increased TCP window size ? this important? Has impact on flow control ? but may be if it has no algorithm, probably wont include.
RFC 2488 - Enhancing TCP over satellite channels, hmmm this important ? seems to be a few features cobbled together like SACK and so on. Nothing unique here.
RFC 2525 - TCP problems…. Useful for showing up problems in different algorithsm via the simualtor.
RFC 2581 - Official specs for congestion control, Jacobson stuff all formalized here.
RFC 2757 - Long Thin Networks, again nothing unique, just recommendations on using SACK and stuff to improve rates.

From reading all this it seems that there are no "strict" TCP versions, official TCP requirements are stated in RFC 1122, as long as a TCP fits those requirements, it is "TCP" - so any "TCP" with something extra can be called a new "TCP" version. So I am not looking at strict TCP versions par se, but famous algorithms added to TCP which make it distinct enough from others to be considered another TCP version. Need more thought on this

29/3

After talking with Jim seems I was right, TCP "versions" are just famous algorithms cobbled on top of the "official" TCP specs. Also, nobody "owns" the right to TCP, so there are no "official" releases of TCP - any company can release anything that conforms to TCP standards but can have something extra and call it a "extra" TCP version.

So my research will probably have to focus on "famous" algorithms - the official ones in the RFCs are probably best - there are many research ideas but they don't seem to have being widespread implemented.

More TCP RFCs found,

RFC 2582 - New Reno Official Modification - Seems that this small modification is what makes Reno 2 TCP "New Reno". This one is important.
RFC 2760 - TCP satellite research, lists all the research on this so far, very similar to LFN except they include SACK and increased window initiation. Again, nothing really unique in terms of algorithms. Mostly standards and best current practices.
RFC 2861 - Congestion Window Validation, hmmm this one is different, after idleness instead of slow starting, they use some weird thingy to adjust window to a higher then slow start size so it can start faster. Is this important? Again doesn't seem to be popular, seems more experimental to me.
RFC 2883 - SACK TCP extension for TCP. important stuff, but only implements receiver side !!! what am I supposed to do ? make up the sender side stuff? Obviously SACK is important here its mentioned in many papers, but there is no offcial sender side mechanism ! Hmmm what to do ?
RFC 2988 - Stuff on TCP retransmission timer, standards on how RTO timer is to be calculated. Nothing new here.
RFC 3042 - Another algorithm, uses "limited transit" to recover from lost segments faster, just seems to be a replacement for Jacobson's fast retransmit. I think this is the partial recovery in New Reno

This seem to make up the bulk of the TCP RFC up to recently. Also Jim mentions that he wants a plug and play mechanism of some type that can be used to extend the simulator to include future flow control algorithms. How do I do that ? from what I read flow control can be anything from change a retransmission timer to regulate the rate at which segments are retransmitted, to Jacobson window size controlling algorithms to nagles and SWS stuff. Need to read up to see if any abstraction can be done.