Transport-Layer services
Transport services and protocols
provide logical communication between app processes running on different hosts
transport protocols run in end systems
send side: breaks app message into segments, passes to network layer
rcv side: reassembles segments into messages, passes to app layer
more than one transport protocol available to apps
Internet: TCP and UDP
Transport vs. network layer
network layer:
logical communication between hosts
transport layer:
logical communication between processes
relies on & enhances, network layer services
Internet transport-layer protocols
UDP
unreliable, unorderd delivery
no frills extension of best effort IP
TCP
reliable, in-order delivery
congestion control
flow control
connection setup
services not availeble:
delay guarantees
bandwidth guarantees
Multiplexing and demultiplexing
Multiplexing/demultiplexing
Multiplexing
gatherng data from multiple sockets, enveloping data with header
Demultiplexing
delivering received segments to correct socket
How demultiplexing works
host recoives IP datagrams
each datagram has source IP address, destination IP address
each datagram carries 1 transport-layre segment
each segment has source, destination port number
host uses IP addresses & port numbers to direct segment to appropriate socket
Connectionless demultiplexing
When host receives UDP segment:
checks dest. port number in segment
directs UDP segment to socket with that port number
IP datagrams witch different source IP addresses and/or source port numbers
directed to same socket
UDP socket identified by two-tuble:
dest. IP address, dest. port number
Connection-oriented demux
TCP socket identified by 4-tuble:
source IP address
source port number
dest IP address
dest port number
recv host uses all four values to direct segment to appropriate socket
Server host may support many simultaneous TCP sockets:
each socket identified by its own 4-tuple
Web servers have different sockets for each connecting client
Connectionless transport: UDP
The Problem with TCP
TCP offers a reliable and easy to use transport protocol to programmers
Congestion control
Retransmissions etc.
However congestion control imposes transmission-rate constraints
If a traffic jam is detected on a path, sender decreases sending rate dramatically
Problem: One cannot switch off funcions of TCP ex. Congestion control
UDP: User Datagram Protocol
no frills, bare bones Internet transport protocol
best effort service, UDP segments may be:
lost
delivered ouf of order to app
connectionless:
no handshaking between UDP sender, receiver
each UDP segment handeld independently of others
often used for streaming multimedia apps
loss tolerant
rate senitive
other UDP uses
DNS
SNMP
reliable tronsfer over UDP: add reliability ot application layer
application-specific error recovery!
ex. ACK/NAK, retransmissions (non trivial)
UDP checksum
Goal: detect errors e.g., flipped bits in transmitted segment
Sender:
treat segment contens as sequence of 16-bit integers
checksum: addition 1'complement sum of segment contens
sender puts checksum value into UDP checksum field
Receiver:
compute checksum of received segment
check if computed checksum equals checksum field value:
NO - error detected
YES - no error detected, But maybe errors nonetheless?
Why error detection in the first place?
Link Layer provides CRC! (Ethernet)
No guarantee for:
link to link reliability e.g. non ethernet
memory error detection on routers
IP is designed to run on any layer 2 protocol
End to end error detection is safety measure
UDP does not recover from errors
Principles of reliable data transfer
Reliable data franfer: getting started
We'll:
incrementally develop sender, receiver sides of reliable data tansfer protocol (rdt)
consider only unidirectional data transfer
but control info will flow on both directions!
use finite state machine (FSM) so specify sender, receiver
Use generic term packet rather than segment
Finite State Machine
FSM is a model of behavior composed of a finite number of
states
transitions between states on events
actions taken upon events
Necessary to define the behavior of our protocol, prior to implementation
Rdt1.0: reliable transfer over a reliable channel
Assumption: underlying channel perfectly reliable
no bit errors
no loss of packets
separate FSMs for sender, receiver:
sender sends data into underlying channel
receiver read data from underlying channel
Rdt2.0 channel with bit errors
underlying channel may flip bits in packet
checksum to detect bit errors
the question: how to recover from errors?
acknowledgments (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
new mechanisms in rdt2.0(beyond rdt1.0)
error detection
receiver feedback: control msgs (ACK, NAK) rcvr -> sender
Automatic Repeat reQuest type of protocol (ARQ)
What happens if ACK/NAK corrupted?
sender doesn't know what happend at receiver!
can't just retransmit: possible duplicate
Handling duplicates:
sender retransmits current pkt if ACK/NAK garbled
sender adds sequence number to eacht pkt
receiver discards (doesn't deliver up) duplicate pkt
Using only ACK + Sequence:
We can discard NAK packets, by using only ACK + Seq.#
duplicate ACK at sender results in same action as NAK: retransmit current pkt
rdt2.2: discussion
Sender:
seq # added to pkt
two seq. #'s (0,1) will suffice. Why?
must check if received ACK corrupted
twice as many states
- state must remember whether current pkt has 0 or 1 seq. #
Receiver:
must check if received packet is duplicate
state indicates whether 0 or 1 is expected pkt seq #
note: receiver can not know if its last ACK received OK at sender
rdt3.0: 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
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
rdt3.0 works, but performance stinks
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
Pipelined protocols
Pipelining: sender allows multiple, in-flight, yet-to-be-acknowledged pkts
- range of sequence numbers must be increased
- buffering at sender and/or receiver
Two generics forms of pipelined protocols: go-Back-N, selective repeat
Go-back-N: big picture:
Sender can have up to N unacked packets in pipeline
Rcvr only sends cumulative acks
Doesn's ack packet if there's a gap
Sender has timer for oldest unacked packet
If timer expires, retransmit all unacked packets
Selective Repeat: big pic
Sender can have up to N unacked packets in pipeline
Rcvr acks individual packets
Sender maintains timer for each unacked packet
When timer expires, retransmit only unack packet
