Exam 2

TCP Fast Open: How is the primary design goal of TFO (preventing source-address spoofing attack) handled?

"Security cookie" A client that wishes to use TFO requests a cookie—an opaque bytestring—from the server in a regular TCP connection with the TFO TCP option included, and uses that cookie to perform fast open in subsequent connections to the same server.

CUBIC: Depending on the value of cwnd, CUBIC runs in three different modes - what are they?

(1) if cwnd is less than the window size that (standard) TCP would reach at time t after the last loss event, then CUBIC is in the TCP mode. (2) if cwnd is less than Wmax, then CUBIC is in the concave region, (3) if cwnd is larger than Wmax, CUBIC is in the convex region.

Buffer Bloat Example

- 3 different DSL routers * need to draw graph - some experience latency 1 second, others 10 seconds - Modem has a buffer, ISP may be upstream of that buffer and your access link may be draining that buffer at a certain rate. TCP senders in your home will send until they see lost packets but if the buffer is large, they won't actually see those lost packets until the buffer has already filled up; the senders continue to send at increasingly faster rates until they see a loss, as a result, packets that are arriving at this buffer see increasing delays and senders continue to send at faster rates because without packet loss, they don't have a signal to slow down. Solutions to the Buffer Bloat problem: 1. Smaller buffers: lots of deployed infrastructure; simply reducing buffer size 2. Shaping (can be done on many Wrt routers, e.g. Bismark)

Leaky Bucket

- A way of shaping traffic - each flow has it's own bucket - Isochronous - in a leaky bucket traffic shaper data arrives in a bucket of size Beta and drains from the bucket at a rate of rho (p). The parameter rho (p) controls the average rate. Data can arrive faster or slower into the bucket but it cannot drain at a faster rate than rho (p); therefore, the maximum average rate that traffic can be sent is this smooth rate rho (p); - The size of the bucket controls the maximum burst size that a sender can send for a particular flow; so even though the average rate cannot exceed rho (p); at times the sender might be able to send at a faster rate as long as the total size of the burst does not exceed the size of the bucket or does not overflow the bucket - The leaky bucket allows flows to periodically burst and the regulator at the bottom of the leaky bucket ensures that the average rate does not exceed the drain rate of the bucket - Can be combined with Token bucket to make composite

TCP fit for Streaming Applications

- Challenges for Media streaming: (1) large volume of data; (2) data volume varies over time; (3) users have low tolerance for delay variation; (4) users might have a low tolerance for delay, period...although some loss is acceptable - Streaming Video: server stores audio/video files and client requests them as it plays them; important for playout at the right time; - Solution: client should use a playout buffer to store data until it's needed to play continuously - so buffer may be filled fast or slowly but as long as it doesn't empty completely and empties at a steady rate, the user sees a steady streamed video - The pathologies that streaming audio/video can tolerate are loss (small amount of packet loss acceptable) and delay (some at beginning at packet stream is acceptable) TCP is not a good fit for congestion control for streaming video or streaming audio. TCP retransmits lost packets, but retransmissions may not always be useful (reliable delivery); TCP also slows down it's sending rate after packet loss which may cause starvation at the client; there's also a fair amount of overhead in the protocol; -- INSTEAD, one might consider using UDP (User Datagram Protocol) - UDP does not retransmit lost packets and it does not automatically adapt the sending rate; it also has a smaller header; Because UDP does not automatically retransmit packets or adjust the sending rate - many things are left to higher layers (like the application layer - such as when to transmit the data or how to encapsulate it or whether to retransmit and whether to adapt the sending rate).... SO higher layers must solve the fact that there's no retransmission and no sending rate adaptation (sending rate should still be fair to other TCP senders which may be sharing the link)

MPTCP: What are the five main mechanisms in TCP?

- Connection setup handshake and state machine - Reliable transmission & acknowledgment of data. - Congestion control. - Flow control. - Connection teardown handshake and state machine.

DHT (Distributed Hash Tables)

- Enable a form of content overlay called a structured content overlay. - Chord: particular distributed hash table; scalable, distributed "lookup service"; a lookup service is any service that maps keys to values (i.e. DNS, directories, etc); Desirable properties of chord: +scalability, +provable correctness, +performance - Consistent Hashing: underlying mechanism that enables Chord; - Hash table is distributed across the network - all we are trying to do is a simple lookup

Server Selection

- How to choose the appropriate server replica or cache for a particular client? - Could answer which server based on a number of criteria: such as the lowest load, server with the lowest network latency, or any "alive" server to help provide fault tolerance - CDNs typically aim to direct clients to servers with the lowest latency (since latency plays a huge role in the performance of web)

Content Routing

- How to direct clients towards the appropriate replica once it's selected? - One might do this in a number of ways: (1) Routing (i.e. anycast): so, one could number all of the replicas with the same IP address and then rely on routing to take the client to the closest replica based on the routes that the Internet routers choose - this is simple but it provides the service level providers very little control (-coarse) over which servers the clients ultimately get redirected to (because the redirection is at the whims of Internet routing); (2) Application-based (i.e. HTTP redirect): effective, but it requires the client to first go to the origin server to get the redirect in the first place, increasing latency/delays; (3) Naming based (i.e. DNS): most common; client looks up a particular domain name, and the response contains an IP address of a nearby cache; provides significant flexibility in directing different clients to different server replicas (+fine-grained control, +fast);

Power Boost

- June 2006 (Comcast) - traffic shaping mechanism - allows subscriber to send at higher rate for a brief period of time - Power boost is the spare capacity for users who don't put sustained load on a network - d = B/(r-Rsus) - Examples: Bismark - Different homes --> different shaping profiles - Effects on latency and loss rates; greater latency + loss may be had when sending at higher rate because access link may not be able to support the higher rate - sender might configure rate to never exceed sustained rate (R) --> will avoid seeing latency effects

Consistent Hashing

- Main Idea: keys and nodes map to same ID space - Node: hash (IP) - Key: hash (Key) - how to map key Ids to node ids so that we know which nodes are responsible for resolving the lookups for a particular key? - Chord: key stored at successor (node with next highest ID) + Load balance (all nodes recieve roughly the same number of keys) + Flexibility (when a node leaves the network, only a fraction of the keys need to be moved to a different location) This solution is optimal: number of keys that need to be remapped to maintain load balance when a node joins or leaves the network. - How to implement?: (1) Option 1: every node knows location of every other node. Lookups are fast (O(1)) but the tables are O(N) - because every node needs to know the location of every other node in the network. (2) Option 2: each node only knows the location of it's successor, this results in a small table (O(1)), but locating the content is O(N) Solution to these two crappy options is Finger Tables (every node knows m other nodes)

MPTCP: Connection Setup:

