Networks and Communication Lecture 10: Transport protocols

1
Networks and CommunicationLecture 10 Transport
protocols

• Peter Steenkiste
• School of Computer Science
• Carnegie Mellon University
• ECOM, Summer 2000

2
Outline

• Transport protocols.
• UDP.
• TCP.

3
Transport protocols

• Lowest level end-to-end protocol.
• Header generated by sender is interpreted only by
  the destination
• Wide range of functions
• Multiplexing/ demultiplexing for multiple
  applications
• Connection establishment
• Various types of error control
• End-to-end flow control
• Congestion control

7
7
6
6
5
5
Transport
Transport
IP
IP
IP
Datalink
Datalink
2
2
Physical
Physical
1
1
router
4
User Datagram ProtocolUDP

• Addressing used for (de)multiplexing.
• port numbers connection/application endpoint
• End-end reliability through optional end-to-end
  checksum.
• protects against any data corruption errors
  between source and destination (links,
  switches/routers, bus)
• does not protect against packet loss, duplication
  or reordering
• checksum is very simple

Source Port
Dest. Port
Length
D. Checksum
5
Using UDPHow about the Missing Features?

• Non-standard protocols can be implemented on
  top of UDP.
• Non-standard non-TCP in practice
• use the addressing provided by UDP
• implement their own reliability, flow control,
  ordering, congestion control
• Examples
• remote procedure calls (client-server)
• transaction processing
• multimedia
• distributed computing communication libraries
• look at some examples later

6
Transmission Control Protocol

• Feature rich protocol.
• Service fully reliable two-way byte stream.
• Connection establishment and tear down.
• Reliability.
• End-end flow control.
• Congestion avoidance.
• TCP extensions.

Source Port
Dest. Port
Sequence Number
Acknowledgment
HL/Flags
Window
D. Checksum
Urgent Pointer
Options..
7
High-Level TCP Characteristics

• Connection-oriented reliable byte-stream
  protocol.
• Used for file transfers, telnet, web access, .
• Two way connections.
• control information for one direction
  piggy-backed on data flow in other direction
• header fields fall in three classes general,
  forward flow, opposite flow
• Protocol has evolved over time and will continue
  to do so.
• Change processing at endpoints
• uses options to add information to the header
• backward compatibility is what makes it TCP

8
Connection management
Sender
Receiver
syn
Establish Initial Sequence Numbers
Open
syn/ack
ack
Data
fin
ack
Close
fin
ack
Time
9
Sequence Number Space

• Each byte in byte stream is numbered.
• 32 bit value
• wraps around
• initial values selected at start up time
• Each packet has a sequence number.
• indicates where it fits in the byte stream
• Detects lost, duplicate or out of order packets.
• Recovers to offer reliable in-order byte
  streaming

packet 10
packet 9
packet 8
10
Reliability

• Checksum guarantees end-end data integrity.
• Sequence numbers detect packet sequencing
  problems
• duplicate ignore
• reordered reorder or drop
• lost retransmit
• Lost packets detected by sender.
• uses time out to detect lack of acknowledgment
• requires reliable roundtrip time estimate
• Retransmission requires that sender keeps copy of
  the data until ACK is received.
• performance issue

11
When to Send a Packet?

• End-to-end flow control.
• avoid buffer overflow on receiver
• receiver advertizes a window size
• Congestion control.
• estimates amount of data that can be in network
• implemented using the congestion window, slow
  start, and fast retransmit/recovery mechanisms
• Efficiency considerations.
• try to send large packets (if possible)
• more efficient in the network and on end points
• piggybacking of acks

12
End-to-End Flow Control

• Receiver advertises how much data it can receive.
• backed up with real buffer space
• point in sequence space
• Acknowledgement indicates that data was received
  correctly.
• sender can delete copy of message
• but data still consumes buffer space on receiver
• Window update indicates that data was consumed
  and that buffer space was freed up.
• sender can send more data

acknowledged
sent
to be sent
outside window
13
Window Size versus Throughput
Sender
Receiver
Time
Window Size
Throughput
Roundtrip Time
14
TCP Congestion Avoidance

• Congestion avoidance limits how fast TCP can send
  data.
• Implemented using a congestion window that limits
  how much data can be in the network
• independent from flow control window
• transmission is limited by minimum of the two
  windows
• window grows in response to acknowledgement
• Packet loss is seen as sign of congestion.
• multiplicative decrease of the congestion window
• have to cut back fast since cost of congestion is
  high
