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
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
- 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
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
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
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
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
- 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
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.1. Informative References
[Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", Proceedings of ACM SIGCOMM'99,
[Andrew05] Andrew, L., Wydrowski, B., and S. Low, "An Example of
Instability in XCP", Manuscript available at
[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
[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,
[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,
[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,
[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
[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,
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)
[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.
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
[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.
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.
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
[LEDBAT] IETF WG Action: Low Extra Delay Background Transport
[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),
[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
[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.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
[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,
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October
[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
[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,
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
[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
[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
[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,
[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,
[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,
[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
[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
[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,
[Shal10] Shalunov, S., Hazel, G., and J. Iyengar, "Low Extra Delay
Background Transport (LEDBAT)", Work in Progress, October
[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,
[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,
[Thaler07] Thaler, D., Sridharan, M., and D. Bansal, "Implementation
Report on Experiences with Various TCP RFCs",
Presentation to the IETF Transport Area, March 2007.
[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-
[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),
[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,
[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.
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-
Dimitri Papadimitriou's contribution was partly funded by [ECODE], a
Seventh Framework Program (FP7) research project sponsored by the
Bob Briscoe's contribution was partly funded by [TRILOGY], a research
project supported by the European Commission.
Michael Scharf is now with Alcatel-Lucent.
The following additional people have contributed to this document:
- Wesley Eddy <email@example.com>
- Bela Berde <firstname.lastname@example.org>
- Paulo Loureiro <email@example.com>
- Chris Christou <firstname.lastname@example.org>