EE 122: Transport Protocols

1
EE 122 Transport Protocols

• Kevin Lai
• October 16, 2002

2
Motivation

• IP provides a weak, but efficient service model
  (best-effort)
• packets can be delayed, dropped, reordered,
  duplicated
• packets have limited size (why?)
• IP packets are addressed to a host
• how to decide which application gets which
  packets?
• How should hosts send into the network?
• every sends as fast as they can ? drop many
  packets, network is under-utilized (congestion
  collapse)

3
Transport Protocol
TCP/UDP
Transport Layer

• Provides more than the underlying network
  protocol
• more reliability, in order delivery, at most once
  delivery
• supports messages of arbitrary length
• provide a way to decide which packets go to which
  applications (multiplexing/demultiplexing)
• govern how hosts should send data to prevent
  congestion collapse (congestion control and
  avoidance)

Networking Layer
IP
Link Layer
Physical Layer
4
UDP

• User Datagram Protocol
• minimalistic transport protocol
• same best-effort service model as IP
• messages can be larger than one packet, but still
  limited (64KB)
• uses fragmentation
• provides multiplexing/demultiplexing to IP
• does not provide congestion control
• advantage over TCP does not increase end-to-end
  delay over IP
• application example video/audio streaming

5
TCP

• Transmission Control Protocol
• reliable, in-order, and at most once delivery
• messages can be of arbitrary length
• provides multiplexing/demultiplexing to IP
• provides congestion control and avoidance
• increases end-to-end delay over IP
• e.g., file transfer, chat

6
Headers

• IP header ? used for IP routing, fragmentation,
  error detection
• UDP header ? used for multiplexing/demultiplexing,
  error detection
• TCP header ? used for multiplexing/demultiplexing,
  flow and congestion control

Receiver
Sender
Application
Application
data
data
TCP UDP
TCP UDP
data
TCP/UDP
data
TCP/UDP
IP
IP
data
TCP/UDP
IP
data
TCP/UDP
IP
7
IP Header
0
4
8
16
19
31
Version
HLen
TOS
Length
Identification
Flags
Fragment offset
20 bytes
TTL
Protocol
Header checksum
Source address
Destination address
Options (variable)
Payload

• Comments
• HLen header length only in 32-bit words (5 lt
  HLen lt 15)
• TOS (Type of Service) Differentiated Service (6
  bits) Explicit Congestion Notification (ECN) (2
  bits)
• Length the length of the entire
  datagram/segment header data
• Flags Dont Fragment (DF) and More Fragments
  (MF)
• Protocol identifies the transport protocol
• Header checksum - uses 1s complement

8
Fragmentation

• What happens if router has to forward an IP
  packet that is larger than allowed by a data link
  layer?
• Break the IP packet into smaller IP packets and
  provide a way to reassemble
• set more fragments bit in all fragments but
  last
• set the fragment offset of fragment to be offset
  (in 8-byte offsets) from beginning of original
  packet
• set the packet len to be length of this fragment

9
Fragmentation Issues

• Sending host had better be changing the IP ID
• Loose one fragment, loose them all
• Reassembly is complex
• requires per packet state
• Only reassemble at destination
• Fragmentation can be avoided using Path Maximum
  Transmission Unit Discovery (PMTU)
• most TCP implementations use PMTU

10
UDP Header
0
16
31
Destination port
Source port
UDP length
UDP checksum
Payload (variable)

• Source and destination ports use port address
  space
• UDP length is UDP packet length (including UDP
  header and payload, but not IP header)
• Optional UDP checksum is over UDP packet
• why have UDP checksum in addition to IP checksum?
• why not have just the UDP checksum?
• why is the UDP checksum optional?

11
Port Addressing

• Need to decide which application gets which
  packets
• Solution map each socket to a port
• Client must know servers port
• separate 16-bit port address space for UDP and
  TCP
• (src IP, src port, dst IP, dst port) uniquely
  identifies TCP connection
• Well known ports(0-1023) everyone agrees which
  services run on these ports
• e.g., ssh22, http80
• on UNIX, must be root to gain access to these
  ports (why?)
• ephemeral ports(most 1024-65535) given to
  clients
• e.g. chatclient gets one of these

12
TCP Header
0
4
10
16
31
Destination port
Source port
Sequence number
Acknowledgement
Advertised window
Flags
HdrLen
Checksum
Urgent pointer
Options (variable)
Payload (variable)

• Sequence number, acknowledgement, and advertised
  window used by sliding-window based flow
  control
• Flags
• SYN, FIN establishing/terminating a TCP
  connection
• ACK set when Acknowledgement field is valid
• URG urgent data Urgent Pointer says where
  non-urgent data starts
• PUSH dont wait to fill segment
• RESET abort connection

13
TCP Challenges

• how to provide reliable, in-order, and at most
  once delivery? (sliding window)
• need to synchronize sender and receiver
  (connection establishment)
