cs/ee/ids 143 Communication Networks Chapter 4 Transport Text: Walrand & Parakh, 2010 Steven Low CMS, EE, Caltech
Agenda Internetworking n Routing across LANs, layer2-layer3 n DHCP n NAT Transport layer n Connection setup n Error recovery: retransmission n Congestion control
Protocol stack Network mechanisms implemented as protocol stack Each layer designed separately, evolves asynchronously application transport network link physical Many control mechanisms Error control, congestion control (TCP) Routing (IP) Medium access control Coding, transmission, synchronization
Transport services UDP Datagram service No congestion control No error/loss recovery Lightweight TCP Connection oriented service Congestion control Error/loss recovery Heavyweight
UDP 1 ~ 65535 (2 16-1) UDP header 65535 Bytes 8 Bytes (UDP header) 20 Bytes (IP header) Usually smaller to avoid IP fragmentation (e.g., Ethernet MTU 1500 Bytes)
TCP TCP header
Example TCP states 3-way handshake 4-way handshake Possible issue: SYN flood attack Result in large numbers of half-open connections and no new connections can be made.
Window Flow Control RTT Source 1 2 W 1 2 W time data ACKs Destination 1 2 W 1 2 W time o ~ W packets per RTT o Lost packet detected by missing ACK
ARQ (Automatic Repeat Request) Go-back-N Selective repeat TCP Sender & receiver negotiate whether or not to use Selective Repeat (SACK) Can ack up to 4 blocks of contiguous bytes that receiver got correctly e.g. [3; 10, 14; 16, 20; 25, 33]
Window control o Limit the number of packets in the network to window W o Source rate = bps o If W too small then rate «capacity If W too big then rate > capacity => congestion W MSS RTT o Adapt W to network (and conditions)
TCP window control o Receiver flow control n Avoid overloading receiver n Set by receiver n awnd: receiver (advertised) window o Network congestion control n Avoid overloading network n Set by sender n Infer available network capacity n cwnd: congestion window o Set W = min (cwnd, awnd)
TCP congestion control o Source calculates cwnd from indication of network congestion o Congestion indications n Losses n Delay n Marks o Algorithms to calculate cwnd n Tahoe, Reno, Vegas,
TCP Congestion Controls o Tahoe (Jacobson 1988) n Slow Start n Congestion Avoidance n Fast Retransmit o Reno (Jacobson 1990) n Fast Recovery o Vegas (Brakmo & Peterson 1994) n New Congestion Avoidance
TCP Tahoe (Jacobson 1988) window SS CA time : Slow Start : Congestion Avoidance : Threshold
Slow Start o Start with cwnd := 1 (slow start) o On each successful ACK increment cwnd cwnd := cnwd + 1 o Exponential growth of cwnd each RTT: cwnd := 2 x cwnd o Enter CA when cwnd >= ssthresh
Congestion Avoidance o Starts when cwnd >= ssthresh o On each successful ACK: cwnd := cwnd + 1/cwnd o Linear growth of cwnd each RTT: cwnd := cwnd + 1
Packet Loss o Assumption: loss indicates congestion o Packet loss detected by n Retransmission TimeOuts (RTO timer) n Duplicate ACKs (at least 3) (Fast Retransmit) Packets 1 2 3 4 5 6 7 Acknowledgements 1 2 3 3 3 3
Fast Retransmit o Wait for a timeout is quite long o Immediately retransmits after 3 dupacks without waiting for timeout o Adjusts ssthresh flightsize := min(awnd, cwnd) ssthresh := max(flightsize/2, 2) o Enter Slow Start (cwnd := 1)
Summary: Tahoe o Basic ideas n Gently probe network for spare capacity n Drastically reduce rate on congestion n Windowing: self-clocking for every ACK { if (W < ssthresh) then W++ else W += 1/W } for every loss { ssthresh := W/2 W := 1 } (SS) (CA) Seems a little too conservative?
TCP Reno (Jacobson 1990) SS CA for every ACK { W += 1/W } for every loss { W := W/2 } (AI) (MD) How to halve W without emptying the pipe? Fast Recovery
Fast recovery o Idea: each dupack represents a packet having left the pipe (successfully received) o Enter FR/FR after 3 dupacks n Set ssthresh := max(flightsize/2, 2) n Retransmit lost packet n Set cwnd := ssthresh + ndup (window inflation) n Wait till W := min(awnd, cwnd) is large enough; transmit new packet(s) n On non-dup ACK, set cwnd := ssthresh (window deflation) o Enter CA
Example: FR/FR S 1 2 3 4 5 6 7 8 1 9 10 11 time Exit FR/FR R 0 0 0 0 0 0 0 8 time cwnd 8 ssthresh 7 4 9 4 11 4 4 4 o Fast retransmit n Retransmit on 3 dupacks o Fast recovery n Inflate window while repairing loss to fill pipe
Summary: Reno o Basic ideas n dupacks: halve W and avoid slow start n dupacks: fast retransmit + fast recovery n Timeout: slow start congestion avoidance dupacks FR/FR timeout slow start retransmit
Multiple loss in Reno? FR/FR S 1 2 3 4 5 6 7 8 9 0 1 3 time D 0 0 0 0 0 2 time 8 9 5 timeout 8 unack d pkts o On 3 dupacks, receiver has packets 2, 4, 6, 8, cwnd=8, retransmits pkt 1, enter FR/FR o Next dupack increment cwnd to 9 o After a RTT, ACK arrives for pkts 1 & 2, exit FR/FR, cwnd=5, 8 unack ed pkts o No more ACK, sender must wait for timeout
New Reno Fall & Floyd 96, (RFC 2583) o Motivation: multiple losses within a window n Partial ACK takes Reno out of FR, deflates window n Sender may have to wait for timeout before proceeding o Idea: partial ACK indicates lost packets n Stays in FR/FR and retransmits immediately n Retransmits 1 lost packet per RTT until all lost packets from that window are retransmitted n Eliminates timeout
Delay-based TCP: Vegas (Brakmo & Peterson 1994) window SS CA time o Reno with a new congestion avoidance algorithm o Converges (provided buffer is large)!
Congestion avoidance o Each source estimates number of its own packets in pipe from RTT o Adjusts window to maintain estimate # of packets in queues between α and β for every RTT { if W/RTT min W/RTT < α / RTT min then W ++ if W/RTT min W/RTT > β / RTT min then W -- } for every loss W := W/2
Implications o Congestion measure = end-to-end queueing delay o At equilibrium n Zero loss n Stable window at full utilization n Nonzero queue, larger for more sources o Convergence to equilibrium n Converges if sufficient network buffer n Oscillates like Reno otherwise
Theory-guided design: FAST We will study them further in TCP modeling in the following weeks
Summary o UDP header/tcp header o TCP 3-way/4-way handshake o ARQ: Go-back-N/selective repeat o Tahoe/Reno/New Reno/Vegas/FAST -- useful details for your project
Why both TCP and UDP? o Most applications use TCP, as this avoids reinventing error recovery in every application o But some applications do not need TCP n For example: Voice applications Some packet loss is fine. Packet retransmission introduces too much delay. n For example: an application that sends just one message, like DNS/SNMP/RIP. TCP sends several packets before the useful one. We may add reliability at application layer instead. 31
Mathematical model
TCP/AQM TCP: n Reno n Vegas n FAST x i (t) p l (t) AQM: n DropTail n RED n REM/PI n AVQ Congestion control is a distributed asynchronous algorithm to share bandwidth It has two components n TCP: adapts sending rate (window) to congestion n AQM: adjusts & feeds back congestion information They form a distributed feedback control system n n Equilibrium & stability depends on both TCP and AQM And on delay, capacity, routing, #connections
Network model Network n Links l of capacities c l and congestion measure p l (t) Sources i n Source rates x i (t) Routing matrix R x 1 (t)! R = 1 1 0 $ # & " 1 0 1% x 1 + x 2 c 1 x 1 + x 3 c 2 p 1 (t) p 2 (t) x 2 (t) x 3 (t)
Network model x R y F 1 TCP Network AQM G 1 F N G L q R T p R li 1 if source i uses link l TCP CC model x(t +1) = F (x(t), R T consists of p(t)) specs for F i and G l p(t +1) = G (Rx(t), p(t)) = IP routing Reno, Vegas Droptail, RED
Examples Derive (F i, G l ) model for n Reno/RED n Vegas/Droptail n FAST/Droptail Focus on Congestion Avoidance
Model: Reno for every ack (ca) { W += 1/W } for every loss { W := W/2 } Δw i ( t) = x i (t)(1 q i (t)) w i w i (t) 2 x i (t)q i (t)
Model: Reno for every ack (ca) { W += 1/W } for every loss { W := W/2 } Δw i ( t) = x i (t)(1 q i (t)) w i (t) w i (t) 2 x i (t)q i (t) throughput window size q i (t) = l R li p l (t) round-trip loss probability link loss probability
Model: Reno for every ack (ca) { W += 1/W } for every loss { W := W/2 } Δw i ( t) = x i (t)(1 q i (t)) w i (t) w i (t) 2 x i (t)q i (t) x i (t +1) = x i (t)+ 1 T x 2 i 2 i 2 q (t) i ( ) F i x i (t),q i (t) Uses: x i (t) = w i (t) T i q i (t) 0
Model: RED marking prob 1 y l (t) = i R li x i (t) queue length aggregate link rate source rate b l (t +1) = [ b l (t)+ y l (t) c ] + l p l (t) = min{ αb l (t),1} ( ) p l (t)=g l y l (t), p l (t)
Model: Reno/RED x i (t +1) = x i (t)+ 1 T x 2 i 2 i 2 q (t) i ( ) x i (t+1)=f i x i (t),q i (t) b l (t +1) = [ b l (t)+ y l (t) c ] + l q i (t) = y l (t) = l i R li p l (t) R li x i (t) p l (t) = max{ αb l (t),1} ( ) p l (t)=g l y l (t), p l (t)
Decentralization structure x R y F 1 TCP Network AQM G 1 F N G L q R T p x(t +1) = F(x(t), q(t)) p(t +1) = G(y(t), p(t)) q i (t) = y l (t) = l i R li p l (t) R li x i (t)
Validation Reno/REM o 30 sources, 3 groups with RTT = 3, 5, 7 ms o Link capacity = 64 Mbps, buffer = 50 kb o Smaller window due to small RTT (~0 queueing delay)
Model: Vegas/Droptail for every RTT { if W/RTT min W/RTT < α then W ++ if W/RTT min W/RTT > α then W -- } for every loss W := W/2 queue size F i : ( ) = # x i (t) + 1 x i t +1 x i t +1 " $ " # $ T i 2 (t) ( ) = x i (t) 1 T i 2 (t) if w i (t) d i x i (t) < α i if w i (t) d i x i (t) > α i d i d i G l : x i ( t +1) = x i (t) else p l (t+1) = [p l (t) + y l (t)/c l - 1] + T i (t) = d i + q i (t)
Model: FAST/Droptail periodically { basertt W : = W + RTT } α x i (t +1) = x i (t)+ γ i T i (t) α i x i (t)q i (t) ( ) " p l (t +1) = $ p l (t)+ 1 # c l y l (t) c l ( ) % ' & +
L., Peterson, Wang, JACM 2002
Validation: matching transients + + + = c t x t w t p d t w c p i f i i i f i i ) ( ) ( ) ( ) ( 1 0 τ τ!! Same RTT, no cross traffic Same RTT, cross traffic Different RTTs, no cross traffic [Jacobsson et al 2009]
Recap Protocol (Reno, Vegas, FAST, Droptail, RED ) x(t +1) = F (x(t), q(t)) p(t +1) = G (y(t), p(t)) Equilibrium n Performance n Throughput, loss, delay n Fairness n Utility Dynamics n Local stability n Global stability