draft-irtf-iccrg-welzl-congestion-control-open-research-01.txt   draft-irtf-iccrg-welzl-congestion-control-open-research-02.txt 
Network Working Group Michael Welzl Network Working Group Michael Welzl
Internet Draft Dimitri Papadimitriou Internet Draft Dimitri Papadimitriou
Document: draft-irtf-iccrg-wetzl- Editors Document: draft-irtf-iccrg-welzl- Editors
congestion-control-open-research-01.txt congestion-control-open-research-02.txt
Michael Scharf Michael Scharf
Bob Briscoe Bob Briscoe
Open Research Issues in Internet Congestion Control Open Research Issues in Internet Congestion Control
draft-irtf-iccrg-welzl-congestion-control-open-research-01.txt draft-irtf-iccrg-welzl-congestion-control-open-research-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 2008. This Internet-Draft will expire on January 30, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes some of the open problems in Internet This document describes some of the open problems in Internet
congestion control that are known today. This includes several new congestion control that are known today. This includes several new
challenges that are becoming important as the network grows, as well challenges that are becoming important as the network grows, as well
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [i]. document are to be interpreted as described in RFC-2119 [i].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Global Challenges – Overview...................................4 2. Global Challenges..............................................4
2.1 Heterogeneity..............................................4 2.1 Heterogeneity..............................................4
2.2 Stability..................................................6
2.3 Fairness...................................................7
3. Detailed Challenges............................................8 3. Detailed Challenges............................................8
3.1 Challenge 1: Router Support................................8 3.1 Challenge 1: Router Support................................8
3.2 Challenge 2: Corruption Loss..............................11 3.2 Challenge 2: Corruption Loss..............................12
3.3 Challenge 3: Small Packets................................13 3.3 Challenge 3: Small Packets................................14
3.4 Challenge 4: Pseudo-Wires.................................17 3.4 Challenge 4: Pseudo-Wires.................................18
3.5 Challenge 5: Multi-domain Congestion Control..............18 3.5 Challenge 5: Multi-domain Congestion Control..............20
3.6 Challenge 6: Precedence for Elastic Traffic...............19 3.6 Challenge 6: Precedence for Elastic Traffic...............21
3.7 Challenge 7: Misbehaving Senders and Receivers............20 3.7 Challenge 7: Misbehaving Senders and Receivers............22
3.8 Other challenges..........................................21 3.8 Other challenges..........................................23
4. Security Considerations.......................................24 4. Security Considerations.......................................25
5. Contributors..................................................24 5. Contributors..................................................26
6. References....................................................24 6. References....................................................26
7.1 Normative References.........................................24 6.1 Normative References.........................................26
Acknowledgments...............................................30 Acknowledgments...............................................32
1. Introduction 1. Introduction
This document describes some of the open research topics in the This document describes some of the open research topics in the
domain of Internet congestion control that are known today. We begin domain of Internet congestion control that are known today. We begin
by reviewing some proposed definitions of congestion and congestion by reviewing some proposed definitions of congestion and congestion
control based on current understandings. control based on current understandings.
Congestion can be defined as the reduction in utility due to overload Congestion can be defined as the reduction in utility due to overload
in networks that support both spatial and temporal multiplexing, but in networks that support both spatial and temporal multiplexing, but
no reservation [Keshav]. Congestion control is a (typically no reservation [Keshav]. Congestion control is a (typically
distributed) algorithm to share network resources among competing distributed) algorithm to share network resources among competing
traffic sources. Two components of distributed congestion control traffic sources. Two components of distributed congestion control
have been defined: the primal and the dual [Kelly98]. Primal have been defined in the context of prima-dual modeling [Kelly98].
congestion control refers to the algorithm executed by the traffic Primal congestion control refers to the algorithm executed by the
sources algorithm for controlling their sending rates or window traffic sources algorithm for controlling their sending rates or
sizes. This normally a closed-loop control, where this operation window sizes. This is normally a closed-loop control, where this
depends on feedback. TCP algorithms fall in the "primal" category. operation depends on feedback. TCP algorithms fall in this category.
Dual congestion control is implemented by the routers through Dual congestion control is implemented by the routers through
gathering information about the traffic traversing them. A dual gathering information about the traffic traversing them. A dual
congestion control algorithm updates, implicitly or explicitly, a congestion control algorithm updates, implicitly or explicitly, a
congestion measure and sends it back, implicitly or explicitly, to congestion measure and sends it back, implicitly or explicitly, to
the traffic sources that use that link. Queue management algorithms the traffic sources that use that link. Queue management algorithms
such as Random Early Detection (RED) [Floyd93] or Random Exponential such as Random Early Detection (RED) [Floyd93] or Random Exponential
Marking (REM) [Ath01] fall in the "dual" category. Marking (REM) [Ath01] fall in the "dual" category.
Congestion control provides for a fundamental set of mechanisms for Congestion control provides for a fundamental set of mechanisms for
maintaining the stability and efficiency of the Internet. Congestion maintaining the stability and efficiency of the Internet. Congestion
skipping to change at page 3, line 46 skipping to change at page 3, line 46
algorithms [Jacobson88] [RFC2581] are used by the Internet transport algorithms [Jacobson88] [RFC2581] are used by the Internet transport
protocol TCP [RFC4614]. They have been proven to be highly successful protocol TCP [RFC4614]. They have been proven to be highly successful
over many years but have begun to reach their limits, as the over many years but have begun to reach their limits, as the
heterogeneity of both the data link and physical layer and heterogeneity of both the data link and physical layer and
applications are pulling TCP congestion control (which performs applications are pulling TCP congestion control (which performs
poorly as the bandwidth or delay increases) outside of its natural poorly as the bandwidth or delay increases) outside of its natural
operating regime. A side effect of these deficits is that there is an operating regime. A side effect of these deficits is that there is an
increasing share of hosts that use non-standardized congestion increasing share of hosts that use non-standardized congestion
control enhancements (for instance, many Linux distributions have control enhancements (for instance, many Linux distributions have
been shipped with "CUBIC" as default TCP congestion control been shipped with "CUBIC" as default TCP congestion control
mechanism.) mechanism).
While the original Jacobson algorithm requires no congestion-related While the original Jacobson algorithm requires no congestion-related
state in routers, more recent modifications have departed from the state in routers, more recent modifications have departed from the
strict application of the end-to-end / transparency principle. Active strict application of the end-to-end principle [Saltzer84]. Active
Queue Management (AQM) in routers, e.g., RED and all its variants, Queue Management (AQM) in routers, e.g., RED and its variants such as
xCHOKE [Pan00], RED with In/Out (RIO) [Clark98], improves performance xCHOKE [Pan00], RED with In/Out (RIO) [Clark98], improves performance
by keeping queues small (implicit feedback via dropped packets), by keeping queues small (implicit feedback via dropped packets),
while Explicit Congestion Notification (ECN) [Floyd94] [RFC3168] while Explicit Congestion Notification (ECN) [Floyd94] [RFC3168]
passes one bit of congestion information back to senders when an AQM passes one bit of congestion information back to senders when an AQM
would normally drop a packet. These measures do improve performance, would normally drop a packet. These measures do improve performance,
but there is a limit to how much can be accomplished without more but there is a limit to how much can be accomplished without more
information from routers. The requirement of extreme scalability information from routers. The requirement of extreme scalability
together with robustness has been a difficult hurdle to accelerating together with robustness has been a difficult hurdle to accelerating
information flow. Primal-Dual TCP/AQM distributed algorithm stability information flow. Primal-Dual TCP/AQM distributed algorithm stability
and equilibrium properties have been extensively studied (cf. [Low02] and equilibrium properties have been extensively studied (cf. [Low02]
skipping to change at page 5, line 31 skipping to change at page 5, line 31
algorithms raise fairness issues, and they may be less robust in algorithms raise fairness issues, and they may be less robust in
certain situations for which they have not been designed. Up to now, certain situations for which they have not been designed. Up to now,
there is still no common agreement in the IETF on which algorithm and there is still no common agreement in the IETF on which algorithm and
protocol to choose. protocol to choose.
It is always possible to tune congestion control parameters based on It is always possible to tune congestion control parameters based on
some knowledge about the environment and the application scenario. some knowledge about the environment and the application scenario.
However, the fundamental question is whether it is possible to define However, the fundamental question is whether it is possible to define
one congestion control mechanism that operates reasonable well in the one congestion control mechanism that operates reasonable well in the
whole range of scenarios that exist in the Internet. Hence, it is an whole range of scenarios that exist in the Internet. Hence, it is an
important research question how such a "unified" congestion control important research question how new Internet congestion control
would have to be designed, and which maximum degree of dynamics it mechanisms would have to be designed, which maximum degree of
could efficiently handle. dynamics it could efficiently handle, and whether it could keep the
genererality of the existing end-to-end solutions.
Some improvements of congestion control could be realized by simple
changes of single functions in end-system or network components.
However, new mechanism can also require a fundamental redesign of the
overall network architecture, and they may even affect the design of
Internet applications. This can imply significant interoperability
and backward compatibility challenges and/or create network
accessibility obstacles. In particular, networks and/or applications
that do not use or support a new congestion control mechanism could
be penalized by a significantly worse performance compared to what
they would get if everybody used the existing mechanisms (cf. the
discussion on fairness in section 2.3). [RFC5033] defines several
criteria to evaluate the appropriateness of a new congestion control
mechanism. However, the fundamental question is how much performance
deterioration is acceptable for "legacy" applications. This tradeoff
between performance and cost has to be very carefully examined for
all new congestion control schemes.
2.2 Stability 2.2 Stability
Control theory, which is a mathematical tool for describing dynamic Control theory, which is a mathematical tool for describing dynamic
systems, lends itself to modeling congestion control - TCP is a systems, lends itself to modeling congestion control - TCP is a
perfect example of a typical "closed loop" system that can be perfect example of a typical "closed loop" system that can be
described in control theoretic terms. In control theory, there is a described in control theoretic terms. In control theory, there is a
mathematically defined notion of system stability. In a stable mathematically defined notion of system stability. In a stable
system, for any bounded input over any amount of time, the output system, for any bounded input over any amount of time, the output
will also be bounded. For congestion control, what is actually meant will also be bounded. For congestion control, what is actually meant
skipping to change at page 6, line 10 skipping to change at page 6, line 30
heterogeneous RTTs into account. It has therefore become common heterogeneous RTTs into account. It has therefore become common
practice to model simpler cases and leave the more complicated practice to model simpler cases and leave the more complicated
(realistic) situations for simulations. Clearly, if a mechanism is (realistic) situations for simulations. Clearly, if a mechanism is
not stable in a simple scenario, it is generally useless; this method not stable in a simple scenario, it is generally useless; this method
therefore helps to eliminate faulty congestion control candidates at therefore helps to eliminate faulty congestion control candidates at
an early stage. an early stage.
Some fundamental facts, which are known from control theory are Some fundamental facts, which are known from control theory are
useful as guidelines when designing a congestion control mechanism. useful as guidelines when designing a congestion control mechanism.
For instance, a controller should only be fed a system state that For instance, a controller should only be fed a system state that
reflects its output. A (low-pass) filter function should be reflects its output. A (low-pass) filter function should be used in
used in order to pass only states to the controller that are order to pass only states to the controller that are expected to last
expected to last long enough for its action to be meaningful long enough for its action to be meaningful [Jain88]. Action should
[Jain88]. Action should be carried out whenever such feedback be carried out whenever such feedback arrives, as it is a fundamental
arrives, as it is a fundamental principle of control that the control principle of control that the control frequency should be equal to
frequency should be equal to the feedback frequency. Reacting faster the feedback frequency. Reacting faster leads to oscillations and
leads to oscillations and instability while reacting slower makes the instability while reacting slower makes the system tardy [Jain90].
system tardy [Jain90].
TCP stability can be attributed to two key aspects which were TCP stability can be attributed to two key aspects which were
introduced in [Jacobson88]: the AIMD control law during congestion introduced in [Jacobson88]: the AIMD control law during congestion
avoidance, which is based on a simple, vector based analysis of two avoidance, which is based on a simple, vector based analysis of two
controllers sharing one resource with synchronous RTTs [Chiu89], and controllers sharing one resource with synchronous RTTs [Chiu89], and
the "conservation of packets principle", which, once the control has the "conservation of packets principle", which, once the control has
reached "steady state", tries to maintain an equal amount of packets reached "steady state", tries to maintain an equal amount of packets
in flight at any time by only sending a packet into the network when in flight at any time by only sending a packet into the network when
a packet has left the network (as indicated by an ACK arriving at the a packet has left the network (as indicated by an ACK arriving at the
sender). The latter aspect has guided many decisions regarding sender). The latter aspect has guided many decisions regarding
changes that were made to TCP over the years. changes that were made to TCP over the years.
The reasoning in [Jacobson88] assumes all senders to be acting at the The reasoning in [Jacobson88] assumes all senders to be acting at the
same time. The stability of TCP under more realistic network same time. The stability of TCP under more realistic network
conditions has been investigated in a large number of ensuing works, conditions has been investigated in a large number of ensuing works,
leading to no clear conclusion that TCP would also be asymptotically leading to no clear conclusion that TCP would also be asymptotically
stable under arbitrary network conditions. stable under arbitrary network conditions. The stability impact of
Slow Start (which can be significant as short-lived HTTP flows often
never leave this phase) is also not entirely clear.
2.3 Fairness 2.3 Fairness
Recently, the way the Internet community reasons about fairness has Recently, the way the Internet community reasons about fairness has
been called into deep questioning [Bri07]. Much of the community has been called into deep questioning [Bri07]. Much of the community has
taken fairness to mean approximate equality between the rates of taken fairness to mean approximate equality between the rates of
flows (flow rate fairness) that experience equivalent path congestion flows (flow rate fairness) that experience equivalent path congestion
as with TCP [RFC2581] and TFRC [RFC3448]. [RFC3714] depicts the as with TCP [RFC2581] and TFRC [RFC3448]. [RFC3714] depicts the
resulting situation as "The Amorphous Problem of Fairness". resulting situation as "The Amorphous Problem of Fairness".
A parallel tradition has been built on [Kelly98] where, as long as A parallel tradition has been built on [Kelly98] where, as long as
each user is accountable for the cost their rate causes to others each user is accountable for the cost their rate causes to others
[MKMV95], the set of rates that everyone chooses is deemed fair (cost [MKMV95], the set of rates that everyone chooses is deemed fair (cost
fairness)---because with any other set of choices people would lose fairness) - because with any other set of choices people would lose
more value than they gained overall. more value than they gained overall.
In comparison, the debate between max-min, proportional and TCP In comparison, the debate between max-min, proportional and TCP
fairness is about mere details. These three all share the assumption fairness is about mere details. These three all share the assumption
that equal flow rates are desirable; they merely differ in the second that equal flow rates are desirable; they merely differ in the second
order issue of how to share out excess capacity in a network of many order issue of how to share out excess capacity in a network of many
bottlenecks. In contrast, cost fairness should lead to extremely bottlenecks. In contrast, cost fairness should lead to extremely
unequal flow rates by design. Equivalently, equal flow rates would unequal flow rates by design. Equivalently, equal flow rates would
typically be considered extremely unfair. typically be considered extremely unfair.
The two traditional approaches are not protocol options that can each The two traditional approaches are not protocol options that can each
be followed in different parts of a network. They result in research be followed in different parts of a network. They result in research
agendas and issues that are different in their respective objectives agendas and issues that are different in their respective objectives
resulting in different set of open issues. resulting in different set of open issues.
If we assume TCP-friendliness as a goal with flow rate as the metric, If we assume TCP-friendliness as a goal with flow rate as the metric,
open issues would be: open issues would be:
- Should rate fairness depend on the packet rate or the bit rate? - Should rate fairness depend on the packet rate or the bit rate?
- Should flow rate depend on RTT (as in TCP) or whether only flow - Should the flow rate depend on RTT (as in TCP) or should only flow
dynamics should depend on RTT (e.g. as in Fast TCP [Jin04])? dynamics depend on RTT (e.g. as in Fast TCP [Jin04])?
- How to estimate whether a particular flow start strategy is fair,
- How to estimate whether a particular flow start strategy is fair? or whether a particular fast recovery strategy after a reduction in
Whether a particular fast recovery strategy after a reduction in
rate due to congestion is fair? rate due to congestion is fair?
- If an application needs still smoother flows than TFRC, or it needs - How should we judge what is reasonably fair if an application
to burst occasionally, or any other application behavior, how needs, for example, even smoother flows than TFRC, or it needs to
should to judge what is reasonably fair? burst occasionally, or with any other application behavior?
- During brief congestion bursts (e.g. due to new flow arrivals) how - During brief congestion bursts (e.g. due to new flow arrivals) how
to judge at what point it becomes unfair for some flows to continue to judge at what point it becomes unfair for some flows to continue
at a smooth rate while others reduce their rate? at a smooth rate while others reduce their rate?
- Which mechanism(s) should be used to enforce approximate flow rate
- Which mechanism(s) to enforce approximate flow rate fairness? fairness?
- How can we introduce some degree of fairness that takes account of - How can we introduce some degree of fairness that takes account of
flow duration? Large number of flows over separate paths (e.g. via flow duration?
an overlay)? - How to judge the fairness of applications using a large number of
flows over separate paths (e.g. via an overlay)?
If we assume cost fairness as a goal with congestion volume as the If we assume cost fairness as a goal with congestion volume as the
metric, open issues would be: metric, open issues would be:
- Can one application's sensitivity to instantaneous congestion - Can one application's sensitivity to instantaneous congestion
really be protected by longer-term accountability of competing really be protected by longer-term accountability of competing
applications? applications?
- Which protocol mechanism(s) to give accountability for causing - Which protocol mechanism(s) should give accountability for causing
congestion? congestion?
- How to design one or two generic transport protocols (such as to - How to design one or two generic transport protocols (such as to
TCP, UDP, etc.) with the addition of application policy control? TCP, UDP, etc.) with the addition of application policy control?
- Which policy enforcement by networks and interactions between - Which policy enforcement should be used by networks and which
application policy and network policy enforcement? interactions between application policy and network policy
- Competition with flows aiming for rate equality (e.g. TCP); enforcement?
- How to design a new policy enforcement framework that will
appropriately compete with existing flows aiming for rate equality
(e.g. TCP)?
The question of how to reason about fairness is a pre-requisite to The question of how to reason about fairness is a pre-requisite to
agreeing the research agenda. However, that question does not require agreeing on the research agenda. However, that question does not
more research in itself, it is merely a debate that needs to be require more research in itself, it is merely a debate that needs to
resolved by studying existing research and by assessing how bad be resolved by studying existing research and by assessing how bad
fairness problems could become if they are not addressed rigorously. fairness problems could become if they are not addressed rigorously.
3. Detailed Challenges 3. Detailed Challenges
3.1 Challenge 1: Router Support 3.1 Challenge 1: Router Support
Routers can be involved in congestion control in two ways: first, Routers can be involved in congestion control in two ways: first,
they can implicitly optimize their functions, such as queue they can implicitly optimize their functions, such as queue
management and scheduling strategies, in order to support the management and scheduling strategies, in order to support the
operation of an end-to-end congestion control. operation of an end-to-end congestion control. Second, routers can
participate in congestion control via explicit notification
mechanisms.
Various approaches have been proposed and also deployed, such as In the first category, various approaches have been proposed and also
different AQM techniques. Even though these implicit techniques are deployed, such as different AQM techniques. Even though these
known to improve network performance during congestion phases, they implicit techniques are known to improve network performance during
are still only partly deployed in the Internet. This may be due to congestion phases, they are still only partly deployed in the
the fact that finding optimal and robust parameterizations for these Internet. This may be due to the fact that finding optimal and robust
mechanisms is a non-trivial problem. Indeed, the problem with various parameterizations for these mechanisms is a non-trivial problem.
AQM schemes is the difficulty to identify correct values of the Indeed, the problem with various AQM schemes is the difficulty to
parameter set that affects the performance of the queuing scheme (due identify correct values of the parameter set that affects the
to variation in the number of sources, the capacity and the feedback performance of the queuing scheme (due to variation in the number of
delay) [Fioriu00] [Hollot01] [Zhang03]. Many AQM schemes (RED, REM, sources, the capacity and the feedback delay) [Fioriu00] [Hollot01]
BLUE, PI-Controller but also Adaptive Virtual Queue (AVQ)) do not [Zhang03]. Many AQM schemes (RED, REM, BLUE, PI-Controller but also
define a systematic rule for setting their parameters. Adaptive Virtual Queue (AVQ)) do not define a systematic rule for
setting their parameters.
Second, routers can participate in congestion control via explicit By using explicit feedback from the network, connection endpoints can
notification mechanisms. By such feedback from the network, obtain more accurate information about the current network
connection endpoints can obtain more accurate information about the characteristics on the path. This allows endpoints to make more
current network characteristics on the path. This allows endpoints to precise decisions that can better prevent packet loss and that can
make more precise decisions that can better prevent packet loss and also improve fairness among different flows. Examples for explicit
that can also improve fairness among different flows. Examples for router feedback include Explicit Congestion Notification (ECN)
explicit router feedback include Explicit Congestion Notification [RFC3168], Quick-Start [RFC4782], the eXplicit Control Protocol (XCP)
(ECN) [RFC3168], Quick-Start [RFC4782], and eXplicit Control Protocol [Katabi02] [Falk07], the Rate Control Protocol (RCP) [Dukk06], and
(XCP) [Katabi02] [Falk07]. CADPC/PTP [Welzl03].
As the per-flow bandwidth-delay product increases, TCP becomes Explicit router feedback can address some of the inherent
inefficient and prone to instability, regardless of the queuing shortcomings of TCP. For instance, XCP has been developed to overcome
scheme. XCP is a well-known scheme that has been developed to address the inefficiency, unfairness and instability that TCP suffers from
these issues with per-packet feedback. By decoupling resource when the per-flow bandwidth-delay product increases. By decoupling
utilization/congestion control from fairness control, XCP outperforms resource utilization/congestion control from fairness control, XCP
TCP in conventional and high bandwidth-delay environments, and achieves fair bandwidth allocation, high utilization, a small
remains efficient, fair, scalable, and stable regardless of the link standing queue size, and near-zero packet drops, with both steady and
capacity, the round trip time (RTT), and the number of sources. XCP highly varying traffic. Importantly, XCP does not maintain any per-
aims at achieving fair bandwidth allocation, high utilization, a flow state in routers and requires few CPU cycles per packet, hence
small standing queue size, and near-zero packet drops, with both making it potentially applicable in high-speed routers. However, XCP
steady and highly varying traffic. Importantly, XCP does not maintain is still subject to research: as [Andrew05] has pointed out, XCP is
any per-flow state in routers and requires few CPU cycles per packet, locally stable but globally unstable when the maximum RTT of a flow
hence making it potentially applicable in high-speed routers. is much larger than the mean RTT. This instability can be removed by
However, XCP is still subject to research efforts: [Andrew05] has changing the update strategy for the estimation interval, but this
recently pointed out cases where XCP is locally stable but globally makes the system vulnerable to erroneous RTT advertisements. The
unstable (when the maximum RTT of a flow is much larger than the mean authors of [PAP02] have shown that, when flows with different RTTs
RTT). This instability can be removed by setting the estimation are applied, XCP sometimes discriminates among heterogeneous traffic
interval to be the maximum observed RTT rather than the mean RTT. flows, even if XCP is generally fair to different flows. [Low05]
Nevertheless, this makes the system vulnerable to erroneous RTT provides for a complete characterization of the XCP equilibrium
advertisements. The authors of [PAP02] have shown that, when flows properties.
with different RTTs are applied, XCP sometimes discriminates among
heterogeneous traffic flows, even if XCP is generally fair to
different flows even if they belong to significantly heterogeneous
flows. [Low05] provides for a complete characterization of the XCP
equilibrium properties.
In general, such router support raises many issues that have not been Several other explicit router feedback schemes have been developed
with different design objectives. For instance, RCP uses a per-packet
feedback similar to XCP. Different to XCP, RCP focuses on the
reduction of flow completion times and therefore tolerates larger
instantaneous queue sizes [Dukk06].
Both implicit and explicit router support should be considered in the
context of the end-to-end argument [Saltzer84], which is one of the
key design principles of the Internet. It suggests that functions
that can be realized both in the end-systems and in the network
should be implemented in the end-systems. This principle ensures that
the network provides a general service and that remains as simple as
possible (any additional complexity is placed above the IP layer,
i.e., at the edges) so as to ensure reliability and robustness. In
particular, this means that Internet protocols should not rely on the
maintenance of applicative state (i.e., information about the state
of the end-to-end communication) inside the network [RFC1958] and
that the network state (e.g. routing state) maintained by the
Internet shall minimize its interaction with the states maintained at
the end-points/hosts.
However, as discussed for instance in [Moors02], congestion control
cannot be realized as a pure end-to-end function only. Congestion is
an inherent network phenomenon and can only be resolved efficiently
by some cooperation of end-systems and the network. Congestion
control in today's Internet protocols follows the end-to-end design
principle insofar as only minimal feedback from the network is used
(e. g., packet loss and delay). The end-systems only decide how to
react and how to avoid congestion. The crux is that, on the one hand,
there would be substantial benefit by further assistance from the
network, but, on the other hand, such router support could lead to
duplication of functions, which might even harmfully interact with
end-to-end protocol mechanisms. The different requirements of
applications (cf. the fairness discussion in Section 2.3) call for a
variety of different congestion control approaches, but putting such
application-specific behavior inside the network should be avoided,
as such design would clearly be at odds with the end-to-end design
principle.
The end-to-end argument is generally regarded as a key ingredient for
ensuring a scalable network design. In order to ensure that new
congestion control mechanisms are scalable, violating this principle
must therefore be avoided.
In general, router support raises many issues that have not been
completely solved yet. completely solved yet.
3.1.1 Performance and robustness 3.1.1 Performance and robustness
Congestion control is subject to some tradeoffs: on one hand, it must Congestion control is subject to some tradeoffs: on one hand, it must
allow high link utilizations and fair resource sharing but on the allow high link utilizations and fair resource sharing but on the
other hand, the algorithms must also be robust and conservative in other hand, the algorithms must also be robust and conservative in
particular during congestion phases. particular during congestion phases.
Router support can help to improve performance and fairness, but it Router support can help to improve performance and fairness, but it
skipping to change at page 9, line 43 skipping to change at page 11, line 11
congestion can delay feedback signals. Also, the measurement of congestion can delay feedback signals. Also, the measurement of
parameters such as RTTs or data rates may contain estimation errors. parameters such as RTTs or data rates may contain estimation errors.
Even though there has been significant progress in providing Even though there has been significant progress in providing
fundamental theoretical models for such effects, research has not fundamental theoretical models for such effects, research has not
completely explored the whole problem space yet. completely explored the whole problem space yet.
Open questions are: Open questions are:
- How much can routers theoretically improve performance in the - How much can routers theoretically improve performance in the
complete range of communication scenarios that exists in the complete range of communication scenarios that exists in the
Internet? Internet without damaging or impacting end-to-end mechanisms
already in place?
- Is it possible to design robust mechanisms that offer significant - Is it possible to design robust mechanisms that offer significant
benefits without additional risks? benefits without additional risks?
- What is the minimum support that is needed from routers in order - What is the minimum support that is needed from routers in order
to achieve significantly better performance than with end-to-end to achieve significantly better performance than with end-to-end
mechanisms? mechanisms?
3.1.2 Granularity of router functions 3.1.2 Granularity of router functions
skipping to change at page 10, line 36 skipping to change at page 12, line 4
- How can additional processing efforts be kept at a minimum? - How can additional processing efforts be kept at a minimum?
3.1.3 Information acquisition 3.1.3 Information acquisition
In order to support congestion control, routers have to obtain at In order to support congestion control, routers have to obtain at
least a subset of the following information. Obtaining that least a subset of the following information. Obtaining that
information may result in complex tasks. information may result in complex tasks.
1. Capacity of (outgoing) links 1. Capacity of (outgoing) links
Link characteristics depend on the realization of lower protocol Link characteristics depend on the realization of lower protocol
layers. Routers do not necessarily know the link layer network layers. Routers do not necessarily know the link layer network
topology and link capacities, and these are not always constant (e. topology and link capacities, and these are not always constant (e.
g., on shared wireless links). Difficulties also arise when using IP- g., on shared wireless links). Depending on the network technology,
in-IP tunnels [RFC 2003] or MPLS [RFC3031] [RFC3032]. In these cases, there can be queues or bottlenecks that are not directly visible at
link information could be determined by cross-layer information the IP layer. Difficulties also arise when using IP-in-IP tunnels
exchange, but this requires link layer technology specific [RFC 2003] or MPLS [RFC3031] [RFC3032]. In these cases, link
interfaces. An alternative could be online measurements, but this can information could be determined by cross-layer information exchange,
cause significant additional network overhead. but this requires link layer technology specific interfaces. An
alternative could be online measurements, but this can cause
significant additional network overhead.
2. Traffic carried over (outgoing) links 2. Traffic carried over (outgoing) links
Accurate online measurement of data rates is challenging when traffic Accurate online measurement of data rates is challenging when traffic
is bursty. For instance, measuring a "current link load" requires is bursty. For instance, measuring a "current link load" requires
defining the right measurement interval/ sampling interval. This is a defining the right measurement interval/ sampling interval. This is a
challenge for proposals that require knowledge e.g. about the current challenge for proposals that require knowledge e.g. about the current
link utilization. link utilization.
3. Internal buffer statistics 3. Internal buffer statistics
skipping to change at page 11, line 48 skipping to change at page 13, line 18
networks, packets can be dropped because of corruption, rendering the networks, packets can be dropped because of corruption, rendering the
typical reaction of a congestion control mechanism inappropriate. typical reaction of a congestion control mechanism inappropriate.
TCP over wireless and satellite is a topic that has been investigated TCP over wireless and satellite is a topic that has been investigated
for a long time [Krishnan04]. There are some proposals where the for a long time [Krishnan04]. There are some proposals where the
congestion control mechanism would react as if a packet had not been congestion control mechanism would react as if a packet had not been
dropped in the presence of corruption (cf. TCP HACK [BALAN01]), but dropped in the presence of corruption (cf. TCP HACK [BALAN01]), but
discussions in the IETF have shown that there is no agreement that discussions in the IETF have shown that there is no agreement that
this type of reaction is appropriate. For instance, it has been said this type of reaction is appropriate. For instance, it has been said
that congestion can manifest itself as corruption on shared wireless that congestion can manifest itself as corruption on shared wireless
links, and in any case it is questionable whether a source that sends links, and it is questionable whether a source that sends packets
packets that are continuously impaired by link noise should keep that are continuously impaired by link noise should keep sending at a
sending at a high rate. high rate.
Generally, two questions must be addressed when designing congestion Generally, two questions must be addressed when designing congestion
control mechanism that takes corruption into account: control mechanism that takes corruption into account:
1. How is corruption detected? 1. How is corruption detected?
2. What should be the reaction? 2. What should be the reaction?
In addition to question 1 above, it may be useful to consider In addition to question 1 above, it may be useful to consider
detecting the reason for corruption, but this has not yet been done detecting the reason for corruption, but this has not yet been done
skipping to change at page 12, line 44 skipping to change at page 14, line 14
The idea of having a transport endpoint detect and accordingly react The idea of having a transport endpoint detect and accordingly react
to corruption poses a number of interesting questions regarding to corruption poses a number of interesting questions regarding
cross-layer interactions. As IP is designed to operate over arbitrary cross-layer interactions. As IP is designed to operate over arbitrary
link layers, it is therefore difficult to design a congestion control link layers, it is therefore difficult to design a congestion control
mechanism on top of it, which appropriately reacts to corruption - mechanism on top of it, which appropriately reacts to corruption -
especially as the specific data link layers that are in use along an especially as the specific data link layers that are in use along an
end-to-end path are typically unknown to entities at the transport end-to-end path are typically unknown to entities at the transport
layer. layer.
The IETF has not yet specified how a congestion control mechanism While the IETF has not yet specified how a congestion control
should react to corruption. mechanism should react to corruption, proposals exist in the
literature. For instance, TCP Westwood sets the congestion window
equal to the measured bandwidth at time of congestion in response to
three DupACKs or a timeout. This measurement is obtained by counting
and filtering the ACK rate. This setting provides a significant
goodput improvement in noisy channels because the "blind" by half
window reduction of standard TCP is avoided, i.e. the window is not
reduced by too much [Mascolo01].
Open questions concerning corruption loss include: Open questions concerning corruption loss include:
- How should corruption loss be detected? - How should corruption loss be detected?
- How should a source react when it is known that corruption has - How should a source react when it is known that corruption has
occurred? occurred?
3.3 Challenge 3: Small Packets 3.3 Challenge 3: Small Packets
Over past years, the performance of TCP congestion avoidance Over past years, the performance of TCP congestion avoidance
algorithms has been extensively studied. The square root formula of algorithms has been extensively studied. The well known "square root
[Padye98] provides the performance of the TCP congestion avoidance formula" provides the performance of the TCP congestion avoidance
algorithm for TCP Reno [RFC2581]. The PKFT model enhances the square algorithm for TCP Reno [RFC2581]. [Padhye98] enhances the model to
root formula to account for timeouts, receiver window, and delayed account for timeouts, receiver window, and delayed ACKs.
ACKs. This formula validated by many experiments is insensitive to
the TCP flavor. However, large portion of TCP flows are short-lived
short-transfers, for which delay is dominated by slow-start.
For the sake of the present discussion, we will assume that the TCP For the sake of the present discussion, we will assume that the TCP
throughput is expressed using the simplified SQRT formula. Using this throughput is expressed using the simplified formula. Using this
formula, the TCP throughput is inversely proportional to the RTT and formula, the TCP throughput is proportional to the packet size and
the square root of the drop probability: inversely proportional to the RTT and the square root of the drop
probability:
MSS 1 MSS 1
B ~ C --- ------- B ~ C --- -------
RTT sqrt(p) RTT sqrt(p)
where where
MSS is the TCP segment size (in bytes) MSS is the TCP segment size (in bytes)
RTT is the end-to-end round trip time of the TCP connection (in RTT is the end-to-end round trip time of the TCP connection (in
seconds) seconds)
p is the packet drop probability p is the packet drop probability
Observing that TCP is not suited for applications such as streaming Neglecting the fact that the TCP rate linearly depends on it,
media (since reliable in-order delivery and congestion control can choosing the ideal packet size is a trade-off between high throughput
cause arbitrarily long delays), the Datagram Congestion Control (the larger a packet, the smaller the relative header overhead) and
Protocol (DCCP) [RFC4340] has been designed. DCCP enables unreliable low delay (the smaller a packet, the shorter the time that is needed
but congestion-controlled datagram flow transmission avoiding the until it is filled with data). Observing that TCP is not suited for
arbitrary delays associated with TCP. DCCP is intended for applications such as streaming media (since reliable in-order
delivery and congestion control can cause arbitrarily long delays),
this trade-off has not usually been considered for TCP applications,
and the influence of the packet size on the sending rate is not
typically seen as a significant issue.
The situation is different for the Datagram Congestion Control
Protocol (DCCP) [RFC4340], which has been designed to enable
unreliable but congestion-controlled datagram transmission, avoiding
the arbitrary delays associated with TCP. DCCP is intended for
applications such as streaming media that can benefit from control applications such as streaming media that can benefit from control
over the tradeoffs between delay and reliable in-order delivery. over the tradeoffs between delay and reliable in-order delivery.
DCCP provides for a choice of modular congestion control mechanisms. DCCP provides for a choice of modular congestion control mechanisms.
DCCP uses Congestion Control Identifiers (CCIDs) to specify the DCCP uses Congestion Control Identifiers (CCIDs) to specify the
congestion control mechanism. Three profiles are currently specified: congestion control mechanism. Three profiles are currently specified:
- DCCP Congestion Control ID 2 (CCID 2) [RFC4341]: - DCCP Congestion Control ID 2 (CCID 2) [RFC4341]:
TCP-like Congestion Control. CCID 2 sends data using a close TCP-like Congestion Control. CCID 2 sends data using a close
variant of TCP's congestion control mechanisms, incorporating a variant of TCP's congestion control mechanisms, incorporating a
variant of SACK [RFC2018, RFC3517]. CCID 2 is suitable for senders variant of SACK [RFC2018, RFC3517]. CCID 2 is suitable for senders
skipping to change at page 14, line 18 skipping to change at page 15, line 50
for bandwidth with TCP flows, but has a much lower variation of for bandwidth with TCP flows, but has a much lower variation of
throughput over time compared with TCP, making it more suitable for throughput over time compared with TCP, making it more suitable for
applications such as streaming media where a relatively smooth applications such as streaming media where a relatively smooth
sending rate is of importance. CCID 3 is appropriate for flows that sending rate is of importance. CCID 3 is appropriate for flows that
would prefer to minimize abrupt changes in the sending rate, would prefer to minimize abrupt changes in the sending rate,
including streaming media applications with small or moderate including streaming media applications with small or moderate
receiver buffering before playback. receiver buffering before playback.
- DCCP Congestion Control ID 4 [draft-ietf-ccid4-02.txt]: - DCCP Congestion Control ID 4 [draft-ietf-ccid4-02.txt]:
TFRC Small Packets (TFRC-SP) [RFC4828], a variant of TFRC TFRC Small Packets (TFRC-SP) [RFC4828], a variant of TFRC
mechanism has been designed for applications that exchange small mechanism has been designed for applications that exchange small
packets. The objective of TFRC-SP is to achieve the same packets. The objective of TFRC-SP is to achieve the same bandwidth
bandwidth in bps (bits per second) as a TCP flow using packets of in bps (bits per second) as a TCP flow using packets of up to 1500
up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms bytes. TFRC-SP enforces a minimum interval of 10 ms between data
between data packets to prevent a single flow from sending small packets to prevent a single flow from sending small packets
packets arbitrarily frequently. TFRC is a congestion control arbitrarily frequently. TFRC is a congestion control mechanism for
mechanism for unicast flows operating in a best-effort Internet unicast flows operating in a best-effort Internet environment, and
environment, and is designed for DCCP that controls the sending is designed for DCCP that controls the sending rate based on a
rate based on a stochastic Markov model for TCP Reno. CCID 4 has stochastic Markov model for TCP Reno. CCID 4 has been designed to
been designed to be used either by applications that use a small be used either by applications that use a small fixed segment size,
fixed segment size, or by applications that change their sending or by applications that change their sending rate by varying the
rate by varying the segment size. Because CCID 4 is intended for segment size. Because CCID 4 is intended for applications that use
applications that use a fixed small segment size, or that vary a fixed small segment size, or that vary their segment size in
their segment size in response to congestion, the transmit rate response to congestion, the transmit rate derived from the TCP
derived from the TCP throughput equation is reduced by a factor throughput equation is reduced by a factor that accounts for packet
that accounts for packet header size, as specified in [RFC4828]. header size, as specified in [RFC4828].
The resulting open questions are: The resulting open questions are:
- Assess and experiment TFRC-SP variant: in some stable and - How does TFRC-SP operate under various network conditions?
unstable conditions, it appears that the congestion control
mechanisms for small packets must be further enhanced, tightly
coordinated, and controlled over wide-area networks.
- How to design congestion control so as to scale with packet - How to design congestion control so as to scale with packet
size (dependency of congestion algorithm on packet size)? Early size (dependency of congestion algorithm on packet size)? Early
assessment shows that packet size dependency should remain at assessment shows that packet size dependency should remain at
the transport layer. the transport layer.
Today, many network resources are designed so that packet processing Today, many network resources are designed so that packet processing
cannot be overloaded even for incoming loads at the maximum bit-rate cannot be overloaded even for incoming loads at the maximum bit-rate
of the line. If packet processing can handle sustained load r [packet of the line. If packet processing can handle sustained load r [packet
per second] and the minimum packet size is h [bit] (i.e. packet per second] and the minimum packet size is h [bit] (i.e. packet
headers with no payload), then a line rate of x [bit per second] will headers with no payload), then a line rate of x [bit per second] will
never be able to overload packet processing as long as x =< r.h. never be able to overload packet processing as long as x <= r.h.
However, realistic equipment is often designed to only cope with a However, realistic equipment is often designed to only cope with a
near-worst-case workload with a few larger packets in the mix, rather near-worst-case workload with a few larger packets in the mix, rather
than the worst-cast of all minimum size packets. In this case, x = than the worst-cast of all minimum size packets. In this case, x =
r.(h + e) for some small value of e. r.(h + e) for some small value of e.
Therefore, it is likely that most congestion seen on today's Internet Therefore, it is likely that most congestion seen on today's Internet
is due to an excess of bits rather than packets, although packet- is due to an excess of bits rather than packets, although packet-
congestion is not impossible for runs of small packets (e.g. TCP ACKs congestion is not impossible for runs of small packets (e.g. TCP ACKs
or DoS attacks with small UDP datagrams). or DoS attacks with small UDP datagrams).
This observation raises additional open issues: This observation raises additional open issues:
o) Will bit congestion remain prevalent? - Will bit congestion remain prevalent?
Being able to assume that congestion is generally due to excess bits Being able to assume that congestion is generally due to excess bits
not excess packets is a useful simplifying assumption in the design not excess packets is a useful simplifying assumption in the design
of congestion control protocols. Can we rely on this assumption into of congestion control protocols. Can we rely on this assumption into
the future? the future?
Over the last three decades, performance gains have mainly been Over the last three decades, performance gains have mainly been
through increased packet rates, not bigger packets. But if bigger through increased packet rates, not bigger packets. But if bigger
maximum segment sizes become more prevalent, tiny segments (e.g. maximum segment sizes become more prevalent, tiny segments (e.g.
ACKs) will still continue to be widely used---a widening /range/ of
ACKs) will still continue to be widely used - a widening range of
packet sizes. packet sizes.
The open question is thus whether packet processing rates (r) will The open question is thus whether or not packet processing rates (r)
keep up with growth in transmission rates (x). A superficial look at will keep up with growth in transmission rates (x). A superficial
Moore's Law type trends would suggest that processing (r) will look at Moore's Law type trends would suggest that processing (r)
continue to outstrip growth in transmission (x). But predictions will continue to outstrip growth in transmission (x). But predictions
based on actual knowledge of technology futures would be useful. based on actual knowledge of technology futures would be useful.
Another open question is whether there are likely to be more small Another open question is whether there are likely to be more small
packets in the average packet mix. If the answers to either of these packets in the average packet mix. If the answers to either of these
questions predict that packet congestion could become prevalent, questions predict that packet congestion could become prevalent,
congestion control protocols will have to be more complicated. congestion control protocols will have to be more complicated.
o) Confusable Causes of Drop - Confusable Causes of Drop
There is a considerable body of research on how to distinguish There is a considerable body of research on how to distinguish
whether packet drops are due to transmission corruption or to whether packet drops are due to transmission corruption or to
congestion. But the full list of confusable causes of drop is longer congestion. But the full list of confusable causes of drop is longer
and includes transmission loss, congestion loss (bit congestion and and includes transmission loss, congestion loss (bit congestion and
packet congestion), and policing loss packet congestion), and policing loss.
If congestion is due to excess bits, the bit rate should be reduced. If congestion is due to excess bits, the bit rate should be reduced.
If congestion is due to excess packets, the packet rate can be If congestion is due to excess packets, the packet rate can be
reduced without reducing the bit rate---by using larger packets. reduced without reducing the bit rate - by using larger packets.
However, if the transport cannot tell which of these causes led to a However, if the transport cannot tell which of these causes led to a
specific drop, its only safe response is to reduce bit rate. This is specific drop, its only safe response is to reduce the bit rate. This
why the Internet would be more complicated if packet-congestion were is why the Internet would be more complicated if packet congestion
prevalent, as reducing the bit rate also reduces the packet rate were prevalent, as reducing the bit rate normally also reduces the
(except in perverse cases), while reducing the packet rate doesn't packet rate, while reducing the packet rate doesn't necessarily
necessarily reduce the bit rate. reduce the bit rate.
Given distinguishing between transmission loss and congestion is Given distinguishing between transmission loss and congestion is
already an open issue (Section 3.2), if that problem is ever solved, already an open issue (Section 3.2), if that problem is ever solved,
a further open issue would be whether to standardize a solution that a further open issue would be whether to standardize a solution that
distinguishes all the above causes of drop, not just two of them. distinguishes all the above causes of drop, not just two of them.
Nonetheless, even if we find a way for network equipment to Nonetheless, even if we find a way for network equipment to
explicitly distinguish which sort of drop has occurred, we will never explicitly distinguish which sort of drop has occurred, we will never
be able to assume that such a smart AQM solution is deployed at every be able to assume that such a smart AQM solution is deployed at every
congestible resource throughout the Internet---at every higher layer congestible resource throughout the Internet - at every higher layer
device like firewalls, proxies, servers and at every lower layer device like firewalls, proxies, servers and at every lower layer
device like low-end home hubs, DSLAMs, WLAN cards, cellular base- device like low-end home hubs, DSLAMs, WLAN cards, cellular base-
stations and so on. Thus, transport protocols will always have to stations and so on. Thus, transport protocols will always have to
cope with drops due to unguessable causes, so we should always treat cope with drops due to unguessable causes, so we should always treat
AQM smarts as an optimization, not a given. AQM smarts as an optimization, not a given.
o) What does a congestion notification on a packet of a certain size - What does a congestion notification on a packet of a certain size
mean? mean?
The open issue here is whether a loss or explicit congestion mark The open issue here is whether a loss or explicit congestion mark
should be interpreted as a single congestion event irrespective of should be interpreted as a single congestion event irrespective of
the size of the packet lost or marked, or whether the strength of the the size of the packet lost or marked, or whether the strength of the
congestion notification is weighted by the size of the packet. This congestion notification is weighted by the size of the packet. This
issue is discussed at length in [Bri08], along with other aspects of issue is discussed at length in [Bri08], along with other aspects of
packet size and congestion control. packet size and congestion control.
[Bri08] makes the strong recommendation that network equipment should [Bri08] makes the strong recommendation that network equipment should
drop or mark packets with a probability independent of each specific drop or mark packets with a probability independent of each specific
packet's size, while congestion controls should respond to dropped or packet's size, while congestion controls should respond to dropped or
skipping to change at page 16, line 36 skipping to change at page 18, line 17
congestion notification is weighted by the size of the packet. This congestion notification is weighted by the size of the packet. This
issue is discussed at length in [Bri08], along with other aspects of issue is discussed at length in [Bri08], along with other aspects of
packet size and congestion control. packet size and congestion control.
[Bri08] makes the strong recommendation that network equipment should [Bri08] makes the strong recommendation that network equipment should
drop or mark packets with a probability independent of each specific drop or mark packets with a probability independent of each specific
packet's size, while congestion controls should respond to dropped or packet's size, while congestion controls should respond to dropped or
marked packets in proportion to the packet's size. This issue is marked packets in proportion to the packet's size. This issue is
deferred to the Transport Area Working Group. deferred to the Transport Area Working Group.
o) Packet Size and Congestion Control Protocol Design - Packet Size and Congestion Control Protocol Design
If the above recommendation is correct---that the packet size of a If the above recommendation is correct - that the packet size of a
congestion notification should be taken into account when the congestion notification should be taken into account when the
transport reads, not when the network writes the notification---it transport reads, not when the network writes the notification - it
opens up a significant program of protocol engineering and re- opens up a significant program of protocol engineering and re-
engineering. Indeed, TCP does not take packet size into account when engineering. Indeed, TCP does not take packet size into account when
responding to losses or ECN. At present this is not a pressing responding to losses or ECN. At present this is not a pressing
problem because use of 1500B data segments is very prevalent for TCP problem because use of 1500B data segments is very prevalent for TCP
and the range of alternative segment sizes is not large. However, we and the range of alternative segment sizes is not large. However, we
should design the Internet's protocols so they will scale with packet should design the Internet's protocols so they will scale with packet
size, so an open issue is whether we should evolve TCP, or expect new size, so an open issue is whether we should evolve TCP, or expect new
protocols to take over. protocols to take over.
As we continue to standardize new congestion control protocols, we As we continue to standardize new congestion control protocols, we
skipping to change at page 18, line 34 skipping to change at page 20, line 18
responsive and efficient congestion control technique in order to responsive and efficient congestion control technique in order to
prevent impacting normally behaving Internet traffic. However, it is prevent impacting normally behaving Internet traffic. However, it is
still an open question how the corresponding mechanisms in the data still an open question how the corresponding mechanisms in the data
and control planes have to be designed. and control planes have to be designed.
3.5 Challenge 5: Multi-domain Congestion Control 3.5 Challenge 5: Multi-domain Congestion Control
Transport protocols such as TCP operate over the Internet that is Transport protocols such as TCP operate over the Internet that is
divided into autonomous systems. These systems are characterized by divided into autonomous systems. These systems are characterized by
their heterogeneity as IP networks are realized by a multitude of their heterogeneity as IP networks are realized by a multitude of
technologies. Variety of conditions and their variations leads to technologies. The variety of conditions and their variations leads to
correlation effects between policers that regulate traffic against correlation effects between policers that regulate traffic against
certain conformance criteria. certain conformance criteria.
With the advent of techniques allowing for early detection of With the advent of techniques allowing for early detection of
congestion, packet loss is no longer the sole metric of congestion. congestion, packet loss is no longer the sole metric of congestion.
ECN (Explicit Congestion Notification) marks packets - set by active ECN (Explicit Congestion Notification) marks packets - set by active
queue management techniques - to convey congestion information trying queue management techniques - to convey congestion information trying
to prevent packet losses (packet loss and the number of packets to prevent packet losses (packet loss and the number of packets
marked gives an indication of the level of congestion). Using TCP marked gives an indication of the level of congestion). Using TCP
ACKs to feed back that information allows the hosts to realign their ACKs to feed back that information allows the hosts to realign their
skipping to change at page 19, line 35 skipping to change at page 21, line 19
exchange some limited amount of information about their internal exchange some limited amount of information about their internal
state (topology hiding principle), even though having more precise state (topology hiding principle), even though having more precise
information could be highly beneficial for congestion control. The information could be highly beneficial for congestion control. The
future evolution of the Internet inter-domain operation has to show future evolution of the Internet inter-domain operation has to show
whether more multi-domain information exchange can be realized. whether more multi-domain information exchange can be realized.
3.6 Challenge 6: Precedence for Elastic Traffic 3.6 Challenge 6: Precedence for Elastic Traffic
Traffic initiated by so-called elastic applications adapt to the Traffic initiated by so-called elastic applications adapt to the
available bandwidth using feedback about the state of the network. available bandwidth using feedback about the state of the network.
There are two types of flows: short-lived flows and flows with an For all these flows the application dynamically adjusts the data
expected average throughput. For all those flows the application generation rate. Examples encompass short-lived elastic traffic
dynamically adjusts the data generation rate. Examples of short-lived including HTTP and instant messaging traffic as well as long file
elastic traffic include HTTP and instant messaging traffic. Examples transfers with FTP. In brief, elastic data applications can show
of average throughput requiring elastic traffic are FTP and email. In extremely different requirements and traffic characteristics.
brief, elastic data applications can show extremely different
requirements and traffic characteristics.
The idea to distinguish several classes of best-effort traffic types The idea to distinguish several classes of best-effort traffic types
is rather old, since it would be beneficial to address the relative is rather old, since it would be beneficial to address the relative
delay sensitivities of different elastic applications. The notion of delay sensitivities of different elastic applications. The notion of
traffic precedence was already introduced in [RFC791], and it was traffic precedence was already introduced in [RFC791], and it was
broadly defined as "An independent measure of the importance of this broadly defined as "An independent measure of the importance of this
datagram." datagram."
For instance, low precedence traffic should experience lower average For instance, low precedence traffic should experience lower average
throughput than higher precedence traffic. Several questions arise throughput than higher precedence traffic. Several questions arise
here: what is the meaning of "relative"? What is the role of the here: what is the meaning of "relative"? What is the role of the
Transport Layer? Transport Layer?
The preferential treatment of higher precedence traffic with The preferential treatment of higher precedence traffic with
appropriate congestion control mechanisms is still an open issue that appropriate congestion control mechanisms is still an open issue that
may, depending on the proposed solution, impact both the host and the may, depending on the proposed solution, impact both the host and the
network precedence awareness, and thereby congestion control. network precedence awareness, and thereby congestion control.
[RFC2990] points out that interactions between congestion control and
DiffServ [RFC2475] have yet to be addressed, and this statement is
still valid at the time of writing.
TODO: There is also still work to be performed regarding lower precedence
- Discuss existing work on low-priority flows – why isn't this stuff traffic – data transfers which are useful, yet not important enough
used? That's an open issue, interesting things could be done with it! to significantly impair any other traffic. Examples of applications
that could make use of such traffic are web caches and web browsers
- Discuss DiffServ [RFC2474] [RFC2475] related aspects with (e.g. for pre-fetching) as well as peer-to-peer applications. There
congestion control. are proposals for achieving low precedence on a pure end-to-end basis
(e.g. TCP-LP [Kuzmanovic]), and there is a specification for
achieving it via router mechanisms [RFC3662]. It seems, however, that
such traffic is still hardly used, and sending lower precedence data
is not yet a common service on the Internet.
3.7 Challenge 7: Misbehaving Senders and Receivers 3.7 Challenge 7: Misbehaving Senders and Receivers
In the current Internet architecture, congestion control depends on In the current Internet architecture, congestion control depends on
parties acting against their own interests. It is not in a receiver's parties acting against their own interests. It is not in a receiver's
interest to honestly return feedback about congestion on the path, interest to honestly return feedback about congestion on the path,
effectively requesting a slower transfer. It is not in the sender's effectively requesting a slower transfer. It is not in the sender's
interest to reduce its rate in response to congestion if it can rely interest to reduce its rate in response to congestion if it can rely
on others to do so. Additionally, networks may have strategic reasons on others to do so. Additionally, networks may have strategic reasons
to make other networks appear congested. to make other networks appear congested.
skipping to change at page 21, line 26 skipping to change at page 23, line 14
Note also that self-restraint is disappearing from the Internet. So, Note also that self-restraint is disappearing from the Internet. So,
it may no longer be sufficient to rely on developers/users it may no longer be sufficient to rely on developers/users
voluntarily submitting themselves to congestion control. As main voluntarily submitting themselves to congestion control. As main
consequence, mechanisms to enforce fairness (see Section 2.3) need to consequence, mechanisms to enforce fairness (see Section 2.3) need to
have more emphasis within the research agenda. have more emphasis within the research agenda.
3.8 Other challenges 3.8 Other challenges
This section provides additional challenges and open research issues This section provides additional challenges and open research issues
that are not (at this point in time) deemed sufficiently large or of that are not (at this point in time) deemed very large or of
different nature compared to the main challenges depicted since so different nature compared to the main challenges depicted since so
far. far.
Note that this section may be complemented in future release of this Note that this section may be complemented in future release of this
document by topics discussed during the last ICCRG meeting co-located document by topics discussed during the last ICCRG meeting, co-
with PFLDNet 2008 International Workshop. Topics of interest include located with PFLDNet 2008 International Workshop. Topics of interest
but not limited to multipath congestion control and congestion include multipath congestion control, and congestion control for
control for multimedia codecs that only support certain set of data multimedia codecs that only support certain set of data rates.
rates.
3.8.1 RTT estimation 3.8.1 RTT estimation
Several congestion control schemes have to precisely know the round- 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 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 on a network. It is defined as the delay between the sending of a
packet and the reception of a corresponding response, which is echoed packet and the reception of a corresponding response, which is echoed
back immediately by receiver upon receipt of the packet. This back immediately by receiver upon receipt of the packet. This
corresponds to the sum of the one-way delay of the packet and the corresponds to the sum of the one-way delay of the packet and the
(potentially different) one-way delay of the response. Furthermore, (potentially different) one-way delay of the response. Furthermore,
skipping to change at page 23, line 16 skipping to change at page 24, line 52
frequent RTT measurements with timestamps, certain implementations frequent RTT measurements with timestamps, certain implementations
modify the weight factors (e. g., [SK02]). There are also proposals modify the weight factors (e. g., [SK02]). There are also proposals
for more sophisticated estimators, such as Kalman filters or for more sophisticated estimators, such as Kalman filters or
estimators that utilize mainly peak values. estimators that utilize mainly peak values.
However, open questions concerning RTT estimation in the Internet However, open questions concerning RTT estimation in the Internet
remain: remain:
- Optimal measurement frequency: Currently, there is no common - Optimal measurement frequency: Currently, there is no common
understanding of the right time scale of RTT measurement. In understanding of the right time scale of RTT measurement. In
particular, the implications of rather frequent measurements (e. g., particular, the necessity of rather frequent measurements
per packet) are not well understood. There is some empirical evidence (e.g., per packet) is not well understood. There is some empirical
that frequent sampling may not have a significant benefit [Allman99]. evidence that such frequent sampling may not have a significant
benefit [Allman99].
- Filter design: A closely related question is how to design good - Filter design: A closely related question is how to design good
filters for the measured samples. The existing algorithms are known filters for the measured samples. The existing algorithms are known
to be robust, but they are far from being perfect. The fundamental 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 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 characterize the Internet as a whole, i. e., it is hard to define a
design target. design target.
- Default values: RTT estimators can fail in certain scenarios, e. - Default values: RTT estimators can fail in certain scenarios, e.
g., when any feedback is missing. In this case, default values have g., when any feedback is missing. In this case, default values have
skipping to change at page 24, line 21 skipping to change at page 26, line 9
4. Security Considerations 4. Security Considerations
Misbehavior may be driven by pure malice, or malice may in turn be Misbehavior may be driven by pure malice, or malice may in turn be
driven by wider selfish interests, e.g. using distributed denial of driven by wider selfish interests, e.g. using distributed denial of
service (DDoS) attacks to gain rewards by extortion [RFC4948]. DDoS service (DDoS) attacks to gain rewards by extortion [RFC4948]. DDoS
attacks are possible both because of vulnerabilities in operating attacks are possible both because of vulnerabilities in operating
systems and because the Internet delivers packets without requiring systems and because the Internet delivers packets without requiring
congestion control. congestion control.
To date, compliance with congestion control rules and being fair
requires end points 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 Currently the focus of the research agenda against denial of service
is about identifying attack packets, attacking machines and networks is about identifying attack packets, attacking machines and networks
hosting them, with a particular focus on mitigating source address hosting them, with a particular focus on mitigating source address
spoofing. But if mechanisms to enforce congestion control fairness spoofing. But if mechanisms to enforce congestion control fairness
were robust to both selfishness and malice [Bri06] they would also were robust to both selfishness and malice [Bri06] they would also
naturally mitigate denial of service, which can be considered (from naturally mitigate denial of service, which can be considered (from
the perspective of well-behaving Internet user) as a congestion the perspective of well-behaving Internet user) as a congestion
control enforcement problem. control enforcement problem.
5. Contributors 5. Contributors
This document is the result of a collective effort to which the This document is the result of a collective effort to which the
following people have contributed: following people have contributed:
Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel-lucent.be> Dimitri Papadimitriou <dimitri.papadimitriou@alcatel-lucent.be>
Michael Welzl <michael.welzl@uibk.ac.at> Michael Welzl <michael.welzl@uibk.ac.at>
Wesley Eddy <weddy@grc.nasa.gov> Wesley Eddy <weddy@grc.nasa.gov>
Bela Berde <bela.berde@gmx.de> Bela Berde <bela.berde@gmx.de>
Paulo Loureiro <loureiro.pjg@gmail.com> Paulo Loureiro <loureiro.pjg@gmail.com>
Chris Christou <christou_chris@bah.com> Chris Christou <christou_chris@bah.com>
Michael Scharf <michael.scharf@ikr.uni-stuttgart.de> Michael Scharf <michael.scharf@ikr.uni-stuttgart.de>
6. References 6. References
6.1 Normative References 6.1 Normative References
skipping to change at page 25, line 11 skipping to change at page 27, line 5
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC793, September 1981. RFC793, September 1981.
[RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896, [RFC896] Nagle, J., "Congestion Control in IP/TCP", RFC 896,
January 1984. January 1984.
[RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for [RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for
High Performance", RFC 1323, May 1992. High Performance", RFC 1323, May 1992.
[RFC1958] B. Carpenter, Ed., “Architectural Principles of the
[RFC2309] Braden, B., et al., "Recommendations on queue management [RFC2309] Braden, B., et al., "Recommendations on queue management
and congestion avoidance in the Internet", RFC 2309, and congestion avoidance in the Internet", RFC 2309,
April 1998. April 1998.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 1633, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 1633,
October 1996. October 1996.
[RFC2474] Nichols, K., Blake, S. Baker, F. and D. Black, [RFC2474] Nichols, K., Blake, S. Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December Field) in the IPv4 and IPv6 Headers", RFC 2474, December
skipping to change at page 25, line 36 skipping to change at page 27, line 31
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000. RFC 2914, September 2000.
[RFC2988] Paxson, V. and Allman, M., "Computing TCP's [RFC2988] Paxson, V. and Allman, M., "Computing TCP's
Retransmission Timer", RFC 2988, Nov. 2000 Retransmission Timer", RFC 2988, Nov. 2000
[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture",
RFC 2990, November 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003. RFC 3448, January 2003.
[RFC3540] N. Spring, D. Wetherall, "Robust Explicit Congestion [RFC3540] N. Spring, D. Wetherall, "Robust Explicit Congestion
Notification (ECN) Signaling with Nonces", RFC 3540, June Notification (ECN) Signaling with Nonces", RFC 3540, June
2003. 2003.
[RFC3662] Roland Bless, Kathleen Nichols, Klaus Wehrle, "A Lower
Effort Per-Domain Behavior for Differentiated Services",
RFC 3662, December 2003.
[RFC3714] S. Floyd, Ed., J. Kempf, Ed. "IAB Concerns Regarding [RFC3714] S. Floyd, Ed., J. Kempf, Ed. "IAB Concerns Regarding
Congestion Control for Voice Traffic in the Internet", Congestion Control for Voice Traffic in the Internet",
RFC 3714, March 2004. RFC 3714, March 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March Congestion Control Protocol (DCCP)", RFC 4340, March
2006. 2006.
skipping to change at page 26, line 33 skipping to change at page 28, line 40
Roadmap for Transmission Control Protocol (TCP) Roadmap for Transmission Control Protocol (TCP)
Specification Documents", RFC 4614, September 2006. Specification Documents", RFC 4614, September 2006.
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti,
"Quick-Start for TCP and IP", RFC 4782, Jan. 2007. "Quick-Start for TCP and IP", RFC 4782, Jan. 2007.
[RFC4948] L. Andersson, E. Davies, L. Zhang, "Report from the IAB [RFC4948] L. Andersson, E. Davies, L. Zhang, "Report from the IAB
workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, workshop on Unwanted Traffic March 9-10, 2006", RFC 4948,
August 2007. August 2007.
[RFC5033] S. Floyd, M. Allman, "Specifying New Congestion Control
Algorithms ", RFC 5033, Aug. 2007.
6.2 Informative References 6.2 Informative References
[Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End [Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM, Sept. 99. Network Path Properties", Proc. SIGCOMM, Sept. 99.
[Andrew00] L. Andrew, B. Wydrowski and S. Low, "An Example of [Andrew00] L. Andrew, B. Wydrowski and S. Low, "An Example of
Instability in XCP", Manuscript available at Instability in XCP", Manuscript available at
<http://netlab.caltech.edu/maxnet/XCP_instability.pdf> <http://netlab.caltech.edu/maxnet/XCP_instability.pdf>
[Ath01] S. Athuraliya, S. Low, V. Li, and Q. Yin, "REM: Active [Ath01] S. Athuraliya, S. Low, V. Li, and Q. Yin, "REM: Active
queue management", IEEE Network Magazine, vol.15, no.3, queue management", IEEE Network Magazine, vol.15, no.3,
pp. 48-53, May 2001. pp. 48-53, May 2001.
[BALAN01] Balan, R. K., Lee, B.P., Kumar, K.R.R., Jacob, L., Seah, [BALAN01] Balan, R. K., Lee, B.P., Kumar, K.R.R., Jacob, L., Seah,
W.K.G., Ananda, A.L., "TCP HACK: TCP Header Checksum W.K.G., Ananda, A.L., "TCP HACK: TCP Header Checksum
Option to Improve Performance over Lossy Links", Option to Improve Performance over Lossy Links",
Proceedings of IEEE Infocom, Anchorage, Alaska, April Proceedings of IEEE Infocom, Anchorage, Alaska, April
2001. 2001.
skipping to change at page 27, line 11 skipping to change at page 29, line 20
Option to Improve Performance over Lossy Links", Option to Improve Performance over Lossy Links",
Proceedings of IEEE Infocom, Anchorage, Alaska, April Proceedings of IEEE Infocom, Anchorage, Alaska, April
2001. 2001.
[Bonald00] T. Bonald, M. May, and J.-C. Bolot, "Analytic Evaluation [Bonald00] T. Bonald, M. May, and J.-C. Bolot, "Analytic Evaluation
of RED Performance," In Proceedings of IEEE INFOCOM, Tel of RED Performance," In Proceedings of IEEE INFOCOM, Tel
Aviv, Israel, March 2000. Aviv, Israel, March 2000.
[Bri07] Bob Briscoe, "Flow Rate Fairness: Dismantling a Religion" [Bri07] Bob Briscoe, "Flow Rate Fairness: Dismantling a Religion"
ACM SIGCOMM Computer Communication Review 37(2) 63--74 ACM SIGCOMM Computer Communication Review 37(2) 63--74
(April 2007). (April 2007)
[Bri06] Bob Briscoe, "Using Self-interest to Prevent Malice; [Bri06] Bob Briscoe, "Using Self-interest to Prevent Malice;
Fixing the Denial of Service Flaw of the Internet," Fixing the Denial of Service Flaw of the Internet,"
Workshop on the Economics of Securing the Information Workshop on the Economics of Securing the Information
Infrastructure (Oct 2006) Infrastructure (Oct 2006)
<http://wesii.econinfosec.org/draft.php?paper_id=19> <http://wesii.econinfosec.org/draft.php?paper_id=19>
[Chester04] Chesterfield, J., Chakravorty, R., Banerjee, S., [Chester04] Chesterfield, J., Chakravorty, R., Banerjee, S.,
Rodriguez, P., Pratt, I. and Crowcroft, J., "Transport Rodriguez, P., Pratt, I. and Crowcroft, J., "Transport
level optimisations for streaming media over wide-area level optimisations for streaming media over wide-area
skipping to change at page 27, line 33 skipping to change at page 29, line 42
[Chiu89] D. M. Chiu and R. Jain, "Analysis of the increase and [Chiu89] D. M. Chiu and R. Jain, "Analysis of the increase and
decrease algorithms for congestion avoidance in computer decrease algorithms for congestion avoidance in computer
networks", Computer Networks and ISDN Systems, vol. 17, networks", Computer Networks and ISDN Systems, vol. 17,
pp. 1-14, 1989. pp. 1-14, 1989.
[Clark98] D. Clark and W. Fang, "Explicit Allocation of Best-Effort [Clark98] D. Clark and W. Fang, "Explicit Allocation of Best-Effort
Packet Delivery Service," IEEE/ACM Transactions on Packet Delivery Service," IEEE/ACM Transactions on
Networking, vol.6, no.4, pp.362-373, August 1998 Networking, vol.6, no.4, pp.362-373, August 1998
[Dukki06] N. Dukkipati and N. McKeown, "Why Flow-Completion Time is
the Right Metric for Congestion Control" ACM SIGCOMM
Computer Communication Review Volume 36, issue 1, Jan.
2006.
[Floyd93] S. Floyd and V. Jacobson, “Random early detection [Floyd93] S. Floyd and V. Jacobson, “Random early detection
gateways for congestion avoidance,” IEEE/ACM Trans. on gateways for congestion avoidance,” IEEE/ACM Trans. on
Networking, vol.1, no.4, pp. 397-413, Aug. 1993. Networking, vol.1, no.4, pp. 397-413, Aug. 1993.
[Falk07] A. Falk et al "Specification for the Explicit Control [Falk07] A. Falk et al "Specification for the Explicit Control
Protocol (XCP)", Work in Progress, draft-falk-xcp-spec- Protocol (XCP)", Work in Progress, draft-falk-xcp-spec-
03.txt, July 2007. 03.txt, July 2007.
[Firoiu00] V. Firoiu and M. Borden, "A Study of Active Queue [Firoiu00] V. Firoiu and M. Borden, "A Study of Active Queue
Management for Congestion Control," In Proceedings of Management for Congestion Control," In Proceedings of
skipping to change at page 28, line 42 skipping to change at page 31, line 10
[Keshav] S. Keshav, "What is congestion and what is congestion [Keshav] S. Keshav, "What is congestion and what is congestion
control", Presentation at IRTF ICCRG Workshop, Pfldnet control", Presentation at IRTF ICCRG Workshop, Pfldnet
2007, (Los Angeles), California, February 2007. 2007, (Los Angeles), California, February 2007.
[Krishnan04] R. Krishnan, J. Sterbenz, W. Eddy, C. Partridge, and M. [Krishnan04] R. Krishnan, J. Sterbenz, W. Eddy, C. Partridge, and M.
Allman, "Explicit Transport Error Notification (ETEN) for Allman, "Explicit Transport Error Notification (ETEN) for
Error-Prone Wireless and Satellite Networks", Computer Error-Prone Wireless and Satellite Networks", Computer
Networks, vol.46, no.3, October 2004. Networks, vol.46, no.3, October 2004.
[Kuzmanovic] A. Kuzmanovic and E. W. Knightly, "TCP-LP: A Distributed
Algorithm for Low Priority Data Transfer", Proceedings of
IEEE INFOCOM 2003, San Francisco, CA, April 2003.
[Low05] S. Low, L. Andrew and B. Wydrowski. "Understanding XCP: [Low05] S. Low, L. Andrew and B. Wydrowski. "Understanding XCP:
equilibrium and fairness", Proceedings of IEEE Infocom, equilibrium and fairness", Proceedings of IEEE Infocom,
Miami, USA, March 2005. Miami, USA, March 2005.
[Low03.2] S. Low, F. Paganini, J. Wang, and J. Doyle, "Linear [Low03.2] S. Low, F. Paganini, J. Wang, and J. Doyle, "Linear
stability of TCP/RED and a scalable control", Computer stability of TCP/RED and a scalable control", Computer
Networks Journal, vol.43, no.5, pp.633-647, December Networks Journal, vol.43, no.5, pp.633-647, December
2003. 2003.
[Low03.1] S. Low, "A duality model of TCP and queue management [Low03.1] S. Low, "A duality model of TCP and queue management
algorithms", IEEE/ACM Trans. on Networking, vol.11, no.4, algorithms", IEEE/ACM Trans. on Networking, vol.11, no.4,
pp.525–536, August 2003. pp.525–536, August 2003.
[Low02] S. Low, F. Paganini, J. Wang, S. Adlakha, and J. C. [Low02] S. Low, F. Paganini, J. Wang, S. Adlakha, and J. C.
Doyle, "Dynamics of TCP/RED and a Scalable Control", Doyle, "Dynamics of TCP/RED and a Scalable Control",
Proceedings of IEEE Infocom, New York, USA, June 2002. Proceedings of IEEE Infocom, New York, USA, June 2002.
[Mascolo01] Saverio Mascolo, Claudio Casetti, Mario Gerla, M. Y.
Sanadidi, Ren Wang, "TCP westwood: Bandwidth estimation
for enhanced transport over wireless links", Proceedings
of MOBICOM 2001, pp. 287-297.
[Moors02] T. Moors, “A critical review of "End-to-end arguments in
system design"”, Proc. International Conference on
Communications (ICC), Apr./May 2002.
[MKMV95] MacKie-Mason, J. and H. Varian, "Pricing Congestible [MKMV95] MacKie-Mason, J. and H. Varian, "Pricing Congestible
Network Resources", IEEE Journal on Selected Areas in Network Resources", IEEE Journal on Selected Areas in
Communications, `Advances in the Fundamentals of Communications, `Advances in the Fundamentals of
Networking' 13(7)1141--1149, 1995, <http:// Networking' 13(7)1141--1149, 1995, <http://
www.sims.berkeley.edu/~hal/Papers/ www.sims.berkeley.edu/~hal/Papers/
pricing-congestible.pdf>. pricing-congestible.pdf>.
[Padye98] Padhye, J., Firoiu, V., Towsley, D., Kurose, J., Modeling [Padhye98] Padhye, J., Firoiu, V., Towsley, D., Kurose, J., Modeling
TCP Throughput: A Simple Model and Its Empirical TCP Throughput: A Simple Model and Its Empirical
Validation, UMASS CMPSCI Tech Report TR98-008, Feb. 1998. Validation, UMASS CMPSCI Tech Report TR98-008, Feb. 1998.
[Pan00] R. Pan, B. Prabhakar, and K. Psounis, "CHOKe: a stateless [Pan00] R. Pan, B. Prabhakar, and K. Psounis, "CHOKe: a stateless
AQM scheme for approximating fair bandwidth allocation", AQM scheme for approximating fair bandwidth allocation",
In Proceedings of IEEE Infocom, Tel Aviv, Israel, March In Proceedings of IEEE Infocom, Tel Aviv, Israel, March
2000. 2000.
[Rossi06] Rossi, M., "Evaluating TCP with Corruption Notification [Rossi06] Rossi, M., "Evaluating TCP with Corruption Notification
in an IEEE 802.11 Wireless LAN", master thesis, in an IEEE 802.11 Wireless LAN", master thesis,
University of Innsbruck, November 2006. Available from University of Innsbruck, November 2006. Available from
http://www.welzl.at/research/projects/corruption/ http://www.welzl.at/research/projects/corruption/
[Sarola02] Sarolahti, P. and Kuznetsov, A., "Congestion Control in [Sarola02] Sarolahti, P. and Kuznetsov, A., "Congestion Control in
Linux TCP", "Proc. USENIX Annual Technical Conference", Linux TCP", "Proc. USENIX Annual Technical Conference",
June 2002.
[Savage99] Savage, S., Wetherall, D., and T. Anderson, "TCP [Savage99] Savage, S., Wetherall, D., and T. Anderson, "TCP
Congestion Control with a Misbehaving Receiver," in ACM Congestion Control with a Misbehaving Receiver," in ACM
SIGCOMM Computer Communication Review (1999). SIGCOMM Computer Communication Review (1999).
[Saltzer84] Saltzer, J., Reed, D., and Clark, D. D.
End-to-end arguments in system design. ACM
Transactions on Computer Systems 2, 4 (Nov. 1984).
[TRILOGY] "Trilogy Project", European Commission Seventh Framework [TRILOGY] "Trilogy Project", European Commission Seventh Framework
Program Contract Number: INFSO-ICT-216372 Program Contract Number: INFSO-ICT-216372
<http://www.trilogy-project.org> <http://www.trilogy-project.org>
[Welzl03] M. Welzl, "Scalable Performance Signalling and Congestion
Avoidance", Springer, August 2003. ISBN 1-4020-7570-7.
[Welzl08] M. Welzl, M. Rossi, A. Fumagalli, and M. Tacca, " TCP/IP [Welzl08] M. Welzl, M. Rossi, A. Fumagalli, and M. Tacca, " TCP/IP
over IEEE 802.11b WLAN: the Challenge of Harnessing over IEEE 802.11b WLAN: the Challenge of Harnessing
Known-Corrupt Data", In Proceedings of IEEE ICC 2008, 19- Known-Corrupt Data", In Proceedings of IEEE ICC 2008, 19-
23 May 2008, Beijing, China. 23 May 2008, Beijing, China.
[Zhang03] H. Zhang, C. Hollot, D. Towsley, and V. Misra. "A Self- [Zhang03] H. Zhang, C. Hollot, D. Towsley, and V. Misra. "A Self-
Tuning Structure for Adaptation in TCP/AQM Networks", Tuning Structure for Adaptation in TCP/AQM Networks",
SIGMETRICS’03, June 10–14, 2003, San Diego, California, SIGMETRICS’03, June 10–14, 2003, San Diego, California,
USA. USA.
 End of changes. 72 change blocks. 
202 lines changed or deleted 327 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/