Scribed by Glenn Ulansey
General Discussion:
- Why are we talking about TCP? → 90% of internet traffic
- Congestion is more traffic on the network than it can handle. But even in such cases, we want to keep information flowing.
- Onus is on the sender to deal with congestion, and are relied on to change their behavior
- Why don’t people cheat? → Laziness; ISP might monitor; etc
- Most used TCP: NewReno with SACK (probably)
- Implementations can vary slightly(windows vs. linux)
- Each OS might support multiple types
- Each has many parameters that can be tuned
- Max utilization of a link with TCP is <100%, because the next time the window size is increased, two packets will be sent, and one of those must be dropped(assuming no buffer)
- 75% utilization average in router with a single flow
- Packets are unlikely to be dropped at the backbone
- After utilizing 100% of bottleneck link, TCP will still increase window size, however with no benefit for overall bandwidth
- After window is halved, sender stops sending packets until outstanding packets are completed. And if buffer is sized correctly, utilization always remains at 100%
- Not clear if RED really helps (and regardless, is not used very much)
- Buffers increase latency(along with RTT) → makes sawtooth diagram more curved
- Reasons XP LAN connection is steady:
- Probably because a buffer is saturated
- or a packet-shaper is being used (delays acks to steady bandwidth)
- Internet experience might improve if Comcast(for example) provided a smaller buffer
- Link utilization, even at non-bottleneck links are constant(other than the occasional drop, but will quickly jump up again)
- Increasing window-size based on time(CUBIC) allows all links to speed up at the same rate → good for links with RTT
- To throttle sending rates: decrease window size; delay acks(packet shaping); increase queues
Congestion Avoidance and Control:
Summary:
In 1986, the Internet experienced “congestions collapses”, this paper describes and discusses some of the changes made to TCP in order to properly address congestion. Slow start results in a gradual increase of the data transfer rate, and does so by adding a congestion window(the number of packets in the network at any time) which begins with a value of one, and increases by one on each ack for new data. Round-trip timing is important for an accurate implementation of slow start and exponential retransmit backoff, and RFC793 provides one such algorithm.
Congestion avoidance has two components: the network must notify the endpoints of congestion, and those hosts must then decrease their used bandwidth. TCP takes advantage of the fact that packet loss is almost always caused by congestion, and uses this as the notifier. In order to stabilize the system, TCP throttles traffic sources back faster than the queues are growing, using multiplicative decrease upon any timeout.
The authors also briefly touch upon the idea of “collision detection”, which would enlist the gateways to actively notify the end-points of detected congestion. Packet drops would continue to be used as a congestion signal, and one potential scheme is based on averaging between queue regeneration points.
Discussion:
- Justification for new TCP: old one didn’t work, and decided it need to to get fixed
- TCP is Complex and hard to analyze: “Was not designed”
Opinion:
Not a huge amount to say about this paper: well written, fairly thorough, and provides diagrams demonstrating the inadequacies of a transport protocol without these improvements, and the result once they are implemented. Most (if not all) of the ideas discussed are still in use today, including the idea of collision detection.
Nandita Dukkipati’s Ph.D. Thesis, Chapter 1 only – Overview of Issues with TCP, 2007
Summary:
TCP provides reliable and in order delivery of bytes, multiplexes and demultiplexes traffic from different processes, performs flow control, and perform congestion control. Congestion control is implemented using the slow start and congestion avoidance phases, and was introduced and improved in TCP Tahoe, Reno, NewReno, and SACK.
TCP has several problems:
- High bandwidth-delay environments result in long packet loss recovery times
- Requires very small loss links to sustain a flow with a large window(and thus high-throughput)
- Gets confused by lossy links
- Flows with high RTT(ie. Satellite) have difficulty obtaining their fair share of the bandwidth
- Slow start restricts short flows from completely quickly when no congestion exists
- Tries to fill up buffer space prior to bottleneck → adds extra delay to the flow
In Explicit Control Protocol(XCP), network explicitly tells the receiver the state of congestion and how to react to it. XCP is inefficient in dynamic environments and requires additional calculations in routers.
In the Rate Control Protocol(RCP), the router maintains a R(t) for every link, and “stamps” the value on every packet(unless it already contains a slower one). Then the receiver send this back to the sender(and once again every RTT), so the sender never is in slow-start. RCP Advantages: Inherently fair; much shorter completion times; no per-flow state; simple router computations. RCP Downsides: Involves the router in congestion control; no guarantees of no buffer-overflow.
Discussion:
- Why is wireless usable? Several reasons, primarily error correctly on link
- How to fix TCP? Don’t cut back window size upon packet loss; use “congestion” bit (routers mark)
- Uses for TCP acks:
- Ready to send out another racket(recipient ready)
- Last data sent, was received correctly
- No congestion
- Round-trip time
Opinion:
This paper covers a lot of ground concerning TCP and congestion control in general. One thing I found interesting while reading the part about an ideal congestion control system, are the assumptions made that it will never be perfect. For example, concerning stability, the author doesn’t state that ideal congestion control will always be stable, but instead that it will return to stability quickly.
Guido Appenzeller’s Ph.D. Thesis, Chapter 2 only – What Really Happens with TCP, 2003
Summary:
Routers today use buffers of size RTT*C, in order to keep link utilization high. The author argues that dues to multiplexing of flows, this amount can be greatly reduced, resulting in cheaper routers, and ability to use faster, on-chip RAM. The role of the router buffer is to absorb the fluctuation in the number of packets on the network. If we under-buffer a router, the sending buffer will eventually drain or stay empty, resulting in a link utilization of less than 100%. Or if we over-buffer a router, the sending rate will stay equal to the link capacity, and the buffer will never empty. From this, the queuing delay increases, along with the RTT.
The familiar rule-of-thumb is derived from the concepts that the sending rate before and after the windows size is reduced, is equal to the bottleneck link rate, and that the minimum window size is half the maximum window size. The “new” rule-of-thumb, on the other hand, takes into account individual packets, and their affect on flows.
Opinion:
This paper makes a number of thought-out assumptions, and thoroughly describes the results. It is interesting that this paper focuses on 100% utilization of links, and assumes this is the goal when making routers. However, many other researchers have found far less utilization on some backbone links, and would it be possible to take this additional fact into consideration when designing routers?
