Exam 2 Paper Review Questions

Question 1

What causes congestion collapse to occur?

Answer 1

Dropped packets and excessive queueing delays exacerbate the problem. Not only do dropped packets cause additional traffic, spurious retransmissions occur. It is not the normal traffic that causes collapse but the extra traffic caused by congestion.

Question 2

What is a spurious retransmission?

Answer 2

Spurious retransmission occurs when there is a timeout that causes retransmission, but the packet retransmitted was only delayed and not lost.

Question 3

What is efficiency in a congestion control scheme?

Answer 3

Efficiency is how much of the available bandwidth is used. (i.e. can we leave little or no bandwidth wasted?)

Question 4

What is fairness in a congestion control scheme?

Answer 4

Fairness is how the bandwidth is allocated between different flows. Two common definitions of fair are that all flows get equal throughput, or that all flows get throughput proportionate to their demand.

Question 5

What is the difference between fairness and efficiency in a congestion control scheme?

Answer 5

Efficiency is how much of the available bandwidth is used, i.e., efficient congestion control leaves little or no bandwidth wasted. (Some definitions of efficiency may refer specifically to bandwidth used to do “productive work”, thus excluding overhead traffic.) Fairness is how bandwidth is allocated between different flows. Two common definitions of fair are that all flows get equal throughput, or that all flows get throughput proportionate to their demand.

Question 6

Why might you build a video-calling service on top of UDP in-place of using TCP?

Answer 6

Latency is critical & retransmissions are pointless. The call is real-time and so the delivery guarantee of TCP is not necessary. Again, dropped frames are not a big deal as the next frame will advance the video state before a retransmitted frame could arrive anyway. Congestion control and flow control provided by TCP can cause unacceptable delays.

Question 7

Why does the linear growth rate of TCP-Reno (1/RTT) perform poorly for short lived flows in networks with large bandwidth and delay products?

Answer 7

The time period required for the congestion window to reach its maximum value is very large (on the order of minutes and hours) for TCP-Reno in paths with large bandwidth-delay products. Short lived flows may never reach a congestion event, meaning the flow unnecessarily transmitted slower than necessary over its entire lifetime to avoid congestion.

Question 8

What kinds of web traffic stand to benefit most from utilizing the TFO option?

Answer 8

Short lived TCP connections (small data sizes) on links with large propagation delays. The performance of these flows are dominated by RTT. Using TFO removes 1 RTT of delay. This reduction in RTT penalty incurred by 3WHS is highly beneficial.

Question 9

How does TFO prevent a source address spoof attack?

Answer 9

An attacker can send many HTTP GET requests for large resources to a victim server, spoofing a victim host address as the requestor. The victim server would then perform the expensive data fetch operations and transmit large volumes of data to a victim host. The result is a denial of service attack on both viticims. TFO prevents this by using an encrypted cookie that must be requested by the requestor before initiating requests. The server uses this cooke to verify that the requested address is not a forgery.

Question 10

How can a trivial implementation of TCP Fast Open be exploited to mount a source address spoof attack?

Answer 10

An attacker can send many HTTP GET requests for large resources to a victim server, spoofing a victim host address as the requestor. The victim server would then perform the expensive data fetch operations and transmit large volumes of data to a victim host. This results in a denial of service attack on both victims.

Question 11

What two categories do we typically classify traffic sources into?

Answer 11

constant bit rate (CBR) and variable bit rate (VBR) sources.

Question 12

How do we shape CBR traffic?

Answer 12

According to peak rate typically

Question 13

How do we shape VBR traffic?

Answer 13

VBR traffic is often shaped according to an average rate, and a peak rate.

Question 14

Would you use a leaky bucket or a token bucket to shape a constant bit rate (CBR) audio stream?

Answer 14

CBR is not burst and so the traffic shaping mechanism need not handle bursts. The leaky bucket would suffice to keep the stream smooth and even out any bursts.

Question 15

Why is traffic shaping necessary?

Answer 15

burst traffic in data networks need to be handled because they can fill buffers and cause packets to be lost.

Question 16

What do Random Early Detection (RED) and CoDel have in common in their approach to solving the buffer bloat problem?

Answer 16

Both drop packets even when their buffers are not full. RED determines whether to drop a packet statistically based off how close to full the buffer is, whereas CoDel calculates the queueing delay of packets that it forwards and drops packets if the queueing delay is too long.

Question 17

If you want to find out if a remote host is currently under a DoS attack, would you use active or passive measurement?

Answer 17

Active measurements, such as ping, are required here. Only the server’s owner or ISP would be able to use passive measurements, since they control the machines over which the server’s traffic is handled. Excessive ping delay sto the server are a sign of congestion on the server’s link.

Question 18

Why is it a bad idea to use massive buffers to ensure high link utilization?

Answer 18

Massive buffers have a cost in terms of size, power consumption, and design complexity. Large buffers are implemented in DRAM and not SRAM typically. It also presents problems for low latency applications.

Question 19

Under what conditions was the “rule-of-thumb” for buffer size (B=RTT*C) originally conceived? How does this fundamentally differ from current, real world conditions?

Answer 19

This rule of thumb is derived from an analysis of a single long lived TCP flow. Actual flows in backbone routers are much different. A 2.5 Gb/s link typically carries 10,000 flows at a time, of which the life of the flow varies. Of the flows that are not synchronized, they have various RTTs and their congestion windows are not synchronized.

Question 20

Statistical modeling of desynchronized long lived flows indicate that smaller buffer sizes are sufficient to maintain link utilization as the number of these long-lived flows increases. Why do short lived flows (less than 100 packets) not significantly detract from these findings?

Answer 20

When the vast majority of flows across a link are short lived, the flow length distribution remains dominated by the long lived flows on the link. This means that the majority of the packets on the link at any given time belong to long lived flows.

Question 21

How do standing queues develop in network buffers at bottleneck links?

Answer 21

Queues develop at bottleneck links as a result of the bottleneck’s reduced forwarding speed. As some packets in the queue are forwarded, the TCP sender will begin to receive ACKs and send more packets, which arrive at the bottleneck link buffer, refilling the queue. The difference in the bottleneck link speed and the link RTT (driving the congestion window of the TCP flow) will result in a certain number of packets consistently occupying the buffer.

Question 22

Why is a standing queue not identified as congestion?

Answer 22

Standing queues are not congestion because it results from a mismatch in congestion window and the bottleneck link size. A standing queue can develop in single flow environments, and under usage limits that would eliminate actual congestion.

Question 23

How does CoDel decide whether or not to drop a flow’s packets?

Answer 23

CoDel assumes that a standing queue of the target size is acceptable, and that at least one maximum transmission unit (MTU) worth of data must be in the buffer before preventing packets from entering the queue (by dropping them). CoDel monitors the minimum queue delay experienced by allowed packets as they traverse the queue (by adding a timestamp upon arrival). If this metric exceeds the target value for at least one set interval, then packets are dropped according to a control law until the queue delay is reduced below the target, or the data in the buffer drops below one MTU.

Question 24

Why do ISPs want to peer with CDNs?

Answer 24

lower transit costs & better performance for customers