Outline: TCP
- Connection Invariants
- Sliding Window
- Flow Control
- Adaptive Retransmission
Notes:
Show picture from page 294 of the book.
TCP Connection Invariants
- the ISS (Initial Sequence Number) is different for
each connection and in each direction.
- an ack is sent with every packet
- ack = n acknowledges all data ISS ... n - 1
- each byte has a sequence number
- window size is in units of bytes
- syn and fin also have sequence numbers.
- a per-connection adaptive timer controls retransmission
- receiver rejects (drops, ignores) data outside the window
- sender rejects (drops, ignores) "old" acks.
TCP Sliding Window
Sender State
- ISS
- next sequence
- unacknowledged sequence ( unacked \le next).
- window size (in segment, given as offset from ack).
- urgent pointer (offset from seq).
- sequence number for last window update
- ack number for last window update
Notes:
For the last two, mention that an old ack coming in with a smaller
window might unintentionally reduce the window, so we keep the
sequence and ack numbers of packets that update the window, and only
update the window when we get a newer packet that is acking new data.
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 Flow Control
If receiver processes data more slowly than sender sends it,
eventually on the receiver:
window = buffer - ( highest.recvd - last.read) = 0
Then the sender must stop.
If x new bytes are acked, but the window grows smaller by x, then
the sender (if it was blocked by the window) cannot send any new data.
TCP Window Change
Window information is carried in Acks. If the window shrinks to zero,
the sender sends nothing, and the receiver sends no acks. How does the
sender find out if the receiver has enlarged the window?
Principle: keep the receiver as simple as possible.
The sender periodically sends a 1-byte packet outside the window.
When the window reopens, this packet will be acked and the sender will
obtain the new window.
TCP Sequence Number Wrap-Around
2^{32} bytes equals how much time on various technologies? (Book,
Table 6.1).
Bandwidth | Time until Wraparound |
T-1 (1.5Mb/s) | 6.4 hours |
Ethernet (10Mb/s) | 57 minutes |
T-3 (45Mb/s) | 13 minutes |
FDDI (100Mb/s) | 6 minutes |
OC-3 (155Mb/s) | 4 minutes |
OC-12 (622Mb/s) | 55 seconds |
OC-48 (2.4 Gb/s) | 14 seconds |
|
If packets can be delivered after as much as 60 seconds (in the
internet), then with OC-12 and up we cannot send at full speed,
or an old packet might be confused with a new one (same sequence
number).
TCP Window Size
2^{16} bytes equals how much time on various technologies? (Similar
to Book, Table 6.2, but different).
Bandwidth | RTT for max |
| Bandwidth-Delay |
T-1 (1.5Mb/s) | 0.35 seconds |
Ethernet (10Mb/s) | 52 ms |
T-3 (45Mb/s) | 12 ms |
FDDI (100Mb/s) | 5 ms |
OC-3 (155Mb/s) | 3 ms |
OC-12 (622Mb/s) | 850 us |
OC-48 (2.4 Gb/s) | 220 us |
|
2^{16} bytes is clearly inadequate for long-distance high-speed
connections (connections with large Bandwidth-Delay product).
TCP Options
Different TCP options allow for scaling of the window, and for
using a sequence number space that effectively covers more than
2^{32} bytes.
Adaptive Retransmission
Basic idea: record the time tx at which we sent the segment with
sequence number x.
If we receive ackx at time t'x, we estimate the RTT
(round-trip-time) as LastRTTx = t'x - tx.
Since the RTT varies among successive packets, we keep a
running average of RTTs. This running average is
RTTx = \alpha RTT[x-1] * \beta LastRTTx, 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.
We set the timeout to twice the average estimated RTT.
Adaptive Retransmission: Retransmitted Segments
If we sent a segment at time tx, then resent it at time t'x, and
get the ack at time t"x, we don't know whether to use
t"x - tx or t"x - t'x for our estimate.
So, (Karn/Partridge algorithm) we don't use retransmitted segments for
RTT estimation.
Timeouts and Congestion
If the network is experiencing congestion, the RTT will keep
increasing. Because we use a smoothed (averaged) RTT, our estimate
will be too low, and we might retransmit too soon (before the remote
system has a chance to ack our segment).
If we retransmit something that was not dropped, we are asking the
network to carry even more data. At a time of congestion, that is a
bad idea.
Timeouts and CongestionJakobson/Karels algorithm
Keep track of the variance in RTT.
If the RTT is not varying much, trust your estimate.
If the RTT is changing, don't trust the estimate, and set your timeout
to more than twice the estimated RTT.
Jakobson/Karels algorithm
- Has the RTT changed? Diffx = SampleRTTx - RTT[x-1]
- New estimate: RTTx = RTT[x-1] + \delta Diffx
- Deviation:
Devx = Dev[x-1] + \delta (|Diffx| - Dev[x-1])
- Timeout: Timeoutx = u RTTx + \phi Devx
With:
0 < \delta < 1 | (typically, \delta = 1/8) |
u = 1 | |
\phi = 4 | |
|
Note that dividing everything by \delta (i.e. multiplying by 8) lets
us use integers for the computation.
Summary: TCP
- Stream Transmission
- Connection Setup
- Connection Teardown
- Sender and Receiver Sliding Windows
- Sliding-Window Flow Control
- Adaptive Retransmission
Next: TCP congestion control.
| |