Designing DCCP: Congestion Control Without Reliability May 29, 2009

(i) the three most important things the paper says

1. The initial observation that congestion control is necessary in connectionless protocols like UDP (and not as its own layer) is an important one.  The authors argue that having congestion control in any other part of the Internet model (in IP or on its own layer) would require input from each program that implements that protocol; a quite unreasonable demand from application programmers.  The authors also made the observation that having the congestion control in the protocol itself is really the best option for receiving information about packet loss that would be appropriate for a connectionless best-effort protocol.
2. Another important observation that the authors make is that although there should be a “safe” set of parameters (where all mechanisms would work at today’s link speeds), there should also be a method in which to negotiate a smaller header size so that traffic that uses smaller packet sizes (or any other such difference from the “standard” type of communication) won’t suffer by using congestion control in its traffic.
3. A third important observation that the authors make is that a customer of this protocol should have his or her choice of congestion control policies and should not be limited to a mandated policy.  Locking down this decision is often a protocol-killer as that particular design choice (that might not be the “right” one all the time) might not work for all applications.

(ii) the most glaring problem with the paper

I feel that the lack of meaningful simulation/verification is a large problem with this paper.  I found that it was hard to believe that this scheme will work entirely without some sort of empirical evidence of it working (also, it would be useful to see how this will affect different types of connectionless traffic, in terms of performance).  The authors provide some minimal simulation, but simulating this over other internet traffic (TCP, etc.) would be necessary in order to verify the usefulness of this protocol. (Let it be known that this paper was very through, and finding holes in it was a bit difficult for me.)

(iii) the future research directions of the work

One future research direction would be to profile applications using this protocol over UDP (mapping the slowdowns that the application will incur–if any at all, the effect on the latency of the connection, how the protocol coexists with other internet protocols, etc.) .  Another great topic to look at would be if it would be in the best interest of the protocol to look at improving its semantics without referring back to TCP for each comparison.  Some of the design decisions made could be better off without relying on a connection-based protocol for holding the “oracle” of how this connection should behave.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

The Datagram Congestion Control Protocol (DCCP) is a transport layer protocol that values speed over correctness, e.g. streaming media, telephony, etc.

DCCP provides a choice of congestion control schemes. This option is exposed at the application level. The choices are either a selective acknowledgment TCP-style scheme using a congestion window with additional control based on the ratio of data packets to acknowledgments, or a scheme where the sender transmits at a certain rate based on periodic feedback from the receiver.

Retransmissions are not always desirable and are easily added above the transport layer. Thus, everything sent over the transport layer (packets and acknowledgments included) has a unique sequence ID number. Since there are no retransmissions, the acknowledgment ID numbers refer to the latest packet received, leaving the specifics of packets not arriving to other modules within DCCP. Furthermore, for some flows, a 6-byte long sequence number in the header may be a significant amount of overhead, especially when sending e.g. an 8-byte data packet; therefore, DCCP includes an alternate set of headers using a 3-byte long sequence number which is concatenated with 3 upper bytes at the receiver.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

(i) Three most important things

1. A new protocol is needed to accommodate increasingly popular applications such as Internet telephony, interactive videoconferencing, streaming media, and interactive games. UDP provides unreliable, connectionless data transport, for applications where timeliness is the primary concern but users are forced to implements congestion control themselves. The paper proposes the Datagram Congestion Control Protocol (DCCP) as a new protocol that does not burden the application developer by providing congestion control.

2. Design goals for a new UDP protocol with congestion control would be minimalism, robustness, and framework for modern congestion control. The protocol should be simple in protocol design, implementation, and ability to leverage for applications and should have a reduction in protocol overhead. The protocol needs to be robust to withstand abuse and the protocol should support the congestion control features of TCP, yet still have the capability to evolve over time.

3. The headers of the new UDP protocol with congestion control must include sequence numbers that measure datagrams and ACK numbers should represent the most recent packet received. Sequence numbers should measure datagrams rather than bytes because unreliable applications generally send and receive datagrams rather than portions of a byte stream. DCCP’s ACKs report the most recent packet received and stores additional info in the ACK Vector, a TCP SACK relative that enables DCCP to report the specific packets received.

(ii) Most glaring problem

