3a1

1
Chapter 3 Transport Layer

• Chapter goals
• understand principles behind transport layer
  services
• multiplexing/demultiplexing
• reliable data transfer
• flow control
• congestion control (some now more in connection
  with RT applications)
• instantiation and implementation in the Internet

• Chapter Overview
• transport layer services
• multiplexing/demultiplexing
• connectionless transport UDP
• principles of reliable data transfer
• connection-oriented transport TCP
• reliable transfer
• flow control
• connection management
• TCP congestion control

2
Transport services and protocols

• provide logical communication between app
  processes running on different hosts
• transport protocols run in end systems
• transport vs network layer services
• network layer data transfer between end systems
• transport layer data transfer between processes
• uses and enhances, network layer services

3
Transport-layer protocols

• Internet transport services
• reliable, in-order unicast delivery (TCP)
• congestion
• flow control
• connection setup
• unreliable (best-effort), unordered unicast or
  multicast delivery UDP
• services not available
• real-time
• bandwidth guarantees
• reliable multicast

4
Multiplexing/demultiplexing
delivering received segments to correct socket
gathering data from multiple sockets, enveloping
data with header (later used for demultiplexing)
process
socket

• Recall segment - unit of data exchanged between
  transport layer entities
• aka TPDU transport protocol data unit

5
How demultiplexing works

• host receives IP datagrams
• each datagram has source IP address, destination
  IP address
• each datagram carries 1 transport-layer segment
• each segment has source, destination port number
  (recall well-known port numbers for specific
  applications)
• host uses IP addresses port numbers to direct
  segment to appropriate socket

32 bits
source port
dest port
other header fields
application data (message)
TCP/UDP segment format
6
Connectionless demultiplexing

• When host receives UDP segment
• checks destination port number in segment
• directs UDP segment to socket with that port
  number
• IP datagrams with different source IP addresses
  and/or source port numbers directed to same socket

• Create sockets with port numbers
• DatagramSocket mySocket1 new DatagramSocket(9911
  1)
• DatagramSocket mySocket2 new DatagramSocket(9922
  2)
• UDP socket identified by two-tuple
• (dest IP address, dest port number)

7
Connectionless demux (cont)

• DatagramSocket serverSocket new
  DatagramSocket(6428)

SP provides return address
8
Connection-oriented demux

• TCP socket identified by 4-tuple
• 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
• non-persistent HTTP will have different socket
  for each request

9
Connection-oriented demux (cont)
S-IP B
D-IPC
SP 9157
Client IPB
DP 80
server IP C
S-IP A
S-IP B
D-IPC
D-IPC
10
Connection-oriented demux Threaded Web Server
P4
S-IP B
D-IPC
SP 9157
Client IPB
DP 80
server IP C
S-IP A
S-IP B
D-IPC
D-IPC
11
UDP User Datagram Protocol RFC 768

• best effort service, UDP segments may be
• lost
• delivered out of order to app
• connectionless
• no handshaking between UDP sender, receiver
• each UDP segment handled independently of others
  subsequent UDP segments can arrive in wrong order

• Is UDP any good?
• no connection establishment (which can add delay)
• simple no connection state at sender, receiver
• small segment header
• no congestion control UDP can blast away as fast
  as desired

12
UDP more

• often used for streaming multimedia apps
• loss tolerant
• rate sensitive
• other UDP uses (why?)
• DNS
• SNMP
• reliable transfer over UDP add reliability at
  application layer
• application-specific error recovery!

32 bits
source port
dest port
Length, in bytes of UDP segment, including header
checksum
length
Application data (message)
UDP segment format
13
UDP checksum

• Goal detect errors (e.g., flipped bits) in
  transmitted segment

• Receiver
• compute checksum of received segment
• check if computed checksum equals checksum field
  value
• NO - error detected (report error to app or
  discard)
• YES - no error detected.
• But maybe (very rarely) errors nonethless? More
  later .

• Sender
• treat segment contents as sequence of 16-bit
  integers
• checksum addition (1s complement sum) of
  segment contents
• sender puts checksum value into UDP checksum
  field

14
Principles of Reliable data transfer

• important in (app.,) transport, link layers
• in top-10 list of important networking topics!

• characteristics of unreliable channel will
  determine complexity of reliable data transfer
  protocol (rdt)

15
Reliable data transfer getting started
send side
receive side
16
Reliable data transfer getting started

• Well
• incrementally develop sender, receiver sides of
  reliable data transfer protocol (rdt)
• consider only unidirectional data transfer
• but control info will flow on both directions!
• use finite state machines (FSM) to specify
  sender, receiver

event causing state transition
actions taken on state transition
state when in this state next state uniquely
determined by next event
17
Rdt1.0 reliable transfer over a reliable channel

• underlying channel perfectly reliable
• no bit erros
• no loss of packets
• separate FSMs for sender, receiver
• sender sends data into underlying channel
• receiver read data from underlying channel

