zoukankan html css js c++ java

Congestion Avoidance in TCP

Consequence of lack of congestion control

When a popular resource is shared without regulation the result is always over-utilization
With the introduction of TCP in 1983, users can write networking applications that require reliablity with greater ease
When more applications are available, more data and information are exchange on the Internet.
In mere 3 years time, the Internet had its first breakdown....

A classic paper by Jacobson contains the following introduction:

"In October of '86, the Internet had the first of what became a series of congestion collapses.

..., the data throughput from LBL to UC Berkeley (sites separated by 400 yards and 2 IMP - i.e., routers - hops) dropped from 32 Kilo bits/sec to 40 bits/sec."

Jacobson's paper can be found here: click here

History of Congestion Control in TCP

There have been many (and increasingly sophisticated) congestion avoidance mechanims added to TCP since Jacobson's work on Congestion Control.
The Congestion Control mechanism in TCP is an ever developing process.... (it is still a research topic !)

The most popular versions of TCP - named after cities in Nevada - are:

TCP Tahoe
- This is the original version of TCP congestion control as implemented by Jacobson
- Congestion detection mechanism is based on packet loss
- Techniques used for congestion control:
  - Slow Start
  - Congestion Avoidance
  - Fast Retransmit
TCP Reno
- This is the most popular version of TCP congestion control mechanism today.
- Techniques used for congestion control:
  - same as TCP Tahoe (Slow Start, Congestion Avoidance and Fast Retransmit), plus
  - Fast Recovery
TCP Vegas
- This is completely new implementation
- Congestion detection mechanism is based on end-to-end delay

TCP packet size

TCP is a byte oriented protocol
However, TCP would not send every byte in a separate packet since this would result in an enormous overhead...
User data is carried inside a TCP packet which itself is carried inside a IP packet :
Example:
- If no additional options are used (no additional packet header information beside the necessary ones), and each packet carries a single byte of data, the IP packet size will be 41 bytes.
- The efficiency (useful part of the packet) would be 1/41 or 2.4%
- That's equivelent to Uncle Sam taking 97.6% in income taxes !!!
TCP will always try to send multiple bytes in a packet to improve efficient

Since we are dealing with congestion control, we will assume the worst case scenario which is when the TCP source is transmitting a large amount of data continuously

In other words:

We assume that every TCP source is sending at maximum data rate

This is achieved by sending packets whose size is as large as possible

In other words, in the analysis of TCP congestion control scheme, we always assume that:

TCP always transmits packets of size equal to MSS bytes

Maximum Packet (Segment) Size
- User/System can impose a maximum packet size used in TCP
- The maximum packet size is called Maximum Segment Size or MSS
The MSS will play an important part in describing the congestion avoidance mechanism used in TCP....

Transmission Data Rate
- The transmission data rate is indirectly dependent on the transmit window size...
  The dependency is pretty complicated and very dynamic in nature
  
  The following examples will derive a simple relationship between the data transmission rate and the transmit window size.
- Example 1:
  - Suppose the sender has a lot of data to transmit (transmits continously) and the transmit window size is equal to MSS (Max Segment Size). The following will happen:
    1. Because transmit window size is equal to MSS, the sender can send only 1 packet at a time and must stop (because he promised not to send more than MSS bytes before hearing back from the receiver on how the data were received).
    2. The ACK for will return in approximately RTT (round trip time) sec
    3. When the ACK returns, the sender sends the next packet. (If the ACK does not return for a long time, the sender will retransmit - sender assumes the packet was lost).
    4. The resulting transmission rate is approximately MSS/RTT bps.
- Example 2: If window size = 2*MSS, the sender can send faster:
  
  But do not conclude that data rate is proportional to the window size. The above examples are "idealized". Network delays, route changes and other factors can make the relationship very unpredictable and dynamic.
TCP Transmit Window Size
- Terminology:
  Transmit Window
  
  # packets (
  
  MSS
  bytes in each packet) that sender can transmit without having to wait for acknowledgement
