340 likes | 426 Views
Internetworking Technologies. Transmission Control Protocol (TCP). IP review. IP provides just enough 'connectedness' Global addressing Hop-by-hop routing IP over everything Ethernet, ATM, X.25, SONET, etc. Lack of state in the network Unreliable packet (datagram) switching.
E N D
Internetworking Technologies • Transmission Control Protocol (TCP)
IP review • IP provides just enough 'connectedness' • Global addressing • Hop-by-hop routing • IP over everything • Ethernet, ATM, X.25, SONET, etc. • Lack of state in the network • Unreliable packet (datagram) switching
TCP key features • Sequencing • Byte-stream delivery • Connection-oriented • Reliability
TCP feature summary Provides a completely reliable (no data duplication or loss), connection-oriented, full-duplex stream transport service that allows two application programs to form a connection, send data in either direction and then terminate the connection.
Apparent contradiction • IP offers best-effort (unreliable) delivery • TCP uses IP • TCP provides completely reliable transfer • How is this possible?
Achieving reliability • Reliable connection startup • Reliable data transfer • Sender starts a timer • Receiver sends ACK when data arrives • Sender retransmits if timer expires before ACK is returned • Reliable connection shutdown
How long to wait before retransmitting? • Time for ACK to return depends on: • Distance between sender/receiver • Network traffic conditions • End system conditions • Packets can be lost, damaged or fragmented • Traffic conditions can change rapidly
Solving the retransmission problem • Keep running average of round trip time (RTT) for each TCP connection • Current average (estimate) determines retransmission timer • How does each RTT affect the average? • This is known as adaptive retransmission • Key to TCP's success
Flow control • Match sending rate to receiver rate • TCP uses a sliding window • Receiver advertises available buffer space • Also known as the window • Sender can transmit a full window size before receiving an ACK
Window advertisement • Each ACK carries the current window size • Called the window advertisement • Can be zero (a closed window) • Interpretation of window advertisement: • Receiver: I can accept X octets or less unless I tell you otherwise
Byte stream sequencing • Each segment contains a sequence number • Sequencing helps ensure in-order delivery • TCP sequence numbers are fixed at 32 bits • Is the byte stream of limited size (232 bytes)? • Initial sequence numbers (ISN) are exchanged at connection startup • ACKs acknowledgement cumulative bytes
Application multiplexing • Separation of functionality from IP • In the beginning TCP and IP were one • No unused bits to encode application process • Cannot use OS dependent quality • Process ID • Task number • Job name • Semantics must work on all end systems
Port numbers • Separation of functionality from IP • In the beginning TCP and IP were one • No unused bits to encode application process • Cannot use OS dependent quality • Process ID • Task number • Job name • Semantics must work on all end systems
TCP ports • Each application assigned a unique integer • Server • Follows a standard (e.g. Well know ports) • Uses a well known port number • Usually uses lower port numbers • Client • Obtains unused port from protocol software • Usually uses high numbered ports
TCP connection startup • Uses a three message exchange • AKA 3-way handshake • Necessary and sufficient for unambiguous and reliable startup • Sequence number exchange is primary goal • Can also exchange other parameters • e.g. maximum segment size
Congestion • Flow control • Congestion control • Avoidance
Useful terms before proceding • Maximum segment size (MSS) • Window • Retransmission • Timer • Delayed ACK • Duplicate ACK
Congestion window • Sender based flow control • Rather than by a window advertisement • Sender uses min(cwnd, advertised window) • This is the transmission window • Infer network conditions and adjust • Use timers, ACKs and network feedback
TCP segment retransmission • TCP starts timer after sending a segment • If ACK returns, reset timer • If not, retransmit and set (timer = timer x 2) • This is backoff • Can't retransmit forever, error may occur • Timer is the estimate of round trip time (RTT) • Current, running average of RTT
Round trip time (RTT) • TCP measures RTT • TCP uses estimated RTT to calculate timers • If ACKs return quickly, timers are short • If loss occurs, recovery is quicker • The converse is also true • RTT too high = throughput suffers • RTT too low = unnecessary retransmits
TCP slow start • Initialize cwnd to 1 MSS • Increase cwnd by 1 MSS for every ACK • Not really that slow
TCP congestion avoidance • When timer expires (loss?), slow down! • Set ssthresh = (transmission window x ½) • Set cwnd = 1 • Transmit min(cwnd, transmission window) • Slow start until transmission window = sshtresh • Thereafter, increase cwnd by 1/cwnd per ACK
TCP fast retransmit • If 3 or more duplicate ACKs are received before timer has expired • Sender assumes loss • Assumes out of order packets had enough time to be reassembled • Retransmit without waiting for timer to expire • Enter TCP fast recovery
TCP fast recovery • Sender assumes data is still flowing • Due to the reception of duplicate ACKs • Loss was probably a temporary event • Go into congestion avoidance, not slow start • Just cut cwnd in half • Resume additive increase (1/cwnd) per ACK
Other mechanisms • Selective acknowledgements (SACK) • Traffic shaping • ACK pacing • AQM (FIFO and RED and variants) • ECN, ICMP source quench, back pressure • Fair queueing • Class/uality of service (CoS/QoS)
Congestion collapse • When network load increases and less actual work gets done due to packet drops • Fragmented packets are especially bad • As retransmissions increase, goodput drops