1 End-to-End Protocols (UDP, TCP, Connection Management)

2 Multiplexing/demultiplexing Multiplexing: gathering data from multiple app processes, enveloping data with header (later used for demultiplexing) source port #dest port # 32 bits application data (message) other header fields TCP/UDP segment format Demultiplexing: delivering received segments to correct app layer processes

3 Multiplexing/demultiplexing: Example Web client host A Web server B Web client host C Source IP: C Dest IP: B source port: x dest. port: 80 Source IP: C Dest IP: B source port: y dest. port: 80 Web server Source IP: A Dest IP: B source port: x dest. port: 80

4 UDP: User Datagram Protocol [RFC 768]  Often used for streaming multimedia apps  loss tolerant  rate sensitive  Other UDP uses  DNS  SNMP  Reliable transfer over UDP: add reliability at application layer  application-specific error recover! source port #dest port # 32 bits Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header

5 UDP Checksum Sender:  treat segment contents as sequence of 16-bit integers  checksum: addition (1’s complement sum) of segment contents  sender puts checksum value into UDP checksum field Receiver:  compute checksum of received segment  check if computed checksum equals checksum field value:  NO - error detected  YES - no error detected. But maybe errors nonethless? More later …. Goal: detect “errors” (e.g., flipped bits) in transmitted segment

6 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581  A sliding window protocol providing reliable, in-order byte steam:  no “message boundaries”  Flow controlled:  set window size according to the buffer size at the receiver  Congestion controlled  set window size according to the status of the network  End-to-end full duplex data transfer:  one sender, one receiver  bi-directional data flow using the same connection  MSS: maximum segment size  Connection-oriented:  Connection management

7 TCP Segment Structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F SR PAU head len not used Options (variable length) RST, SYN, FIN: connection management (reset, setup teardown commands) # bytes rcvr willing to accept ACK: ACK # valid counting by bytes of data (not segments!) Also in UDP URG: urgent data (generally not used) PSH: push data now (generally not used)

8 TCP Terminology: Seq. #’s and ACKs Seq. #’s:  byte stream seq# of the first byte of a segment ACKs:  seq# of the next byte expected from other side  cumulative ACK If no data to send: Use the seq# of the next byte. Host A Host B Seq=42, ACK=79, data = ‘C’ Seq=43, ACK=80 User types ‘C’ host ACKs receipt of echoed ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ time simple telnet scenario Seq=80, ACK=43, data = ‘X’ Seq=43, ACK=81 Assume Host B Sends data ‘x’ Back to Host A host ACKs Receipt of echoed ‘x’

9 Connection Management: Setup  The previous protocols assume we start with sequence number 0. Is there any problem with this approach?  The objectives of connection setup  agree on initial sequence numbers  agree on other initial parameters

10 Three Way Handshake (TWH) [Tomlinson 1975] Host A SYN(seq=x) Host B ACK(seq=x+1), SYN(seq=y) ACK(seq=y+1) DATA(seq=x+1) SYN: indicates connection setup

11 Scenarios with Duplicate Request Host A Host B ACK(seq=x+1), SYN(seq=y) REJECT(seq=y+1) SYN(seq=x) accept? no such request reject

12 Scenarios with Duplicate Request/Reply Host A Host B ACK(seq=x+1), SYN(seq=y) REJECT(seq=y+1) SYN(seq=x) accept? no such request reject ACK(seq=z)

13 Connection Management: Close FIN: indicates connection close Host A Host B FIN DATA no data is delivered after FIN

14 The First Attempt: Agreeing on Connection Close client I am done. Are you done too? server I am done too. Goodbye! init. close close Is this approach right?

15 Four Way Teardown Host A FIN Host B ACK FIN close closed timed wait

16 %netstat --tcp -a CLOSED LISTEN SYN RCVD SYN SYN/ACK ACK CLOSED SYN SENT ESTABLSIHED FIN ACK FIN WAIT 1 ESTABLSIHED CLOSE WAIT FIN LAST ACK FIN WAIT 2 TIME WAIT

17 00 sendbase = initial_sequence number agreed by TWH 01 nextseqnum = initial_sequence number by TWH 02 loop (forever) { 03 switch(event) 04 event: data received from application above 05 if (window allow send) 06 create TCP segment with sequence number nextseqnum 06 start timer for segment nextseqnum 07 pass segment to IP 08 nextseqnum = nextseqnum + length(data) else put packet in buffer 09 event: timer timeout for segment with sequence number y 10 retransmit segment with sequence number y 11 compute new timeout interval for segment y 12 restart timer for sequence number y 13 event: ACK received, with ACK field value of y 14 if (y > sendbase) { /* cumulative ACK of all data up to y */ 15 cancel all timers for segments with sequence numbers < y 16 sendbase = y 17 while (there are segments and window allow) 18 sent a segment as in line 04; 18 } 19 else { /* y==sendbase, duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ TCP: reliable data transfer Simplified TCP sender

18 TCP Receiver: ACK Generation [RFC 1122, RFC 2581] Event in-order segment arrival, no gaps, everything else already ACKed in-order segment arrival, no gaps, one delayed ACK pending out-of-order segment arrival 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 (this called delayed ACK) immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap Discussion: Why delayed ACKs?

19 TCP: Retransmission Scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout time lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 Host A Seq=100, 20 bytes data ACK=100 Seq=92 timeout premature timeout, cumulative ACKs Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=100 timeout ACK=120

20 TCP Timeout Q: how to set TCP timeout value?  too short: premature timeout  unnecessary retransmissions  too long: slow reaction to segment loss  even worse: RTT fluctuates Q: how to estimate RTT?  SampleRTT : measured time from segment transmission until ACK receipt  ignore retransmissions, cumulatively ACKed segments  SampleRTT will vary, want a “smoother” estimated RTT  use several recent measurements, not just current SampleRTT  Using the average of SampleRTT will generate many timeouts due to network variations  consider variance as well RTT freq.

21 TCP Timeout: Initial Timeout EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT  exponential weighted moving average  influence of given sample decreases exponentially fast  typical value of x:  Estimate the variance of RTT Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|  Estimate the average of RTT  Set initial timeout value

22 An Example of Initial Timeout timeout value per packet round-trip time

23 TCP Timeout: Repeated Retransmission  Exponential backoff:  Double timeout value after each retransmission  Max 64 seconds  Max 12 restransmits  Discussion: why exponential backoff?