- The size of the Transmit Window is computed using 2 windows:
  1. Advertised Window Size
  2. TCP's Congestion Window Size
- We have learned about the Advertised Window Size previously (see: click here ):
  - The advertised window size is the amount of data that the receiver is willing to buffer when data arrived out of order:
TCP's Congestion Window Size
- An intuitive definition of the Congestion Window Size is:
  Congestion Window Size is
  
  the number of packets (of
  
  MSS
  
  bytes of data) that the sender
  
  believes
  that it can transmit into the network without causing congestion in the network.
- Notice that this amount of data depends on the current network status and thus varies over time...
  In fact, it changes faster than the weather and it is just as unpredictable...
Relationship of the Transmit Window and the Congestion Window
- When users send a large amount of data through the shared Internet, they must be be courteous in regard to:
  1. The receiving party (do not overwhelm a slower receiver)
  2. The shared transmission medium (Internet)
- In other words, the sender must NOT transmit more data than:
  1. The receiver can handle
  2. The network links can handle
- In yet other words:
  TCP Transmit Window size <= Advertised Window size, and:
  
  TCP Transmit Window size <= Congestion Window size
Notations used in TCP congestion control scheme
- Advertised Window Size (AWS) = amount of data that the receiver will buffer.
  AWS is negotiated at connection establishment and remains unchanged afterwards
- Congestion Window Size (CWND) = window size imposed by the TCP congestion mechanism to avoid causing congestion in the network
  CWND changes over time !!!
- Transmit Window Size (TWS) = the amount of unacknowledged data, i.e., data that TCP transmits in a burst without receiving any indication on what happened to the data.
- Relationship:
  TWS = min (AWS, CWND)
How TCP controls its transmission rate
- Recall that the Advertised Window Size (AWS) is contained in the TCP header (so TCP has this information to its disposal)
- The TCP congestion control algorithm will compute the value of CWND according to (implicit) signals/events (such as timeout, duplicate ACKs, see: click here ) from the network
  (We have not yet discussed HOW TCP changes the value of CWND - will come next)
- From the values of AWS and CWND, TCP will computes the transmit window size as:
- TWS = min (AWS, CWND)
- Because AWS is not under TCP control (but determined by the receiver), we will leave this value out of the discussion.
  In the remainder of the discussion, we will discuss how TCP updates the value of CWND
TCP modes/phases of operation
- The key to understand why TCP operates in the way it does is to remember that network condition changes constantly
  - New TCP connections can be started at any time which will reduce the avaliable network capacity for existing TCP connections
  - Existing TCP connections can end at any time which will increase the avaliable network capacity for the remaining TCP connections
- To accomodate the uncertainty, TCP operates in two different modes/phases
  1. Slow Start Mode/Phase:
    - This is the start up mode of operation of TCP
    - In this mode/phase, TCP has an idea (guess) about the maximum transmission rate and TCP is trying to reach this transmission rate
    - Although TCP has an idea (guess) about this maximum transmission rate, TCP will NOT transmit at this rate instantaneously
      Rather, TCP will try to reach this maximum transmission rate in a piece meal fashion
    - In this phase, TCP will start by transmitting ONE packet and at each successfully transmission epoch, TCP will DOUBLE the number of packets (resulting in an exponential increase in number of packets in time).
  2. Congestion Avoidance Phase:
    - This is the phase that begins AFTER the start up phase
      The start up phase ends when TCP has reached the maximum transmission rate that it "believed" to be safe.
    - In other words, TCP is now in uncharted territory....
      Because TCP has reach the maximum safe level, it would appear that there is still some more capacity available - it would be a shame NOT to use the available capacity !!!
    - But ! TCP has no idea what the new maximum capacity is... so it must be careful !
    - In this phase, TCP will increase the number of packet much slower than in the start up phase (increase rate will not be exponential, but linear)

