1. Computer Networks CSE 434 Fall 2009 Sandeep K. S. Gupta Arizona State University http://impact.asu.edu/cse434fa09.html http://impact.asu.edu Research Experience for Undergraduates (REU)

2. Announcements and Agenda  Programming Assignment Due Date  Next Class Presentations Start  Remember to email presentation slides to TA by 8am the morning of presentation  Peer evaluation of presentation – everyone is expected to be present  Transport Layer (Cont.)  TCP Congestion Control Fairness

3. TCP reliable data transfer r TCP creates rdt service on top of IP’s unreliable service r pipelined segments r cumulative ACKs r TCP uses single retransmission timer r retransmissions are triggered by: m timeout events m duplicate ACKs r initially consider simplified TCP sender: m ignore duplicate ACKs m ignore flow control, congestion control

4. TCP sender events: data rcvd from app: r create segment with seq # r seq # is byte-stream number of first data byte in segment r start timer if not already running (think of timer as for oldest unACKed segment)  expiration interval: TimeOutInterval timeout: r retransmit segment that caused timeout r restart timer ACK rcvd: r if acknowledges previously unACKed segments m update what is known to be ACKed m start timer if there are outstanding segments

5. TCP: retransmission scenarios Host A Seq=100, 20 bytes data ACK=100 time premature timeout Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=92 timeout ACK=120 Host A Seq=92, 8 bytes data ACK=100 loss timeout lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 time Seq=92 timeout SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100

6. TCP retransmission scenarios (more) Host A Seq=92, 8 bytes data ACK=100 loss timeout Cumulative ACK scenario Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120

7. TCP ACK generation [RFC 1122, RFC 2581] Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. #. Gap detected Arrival of segment that partially or completely fills gap TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap

8. Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate ACKs. m sender often sends many segments back-to- back m if segment is lost, there will likely be many duplicate ACKs for that segment r If sender receives 3 ACKs for same data, it assumes that segment after ACKed data was lost: m fast retransmit: resend segment before timer expires

9. Host A timeout Host B time X resend seq X2 seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 ACK x1 triple duplicate ACKs

10. TCP Flow control: how it works (suppose TCP receiver discards out-of-order segments)  unused buffer space: = rwnd = RcvBuffer-[LastByteRcvd - LastByteRead]  receiver: advertises unused buffer space by including rwnd value in segment header  sender: limits # of unACKed bytes to rwnd m guarantees receiver’s buffer doesn’t overflow IP datagrams TCP data (in buffer) (currently) unused buffer space application process rwnd RcvBuffer

11. Need for Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle” r different from flow control! r manifestations: m lost packets (buffer overflow at routers) m long delays (queueing in router buffers) r a top-10 problem!

12. Approaches towards congestion control end-end congestion control: r no explicit feedback from network r congestion inferred from end-system observed loss, delay r approach taken by TCP network-assisted congestion control: r routers provide feedback to end systems m single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) m explicit rate sender should send at two broad approaches towards congestion control:

13. Case study: ATM ABR congestion control ABR: available bit rate: r “elastic service” r if sender’s path “underloaded”: m sender should use available bandwidth r if sender’s path congested: m sender throttled to minimum guaranteed rate RM (resource management) cells: r sent by sender, interspersed with data cells r bits in RM cell set by switches (“network-assisted”) m NI bit: no increase in rate (mild congestion) m CI bit: congestion indication r RM cells returned to sender by receiver, with bits intact

14. Case study: ATM ABR congestion control r two-byte ER (explicit rate) field in RM cell m congested switch may lower ER value in cell m sender’ send rate thus maximum supportable rate on path r EFCI bit in data cells: set to 1 in congested switch m if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell

15. TCP congestion control: r goal: TCP sender should transmit as fast as possible, but without congesting network m Q: how to find rate just below congestion level r decentralized: each TCP sender sets its own rate, based on implicit feedback: m ACK: segment received (a good thing!), network not congested, so increase sending rate m lost segment: assume loss due to congested network, so decrease sending rate

16. TCP congestion control: bandwidth probing r “probing for bandwidth”: increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate m continue to increase on ACK, decrease on loss (since available bandwidth is changing, depending on other connections in network) ACKs being received, so increase rate X X X X X loss, so decrease rate sending rate time r Q: how fast to increase/decrease? m details to follow TCP’s “sawtooth” behavior

