Comp 443 Week 13: Nov 28 RPC TCP Fairness different RTT Classic example: 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. ============================================================== TCP loss rate, p, versus cwin. cwin = k/sqrt(p), bw = k/RTT*sqrt(p) tcp friendliness 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 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 ============================================================= Satellite Internet: web acceleration Here the problem is that RTT is sooo large. ==================== RTP: sometimes (though not always) coupled with TFRC: TCP-Friendly Rate Control * establish RATE of sending packets * periodic ACKs return summaries of loss rates * suitable for MULTICAST use: greatly limits feasible ACK rates * Adjust sending up/down based on loss rate and TCP cwnd=1.2/sqrt(P) rule * usually some stability rule: * on loss, reduce by less than half ===================================================== SACK TCP in practice, not nearly as useful as one might imagine. Reno does pretty well, in low-loss environments. =========================================================================== Active Queue Management Dealing with timing: PacketPairs Send two packets in rapid succession; do this multiple times; get min. Assume at the min the two packets were transmitted consecutively by the bottleneck router; then bandwidth = size of 1st packet / time gap Gives glimpse at basic network capacity of link Doesn't shed much light on average share DECbit / ECN bit (ECN is below) Early detection of congestion DECbit: use AIMD (+1, *.875) to shoot for 50% "congested" RED gateways Basic idea: improve TCP performance TCP Reno: behaves badly with multiple losses/window; RED tends to minimize that. AvgLen: weighted average queue length dropped packets are spaced more-or-less uniformly ECN: routers set bit when we might otherwise drop the packet (possibly when queue is half full, or in lieu of RED drop) receivers: cwnd = cwnd/2 Biggest advantage of ECN: the receiver discovers the congestion immediately, rather than waiting for the existing queue to be transmitted. Dropped packets are dropped upon arrival at bottleneck router, but loss is not discovered until the queue is transmitted and three subsequent packets are sent.