- Negotiating MPTCP in the initial handshake is feasible, but with some caveats There is no real problem if a middle- box removes the MP CAPABLE option from the SYN: MPTCP simply falls back to regular TCP behavior. How- ever removing it from the SYN/ACK would cause the client to believe MPTCP is not enabled, whereas the server believes it is. This mismatch would be a problem if data packets were encoded differently with MPTCP. The obvious solution is to require the third packet of the handshake (ACK of SYN/ACK) to carry an option in- dicating that MPTCP was enabled. However this packet may be lost, so MPTCP must require all subsequent data packets to also carry the option until one of them has been acked. If the first non-SYN packet received by the server does not contain an MPTCP option, the server must assume the path is not MPTCP-capable, and drop back to regular TCP behavior. Finally, if a SYN needs to be retransmitted, it would be a good idea to follow the retransmitted SYN with one that omits the MP CAPABLE option.

HTTP Responses

- Pages/objects in pages are returned to web browser as responses - Server action (server maintains no information about past client requests - stateless) - Contents: --> Status Line: includes (1) HTTP Version; (2) Response Code (may indicate a number of possible outcomes; 100s are informational; 200s success (200 = OK); 300s redirect (301 moved per monthly; 304 not modified); 400 errors (404 Not found); 500 server errors; --> Location (may be used for redirection) --> Server (server software) --> Allow (indicates legal HTTP methods: GET, HEAD, etc) --> Content Encoding (describes how content is encoded, example: compressed) --> Content Length (bytes) --> Expires: how long content can be cached --> Last-modified: indicates last time page was modified EXAMPLE: HTTP/1.1 200 OK Date: Tue, 25 Oct 2011 ... Server: Apache/2.2.16... .... Set Cookie: X; path=/...

Bittorent

- Peer-to-peer content distribution network (commonly used for file sharing, large file distribution) - Example: network with lots of clients; all clients want a large file from the origin; each client shouldn't request a copy of the file because the origin may be overloaded or the act of making the request may create congestion or overload at the network where the content is being hosted; solution is to fetch the content from other peers!; take original file, chop into pieces; each different piece goes to different client; then we can replicate different pieces on different peers - through trading of the pieces of the file, everyone eventually gets the entire file. - has several steps for publishing: (1) Peer creates "torrent" which contains metadata about the tracker and pieces of the file, as well as a checksum for each piece of the file at the time the torrent was created; (2) "Seeders" - clients that need to maintain a copy of the entire file - create initial copy; - Clients that contain incomplete copies of the file are called leechers - Tracker allows peers to find each other, and it also returns a random list of peers that any particular leecher can use to swap parts of the file - Bittorrent solved a problem that many attempts similar to this could not called freeriding (whereby a client might leave a network as soon as it finished downloading a copy of the file - not providing any benefit to clients who also want the file) - Bittorrent's solution for freeriding is called Choking (tit for tat strategy): temporarily refuses to upload chunks to another peer that is requesting them; downloading, of course, occurs as normal - but if a node is unable to download from a client, don't upload it - this ensures that nodes cooperate - One of the problems that bittorrent needs to solve is ensuring that each client gets chunks to swap with other clients; if all of the clients received the same chunks then no one would want to trade with one another and everyone would have an incomplete copy of the file. To solve this problem, bittorrent clients use a policy called rarest piece first (allows a client to determine which pieces are most rare among clients --> and download those first) - ensures most common pieces are left to the end for download and that a large variety of pieces are downloaded from the seeder. - Additionally, a client has nothing to trade and it's important to get a piece as soon as possible - rare pieces are harder to come by initially so downloading a rare piece is maybe not a good idea so select random piece first and download it from seeder;

Token Bucket

- Sometimes we want to shape bursty traffic patterns; but still ensure that the flow does not exceed some average rate - p (rho) = rate at which tokens are placed in the bucket - b (beta) size of bucket - lambda = peak; lambda = avg - Tokens arrive into bucket at rate p and b = capacity of bucket; - Traffic can be sent by the regulator as long as there are tokens in the bucket - To consider the difference between a token bucket and a leaky bucket, consider sending a packet of size b that is less than beta: -- If the token bucket is full --> the packet is sent and b tokens are removed -- If the token bucket is empty --> the packet must wait until b tokens drip into the bucket -- If the bucket is partially full --> then it depend; if the number of tokens in in the bucket exceed little b then the packet is sent immediately; otherwise, we have to wait until there are little b tokens in the bucket before we can send the packet

CDNs (Content Distribution Networks)

- Special type of cache used to improve performance - Overlay network of web caches that is designed to deliver content to a client from the optimal location (in many cases, optimal means geographically closest) - Made of geographically disparate groups of servers; where each group can serve all the content on the CDN - can be quite extensive overall - some CDN's are owned by content providers (like Google) (can place servers in other ISPs) and others are owned by Networks or ISPs - number of cached nodes in a CDN can vary;

TCP Incast

- TCP Throughput collapse problem called TCP Incast - A drastic reduction in application throughput that results when servers using TCP all simultaneously request data leading to a gross underutilization of network capacity in many to one communication networks like a data center - The filling up of the buffers at the switches result in bursty retransmissions that overfill the switch buffers; and these bursty retransmissions are caused by TCP Timeouts (can last 100s of ms) but the RTT in a data center is typically less than a millisecond - because the RTT are so much less than TCP Timeouts the senders will have to wait for the TCP timeout before they retransmit Solutions to TCP Incast Problem: - ACKs for every other packet - micro second granularity retransmission

CDN Challenges

- The underlying goal of CDNs is to replicate content on many servers so that the content is replicated close to the clients -- leaves many open questions (how to replicate the content? where it should be replicated? how clients should find the replicated content? how to choose the appropriate server replica or cache for a particular client?--> called server selection How to direct clients towards the appropriate replica once it's selected?-->called content routing)

MPTCP: TCP's Recieve Window (Flow Control)

- indicates the number of bytes beyond the sequence number from the acknowledgment field that the receiver can buffer. The sender is not permitted to send more than this amount of additional data.

Persistent Connections

- multiple requests/responses are multiplexed on a single TCP connection - delimiters indicate the ends of the requests - content-length allows the receiver to identify how long a response is (server has to actually know the size of the transfer in advance) - can be combined with pipelining (client sends requests as soon as it encounters a referenced object; so there is as little as one RTT for all referenced objects before they begin to be fetched) - Persistent connections with pipelining is the default behavior in HTTP 1.1

CDNs and ISPs

- symbiotic relationship when it comes to peering relationships - CDNs like to peer with ISPs because peering directly with ISPs where a customer is located provides better throughput (since there are not intermediate AS hops and network latency is lower); Having more vectors to deliver content (+ redundancy) increases reliability and during large request events having direct connectivity to multiple networks where the content is hosted allows an ISP to spread it's traffic across multiple transit links (+burstiness) thereby potentially reducing the 95th percentile and lowering it's transit costs - On the other hand, there are good reasons for ISPs to peer with CDNs: (1) good performance for customers (providing content closer to the ISPs customers, allows the ISP to provide customers with good performance for a particular service) (major selling point for ISPs); (2) lower transit costs

TCP FAST OPEN: What are the two components of the RTT of a web flow?

1) Transmission Delay (has been reduced in the past two decades) 2) Propagation Delay (largely constrained by the speed of light and therefor has remained unchanged)

