Principles of Congestion Control

Transcription

1 Principles of Congestion Control Causes/costs of congestion: scenario Congestion: informally: too many sources sending too much data too fast for network to handle different from flow control! two senders, two receivers one router, infinite buffers no retransmission Host B Host A λ in : original data unlimited shared output link buffers λ out manifestations: lost packets (buffer overflow at routers) long delays (queueing in router buffers) a top- problem! large delays when congested maximum achievable throughput Causes/costs of congestion: scenario one router, finite buffers sender retransmission of lost packet Host A λ in : original data λ' in : original data, plus retransmitted data λ out Causes/costs of congestion: scenario always: λ = λ in out (goodput) perfect retransmission only when loss: λ > λ in out retransmission of delayed (not lost) packet makes λ larger (than perfect case) for same λout in Host B finite shared output link buffers costs of congestion: more work (retrans) for given goodput unneeded retransmissions: link carries multiple copies of pkt 3 4

2 Causes/costs of congestion: scenario 3 Causes/costs of congestion: scenario 3 four senders multihop paths timeout/retransmit Q: what happens as λ and increase? in λ in H o s t A λ o u t Host A λ in : original data λ' in : original data, plus retransmitted data λ out H o s t B finite shared output link buffers Host B Another cost of congestion: when packet dropped, any upstream transmission capacity used for that packet was wasted! 5 6 Approaches towards congestion control Case study: ATM AB congestion control Two broad approaches towards congestion control: End-end congestion control: Network-assisted congestion control: no explicit feedback from network routers provide feedback to end systems congestion inferred from end-system single bit indicating congestion observed loss, delay (NA, DECbit, TCP/IP ECN, ATM) approach taken by TCP explicit rate sender should send at AB: available bit rate: elastic service if sender s path underloaded : sender should use available bandwidth if sender s path congested: sender throttled to minimum guaranteed rate M (resource management) cells: sent by sender, interspersed with data cells bits in M cell set by switches ( networkassisted ) NI bit: no increase in rate (mild congestion) CI bit: congestion indication M cells returned to sender by receiver, with bits intact 7 8

3 Case study: ATM AB congestion control TCP Congestion Control two-byte E (explicit rate) field in M cell congested switch may lower E value in cell sender send rate thus minimum supportable rate on path EFCI bit in data cells: set to in congested switch if data cell preceding M cell has EFCI set, sender sets CI bit in returned M cell end-end control (no network assistance) sender limits transmission: LastByteent-LastByteAcked CongWin oughly, rate = CongWin TT Bytes/sec CongWin is dynamic, function of perceived network congestion How does sender perceive congestion? loss event = timeout or 3 duplicate acks TCP sender reduces rate (CongWin) after loss event three mechanisms: AIMD slow start conservative after timeout events 9 TCP AIMD TCP low tart multiplicative decrease: cut CongWin in half after loss event 4 Kbytes congestion window additive increase: increase CongWin by M every TT in the absence of loss events: probing When connection begins, CongWin = M Example: M = 500 bytes & TT = 00 msec initial rate = 0 kbps When connection begins, increase rate exponentially fast until first loss event 6 Kbytes available bandwidth may be >> M/TT 8 Kbytes desirable to quickly ramp up to respectable rate time Long-lived TCP connection 3

4 TCP low tart (more) efinement When connection begins, increase rate exponentially until first loss event: double CongWin every TT done by incrementing CongWin for every ACK received ummary: initial rate is slow but ramps up exponentially fast TT Host A Host B one segment two segments After 3 dup ACKs: CongWin is cut in half window then grows linearly But after timeout event: CongWin instead set to M; Philosophy: 3 dup ACKs indicates network capable of delivering some segments timeout before 3 dup ACKs is more alarming four segments window then grows exponentially time to a threshold, then grows linearly 3 4 efinement (more) Q: When should the exponential increase switch to linear? A: When CongWin gets to / of its value before timeout. Implementation: congestion window size (segments) Variable Threshold At loss event, Threshold is set to / of CongWin just before loss event threshold TCP Tahoe TCP eno Transmission round eries eries ummary: TCP Congestion Control When CongWin is below Threshold, sender in slow-start phase, window grows exponentially. When CongWin is above Threshold, sender is in congestionavoidance phase, window grows linearly. When a triple duplicate ACK occurs, Threshold set to CongWin/ and CongWin set to Threshold. When timeout occurs, Threshold set to CongWin/ and CongWin is set to M