The most glaring problem would be that unreliable UDP flows are still a small fraction of the total Internet traffic so the case for DCCP just doesn’t seem convincing currently. For now UDP is good enough until unregulated UDP flows become a larger portion of Internet traffic.

(iii) Future Research Directions

Future research directions for this work would be to test DCCP over the Internet and demonstrate the viability of the new protocol in comparison to UDP and TCP and under what kind of networks loads.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

1. A bare framework in line with the end-to-end argument
DCCP is a congestion control protocol for unreliable connection oriented network. The protocol provides only the bare necessities required for congestion control. All other features have been left for the higher layers to implement. This makes it protocol independent allowing it to support a large number of existing and future protocols. It also makes it application independent which is an important feature considering the type of traffic it was directed at. It is likely that applications for multimedia, VOIP, video streaming etc have advanced mechanisms to implement fine-grained control over the arriving data. Not providing these features in DCCP provides these application the flexibility to implement these feature in a manner most suitable for their needs. This also allows each connection to negotiate its own features depending on the application at hand.

2. Specialized sequencing scheme
DCCP differs from TCP in method it uses for sequence numbering. Every packet in DCCP, regardless of the type of packet it is, gets its own sequence number. Moreover, each packet in DCCP gets a sequence number as compared to a byte-wise sequencing scheme in TCP. Hence the entire exchange maintains a single sequence of numbers for all its packets. This would also imply that each connection would require a larger sequence space.

3. Congestion control specialized for traffic requiring timely delivery over minimize-packet-drop delivery.
DCCP makes several enhancements/changes to TCP congestion control. It provides acknowledgement of acknowledgments. Its sequence number reports the latest packet received as compared to the earliest packet not received since applications here are more concerned with timely delivery as compared to confirmed, every packet delivery. DCCCP also leverages the unidirectional nature of its traffic by maintaining acknowledgment history and order in only a single direction.

Drawbacks
Some of the features provided by them to support real-time traffic adds some over-head over the congestion-control provided for by TCP. A sequence number for every packet implies a larger space for sequence number (48 bits in DCCP as compared to 32 bits used by TCP). The paper does talk about selectively using the upper 24 of the 48 bits. The protocol also requires acknowledgment of acknowledgment packets which would add to the network traffic. The Ack Vector, if used, would lead to even more overhead
In trying to exploit the unidirectional nature of their traffic, a direction goes into a “quiescent” state if there is no traffic in the direction for more than 0.2 second. This could lead to obvious issues if the application involved generates data in bursts.

Future Work
DCCP follows a policy of bare framework. This, while having its advantages, leaves out several hard to implement features to the upper layers. It might be possible to selectively provide these features in DCCP. The paper does mention support for feature negotiation. The more complex features (such as support for multicast) could be added on during feature negotiation. However, there is no end to the additional features that can be provided.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

This paper describes the DCCP protocol, which is designed as an alternative to UDP which will provide the same timeliness prioritization over reliability while adding the congestion control that UDP lacks.

The main points of this paper are as follows:

1. Congestion control should be decoupled from the protocol itself. Different applications have different communications requirements. While some prefer discarding corrupted information, others prefer receiving it. In other cases, some datagrams are more important than others (I-frames vs. B/P-frames in MPEG video), so if some have to be dropped due to buffers, it can be helpful to be able to handle some more carefully than others. DCCP provides flexibility in congestion control by acting as a congestion control framework which different congestion algorithms can be “plugged into.” This has the added benefit of allowing different congestion control for halves of a bidirectional communication, since many of the applications of UDP (and subsequently DCCP) tend to be mostly unidirectional.
2. The main requirement for congestion control is sequence numbers. These allow the protocol to detect loss and respond accordingly. Even though DCCP does not require retransmission, it also does not preclude it, if the application determines that there is sufficient time to make it worthwhile. However, as opposed to TCP, which numbers bytes in a byte stream, UDP and DCCP provide an abstraction in terms of datagrams, not bytes. Therefore, the sequence numbers in DCCP are specified in terms of packets. They also took the opportunity to specify a variable number of bits in the header for sequence numbers. Whereas TCP only specifies 32 bits which are used to specify bytes in the byte stream (which is becoming more and more of a problem with gigabit and higher bandwidths), DCCP can use up to 48 bits to specify a number of packets. This provides resilience against both malicious users (trying to run reset attacks is much harder than it is against TCP) and mistimed packet arrivals. However, they also recognized that not all applications need the overhead of 48-bit sequence numbers, so they created an option to use 24-bit numbers instead. This opens the attack window for reset attacks, but reduces the overhead when it is unlikely that mistimed packets will overlap a window in 24-bit space. This provides the application developer a choice of resilience or overhead.
3. Connection management should provide flexibility in usage models. In order to provide congestion management, DCCP is required to use a connection-based paradigm more similar to TCP. However, since connections over DCCP can often be mostly unidirectional, it is helpful to be able to configure the half-connections separately. DCCP provides this through feature negotiation, wherein both sides of a connection can agree on the policies to be implemented at one or both endpoints. In addition to adding per-direction policies, DCCP provides mobility support by allowing multiple connections to tie into a single session. This is made much easier since DCCP is an unreliable protocol and therefore requires much less synchronization upon the change in an endpoint’s location.

