1. The Transport Layer introduction fundamental problems in networking
communicating reliably over an unreliable channel
congestion and flow control
setting up/tearing down a connection
multiplexing and addressing
fragmentation and reassembly
quality of service
implementation issues
case studies: TCP, UDP, ATM, XTP
Tannenbaum: 6.1, 3.3, 3.4, 3.5.1, 6.2, 6.3, 3.2, 6.4, 6.5
Ross/Kurose: 3

2. Transport Layer: many interesting issues
many fundamentally important networking issues show up
how to provide reliable communication over an unreliable channel
why/how/when should a send restrain itself: flow and congestion control
how to agree to communicate (and stop) in presence of lost, delayed, reordered messages
how to deal with large data: fragmentation and reassembly
how to guarantee performance when resources statistically shared

3. Transport Layer: services provided
end-host to end-host delivery of data
aspects of transport service:
error detection and recovery: errors (lost or corrupted data) detected at receiver? Detected error corrected?
timing: timing between data at sender preserved when delivered at receiver?
framing: data unit boundaries (e.g., “message”) preserved?
common transport service models:
connectionless: datagram, no promises, error detection optional, no error recovery, no timing
connection-oriented: error recovery, no timing
circuit-like: timing preserved, no error recovery, optional error detection

4. Internet, OSI, ATM service models
Note: why multiple protocols for same service?
ATM:
OSI:

5. Reliable Communication over an unreliable channel
Goal: design a simple “reliable” data transfer protocol that:
reliably delivers data between upper layer applications/protocols
uses a network layer that is “unreliable”

6. Interaction with upper and lower layers
sender upper layer: transport layer invoked from above by call to rdt_send(data)
rdt: reliable data transfer
data: to be delivered to receiver upper layer
receiver upper layer: transport layer delivers data to upper layer via call to deliver_data(data)
sender lower layer: call to udt_send(packet) will pass packet to lower layer
udt: unreliable data transfer

7. Interaction with upper and lower layers
receiver lower layer: delivers packet to transport layer via call to rdt_rcv(packet)
Notes:
data is unit of data crossing upper boundary
packet is unit of data crossing lower boundary
packet = data with some added fields

8. Reliable data transfer: medium assumptions
Assumptions about network layer service
underlying medium (network) connecting sender and receiver may have many links, routers, networks!
can packets be lost, corrupted, delayed, reordered by network?
A first set of media assumptions
no loss, no corruption, no reordering

10. Reliable data transfer: medium assumptions
A first try at a protocol (rdt1.0)
rdt_send(data) {
make_packet(packet,data);
udt_send(packet); }
rdt_rcv(packet)
extract(packet,data);
deliver_data(data);

11. How to specify a protocol?
How to describe/specify a protocol?
English (why a good/bad idea)?
programming language or pseudocode (good/bad?)
graph-based methods: Petri net models and finite state machines
A finite state machine (FSM) consists of:
set of states for each protocol entity
each entity has its own set of states
state “records” all relevant past history of entity
entity response to each “event” in state must be uniquely defined
set of labeled directed arcs between states
represent changes in state
arc labelling:

12. FSM for rdt1.0

13. A second set of media assumptions
packets sent to network can be corrupted but neither lost nor reordered
any part of packet can be corrupted
corrupt(P), notcorrupt(P) return T if packet is (is not) corrupt
Questions:
how does rdt1.0 fail under new media assumptions?
new protocol mechanisms required (rdt2.0)
checksum
ACK, NACK

14. Protocol rdt2.0

17. Q: will rdt2.0 always work given assumptions?

18. Protocol rdt2.1
approaches to fix rdt2.0 1. 2. 3.

19. Protocol rdt2.1: sender

21. Protocol rdt2.1: receiver

23. A third set of media assumptions
packets sent to network layer can be lost, corrupted, but not reordered
new protocol mechanisms required (rdt3.0): 1. 2. 3.

24. Protocol rdt3.0: sender

26. Operation of rdt3.0: no errors

27. Operation of rdt3.0: lost packets

28. The Alternating bit protocol
protocol rdt3.0 known as Alternating Bit (AB) protocol
stop and wait ARQ
ARQ: automatic repeat/request
half-duplex-like communication
user of
timers
sequence numbers
error detection bits
required to provide reliable communication in presence of lost or corrupted packets
Q: what if channel can reorder packets??

29. Pipelined error recovery protocols
large bandwidth-delay product: propagation delays long with respect to packet transmission time
e.g.: 1 Gbit/sec link, 1Kbyte packet implies 8 microsecs to transmit into wire
t_trans = (8Kbits/packet)/(10**9 bits/sec) = 8 microsecs
cross country speed of light propagation delay is 15 msecs
channel utilization: fraction of time sender (channel at sender) is busy transmitting
U_sender = 0.008msecs/30.016msecs =
sender only busy .02% of time!
Sender throughput is 266Kbits/sec even with 1G link
protocol (not channel capacity) constrains performance (throughput)

30. Pipelined error recovery protocols
solution to low throughput with long propagation delays: pipelining allow multiple unacknowledged packets to be in-transit between sender and receiver