[Paper Link]
Networks at the time were suffering from widespread congestion, despite the fact that the TCP specification had a theoretically correct description of how to avoid it. The principle they wish to adhere to is the 'conservation of packets' principle, which states that a new packet should not be transmitted until another packet has left the network. Since the protocol itself adheres to conservation of packets but networks at the time were still failing due to load, then they observe that this must be due to implementation bugs. Thanks to the bugs, one of the following three things happens: a connection doesn't get to equilibrium, a sender injects a new packet before one has exited, or an equilibrium can't be reached because of resource limits.
Descriptions of the changes they made to the 4BSD TCP implementation:
Slow-start. A connection can potentially not get to equilibrium if it acts wonky on startup. A host doesn't send its next packet until it's received an ACK. However, if restarted hosts start off firing off packets really fast and then throttle downwards, or starts at 0 and has no defined way of going upwards, that can cause the connection to not be at equilibrium. Instead, slow-start gradually increases the number of packets being sent. It starts at 1 and increases as more and more ACKs come back.
Round-trip-time variance estimation and exponential retransmit timer backoff. Sometimes packet transmission fails and therefore no ACK is generated. At what point should the sender decide to retransmit? Their round-trip-time variance estimation algorithm addresses this. And, if a packet needs to be retransmitted repeatedly, their exponential retransmit timer backoff algorithm handles that.
More aggressive receiver ack policy and dynamic window sizing on congestion. If recipients ALWAYS send an ACK upon receipt, then the lack of an ACK is equivalent to the network notifying the sender of congestion on that link. That near-guarantee of an ACK if all is well is what they mean by an aggressive receiver ACK policy. Additionally, they describe 'dynamic window sizing', which talks about how to increase/decrease (multiplicative increase and additive increase) to fill up a connection.
-- Unlike the previous paper, none of the main schemes they discuss need the cooperation of anything in the core. They can infer congestion by dropped packets, so no specific indicator (or view of the network state) is necessary. The end-to-end argument is satisfied here.
-- In their future work, they address the issue of misbehaving hosts. They argue that ONLY with the participation of gateways can you ensure fairness, since you can't trust hosts to be fair without another agent to police the situation. The idea is that if a host starts using more than it's fair share, the gateway starts dropping its packets.
-- The paper takes a very practical tone. I especially like how they explain their logic, the major takeaway points, the relevant math, AND the actual algorithm. It's a well-written, easy-to-read paper, in my opinion.
Blog Archive
-
▼
2009
(32)
-
▼
September
(11)
- Understanding TCP Incast Through Collapse in Datac...
- Safe and Effective Fine-grained TCP Retransmission...
- VL2: A Scalable and Flexible Data Center Network
- PortLand: A Scalable Fault-Tolerant Layer 2 Data C...
- Detailed Diagnosis in Enterprise Networks
- Floodless in SEATTLE
- Congestion Avoidance and Control
- Analysis of the Increase and Decrease Algorithms f...
- Understanding BGP Misconfiguration
- Interdomain Internet Routing
- End-to-End Arguments in System Design
-
▼
September
(11)
Subscribe to:
Post Comments (Atom)
About Me
- Adrienne
- Berkeley EECS PhD student
True, the AIMD paper simply discusses a binary signal (congestion/no congestion) without really indicating a mechanism. That is because the DecNet protocols actually used a bit in a packet to indicate congestion. In some sense TCP embeds in the algorithm that the sender purposely overdrives the network. One can ask whether that is a good idea or not!
ReplyDelete