The main weakness in this protocol is that it is not backwards compatible in any useful sense with either TCP or UDP. While it is careful to be TCP-friendly (and indeed, compared to UDP, almost anything is friendlier to TCP), it requires fresh implementations on end-nodes, NATs, etc., which is a distinct barrier to deployment.

It would be interesting to see future research on this protocol using an overlay on a UDP system. Since NATs already support UDP, it might be an effective way to test the congestion control policies without requiring multiple nodes on the path to understand a new protocol. However, it remains to be seen whether it would be as effective as an overlay.

Designing DCCP: Congestion Control Without Reliability May 29, 2009

Application writers of VOIP, interactive games, and streaming media programs use UDP over TCP since these applications cannot tolerate arbitrary delay and do not require reliability. Using UDP will burden application designers with the need to implement their own congestion control.

The authors present DCCP as a protocol designed for this set of applications with the goals of minimalism, robustness, modular framework for congestion control, self-sufficiency, and support timing-reliability tradeoffs. The authors argue that having each application designer write their own congestion control mechanism is too complex and can be dangerous.

DCCP is connection oriented, support explicit synchronization, has a 48-bit sequence number for security, mobility and multihoming support. Data and ACKs occupy the same sequence space so that ACKs can be acknowledged. The sequence number is incremented at a packet granularity rather than byte granularity. Cumulative ACKs doesn’t make sense in a unreliable protocol so ACK vectors were introduced similar to TCP selective acknowledgements. With this, DCCP can report specific packets received if there were lost packets. ACK vectors can grow to unbounded size so ACKs of ACK vectors will allow the receiver to clear it’s state. DCCP partial checksums can differentiate non congestion related corruption for congestion control over lossy links and also allow for corrupted packets to be accepted.

DCCP implements modular congestion control by negotiating a CCID. CCID = 2 allows for a TCP like congestion control with a congestion window and uses Ack Vectors for feedback. Unlike TCP, ACK  Ratio controls the ratio of data packets per acknowledgement. This provides a reverse-path congestion control and the ratio is capped to provide sufficient timely ACKs. CCID =3 provides TFRC congestion control where instead of a congestion window, the sender uses sending rate and depends on receiver feedback and does not require ACKs for ACK vectors.

The main problem that still needs to be resolved is related to whether routers drop packets or bytes of a packet. This affects the congestion control and fairness at bottleneck routers. The paper didn’t conduct any benchmark for performance differences between applications running UDP w/ own congestion control and DCCP so it’s not clear whether DCCP is a clear winner.

Further research can be done to compare congestion control layer on top of UDP, DCCP, and proprietary protocols. The benefit of a modular congestion control mechanism can open research into new innovation in this area. Further research to resolve middlebox issues can be done to ensure compatibility.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

Three Important Things:

