Objective: Design transport protocols that enable applications to utilize large capacities.

Problems with Standard TCP: Can't utilize available capacity.

To achieve 10 Gbps with a 100 ms round-trip time, we need a window size ~ 83,000 packets. The following issues make it difficult for Standard TCP to maintain this window size.

• Steady-State:

  
  (Figure from [Kelly03])

  
  

  • If congestion events occur frequently, average throughput will be less than C.

    Qn: Would the fraction of link capacity utilized in both cases be different? Is there something wrong with the picture?

    
    

  • Floyd's alternative argument: To achieve 10 Gbps, only 1 in (2 x 10^{-10}) packets should be dropped.
    
    ``This is probably past the limits of achievable fiber error rates.'' [Floyd02]

    Qns:
    

    1. Is that true?
       ``A packet loss rate of 10-7 is comparable with those that can occur on long haul fiber links, within network devices, and in end-systems; this places a limit on throughput before any transient congestion due to load fluctuations are considered.'' [Kelly03]
       
       
    2. Why should recovery from fiber error rates be dealt with at the transport layer?
       In particular, why should TCP reduce its sending window significantly in response to fiber ``error'' rates?

• Slow-Start:

  Start with a window of 1 packet.

  • Multiplicatively increase till SSthresh.
  • Additively increase beyond SSthresh.

  
  Could take hours to achieve a window size of a 100 thousand packets.

  Qn: Is this true? Doesn't SSthresh control the ramp-up time?

• Recovery from Consecutive Time-Outs:

  When 2 consecutive timeouts occur, ssThresh drops to 1 and and sender has to use additive increase only to ramp-up its window size.
  This could certainly take several hours.

------------------------------------------------------------------------------------

Design Goals for High-speed TCP:

1. Achieve high throughput
   • Without requiring unrealistically low packet loss rates.
   • Quickly during slow-start.
   • After recovering quickly from multiple retransmit timeouts.
2. Do not require changes to routers and TCP receivers (sender-side modifications only).
3. TCP-friendly performance.
4. . . . (see [Floyd03])

------------------------------------------------------------------------------------

High-speed TCP / Scalable TCP: (basic ideas)

• For High Throughput:

  1. Increase window size more aggressively (multiplicative increase).

     Standard TCP:
     

     every RTT, newW = d + oldW,
     HS-TCP:
     

     every RTT, newW = (1+a) x oldW,

  2. Decrease window size less aggressively (smaller factor).

     newW = b*oldW, where b > 0.5

  
  

  
  (Figure from [Kelly03])

  
  

• For TCP-friendliness:

  1. Under conditions of moderate-to-high congestion (W < LowThresh), behave exactly the same as Standard TCP.
  2. At low loss rates (W > LowThresh), do not be concerned with TCP-friendliness, as Standard TCP can't utilize high available capacity anyways.

  
  

  

------------------------------------------------------------------------------------

Issues:

• Is it really true that the TCP receiver need not be modified?
  What about receive window settings?
  What about flurry of Selective-ACKs due to large windows?
  
  
• Is it really true that routers need not be modified?
  What about buffer space?
  
  
• How to pick LowThresh?
  
  
• Doesn't deal with Slow-Start and multiple consecutive timeouts.
  
  
• How do multiple HS-TCP flows interact?
  Are there any oscillations due to synchronization?
  
  

------------------------------------------------------------------------------------

References:

[Floyd02]	S. Floyd, S. Ratnasamy, S. Shenker, "Modifying TCP's Congestion Control for High Speeds", May 2002.
[Floyd03]	S. Floyd, "HighSpeed TCP for Large Congestion Windows", Internet Draft, July 2003.
[Kelly03]	T. Kelly, "Scalable TCP: Improving Performance in HighSpeed Wide Area Networks", First International Workshop on Protocols for Fast Long-distance Networks, February 2003.

------------------------------------------------------------------------------------