DYNAMIC ADAP STREAMING: What are the reasons that lead to the choice of HTTP as the delivery protocol for streaming services?

1. HTTP streaming is spreading widely as a form of delivery of Internet video. 2. There is a clear trend towards using HTTP as the main proto- col for multimedia delivery over the Open Internet. 3. HTTP-based delivery enables easy and effortless streaming services by avoiding NAT and firewall traversal issues. 4. HTTP-based delivery provides reliability and deployment simplicity due as HTTP and the underlying TCP/IP protocol are widely implemented and deployed. 5. HTTP-based delivery provides the ability to use standard HTTP servers and standard HTTP caches (or cheap servers in general) to deliver the content, so that it can be delivered from a CDN or any other standard server farm. 6. HTTP-based delivery provides the ability to move control of "streaming session" entirely to the client. The client basically only opens one or several or many TCP connections to one or several standard HTTP servers or caches. 7. HTTP-based delivery provides the ability to the client to automatically choose initial content rate to match initial available bandwidth without requiring the negotiation with the streaming server. 8. HTTP-based delivery provides a simple means to seamlessly change content rate on-the-fly in reaction to changes in avail- able bandwidth, within a given content or service, without requiring negotiation with the streaming server. 9. HTTP-based streaming has the potential to accelerate fixed- mobile convergence of video streaming services as HTTP- based CDN can be used as a common delivery platform.

TCP FAST OPEN: What are the steps a client performs to request a TFO cookie?

1. The client sends a SYN packet to the server with a Fast Open Cookie Request TCP option. 2. The server generates a cookie by encrypting the client's IP address under a secret key. The server responds to the client with a SYN-ACK that includes the generated Fast Open Cookie in a TCP option field. 3. The client caches the cookie for future TFO connections to the same server IP.

TCP FAST OPEN: How does the client utilize the fast open cookie that it receives from a server?

1. The client sends a SYN with the cached Fast Open cookie (as a TCP option) along with application data. 2. The server validates the cookie by decrypting it and comparing the IP address or by re-encrypting the IP address and comparing against the received cookie. (a) If the cookie is valid, the server sends a SYN- ACK that acknowledges the SYN and the data. The data is delivered to the server application. (b) Otherwise, the server drops the data, and sends a SYN-ACK that only acknowledges the SYN sequence number. The connection proceeds through a regular 3WHS. 3. If the data in the SYN packet was accepted, the server may transmit additional response data segments to the client before receiving the first ACK from the client. 4. The client sends an ACK acknowledging the server SYN. If the client's data was not acknowledged, it is retransmitted with the ACK. 5. The connection then proceeds like a normal TCP con- nection.

31. How does BitTorrent implement the tit-for-tat algorithm? Be sure to explain in detail, including the roles of both choking and unchoking.

A BitTorrent client sends data only to the top N peers who are sending to it, plus one peer who is optimistically unchoked. Let's say for example purposes that N=4. Your BitTorrent client will choose the 4 peers who are sending to it at the fastest rate and it will send data to them in return. It will not send to other peers, and they are said to be choked. Thus it provides tit-for-tat by sending to those who send the most to it, and choking those that are not sending to it, or are sending slowly. However, this creates a problem where two peers who might be able to send to each other are mutually choked. Neither will begin sending to the other because the other is not sending to it. Therefore, each client will optimistically unchoke one peer at any given time for a brief period. If the client sends fast enough to the optimistically unchoked client to get on its top-4 then the peer will send data back in return. If the client receives enough data from the peer for it to be in the top-4 then that peer becomes one of the new top-4 and the slowest of the previous top-4 will be choked. Thus they both end up in each other's top-4. (The peer is no longer "optimistically" unchoked, and is merely unchoked. A new peer is selected to be optimistically unchoked.) On the other hand, if the client does not get into its peer's top-4, or if it does but the peer does not send fast enough in return to get in the client's top-4, then they will not end up in each other's top-4. After some time, the client will stop optimistically unchoking that peer and stop sending to it. It will choose a new peer to optimistically unchoke. This process repeats forever (until the client has the entire file, that is) in order to keep exploring different peers for better matches than the client's current top-N. The game theoretic result is that clients will end up sending to peers that are able to send back about the same amount - fast peers will get paired up, while slow peers are matched with each other. This happens because a fast peer will readily drop a slow peer from its top-N in favor of another fast peer, matching fast peers together. Slow peers will not get matched with fast peers because the fast peers will soon learn to choke them, but they will pair up with other slow peers because neither peer can find a better match who is willing to unchoke them.

32. In a distributed hash table, how many steps (hops) are required to lookup an item if the finger table is a constant size (i.e., its size does not depend on the number of DHT nodes in the system)? Explain why that is the right answer.

A lookup will require O(N) hops in this case. Suppose a constant size of 1, as an example. Each node only knows how to find the next one, so it basically forms a ring topology. In the worst case, the requested item is on the last node in the ring before getting back to the node that originated the request. So the request has to go all the way around the ring, taking N-1 hops. Based on similar reasoning, if a larger, constant number of nodes is in the finger table, a proportionately smaller amount of time may be required. However, for any given constant size finger table, as the number of nodes in the system grows, the number of hops required will still be on the order of O(N).

20. If you want to find out if a remote host (i.e., not your server) is currently under a DoS attack, would you use active or passive measurement? Explain why.

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 delays to the server are a sign of congestion on the server's link. (It's hard to be sure that it's due to a DoS attack without additional context, but it's a sign that something is wrong...)

3. Assuming traditional TCP Reno with AIMD behavior (i.e., the version presented in the lecture videos), suppose a TCP flow's bottleneck link has 1 Gbps capacity, and that link is not being shared with any other flows. What will the average throughput of that flow be, in megabits per second (Mbps)?

Additive increase will increase the throughput until it equals the bandwidth, at which point a packet loss will occur and trigger multiplicative decrease. At that point, throughput immediately drops to ½ the bandwidth. Additive increase then resumes, raising throughput linearly until it reaches the total bandwidth again. Thus the average throughput is the average of ½ bandwidth and 1x bandwidth = ¾ bandwidth. Therefore, the average throughput on a 1 Gbps link will be ¾ x 1 Gbps = 750 Mbps. (A more detailed approach may look at the area beneath the throughput curve, but this results in the same math since the additive increase is linear.)

12. Describe how a trivial implementation of TCP Fast Open (in which the server replies to all HTTP GET requests with a TCP SYN-ACK packet with data attached) can be exploited to mount a source address spoof attack. How does TFO prevent this?

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 victims. TFO prevents this by using an encrypted cookie that must be requested by the requestor before initiating requests. The server uses this cookie to verify that the requester address is not a forgery.

7. Describe the operation of BIC-TCP's binary search algorithm for setting the congestion window. Once stable, how does BIC-TCP react to changes in available bandwidth, i.e. what happens when there is a sudden increase or decrease in available bandwidth?