• CUBIC represents a departure from the traditional TCP notion of ACK clocking for window growth. Instead the growth function is based on real time, effectively decoupling it from RTT and thus making it more deployable on high latency links. On packet loss, the windows size is reduced by a multiplicative factori, and the subsequent growth is a cubic function of time and the old window size. This scheme results in speedy rampup of the throughput and ensures fairness among competing flows. All flows will converge to the same window size because of the proportional decrease
• The paper makes the argument that fair coexistence with TCP is crucial for the deployment of any new high speed protocol. Fairness is defined as behaving like TCP when there is high loss, to ensure that legacy flows are not dominated. CUBIC achieves this by entering TCP compatibilty mode and simulating the multiplicative adjustment of TCP. It essentially reverts to TCP behavior during periods of loss and large relative cmputed window size
• Simulation experiments comparing 5 high-speed TCP variants showed that CUBIC achieved better TCP-friendliness, link utilization, balancing, and stability than any other protocol. This results held across variations of bottleneck bandwidth, RTT, background traffic, and flow competition.

Glaring Problem:

The new protocol is shown to perform well relative to others, and its success relies on several fundamental formulas and appropriately chosen constants. Most of these are presented “as is” in the paper, with little or no formal analysis and justification. There was also no discussion of the methods used to arrive at the material presented, beyond a few vague references to control theory.

Future Work:

The ultimate goal of any TCP protocol is to converge as quickly as possible to the optimal window size while being responsive to changes congestions changes. Graphically speaking this behavior will maximize the area under the throughput curve. Future work should analyze how much better it is possible to do with TCP, meaning that no help is provided from the network. If protocols like CUBIC are getting to close to the point of “as good as can be hoped for” then this should result in a shift of attention to other protocol research possible internet philisophy changes.

CUBIC: A new TCP-Friendly High-Speed TCP Variant May 25, 2009

The paper “CUBIC: A new TCP-Friendly High-Speed TCP Variant” by Injong Rhee and Lisong Xu presents yet another TCP variant building on their previous work on BIC. The goal of the paper is to improve congestion control in TCP by fixing the slow growth of the congestion window in large bandwith-delay product links.

Their first contribution is to base the part of the protocol variant that behaves like TCP (the so-called TCP region) not on window size but on wall clock time. This helps in accustoming the protocol variant to networks with RTT values differing over more than one order of magnitude. The proposed window growth function is a cubic function, which is essentially flat around the origin (which is defined to be the last observed maximum window size). Therefore, the authors have a large area of stability around the maximum window size to reduce oscillation and still have a high rate of change when the network conditions have changed significantly.

The second contribution is an emulation mode for TCP, which emulates the Additive Increase Multiplicative Decrease protocol used in current versions of TCP. This emulation is run in parallel to the window growth function provided by CUBIC, to ensure that CUBIC doesn’t give an unfair share to TCP on small RTT networks.

The last contribution is an comparative study of TCP variants, especially their behavior on networks with different RTTs in respect to the ongoing (old) TCP connections. The authors are able to show that some proposed variants have an heavy impact on TCP connections based on the current implementation, especially for slow link speeds. Finally, the authors look into the stability of the throughput of different variants.

This paper ignores deployment for the new TCP variant and fails to report the impact of the improved TCP friendliness on its own flows.

Future research in this area could involve studying stability and throughput on networks with flows using different TCP variants. This could result in interesting scenarios for the deployment, where compatibility issues might hinder the adoption of certain TCP variants.

CUBIC: A New TCP-Friendly High-Speed TCP Variant May 25, 2009

(i) The three most important things the paper says:

1) One of the most important point the paper makes is their focus on “fairness” which remains one of the challenges of new TCP variants.  The first is their consideration of TCP-friendliness to the safety of the protocol.  I believe that Rhee and Xu mention this because, since TCP is the dominating protocol and the adoption of any new protocol hinges on its ability to work well with existing traffic.  Another aspect of fairness that they consider is fairness to other high speed protocols with different RTTs.  This second point is important to maintain stability in the network aswell as not starve another flow (possibly one that is running the same protocol).

2) The choice to use a window groth function that Is definined in real-time independent of RTT.  This is because TCP scabilbitly is more often times defined by real time (e.g. this network takes x amount of times longer than y network…).  Secondly the choice to make the protocol independent of RTT was important to fairness, since growth function will grow for different flows at the same rate.

3) Observing that slow window growth around Wmax enhances the stability and increases the use of the network while fast growth away from Wmax ensure the scalability of the protocol.  These were critical points that they needed to exploit to develop a function to capture these properties.  Also, it was these 2 key observations that allow them to extract the good point from BIC and enhance it to perform even better than it as shown in their results section.

