Outline: TCP details

• stream model
• sliding window
• retransmission
• flow control
• congestion control
• performance

TCP Stream Model

• TCP has no record boundaries:
  • TCP segments outgoing data (generally on MTU or send-operation boundaries)
  • receiver never knows whether more data is about to arrive
  • generally, if application has called receive, TCP gives it the smaller of:
    • the size R of data received so far
    • the length L of the buffer passed to receive or read

TCP Stream Example

• contrast UDP (datagram) and TCP (stream):
  • sending a 1,000-byte packet, reading with a 500-byte buffer:
    • [UDP:] the first 500 bytes are received, the rest is discarded
    • [TCP:] the first 500 bytes are received, the rest is requeued for a later receive
  • sending three 1-byte packets, reading with a 500-byte buffer:
    • [UDP:] the first 1-byte packet is received, the other packets may be received in subsequent reads
    • [TCP:] anywhere between 1 and 3 bytes may be received in a single operation

TCP Sliding Window
Sender State

• ISS
• next sequence
• unacknowledged sequence ( unacked <= next).
• window size (in segment, given as offset from ack).
• urgent pointer (offset from seq).
• sequence and ack number for last window update, to ignore older acks which might reduce window

TCP Sliding Window
Receiver State

• IRS
• next sequence expected
• window size
• buffer size
• last byte read by application (last.read)
• highest-sequence byte received (highest.recvd)
• window = buffer - ( highest.recvd - last.read)

TCP Adaptive Retransmission

• Basic idea: record the time t_x at which we sent the segment with sequence number x.
• If we receive ack_x at time t'_x, we estimate the RTT (round-trip-time) as LastRTT_x = t'_x - t_x.
• Since the RTT varies among successive packets, we keep a running average of RTTs. This running average is RTT_x = alpha RTT[x-1] * beta LastRTT_x, with alpha + beta = 1
• For example, alpha = 0.8 and beta = 0.2 is fairly insensitive to temporary fluctuations (they are reduced by a factor of 5) but takes about 5 segment computations to respond to a real change.

TCP Timeout and Retransmissions

• we set the timeout to twice the average estimated RTT.
• we retransmit a segment not acked by the timeout.
• if we sent a segment at time t_x, then resent it at time t'_x, and get the ack at time t"_x, we don't know whether to use t"_x - t_x or t"_x - t'_x for our estimate.
• so, (Karn/Partridge algorithm) we don't use retransmitted segments for RTT estimation.

In-class exercise

• we send TCP data at approximately 10Kb/s on a network limited by a 14.4 Kb/s modem
• the RTT calculation has converged to a value of 300ms (.3s)
• now someone else sends TCP data at 10Kb/s, causing congestion:

1. will our actual (measured) RTT be higher or lower than .3s?
2. will our computed RTT become higher or lower than .3s?
3. for the first few packets, is our computed RTT higher or lower than our actual RTT?
4. what are possible consequences of the gap between our computed and actual RTT?

Timeouts and Congestion
Jakobson/Karels algorithm

• keep track of the variance in RTT.
• if the RTT is not varying much, trust your estimate.
• this may allow you to retransmit sooner if a packet is really lost
• If the RTT is changing, don't trust the estimate, and set your timeout to more than twice the estimated RTT.

TCP Flow Control

• if receiver processes data more slowly than sender sends it, eventually on the receiver: window = buffer - ( highest.recvd - last.read) = 0
• when the sender receives a zero window, it may no longer send
• if the receiver acks x new bytes, but the window grows smaller by x, then the sender cannot send additional data.
• Silly Window Syndrome (SWS): receiver acks 3 bytes, sender sends a 3-byte packet.
• Nagle Algorithm: only transmit less than an MTU if everything has been acked
• see RFC 1122 for details

TCP Congestion Control

• the function of flow control is to slow down the sender to avoid overwhelming the receiver
• the function of congestion control is to slow down the sender to avoid overwhelming the network
• TCP's flow control is direct: the receiver tells the sender how much it may send
• TCP's congestion control is indirect: the sender tries to guess whether the network is congested
• the textbook describes TCP congestion control in detail in Chapter 8

Transport-Layer Performance

• one-way or ping-pong tests
• must receive all the data for repeatable results:
  • receiver must be faster than sender, or
  • protocol must have flow control mechanism, or otherwise
  • just measuring sender speed
• 1-byte case measures per-packet cost
• N-byte case measures per-byte cost
• cost of one individual layer is cost of sending from that layer, minus the cost of only the lower layers