480 likes | 621 Views
Transport Layer – TCP. UIUC CS438: Communication Networks Summer 2014 Fred Douglas Slides: Fred , Kurose&Ross (sometimes edited), Caesar&many others (also edited). Recap: components of a solution. Checksums (for error detection) Timers (for loss detection) Acknowledgments
E N D
Transport Layer – TCP UIUC CS438: Communication Networks Summer 2014 Fred Douglas Slides: Fred, Kurose&Ross(sometimes edited), Caesar&many others (also edited)
Recap: components of a solution • Checksums (for error detection) • Timers (for loss detection) • Acknowledgments • cumulative • selective • Sequence numbers (duplicates, windows) • Sliding Windows (for efficiency)
What does TCP do? Most of our previous tricks + a few differences • Sequence numbers are byte offsets • Sender and receiver maintain a sliding window • Receiver sends cumulative acknowledgements (like GBN) • Receivers do not drop out-of-sequence packets (like SR) • Sender maintains a single retx. timer • Introduces timeout estimation algorithms • Introduces fast retransmit : optimization that uses duplicateACKs to trigger early retx.
TCP Header Source port Destination port Recall: used to mux and demux Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data
What does TCP do? Most of our previous tricks + a few differences • Checksum • Sequence numbers are byte offsets • Sender and receiver maintain a sliding window • Receiver sends cumulative acknowledgements (like GBN) • Sender maintains a single retx. timer • Introduces timeout estimation algorithms • Receivers do not drop out-of-sequence packets (like SR) • Introduces fast retransmit : optimization that uses duplicateACKs to trigger early retx.
TCP Header – Checksum Source port Destination port Sequence number Acknowledgment Computed overheader and data Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data
What does TCP do? Most of our previous tricks + a few differences • Checksum • Sequence numbers are byte offsets • Sender and receiver maintain a sliding window • Receiver sends cumulative acknowledgements (like GBN) • Sender maintains a single retx. timer • Introduces timeout estimation algorithms • Receivers do not drop out-of-sequence packets (like SR) • Introduces fast retransmit : optimization that uses duplicateACKs to trigger early retx.
TCP Header – Sequence # Source port Destination port Starting byte offsetof data carried in thissegment Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data
TCP “Stream of Bytes”Service… Application @ Host A Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 Application @ Host B
…Provided Using TCP “Segments” Host A Byte 0 Byte 1 Byte 2 Byte 3 Byte 80 • Nagle’s algorithm: send segment when: • Segment full (Max Segment Size), • Not full, but times out TCP Data TCP Data Host B Byte 0 Byte 1 Byte 2 Byte 3 Byte 80
Timeout for Terminology • We have many names for “a chunk of data” • Segment: TCP • Datagram: IP • Packet: IP, generic • Frame: Ethernet Ethernet frame IP packet (or datagram) TCP segment (payload is some application data)
TCP Segment IP Data IP Hdr TCP Data (segment) TCP Hdr • IP packet • No bigger than Maximum Transmission Unit (MTU) • E.g., up to 1500 bytes with Ethernet • TCP packet • IP packet with a TCP header and data inside • TCP header 20 bytes long • TCP segment • No more than Maximum Segment Size (MSS) bytes • E.g., up to 1460 consecutive bytes from the stream • MSS = MTU – (IP header) – (TCP header)
Sequence Numbers ISN (initial sequence number) k bytes Host A Sequence number = 1st byte in segment = ISN + k
Sequence Numbers ISN (initial sequence number) k Host A Sequence number = 1st byte in segment = ISN + k TCP HDR TCP Data ACK sequence number = next expected byte = seqno + length(data) TCP HDR TCP Data Host B
What does TCP do? Most of our previous tricks + a few differences • Checksum • Sequence numbers are byte offsets • Sender and receiver maintain a sliding window • Receiver sends cumulative acknowledgements (like GBN) • Sender maintains a single retx. timer • Introduces timeout estimation algorithms • Receivers do not drop out-of-sequence packets (like SR) • Introduces fast retransmit : optimization that uses duplicateACKs to trigger early retx.
TCP ACKs • ACK byte n: “I need byte n next” • Or: “I have received contiguously from start to n-1” Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data
Pattern when everything is fine • Sender: seqno=X, length=B • Receiver: ACK=X+B • Sender: seqno=X+B, length=B • Receiver: ACK=X+2B • Sender: seqno=X+2B, length=B • Seqno of next packet is same as last ACK field
What does TCP do? Most of our previous tricks + a few differences • Sequence numbers are byte offsets • Sender and receiver maintain a sliding window • Receiver sends cumulative acknowledgements (like GBN) • Sender maintains a single retx. timer • Introduces timeout estimation algorithms • Receivers do not drop out-of-sequence packets (like SR) • Introduces fast retransmit : optimization that uses duplicateACKs to trigger early retx.
TCP Timeouts + Timer Estimation • (Nothing to see here: header not involved) Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data
Retransmission Timeout • If the sender hasn’t received an ACK by timeout, retransmit the first packet in the window • How do we pick a timeout value?
Timing Illustration 1 1 Timeout RTT RTT 1 Timeout 1 Timeout too long inefficient Timeout too short duplicate packets
Retransmission Timeout • If haven’t received ack by timeout, retransmit the first packet in the window • How to set timeout? • Too long: connection has low throughput • Too short: retransmit packet that was just delayed • (When we learn about TCP’s congestion control, we’ll see that this also causes low throughput) • Solution: make timeout proportional to RTT • But how do we measure RTT?
time (seconds) TCP round trip time, timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT • exponential weighted moving average • influence of past sample decreases exponentially fast • typical value: = 0.125 RTT:gaia.cs.umass.edutofantasia.eurecom.fr RTT (milliseconds) sampleRTT EstimatedRTT
timeout interval:EstimatedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin estimate SampleRTT deviation from EstimatedRTT: TCP round trip time, timeout (typically, = 0.25) DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| TimeoutInterval = EstimatedRTT + 4*DevRTT estimated RTT “safety margin”
What does TCP do? Most of our previous tricks + a few differences • Sequence numbers are byte offsets • Sender and receiver maintain a sliding window • Receiver sends cumulative acknowledgements (like GBN) • Sender maintains a single retx. timer • Introduces timeout estimation algorithms • Receivers do not drop out-of-sequence packets (like SR) • Introduces fast retransmit : optimization that uses duplicateACKs to trigger early retx.
Receive Buffer • Why drop a perfectly good packet? • This requires a buffer • Buffers are finite: sender could overwhelm us Receiver’s received packets 1 2 3 5
Flow Control • “Bytes beyond n I am able to receive” Source port Destination port Sequence number Acknowledgment n Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data
What does TCP do? Most of our previous tricks + a few differences • Sequence numbers are byte offsets • Sender and receiver maintain a sliding window • Receiver sends cumulative acknowledgements (like GBN) • Sender maintains a single retx. timer • Introduces timeout estimation algorithms • Receivers do not drop out-of-sequence packets (like SR) • Introduces fast retransmit : optimization that uses duplicateACKs to trigger early retx.
Loss with cumulative ACKs • Sender sends packets with 100B and seqnos.: • 100, 200, 300, 400, 500, 600, 700, 800, 900, … • Assume the fifth packet (seqno 500) is lost, but no others • Stream of ACKs will be: • 200, 300, 400, 500, 500, 500, 500,…
Loss with cumulative ACKs • “Duplicate ACKs” are a sign of an isolated loss • The lack of ACK progress means 500 hasn’t been delivered • Stream of ACKs means some packets are being delivered • So, let’s resend upon receiving k duplicate ACKs • TCP uses k=3 • (It’s in case there’s a minor reordering • But that doesn’t happen much • You could start with k=1 and increase as you notice reordering • Doesn’t speed things up enough to matter)
TCP Connections: 3-way Handshake • TCP establishesconnections • There are somereliability issueswith establishing connections, so TCP uses handshaking techniques. • Why do we need to formally establish a connection? • Set up buffers • Set up Initial Sequence Numbers • Sequence #s: what sequence? (cf. UDP)
SYN SYN ACK ACK Data Data Establishing a TCP Connection B A • Three-way handshake to establish connection • Host A sends a SYN( “synchronize sequence numbers”) to host B • Host B returns an ACK, plus its own SYN(SYN ACK) • Host A sends anACK to acknowledge the SYN ACK Each host tells its ISN to the other host.
TCP Header Source port Destination port Sequence number Flags: SYN ACK FIN RST PSH URG Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data
Step 1: A’s Initial SYN Packet A’s port B’s port A’s Initial Sequence Number Flags: SYN ACK FIN RST PSH URG (Irrelevant since ACK not set) Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) A tells B it wants to open a connection…
Step 2: B’s SYN-ACK Packet B’s port A’s port B’s Initial Sequence Number Flags: SYN ACK FIN RST PSH URG ACK = A’s ISN plus 1 Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) B tells A it accepts, and is ready to hear the next byte… … upon receiving this packet, A can start sending data
Step 3: ACK of the SYN-ACK A’s port B’s port A’s Initial Sequence Number Flags: SYN ACK FIN RST PSH URG B’s ISN plus 1 Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) A tells B it’s likewise okay to start sending … upon receiving this packet, B can start sending data
SYN, SeqNum = x SYN + ACK, SeqNum = y, Ack = x + 1 ACK, Ack = y + 1 Sockets functions and the3-Way Handshake Server (respondent, “passive open”) Client (initiator, “active open”) bind(), listen() Into queue established by listen() connect() accept() Finds the SYN in listen()’s queue
What if the SYN Packet Gets Lost? • Suppose the SYN packet gets lost • Packet is lost inside the network, or: • Server discards the packet (e.g., it’s too busy) • Eventually, no SYN-ACK arrives • Sender sets a timer and waits for the SYN-ACK • … and retransmits the SYN if needed • How should the TCP sender set the timer? • Sender has no idea how far away the receiver is • Hard to guess a reasonable length of time to wait • SHOULD (RFCs 1122 & 2988) use default of 3 seconds • Some implementations instead use 6 seconds
SYN Loss and Web Downloads • User clicks on a hypertext link • Browser creates a socket and does a “connect” • The “connect” triggers the OS to transmit a SYN • If the SYN is lost… • 3-6 seconds of delay: can be very long • User may become impatient • … and click the hyperlink again, or click “reload” • User triggers an “abort” of the “connect” • Browser creates a new socket and another “connect” • Essentially, forces a faster send of a new SYN packet! • Sometimes very effective, and the page comes quickly
ACK ACK FIN FIN Connectionnow closed Connectionnow half-closed TIME_WAIT: Avoid reincarnation B will retransmit FIN if ACK is lost Normal Termination, One Side At A Time B • Finish (FIN) to close and receive remaining bytes • FINoccupies one byte in the sequence space • Other host acksthe byte to confirm • Closes A’s side of the connection, but notB’s • Until B likewise sends a FIN • Which A then acks ACK SYN ACK SYN ACK Data A time
ACK FIN + ACK FIN TIME_WAIT: Avoid reincarnation Can retransmitFIN ACK if ACK lost Connectionnow closed Normal Termination, Both Together B • Same as before, but B sets FIN with their ack of A’s FIN ACK SYN ACK SYN ACK Data A time
RST RST Data Abrupt Termination B • A sends a RESET (RST) to B • E.g., because application process on A crashed • That’s it • B does notack the RST • Thus, RST is not delivered reliably • And: any data in flight is lost • But: if B sends anything more, will elicit anotherRST ACK SYN ACK SYN ACK Data A time
TCP Header Source port Destination port Sequence number Flags: SYN ACK FIN RST PSH URG Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data
TCP State Transitions Data, ACK exchanges are in here
An Simpler View of the Client Side SYN (Send) CLOSED TIME_WAIT SYN_SENT Rcv. FIN, Send ACK Rcv. SYN+ACK,Send ACK ESTABLISHED FIN_WAIT2 FIN_WAIT1 Rcv. ACK,Send Nothing Send FIN
TCP Options Source port Destination port Tells you if options are present Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data Used to negotiateadditional features Some uses: MPTCP, TCP timestamps, Advertised window scaling, SACK (selective ACK), …
Transport paradigms: Streams, packets, and reliability • Are there any useful transport paradigms other than those of UDP and TCP? Packet Stream [not useful] UDP (Data updates, especially real-time) Reliable Unreliable TCP (Standard transfer of important data) SCTP (Control info: discrete messages structured by a protocol)