(ii) The most glaring problem with the paper:

The biggest problem with the paper is they mention a lot of observations and comparisons with TCP and TCP variants.  However another dimension to consider would be how a small amount of traffic from a secondary protocol such as UDP may change the characteristics dramatically.  Consider that a randomized bursty UDP traffic may cause the use of “the last lost packet” to have an undesired effect to their cubic function.  For completeness, consideration of the friendliness with at least another two protocol would make this paper much stronger.

(iii) The future research directions of the work:

The future research of the work would be to assume that this has the potential to overtake traditional TCP traffic.  Does it have the versatility of TCP?  For instance could it be used in low speed, high lost, unstable networks?  Or if we must always live in a system managaging two types of TCP variants, what are good algorithms that can be used to determine which TCP variant to use (CUBIC vs traditional).

Internet Congestion Control for Future High Bandwidth-Delay Product Environments May 25, 2009

This paper discusses XCP, a proposed successor to TCP which provides much better behavior than TCP by increasing bandwidth utilization, reducing bottleneck queueing, and drastically reducing packet loss, especially over networks with high bandwidth-delay products.

The main points of the paper were as follows:

1. The most significant insight provided by this paper is that TCP tries to do too much at once. By separating efficiency and fairness, XCP is able to better serve both goals. This is primarily because optimizing efficiency and fairness require two different algorithms. Optimizing efficiency is best served by a multiplicative-increase multiplicative-decrease (MIMD) system, which allows XCP to quickly converge on maximum utilization of the available bandwidth by all flows. Optimizing fairness, on the other hand, it best served by an additive-increase multiplicative-decrease (AIMD) system, which converges to a fair solution. Since TCP only uses AIMD for all efficiency and fairness requirements, it is sluggish when trying to take advantage of all of the available bandwidth.
2. In addition to allowing different algorithms for efficiency and fairness, splitting the goals also allows modifying one system without affecting the other. This is useful in multiple contexts. For example, it is possible to modify the fairness controller to take advantage of pricing information to allow usage-based billing and bandwidth allocation. It is also possible to use a different fairness controller, like one based on a binomial law, in order to try to optimize fairness in different situations. This simplifies the design and testing of different algorithms because the amount of code that has to be modified is reduced and there is no risk of damaging efficiency while modifying fairness.
3. While XCP is a very effective system, it is all for naught if it cannot be deployed efficiently. The authors of the paper provide two different ways that XCP can be incrementally deployed. The first is as a cloud within a TCP network. This would allow an ISP to deploy XCP within their administrative domain while the rest of the Internet remained primarily TCP-based. This would benefit ISPs because of the fairness options allowed under XCP. Some ISPs are already trying to implement usage-based billing/allocation, and XCP would facilitate that through its fairness controller design. The other option is to modify XCP routers to handle TCP traffic as well, balancing TCP and XCP traffic using a weighted fair-queuing approach. This is somewhat similar to the dual-stack IP situation, where more and more routers are having to handle two similar, but distinct, classes of traffic fairly.

The biggest weakness of this paper is that many of the parameters seem to be based on theoretical results. Normally this is the thing lacking from papers, which tend to use “stochastic optimization” to pick algorithmic parameters. However, in the case of this paper, it might be nice to see a chart where they try their optimal parameters against others to verify that they are indeed optimal.

Future research on XCP should look at various fairness algorithms in order to determine which are best for deployment on the Internet at large, with its large number of traffic classes and diversity of users. Research could also examine all of the various control parameters to verify that they still apply on the Internet as well.

Congestion Control for Future High Bandwidth-Delay Product Environments May 25, 2009

1. Explicit rate control feedback to sender.

XCP explicitly lets the sender know how it needs to vary its rate to optimize utilization while avoiding congestion. This way it does not depend on packet drop as an indication of congestion hence avoiding packet drops. It uses the difference between available and utilized bandwidth and current queue length to compute rate change information.

2. Separate fairness and efficiency control.

