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)
(HTTP protocal data are transmitted using the TCP protocol)
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 throughput collapse was caused by the lack of congestion control in the TCP protocol

Congestion, Buffer overflow and Packet Drop

Example network:
Run the following Nam (Network Animation) Output to see the effect of buffer overflow and packet drop:

Example Program:

Prog file: click here

Run with:

/home/cheung/NS/bin/nam NoSlowStart.nam

Note:

You may think that it is not realitic that the output link's bandwidth is lower than the input link's bandwidth
You need to see the bigger picture:

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

However, the sender makes very little progress

Because:

Sender restransmits many packets
In severe congestion, the same packet is retransmitted many times
The travesty of it all is the fact that the retransmissions will cause more congestion and thus even more packet drops

If we do nothing, we have a "network collapse"... (which is what happened in 1986)

Simplified and Summarized: suppose approximately 50% packets are dropped

Send window = 10 Recevier buffers 10 packets Sender: 1 2 3 4 5 6 7 8 9 10 Receiver: Sends ACK 1 Buffers: 3 5 7 9 Sender times out: 2 3 4 5 6 7 8 9 10 11 Receiver: Sends ACK 1 Buffers: 3 4 5 7 9 11 Sender times out: 2 3 4 5 6 7 8 9 10 11 Receiver: Sends ACK 5 Buffers: 7 9 11 And so on...
Botton line: Sender has sent 30 packets The progress is onlt 5 packets

(If the first missing packet in the retransmission is dropped, then the sender will retransmit the whole window of packets without making any progress !!!)

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 proposed for use on the Internet must be "friendly" towards TCP !!!

In other words:

Note:

It is quite easy to bully TCP and rob it's share of bandwidth using UDP....
You can transmit as fast as you can with the UDP protocol...
this will cause TCP tp detect congestion and use less bandwidth

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".