Lecture 3 The Transport Control Protocol (TCP) Antonio Cianfrani DIET Department Networking Group netlab.uniroma1.it

Transcription

1 Lecture 3 The Transport Control Protocol (TCP) Antonio Cianfrani DIET Department Networking Group netlab.uniroma1.it

2 TCP segment structure URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # head len sequence number acknowledgement number not used UAP R S F checksum rcvr window size ptr urgent data Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept

3 Reliable data transfer Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt): Errors Delays Packet loss

4 Bit errors Underlying channel may flip bits in packet recall: UDP checksum to detect bit errors the question: how does the sender know that an error occurs?: acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK

5 ACK/NACK corrupted What happens if ACK/NAK corrupted? sender doesn t know what happened at receiver! just retransmit: possible duplicate What to do? sender ACKs/NAKs receiver s ACK/NAK? What if sender ACK/NAK lost? retransmit, but this might cause retransmission of correctly received pkt! Handling duplicates: sender adds sequence number to each pkt sender retransmits current pkt if ACK/NAK garbled receiver discards (doesn t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for receiver response

6 Sequence Number Sender: seq # added to pkt two seq. # s (0,1) will suffice. must check if received ACK/NAK corrupted Receiver: must check if received packet is duplicate note: receiver can not know if its last ACK/NAK received OK at sender NAK-free instead of NAK, receiver sends ACK for last pkt received OK receiver must explicitly include seq # of pkt being ACKed

7 Channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmissions will be of help, but not enough Q: how to deal with loss? Approach: sender waits reasonable amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission will be duplicate, but use of seq. # s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer

8 Reliable data transfer protocol

9 Reliable data transfer protocol

10 Pipelined protocols Pipelining: sender allows multiple, in-flight, yet-to-beacknowledged pkts range of sequence numbers must be increased buffering at sender (Transm. Window) and/or receiver Two generic forms of pipelined protocols: go-back-n: cumulative ACK, discard out-of-order packets selective repeat: selective ACK, accept out-of-order packets Rcv Buffer

11 Go-Back-N: sender Sender: k-bit seq # in pkt header window of up to N, consecutive unack ed pkts allowed ACK(n): ACKs all pkts up to, including seq # n. Cumulative ACK timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window

12 Go-Back-N: receiver The Receiver is simple: ACK-only: always send ACK for correctly-received pkt with highest in-order seq # may generate duplicate ACKs need only remember expectedseqnum out-of-order pkt: discard (don t buffer) -> no receiver buffering! ACK pkt with highest in-order seq #

13 Selective Repeat

14 Selective Repeat receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer sender only resends pkts for which ACK not received sender timer for each unacked pkt sender window N consecutive seq # s again limits seq #s of sent, unacked pkts

15 Selective repeat sender data from above : if next available seq # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+n]: mark pkt n as received if n smallest unacked pkt, advance window base to next unacked seq # receiver pkt n in [rcvbase, rcvbase+n-1] send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n in [rcvbase-n,rcvbase-1] ACK(n) otherwise: ignore

16 TCP seq. numbers and ACKs Seq. # s: ACKs: byte stream number of first byte in segment s data seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments No specification in TCP standard, up to implementations Loss: Timeout or Three Duplicate ACKs User types C host ACKs receipt of echoed C Host A Host B simple telnet scenario host ACKs receipt of C, echoes back C time

17 timeout Seq=100 timeout Seq=92 timeout TCP: retransmission scenarios Host A Host B Host A Host B X loss time lost ACK scenario time premature timeout, cumulative ACKs

18 TCP Flow Control flow control sender won t overrun receiver s buffers by transmitting too much, too fast RcvBuffer = size or TCP Receive Buffer RcvWindow = amount of spare room in Buffer receiver: explicitly informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment sender: keeps the amount of transmitted, unacked data less than most recently received RcvWindow receiver buffering

19 Principles of Congestion Control Congestion: informally: too many sources sending too much data too fast for network to handle different from flow control! Leads to: lost packets (buffer overflow at routers) long delays (queueing in router buffers) Congestion Window (Congwin) to limit the transmission rate

20 TCP congestion control probing for usable bandwidth: ideally: transmit as fast as possible (Congwin as large as possible) without loss increase Congwin until loss (congestion) loss: decrease Congwin, then begin probing (increasing) again two phases slow start congestion avoidance important variables: Congwin threshold: defines threshold between the slow start phase and the congestion control phase

21 RTT TCP Slowstart Slowstart algorithm Host A Host B initialize: Congwin = 1 for (each segment ACKed) Congwin=2Congwin until (loss event OR CongWin > threshold) exponential increase (per RTT) in window size (not so slow!) loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) time

22 TCP Congestion Avoidance Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart

23 TCP Tahoe and TCP Reno TCP Tahoe: Loss event back to slow start TCP Reno: Loss event revealed by 3 Duplicate ACKs window to threshold value and increase by 1 (Congestion Avoidance)

24 Congwin (in segments) TCP Tahoe vs TCP Reno Congestion avoidance Congestion avoidance Threshold ( ssthresh ) Threshold Threshold ( ssthresh Threshold) Slow start Rilevazione Loss di evento di perdita Esempio di andamento seguito da TCP Reno se la perdita è stata rilevata dalla ricezione TCP Reno: di 3 duplicate ACK duplicati ACKs Andamento seguito se la perdita è stata rilevata da un TO e, TCP Tahoe in TCP ogni Reno: caso, Timeout da Tahoe Number of Transmissions

25 Flow and Congestion Flow control procedure computes RcvWindow Congestion control procedure computes Congwin Transm. window = min [RcvWindow,Congwin]

26 TCP Connection Management TCP sender, receiver establish connection before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) Three way handshake: Step 1: client end system sends TCP SYN control segment to server specifies initial seq # Step 2: server end system receives SYN, replies with SYNACK control segment ACKs received SYN allocates buffers specifies server-> receiver initial seq. # Step 3: client replies with ACK

27 TCP segment structure 32 bits ACK: ACK # valid SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) source port # dest port # head len sequence number acknowledgement number not used UAP R S F checksum rcvr window size ptr urgent data Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept