Lesson 6 - Congestion Control & Streaming Flashcards
Resource control deals with
handling bandwidth constraints on links
The goal of congestion control
fill the internet’s pipes without overflowing them
Hosts are _______ of other hosts and their current state (i.e. how much other traffic is on the network)
unaware
Congestion collapse
Throughput is less than the bottleneck link
Congestive collapse (or congestion collapse) is the condition in which congestion prevents or limits useful communication. Congestion collapse generally occurs at “choke points” in the network, where incoming traffic exceeds outgoing bandwidth.
Saturation
point at which increasing the load no longer results in useful work getting done
Collapse
increasing the traffic load can cause the amount of work done or amount of traffic forwarded to actually decrease
Possible causes of congestion collapse
- Spurious transmissions of packets still in flight
- Undelivered packets
Spurious transmissions
when senders don’t receive acknowledgments for packets in a timely fashion, then cay spuriously retransmit, resulting in many copies of the same packets being outstanding in the network at any one time
Undelivered packets
Packets consume resources and are dropped elsewhere in the network
Solution to congestion collapse
Congestion control
-For spurious transmission: better timers and TCP congestion control
Two approaches to congestion control
- End-to-end: Network provides no explicit feedback to the senders about when they should slow down their rates. Instead, congestion is inferred, typically by packet loss, and potentially also by increased delay.
- Network-assisted: Routers provide explicit feedback about the rates that end systems should be sending in
Two parts of TCP congestion control
- Increase algorithm
2. Decrease algorithm
TCP increase algorithm
the sender must test the network to determine whether the network can sustain a higher sending rate
TCP decrease algorithm
the senders react to congestion to achieve optimal loss rates, delays, and sending rates
2 approaches of adjusting rate
- Window-based algorithm
- Rate-based algorithm
Window-based algorithm
- Sender can only have a certain number of packets outstanding (in flight). The sender uses acknowledgments from the receiver to clock the retransmission of new data.
- When sender receives another ACK from receiver, it can send another packet.
- If a sender wants to increase the rate at which it’s sending, it simply needs to increase the window size. Below example: window size is 4. If 4 are inflight, waits for an ACK for 1 of them, then sends another.
- Window-based congestion control (or AIMD) is the common way of performing congestion control in today’s networks
Rate-based algorithm
- Explicitly rate-based congestion control algorithm
- Monitor loss rate
- Use a timer to modulate the transmission rate
If RTT is 100 milliseconds, packet is 1 KB, and window size is 10 packets, what is the sending rate?
100 pkts/sec * 8000 bits/packet = ~800,000 bps, or 800 Kbps
2 goals of TCP Congestion Control
- Fairness: every sender gets their fair share of network resources
- Efficiency: network resources are used well
In multiplicative decrease, each sender decreases its rate by _______
Some constant factor of its current sending rate (e.g. by half)
3 traits of AIMD
- Distributed (all senders can act independently)
- Fair
- Efficient
TCP Incast
- The throughput collapse that results from high fan-in, high bandwidth/low latency, many small/parallel requests, and small buffers in switches in a data center
- It is a drastic reduction in application throughput that results when servers using TCP all simultaneously request data, leading to a gross underutilization in network capacity in many to one communication networks like a data center. The filling up of the buffers in the switches results in bursty retransmissions that overfill the switch buffers.
TCP timeout
Filling up of the buffers in the switches results in busty retransmissions that overfill the switch buffers.
- Can last 100s of milliseconds but the RTT in a data center is typically < 1 ms, often just 100s of microseconds
- Because the RTT are so much less than TCP timeouts, the senders will have to wait for the TCP timeout before they retransmit, and application throughput can be reduced by as much as 90% as a result of link idle time
Barrier Synchronization
- common request pattern in data centers today
- A client/application might might have many parallel threads and no forward progress can be made until all the responses for those threads are satisfied