Internetworking Technologies

TDC365 Spring 2001 John Kristoff - DePaul University 1

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


Reliability illustrated


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


Adaptive retranmission illustrated


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


Window advertisement illustrated


Another view: the sliding window


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


TCP segment format


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


3-way handshake illustrated


TCP connection shutdown


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


Congestion avoidance illustrated


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

Documents

Internetworking Technologies