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

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

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

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

4. 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! UDP: User Datagram Protocol [RFC 768] 32 bits source port # dest port # Length, in bytes of UDP segment, including header checksum length Application data (message) UDP segment format

5. 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 …. UDP Checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment

6. 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 TCP: OverviewRFCs: 793, 1122, 1323, 2018, 2581

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

8. Seq. #’s: byte streamseq# 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. Seq=42, ACK=79, data = ‘C’ Seq=79, ACK=43, data = ‘C’ Seq=80, ACK=43, data = ‘X’ Seq=43, ACK=80 Seq=43, ACK=81 time TCP Terminology: Seq. #’s and ACKs Host B Host A User types ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ host ACKs receipt of echoed ‘C’ Assume Host B Sends data ‘x’ Back to Host A host ACKs Receipt of echoed ‘x’ simple telnet scenario

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. DATA(seq=x+1) ACK(seq=y+1) SYN(seq=x) ACK(seq=x+1), SYN(seq=y) Three Way Handshake (TWH) [Tomlinson 1975] Host A Host B SYN: indicates connection setup

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

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

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

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

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

16. CLOSED SYN SENT SYN ESTABLSIHED ACK SYN/ACK FIN ACK %netstat --tcp -a CLOSED LISTEN SYN RCVD ESTABLSIHED ESTABLSIHED ESTABLSIHED FINWAIT 1 FIN CLOSEWAIT LASTACK FINWAIT 2 TIMEWAIT ACK

17. 00sendbase = 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 • while (there are segments and window allow) • 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] 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 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 Discussion: Why delayed ACKs?

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

20. 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 freq. RTT TCP Timeout RTT

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

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?