At a high level, when BIC-TCP experiences a packet loss event, the congestion window value is set to the midpoint between last window value that did not suffer from loss (WMAX) and the previous window size that was loss free for at least one RTT (WMIN). This is often referred to as a binary search, as it follows intuitively that the maximum possible stable window value is somewhere between a value that was known to be stable and the value achieved just prior to the loss event. This algorithm "searches" for this maximum stable window value by effectively reducing the range of possible value by half per packet loss event. Once this maximum stable window size has been achieved, if there is a sudden increase in available bandwidth, then max probing phase of BIC-TCP will rapidly increase the window beyond the value of WMAX until another loss event occurs, which resets the value of WMAX. If a sudden decrease in available bandwidth occurs, and this loss is below the value of WMAX, then the window size is reduced by a multiplicative value (β), enabling a safe reaction to a lower saturation point.

CUBIC: Benefits of BIC-TCP/Drawbacks?

Benefits: - Good scalability in high speed networks - Fairness among competing flows of its own - Stability with low window oscillations Drawbacks: - Still too aggressive for TCP, especially under short RTT or low speed networks - The several different phases of window control add complexity in implementing the protocol and analyzing its performance

Two classes of Traffic

CBR: Traffic arrives at regular intervals and packets are typically the same size as they arrive; resulting in a constant bit rate of arrival (ex audio); shaped according to a peak rate VBR: (video, data); shaped according to average rate and peak rate where the average rate might be fraction of peak rate

8. How does the replacement of this congestion control algorithm with a cubic growth function in CUBIC-TCP improve on BIC-TCP? Discuss.

CUBIC retains the strengths of BIC-TCP, but makes many improvements. First, BIC-TCP is a rather complex algorithm that approximates a cubic function. It's growth function has both linear and logarithmic elements, and many different phases (additive increase, binary search, max probing). Additionally, on short RTT and low speed networks, BIC-TCP's growth function can be too aggressive (recall it was designed to achieve high utilization on large bandwidth, long RTT networks), making it fairly unfriendly to other TCP flows competing for bandwidth. CUBIC replaces the growth function in BIC-TCP with a cubic growth function, based on the elapsed time between congestion events. This function maintains the multiplicative decrease utilized by many TCP variants, but records the window size at a congestion event as WMAX. Using this value of WMAX , the cubic growth function can be restarted, with the plateau occurring at WMAX. This eliminates the need for multiple growth phases and maintaining values like SMAX/MIN. The plateau of the cubic growth function retains BIC-TCP's stability and utilization strengths

26. Consider the CoDel active queue management algorithm. How does the algorithm decide whether or not drop a flow's packets? What effect does dropping the packet have on the TCP sender?

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. Dropping a flow's packet triggers a congestion window reduction by the TCP sender, which helps to eliminate buffer bloat.

Congestion Control Goals

Congestion Control has two main goals: (1) use network resources efficiently (fill the sink as quickly as possible); (2) preserve fair allocation of resources across senders; (3) Extra goal is to avoid congestion collapse

1. What causes congestion collapse to occur?

Congestion collapse occurs when dropped packets and excessive queuing delays that result from congestion in turn further exacerbate the problem, which causes more drops and delays, and so on. Dropped packets cause retransmissions that add additional traffic to the congested path, while excessive delays can cause spurious retransmissions (i.e., a timeout occurs when the packet was merely delayed, not lost). Note that normal traffic that contributes to congestion is not the cause of collapse, it is the extra traffic that is caused by congestion that leads to collapse.

30. Of the various methods to redirect web requests to CDN servers, DNS redirection is the most common. Why would this method be more popular than the alternatives?

DNS-based redirection is much faster than HTTP redirection, as the latter requires a couple extra round trips to servers. (It's actually more than just one extra round trip because you need to establish a TCP connection to a second different server.) It also gives the CDN provider more control over who will be redirected where than a technique like IP anycast would. Finally, it is not too difficult to implement (even if slightly more complex than the other two) and it uses tools that are widely supported (i.e., DNS) and do not need any modifications to support this technique (i.e., DNS works out of-the-box).

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

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 allocated between the different flows. Two common definitions of fair are that all flows get equal throughput, or that all flows get throughput proportionate to their demand (i.e., how much they want to send).

24. Statistical modeling of desynchronized long lived flows indicates that smaller buffer sizes are sufficient to maintain link utilization as the number of these long lived flows increases. However, not all flows can be expected to be long lived. Discuss why short lived flows (less than 100 packets) do not significantly detract from these findings.

Even 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. Required buffer size in the case of short lived flows depends on actual load on the links and the length of the flows, not the number of flows or propagation delays. This means that roughly the same amount of buffering required for desynchronized long lived flows will also be sufficient for short lived flows as well.

Congestion Control Fairness and Efficiency

Fairness: everyone gets fair share Efficiency: network resources are used well - Phase plot: capacity = x1 + x2 (efficiency) (anything to left of line = underutilization) (anything to the right = over-utilization) --> makes a right triangle |_\ If x1 = x2 --> fairness |/_ The optimal point is where these two lines cross *see udacity lecture for phase plot diagram details - Every time AI is applied it improves efficiency; every time MD is applied it improves fairness

MPTCP: What problems does adding a subflow raise?

First, the new subflow needs to be associated with an existing MPTCP flow. The classical five-tuple cannot be used as a connection identifier, as it does not survive NATs. Second, MPTCP must be robust to an attacker that attempts to add his own subflow to an existing MPTCP connection.

HTTP Requests

HTTP (Hypertext Transfer Protocol - Application layer protocol to transfer web content) - Web Browser makes requests - Client action - Contents: -->Request line (typically indicates, a (1) method of request (GET content from URL (can also be used to send content to server), POST or send data to the server, HEAD returns typically only the headers of the get response, not the content), (2) URL (index.html), (3) Version Number --> Headers: (typically optional): include (1) Referrer (what URL caused the page to be requested); (2) User agent (client software being used to fetch the page) - EXAMPLE: GET / HTTP/1.1 (request line) (headers below) Accept: */* (any content type) Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/5.0 Host: www.gtnoise.net Connection: Keep-Alive Early HTTP only had 1 request/response per TCP connection (+simple to implement; - TCP connection for every request)

CUBIC: TCP Friendly Region

If cwnd is less than Wtcp(t), then the protocol is in the TCP mode and cwnd is set to Wtcp(t) at each reception of ACK. - Prevents CUBIC flow from dominating links that TCP is effectively utilizing

Buffer Bloat

In the example we explored, the sender could send at a rate r that was bigger than Rsus without seeing packet loss. Now if there's a buffer in the network that can support this higher rate we will see that buffer will start filling up with packets. But this buffer can only drain at Rsus. So, even though sender might be able to send at a faster rate for a brief period of time in terms of throughput, all of those packets the sender sent at that faster rate are queued up in line waiting to be sent. As packets are waiting in buffer, delays will be greater than if they arrived at the front of the queue. The delay that the packet will see is the amount of data in the buffer divided by the rate that the buffer can drain (Rsus) These large buffers introduce delays that ruin the performance for time critical applications such as voice and video (ex. home routers, hosts, switches/routers, home apis)

TCP AIMD

Increase: sender must test the network to determine if the link can handle a higher sending rate Decrease: senders react to the congestion to achieve optimal loss rates, delays and sending rates - success: one packet increased window per round trip (additive increase) - failure: window size reduced by half (multiplicative decrease) - AIMD == window-based approach to adjusting rates -- common way to adjust rates - Increased window size, increases rate AIMD: converge to fairness and efficiency - Every time AI is applied it improves efficiency; every time MD is applied it improves fairness - Algorithm is distributed (meaning that all senders can act independently); it's also (clearly) fair and efficient - TCP sawtooth (mapping rate against time)...AI till sender hits saturation point (filling a buffer) and then MD A sender sends at a rate of the --- line or 3/4*Wm. The saturation point of the sawtooth = Wm and the point that MD takes it back to is Wm/2. Between the lowest sending rate and the highest: Wm/2 + 1 round trips Loss Rate = (1/2)*(Wm/2)*((Wm/2)+1) Tput = (3/4)*(Wm/RTT) = lambda

CUBIC: What is the main feature of BIC-TCP?

Its unique window growth function. When it gets a packet loss event, BIC-TCP reduces its window by a multiplicative factor beta. The window size just before the reduction is set to the maximum Wmax and the window size just after the reduction is set to the minimum Wmin. Then, BIC-TCP performs a binary search using these two parameters - by jumping to the midpoint between Wmax and Wmin. Since packet losses have occurred at Wmax, the window size that the network can currently handle without loss must be somewhere between these two numbers. - Growth function after a window reduction will be most likely to be a linear one followed by a logarithmic one (additive increase, binary search) (max probing)

MPTCP: How does MPTCP work?

MPTCP is nego- tiated via new TCP options in SYN packets, and the end- points exchange connection identifiers; these are used later to add new paths—subflows—to an existing con- nection. Subflows resemble TCP flows on the wire, but they all share a single send and receive buffer at the end- points. MPTCP uses per subflow sequence numbers to detect losses and drive retransmissions, and connection- level sequence numbers to allow reordering at the receiver. Connection-level acknowledgements are used to implement proper flow control. We discuss the rationale behind these design choices below.

13. What threat do network middleboxes pose to negotiating MPTCP connections? How does the design of MPTCP mitigate this?

Network middleboxes may strip out unrecognized TCP options (flags) used during the 3-way handshake used to negotiate a MPTCP connection. This means that while the sender and receiver may both be MPTCP capable with multiple viable interfaces, a middlebox along the route may ultimately prevent a MPTCP connection. MPTCP is designed to resort to a single path TCP when both ends of the connection cannot support MPTCP. In this case, when the sender's MPTCP capable flag is stripped out by a middlebox enroute to the receiver, the receiver thinks that the sender is not MPTCP capable and proceeds with a single path TCP connection. The sender will see that traffic returning from the receiver is not MPTCP enabled (the flag is carried on all packets until acknowledged) and as such revert to single path TCP.

33. For a more typical DHT setup where the finger table has O(log N) entries, for N DHT nodes in the system, explain why the number of steps to access an item is O(log N).

O(log N) entries in the finger table means that each node knows about the node halfway around the ring back to it, about the node halfway to that one, the one halfway to that one, and so on until the last entry in the finger table that is just the next node. This means that for any given item that could be on any node, each node knows the address of at least one node that is at least half way around the ring from itself to the item. Since each hop cuts the distance to the item in half, the number of hops required to get to the item from any starting point in the DHT is O(log N). (This should be understood by analogy to binary search, divide-and-conquer, etc.)

15. Explain two of the benefits of using HTTP as a streaming media delivery protocol. Make sure you explain the "why" as well as the "what".

Possible answers include: ● HTTP is built upon TCP, which provides several benefits to streaming media including ● TCP flows can easily traverse NATs and Firewalls ● Support for TCP is widely implemented and deployed, simplifying deployment and reliability ● HTTP based CDNs and caches are currently used at scale to serve content like web pages to load balance traffic, reduce load on origin servers, and reduces latency. If HTTP is used as a streaming protocol, these CDNs and caches are able to serve the content without modification. ● HTTP based streaming puts the client in charge of the session. This enables the client to select the initial content rate, or change this rate during the stream as a reaction to available bandwidth without negotiating with the server. Additional answers may also be correct.

25. Explain how standing queues develop in network buffers at bottleneck links. Why is a standing queue NOT correctly identified as congestion?

Queues develop at bottleneck links as a result of the bottleneck's reduced forwarding speed. As some of the 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, until the flow completes, which is referred to as the standing queue. 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.

11. What kinds of web traffic stand to benefit most from utilizing the TFO option? How does TFO improve the performance of these flows?

Short lived TCP connections (small data sizes) on links with large propagation delays. The performance of these flows are dominated by the return trip time (RTT), and as such, the 3 way handshake used in standard TCP constitutes a large amount of overhead. By enabling the client and server to communicate some of the payload (data) during the 3WHS, it is possible to reduce the number of required RTTs for the flow to complete, reducing the RTT penalty incurred by the 3WHS.

18. Suppose you're running an ISP and get the crazy idea that implementing Power Boost for your own network would be a good idea. For the 6 Mbps service plan (i.e., customers can have a sustained rate of 6 Mbps), you'd like to allow them to burst up to 10 Mbps for up to 10 seconds. In megabytes (MB), what should you set the beta parameter of your token bucket to? (Round to the nearest tenth of a MB, i.e., one decimal place.)

Similar to the last problem, (10 - 6 Mbps)(10s) = 40 Mb = 5 MB (or 4.77 MB)

16. Would you use a leaky bucket or a token bucket to traffic shape a constant bit rate (CBR) audio stream? Explain why.

Since a constant bit rate stream isn't bursty, the traffic shaping mechanism doesn't need to handle bursts. Since the original stream is "smooth", it would be better to use the leaky bucket to keep the stream "smooth" and even out any bursts.

17. If you want to traffic shape a variable bit rate (VBR) video stream with average bit rate 6 Mbps and maximum bit rate 10 Mbps, should you use a leaky bucket or a token bucket? What values should you use for rho and beta if you want to allow bursts of up to 500 ms?

Since a variable bit rate stream has bursts, it is better to use a token bucket that will allow short bursts, but even things out to the average bit rate of the stream in the long run. Rho is the rate of tokens being added to the bucket, so it should match the average bit rate: rho = 6 Mbps. Beta determines how large and how long a burst is allowed. Since we want to allow up to 10 Mbps bursts for up to 500 ms (0.5s), we should allow (10 - 6 Mbps)(0.5s), or beta = 2 Mb = 250kB (or 245 kB). (Note: b = bit; B = byte.)

DYNAMIC ADAP STREAMING: What is the HTTP Streaming solution that 3GPP took initiative to specify (in addition to the already existing RTP/RTSP-based streaming solutions and the HTTP-based progressive download solution)?

Specifically the solution is designed • to support delivery of media components encapsulated in ISO base media file format box structure, • to address delivery whereas presentation, annotation and user interaction is largely out-of-scope, • to permit integration in different presentation frameworks.

23. Under what conditions was the "rule-of-thumb" for buffer size (𝐵= 𝑅𝑇𝑇̅̅̅̅̅̅ 𝑋 𝐶) originally conceived? How does this fundamentally differ from current, real world conditions?

The "rule-of-thumb" is derived from an analysis of a single long lived TCP flow. The rate is designed to maintain buffer occupancy during TCP congestion avoidance, preventing the bottleneck link from going idle. These conditions are not realistic compared to actual flows in backbone routers. For example a 2.5 Gb/s link typically carries 10,000 flows at a time, of which the life of the flow varies. Some flows are only a few packets, and never leave TCP slow start, and hence never establish an average sending rate. Of the flows that are long lived, they have various RTTs and their congestion windows are not synchronized, which contrasts directly with a single long lived flow with a stable RTT and single congestion window.

27. If your browser has a page in the cache and wants to know if the page is still fresh and can be used, or is too old and should be replaced with fresh content from the server, which HTTP method should it use to find out? (If you are familiar with the If-Modified-Since header field, which we have not discussed in this class, please assume that we are not using If-Modified-Since.)

The HEAD method in HTTP requests a document just like the GET method except that the server will respond to a HEAD request with only the HTTP response header; the response body (which would normally contain the document data) is not included. This saves the delay of transmitting the actual document, e.g., if it is a large file, but allows the browser to check the Last-Modified field in the response header to find out if it's been changed since the time when the cached version was retrieved.

9a. What is the purpose of the Concave region of the CUBIC growth function?

The concave region of CUBIC's growth function rapidly increases the congestion window to the previous value where a congestion event occurred, allowing for a quick recovery and high utilization of available bandwidth following a congestion event.

9c. What is the purpose of the Convex region of the CUBIC growth function?

The convex region of CUBIC's growth function exists to rapidly converge on a new value of WMAX following a change in available bandwidth. When the congestion window exceeds WMAX, and continues to increase throughout the end of the plateau, it likely indicates some competing flows have terminated and more bandwidth is available. This is considered a max probing phase, as the congestion window will grow exponentially in this region until another congestion event occurs and WMAX is reset.

MPTCP: MPTCP Flow Control

The correct solution is to generalize TCP's receive window semantics to MPTCP. For each connection a single receive buffer pool should be shared between all subflows. The receive window then indicates the maxi- mum data sequence number that can be sent rather than the maximum subflow sequence number. As a packet resent on a different subflow always occupies the same data sequence space, no such deadlock can occur.

MPTCP: What are the goals of MPTCP?

The goal is for an unmodified application to start (what it believes to be) a TCP connection with the regular API. When both endpoints support MPTCP and multiple paths are available, MPTCP can set up additional subflows and stripe the connection's data across these subflows, sending most data on the least congested paths. The potential benefits are clear, but there may be costs too. If negotiating MPTCP can cause connections to fail when regular TCP would have succeeded, then deploy- ment is unlikely. The second goal, then, is for MPTCP to work in all scenarios where TCP currently works. If a subflow fails for any reason, the connection must be able to continue as long as another subflow has connectivity. Third, MPTCP must be able to utilize the network at least as well as regular TCP, but without starving TCP. The congestion control scheme described in [23] meets this requirement, but congestion control is not the only factor that can limit throughput. Finally MPTCP must be implementable in operating systems without using excessive memory or processing. As we will see, this requires careful consideration of both fast-path processing and overload scenarios.

Congestion Control Definition

The goal of congestion control is to fill the pipes without overflowing them. - Sink: Filling with water; how should you control the faucet? - fill the bucket as quickly as possible without overflowing it. - Congestion is when different sources compete for resources (sources are unaware of each other and of current state of flow...this shows up as lost packets and long delays and can result in throughput that is less than the bottleneck link) Solution to congestion collapse is congestion control (congestion collapse causes include spurious retransmissions and undelivered packets)

4. What circumstances lead to the incast problem? (In other words, what factors must be present for incast to occur?)

The incast problem occurs when collective communication (i.e., many-to-one or many-to-many patterns) occurs on high fan-in switches. This results in many small packets arrive at the switch at the same time, thus causing some of the packets to be lost. The last necessary factor is a low-latency network, which means the timeout delay will be much more than the round-trip-time of the network. Consequently, large delays occur in which the system is simply waiting for the timeouts to occur. This slows the whole application, since hearing from all the senders in collective communication is usually necessary before the application can proceed. As a real-world example, suppose a web app has to query a back-end database and needs to check with 100 database nodes to do this. It needs to hear back from all 100 nodes before proceeding, or else it risks missing some of the results. (This is the implicit "barrier" that occurs in some data center applications that are not explicitly using barrier synchronization.) Because they are all responding to the same query, all the nodes will reply at roughly the same time. This means a high fan-in switch will have to handle many of these database replies at the same time. Such traffic bursts may cause only a few of these packets to be lost, while the rest are delivered. However, the application still cannot proceed until it receives replies from these few, so it waits. After a significant delay, retransmissions finally occur and may be delivered, allowing the application to proceed.

28c. Consider the HTTP protocol. What will cause a server to send a response message with the status code 200 OK?

The operation in the request message succeeded. What that operation is exactly depends on the request method. For example, if the request method was GET then 200 OK means that the document was retrieved and its content should be in the body of the 200 OK response. (200 OK responses to other methods do not necessarily contain a body, though. This also depends on what the method was.)

9b. What is the purpose of the Plateau region of the CUBIC growth function?

The plateau is also known as the TCP friendly region. In this region of the growth curve, the congestion window is nearly constant as it approaches and potentially exceeds WMAX. This achieves stability, as WMAX represents the point where network utilization is at its highest under steady state conditions.

14. Why are receive buffer sizes required to be larger for MPTCP enabled connections? What controls does MPTCP put in place to maximize memory usage?

The receive buffer allows out of order data to continue flowing in the event a packet is dropped and must be resent. For a standard TCP connection, the required buffer size is determined by the bandwidth delay product of the connection. With multiple subflows across a single connection present in MPTCP, the worst case scenario is that a packet drop occurs early and must be resent across the slowest link (like a 3G mobile connection). This would require other subflows (like high bandwidth WiFi connections) to have larger buffers than would be required if it were the only connection, because it can send data much faster than the slower link that is retransmitting the lost packet.

28a. Consider the HTTP protocol. What will cause a server to send a response message with the status code 404 Not Found?

The requested file does not exist on the server. That is, the file indicated by the path part of the GET method line cannot be found at that path.

28b. Consider the HTTP protocol. What will cause a server to send a response message with the status code 302 Moved Temporarily (also sometimes called 302 Found)?

The requested file is not at this location (i.e., the path part of the GET method line), but the browser should instead use the URL provided in the Location field of the response to retrieve the file. However, the file may be found at this location in the future (unlike a Moved Permanently response), so the URL in the Location field should be used this once, but not necessarily again in the future.

21. If you want to compute the traffic intensity, I=La/R, on a router interface (i.e., the ratio between arrival rate and forwarding rate), would you use Counters, Flow Monitoring, or Packet Monitoring? Explain why.

The sending rate is a known quantity (it's just the maximum rate of that device's interface). The average length of packets and the average arrival rate of the packets can be determined from simple counters. (We do not need to inspect the packet contents, so packet monitoring is unnecessary. Since we are only concerned with all packets on a particular interface and do not care about which flow each packet belongs to, flow monitoring is also unnecessary. However, if you knew that traffic intensity was high and wanted to determine which source is responsible for most of the traffic, flow monitoring would come in handy in that case.)

CUBIC: Where does the good performance of BIC-TCP come from?

The slow increase around Wmax and linear increase during additive increase and max probing

MPTCP: If the client is multi-homed, then it can easily initiate new subflows from any additional IP addresses it owns. However, if only the server is multi-homed, the wide prevalence of NATs makes it unlikely that a new SYN it sends will be received by a client. What's the solution?

The solution is for the MPTCP server to inform the client that the server has an additional address by sending an ADD ADDR option on a segment on one of the existing subflows.

6. 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?

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.

19. Read about the following two Active Queue Management (AQM) techniques: Random Early Detection (RED) and CoDel . Although they vary in specifics, these two algorithms share a common basic approach to solving the buffer bloat problem. Explain what that approach is and why it works.

Their approach is to 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 queuing delay of packets that it forwards and drops packets if the queuing delay is too long. By dropping packets early, senders are made to reduce their sending rates at the first signs of congestion problems, rather than waiting for buffers to fill.

29c. Consider the HTTP protocol. What would the Cookie header field be used for?

This is included in request messages that are sent to a domain that previously gave the browser a cookie. That cookie would have been provided by the Set-Cookie field in a response message, and after that (until the cookie expires) the browser should include the exact same cookie given by Set-Cookie in any request message it sends to the same domain. This allows the server to know that a request is coming from the same client that made another earlier request. For example, when you request to view your shopping cart, the web server may use cookies to know that you are the same person who earlier clicked on an item to add to your cart, so it can show you a cart containing that item.

29a. Consider the HTTP protocol. What would the Last-Modified header field be used for?

This is the date and time that the requested document file was last modified on the server. It can be used to check if a cached copy is fresh (newer than the Last-Modified time) or stale (older than the Last-Modified time, indicating that it's been changed since the cached copy was retrieved).

29b. Consider the HTTP protocol. What would the Host header field be used for?

This is the domain name of the web request (e.g., from the domain part of the URL). One way this may be used is if a single web server (with a single IP address) is hosting websites for more than one domain. The web server can check the Host field to see which domain's pages should be retrieved for each request it gets.

MPTCP: The simplest possible way to implement Multipath TCP would be to take segments coming out of the regular stack and "stripe" them across the available paths somehow1. For this to work well, the sender would need to know which paths perform well and which don't: it would need to measure per path RTTs to quickly and accurately detect losses. To achieve these goals, the sender must remember which segments it sent on each path and use TCP Selective Acknowledgements to learn which segments arrive. Using this information, the sender could drive retransmissions independently on each path and maintain congestion control state. - What is wrong with this simple design?

This simple design has one fatal flaw: on each path, Multipath TCP would appear as a discontinuous TCP bytestream, which will upset many middleboxes (our study shows that a third of paths will break such connec- tions)

MPTCP: Acknowledgements - Solution to reordering of packets

To avoid such scenarios MPTCP must carry an ex- plicit data acknowledgment field, which gives the left edge of the receive window.

TCP FAST OPEN: Problem with TCP today?

Today's TCP standard permits data exchange only after the client and server perform a handshake to establish a con- nection. This introduces one RTT of delay for each connec- tion. For short transfers such as those common today on the web, this additional RTT is a significant portion of the flows' network latency

Token Bucket vs Leaky Bucket

Token Bucket: - permits traffic to be bursty, but bounds it by the rate rho (p) - the bound in a token bucket is as follows: if our bucket size is beta (B) then we know that in any interval T, then the rate is always less than beta (that is, the maximum number of tokens that can be accumulated in the bucket) plus the rate at which tokens accumulate times that time interval (rate < Beta + T*p) - long term rate will always be < rho (p) - no discard or priority policies - One of the limitations of token bucket is the fact that in any traffic interval of length T, the flow can send B+T*p tokens of data; if a network tries to police the flows, by simply measuring the traffic over intervals of length T, then the flow can cheat by sending this amount of data in each interval; policiing traffic being sent by token buckets is actually quite difficult, so token buckets allow for long bursts and if the bursts are for high priority traffic they are difficult to police and may interfere with other high priority traffic - so there's some need to limit how long a token bucket sender can monopolize the network Leaky Bucket: - forces bursty traffic to be smooth - priority policies for flows that exceed the smoothing rate Both are relatively easy to implement but the token bucket is a little bit more flexible since it has some additional parameters that we can use to configure burst size

Congestion Control Approaches

Two Main Approaches: End-to-End and Network-assisted - End-to-End (TCP): no explicit feedback from network to senders about when they should slow down their sending rate; congestion inferred by (typically) packet loss and (but also) increased delay - Network-Assisted: routers provide explicit feedback about the rates that end systems should be sending at - so they might set a single bit indicating congestion or they might tell the sender an explicit rate that they should be sending at

CUBIC: Max Probing

Uses a window growth function exactly symmetric to those used in additive increase and binary search (exponential). During Max probing, the window grows slowly initially to find the new max nearby, and after some time of slow growth, if it does not find the new maximum (i.e. packet losses), then it guesses the new maximum is further away so it switches to a faster increase by switching to additive increase where the window size is incremented by a large fixed increment.

22. Discuss the drawbacks to over-buffering routers. If memory is widely available at low cost, why is it a bad idea to use massive buffers to ensure high link utilization?

Using massive buffers in internet routers increases the size, power consumption, and design complexity of routers. Large buffers are typically implemented in off chip DRAM, where small buffers can be implemented on chip. Additionally, large off chip DRAM is slower to retrieve data than on chip SRAM. This means that retrieving buffered packets takes longer, which means the latency on the link will grow. During periods of congestion with a large amount of buffered packets, latency sensitive applications like live streaming and networked video games will suffer. Further, TCP congestion control algorithms can also suffer under these conditions. Using large amounts of cheap memory may eliminate the need to worry about proper buffer sizing, but it induces hardware efficiency issues and presents problems for low latency applications.

CUBIC: Fast Convergence

When a new flow joins the net- work, existing flows in the network need to give up their bandwidth shares to allow the new flow some room for growth. To increase this release of bandwidth by existing flows, we add the following mechanism called fast convergence. With fast convergence, when a loss event occurs, before a window reduction of the congestion window, the protocol remembers the last value of Wmax before it updates Wmax for the current loss event. Let us call the last value of Wmax to be Wlast max. At a loss event, if the current value of Wmax is less than the last value of it, Wlast max, this indicates that the saturation point experienced by this flow is getting reduced because of the change in available band- width. Then we allow this flow to release more bandwidth by reducing Wmax further. This action effectively lengthens the time for this flow to increase its window because the reduced Wmax forces the flow to have the plateau earlier. This allows more time for the new flow to catch up its window size.

CUBIC: Multiplicative Decrease

When a packet loss occurs, CUBIC reduces its window size by a factor of β. We set β to 0.2. A side effect of setting β to a smaller value than 0.5 is slower convergence. We believe that while a more adaptive setting of β could result in faster convergence, it will make the analysis of the protocol much harder and also affects the stability of the protocol.

10. How does CUBIC's fast convergence mechanism detect a reduction in available bandwidth (i.e. a new flow competing for bandwidth)?

When new flows start competing for bandwidth, other flows must release some bandwidth to maintain fairness. CUBIC employs the fast convergence mechanism to accomplish this. When two successive congestion events indicate a reduction in available bandwidth (i.e. a reduced value of WMAX), the new value of WMAX further reduced (based on the multiplicative decrease factor used for resetting the congestion window) to free up additional bandwidth and reduce the number of congestion events required for all flows to converge on a fair distribution of bandwidth.

CUBIC: Concave Region

When receiving an ACK in congestion avoidance, if the pro- tocol is not in the TCP mode and cwnd is less than Wmax, then the protocol is in the concave region. -- Here the cwnd is being INCREMENTED.

CUBIC: Convex Region

When the window size of CUBIC is larger than Wmax, it passes the plateau of the cubic function after which CU- BIC follows the convex profile of the cubic function. Since cwnd is larger than the previous saturation point Wmax, this indicates that the network conditions might have been perturbed since the last loss event, possibly implying more available bandwidth after some flow departures. Since the Internet is highly asynchronous, fluctuations in available bandwidth always exist. The convex profile ensures that the window increases very slowly at the beginning and gradu- ally increases its growth rate. We also call this phase as the maximum probing phase since CUBIC is searching for a new Wmax. As we do not modify the window increase function only for the convex region, the window growth function for both regions remains unchanged (i.e. again, cwnd is being INCREMENTED - same formula as Concave!)

CUBIC: CUBIC

Window growth function of CUBIC is a cubic function (similar shape to BIC-TCP) - CUBIC uses a cubic function of the elapsed time from the last congestion event - CUBIC uses both the concave and convex profiles of a cubic function for window increase After a window re- duction following a loss event, it registers Wmax to be the window size where the loss event occurred and performs a multiplicative decrease of congestion window by a factor of β where β is a window decrease constant and the regular fast recovery and retransmit of TCP. After it enters into conges- tion avoidance from fast recovery, it starts to increase the window using the concave profile of the cubic function. The cubic function is set to have its plateau at Wmax so the con- cave growth continues until the window size becomes Wmax. After that, the cubic function turns into a convex profile and the convex window growth begins. This style of window ad- justment (concave and then convex) improves protocol and network stability while maintaining high network utiliza- tion [12]. This is because the window size remains almost constant, forming a plateau around Wmax where network utilization is deemed highest and under steady state, most window size samples of CUBIC are close to Wmax, thus pro- moting high network utilization and protocol stability. Note that protocols with convex growth functions tend to have the largest window increment around the saturation point, introducing a large burst of packet losses.

TCP FAST OPEN: A simple solution is to exchange data during TCP's initial handshake - but what is the problem with this?

a straightforward implementation of this idea is vulnerable to denial-of-service (DoS) attacks and may face difficulties with duplicate or stale SYNs

TCP FAST OPEN: What is the performance penalty incurred by a web flow due to its TCP handshake?

between 10% and 30% of the latency to serve the HTTP request

TCP FAST OPEN: TCP initial handshake design

designed to deal with delayed or duplicate SYN packets received by a server and to prevent such packets from creating unnecessary new connections on the server; server applications are notified of new connec- tions only when the first ACK is received from the client.

TCP FAST OPEN: TFO Definition

enables data to be exchanged safely during TCP's initial handshake. At the core of TFO is a security cookie that is used by the server to authenticate a client that is initiating a TFO connection

TCP FAST OPEN: Suppose for the moment that we were to remove this re- striction, and simply enable ordinary TCP-based client ap- plications to send HTTP GET requests in TCP SYN packets and servers to respond with data in their TCP SYN-ACK packets. While this would trivially meet the needs of TCP Fast Open - what is the issue?

it would open the protocol up to a straightfor- ward denial-of-service attack of both the server and arbitrary hosts: an attacker or set of attackers could send HTTP GET requests to a server while spoofing the source address of a victim host, thereby causing the server both to perform po- tentially expensive request processing and to send a poten- tially large response to a victim host

TCP FAST OPEN: What are the assumptions made for the settings in which TFO is deployed?

servers cannot maintain permanent or semi-permanent per-client state since this may require too much server memory, and that servers may be behind load balancers or other such network devices. servers cannot perform any operations to support TFO that are not reasonable to implement on the kernel's critical path (e.g. symmetric cryptography is possible, but asymmetric is not). We assume that clients are willing to install new software to support TFO and that small changes to applications are acceptable. Finally, we assume that it is acceptable to leverage other security mechanisms within a server's domain (if needed) in concert with TFO to provide the required security guarantees.

TCP FAST OPEN: How did they deal with the fact that to manage stale or duplicate SYN packets would add significant complexity to the design?

we decided to accept old SYN packets with data in some rare cases; this decision restricts the use of TFO to applica- tions that are tolerant to duplicate connection / data requests

DYNAMIC ADAP STREAMING: Features supported by solution of 3GPP Adaptive HTTP Streaming (AHS)?

• fast initial startup and seeking, • bandwidth-efficiency, • adaptive bitrate switching, • adaptation to CDN properties, • re-use of HTTP-server and caches, • re-use of existing media playout engines, • support for on-demand, live and time-shift delivery services, • simplicity for broad adoption.

5. Suppose you are working on some live video call software (think Skype or Google Hangouts) and decide to build your application protocol on top of UDP (rather than TCP). Give as many different points as you can (minimum two) to help justify that decision.

● Latency is critical - retransmissions are pointless since they will arrive too late anyway ● Dropped frames aren't a big deal - the next frame will advance the video state before a retransmitted frame could arrive anyway ● Congestion control and flow control could cause unacceptable delays, as video frames get backed up in the sender host's local buffer (what is needed instead is for the application itself to reduce the frame rate that it tries to send)