Transport ProtocolsTransport Protocols
IntroductionIntroductionProtocols – what are they used for?
◦Transferring application information among machines (“transporting” protocols)
◦Naming and discovering resources and machines (“networking” protocols)
“Transporting” protocols might be “end-to-end” protocols
“Networking” protocols might be “hop-by-hop” protocols
““Transporting” protocolsTransporting” protocols“Transporting” protocols are
responsible for pushing data from A to B
Do two major functions:◦Manipulate data – moving data
to/from net, error detection, buffering, encryption, moving data to/from apps, presentation formatting, framing
◦Control transfer process – flow control, congestion control, multiplexing, time-stamping, and detect network transmission problems
Manipulating Data in Manipulating Data in ProtocolsProtocols
Application
App-to-OS data movement (e.g., send_udp(...))
Data bufferinginside OS
OS-to-net data movement (e.g., write data to network interface) Network transport over
physical network
Presentation FormattingPresentation Formatting
Application
Floating point valuesneed to be converted
Simplest formatting – host-to-networkbyte ordering; happens on all networkprograms
Linux
x86 arch Sun
Solaris
XDR – external data representationNetCDF – network common data format
Needed when heterogeneousmachines are interconnected by networks (e.g., scientific computing)
Multiplexing among AppsMultiplexing among Apps
Source Application
OS-to-net data movement (e.g., write data to network interface) Network transport over
physical network
Destination Application
Error DetectionError DetectionSource applicationcan be involved in “fixing”data loss as well. Newerdata can be provided by the App
Data held by OS could be re-transmittedto “fix” network errors (without theApp knowing about the network data loss)
Error detection can becarried out by network hardwareand/or OS
Destination Application
Flow ControlFlow Control
Transmission pauses waiting forspace at the receiver Send flow control message
to the source to stop tranmit
Destination bufferfull – may be destinationapplication is not activelyempting the buffer or slow
Prevent fast transmitter from overrunning a slow receiver
Congestion ControlCongestion Control
Request end station to pausetransmission because network isunable to cope with traffic load (e.g.,large wait queues)
Network routers in pathfrom source to destination
Destination buffermay be empty!Prevent a busy end
station from overburdening the network
Other “Transporting” Other “Transporting” Protocol IssuesProtocol IssuesAddressing
◦Mostly done by Networking protocols◦Multiplexing part is done by
transporting protocolsConnection establishment
◦Sender/receiver synchronization◦State establishment at both ends
Connection release◦Gracefully tearing down the state
Implementation of Implementation of “Transporting” protocols“Transporting” protocols“Transporting” protocols are
implemented in a layered manner
Primary motivation – complexity management
The concept of LayeringThe concept of Layering Physical – transmits
bits across a link Data link – deals with
checksum; errors; access control
Network – route computation; packet fragmentation; network interconnection
Transport – lost packets, packet reordering, congestion
Session – not much use; multimedia session control?
Presentation – data representation for network physic
alphysic
al
data link
data link
network
network
transport
transport
session
session
presentation
presentation
application
application
Drawbacks of Layered Drawbacks of Layered ImplementationImplementationEfficiency – could lead to multiple
copyingFraming – data can be
divided/joined as it goes through a layered stack
Simple Data Transfer Simple Data Transfer ProtocolProtocol
while (1) { get_net_layer(&buf); pkt.payload = buf; put_phy_layer(&pkt);}
while (1) { get_phy_layer(&pkt); buf = pkt.payload; put_net_layer(&buf);}
Buffer might be necessary even when retransmission is not done.For example, buffering can help in framing the data. That is, datainjected by the application is usually buffered and “packetized” based on some condition.
No reliability inProtocol
Reliable Data Transfer Reliable Data Transfer ProtocolsProtocolsObjective:
◦Reliably transmit data between two nodes
Reliable data transfer dealt with in different layers of the protocol stack◦physical layer – could be doing reliable
transmit◦transport layer – could be redoing
reliable data transmit◦application layer – could be doing it
instead of the transport layer
Reliable Data Transfer...Reliable Data Transfer...
Physical layer
Transport layer
Application layer
Layer not relevant to the discussion are not shown here!
Implementing Reliable Data Implementing Reliable Data TransferTransferOS protocols provide reliability
“buffer” to “buffer”Concern 1: prevent loss at
buffer (buffer overruns)Concern II: recover from data
loss in networksConcern III: detect and correct
corrupted dataConcern IV: deal with out-of-
order data reception
Simple Data Transfer Simple Data Transfer ProtocolProtocol
SDTP shown above assumes:◦ infinite buffers (no buffer overruns)◦ loss-less channel (no packet loss)◦ error-free channel (no packet corruption)◦ in-order data transfer (no packet reordering)
SDTP is very idealistic – may work in local area environments!
// sender
while (1) { get_net_layer(&buf); pkt.payload = buf; put_phy_layer(&pkt);}
// receiver
while (1) { get_phy_layer(&pkt); buf = pkt.payload; put_net_layer(&buf);}
Unrestricted Simplex Protocol
Simple Data Transfer Simple Data Transfer Version 2Version 2
Adds flow control:◦ Receiver has finite buffer space and may not keep
up with the sender
// sender loop
bool dst_buf_full = FALSEwhile (1) { if (dst_buf_full == FALSE) get_net_layer(&buf); pkt.payload = buf; put_phy_layer(&pkt); get_phy_layer(&ack); dst_buf_full = ack.buf_state; // some timed trigger to // iterate}
send_data() { // write data to network buffer}
// receiverint bspace = BUF_SIZE;
while (1) { get_phy_layer(&pkt); buf = pkt.payload; bspace--; put_net_layer(&buf); if (bspace <= 0) ack.buf_state = FALSE; else ack.buf_state = TRUE; put_phy_layer(&ack);}
receive_data() { // read data from networ // buffer // increment bspace counter}
Sliding Window ProtocolsSliding Window ProtocolsGeneralize the protocols to:
◦Duplex◦Piggyback ACK◦Set windows at sender and receiver
to denote valid framesThree variants:
◦A One-Bit Sliding Window Protocol◦A Protocol Using Go Back N◦A Protocol Using Selective Repeat
One-bit Sliding WindowOne-bit Sliding Window
0
1
0
1
Sender Receiver
Protocol in actionProtocol in action
Protocol in actionProtocol in action
PerformancePerformance
Example: 1.0 Gbps link, 15 ms e-e prop. delay, 1KB packet:
Ttransmit
= 8kb/pkt10**9 b/sec
= 8 microsec
U sender: utilization – fraction of time sender busy sending
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
network protocol limits use of physical resources!
U sender
= .008
30.008 = 0.00027
microseconds
L / R
RTT + L / R =
L (packet length in bits)R (transmission rate, bps)
=
Pipelined protocolsPipelined protocolsPipelining: sender allows multiple, “in-
flight”, yet-to-be-acknowledged pkts◦ range of sequence numbers must be
increased◦ buffering at sender and/or receiver
Two generic forms of pipelined protocols: go-Back-N, selective repeat
Pipelined ProtocolsPipelined Protocols
1
Sender Receiver
2
n-1
0
1
2
m-1
0
Buffers atthe sender andreceiver
Receiverbuffers areused to holdout-of-orderpackets
Go-Back-NGo-Back-N
Sender
Receiver
Receiverdoes notbuffer out-of-orderpackets
Sends “cumulative”ACKs
Sender buffersUn ACKd packets
Packet loss causes retransmissionof all Un ACKd packets.
Can be costly with large window sizes
Go-Back-NGo-Back-NSender: k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed
► ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs timer for each in-flight pkt
► timeout(n): retransmit pkt n and all higher seq # pkts in window
GBN inGBN inactionaction
Selective RepeatSelective Repeat
receiver individually acknowledges all correctly received pkts◦ buffers pkts, as needed, for eventual in-
order delivery to upper layersender only resends pkts for which
ACK not received◦ sender timer for each unACKed pkt
sender window◦ N consecutive seq #’s◦ again limits seq #s of sent, unACKed pkts
Selective repeat: sender, receiver Selective repeat: sender, receiver windowswindows
Selective repeatSelective repeat
data from above : if next available seq # in
window, send pkt
timeout(n): resend pkt n, restart
timer
ACK(n) in [sendbase,sendbase+N]:
mark pkt n as received if n smallest unACKed pkt,
advance window base to next unACKed seq #
senderpkt n in [rcvbase,
rcvbase+N-1]
► send ACK(n)► out-of-order: buffer► in-order: deliver (also
deliver buffered, in-order pkts), advance window to next not-yet-received pkt
pkt n in [rcvbase-N,rcvbase-1]
► ACK(n)
otherwise: ► ignore
receiver
Selective repeat in actionSelective repeat in action
Selective repeat:Selective repeat: dilemma dilemmaExample: seq #’s: 0, 1, 2, 3 window size=3
receiver sees no difference in two scenarios!
incorrectly passes duplicate data as new in (a)
Q: what relationship between seq # size and window size?