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

Transcription

1 Lecture 4 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 3a-5

6 rdt2.1: discussion 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 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 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

12 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

13 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

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

15 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

16 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

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

18 AIMD TCP congestion avoidance: AIMD: additive increase, multiplicative decrease increase window by 1 per RTT decrease window by factor of 2 on loss event TCP Fairness Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 TCP connection 2 bottleneck router capacity R

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

20 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

21 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