TCP congestion strategy: A video game analogy

What TCP is doing is somewhat the same strategy as playing a video game...
In some adventure video games, there are "danger" areas where the player get killed by some booby trap.
So how do you play such a video game ?
You just walked in a trap and get killed....

Restart the game, and play quickly upto the point where you got killed.

From that point on, play very carefully.....

The life of TCP is like a never-ending video game:

When TCP detects congestion (through a packet loss), it sets CWND to half of the transmit window size that it was used when the packet loss occured.
(Because the current transmit window size causes packet loss, half of the current transmit window size is a conservative estimate of the NEW safe level to operate !)
Then TCP will restart by transmitting using CWND = 1 (ONE packet outstanding) and increase CWND exponentially (from ONE) to the new congestion window size CWND
This phase is the slow start phase
When TCP reach the new congestion window size (this is the point where TCP believe it is safe), it will enter the second phase and increase the window size much less aggressively (linearly instead of exponentially)
This phase is the congestion avoidance phase
The congestion avoidance phase ends when TCP detects a packet loss and the cycle starts again from the top....

Overview of the (idealized) TCP congestion control operation:
- NOTES:
  - Remember: the goal of TCP is get the highest possible throughput.
  - This goal is not achieved by sending as fast as possible, but as much as the network can handle !!!
  - The available network bandwidth changes constantly.
  - TCP tries to determine the available capacity by remembering when the data rate at which a packet drop occured the last time and proceeds carefully starting from half way of this capacity level.
  - NOTE: the first time that TCP starts, it has no idea what the network capacity is and the only thing that it can do is to set the level to what the receiver can handle...
An overview of of techniques used in TCP Congestion control
- We have just seen an high level discussion of the TCP Congestion control algorithm consisting of 2 different phase
  In the slow start phase, transmission rate increases exponentially in time.
  
  In the congestion avoidance phase, transmission rate increases linearly in time.
- So basically, the difference between the 2 phases is the rate of increase in transmission speed.
- Now it's time to see how the increase in transmission speed is realised.
- TCP uses the following 3 mechanisms with very sexy sounding names:
  1. Slow Start
  2. Fast Retransmit
  3. Fast Recovery
We will look at each mechanism separately and indicated when the mechanism is appropriate.

The SLOW START Phase

The Slow Start Mechanism

During the slow start phase, TCP uses the slow start mechanism for congestion control.

Information needed to implement the slow start mechanism:

SSThresHold
believes
CWND
CWND and AWS will determine the transmit window size of TCP

Operation of the slow start mechanism is as follows:

Initilization:

SSThresHold is set to AWS (when TCP first begins) or Transmit Window/2 (when TCP detects congestion)

Slow Start:

Set CWND = MSS (i.e., ONE packet)
TCP increases CWND by MSS whenever TCP receives an NEW ACK packet (= an ACK message that TCP has never seen before)
(NOTE:: If TCP receives a duplicate ACK, no updates are made to the CWND variable)

Example of TCP operation in the slow start phase:
- Initially (at time 0), CWND = 1
- At time RTT (round trip time), CWND = 2
- At time 2 RTT, CWND = 4
- At time 3 RTT (not in figure), CWND = 8
- And so on...
- When you plot CWND over time, CWND will increase exponentially

When to BEGIN a new Slow Start epoch

A slow start epoch can be initiated in 2 stituations:

When a TCP connection is first establish.
In this case, SSThresHold is set to AWS
When TCP has detected a packet loss
In this case, SSThresHold is set to Transmit Window/2

When to END a Slow Start epoch

The slow start epoch can ended by 2 events:

When CWND > SSThresh
In this case, TCP will enter the congestion control phase:

TCP is now in "uncharted" territory and will increase its congestion window slower
When TCP detects a packet loss
In this case, TCP will re-enter

TCP first sets SSThresHold = Transmit Window

Then TCP resets CWND = 1 to start a new Slow Start epoch

A $64,000 question:
- Why would TCP use a "slow start" procedure to increase CWND from ONE all the way to SSThrehHold
  Why not just set CWND to SSThrehHold and be done with it ???
- Answer:
  - TCP uses timeouts to tell if packets are lossed
  - The timeout value used must be estimated because we don't know in advance how far away the receiver is located.
  - So TCP must maintain an estimate for the RTT to the receiver and the timeout interval is a function of the RTT
  - By sending packets slowly instead of in a burst, TCP can measure the RTT of packets more accurately
How can you call the EXPONENTIAL increase of transmission rate in "Slow Start" SLOW ???
- The name "slow start" is probably one of the worst misnomer in networking...
- How on earth can you call an exponential increase in window size SLOW ???
- To understand the terminology, you have to look in history....
- Prior to Jacobson's work, TCP operates as follows:
- Now, compared to sending AWS bytes of data, the new way of start transmitting ONE packet first is indeeds slower...
The Congestion Avoidance Phase

TCP's Congestion Avoidance mode

TCP enters the congestion avoidance phase when the slow start phase terminates normally
(i.e., CWND > SSThresHold)

Operation of the congestion avoidance phase is as follows:

Ideally, TCP increases CWND by ONE packet or MSS bytes after every RTT seconds
It is quite complex to remember how many bytes you have acknowledge...

It is far easier to increase CWND each time you receive a NEW acknowledgement
Notice that if TCP is transmitting maximum size packets, and the congestion window is CWND, then there are approximately CWND/MSS packets sent using the transmit window
So if we add MSS/CWND to the congestion window size, we will have effectively increase CWND by ONE after all the acknowledgement packets return (they wil return in RTT seconds)
So practically, this can be (approximately) accomplished by increasing the congestion window CWND by MSS/CWND packets or MSS * MSS/CWND bytes after TCP receives a NEW acknowledgement
So:
```
      CWND = CWND + MSS * MSS/CWND
   
```
when TCP receive a NEW acknowledgement

(Again, when a duplicate (old) ACK is received, CWND is not updated)

Example of TCP operation in the congestion avoidance phase:

Suppose that CWND = 4 when TCP enters the congestion avoidance phase...
TCP sends out 4 packets (each containing MSS bytes) to the receiver.
If there is no congestion, 4 NEW ACK packets will be received in approximately RTT seconds

When the first ACK packet is received, TCP updates CWND as follows:

  CWND = CWND + MSS * MSS/CWND        // CWND = 4 MSS  
       = 4 MSS + MSS * MSS/(4 MSS)
       = 4 MSS + MSS * 1/4
       = 4.25 MSS

When the second ACK packet is received, TCP updates CWND as follows:

  CWND = CWND + MSS * MSS/CWND        // CWND = 4.25 MSS  
       = 4.25 MSS + MSS * MSS/(4.25 MSS)
       = 4.25 MSS + MSS * 1/4.25
       = 4.485 MSS

When the third ACK packet is received, TCP updates CWND as follows:

  CWND = CWND + MSS * MSS/CWND        // CWND = 4.485 MSS  
       = 4.485 MSS + MSS * MSS/(4.485 MSS)
       = 4.485 MSS + MSS * 1/4.485
       = 4.708 MSS

When the fourth (and final) ACK packet is received, TCP updates CWND as follows:

  CWND = CWND + MSS * MSS/CWND        // CWND = 4.708 MSS  
       = 4.708 MSS + MSS * MSS/(4.708 MSS)
       = 4.708 MSS + MSS * 1/4.708
       = 4.92 MSS

So you can see that CWND is increased approximately by MSS or ONE packet after RTT seconds
(In the slow start phase, CWND DOUBLES after each RTT seconds)

NOTE: the actual implementation of TCP (see Stevens - Volume 2) increases CWND during congestion avoidance slightly faster than above using to the following formula:
CWND = CWND + MSS * MSS/CWND + MSS/8