5 TCP Fairness Why is TCP fair? Fairness goal: if K TCP sessions share same bottleneck link of bandwidth, each should have average rate of /K TCP connection TCP connection bottleneck router capacity Two competing sessions: Additive increase gives slope of, as throughout increases multiplicative decrease decreases throughput proportionally Connection throughput Connection throughput equal bandwidth share loss: decrease window by factor of congestion avoidance: additive increase loss: decrease window by factor of congestion avoidance: additive increase 7 8 Fairness (more) Delay modeling Fairness and UDP Multimedia apps often do not use TCP do not want rate throttled by congestion control Instead use UDP: pump audio/video at constant rate, tolerate packet loss esearch area: TCP friendly Fairness and parallel TCP connections nothing prevents app from opening parallel cnctions between hosts. Web browsers do this Example: link of rate supporting 9 connections; new app asks for TCP, gets rate / new app asks for TCPs, gets /! Q: How long does it take to receive an from a Web server after sending a request? Ignoring congestion, delay is influenced by: TCP connection establishment data transmission delay slow start Notation, assumptions: Assume one link between client and server of rate : M (bits) O: size (bits) no retransmissions (no loss, no corruption) Window size: First assume: fixed congestion window, W segments Then dynamic window, modeling slow start 9 0 5

6 Fixed congestion window () Fixed congestion window () First case: W/ > TT + /: ACK for first segment in window returns before window s worth of data sent delay = TT + O/ econd case: W/ < TT + /: wait for ACK after sending window s worth of data sent delay = TT + O/ + (K-)[/ + TT - W/] Where K = O/W TCP Delay Modeling: low tart () TCP Delay Modeling: low tart () Now suppose window grows according to slow start Will show that the delay for one is: O P Latency = TT + + P TT ( ) + where P is the number of times TCP idles at server: P = min{ Q, K } Delay components: TT for connection estab and request O/ to transmit time server idles due to slow start erver idles: P = min{k-,q} times initiate TCP connection request TT first window = / second window = / third window = 4/ - where Q is the number of times the server idles if the were of infinite size. - and K is the number of windows that cover the. Example: O/ = 5 segments K = 4 windows Q = P = min{k-,q} = erver idles P= times delivered time at client time at server fourth window = 8/ complete transmission 3 4 6

7 TCP Delay Modeling (3) + TT = time from when server starts to send segment until server receives acknowledgement k = time to transmit the kth window k + TT = idle time after the kth window O delay = + TT + + P p= idletime P O k = + TT + [ + TT ] k = O P = + TT + P[ TT + ] ( ) p initiate TCP connection request delivered TT time at client first window = / second window = / third window = 4/ fourth window = 8/ complete transmission time at server TCP Delay Modeling (4) ecall K = number of windows that cover How do we calculate K? 0 K = min{ k : + + L+ = min{ k : L+ k k O = min{ k : } O = min{ k : k log( + )} O = log( + ) k O} O / } Calculation of Q, number of idles for infinite-size, is similar (see HW). 5 6 HTTP Modeling Assume Web page consists of: base HTML page (of size O bits) M images (each of size O bits) Non-persistent HTTP: M+ TCP connections in series esponse time = (M+)O/ + (M+)TT + sum of idle times Persistent HTTP: TT to request and receive base HTML file TT to request and receive M images esponse time = (M+)O/ + 3TT + sum of idle times Non-persistent HTTP with X parallel connections uppose M/X integer. TCP connection for base file M/X sets of parallel connections for images. esponse time = (M+)O/ + (M/X + )TT + sum of idle times HTTP esponse time (in seconds) TT = 0 msec, O = 5 Kbytes, M= and X= non-persistent persistent parallel nonpersistent 8 Kbps 0 Kbps Mbps Mbps For low bandwidth, connection & response time dominated by transmission time. Persistent connections only give minor improvement over parallel connections

8 HTTP esponse time (in seconds) TT = sec, O = 5 Kbytes, M= and X= Kbps 0 Kbps Mbps Mbps non-persistent persistent parallel nonpersistent For larger TT, response time dominated by TCP establishment & slow start delays. Persistent connections now give important improvement: particularly in high delay bandwidth networks. ummary principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control