Presentation is loading. Please wait.

Presentation is loading. Please wait.

4//26/05CS1181 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r point-to-point: one sender, one receiver r connection-oriented:  exchange control msgs.

Similar presentations

Presentation on theme: "4//26/05CS1181 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r point-to-point: one sender, one receiver r connection-oriented:  exchange control msgs."— Presentation transcript:

1 4//26/05CS1181 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r point-to-point: one sender, one receiver r connection-oriented:  exchange control msgs first to initialize sender & receiver state r full duplex data delivery:  bi-directional data flow over the same connection r reliable, in-order byte steam delivery  no “message boundaries”  sender & receiver must buffer data r flow controlled  Prevent sender from flooding receiver r Congestion controlled  Reduce potential jam in the network Socket Interface application writes data TCP send buffer application reads data TCP receive buff TCP control parameters(state)

2 4//26/05CS1182 What defines a TCP connection r TCP uses 4 values to define a connection (a communication association) local-host-addr, local-port#, remote-host-addr, remote-port# r each of the two ends keeps state for on-going communication  sequence# for data sent, received, ack'ed, retransmission timer, flow & congestion window IP Ethernet UDPTCP

3 4//26/05CS1183 Issues To Consider r packets may be lost,duplicated,re-ordered r packets can be delayed arbitrarily long inside the network  the delay between two communicating ends is unknown beforehand and may vary over time r port numbers can be reused later  a later connection must not mistake packets from an earlier connection as its own

4 4//26/05CS1184 TCP segment format source port # dest port # 32 bits sequence number acknowledgement number rcvr window size ptr to urgent data checksum F SR PAU head len not used Options (variable length) ACK: ACK # field valid URG: urgent data (generally not used) PSH: push data now (generally not used) RST, SYN, FIN: connection estab. (setup, teardown commands) checksum (as in UDP) # bytes rcvr willing to accept counting by bytes of data IP header application data (variable length)

5 4//26/05CS1185 TCP Connection Establishment r initialize TCP control variables:  Initial seq. # used in each direction  Buffer size (rcvWindow) Three way handshake 1: client host sends TCP SYN segment to server  specifies initial seq #  Does not carry data 2: server receives SYN, replies with SYN_ACK and SYN control segment 3: client end sends SYN_ACK  May carry data client SYN (#) server SYN-ACK/SYN (#) SYN-ACK connect ( ) listen ( ) connection established

6 4//26/05CS1186 TCP Connection Close r Either end can initiate the close of its end of the connection at any time 1: one end (A) sends TCP FIN control segment to the other 2: the other end (B) receives FIN, replies with FIN_ACK; when it’s ready to close too, send FIN 3: A receives FIN, replies with FIN- ACK. 4:B receives FIN_ACK, close connection what problem does A have? client FIN server FIN-ACK close ( ) connection closed FIN close ( ) ? A B

7 4//26/05CS1187 Blue army Red army the well-known “two-army problem” Q: how can the 2 red armies agree on an attack time? r Fact: the last one who send a message does not whether the msg is delivered r Basic rule: one cannot send an ACK to acknowledge an ACK Red army

8 4//26/05CS1188 TCP Connection Close 1: one end (A) sends TCP FIN control segment to the other 2: the other end (B) receives FIN, replies with FIN_ACK; when it’s ready to close too, send FIN 3: A receives FIN, replies with ACK. 4:B receives FIN_ACK, close connection A Enters “timed wait”, waits for 2 min before deleting the connection state r Abort a connection: send “reset” to the other end, enter closed state immediately  All data assumed lost client FIN server FIN-ACK close ( ) connection closed FIN close ( ) timed wait A B

9 4//26/05CS1189 TCP client lifecycle TCP server lifecycle wait 2 min TCP Connection Management (cont)

10 4//26/05CS11810 CLOSED LISTEN SYN_RCVDSYN_SENT ESTABLISHED CLOSE_WAIT LAST_ACKCLOSING TIME_WAIT FIN_WAIT_2 FIN_WAIT_1 Passive openClose Send/SYN SYN/SYN + ACK SYN + ACK/ACK SYN/SYN + ACK ACK Close/FIN FIN/ACKClose/FIN FIN/ACK ACK + FIN/ACK Timeout after two segment lifetimes FIN/ACK ACK Close/FIN Close CLOSED Active open/SYN TCP state-transition diagram I-finished(M) I-finished(N) ACK (M+1) ack(N+1) wait for 2MSL before deleting the conn state Done A B