Why do TCP want to keep increasing CWND ?
- Why does TCP not keep CWND constant after reaching the "safe" operation level SSThresHold ?
- When TCP keeps increasing CWND, it would eventually cause a congestion !!!
  So why so foolish ???
- The reason is:
  - TCP does not know the current network capacity... because network condition keeps changing.
  - The goal of TCP is to transfer data as fast as possible.
    If TCP would stop increasing CWND, it would not be true to its goal.
  - So during the congestion avoidance period, TCP is testing the tolerance of the network:
    CWND
    one more packet
    CWND + MSS
    retest
  (This technique is similar to kids testing their boundary by asking their parents for favors over and over again... The boundary may have moved :-))
When does the Congestion Avoidance phase BEGIN ?
- When the Slow Start phase terminates successfully
When does the Congestion Avoidance phase END ?
- Eventually, TCP will push the congestion window too far and cause some packet drop.
- When a packet loss occurs, it can cause the sending TCP to timeout
- When a timeout occurs, the congestion avoidance phase ends and TCP will begin a slow start phase:
  1. TCP sets SSThresh = CWND/2.
    This is the new "safe" operation level...
  2. Then TCP set CWND = 1 x MSS (i.e., 1 packet worth of data) and increases CWND at an expontial rate towards SSThresh (the "safe" level")

Fast Retransmit

Fast Retransmit
- Before the introduction of the Fast Retransmit, TCP was not "pro-active".
- Example:
  packet 14
  repeatedly
  ACK 13
  NOT act on this signal
  - FURTHERMORE, when TCP times out, TCP will enter the SLOW START phase
- Fast Retransmit: using duplicate ACKs as indicators for lossed pacet
  - Clearly, when the receiver keep sending the same (duplicate) ACK, some message may be lossed
  - BUT, because packets can arrive OUT OF ORDER, an occasional duplicate ACK can arrive:
  - So to eliminate most of these false loss indications, it is decided that when TCP receives 3 duplicate ACKs (so TCP received a total of 4 identical ACK packets), then TCP concludes that the packet is lossed and TCP retransmits the lossed packet IMMEDIATELY (without waiting for timeout):
    - Having received 3 duplicate ACKs privides a high probability that a packet was lossed, but does not provide certainty...
- After TCP retransmits the lossed packet, it enters the Slow Start phase (because a packet loss had occured)
- Time to show TCP congestion control mechanism in action...
TCP Tahoe Demo
- TCP Tahoe (the original version by Jacobson) incorporates the Slow Start and Congestion Avoidance mechanisms.
- We will look at the operation of TCP Tahoe in this sample network:
- Here is a NS2 source file to simulate a TCP Tahoe source: click here
  - Right click and save the file in your directory.
  - Run program with:
```
      export PATH=/usr/local/gnu/gcc/4.1.0/bin:$PATH
      export LD_LIBRARY_PATH=/usr/local/gnu/gcc/4.1.0/lib:$LD_LIBRARY_PATH

      /home/cheung/NS/run-ns Tahoe.tcl
```
  - You should see the Network Animator window when it finish running... click PLAY to see the simulation in action
- You don't need to run the simulation to see the animation... I have saved a copy of the animation file generated by the simulation.
  The NAM (Network Animation) output file is here: click here
```
    /home/cheung/NS/bin/nam   Tahoe.nam
```
- The Congestion Window CWND plot data output file is here: click here
  gnuplot
  In gnuplot, issue the command:
```
     plot "WinFile" using 1:2 title "Flow 1" with lines 1
```
  You should see this plot:
  
  You can see the operation of TCP Tahoe clearly from the above figure:
  1. At approximately time 0, TCP Tahoe starts and it is in the slow start mode: the congestion window size increases exponentially
  2. At approximately time 5, packet loss is detected.
    TCP marks SSThresh = 25 (approximately) and begins another slow start
  3. When it reaches CWND = 25 (approximately), the CWND increases linearly - here TCP Tahoe enters the congestion avoidance mode
  4. At approximately time 19, TCP Tahoe detects packet loss and begins a slow start.
    SSThresHold is approximately 22.
  5. TCP begins another slow start and so on...
Fast Recovery

Added Improvement: Fast Recovery:

Fast recovery is a beautiful little improvement made to TCP that signifantly increased the TCP's performance level.
Research discovered that: Most Fast Retransmit actions
mild congestions
Recall that TCP performs a SLOW START after TCP performs Fast Retransmit (because there was a packet loss)
Instead of perform a SLOW START (which reduces CWND down to 1 x MSS), research found that TCP can use a larger congestion window without causing network congestion !

Fast recovery:

When TCP performs a fast restransmit (so TCP did not timeout):

set SSThresh = CWND/2
set CWND = SSThresh + 3 * MSS.
(The rationel is that 3 duplicate ACK is worth 3 MSS bytes)
TCP continue to use congestion avoidance (but using the new values of of SSThresh and CWND).

Example:

TCP Reno Demo (Reno implements Fast Recovery)
- Here is a NS2 source file to simulate a TCP Reno source: click here
  - Right click and save the file in your directory.
  - Run program with:
```
      export PATH=/usr/local/gnu/gcc/4.1.0/bin:$PATH
      export LD_LIBRARY_PATH=/usr/local/gnu/gcc/4.1.0/lib:$LD_LIBRARY_PATH

      /home/cheung/NS/run-ns Reno.tcl
```
  - You should see the Network Animator window when it finish running... click PLAY to see the simulation in action
- You don't need to run the simulation to see the animation... I have saved a copy of the animation file generated by the simulation.
  The NAM (Network Animation) output file is here: click here
```
    /home/cheung/NS/bin/nam   Reno.nam
```
- The Congestion Window CWND plot data output file is here: click here
  gnuplot
  In gnuplot, issue the command:
```
     plot "Reno-Window" using 1:2 title "Flow 1" with lines 1
```
  You should see this plot:
  
  You can see that this small change in TCP Reno has resulted in a huge performance improvement:
Further TCP Research: the TCP Flow Synchronization problem
- Do NOT think that this is the end of the story about Congestion Control on the Internet !
- This material on TCP is only the tip of the iceberg...
  There are much more problems and issues with TCP after they introduced TCP Reno
- For example, research has discovered that different TCP flows sharing a bottle neck link will synchronize with each other !!!
  (Here is a paper that points out the phenomenon: click here )
  
  Example that illustrates TCP synchronization:
  - Source 1 (red) start transmitting at time 0.1 sec
  - Source 2 (blue) start transmitting at time 20.0 sec
- Here is a NS2 source file to simulate 2 TCP Reno sources sharing the bottle neck link: click here
  - Right click and save the file in your directory.
  - Run program with:
```
      /home/cheung/NS/run-ns Reno.tcl
```
  - You should see the Network Animator window when it finish running... click PLAY to see the simulation in action
- You need to run the simulation to see the animation because I deleted the animation file generated by the simulation.
- The Congestion Window CWND plot data output files are here:
  - Window plot for TCP source 1: click here
  - Window plot for TCP source 2: click here
  To see the plot of the CWND of TCP, save the Congestion Window CWND plot file in your directory and run gnuplot
  
  In gnuplot, issue the command:
```
     plot "WinFile" using 1:2 title "Flow 1" with lines 1, 
          "WinFile2" using 1:2 title "Flow 2" with lines 2
```
  You should see this plot:
- The plots shows clearly that:
  - Flow 1 starts early
  - Flow 2 starts later and cause packet drops for both flows
  - The 2 TCP flows perform Slow Start together and reduce their windows simultaneously
  - Eventually, the congestion windows of both flows are synchronized !!!
  This kind of behavior is not good, because the best way to utilizate all network capacity is for one of the flow to cut back
  
  (But it should NOT always be the same flow, otherwise you have unfairness)
- The research to solve this phenomenon triggered the development of "Active Queue Management (AQM)" - among them, the "Random Early Drop/Detection (RED)" queue is the best well-known representative.
Further TCP Research: RTT unfairness problem
- TCP is NOT fair when different TCP connection share a bottle neck link but have different Round Trip Times (RTT)
- Example that illustrates TCP unfairness when RTTs differ:
  - Source 1 (red) start transmitting at time 0.1 sec, RTT is 2 x 150 msec
  - Source 2 (blue) start transmitting at time 20.0 sec, RTT is 2 x 640 msec
  - Due to higher RTT, the CWND of flow 2 will increase slower !!!
- Here is a NS2 source file to simulate 2 TCP Reno sources sharing the bottle neck link: click here
  - Right click and save the file in your directory.
  - Run program with:
```
      /home/cheung/NS/run-ns Reno.tcl
```
  - You should see the Network Animator window when it finish running... click PLAY to see the simulation in action
    (The NAM file is too big and I deleted it...)
- The Congestion Window CWND plot data output files are here:
  - Window plot for TCP source 1: click here
  - Window plot for TCP source 2: click here
  To see the plot of the CWND of TCP, save the Congestion Window CWND plot file in your directory and run gnuplot
  
  In gnuplot, issue the command:
```
     plot "WinFile" using 1:2 title "Flow 1" with lines 1, 
          "WinFile2" using 1:2 title "Flow 2" with lines 2
```
  You should see this plot:
  - You can see that the average congestion window size of flow 2 is lower than flow 1 and they do not converge...
  - BTW, you can also see the TCP flow synchronization problem in this plot:
    slow start
Further TCP Research: Gigabit networks
- Another area of intense research is to adapt TCP for higher speed networks (Giga or Tera bit networks).
  In these networks, the usable window size is huge... hundreds of thousands of packets.
  
  TCP cannot afford the luxury to increase its window size by 1 in each RTT.
  
  In order to reach the fill capacity of the network, TCP must increase faster...
- Example that illustrates TCP's behavior in high speed network :
  - Source start transmitting at time 0.1 sec
- Here is a NS2 source file to simulate TCP Reno on a high speed (Giga bit) network: click here
  - Right click and save the file in your directory.
  - Run program with:
```
      /home/cheung/NS/run-ns Reno.tcl
```
  - You should see the Network Animator window when it finish running... click PLAY to see the simulation in action
    (The NAM file is too big and I deleted it...)
- The Congestion Window CWND plot data output files are here:
  - Window plot for TCP: click here
  To see the plot of the CWND of TCP, save the Congestion Window CWND plot file in your directory and run gnuplot
  
  In gnuplot, issue the command:
```
     plot "WinFile" using 1:2 title "Flow 1" with lines 1
```
  You should see this plot:
  - You can see that TCP performed 2 unsuccessful slow starts
  - At approximately 16 sec, TCP performs the 3rd slow start.
  - This slow start terminates at approximately 18 sec.
  - Then TCP performs Congestion Avoidance... all the way up from CWND = 20 (approximately) to 250+ The simulated ended after 140 sec and TCP has not reached full capacity yet !!!
- If TCP wants to take advantage of high speed links, it must increase the congestion window more aggressively and additively
http://www.mathcs.emory.edu/~cheung/Courses/558-old/Syllabus/6-transport/TCP.html

查看全文

相关阅读:
CentOS 如何将.deb 文件转换.rpm
zabbix 使用SNMP监控富士施乐打印机
 zabbix5.0安装centos7环境
 zabbix5.0安装centos8
iptables 扩展模式
 -bash: mail: command not found
笔记本安装Centos8
Centos 8 安装
 zabbix5.4部署
 死循环判断进程是否存活脚本

原文地址：https://www.cnblogs.com/forcheryl/p/4053288.html