Data and Computer Communications

Chapter 20 Transport Protocols

Eighth Edition by William Stallings Lecture slides by Lawrie Brown

Transport Protocols
The foregoing observations should make us reconsider the widely held view that birds live only in the present. In fact, birds are aware of more than immediately present stimuli; they remember the past and anticipate the future. The Minds of Birds, Alexander Skutch

Transport Protocols
end-to-end

data transfer service shield upper layers from network details reliable, connection oriented

has greater complexity eg. TCP

best

effort, connectionless

datagram eg. UDP

Connection Oriented Transport Protocols

provides

establishment, maintenance & termination of a logical connection most common service used for a wide variety of applications is reliable but complex first discuss evolution from reliable to unreliable network services

Reliable Sequencing Network Service

assume virtually 100% reliable delivery by network service of arbitrary length messages

eg. reliable packet switched network with X.25 eg. frame relay with LAPF control protocol eg. IEEE 802.3 with connection oriented LLC service

transport service is a simple, end to end protocol between two systems on same network issues are: addressing, multiplexing, flow control, connection establishment and termination

Addressing
establish

identity of other transport entity by:

user identification (host, port)

a socket in TCP

transport entity identification (on host)

specify transport protocol (TCP, UDP)

host address of attached network device

in an internet, a global internet address

network number

transport

layer passes host to network layer

Finding Addresses
know

address ahead of time well known addresses

eg. common servers like FTP, SMTP etc

name

server

does directory lookup

sending

request to well known address which spawns new process to handle it

Multiplexing
of

upper layers (downward multiplexing)

so multiple users employ same transport protocol user identified by port number or service access point

may

also multiplex with respect to network services used (upward multiplexing)

eg. multiplexing a single virtual X.25 circuit to a number of transport service user

Flow Control

issues:

longer transmission delay between transport entities compared with actual transmission time delays communication of flow control info variable transmission delay so difficult to use timeouts
receiving user can not keep up receiving transport entity can not keep up

want TS flow control because:

which can result in buffer overflowing managing flow difficult because of gap between sender and receiver

Coping with Flow Control Requirements

do

nothing

segments that overflow are discarded sender fail to get ACK and will retransmit

refuse

further segments

triggers network flow control but clumsy

use

fixed sliding window protocol

works well on reliable network does not work well on unreliable network

use

credit scheme

Credit Scheme

decouples flow control from ACK each octet has sequence number each transport segment has seq number (SN), ack number (AN) and window size (W) in header sends seq number of first octet in segment ACK includes (AN=i, W=j) which means

all octets through SN=i-1 acknowledged, want i next permission to send additional window of W=j octets

Credit Allocation

Sending and Receiving Perspectives

Establishment and Termination

need

connection establishment and termination procedures to allow:

each end to know the other exists negotiation of optional parameters triggers allocation of transport entity resources

Connection State Diagram

Connection Establishment

Connection Termination

either or both sides by mutual agreement graceful or abrupt termination if graceful, initiator must:

send FIN to other end, requesting termination place connection in FIN WAIT state when FIN received, inform user and close connection when receives FIN must inform TS user and place connection in CLOSE WAIT state when TS user issues CLOSE primitive, send FIN & close connection

other end must:

Unreliable Network Service

more difficult case for transport protocol since

segments may get lost segments may arrive out of order

examples include

IP internet, frame relay using LAPF, IEEE 802.3 with unacknowledge connectionless LLC ordered delivery, retransmission strategy, duplication detection, flow control, connection establishment & termination, crash recovery

issues:

Ordered Delivery
segments

may arrive out of order hence number segments sequentially TCP numbers each octet sequentially and segments are numbered by the first octet number in the segment

Retransmission Strategy

retransmission of segment needed because

segment damaged in transit segment fails to arrive

transmitter does not know of failure receiver must acknowledge successful receipt

can use cumulative acknowledgement for efficiency

sender times out waiting for ACK triggers re-transmission

Timer Value

fixed timer

based on understanding of network behavior can not adapt to changing network conditions too small leads to unnecessary re-transmissions too large and response to lost segments is slow should be a bit longer than round trip time
may not ACK immediately can not distinguish between ACK of original segment and re-transmitted segment conditions may change suddenly

adaptive scheme

Duplication Detection

if ACK lost, segment duplicated & re-transmitted receiver must recognize duplicates if duplicate received prior to closing connection

receiver assumes ACK lost and ACKs duplicate sender must not get confused with multiple ACKs need a sequence number space large enough to not cycle within maximum life of segment

Incorrect Duplicate Detection

Flow Control

credit allocation quite robust with unreliable net

can ack data & grant credit or just one or other lost ACK recovers on next received then send AN=i, W=j to reopen, but this is lost sender thinks window closed, receiver thinks it open

have problem if AN=i, W=0 closing window

solution is to use persist timer if timer expires, send something

could be re-transmission of previous segment

Connection Establishment
two

way handshake

A send SYN, B replies with SYN lost SYN handled by re-transmission ignore duplicate SYNs once connected

lost

or delayed data segments can cause connection problems

eg. segment from old connection

Two Way Handshake: Obsolete Data Segment

Two Way Handshake: Obsolete SYN Segment

Three Way Handshake: State Diagram

Three Way Handshake: Examples

Connection Termination

like connection need 3-way handshake misordered segments could cause:

entity in CLOSE WAIT state sends last data segment, followed by FIN FIN arrives before last data segment ceceiver accepts FIN, closes connection, loses data

need to associate sequence number with FIN receiver waits for all segments before FIN sequence number

Connection Termination Graceful Close

