Transcript CSCI3421_Ch3x

Chapter 3
Transport Layer
Tami Meredith
A protocol defines:
1.
2.
3.
Message Format
(Syntax)
Rules of
Communication
(Semantics)
Synchronisation and
other application
details
(Implementation)






Applications send each other messages; e.g., http
request, http response
Transport layer ensures these messages into pieces
called segments (sometimes called datagrams
when UDP is used)
The transport layer exists only in end-systems
Network layer handles the intermediate systems
Application layer: communication between
processes
Transport layer: communication between hosts

1.
Note: IP provides unreliable service
Reliable data transfer


2.
3.
In correct order
Error free
Congestion control (prevent links getting
swamped or overloaded)
Multiplexing and de-multiplexing of multiple
(application/process-level) communications



Multiplexing: Collecting the messages from
each port/application-socket and combining
them into a single data stream
Demultiplexing: Taking the incoming segments
and separating them by port/applicationsocket
Transport layer messages thus have source port
number and destination port number fields
(port number is NOT a socket id)
1.
UDP uses destination host and destination
port to route


2.
Packets from different hosts all arrive at the same
socket
UDP socket defined by destination host:port
TCP builds a connection between two
processes and thus the source info is also
needed


Packets from different hosts go to different ports
TCP socket defined by both source and destination
host:port




User Datagram Protocol
Bare-bones and minimal transport protocol
Adds almost nothing to IP
Only fields (above IP)
1.
2.
3.
4.
Source port – 2 bytes
Destination port – 2 bytes
Segment length – 2 bytes
Checksum – 2 bytes



Finer grained application control – no
congestion control, re-ordering,
acknowledgements etc., just quick fast simple
transmission attempts
No connection overhead, construction, takedown, or state maintenance
Minimal packet overhead, little extra data to
transmit





Remote file servers using NFS
Network management (SNMP) – since SNMP
run when network is in stressed state
Name translation (DNS) – so common it must
be fast
Routing (RIP) – frequent updates, lost data not
significant
Streaming multimedia/telephony using
proprietary application protocols - avoids
overhead of congestion control (reliability is
performed at the application level instead)



Reliability should exist on an end-to-end level and
this is properly done at the highest level (not the
lowest)
Even if IP does not detect an error, data could be
corrupted when being transferred from the
modem to the socket’s memory
Calculating the checksum (RFC 1071)
Sum all 16 bit words with overflow wrap around
 Take 1’s complement


Using the checksum

Add the checksum to the sum of all 16 bit words which
should generate 11…11



States (circles) – must be in one
Transitions (arrows) – taken when event
happens
Deterministic – no choice when an event occurs
1.
2.
3.


All bits arrive (i.e. none are lost)
In the order they were sent (i.e., not reordered)
As they were sent (i.e., unflipped)
This is difficult to do!
One of the fundamental challenges of
networking


1.

Assumes underlying channel is error free and can
send data as fast as it is produced
Two finite state machines exist (Fig 3.9):
Sender
state1: Wait for a send
Event: Send Requested
Action: Make packet and sent it, go to state1
2.

Receiver
StateA: Wait for an incoming packet
Event: Packet Arrives
 Action: Remove header and deliver it, go to stateA






Assumes that all packets are received (none are
lost)
Packets may be corrupted (bit errors)
Positive acknowledgements: received OK, ACK
Negative acknowledgements: not understood,
NAK
Often known as ARQ (Automatic Repeat
reQuest) protocols



Introduce a new packet, RPT, “Repeat last ACK
or NAK”
Replace checksum with ECC protocol (but
doesn’t work later when we consider lost
packets)
Add a sequence number so that we can resend
last packet and treat garbled ACK as NAK





Alternative to RDT 2.1 except that NAK not
used
If a packet is corrupted, the ACK of the last
correctly received packet is sent
Need to add sequence numbers to ACK
Still handles the same issues – garbled packets
only, not loss tolerant
Not really any simpler – Is {ACK0, ACK1}
different from {ACK, NAK} but builds
framework for RDT 3