• e.g., exchange initial sequence numbers
• prevent sender from sending too fast for receiver
  (flow control)
• estimate RTT for flow control and timeouts
• how to initially decide on sending rate (slow
  start)
• estimate how much bandwidth is available in
  network (congestion avoidance)
• slow down sending rate when we were sending too
  fast (congestion control)

14
Connection Establishment How it works

• Three-way handshake
• Goal agree on a set of parameters the start
  sequence number for each side
• Starting sequence numbers are random.

Server
Client (initiator)
ActiveOpen
connect()
listen()
PassiveOpen
accept()
allocatebuffer space
15
Three-way Handshake Rationale

• Three-way handshare adds 1 RTT delay
• Why not just start sending data immediately?
• congestion control
• network could be congested
• SYN 40 bytes, Data lt 1500 bytes
• packets which are dropped at a link waste the
  bandwidth of all previous links
• smaller packets waste less bandwidth
• SYN acts as cheap probe of network conditions

16
More Rationale

• protection from denial of service (1)
• attacker could use one host to fake many SRC IP
  address (spoofing) and send many SYNs to server
• server must devote resources (e.g., buffer space)
  for open connections
• server would run out of resources and become very
  slow or crash
• 3-way handshake requires client to reply before
  server allocates significant resources
• protection from denial of service (2)
• client and server begin connection using
  well-known sequence number instead of random one
• attacker guesses sequence number, inserts bogus
  packets into stream

17
Even More Rationale

• protection from delayed packets
• client connects to server twice in succession
  using the same port
• a packet from the first connection is delayed and
  arrives during the second connection
• if sequence numbers are close, old packet could
  be accepted

18
Flow control Window Size and Throughput
wnd 3

• Sliding-window based flow control
• Higher window ? higher throughput
• Throughput wnd/RTT
• Remember window size control throughput
• How to determine effective window size?
• How to detect packet loss?

19
Effective Window Size

• Receiver window (MaxRcvBuf maximum buffer size
  at receiver)
• Sender window (MaxSendBuf maximum buffer size
  at sender)

AdvertisedWindow MaxRcvBuffer (LastByteRcvd
LastByteRead)
EffectiveWindow AdvertisedWindow
(LastByteSent LastByteAcked)
MaxSendBuffer gt LastByteWritten - LastByteAcked
Sending Application
Receiving Application
MaxRcvBuffer
MaxSendBuffer
LastByteRead
LastByteWritten
NextByteExpected
LastByteRcvd
LastByteAcked
LastByteSent
sequence number increases
sequence number increases
20
Advertised Window 0

• Sender cannot send any data ? receiver will not
  send acks ? receiver cannot notify sender that
  advertised window has grown
• Solution TCP Persist Timer
• when sender gets advertised window 0, it sets
  timer
• if sender receives advertised window gt 0, cancels
  timer
• when timer expires, sender sends 1 byte payload
  to receiver
• receiver must accept data 1 byte past window
• receiver sends ack for byte before 1 byte
• sender gets new advertised window

21
Silly Window Syndrome (SWS)
advWin w
advWinw
app send 1
size1
app send w1
app read 1
sizew-1
advWinw
app read w-1
size1
advWinw

• Maximum Segment Size (MSS) w
• App sends of small segments and/or receiver
  advertises small window
• causes small packets to be sent in network
• small packets have high header overhead

22
SWS Solution

• Sender only sends if
• no unacknowledged data, (Nagles algorithm) or
• full packet to send
• Receiver only sends new advertised window if
• newAdvWin oldAdvWin gt min(MSS, 0.5maxRcvBuf)

23
Set timeout

• If havent received ack by timeout, retransmit
  packet after last acked packet
• How to set timeout?
• Too long connection has low throughput
• Too short retransmit packet that was just
  delayed
• packet was probably delayed because of congestion
• sending another packet too soon just makes
  congestion worse
• Solution make timeout proportional to RTT

24
RTT Estimation

• Use exponential averaging

SampleRTT
EstimatedRTT
Time
25
Problem

• How to differentiate between the real ACK, and
  ACK of the retransmitted packet

Sender
Receiver
Sender
Receiver
Original Transmission
Original Transmission
SampleRTT
ACK
SampleRTT
Retransmission
Retransmission
ACK
26
Karn/Partridge Algorithm

• Measure SampleRTT only for original transmissions
• Exponential backoff ? for each retransmission,
  double EstimatedRTT

27
Jacobson/Karels Algorithm

• Problem exponential average is not enough
• one solution use standard deviation (requires
  expensive square root computation)
• use mean deviation instead

28
Summary

• IP
• routing, fragmentation
• UDP
• Multiplexing/demultiplexing using ports
• error detection
• TCP
• reliable, in order, at most once delivery
• Connection establishment ? three way handshake
• RTT ? exponential averaging and variance
• Flow control ? based on sliding window protocol
• Congestion control ? next lecture