11 4//26/05CS11811 How to Set TCP Retransmission Timer r TCP sets rxt timer based on measured RTT SRTT: EstimatedRTT SRTT= (1-  ) x SRTT +  x SampleRTT r Setting retransmission timer:  SRTT plus “safety margin” Timer= SRTT + 4 X rttvar data ACK retrans. data SampleRTT ACK retrans. data Timeout! Timeout

12 4//26/05CS11812 After obtain a new RTT sample: r difference = SampleRTT - SRTT r SRTT = (1-  ) x SRTT +  x SampleRTT = SRTT +  x difference r rttvar = (1-  ) x rttvar +  x |difference| ) = rttvar +  (|difference| - rttvar) r Retransmission Timer (RTO) = SRTT + 4 x rttvar Typically:  = 1/8,  = 1/4

13 4//26/05CS11813 An Example sender receiver 3 4 Assuming SRTT = 500 msec, rttvar = 120, RTT(3)=600ms,  = |RTT - SRTT| = 100ms SRTT = 500 + 0.125 * 100 = 512.5 rttvar = 120 + 0.25 (100 - 120) = 115 RTO = SRTT + 4 * rttvar = 512.5 + 460 = 972.5 ms 600 RTT(4)=650ms,  = |RTT - SRTT| =137ms SRTT = 512 + 0.125 * 137 = 529 rttvar = rttvar + 0.25 (137 - 115) = 120 650

14 4//26/05CS11814 Example RTT estimation:

15 4//26/05CS11815 How to measure RTT in cases of retransmissions? Options r take the delay between first transmission and final ACK? r take the delay between last retransmission of segment(n) and ACK(n)? r Don’t measure? timeout RTT? S D

16 4//26/05CS11816 Karn’s algorithm in case of retransmission r do not take the RTT sample (do not update SRTT or rttvar) r double the retransmission timer value (RTO) after each timeout r Take RTT measure again upon next transmission (without retrans.)

17 4//26/05CS11817 One more question What initial SRTT, rttvar values to start with? r Currently by some engineered guessing r what if the guessed value too small?  Unnecessary retransmissions r what if the guessed value too large?  In case of first or first few packets being lost, wait longer than necessary before retransmission r current practice initial SRTT value: 3 sec, rttvar 3 sec when get first RTT, SRTT  RTT, rttvar= SRTT /2

18 4//26/05CS11818 TCP’s seq. #s and ACK #s Seq. #:  The number of first byte in segment’s data ACK #:  seq # of next byte expected from other side  cumulative ACK Host A Host B Seq=42, ACK=79, data Seq=79, ACK=52, data Seq=52, ACK=84 Host A sends 10byte data host ACKs receipt of 5B host B ACKs receipt of 10B data from A, and sends 5byte data time A simple example

19 4//26/05CS11819 How to guarantee seq. # uniqueness r sequence#s will eventually wrap around r TCP assumes Maximum Segment Lifetime ( MSL ) of 120 sec. r make sure that for the same [src-addr, src-port, dest-addr, dest-port] tuple, the same sequence number does not get reused within 2x MSL  assure that no two different data segments can bear the same sequence number, as long as data’s life time < 120 sec.

20 4//26/05CS11820 TCP : reliable data transfer simplified sender, assuming one way data transfer not flow/congestion control wait for event wait for event event: data received from application event: timeout for segment with seq # y event: ACK received, with ACK # y create, send segment retransmit segment ACK processing 00 SendBase = Initial_SeqNumber 01 NextSeqnum = Initial_SeqNumber 02 03 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with seq. number NextSeqNum 07 start timer for segment SextSeqNum 08 pass segment to IP 09 NextSeqNum = NextSeqNum + length(data) 10 event: timer timeout for segment with seq. number y 11 retransmit segment with sequence number y 12 compute new timeout interval for segment y 13 restart timer 14 event: ACK received, with ACK field value of y 15 if (y > SendBase) {/* cumulative ACK of all data up to y*/ 16SendBase = y 17If (any outstanding not-yet-ack'ed segments) 18 Start timer } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment count of duplicate ACKs received for y 21 if (count of dup. ACKS received for y = 3) { 22 resend segment with sequence number y 23 reset dup. count 24} 25 } /* end of loop forever */

