RFC 6077
Open Research Issues in Internet Congestion Control
Pages: 51
Informational
Informational
Part 3 of 3 – Pages 33 to 51
3.8. Other Challenges
This section provides additional challenges and open research issues that are not (at this point in time) deemed so significant, or they are of a different nature compared to the main challenges depicted so far.3.8.1. RTT Estimation
Several congestion control schemes have to precisely know the round- trip time (RTT) of a path. The RTT is a measure of the current delay on a network. It is defined as the delay between the sending of a packet and the reception of a corresponding response, if echoed back immediately by the receiver upon receipt of the packet. This corresponds to the sum of the one-way delay of the packet and the (potentially different) one-way delay of the response. Furthermore, any RTT measurement also includes some additional delay due to the packet processing in both end-systems. There are various techniques to measure the RTT: active measurements inject special probe packets into the network and then measure the response time, using, e.g., ICMP. In contrast, passive measurements determine the RTT from ongoing communication processes, without sending additional packets. The connection endpoints of transport protocols such as TCP, the Stream Control Transmission Protocol (SCTP), and DCCP, as well as several application protocols, keep track of the RTT in order to dynamically adjust protocol parameters such as the retransmission timeout (RTO) or the rate-control equation. They can implicitly measure the RTT on the sender side by observing the time difference between the sending of data and the arrival of the corresponding acknowledgments. For TCP, this is the default RTT measurement procedure; it is used in combination with Karn's algorithm, which prohibits RTT measurements from retransmitted segments [RFC2988]. Traditionally, TCP implementations take one RTT measurement at a time (i.e., about once per RTT). As an alternative, the TCP timestamp option [RFC1323] allows more frequent explicit measurements, since a sender can safely obtain an RTT sample from every received acknowledgment. In principle, similar measurement mechanisms are used by protocols other than TCP. Sometimes it would be beneficial to know the RTT not only at the sender, but also at the receiver, e.g., to find the one-way variation in delay due to one-way congestion. A passive receiver can deduce some information about the RTT by analyzing the sequence numbers of received segments. But this method is error-prone and only works if the sender permanently sends data. Other network entities on the
path can apply similar heuristics in order to approximate the RTT of a connection, but this mechanism is protocol-specific and requires per-connection state. In the current Internet, there is no simple and safe solution to determine the RTT of a connection in network entities other than the sender. The more fundamental question is to determine whether it is necessary or not for network elements to measure or know the RTT. As outlined earlier in this document, the round-trip time is typically not a constant value. For a given path, there is a theoretical minimum value, which is given by the minimum transmission, processing, and propagation delay on that path. However, additional variable delays might be caused by congestion, cross-traffic, shared-media access control schemes, recovery procedures, or other sub-IP layer mechanisms. Furthermore, a change of the path (e.g., route flapping, hand-over in mobile networks) can result in completely different delay characteristics. Due to this variability, one single measured RTT value is hardly sufficient to characterize a path. This is why many protocols use RTT estimators that derive an averaged value and keep track of a certain history of previous samples. For instance, TCP endpoints derive a smoothed round-trip time (SRTT) from an exponential weighted moving average [RFC2988]. Such a low-pass filter ensures that measurement noise and single outliers do not significantly affect the estimated RTT. Still, a fundamental drawback of low-pass filters is that the averaged value reacts more slowly to sudden changes in the measured RTT. There are various solutions to overcome this effect: For instance, the standard TCP retransmission timeout calculation considers not only the SRTT, but also a measure for the variability of the RTT measurements [RFC2988]. Since this algorithm is not well suited for frequent RTT measurements with timestamps, certain implementations modify the weight factors (e.g., [Sarola02]). There are also proposals for more sophisticated estimators, such as Kalman filters or estimators that utilize mainly peak values. However, open questions related to RTT estimation in the Internet remain: - Optimal measurement frequency: Currently, there is no theory or common understanding of the right time scale of RTT measurement. In particular, the necessity for rather frequent measurements (e.g., per packet) is not well understood. There is some empirical evidence that such frequent sampling may not have a significant benefit [Allman99].
- Filter design: A closely related question is how to design good
filters for the measured samples. The existing algorithms are
known to be robust, but they are far from being perfect. The
fundamental problem is that there is no single set of RTT values
that could characterize the Internet as a whole, i.e., it is hard
to define a design target.
- Default values: RTT estimators can fail in certain scenarios,
e.g., when any feedback is missing. In this case, default values
have to be used. Today, most default values are set to
conservative values that may not be optimal for most Internet
communication. Still, the impact of more aggressive settings is
not well understood.
- Clock granularities: RTT estimation depends on the clock
granularities of the protocol stacks. Even though there is a
trend toward higher-precision timers, limited granularity
(particularly on low-cost devices) may still prevent highly
accurate RTT estimations.
3.8.2. Malfunctioning Devices
There is a long history of malfunctioning devices harming the
deployment of new and potentially beneficial functionality in the
Internet. Sometimes, such devices drop packets or even crash
completely when a certain mechanism is used, causing users to opt for
reliability instead of performance and disable the mechanism, or
operating-system vendors to disable it by default. One well-known
example is ECN, whose deployment was long hindered by malfunctioning
firewalls and is still hindered by malfunctioning home-hubs, but
there are many other examples (e.g., the Window Scaling option of
TCP) [Thaler07].
As new congestion control mechanisms are developed with the intention
of eventually seeing them deployed in the Internet, it would be
useful to collect information about failures caused by devices of
this sort, analyze the reasons for these failures, and determine
whether there are ways for such devices to do what they intend to do
without causing unintended failures. Recommendations for vendors of
these devices could be derived from such an analysis. It would also
be useful to see whether there are ways for failures caused by such
devices to become more visible to endpoints, or to the maintainers of
such devices.
A possible way to reduce such problems in the future would be
guidelines for standards authors to ensure that "forward
compatibility" is considered in all IETF work. That is, the default
behavior of a device should be precisely defined for all possible
values and combinations of protocol fields, and not just the minimum necessary for the protocol being defined. Then, when previously unused or reserved fields start to be used by newer devices to comply with a new standard, older devices encountering unusual fields should at least behave predictably.3.8.3. Dependence on RTT
AIMD window algorithms that have the goal of packet conservation end up converging on a rate that is inversely proportional to RTT. However, control theoretic approaches to stability have shown that only the increase in rate (acceleration), and not the target rate, needs to be inversely proportional to RTT [Jin04]. It is possible to have more aggressive behaviors for some demanding applications as long as they are part of a mix with less aggressive transports [Key04]. This beneficial effect of transport type mixing is probably how the Internet currently manages to remain stable even in the presence of TCP slow-start, which is more aggressive than the theory allows for stability. Research giving deeper insight into these aspects would be very useful.3.8.4. Congestion Control in Multi-Layered Networks
A network of IP nodes is just as vulnerable to congestion in the lower layers between IP-capable nodes as it is to congestion on the IP-capable nodes themselves. If network elements take a greater part in congestion control (ECN, XCP, RCP, etc. -- see Section 3.1), these techniques will either need to be deployed at lower layers as well, or they will need to interwork with lower-layer mechanisms. [RFC5129] shows how to propagate ECN from lower layers upwards for the specific case of MPLS, but to the authors' knowledge the layering problem has not been addressed for explicit rate protocol proposals such as XCP and RCP. Some issues are straightforward matters of interoperability (e.g., how exactly to copy fields up the layers) while others are less obvious (e.g., re-framing issues: if RCP were deployed in a lower layer, how might multiple small RCP frames, all with different rates in their headers, be assembled into a larger IP layer datagram?). Multi-layer considerations also confound many mechanisms that aim to discover whether every node on the path supports a new congestion control protocol. For instance, some proposals maintain a secondary Time to Live (TTL) field parallel to that in the IP header. Any nodes that support the new behavior update both TTL fields, whereas legacy IP nodes will only update the IP TTL field. This allows the endpoints to check whether all IP nodes on the path support the new
behavior, in which case both TTLs will be equal at the receiver. But mechanisms like these overlook nodes at lower layers that might not support the new behavior. A further related issue is congestion control across overlay networks of relays [Hilt08] [Noel07] [Shen08]. Section 3.5.3 deals with inelastic multi-domain pseudowires (PWs), where the identity of the pseudowire itself implies the characteristics of the traffic crossing the multi-domain PSN (independently of the actual characteristics of the traffic carried in the PW). A more complex situation arises when inelastic traffic is carried as part of a pseudowire (e.g., inelastic traffic over Ethernet PW over PSN) whose edges do not have the means to characterize the properties of the traffic encapsulated in the Ethernet frames. In this case, the problem explained in Section 3.5.3 is not limited to multi-domain pseudowires but more generally arises from a "pseudowire carrying inelastic traffic" (whether over a single- or multi-domain PSN). The problem becomes even more intricate when the Ethernet PW carries both inelastic and elastic traffic. Addressing this issue further supports our observation that a general framework to efficiently deal with congestion control problems in multi-layer networks without harming evolvability is absolutely necessary.3.8.5. Multipath End-to-End Congestion Control and Traffic Engineering
Recent work has shown that multipath endpoint congestion control [Kelly05] offers considerable benefits in terms of resilience and resource usage efficiency. The IETF has since initiated a work item on multipath TCP [MPTCP]. By pooling the resources on all paths, even nodes not using multiple paths benefit from those that are. There is considerable further research to do in this area, particularly to understand interactions with network-operator- controlled route provisioning and traffic engineering, and indeed whether multipath congestion control can perform better traffic engineering than the network itself, given the right incentives [Arkko09].3.8.6. ALGs and Middleboxes
An increasing number of application layer gateways (ALGs), middleboxes, and proxies (see Section 3.6 of [RFC2775]) are deployed at domain boundaries to verify conformance but also filter traffic
and control flows. One motivation is to prevent information beyond
routing data leaking between autonomous systems. These systems split
up end-to-end TCP connections and disrupt end-to-end congestion
control. Furthermore, transport over encrypted tunnels may not allow
other network entities to participate in congestion control.
Basically, such systems disrupt the primal and dual congestion
control components. In particular, end-to-end congestion control may
be replaced by flow-control backpressure mechanisms on the split
connections. A large variety of ALGs and middleboxes use such
mechanisms to improve the performance of applications (Performance
Enhancing Proxies, Application Accelerators, etc.). However, the
implications of such mechanisms, which are often proprietary and not
documented, have not been studied systematically so far.
There are two levels of interference:
- The "transparent" case, i.e., the endpoint address from the sender
perspective is still visible to the receiver (the destination IP
address). Relay systems that intercept payloads but do not relay
congestion control information provide an example. Such
middleboxes can prevent the operation of end-to-end congestion
control.
- The "non-transparent" case, which causes fewer problems for
congestion control. Although these devices interfere with end-to-
end network transparency, they correctly terminate network,
transport, and application layer protocols on both sides, which
individually can be congestion controlled.
4. Security Considerations
Misbehavior may be driven by pure malice, or malice may in turn be
driven by wider selfish interests, e.g., using distributed denial-of-
service (DDoS) attacks to gain rewards by extortion [RFC4948]. DDoS
attacks are possible both because of vulnerabilities in operating
systems and because the Internet delivers packets without requiring
congestion control.
To date, compliance with congestion control rules and being fair
require endpoints to cooperate. The possibility of uncooperative
behavior can be regarded as a security issue; its implications are
discussed throughout these documents in a scattered fashion.
Currently the focus of the research agenda against denial of service
is about identifying attack-packets that attack machines and the
networks hosting them, with a particular focus on mitigating source
address spoofing. But if mechanisms to enforce congestion control
fairness were robust to both selfishness and malice [Bri06], they would also naturally mitigate denial of service against the network, which can be considered (from the perspective of a well-behaved Internet user) as a congestion control enforcement problem. Even some denial-of-service attacks on hosts (rather than the network) could be considered as a congestion control enforcement issue at the higher layer. But clearly there are also denial-of-service attacks that would not be solved by enforcing congestion control. Sections 3.5 and 3.7 on multi-domain issues and misbehaving senders and receivers also discuss some information security issues suffered by various congestion control approaches.5. References
5.1. Informative References
[Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", Proceedings of ACM SIGCOMM'99, September 1999. [Andrew05] Andrew, L., Wydrowski, B., and S. Low, "An Example of Instability in XCP", Manuscript available at <http://netlab.caltech.edu/maxnet/XCP_instability.pdf>. [Arkko09] Arkko, J., Briscoe, B., Eggert, L., Feldmann, A., and M. Handley, "Dagstuhl Perspectives Workshop on End-to-End Protocols for the Future Internet," ACM SIGCOMM Computer Communication Review, Vol. 39, No. 2, pp. 42-47, April 2009. [Ath01] Athuraliya, S., Low, S., Li, V., and Q. Yin, "REM: Active Queue Management", IEEE Network Magazine, Vol. 15, No. 3, pp. 48-53, May 2001. [Balan01] Balan, R.K., Lee, B.P., Kumar, K.R.R., Jacob, L., Seah, W.K.G., and A.L. Ananda, "TCP HACK: TCP Header Checksum Option to Improve Performance over Lossy Links", Proceedings of IEEE INFOCOM'01, Anchorage (Alaska), USA, April 2001. [Bonald00] Bonald, T., May, M., and J.-C. Bolot, "Analytic Evaluation of RED Performance", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000.
[Bri06] Briscoe, B., "Using Self-interest to Prevent Malice; Fixing the Denial of Service Flaw of the Internet", Workshop on the Economics of Securing the Information Infrastructure, October 2006, <http://wesii.econinfosec.org/draft.php?paper_id=19>. [Bri07] Briscoe, B., "Flow Rate Fairness: Dismantling a Religion", ACM SIGCOMM Computer Communication Review, Vol. 37, No. 2, pp. 63-74, April 2007. [Bri08] Briscoe, B., Moncaster, T. and L. Burness, "Problem Statement: Transport Protocols Don't Have To Do Fairness", Work in Progress, July 2008. [Bri09] Briscoe, B., "Re-feedback: Freedom with Accountability for Causing Congestion in a Connectionless Internetwork", UCL PhD Thesis (2009). [Bri10] Briscoe, B. and J. Manner, "Byte and Packet Congestion Notification," Work in Progress, October 2010. [Chester04] Chesterfield, J., Chakravorty, R., Banerjee, S., Rodriguez, P., Pratt, I., and J. Crowcroft, "Transport level optimisations for streaming media over wide-area wireless networks", WIOPT'04, March 2004. [Chhabra02] Chhabra, P., Chuig, S., Goel, A., John, A., Kumar, A., Saran, H., and R. Shorey, "XCHOKe: Malicious Source Control for Congestion Avoidance at Internet Gateways," Proceedings of IEEE International Conference on Network Protocols (ICNP'02), Paris, France, November 2002. [Chiu89] Chiu, D.M. and R. Jain, "Analysis of the increase and decrease algorithms for congestion avoidance in computer networks", Computer Networks and ISDN Systems, Vol. 17, pp. 1-14, 1989. [Clark88] Clark, D., "The design philosophy of the DARPA internet protocols", ACM SIGCOMM Computer Communication Review, Vol. 18, No. 4, pp. 106-114, August 1988. [Clark98] Clark, D. and W. Fang, "Explicit Allocation of Best- Effort Packet Delivery Service", IEEE/ACM Transactions on Networking, Vol. 6, No. 4, pp. 362-373, August 1998. [Chu10] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", Work in Progress, October 2010.
[CONEX] IETF WG Action: Congestion Exposure (conex). [Dukki05] Dukkipati, N., Kobayashi, M., Zhang-Shen, R., and N. McKeown, "Processor Sharing Flows in the Internet", Proceedings of International Workshop on Quality of Service (IWQoS'05), Passau, Germany, June 2005. [Dukki06] Dukkipati, N. and N. McKeown, "Why Flow-Completion Time is the Right Metric for Congestion Control", ACM SIGCOMM Computer Communication Review, Vol. 36, No. 1, January 2006. [ECODE] "ECODE Project", European Commission Seventh Framework Program, Grant No. 223936, <http://www.ecode-project.eu>. [Falk07] Falk, A., Pryadkin, Y., and D. Katabi, "Specification for the Explicit Control Protocol (XCP)", Work in Progress, January 2007. [Feldman04] Feldman, M., Papadimitriou, C., Chuang, J., and I. Stoica, "Free-Riding and Whitewashing in Peer-to-Peer Systems" Proceedings of ACM SIGCOMM Workshop on Practice and Theory of Incentives in Networked Systems (PINS'04) 2004. [Firoiu00] Firoiu, V. and M. Borden, "A Study of Active Queue Management for Congestion Control", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000. [Floyd93] Floyd, S. and V. Jacobson, "Random early detection gateways for congestion avoidance", IEEE/ACM Transactions on Networking, Vol. 1, No. 4, pp. 397-413, August 1993. [Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, Vol. 24, No. 5, pp. 10-23, October 1994. [Gibbens02] Gibbens, R. and Kelly, F., "On Packet Marking at Priority Queues", IEEE Transactions on Automatic Control, Vol. 47, No. 6, pp. 1016-1020, 2002. [Ha08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A new TCP-friendly high-speed TCP variant", ACM SIGOPS Operating System Review, Vol. 42, No. 5, pp. 64-74, 2008.
[Hilt08] Hilt, V. and I. Widjaja, "Controlling Overload in Networks of SIP Servers", Proceedings of IEEE International Conference on Network Protocols (ICNP'08), Orlando (Florida), USA, October 2008. [Hollot01] Hollot, C., Misra, V., Towsley, D., and W.-B. Gong, "A Control Theoretic Analysis of RED", Proceedings of IEEE INFOCOM'01, Anchorage (Alaska), USA, April 2001. [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of ACM SIGCOMM'88 Symposium, August 1988. [Jain88] Jain, R. and K. Ramakrishnan, "Congestion Avoidance in Computer Networks with a Connectionless Network Layer: Concepts, Goals, and Methodology", Proceedings of IEEE Computer Networking Symposium, Washington DC, USA, April 1988. [Jain90] Jain, R., "Congestion Control in Computer Networks: Trends and Issues", IEEE Network, pp. 24-30, May 1990. [Jin04] Jin, Ch., Wei, D.X., and S. Low, "FAST TCP: Motivation, Architecture, Algorithms, Performance", Proceedings of IEEE INFOCOM'04, Hong-Kong, China, March 2004. [Jourjon08] Jourjon, G., Lochin, E., and P. Senac, "Design, Implementation and Evaluation of a QoS-aware Transport Protocol", Elsevier Computer Communications, Vol. 31, No. 9, pp. 1713-1722, June 2008. [Katabi02] Katabi, D., M. Handley, and C. Rohrs, "Internet Congestion Control for Future High Bandwidth-Delay Product Environments", Proceedings of ACM SIGCOMM'02 Symposium, August 2002. [Katabi04] Katabi, D., "XCP Performance in the Presence of Malicious Flows", Proceedings of PFLDnet'04 Workshop, Argonne (Illinois), USA, February 2004. [Kelly05] Kelly, F. and Th. Voice, "Stability of end-to-end algorithms for joint routing and rate control", ACM SIGCOMM Computer Communication Review, Vol. 35, No. 2, pp. 5-12, April 2005.
[Kelly98] Kelly, F., Maulloo, A., and D. Tan, "Rate control in communication networks: shadow prices, proportional fairness, and stability", Journal of the Operational Research Society, Vol. 49, pp. 237-252, 1998. [Keshav07] Keshav, S., "What is congestion and what is congestion control", Presentation at IRTF ICCRG Workshop, PFLDnet 2007, Los Angeles (California), USA, February 2007. [Key04] Key, P., Massoulie, L., Bain, A., and F. Kelly, "Fair Internet Traffic Integration: Network Flow Models and Analysis", Annales des Telecommunications, Vol. 59, No. 11-12, pp. 1338-1352, November-December 2004. [Krishnan04] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and M. Allman, "Explicit Transport Error Notification (ETEN) for Error-Prone Wireless and Satellite Networks", Computer Networks, Vol. 46, No. 3, October 2004. [Kuzmanovic03] Kuzmanovic, A. and E.W. Knightly, "TCP-LP: A Distributed Algorithm for Low Priority Data Transfer", Proceedings of IEEE INFOCOM'03, San Francisco (California), USA, April 2003. [LEDBAT] IETF WG Action: Low Extra Delay Background Transport (ledbat). [Lochin06] Lochin, E., Dairaine, L., and G. Jourjon, "Guaranteed TCP Friendly Rate Control (gTFRC) for DiffServ/AF Network", Work in Progress, August 2006. [Lochin07] Lochin, E., Jourjon, G., and L. Dairaine, "Study and enhancement of DCCP over DiffServ Assured Forwarding class", 4th Conference on Universal Multiservice Networks (ECUMN 2007), Toulouse, France, February 2007. [Low02] Low, S., Paganini, F., Wang, J., Adlakha, S., and J.C. Doyle, "Dynamics of TCP/RED and a Scalable Control", Proceedings of IEEE INFOCOM'02, New York (New Jersey), 2002. [Low03.1] Low, S., "A duality model of TCP and queue management algorithms", IEEE/ACM Transactions on Networking, Vol. 11, No. 4, pp. 525-536, August 2003.
[Low03.2] Low, S., Paganini, F., Wang, J., and J. Doyle, "Linear stability of TCP/RED and a scalable control", Computer Networks Journal, Vol. 43, No. 5, pp. 633-647, December 2003. [Low05] Low, S., Andrew, L., and B. Wydrowski, "Understanding XCP: equilibrium and fairness", Proceedings of IEEE INFOCOM'05, Miami (Florida), USA, March 2005. [MacK95] MacKie-Mason, J. and H. Varian, "Pricing Congestible Network Resources", IEEE Journal on Selected Areas in Communications, Advances in the Fundamentals of Networking, Vol. 13, No. 7, pp. 1141-1149, 1995. [Mascolo01] Mascolo, S., Casetti, Cl., Gerla M., Sanadidi, M.Y., and R. Wang, "TCP Westwood: Bandwidth estimation for enhanced transport over wireless links", Proceedings of MOBICOM 2001, Rome, Italy, July 2001. [Moors02] Moors, T., "A critical review of "End-to-end arguments in system design"", Proceedings of IEEE International Conference on Communications (ICC) 2002, New York City (New Jersey), USA, April/May 2002. [MPTCP] IETF WG Action: Multipath TCP (mptcp). [Noel07] Noel, E. and C. Johnson, "Initial Simulation Results That Analyze SIP Based VoIP Networks Under Overload", International Teletraffic Congress (ITC'07), Ottawa, Canada, June 2007. [Padhye98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, "Modeling TCP Throughput: A Simple Model and Its Empirical Validation", University of Massachusetts (UMass), CMPSCI Tech. Report TR98-008, February 1998. [Pan00] Pan, R., Prabhakar, B., and K. Psounis, "CHOKe: a stateless AQM scheme for approximating fair bandwidth allocation", Proceedings of IEEE INFOCOM'00, Tel Aviv, Israel, March 2000. [Pap02] Papadimitriou, I. and G. Mavromatis, "Stability of Congestion Control Algorithms using Control Theory with an application to XCP", Technical Report, 2002. <http://www.stanford.edu/class/ee384y/projects/ reports/ionnis.pdf>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", RFC 2861, June 2000. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003. [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003. [RFC3714] Floyd, S., Ed., and J. Kempf, Ed., "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large Congestion Windows", RFC 3742, March 2004. [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006. [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, March 2006. [RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure- Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006. [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006. [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007. [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007. [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007. [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, August 2007. [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007.
[RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, December 2007. [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008. [RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of Simple Best-Effort Traffic", RFC 5290, July 2008. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", RFC 5622, August 2009. [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681 (Obsoletes RFC 2581), September 2009. [RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC Series", RFC 5783, February 2010. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010. [Rossi06] Rossi, M., "Evaluating TCP with Corruption Notification in an IEEE 802.11 Wireless LAN", Master Thesis, University of Innsbruck, November 2006. Available from http://heim.ifi.uio.no/michawe/research/projects/ corruption/. [Saltzer84] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments in system design", ACM Transactions on Computer Systems, Vol. 2, No. 4, November 1984. [Sarola02] Sarolahti, P. and A. Kuznetsov, "Congestion Control in Linux TCP", Proceedings of the USENIX Annual Technical Conference, 2002.
[Sarola07] Sarolahti, P., Floyd, S., and M. Kojo, "Transport-layer Considerations for Explicit Cross-layer Indications", Work in Progress, March 2007. [Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM SIGCOMM Computer Communication Review, 1999. [Shal10] Shalunov, S., Hazel, G., and J. Iyengar, "Low Extra Delay Background Transport (LEDBAT)", Work in Progress, October 2010. [Shen08] Shen, C., Schulzrinne, H., and E. Nahum, "Session Initiation Protocol (SIP) Server Overload Control: Design and Evaluation, Principles", Systems and Applications of IP Telecommunications (IPTComm'08), Heidelberg, Germany, July 2008. [Shin08] Shin, M., Chong, S., and I. Rhee, "Dual-Resource TCP/AQM for Processing-Constrained Networks", IEEE/ACM Transactions on Networking, Vol. 16, No. 2, pp. 435-449, April 2008. [Thaler07] Thaler, D., Sridharan, M., and D. Bansal, "Implementation Report on Experiences with Various TCP RFCs", Presentation to the IETF Transport Area, March 2007. <http://www.ietf.org/proceedings/07mar/ slides/tsvarea-3/>. [Tickoo05] Tickoo, O., Subramanian, V., Kalyanaraman, S., and K.K. Ramakrishnan, "LT-TCP: End-to-End Framework to Improve TCP Performance over Networks with Lossy Channels", Proceedings of International Workshop on QoS (IWQoS), Passau, Germany, June 2005. [TRILOGY] "Trilogy Project", European Commission Seventh Framework Program (FP7), Grant No: 216372, <http://www.trilogy- project.org>. [Vinnic02] Vinnicombe, G., "On the stability of networks operating TCP-like congestion control," Proceedings of IFAC World Congress, Barcelona, Spain, 2002. [Welzl03] Welzl, M., "Scalable Performance Signalling and Congestion Avoidance", Springer (ISBN 1-4020-7570-7), September 2003.
[Welzl08] Welzl, M., Rossi, M., Fumagalli, A., and M. Tacca, "TCP/IP over IEEE 802.11b WLAN: the Challenge of Harnessing Known-Corrupt Data", Proceedings of IEEE International Conference on Communications (ICC) 2008, Beijing, China, May 2008. [Xia05] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, "One more bit is enough", ACM SIGCOMM Computer Communication Review, Vol. 35, No. 4, pp. 37-48, 2005. [Zhang03] Zhang, H., Towsley, D., Hollot, C., and V. Misra, "A Self-Tuning Structure for Adaptation in TCP/AQM Networks", Proceedings of ACM SIGMETRICS'03 Conference, San Diego (California), USA, June 2003.6. Acknowledgments
The authors would like to thank the following people whose feedback and comments contributed to this document: Keith Moore, Jan Vandenabeele, and Larry Dunn (his comments at the Manchester ICCRG and discussions with him helped with the section on packet- congestibility). Dimitri Papadimitriou's contribution was partly funded by [ECODE], a Seventh Framework Program (FP7) research project sponsored by the European Commission. Bob Briscoe's contribution was partly funded by [TRILOGY], a research project supported by the European Commission. Michael Scharf is now with Alcatel-Lucent.7. Contributors
The following additional people have contributed to this document: - Wesley Eddy <weddy@grc.nasa.gov> - Bela Berde <bela.berde@gmx.de> - Paulo Loureiro <loureiro.pjg@gmail.com> - Chris Christou <christou_chris@bah.com>
Authors' Addresses
Dimitri Papadimitriou (editor) Alcatel-Lucent Copernicuslaan, 50 2018 Antwerpen, Belgium Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.com Michael Welzl University of Oslo, Department of Informatics PO Box 1080 Blindern N-0316 Oslo, Norway EMail: michawe@ifi.uio.no Michael Scharf University of Stuttgart Pfaffenwaldring 47 70569 Stuttgart, Germany EMail: michael.scharf@googlemail.com Bob Briscoe BT & UCL B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE, UK EMail: bob.briscoe@bt.com