cs/ee 143 Communication Networks Chapter 4 Transport Text: Walrand & Parakh, 2010 Steven Low CMS, EE, Caltech
Recap: Internet overview Some basic mechanisms n Packet switching n Addressing n Routing o hierarchical (AS), forwarding, shortest path routing, software defined networking n Transport o congestion control, error recovery n Medium access control n Internetworking Project
Recap: Internet overview Some basic concepts n Performance metrics o Throughput, line rate (bandwidth), line capacity o Delay, delay jitter n Scalability o location-based routing, hierarchical o best-effort service, end-to-end principle n Layering
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
Recap: Internet overview Some basic analytic tools n Convex optimization o We will use it to understand equilibrium properties of TCP congestion control n Control and dynamical system o We will use it to understand stability properties of TCP congestion control n Queueing theory o We will use it to understand statistical properties of wireless MAC
Recap: Routing Covered layer 3 routing n Autonomous systems (AS) o Defined by administrative domains n Inter-AS: BGP o Policy based n Intra-AS: Dijkstra, Bellman-Ford o Shortest-path routing Error recovery n Can be used in link, transport, or application layer n Parity check, FEC, network coding
Project-oriented ordering o Network layer (Layer 3) last week n Provides host-to-host communication service by finding a path of routers connecting any two hosts n Hosts/routers are identified by IP addresses n Intra-domain and Inter-domain routing protocols o Link layer (Layer 2) next week n Provides host-router and router-router communication by utilizing the physical communication links n Manages routing within the LAN n Hosts are identified by MAC addresses n Examples of protocols: Ethernet, WIFI, etc.
This week 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 (AI) } for every loss { W = W/2 (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
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) = 1 T! x 2 i Δx 2 i 2 q (t) i (t) i! #" ## $ Steady state: F i ( x i (t),q 2 i (t)) x i Fair? Unfair? T i q i Uses: x i (t) = w i (t) T i q i (t)! 0
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 A simple model of AIMD (Reno) for example
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 o Simply model of AIMD
Why both TCP and UDP? o Most applications use TCP, as this avoids re- inventing error recovery in every application o But some applications do not need TCP n For example: Voice applica<ons Some packet loss is fine. Packet retransmission introduces too much delay. n For example: an applica<on that sends just one message, like DNS/SNMP/RIP. TCP sends several packets before the useful one. We may add reliability at applica<on layer instead.