21 4//26/05CS11821 Fast Retransmit r Time-out period often relatively long:  long delay before resending lost packet r Detect lost segments via duplicate ACKs.  Sender often sends many segments back-to-back  If segment is lost, there will likely be many duplicate ACKs. r If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost:  fast retransmit: resend segment before timer expires

22 4//26/05CS11822 TCP: retransmission scenarios Host A Seq=100, 20 bytes data ACK=100 time premature timeout Host B Seq=92, 8 bytes data ACK=120 Seq=92, 8 bytes data Seq=92 timeout ACK=120 Host A Seq=92, 8 bytes data ACK=100 loss timeout lost ACK scenario Host B X Seq=92, 8 bytes data ACK=100 time Seq=92 timeout SendBase = 100 SendBase = 120 SendBase = 120 Sendbase = 100

23 4//26/05CS11823 TCP retransmission scenarios (more) Host A Seq=92, 8 bytes data ACK=100 loss timeout Cumulative ACK scenario Host B X Seq=100, 20 bytes data ACK=120 time SendBase = 120 Host A Seq=92, 500 bytes data Fast RXT scenario Host B Seq=592, 500B data time X Seq=592, 500B data Seq=1092, 500B data Seq=1592, 500B data Seq=2092, 500B data ACK592 timeout ACK592 timeout

24 4//26/05CS11824 TCP Receiver: when to send ACK? EventTCP Receiver action in-order segment arrival, no gaps, everything earlier already ACKed delayed ACK: wait up to 500ms, If nothing arrived, send ACK in-order segment arrival, no gaps, one delayed ACK pending immediately send one cumulative ACK out-of-order arrival: higher-than- expect seq. #, gap detected send duplicate ACK, indicating seq. # of next expected byte arrival of segment that partially or completely fills a gap immediate ACK if segment starts at the lower end of the gap

25 4//26/05CS11825 TCP Flow Control Prevent sender from overrunning receiver’s buffer by transmitting too much too fast flow control throughput = window-size RTT bytes/sec receiver: informs sender of (dynamically changing) amount of free buffer space  RcvWindow field in TCP header sender: keeps the amount of transmitted, unACKed data no more than most recently received RcvWindow Special case: When RcvWindow = 0 sender can send a 1-byte segment receiver can respond with current size receiver buffer eventually freed  windown size increased

26 4//26/05CS11826 Design Choice: Counting bytes or counting packets? pro’s of counting bytes: flexibility r need a byte counter somewhere anyway r can repackage data for retransmission  e.g. first sent segment-1 with 200 bytes  300 more bytes are passed down from application  Segment-1 times out, send new segment with 500 byte data 200 300

27 4//26/05CS11827 Counting Bytes: con's r sequence number runs out faster  needs a larger sequence# field r easily fall into traps of transmitting small packets  network overhead goes up with the number of packets transmitted  silly window syndrome: receiver ACKed a single byte, causing sender to send single byte segment forever

28 4//26/05CS11828 Design Choices: Understand the consequence of the design r TCP sequence number: 32 bits  4 Gbytes  wrap-around time: 50 Kbps: ~20 hours Ethernet (10 Mbps): about an hour FDDI (100 Mbps): 6 minutes at 1Gbps: about 30 seconds r TCP window size: 16-bits  64Kbytes max assume RTT = 100 msec  can keep a channel of 5 Mbps fully utilized  OC3(155 Mbps) x 100 msec = 1.9 MB, need a window size at least 21 bits  1 Gbps x 100 msec =

29 4//26/05CS11829 M M M M H t H t H n H t H n H l Always Keeps the Big Picture in Mind application transport network link physical Web browser HTTP TCP Unreliable network data packet delivery Socket interface Application process Write bytes TCP Send buffer Application process Read bytes TCP Receive buffer segment Web server HTTP TCP Socket interface

Download ppt "4//26/05CS1181 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r point-to-point: one sender, one receiver r connection-oriented:  exchange control msgs."

Similar presentations

Ads by Google