CS558a Syllabus & Progress

Review of Transport Protocols

Functionalities provided by the Transport layer
Recall: Functionalities provided by the transport layers
- TCP:
  - Multiplexing (allow the single UDP layer to accommodate multiple user processes that are running within the computer)
  - Reliable transfer of data (automatically retransmits lossed data)
  - Flow Control
  - Congestion control
  - We have covered reliable transfer
  - We have mainly focus on congestion control
- UDP:
  - Multiplexing
  - Transmits data as soon as possible (will not delay transmission to improve efficiency)
  - No reliability
  - In other words: UDP provides no service except multiplexing....
  - The behavior of the UDP protocol is very close to that of the IP protocol and it is primarily intended for "geeks" who want to develop and test new transport service protocols
    Many network research are performed using the UDP protocol for fast prototyping....
  - Will NOT be discussed/used much in this course...

Traffic Patterns on the Internet

According to some measurements, the traffic pattern on the Internet is as follows:
- 75% of the transmissions are Web traffic (HTTP protocol data)
- 90-95% of the transmissions uses TCP (this includes the Web traffic because HTTP (an application layer) uses TCP (transport layer)).
Link where I got this data from: click here

The moral of the story:

TCP traffic has been (and probably will still be) a dominant portion of Internet traffic for the forseeable future (because network applications that use UDP is very rare - only network research uses UDP).

Short History of TCP and Congestion Control
- 1974: TCP was designed by Vint Cerf, Yogen Dalal and Carl Sunshine: click here
- 1983: TCP adopted as Internet's transport protocol click here
- October 1986: Van Jacobson reported in his classic paper that the throughput on a link between Laurence Berkeley Lab (LBL) and UC Berkeley (3 hops away) dropped to 0.125%.... ( click here )
  Just imagine that for every dollar you make, you had to pay 99.875 cents in taxes.... and you will realise how bad this situation is...
- The collapse was caused by the lack of congestion control in the TCP protocol
Congestion, Buffer overflow and Packet Drop
- Example network:
- Run the following simulation to see the effect of buffer overflow and packet drop:
- Example Program:
  - Prog file: click here
  - Run with:
Effect of network congestion on TCP behavior
- Remember that TCP is a reliable protocol which means that TCP will retransmit packets that the source believe it was lossed.
- Suppose a number of sources use TCP to transfer a large amount of data, and their path uses a common output link.
  This situation will result in congestion:
  1. Initially, the buffer of the output link will fill up gradually because the fill rate is higher than the drain rate:
  2. Sooner or later, the buffer of the output link is full and arriving packets are dropped:
    - In this example, we assume that packet 2 of the top stream is dropped
  3. When packet 1 is received, the ACK 2 is returned
    (TCP uses "ACK n" to mean:
  4. When later packets (for example, packet 3) are received, the receiver will always return ACK 2 (it cannot send ACK 4, because that will make the sender omit packet 2 for good !!!)
  5. After the sender times out, it will retransmits all packets starting with packet 2 again (because due to congestion - long delay - it is likely that packets 3, 4, etc will also time out !)
  6. If the router is still congested (i.e., the buffer is full), then some of the packets of the retransmissions are likely to be dropped by the congested router
    (you have to be very lucky to find an empty buffer in the buffer space - just try finding a packing space at 10 AM in Emory and you will understand what I mean by lucky - someone has to leave before you get a space !!!):
    - Maybe the first packet of the top stream got lucky and found an empty buffer, but the second packet (packet 3) was not as lucky and got dropped
  7. When packet 2 is received, the ACK 3 is returned:
  8. When later packets (for example, packet 4) are received, the receiver will always return ACK 3:
  9. After the sender times out, it will retransmits all packets starting with packet 3 again (because due to congestion - long delay - it is likely that packets 4, 5, etc will also time out !)
  10. And so on...
    And by the way:
- Result of congestion:
  - The sender sends many packets
  - But sender makes very little progress
  - Sender restransmits many packets (causing more congestion and more packet drops)
  - If we do nothing, we have a "network collapse"... (which is what happened in 1986)
TCP Congestion Control
- This congestion problem was recognized and studied mainly by Raj Jain (when he was working at Digital Equipment Coorporation - DEC) and later by Van Jacobson
  They both recognize that the solution to the congestion problem was:
  The difference was that Jain (working at DEC) has been using DEC's network architecture and protocol (DECNET) and studied the congestion problem very thoroughly from a theoretic point of view as he experimented and developed many different ways to allow the source to become aware:
  - Using the "DEC bit" set by the routers to signal congestion
  - Using timeout as a congestion signal
  - And even using average delay as a congestion signal
  On the other hand, Jacobson has been working with the IP protocol and studied the congestion problem in from a practical point of view. His initial version of the solution for the TCP congestion control (See: click here) was suboptimal and - very soon after Jacobson's initial version - later versions of TCP congestion avoidance included ideas from Jain.
- The Current TCP protocol used in the Internet allows sources to share the available bandwidth reasonably fairly
  NOTE: TCP is not perfectly fair. It is biased towards connections between source/destination pairs with small RTT (these connections get a relatively larger share of the available bandwidth)
- "TCP-friendliness"
  - Because TCP traffic comprises a very large portion of the traffic on the Internet, any new transport protocol that researchers propose for use on the Internet must be politically correct towards TCP !!!
  - In other words:
    any new transport protocol must not compromise TCP's ability to obtain a fair share of network resources (bandwidth)
  - Note: it is quite easy to bully TCP and rob it's share of bandwidth using UDP.... just transmit as fast as you can with the UDP protocol and TCP will "automatically" backoff and use less bandwidth (because TCP detected congestion and reduce the source's transmission rate)
- The present day TCP protocol includes a very complex congestion avoidance mechanism and we will study its congestion avoidance mechansim first before discussing transmport protocols for multimedia that are "TCP-friendly".