Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6077

Open Research Issues in Internet Congestion Control

Pages: 51
Informational
Part 3 of 3 – Pages 33 to 51
First   Prev   None

Top   ToC   RFC6077 - Page 33   prevText

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
Top   ToC   RFC6077 - Page 34
   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].
Top   ToC   RFC6077 - Page 35
   -  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
Top   ToC   RFC6077 - Page 36
   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
Top   ToC   RFC6077 - Page 37
   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
Top   ToC   RFC6077 - Page 38
   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
Top   ToC   RFC6077 - Page 39
   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.
Top   ToC   RFC6077 - Page 40
   [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.
Top   ToC   RFC6077 - Page 41
   [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.
Top   ToC   RFC6077 - Page 42
   [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.
Top   ToC   RFC6077 - Page 43
   [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.
Top   ToC   RFC6077 - Page 44
   [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>.
Top   ToC   RFC6077 - Page 45
   [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.
Top   ToC   RFC6077 - Page 46
   [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.
Top   ToC   RFC6077 - Page 47
   [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.
Top   ToC   RFC6077 - Page 48
   [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.
Top   ToC   RFC6077 - Page 49
   [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.
Top   ToC   RFC6077 - Page 50
   [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>
Top   ToC   RFC6077 - Page 51

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