cs/ee 143 Communication Networks Chapter 7 Transport Text: Walrand & Parakh, 2010 Steven Low CMS, EE, Caltech

Recap: Internet overview Some basic mechanisms Packet switching Addressing Routing  hierarchical (AS), forwarding, shortest path routing, software defined networking Transport  congestion control, error recovery Medium access control Internetworking Project

Recap: Internet overview Some basic concepts Performance metrics  Throughput, line rate (bandwidth), line capacity  Delay, delay jitter Scalability  location-based routing, hierarchical  best-effort service, end-to-end principle Layering

Recap: Internet overview Some basic analytic tools Convex optimization  We will use it to understand equilibrium properties of TCP congestion control Control and dynamical system  We will use it to understand stability properties of TCP congestion control Queueing theory  We will use it to understand statistical properties of wireless MAC

Recap: Routing Covered layer 3 routing Autonomous systems (AS)  Defined by administrative domains Inter-AS: BGP  Policy based Intra-AS: Dijkstra, Bellman-Ford  Shortest-path routing Error recovery Can be used in link, transport, or application layer Parity check, FEC, network coding

Project-oriented ordering  Network layer (Layer 3) Provides host-to-host communication service by finding a path of routers connecting any two hosts Hosts/routers are identified by IP addresses Intra-domain and Inter-domain routing protocols  Link layer (Layer 2) Provides host-router and router-router communication by utilizing the physical communication links Manages routing within the LAN Hosts are identified by MAC addresses Examples of protocols: Ethernet, WIFI, etc. next week last week

This week Internetworking Routing across LANs, layer2-layer3 DHCP NAT Transport layer Connection setup Error recovery: retransmission Congestion control

Transport services UDP Datagram service No congestion control No error/loss recovery Lightweight TCP Connection oriented service Congestion control Error/loss recovery Heavyweight

UDP UDP header 1 ~ ( ) ≤ 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 handshake4-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  ~ W packets per RTT  Lost packet detected by missing ACK RTT time Source Destination 12W12W12W data ACKs 12W

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  Limit the number of packets in the network to window W  Source rate = bps  If W too small then rate « capacity If W too big then rate > capacity => congestion  Adapt W to network (and conditions)

TCP window control  Receiver flow control Avoid overloading receiver Set by receiver awnd: receiver (advertised) window  Network congestion control Avoid overloading network Set by sender Infer available network capacity cwnd: congestion window  Set W = min (cwnd, awnd)

TCP congestion control  Source calculates cwnd from indication of network congestion  Congestion indications Losses Delay Marks  Algorithms to calculate cwnd Tahoe, Reno, Vegas, …

TCP Congestion Controls  Tahoe (Jacobson 1988) Slow Start Congestion Avoidance Fast Retransmit  Reno (Jacobson 1990) Fast Recovery  Vegas (Brakmo & Peterson 1994) New Congestion Avoidance

TCP Tahoe (Jacobson 1988) SS time window CA : Slow Start : Congestion Avoidance : Threshold

Slow Start  Start with cwnd = 1 (slow start)  On each successful ACK increment cwnd cwnd  cnwd + 1  Exponential growth of cwnd each RTT: cwnd  2 x cwnd  Enter CA when cwnd >= ssthresh

Congestion Avoidance  Starts when cwnd  ssthresh  On each successful ACK: cwnd  cwnd + 1/cwnd  Linear growth of cwnd each RTT: cwnd  cwnd + 1

Packet Loss  Assumption: loss indicates congestion  Packet loss detected by Retransmission TimeOuts (RTO timer) Duplicate ACKs (at least 3) Packets Acknowledgements (Fast Retransmit)

Fast Retransmit  Wait for a timeout is quite long  Immediately retransmits after 3 dupACKs without waiting for timeout  Adjusts ssthresh flightsize = min(awnd, cwnd) ssthresh  max(flightsize/2, 2)  Enter Slow Start (cwnd = 1)

Summary: Tahoe  Basic ideas Gently probe network for spare capacity Drastically reduce rate on congestion Windowing: self-clocking for every ACK { if (W < ssthresh) then W++ (SS) else W += 1/W (CA) } for every loss { ssthresh = W/2 W = 1 } Seems a little too conservative?

TCP Reno (Jacobson 1990) CASS 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  Idea: each dupACK represents a packet having left the pipe (successfully received)  Enter FR/FR after 3 dupACKs Set ssthresh  max(flightsize/2, 2) Retransmit lost packet Set cwnd  ssthresh + ndup (window inflation) Wait till W=min(awnd, cwnd) is large enough; transmit new packet(s) On non-dup ACK, set cwnd  ssthresh (window deflation)  Enter CA

Example: FR/FR  Fast retransmit Retransmit on 3 dupACKs  Fast recovery Inflate window while repairing loss to fill pipe time S R cwnd8 ssthresh Exit FR/FR

Summary: Reno  Basic ideas dupACKs: halve W and avoid slow start dupACKs: fast retransmit + fast recovery Timeout: slow start slow start retransmit congestion avoidance FR/FR dupACKs timeout

Multiple loss in Reno?  On 3 dupACKs, receiver has packets 2, 4, 6, 8, cwnd=8, retransmits pkt 1, enter FR/FR  Next dupACK increment cwnd to 9  After a RTT, ACK arrives for pkts 1 & 2, exit FR/FR, cwnd=5, 8 unack’ed pkts  No more ACK, sender must wait for timeout 1 2 time S D FR/FR unack’d pkts timeout

New Reno Fall & Floyd ‘96, (RFC 2583)  Motivation: multiple losses within a window Partial ACK takes Reno out of FR, deflates window Sender may have to wait for timeout before proceeding  Idea: partial ACK indicates lost packets Stays in FR/FR and retransmits immediately Retransmits 1 lost packet per RTT until all lost packets from that window are retransmitted Eliminates timeout

Steady state:Fair? Unfair?

Delay-based TCP: Vegas (Brakmo & Peterson 1994)  Reno with a new congestion avoidance algorithm  Converges (provided buffer is large) ! SS time window CA

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 Congestion avoidance  Each source estimates number of its own packets in pipe from RTT  Adjusts window to maintain estimate # of packets in queues between  and 

Implications  Congestion measure = end-to-end queueing delay  At equilibrium Zero loss Stable window at full utilization Nonzero queue, larger for more sources  Convergence to equilibrium Converges if sufficient network buffer 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  UDP header/TCP header  TCP 3-way/4-way handshake  ARQ: Go-back-N/selective repeat  Tahoe/Reno/New Reno/Vegas/FAST -- useful details for your project  Simply model of AIMD

40 Why both TCP and UDP?  Most applications use TCP, as this avoids re- inventing error recovery in every application  But some applications do not need TCP For example: Voice applications Some packet loss is fine. Packet retransmission introduces too much delay. 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.