It has separate mechanisms to handle fairness control and efficiency control. This gives the user the flexibility to implement different control laws for the two. It also means the user has flexibility to implement different fairness laws for different users depending on commercial incentives. It also means efficiency control can be optimized to maximize bandwidth utilization without being held down by fairness laws. In the implementation mentioned in the paper, MIMD is used for efficiency control which works a lot better than AIMD for short bursts of traffic.

3. Bandwidth shuffling

When the efficiency (a combination of queue length and bandwidth utilization) is near optimum, bandwidth shuffling ensures that throughput of individual flows  continue to converge towards their ideal fair-share values while aggregate throughput at the router remains constant. This ensures efficient decoupling of efficiency and fairness control.

Drawback

The XCP implementation comes at added cost. The routers piggyback congestion control information on packets returning to the sender. This adds to packet size and subsequently the amount of control data flowing in the network.

Future Work

XCP could be extended to distinguish between traffic requiring guaranteed delivery and traffic requiring bandwidth guarantees but can tolerate packet loss (eg. audio/video traffic). The control policies could be modified to handle the two types of traffic differently while maintaining optimized utilization and fair division of resources.

Congestion Control for High Bandwidth-Delay Product Networks May 19, 2009

This paper introduces a new congestion control mechanism eXplicit Control Protocol (XCP) that overcomes the unfairness, efficiency issues, instability in TCP over networks with high bandwidth-delay products.

1. XCP puts control state in packets. Every packet sent has a congestion header with the sender’s cwnd and rtt estimate. The router monitor the queue output links and modifies a feedback field in the congestion header to let the sender know to slow down.

2. XCP routers have a new AQM scheme which decouples the controller to an efficiency controller (MIMD) and a fairness controller (AIMD) to provide feedback. Feedback calculation is done every RTT. Senders can reach the desired rate after one RTT.

3. The efficiency controller uses an aggregate view of the traffic to maximize link utilization. The fairness controller apportion the feedback to individual packets to achieve fairness

The paper has no significant problems and is well written. The most glaring problem is that deployment issues are barely discussed.

Further research can go into how to resolve deployment issues since XCP will require a redesign of routers, sender, and receiver. Security issues can hamper deployment as well so research can look into how to mitigate people from maliciously using the feedback headers for their own benefit or to take down a network.

Internet Congestion Control for Future High Bandwidth-Delay Product Environments May 19, 2009

The XCP scheme uses explicit feedback to manage the congestion of a network. It does so using a header containing, among other things, a feedback value first initialized by the sending end-host, and modified by routers along the way according to the output of an “efficiency controller” and a “fairness controller” on each.

The idea of having these two controllers is the separation of congestion and fairness. The efficiency controller decides that the total traffic should change by a certain amount. The fairness controller then takes this amount and distributes the change among individual packets by changing the congestion header.

Internet Congestion Control for Future High Bandwidth-Delay Product Environments May 19, 2009

Three Important Things:

• The motivation for this paper is the fact that TCP’s performance degrades significantly when RTT is high and there is a lot of bandwidth available. This is because additive increase is limited to a packet per RTT. The fundamental observation is that a flow controller must be able to react as quickly as the network is changing, which is not the case in high RTT environments. The “smart router” approach is adopted to combat this problem, where routers along the path annotate packet headers with congestion feedback, allowing the senders to adjust the window size appropriately. Once at the destination, the packet will retain congestion information from the network bottleneck. This approach is shown by simulation to yield very low packet loss, low queuing usage, and significantly higher link utilization
• In XCP, the control mechanism is now pushed into the network and separated into two parts. The efficiency controller only deals with congestion issues, and its job is to maximize utilization while minimizing packet loss. It does this with scaling factor adjustments based on the measured spare bandwidth. This is a strong departure from TCP, which needs to purposely cause packet loss since it is the only form of feedback that can be received from the network. Thus XCP offers a more fine grain view of congestion. The fairness controller seeks to apportion bandwidth fairly across all flows, and it does this by scaling back overshooting flows and gradually ramping up needy flows. This separation provides a framework for implementing different usage policies and allocation schemes as desired.
• The authors claim that XCP can be deployed alongside TCP. This is a critical feature to examine given the difficulty of getting new protocols adopted. The first approach to gradual deployment could be a cloud strategy where small parts of the internet ran XCP and had translation entities at the cloud edges. This has been tried and tested in the case of IPv6 for example. The other idea that the authors propose is to have new routers support both protocols and have weighted fair queues for each, as well as respond to queries about their protocol support. This way two XCP-capable hosts can determine if they have a path between them with XCP-enabled routers.