17. TCP Congestion Control: details r sender limits rate by limiting number of unACKed bytes “in pipeline”:  cwnd: differs from rwnd (how, why?)  sender limited by min(cwnd,rwnd) r roughly,  cwnd is dynamic, function of perceived network congestion rate = cwnd RTT bytes/sec LastByteSent-LastByteAcked  cwnd cwnd bytes RTT ACK(s)

18. TCP Congestion Control: more details segment loss event: reducing cwnd r timeout: no response from receiver  cut cwnd to 1 r 3 duplicate ACKs: at least some segments getting through (recall fast retransmit)  cut cwnd in half, less aggressively than on timeout ACK received: increase cwnd r slowstart phase: m increase exponentially fast (despite name) at connection start, or following timeout r congestion avoidance: m increase linearly

19. TCP Slow Start  when connection begins, cwnd = 1 MSS m example: MSS = 500 bytes & RTT = 200 msec m initial rate = 20 kbps r available bandwidth may be >> MSS/RTT m desirable to quickly ramp up to respectable rate r increase rate exponentially until first loss event or when threshold reached  double cwnd every RTT  done by incrementing cwnd by 1 for every ACK received Host A one segment RTT Host B time two segments four segments

20. Transitioning into/out of slowstart ssthresh: cwnd threshold maintained by TCP  on loss event: set ssthresh to cwnd/2  remember (half of) TCP rate when congestion last occurred  when cwnd >= ssthresh : transition from slowstart to congestion avoidance phase slow start timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment  cwnd > ssthresh cwnd = cwnd+MSS dupACKcount = 0 transmit new segment(s),as allowed new ACK dupACKcount++ duplicate ACK  cwnd = 1 MSS ssthresh = 64 KB dupACKcount = 0 congestion avoidance

21. TCP: congestion avoidance  when cwnd > ssthresh grow cwnd linearly  increase cwnd by 1 MSS per RTT m approach possible congestion slower than in slowstart  implementation: cwnd = cwnd + MSS/cwnd for each ACK received  ACKs: increase cwnd by 1 MSS per RTT: additive increase  loss: cut cwnd in half (non-timeout-detected loss ): multiplicative decrease AIMD AIMD: Additive Increase Multiplicative Decrease

22. TCP congestion control FSM: overview slow start congestion avoidance fast recovery cwnd > ssthresh loss: timeout loss: timeout new ACK loss: 3dupACK loss: 3dupACK loss: timeout

23. TCP congestion control FSM: details slow start congestion avoidance fast recovery timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment  cwnd > ssthresh cwnd = cwnd+MSS dupACKcount = 0 transmit new segment(s),as allowed new ACK cwnd = cwnd + MSS (MSS/cwnd) dupACKcount = 0 transmit new segment(s),as allowed new ACK. dupACKcount++ duplicate ACK ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment dupACKcount == 3 dupACKcount++ duplicate ACK ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment dupACKcount == 3 timeout ssthresh = cwnd/2 cwnd = 1 dupACKcount = 0 retransmit missing segment cwnd = cwnd + MSS transmit new segment(s), as allowed duplicate ACK cwnd = ssthresh dupACKcount = 0 New ACK  cwnd = 1 MSS ssthresh = 64 KB dupACKcount = 0

24. Popular “flavors” of TCP ssthresh TCP Tahoe TCP Reno Transmission round cwnd window size (in segments)

25. Summary: TCP Congestion Control  when cwnd < ssthresh, sender in slow-start phase, window grows exponentially.  when cwnd >= ssthresh, sender is in congestion- avoidance phase, window grows linearly.  when triple duplicate ACK occurs, ssthresh set to cwnd/2, cwnd set to ~ ssthresh  when timeout occurs, ssthresh set to cwnd/2, cwnd set to 1 MSS.

26. TCP throughput r Q: what’s average throughout of TCP as function of window size, RTT? m ignoring slow start r let W be window size when loss occurs. m when window is W, throughput is W/RTT m just after loss, window drops to W/2, throughput to W/2RTT. m average throughout:.75 W/RTT

27. fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 bottleneck router capacity R TCP connection 2 TCP Fairness

28. Why is TCP fair? Two competing sessions: r Additive increase gives slope of 1, as throughout increases r multiplicative decrease decreases throughput proportionally R R equal bandwidth share Connection 1 throughput Connection 2 throughput congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2

29. Fairness (more) Fairness and UDP r multimedia apps often do not use TCP m do not want rate throttled by congestion control r instead use UDP: m pump audio/video at constant rate, tolerate packet loss Fairness and parallel TCP connections r nothing prevents app from opening parallel connections between 2 hosts. r web browsers do this r example: link of rate R supporting 9 connections; m new app asks for 1 TCP, gets rate R/10 m new app asks for 11 TCPs, gets R/2 !

30. Synthesis: a day in the life of a web request r journey down protocol stack complete! m application, transport, network, link r putting-it-all-together: synthesis! m goal: identify, review, understand protocols (at all layers) involved in seemingly simple scenario: requesting www page m scenario: student attaches laptop to campus network, requests/receives www.google.com

31. A day in the life: scenario Comcast network 68.80.0.0/13 Google’s network 64.233.160.0/19 64.233.169.105 web server DNS server school network 68.80.2.0/24 browser web page

32. A day in the life… connecting to the Internet r connecting laptop needs to get its own IP address, addr of first-hop router, addr of DNS server: use DHCP router (runs DHCP) DHCP UDP IP Eth Phy DHCP UDP IP Eth Phy DHCP r DHCP request encapsulated in UDP, encapsulated in IP, encapsulated in 802.1 Ethernet r Ethernet frame broadcast (dest: FFFFFFFFFFFF ) on LAN, received at router running DHCP server r Ethernet demux’ed to IP demux’ed, UDP demux’ed to DHCP

33. A day in the life… connecting to the Internet r DHCP server formulates DHCP ACK containing client’s IP address, IP address of first-hop router for client, name & IP address of DNS server router (runs DHCP) DHCP UDP IP Eth Phy DHCP UDP IP Eth Phy DHCP r encapsulation at DHCP server, frame forwarded (switch learning) through LAN, demultiplexing at client Client now has IP address, knows name & addr of DNS server, IP address of its first-hop router r DHCP client receives DHCP ACK reply

34. A day in the life… ARP (before DNS, before HTTP) r before sending HTTP request, need IP address of www.google.com: DNS DNS UDP IP Eth Phy DNS r DNS query created, encapsulated in UDP, encapsulated in IP, encasulated in Eth. In order to send frame to router, need MAC address of router interface: ARP r ARP query broadcast, received by router, which replies with ARP reply giving MAC address of router interface r client now knows MAC address of first hop router, so can now send frame containing DNS query ARP query Eth Phy ARP ARP reply

35. A day in the life… using DNS DNS UDP IP Eth Phy DNS r IP datagram containing DNS query forwarded via LAN switch from client to 1 st hop router r IP datagram forwarded from campus network into comcast network, routed (tables created by RIP, OSPF, IS-IS and/or BGP routing protocols) to DNS server r demux’ed to DNS server r DNS server replies to client with IP address of www.google.com Comcast network 68.80.0.0/13 DNS server DNS UDP IP Eth Phy DNS

36. A day in the life… TCP connection carrying HTTP HTTP TCP IP Eth Phy HTTP r to send HTTP request, client first opens TCP socket to web server r TCP SYN segment (step 1 in 3-way handshake) inter- domain routed to web server r TCP connection established! 64.233.169.105 web server SYN TCP IP Eth Phy SYN SYNACK r web server responds with TCP SYNACK (step 2 in 3- way handshake)

37. A day in the life… HTTP request/reply HTTP TCP IP Eth Phy HTTP r HTTP request sent into TCP socket r IP datagram containing HTTP request routed to www.google.com r IP datgram containing HTTP reply routed back to client 64.233.169.105 web server HTTP TCP IP Eth Phy r web server responds with HTTP reply (containing web page) HTTP r web page finally (!!!) displayed

38. let’s take a breath r journey down protocol stack complete (except PHY) r solid understanding of networking principles, practice r ….. could stop here …. but lots of interesting topics! m wireless m multimedia m security m network management