18
Rdt2.0 channel with bit errors

• underlying channel may flip bits in packet
• recall UDP checksum to detect bit errors
• the question how to recover from errors
• acknowledgements (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
• human scenarios using ACKs, NAKs?
• new mechanisms in rdt2.0 (beyond rdt1.0)
• error detection
• receiver feedback control msgs (ACK,NAK)
  rcvr-gtsender

19
rdt2.0 FSM specification
sender FSM
receiver FSM
20
rdt2.0 in action (no errors)
sender FSM
receiver FSM
21
rdt2.0 in action (error scenario)
sender FSM
receiver FSM
22
rdt2.0 has a fatal flaw!

• What happens if ACK/NAK corrupted?
• sender doesnt know what happened at receiver!
• What to do?
• sender ACKs/NAKs receivers ACK/NAK? What if
  sender ACK/NAK lost?
• retransmit, but this might cause retransmission
  of correctly received pkt!

• Handling duplicates
• sender adds sequence number to each pkt
• sender retransmits current pkt if ACK/NAK garbled
• receiver discards (doesnt deliver up) duplicate
  pkt

Sender sends one packet, then waits for receiver
response
23
rdt2.1 sender, handles garbled ACK/NAKs
24
rdt2.1 receiver, handles garbled ACK/NAKs
25
rdt2.1 discussion

• Sender
• seq added to pkt
• two seq. s (0,1) will suffice. Why?
• must check if received ACK/NAK 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/NAK
  received OK at sender

26
Bounding sequence numbers

• s.t. no wraparound, i.e. we do not run out of
  numbers binary value suffices for stop-and-wait
• Proof assume towards a contradiction that there
  is wraparound when we use binary seq. nums.
• R expects segment f, receives segment (f2)
• R rec. f2 gt S sent f2 gt S rec. ack for f1
• gt R ack f1gt R ack f gt contradiction
• R expects f2, receives f
• R exp. f2 gt R ack f1 gt S sent f1
• gt S rec. ack for f gt contradiction

27
rdt2.2 a NAK-free protocol
sender FSM

• same functionality as rdt2.1, using ACKs only
• instead of NAK, receiver sends ACK for last pkt
  received OK
• receiver must explicitly include seq of pkt
  being ACKed
• duplicate ACK at sender results in same action as
  NAK retransmit current pkt

!
28
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
• Q how to deal with loss?

• 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

29
rdt3.0 sender
30
rdt3.0 in action
31
rdt3.0 in action
32
Performance of rdt3.0

• rdt3.0 works, but performance stinks
• Example 50 Kbps, 500-msec round-trip propagation
  delay (satellite connection), transmit 1000-bit
  segments

20 msec

• 1 segment every 520 msec -gt 2 Kbps thruput
  (effective bit-rate) over 50 Kbps link
• network protocol limits use of physical
  resources!

33
Pipelined protocols

• Pipelining Solution to the problem of low
  utilization of stop-and-wait sender allows
  multiple, up to N, in-flight,
  yet-to-be-acknowledged pkts.
• Choice of N optimally, it should allow the
  sender to continously transmit during the
  round-trip transit time
• range of sequence numbers must be increased
• buffering at sender and/or receiver

• Two generic forms of pipelined protocols
  go-Back-N, selective repeat

34
Go-Back-N

• Sender
• k-bit seq in pkt header
• window of up to N, consecutive unacked pkts
  allowed

• ACK(n) ACKs all pkts up to, including seq n -
  cumulative ACK
• may receive duplicate ACKs (see receiver)
• timer for each in-flight pkt
• timeout(n) retransmit pkt n and all higher seq
  pkts in window

35
GBN sender extended FSM
36
GBN receiver extended FSM

• receiver simple
• ACK-only always send ACK for correctly-received
  pkt with highest in-order seq
• may generate duplicate ACKs
• need only remember expectedseqnum
• out-of-order pkt
• discard (dont buffer) -gt no receiver buffering!
• ACK pkt with highest in-order seq

37
GBN inaction
38
Selective Repeat

• receiver individually acknowledges all correctly
  received pkts
• buffers pkts, as needed, for eventual in-order
  delivery to upper layer
• sender 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

39
Selective repeat sender, receiver windows
40
Selective repeat

• pkt n in rcvbase, rcvbaseN-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

• data from above
• if next available seq in window, send pkt
• timeout(n)
• resend pkt n, restart timer
• ACK(n) in sendbase,sendbaseN
• mark pkt n as received
• if n smallest unACKed pkt, advance window base to
  next unACKed seq

41
Selective repeat in action
42
Selective repeat dilemma

• Example
• seq s 0, 1, 2, 3
• window size3
• receiver sees no difference in two scenarios!
• incorrectly passes duplicate data as new in (a)
• Q what relationship between seq size and
  window size?