Internet Protocol Stack. TCP: Transmission Control Protocol

Transcription

1 Internet Protocol tack application: supporting network applications HTTP, MTP, FTP, etc transport: endhost-endhost data transfer TCP, UP network: routing of datagrams from source to destination IP, routing protocols link: data transfer between neighboring network elements Ethernet, WiFi physical: bits on the wire application transport network link physical TCP: Transmission Control Protocol Provides reliability on connectionless datagram network: Link layer already provides sequencing and error control Why do we need to provide reliability again at the transport layer?

2 Need for EE Reliability EE Reliability Causes of unreliable delivery re-routed packets bit error dropped/lost packets (due to congestion) system reboots How to achieve reliable delivery? Reliable delivery requires tools:

3 equence Number With ARQ, packets must be numbered, why? equence number space is finite Issues: sequence space size sequence number wrap around 3 initial sequence number (IN) equence Number pace ize If we had only bits to keep track of sequence numbers: new? or rexmit? T MPL: Max Pkt Lifetime MPL A What prevention? 3

4 equence Number pace ize Let: A: time taken by receiver to ACK packet T: time sender continues retransmitting if ACK not received Maximum eqment Lifetime (ML): MPL + T + A Want: no seq number may be duplicated within an ML equence Number Wrap Around equence space is finite and sequence number can wrap around: pkt 3 queued/ delayed which is newer? Assuming s and s are not more than N/ apart, s > s if either: 0 N s > s and s s < N/, or s < s and s s > N/ 0 N 4

5 Required equence Number ize Require that if s > s, s and s are not more than N/ apart ( s s < N/) within an ML Let µ be the transmission bandwidth For TCP, N = 3 -, ie, seq number size n = 3 bits, want µ < (N/)/ML or n > µ*ml Example: F-NY MPL is 5 msec Let ML = min, for n = 3 bits, µ must be < 78 MB/s (43 Mbps) 0 N 0 N Initial equence Number (IN) In case a connection got reincarnated, we must choose an initial sequence number that will not cause packets from the old connection to interfere How can a connection be reincarnated? Possible solutions: 3 5

6 IN from ystem Clock Assume clock keeps ticking even when machine is down Want: no seq number may be duplicated within an ML eq # sequence # wraps around n Forbidden Region ML fast xmission wait for ML resynchronize slow xmission last time this seq# may be used connection start time clock tick What to do on hitting forbidden region? wait for ML before resuming transmission resynchronize sequence number either case, connection stalled TCP s Handling of IN Connection identified by both addresses and port numbers and initial sequence number Connection cannot be reused for ML time on connection tear-down, wait for ML (TIME-WAIT state) bind: Address already in use on reboot, do not create connection for ML ( minutes) on reboot, starts global IN from IN carried in YNchronization packet during connection establishment 6

7 Connection Establishment First try: ender estination reboot YN IN=X YN IN=Z Z+ Z+ Expected eq # EN = X+, ETABLIHE discard dropped, but connection with EN = X+ still ETABLIHE Lesson: connection request must be ACKed Connection Establishment econd try: ender estination discard stray YN IN=X YN IN=Y ACK X+ EN = X+ ETABLIHE Y+ Lesson: connection ACK must be ACKed or rejected 7

8 Connection Establishment Three-way handshake: ender EN = Y+ ETABLIHE YN IN=Y ACK X+ YN IN=X ACK Y+ estination EN = X+ ETABLIHE X+ YN uses a seq# Three-Way Handshake How three-way handshake solves the original problems: reboot YN IN=Z ender RT Y YN IN=X estination YN IN=Y ACK X+ RT Z discard ender stray YN IN=X YN IN=Y ACK X+ RT Y estination EN = X+ ETABLIHE 8

9 Connection Tear-down When to release a connection? Ie, how do you know the other side is done sending and all sent packets have arrived? Use 3-way handshake to tear-down connection: ender FIN X estination ACK X+ FIN Y FIN also uses a seq# ACK Y+ Connection Tear-down If the other side still has data to send: ender FIN X estination ACK X+ More data pkts from FIN Y ACK Y+ Why not send ACK X+ along with FIN Y? 9

10 Connection Tear-down till depends on timeout: ender estination ender estination FIN X FIN X ACK X+ FIN Y X FIN X ACK Y+ X ACK X+ FIN Y ACK X+ FIN Y times out and tears down connection unilaterally ACK Y+ Connection Tear-down till depends on timeout: ender FIN X estination after n attempts tears down connection unilaterally ACK X+ FIN Y X FIN X X FIN X ACK X+ FIN Y X times out and tears down connection unilaterally TCP connection tear-down depends on timers for correctness, but uses 3-way handshake for performance improvement 0

11 TCP Connection Management FM TCP client lifecycle TCP server lifecycle Mao W07 TCP Header 3 bits RT, YN, FIN: connection establishment (setup, teardown) number of 3-bit fields in header URG: urgent data pointer valid (generally not used) ACK: ACK # valid PH: push data now (like fflush()) required source port # dest port # sequence number acknowledgement number head not U A P R F len used checksum window size application data (variable length) urg data pointer options (variable length) counting by bytes of data (not segments!) receiver window size (rwnd, in bytes) end of urgent data, eg, ^C Maximum egment ize negotiation, default (minimum required) 536 bytes data