Channel now permitted to lose packets and garble
them
Sender retransmits when no ACK received in a
timely manner (uses a countdown timer)
Also considers that packets can be duplicated
Puts burden of work on the sender (alternatives
which focus on the receiver are also possible)
No ACK = Packet lost/delayed, ACK lost/delayed
Uses checksums, sequence numbers, timers, ACK,
and NAK
Known as an alternating bit protocol
Problem is that it is stop and wait – tooooo slow!






Utilisation of connection using stop and wait is
very low, often down around 1%!
Pipelining permits a burst of packets to be sent
until such time as an ACK is expected
Requires more buffering
Multiple parts could be lost
Protocols more complicated
Two basic approaches used
1.
2.
Go-Back-N
Selective Repeat






Also known as a sliding window protocol
N is the window size (number of packets that
have not been ACK’d)
Sequence numbers now needed in headers
ACK is used for cumulative acknowledgement
When timer expires all unacknowledged
packets are resent
Provides some rudimentary congestion control


If n is large and the first packet is lost, GBN can
require many packets to be resent and waste
bandwidth – only the missing packets need to
be resent
Selective repeat addresses this issue





Connection oriented
Not a persistent physical connection but an
endhost-to-endhost logical connection
Point-to-point – not multicast
Full duplex – both endhosts can transmit
simultaneously
Three way (3 segments) handshake for
connection establishment – 3rd segment may
have payload




Sequence number = byte offset (into entire
message) of the first byte of payload data
Acknowledgement number = sequence number
(offset) of the next byte expected
Cumulative acknowledgement (like GBN)
When an out of order packet arrives, it is NOT
required that the packet is kept (but it almost
always is)







How long do we wait before doing a retransmit?
Needs to be longer than the RTT (round trip time)
Estimated RTT is a exponential weighted moving
average (most recent packets have more weight)
DevRTT is the deviation that segments can show
Timeout = EstimatedRTT + 4 * DevRTT
Start at 1 second
ONLY 1 TIMER!




No one “right” way to implement TCP
Various implementations exist due to the
freedom allowed by the RFC
The text gives one correct and possible
implementation
Event Based:
1.
2.
3.
Send (App. Layer provides data)
Timeout by timer
ACK received
Fast Retransmit (n=3)



The timeout is doubled in duration every time
a timer expiry event occurs
Intervals grow exponentially after every
retransmission
Helps perform congestion control since
retransmission is probably due to congestion





Matching send rate to the rate at which the
receiver is receiving
Trying to avoid receivers buffer from
overflowing
Is influenced by congestion but is NOT the
same thing
Uses the Receive Window field of the header
Not static – changes constantly






Window is the amount of spare room in the
buffer
Reading moves data from buffer to application
= BufSize – [data in buffer]
= BufSize – [LastByteRcvd – LastByteRead]
Sender must also account for packets “in
transit” (sent but not acknowledged)
If window = 0, still send one byte data packets
to force a response containing an updated
window size




Large queuing delays as packet arrival nears
link capacity
Retransmissions to compensate for lost packets
due to buffer overflow
Unneeded retransmissions due to large delays
(and subsequent timeouts)
Wasted bandwidth for packets that don’t make
it all the way to the destination

Network Assisted Congestion Control (Not
possible since IP does not provide support)
1.
2.

Choke packet
Congestion field set by router
End-to-end Congestion Control (TCP
approach)

Presence of congestion is inferred and each
application acts independently to reduce it



A lost segment implies congestion
ACK indicates reception and sending rate can be
increased
Cyclical Probing
Increase rate until loss occurs
 Decrease rate because loss occurs
 Go back to increasing …


Three components to algorithm:
Slow start
 Congestion avoidance
 Fast recovery
