1
play

1 TCP sender events: TCP reliable data transfer data rcvd from - PDF document

Jul 19, 2023 •257 likes •311 views

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 point-to-point: full duplex data: bi-directional data flow in one sender, one receiver same connection reliable, in-order byte TCP MSS: maximum segment steam: size no

  1. TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 ❒ point-to-point: ❒ full duplex data: ❍ bi-directional data flow in ❍ one sender, one receiver same connection ❒ reliable, in-order byte TCP ❍ MSS: maximum segment steam: size ❍ no “message boundaries” ❒ connection-oriented: ❒ pipelined: ❍ handshaking (exchange of control msgs) init’s sender, ❍ TCP congestion and flow receiver state before data control set window size exchange ❒ send & receive buffers ❒ flow controlled: ❍ sender will not overwhelm application application receiver writes data reads data socket socket door door TCP TCP send buffer receive buffer segment Transport Layer Transport Layer 3-1 3-2 TCP segment structure TCP seq. #’s and ACKs 32 bits Seq. #’s: URG: urgent data Host A Host B counting source port # dest port # ❍ byte stream “number” (generally not used) by bytes of first byte in User sequence number Seq=42, ACK=79, data = ‘C’ ACK: ACK # of data segment’s data types acknowledgement number valid (not segments!) ‘C’ ACKs: host ACKs head not U A P R S F Receive window PSH: push data now receipt of ❍ seq # of next byte len used # bytes C ’ ‘ a = (generally not used) checksum expected from other a t ‘C’, echoes Urg data pnter d 4 3 , = rcvr willing C K A 9 , side = 7 back ‘C’ e q S RST, SYN, FIN: Options (variable length) to accept ❍ cumulative ACK connection estab host ACKs ❍ piggybacking (setup, teardown receipt Seq=43, ACK=80 Q: how receiver handles out-of- commands) application of echoed order segments ‘C’ data Internet ❍ A: TCP spec doesn’t checksum (variable length) say, - up to implementor time (as in UDP) simple telnet scenario Transport Layer 3-3 Transport Layer 3-4 TCP Round Trip Time and Timeout Example RTT estimation: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr Q: how to set TCP Q: how to estimate RTT? 350 timeout value? ❒ SampleRTT : measured time from segment transmission until ❒ longer than RTT 300 ACK receipt ❍ but RTT varies (milliseconds) ❍ ignore retransmissions ❒ too short: premature 250 ❒ SampleRTT will vary, want timeout RTT estimated RTT “smoother” ❍ unnecessary 200 ❍ average several recent retransmissions measurements, not just 150 ❒ too long: slow reaction current SampleRTT to segment loss 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Estimated RTT Transport Layer 3-5 Transport Layer 3-6 1

  2. TCP sender events: TCP reliable data transfer data rcvd from app: timeout: ❒ Create segment with ❒ retransmit segment ❒ TCP creates rdt ❒ Retransmissions are seq # that caused timeout service on top of IP’s triggered by: unreliable service ❍ timeout events ❒ seq # is byte-stream ❒ restart timer ❒ Pipelined segments ❍ duplicate acks number of first data Ack rcvd: byte in segment ❒ Initially consider ❒ Cumulative acks ❒ If acknowledges simplified TCP sender: ❒ start timer if not previously unacked ❒ TCP uses single ❍ ignore duplicate acks already running (think retransmission timer segments ❍ ignore flow control, of timer as for oldest ❍ update what is known congestion control unacked segment) to be acked ❍ start timer if there ❒ expiration interval: are outstanding TimeOutInterval Transport Layer segments Transport Layer 3-7 3-8 NextSeqNum = InitialSeqNum TCP: retransmission scenarios SendBase = InitialSeqNum TCP loop (forever) { sender switch(event) Host A Host A Host B Host B event: data received from application above (simplified) Seq=92, 8 bytes data create TCP segment with sequence number NextSeqNum Seq=92, 8 bytes data if (timer currently not running) Seq=92 timeout S e q = 1 start timer 0 0 , 2 0 b y t e s timeout d pass segment to IP ACK=100 a t a Comment: NextSeqNum = NextSeqNum + length(data) ACK=100 • SendBase-1: last X ACK=120 cumulatively loss event: timer timeout retransmit not-yet-acknowledged segment with ack’ed byte Seq=92, 8 bytes data Seq=92, 8 bytes data Sendbase smallest sequence number Example: start timer = 100 Seq=92 timeout • SendBase-1 = 71; SendBase ACK=120 = 120 event: ACK received, with ACK field value of y y= 73, so the rcvr ACK=100 if (y > SendBase) { wants 73+ ; SendBase = y y > SendBase, so SendBase if (there are currently not-yet-acknowledged segments) SendBase start timer that new data is = 100 = 120 premature timeout } acked time time lost ACK scenario } /* end of loop forever */ Transport Layer 3-9 Transport Layer 3-10 TCP ACK generation [RFC 1122, RFC 2581] TCP retransmission scenarios (more) Host A Host B Event at Receiver TCP Receiver action Seq=92, 8 bytes data Arrival of in-order segment with Delayed ACK. Wait up to 500ms expected seq #. All data up to for next segment. If no next segment, ACK=100 timeout Seq=100, 20 bytes data expected seq # already ACKed send ACK X loss Immediately send single cumulative Arrival of in-order segment with expected seq #. One other ACK, ACKing both in-order segments segment has ACK pending ACK=120 SendBase = 120 Arrival of out-of-order segment Immediately send duplicate ACK, higher-than-expect seq. # . indicating seq. # of next expected byte Gap detected time Arrival of segment that Immediate send ACK, provided that Cumulative ACK scenario partially or completely fills gap segment startsat lower end of gap Transport Layer 3-11 Transport Layer 3-12 2

  3. Fast Retransmit TCP Flow Control flow control sender won’t overflow ❒ Time-out period ❒ If sender receives 3 ❒ receive side of TCP receiver’s buffer by often relatively long: ACKs for the same connection has a transmitting too much, too fast data, it supposes that receive buffer: ❍ long delay before resending lost packet segment after ACKed ❒ speed-matching ❒ Detect lost segments data was lost: service: matching the via duplicate ACKs. ❍ fast retransmit: resend send rate to the segment before timer ❍ Sender often sends expires receiving app’s drain many segments back-to- back ❒ app process may be rate ❍ If segment is lost, slow at reading from there will likely be buffer many duplicate ACKs. Transport Layer Transport Layer 3-13 3-14 TCP Flow control: how it works TCP Connection Management ❒ Rcvr advertises spare Recall: TCP sender, receiver establish “connection” room by including value before exchanging data segments of RcvWindow in ❒ initialize TCP variables: segments ❍ seq. #s ❒ Sender limits unACKed (Suppose TCP receiver ❍ buffers, flow control info (e.g. RcvWindow ) data to RcvWindow discards out-of-order segments) ❍ guarantees receive ❒ client: connection initiator buffer doesn’t overflow Socket clientSocket = new Socket("hostname","port ❒ spare room in buffer number"); = RcvWindow ❒ server: contacted by client = RcvBuffer-[LastByteRcvd - Socket connectionSocket = welcomeSocket.accept(); LastByteRead] Transport Layer 3-15 Transport Layer 3-16 TCP Connection Management TCP Connection Management (cont.) Three way handshake: Closing a connection: client server close Step 1: client host sends TCP SYN segment to server client closes socket: FIN ❍ specifies initial seq # clientSocket.close(); ❍ no data ACK Step 1: client end system close Step 2: server host receives SYN, replies with SYNACK FIN sends TCP FIN control segment segment to server ❍ server allocates buffers timed wait ACK Step 2: server receives ❍ specifies server initial seq. # FIN, replies with ACK. Step 3: client receives SYNACK, replies with ACK segment, Closes connection, sends which may contain data closed FIN. Transport Layer 3-17 Transport Layer 3-18 3

  4. TCP Connection Management (cont.) Step 3: client receives client server FIN, replies with ACK. closing FIN ❍ Enters “timed wait” - will respond with ACK ACK closing to received FINs FIN Step 4: server, receives timed wait ACK. Connection closed. ACK closed Note: with small modification, can handle closed simultaneous FINs. Transport Layer 3-19 4

Recommend

More recommend