Comp [34]43 Week 13: November 19, 2008 TCP Reno Fairness RPC Linkstate TCP Summary: phase cwnd change, loss cwnd change, no loss, per window per Ack slow-start cwnd/2 cwnd *=2 cwnd+=1 congAvoid cwnd/2 cwnd+=1 cwnd+=(1.0/cwnd) TCP Reno: fast recovery detailed diagram EFS: Estimated FlightSize: sender's estimate of how many packets are in transit, one way or the other. This replaces SWS. cwnd inflation/deflation The original algorithm had a more complex strategy; note that strictly speaking, Reno DOES break the sliding-windows rules during fast recovery. NewReno tweak: better handling of the case when two packets were lost If packets 1 and 4 are lost in a window 0,1,2,3,4,5,6,7 then initially we will get dupACK0's. When packet 1 is successfully retransmitted, we start getting dupACK3's. This particular window is much too small to wait for 3 dupACKs. NewReno is essentially the "natural" approach to continuing ============================================================== TCP Fairness Example 1: SAME rtt; both connections get approximately equal allocations. Example 2: different RTT Classic version: Connection 2 has twice the RTT of connection 1. Again we assume both lose when cwin1+cwin2 > 10; else neither. Both start at 1 con1: 1 2 3 4 5 6 7* 3 4 5 6 7 8* 4 5 6 7 8 9* 4 5 ... con2: 1 2 3 4* 2 3 4* 2 3 4* 2 ... con2 averages half the window size. As the time it takes to send a window is doubled, the throughput is down by a factor of FOUR. What is really going on here? Is there something that can be "fixed"? Early thinking (through the 90's?) was that there was. Current thinking is to DEFINE what TCP does as "fair", and leave it at that. ============================================================== TCP loss rate, p, versus cwin. cwnd = k/sqrt(p), bw = k/RTT*sqrt(p) Explanation in terms of TCP sawtooth tcp "friendliness": any transmission method that obeys this rule. Note that the value of k is significant. High-bandwidth TCP consequence for high bandwidth: the cwnd needed implies a very small p unrealistically small! Random losses (not due to congestion) keep window significantly smaller than it should be TCP Throughput (Mbps) RTTs Between Losses W P --------------------- ------------------- ---- ----- 1 5.5 8.3 0.02 10 55.5 83.3 0.0002 100 555.5 833.3 0.000002 1000 5555.5 8333.3 0.00000002 10000 55555.5 83333.3 0.0000000002 Table 1: RTTs Between Congestion Events for Standard TCP, for 1500-Byte Packets and a Round-Trip Time of 0.1 Seconds. Packet Drop Rate P Congestion Window W RTTs Between Losses ------------------ ------------------- ------------------- 10^-2 12 8 10^-3 38 25 10^-4 120 80 10^-5 379 252 10^-6 1200 800 10^-7 3795 2530 10^-8 12000 8000 10^-9 37948 25298 10^-10 120000 80000 Table 2: TCP window size in terms of drop rate One proposed fix: HighSpeed-TCP: allows an inflation of window on each Congestion Window W Number N(W) of Parallel TCPs ------------------- ------------------------- 1 1 10 1 100 1.4 1,000 3.6 10,000 9.2 100,000 23.0 Table 4: Number N(W) of parallel TCP connections roughly emulated by the HighSpeed TCP response function. N(W) = 0.23*W^(0.4), when this is >1. Increased window size is not "smooth" Note N=1 when W=38 or so =========================== TCP Westwood: Keep continuous estimate of bandwidth, BWE (= ack rate * packet size) BWE * RTT_min = min window size to keep bottleneck link busy On loss, reduce cwnd to max(cwnd/2, BWE*RTT_min) Classic sawtooth, TCP Reno cwin alternates between cwin_min and cwin_max = 2*cwin_min. cwin_max = transit_capacity + queue_capacity If transit_capacity < cwin_min, then Reno does a pretty good job keeping the bottleneck link saturated. but if transit_capacity > cwin_min, then when Reno drops to cwin_min, the bottleneck link is not saturated until cwin climbs to transit_capacity. Westwood: on loss, cwin drops to transit_capacity, a smaller reduction. What about random losses? Reno: on random loss, cwin = cwin/2 Westwood: On random loss, drop back to transit_capacity. If cwin < transit_capacity, don't drop at all! ============================================================= Satellite Internet: web acceleration Here the problem is that RTT is sooo large.