also

have problems with loss of segments and obsolete segments need graceful close which will: send FIN i and receive AN i receive FIN j and send AN j wait twice maximum expected segment lifetime

Failure Recovery

after restart all state info is lost may have half open connection

as side that did not crash still thinks it is connected

close connection using keepalive timer

wait for ACK for (time out) * (number of retries) when expired, close connection and inform user

send RST i in response to any i segment arriving user must decide whether to reconnect

have problems with lost or duplicate data

TCP

Transmission Control Protocol (RFC 793) connection oriented, reliable communication over reliable and unreliable (inter)networks two ways of labeling data: data stream push

user requires transmission of all data up to push flag receiver will deliver in same manner avoids waiting for full buffers indicates urgent data is upcoming in stream user decides how to handle it

urgent data signal

TCP Services
a

complex set of primitives:

incl. passive & active open, active open with data, send, allocate, close, abort, status passive open indicates will accept connections active open with data sends data with open

and

parameters:

incl. source port, destination port & address, timeout, security, data, data length, PUSH & URGENT flags, send & receive windows, connection state, amount awaiting ACK

TCP Header

TCP and IP
not

all parameters used by TCP are in its header TCP passes some parameters down to IP

precedence normal delay/low delay normal throughput/high throughput normal reliability/high reliability security

min

overhead for each PDU is 40 octets

TCP Mechanisms Connection Establishment

three

way handshake

SYN, SYN-ACK, ACK

connection

determined by source and destination sockets (host, port) can only have a single connection between any unique pairs of ports but one port can connect to multiple different destinations (different ports)

TCP Mechanisms Data Transfer

data transfer a logical stream of octets octets numbered modulo 223 flow control uses credit allocation of number of octets data buffered at transmitter and receiver

sent when transport entity ready unless PUSH flag used to force send

can flag data as URGENT, sent immediately if receive data not for current connection, RST flag is set on next segment to reset connection

TCP Mechanisms Connection Termination

graceful close

TCP user issues CLOSE primitive transport entity sets FIN flag on last segment sent with last of data entity abandons all attempts to send or receive data RST segment transmitted to other end

abrupt termination by ABORT primitive

TCP Implementation Options

TCP

standard precisely specifies protocol have some implementation policy options:

send deliver accept retransmit acknowledge

implementations

may choose alternative options which may impact performance

Send Policy
if

no push or close TCP entity transmits at its own convenience in credit allocation data buffered in transmit buffer may construct segment per batch of data from user

quick response but higher overheads

may

wait for certain amount of data

slower response but lower overheads

Deliver Policy
in

absence of push, can deliver data at own convenience may deliver from each segment received

higher O/S overheads but more responsive

may

buffer data from multiple segments

less O/S overheads but slower

Accept Policy
segments in

may arrive out of order

order
only accept segments in order discard out of order segments simple implementation, but burdens network

in

windows
accept all segments within receive window reduce transmissions more complex implementation with buffering

Retransmit Policy
TCP

has a queue of segments transmitted but not acknowledged will retransmit if not ACKed in given time

first only - single timer, send one segment only when timer expires, efficient, has delays batch - single timer, send all segments when timer expires, has unnecessary transmissions individual - timer for each segment, complex

effectiveness

depends in part on receivers

accept policy

Acknowledgement Policy
immediate

send empty ACK for each accepted segment simple at cost of extra transmissions piggyback ACK on suitable outbound data segments unless persist timer expires when send empty ACK more complex but efficient

cumulative

Congestion Control
flow

control also used for congestion control

recognize increased transit times & dropped packets react by reducing flow of data

RFCs

1122 & 2581 detail extensions

Tahoe, Reno & NewReno implementations

two

categories of extensions:

retransmission timer management window management

Retransmission Timer Management

static timer likely too long or too short estimate round trip delay by observing pattern of delay for recent segments set time to value a bit greater than estimate simple average over a number of segments exponential average using time series (RFC793) RTT Variance Estimation (Jacobsons algorithm)

Use of Exponential Averaging

Jacobsons RTO Calculation

Exponential RTO Backoff

timeout

probably due to congestion

dropped packet or long round trip time

hence

maintaining RTO is not good idea better to increase RTO each time a segment is re-transmitted

RTO = q*RTO commonly q=2 (binary exponential backoff) as in ethernet CSMA/CD

Karns Algorithm

if segment is re-transmitted, ACK may be for:

first copy of the segment (longer RTT than expected) second copy

no way to tell dont measure RTT for re-transmitted segments calculate backoff when re-transmission occurs use backoff RTO until ACK arrives for segment that has not been re-transmitted

Window Management

slow start

larger windows cause problem on connection created at start limit TCP to 1 segment increase when data ACK, exponential growth when a timeout occurs perhaps due to congestion set slow start threshold to half current congestion window set window to 1 and slow start until threshold beyond threshold, increase window by 1 for each RTT

dynamic windows sizing on congestion

Window Management

Fast Retransmit Fast Recovery

retransmit

timer rather longer than RTT if segment lost TCP slow to retransmit fast retransmit

if receive 4 ACKs for same segment then immediately retransmit since likely lost

fast

recovery

lost segment means some congestion halve window then increase linearly avoids slow-start

User Datagram Protocol (UDP)

connectionless service for application level procedures specified in RFC 768

unreliable delivery & duplication control not guaranteed

reduced overhead least common denominator service uses:

inward data collection outward data dissemination request-response real time application

UDP Header

Summary
connection-oriented

network and transport mechanisms and services TCP services, mechanisms, policies TCP congestion control UDP