performance
CS519: TCP Computer Networks
Lecture 5, Part 3: Mar 10, 2004 Transport: TCP performance
CS519
Weve seen how TCP the protocol works But there are a lot of tricks required to make it work well
Indeed, the Internet nearly died an early death because of bad TCP performance problems
TCP performance
CS519
Interactive TCP
CS519
Making interactive TCP efficient for low-bandwidth links Filling the pipe for bulk-data applications Estimating round trip time (RTT) Keeping the pipe full Avoiding congestion
Interactive applications like telnet or RPC send only occasional data Data sent in both directions Data often very small Packet overhead is huge for small packets
<3% efficiency for a 1-byte data packet This is bad for low-bandwidth links
1
Who cares about low-BW links?
CS519
Transmit versus wait
CS519
Historically low-BW links were a serious problem
As access links got faster, people worried less about this
Ubiquitous computing over TCP/IP wireless links makes this interesting again
Low-power devices
One basic engineering tradeoff is to wait before transmitting Wait for more data to send a bigger packet Hold off on the ACK so that data can be piggybacked with the ACK This is not an easy tradeoff to make--you can only go so far with this approach
TCP/IP header compression
CS519
TCP/IP compression components
CS519
A better approach is to compress the TCP and IP headers (RFC 1144, 2507 - 2509) Basic idea is to:
not transmit fields that dont change from packet to packet, and to transmit only the deltas of those fields that do change
2
TCP header compression
CS519
TCP/IP fields that dont change
CS519
How much compression can we get out of TCP/IP From 40 bytes to:
20 bytes? 10 bytes? 5 bytes? 2 bytes?
This cuts the header in half!
More compression
CS519
Compression header
CS519
Total length not needed because link layer transmits that (2 bytes) IP checksum not needed because there isnt much left to checksum (2 more bytes)
3
Compression issues
CS519
When to schedule transmission
CS519
The main issue is how to deal with errors Once an error occurs, the decompressor cant recover unless a new complete packet is sent RFC1144 has a clever solution to this ...
As we saw, TCP segment transmit doesnt have to correspond to app send() When should TCP send a fragment?
As soon as it gets data to send? As soon as it has a packets worth to send (MSS Max Segment Size)? Not until some timer goes off?
When to schedule transmission
CS519
Silly Window Syndrome
CS519
If TCP sends right away, it may send many small packets If TCP waits for a full MSS, it may delay important data If TCP waits for a timer, then bad behavior can result
Lots of small packets get sent anyway Silly Window Syndrome
This is a nice situation:
(nice big packets, full pipe)
4
Silly Window Syndrome
CS519
Silly Window Syndrome
CS519
Imagine this situation:
How could we get out of it???
Small packets introduced into the loop tend to stay in the loop How do small packets get introduced into the loop?
Silly Window Syndrome: Small packet introduced
CS519
Silly Window Syndrome prevention
CS519
Receiver and sender both wait until they have larger segments to ACK or send Receiver:
Receiver will not advertise a larger window until the window can be increased by one full-sized segment or by half of the receivers buffer space whichever is smaller
5
Silly Window Syndrome prevention
CS519
When to schedule transmission (again)
CS519
Sender:
Waits to transmit until either full a sized segment (MSS) can be sent or at least half of the largest window ever advertised by the receiver can be sent or it can send everything in the buffer
App can force sender to send immediately when data is available
Sockopt TCP_NODELAY
Otherwise, sender sends when a full MSS is available Or when a timer goes off
But with silly window constraints
TCP: Retransmission and Timeouts
Round-trip time (RTT) Retransmission TimeOut (RTO) Guard Band
TCP: Retransmission and Timeouts
CS519
Picking the RTO is important:
CS519
Pick a values thats too big and it will wait too long to retransmit a packet, Pick a value too small, and it will unnecessarily retransmit packets.
Host A
Data1 Data2
Estimated RTT
ACK Host B
ACK
TCP uses an adaptive retransmission timeout value: Congestion RTT changes Changes in Routing frequently Next few slides from Nick McKeown, Stanford
The original algorithm for picking RTO: 1. EstimatedRTTk= EstimatedRTTk-1 + (1 2. RTO = 2 * EstimatedRTT
Determined empirically
) SampleRTT
Characteristics of the original algorithm:
Variance is assumed to be fixed. But in practice, variance increases as congestion increases.
6
TCP: Retransmission and Timeouts
CS519
There will be some (unknown) distribution of RTTs. We are trying to estimate an RTO to minimize the probability of a false timeout.
Probability
TCP: Retransmission and Timeouts
Karns Algorithm
CS519
Host A Host B Host A Host B
Router queues grow when there is more traffic, until they become unstable. As load grows, variance of delay grows rapidly.
Average Queueing Delay
Retransmission Wrong RTT Sample
Variance grows rapidly with load
Retransmission Wrong RTT Sample
Problem:
variance
How can we estimate RTT when packets are retransmitted?
Solution:
RTT
On retransmission, dont update estimated RTT (and double RTO).
mean
Load
(Amount of traffic arriving to router)
TCP: Retransmission and Timeouts
CS519
Newer Algorithm includes estimate of variance in RTT: Difference = SampleRTT - EstimatedRTT EstimatedRTTk = EstimatedRTTk-1 + (*Difference) Deviation = Deviation + *( |Difference| ...