Glaring Problem:

After completing the reading, some of the paper’s discussion did not feel fully developed. For example, the section on security lists an overly simplistic approach to policing misbehaving sources with no discussion of possible spoofing. The paper also does not list any information on continuing research in the section labeled “future work.”

Future Work:

XCP represents a complete departure from the end-to-end principle. Once this is violated and routers become intelligent entities from a protocol perspective there are many more potential benefits that can be reaped. These might include security improvements, fine-grain usage charging policies, etc. All these avenues can be investigated along with the associated cost for the additional router computation.

Internet Congestion Control for Future High Bandwidth-Delay Product Environments May 19, 2009

(i) the three most important things the paper says

The most important idea showed that it is beneficial to separate utilization and fairness control from one another.  The authors demonstrate that using these as separate analyses allows total link utilization to be given a priority over complete fairness control (so that the link doesn’t quickly become overly congested), but also to allow finer tuning in who is using that upper bound of bandwidth.  Another important idea that the authors demonstrate is that router involvement in a protocol can greatly help convergence of a certain set of connections to their maximum link speed.  Without router involvement, the end hosts can only guess what the link saturation is, taking a risk that may cause severe congestion in the process.  Lastly, the authors showed that, even with a long latency connection, XCP can be aggressive in its decisions without highly congesting the links throughout.  It’s able to do this because each router will give very accurate feedback instead of the connection guessing based upon its observation of the network usage.

(ii) the most glaring problem with the paper

I feel that the biggest problem with this paper is that it requires great modification to the internal routers of a connection, and without all of those routers being modified the scheme would be useless.  This requires an ISP to change all of their routers in order of the scheme to be useful (and this would only be for inter-ISP connections).  It seems as if the entire internet would have to be swapped out in order for this scheme to be effective, even if everyone didn’t change protocols right away.  This seems infeasible with the current state of internet politics.  I also feel that adding this complexity to the router level would hinder a router from operating at the fast speeds necessary to handle large amounts of traffic.

(iii) the future research directions of the work

I feel that this scheme is great, but needs to work on a way to tolerate the above listed shortcoming.  I feel that if the authors were able to come up with a way to operate in the meantime (without an entire path having XCP routers), this scheme would be much more viable.

TCP Vegas: End to End Congestion Avoidance on a Global Internet May 15, 2009

(i) Three most important things

1. TCP Reno uses coarse-grain timeouts in addition to the Fast Retransmit and Fast Recovery mechanisms to detect and transmit lost segments but eliminating the dependency on coarse-grain timeouts would result in a 19% increase in throughput. TCP Vegas proposes a new retransmission mechanism that treats the receipt of certain ACKs as a hint to check if a timeout should occur to reduce the time to detect lost packets.

2.  TCP Reno’s congestion detection and control mechanism uses the loss of segments as a signal that there is congestion in the network. TCP Vegas proposes that it looks at the changes in the sending rate to detect congestion. TCP Vegas compares the measure throughput rate with an expected throughput rate to determine the rate at which to send packets.

3. TCP Reno sets the threshold window for slow-start to one half of the congestion window. The slow-start period ends when the exponentially increasing congestion window reaches the threshold window and then increases linearly from then on but if the initial threshold window value is too small then throughput suffers or if value is too larger then packets will be lost. TCP Vegas allow exponential grown only every other RTT to able to detect and avoid congestion during slow-start and when the actual rate falls below the expected rate by the equivalent of one router buffer then Vegas changes from slow-start mode to linear increase/decrease mode.

(ii) Most glaring problem

The most glaring problem would be that when TCP Vegas is intermixed with other versions of TCP like Reno then the performance of TCP Vegas degrades because TCP Vegas reduces the sending rate before TCP Reno since Vegas detects congestion earlier and thus gives more bandwidth to the TCP Reno connections.

(iii) Future Research Directions

Future research directions for this work would be to study how the network congestion avoidance algorithm affects fairness when TCP Vegas connections need to compete with more aggressive TCP implementations like TCP Reno.