• How do you detect when more bandwidth becomes
  available?
• gradually increment congestion window (probing)
• results in oscillation around congestion window
  size!

15
TCP Saw Tooth Behavior
Congestion Window
Time
Cut Congestion Window and Rate
Grabbing back Bandwidth
Packet loss Timeout
16
More Congestion Avoidance

• Many complex details ...
• How fast can you send at startup?
• You have no information about the path to the
  receiver
• slow start quickly discovers approximate
  bandwidth
• How can we avoid performance penalty that follows
  from packet loss due to probing.
• Cost of time out, cutting the window size in
  half, ...
• Fast retransmit and fast recovery recover
  quickly and efficiently from individual packet
  losses
• such as the ones that happen as a result of
  probing
• You can read about it in the book (optional).

17
TCP Saw Tooth Behavior
Congestion Window
Timeouts may still occur
Time
Slowstart to pace packets
Fast Retransmit and Recovery
Initial Slowstart
18
TCP Efficiency Considerations

• Delayed acknowledgment.
• try to piggy back acknowledgements and window
  updates on outgoing packet
• Silly window syndrome
• coalesce small packets to reduce the overhead of
  sending lots of small packets
• implemented using Nagles algorithm (optional)
• 16 bit window size is too restrictive for very
  fast wide-area networks.
• Maximum packet rate is 10 Mbit/second for 50
  millisecond roundtrip time
• Other refinements roundtrip time calculation,
  selective retransmit, sequence number wrap around
  protection, ..

19
Example Use of OptionsWindow Scaling
TCP syn,ack
SW yes
3
SW?
2
20
TCP Fairness Issues

• Multiple TCP flows sharing the same bottleneck
  link do not necessarily get the same bandwidth.
• Factors such as roundtrip time, small differences
  in timeouts, and start time, affect how
  bandwidth is shared
• The bandwidth ratio typically does stabilize
• Modifying the congestion control implementation
  changes the aggressiveness of TCP and will change
  how much bandwidth a source gets.
• Affects fairness relative to other flows
• Changing timeouts, dropping or adding features,
  ..
• Users can grab more bandwidth by using parallel
  flows.
• Each flow gets a share of the bandwidth to the
  user gets more bandwidth than users who use only
  a single flow

21
TCP Performance Issues

• Consistently full queues can degrade TCP
  performance.
• Lock out of some sessions
• Synchronization of TCP sessions due to the
  dropping of bursts of packets
• Penalizing of bursty flows
• Increased queueing delay
• Not all users sharing a bottleneck link get the
  same bandwidth.
• Can be considered to be unfair
• Malicious users can grab more bandwidth by
  modifying TCP or by using UDP.
• Again a fairness issue - very hard problem

22
Random Early Detection(RED)

• Start randomly dropping packets before queue is
  full.
• Some flows will observe a single packet loss and
  slow down, hopefully avoiding queue overflow
• High bandwidth users are more likely to have a
  packet dropped than low bandwidth users
• Queue can still accommodate bursts of packets
• Improves overall network performance by avoid
  that queues stay full.
• Congestion avoidance
• How do you set the thresholds?

P
1
0
Averaged Queue size
23
Explicit Congestion Notification(ECN)

• The goal is to provide explicit congestion
  notification to senders.
• Complements the implicit feedback through packet
  drops
• Bits 6-7 of the TOS bit form the ECN field.
• The ECN-Capable Transport (ECT) bit is set by the
  sender to indicate that the end-points are
  ECN-capable
• The Congestion Experience (CE) bit is set by the
  router to signal congestion
• The ECN is received by the receiver, who is
  responsible for forwarding the information to the
  sender.

V/HL
TOS
Length
ID
Flags/Offset
TTL
Prot.
H. Checksum
Source IP address
Destination IP address
Options..
24
Use of ECN with TCP

• Receiver signals congestion to the sender by
  setting the ECN-Echo flag in the TCP header.
• Bit 9 in the reserved field of the TCP header
• Deals correctly with asymmetric routes
• ECN-Echo flag also used to negotiate ECN use
• The TCP sender should respond to ECN feedback as
  if a single packet loss occurred.
• Reduce the congestion window size
• ECN and RED are supposed to leverage each other.
• The router should set the CE bit if it would
  otherwise have dropped the packet (for a non-ECN
  enabled flow)
• When RED is used, this happens before the queues
  fill up so ECN and RED combined can result in
  congestion notification without packet loss