CS 5565 Network Architecture and Protocols

1. CS 5565Network Architecture and Protocols Godmar Back Lecture 21

2. Announcements • Project 1B due this Friday March 17, 11:59pm • Midterm March 22 • Handout on Wed • See sample midterm from last year • Reading Assignment: Chapter 3 • 3.5-3.8 TCP, except for 3.7.2 CS 5565 Spring 2006

3. Study of TCP: Outline • segment structure • reliable data transfer • flow control • connection management [ Network Address Translation ] [ Principles of congestion control ] • TCP congestion control CS 5565 Spring 2006

4. full duplex data: bi-directional data flow in same connection MSS: maximum segment size connection-oriented: handshaking (exchange of control msgs) init’s sender, receiver state before data exchange flow controlled: sender will not overwhelm receiver point-to-point: one sender, one receiver reliable, in-order byte stream: no “message boundaries” pipelined: TCP congestion and flow control set window size send & receive buffers TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 CS 5565 Spring 2006

5. 32 bits source port # dest port # sequence number acknowledgement number head len not used receive window U A P R S F checksum urg data pnter options (variable length) application data (variable length) TCP Segment Structure URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection establishment (setup, teardown commands) Internet checksum (as in UDP) CS 5565 Spring 2006

6. TCP creates rdt service on top of IP’s unreliable service Pipelined segments Cumulative acks TCP uses single retransmission timer Retransmissions are triggered by: timeout events duplicate acks Initially consider simplified TCP sender: ignore duplicate acks ignore flow control, congestion control TCP Reliable Data Transfer CS 5565 Spring 2006

7. Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn’t say, - up to implementor time TCP Seq. #’s and ACKs Host B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario CS 5565 Spring 2006

8. data rcvd from app: create segment with seq # seq # is byte-stream number of first data byte in segment start timer if not already running (think of timer as for oldest unacked segment) expiration interval: TimeOutInterval timeout: retransmit segment that caused timeout restart timer ack rcvd: If acknowledges previously unacked segments update what is known to be acked start timer if there are outstanding segments TCP Sender Events CS 5565 Spring 2006

9. NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ TCP sender(simplified) • Comment: • SendBase-1: last • cumulatively ack’ed byte • Example: • SendBase-1 = 71; so SendBase = 72, say Ack received with y= 73, so the rcvr acknowledges up to including 72, now wants 73+ ;y is > SendBase, soknow that new data is acked, set SendBase to 73 CS 5565 Spring 2006

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

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

12. TCP ACK generation[RFC 1122, RFC 2581] 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 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 CS 5565 Spring 2006

13. Nagle’s algorithm • Consider again apps writing byte-by-byte (or in small chunks) • If you send 1-byte segments with 20 byte TCP header overhead + overhead of lower layer headers –you get a huge waste of network capacity. • Nagle: • Transmit first byte (why?) • Buffer outgoing bytes until ack has been received – then send all at once • You can turn this off via • Use setsockopt (SOL_SOCKET, TCP_NODELAY) CS 5565 Spring 2006

14. Delayed ACK vs Nagle • These two mechanisms have nothing to do with each other • often confused, especially by various online sources • TCP_NODELAY means “disable Nagle”, not “disable delayed ACKs” • Delayed ACK: implemented by TCP Receiver • Delays sending an acknowledgement (because acks are cumulative, can reduce # of acks sent) • Nagle’s algorithm: implemented by TCP Sender • Delays sending actual data (so that more data can be fit into a single segment) CS 5565 Spring 2006