12 TCP Header Fields equence number: data is sent in segments (= packets with seq#) sequence numbers count bytes sent ACK may be piggy-backed on data packet Checksum: checksum computed including pseudo IP header (containing source and destination IP addresses, protocol, segment length) computed with all 0 s in the checksum field s complement of result stored in checksum field (aka Internet checksum) when checksum is computed at receiver, result is 0 Internet Checksum Example When adding numbers, a carryout from the most significant bit needs to be added to the result Example: add two 6-bit integers wraparound s complement sum s complement Internet Checksum Incremental update of checksum, eg, updating ttl: ~ (~checksum + ~ttl + ttl )

13 TCP Cumulative ACK ACKs the last byte received in-order tells sender the next-expected seq#, ie, if bytes 0 to i have been received, ACK says i+ subsequent out-of-order packets generate the same cumulative ACK: 8 bytes: seq# 0 0 bytes: seq# 8 0 bytes: seq# 8 0 bytes: seq# 8 ender x estination ack 8 ack 8 Advantage: lost ACK can be covered by later ACKs isadvantage: size of gap between two pkts not known to sender TCP Connection Establishment emo % sudo tcpdump i en host wwweecsumichedu 3

14 TCP Flow Control receive side of TCP connection has a receive buffer: flow control sender won t overflow receiver s buffer by transmitting too much, too fast application process may be slow at reading from the buffer Receiver advertises buffer space available by including the current value of rwnd in TCP header ender limits unacked data to rwnd guarantees receiver buffer doesn t overflow TCP Flow Control Problems Two flow-control problems: receiver too slow (silly-window syndrome) sender s data comes in small amount (Nagle s algorithm) illy-window syndrome: receiver window opens only by a small amount, hence sender can send only a small amount of data at a time ender 0 (size 000) 000 (000) 000 (500) estination w = 500 application reads out byte w = Why is this not good? 500 () 50 () application reads out byte w = 4

15 olution to illy-window yndrome on t advertise window until it opens significantly (> ½*M or ½*rwnd) Implementation alternatives: ACK with rwnd=0: sender probes after persistence timer goes off delayed ACK, but not more than 500 ms, or ACK every other segment (why?) persist timer ender 0 (000) 000 (000) 000 (500) probe 499 () estination w = 500 application reads out byte w = 0 w = 000 TCP elayed ACK Generation 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 elayed 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 Immediately send ACK, provided that segment starts at lower end of gap 5

16 Characteristics of Interactive Applications User sends only a small amount of data, eg, telnet sends one character at a time Problem: 40-byte header for every byte sent! olution: clumping, sender clumps data together, ie, sender waits for a reasonable amount of time before sending How long is reasonable? Nagle Algorithm send first segment immediately accumulate data until ACK returns, or ½ sender window or ½ M amount of data has been accumulated Advantages: bulk transfer is not held up data sent as fast as network can deliver Can be disabled by setsockopt(tcp_noelay) 6

17 Nagle Algorithm Nagle sends data as fast as network can deliver: round-trip time () ender 3 w pkts ACKs Receiver R 3 w round-trip time () ender to w+ Receiver R to w+ w+ bytes in s w+ bytes in s Retransmission Timeout ARQ depends on retransmission to achieve reliability Retransmission timeout (RTO) computed from roundtrip time (RTT) On the Internet, RTT of a path varies over time, due to: Varying RTT complicates the computation of: retransmission timeout (RTO) optimal sender s window size round-trip time () retransmission timeout ()!! ender 3 4 ACKs Pkts Receiver R 3 4 7

18 Implications of Bad RTO RTO too small: unnecessary retransmissions: RTO too big: lower throughput: ender Router R estination ender Router R estination A A X A Estimating RTT RTO must adapt to actual AN current RTT samplertt: time between when a segment is transmitted and when its ACK is received estimatedrtt computed by exponential weighted average estimatedrtt = α *currentrttestimate + (-α) *samplertt, where α is the weight: α : each sample changes the estimate only a little bit α 0: each sample influences the estimate heavily α is typically ⅞ (-½ 3, which allows for fast implementation) 8

19 Example RTT Estimation How to Compute RTO? First try: RTO = β RTT, with β typically or 3 Two problems: which packet to associate with an ACK in case of retransmission? ender pkt i pkt i estination? ack i RTTs spread too wide pdf pkts with these must be rexmitted mean = samples 9

20 ACK Ambiguity Which retransmitted packet to associate with an ACK? original packet: RTO can grow unbounded retransmitted packet: RTO shrinks ender 0 X estination ender 0 estination 0 X 0 X There is a feedback loop between RTO computation and RTT estimate ACK Ambiguity: Karn s Algorithm Karn s algorithm: adjust RTT estimate only from non-retransmitted samples however, ignoring retransmissions could lead to insensitivity to long delays so, back off RTO upon retransmission: RTO new = γ RTO old, γ typically = 0

21 RTT pread Too Wide RTT estimate computed using exponential weighted average gives only a good mean pdf pkts with these must be rexmitted = mean Jacobson s algorithm: estimate the variance in samplertt use the deviation in samplertt () in RTO computation new = α old + (-α) samplertt estimatedrtt compute new estimatedrtt RTO = estimatedrtt + 4 samples Timers Used in TCP TIME_WAIT: * ML persistence timer 3 RTO 4 keep-alive timer: probe if connection idle too long may be turned on/off and idle period may be set using setsockopt()