[IRTF-Announce] new IRTF research group: Internet Congestion Control (ICCRG)

[Aaron Falk <[e-mail]>]

IMPORTANT! This message has been blind-carbon-copied to you.
Do not reply-to-all or forward it without the author's permission.

Name
----

Internet Congestion Control Research Group (ICCRG)

Chairs
------

S. Keshav <[e-mail]>
Mark Handley <[e-mail]>


Mail List
---------

Subscribe: <http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>
List address: <[e-mail]>

Charter Page
------------

<http://www.irtf.org/charter?gtype=rg&group=iccrg>


Goals
-----

Key to the correct functioning of the Internet is TCP's congestion
control mechanism, which serves to match offered load to available
bandwidth.  Congestion control also allocates available bandwidth to many
flows, more or less reasonably.  Since the deployment of TCP's
additive-increase, multiplicative decrease (AIMD) algorithm in 1988, the
Internet has changed significantly, becoming much more heterogeneous in
many areas including link speeds and characteristics, and types of
application.  Although there is no immediate crisis, TCP's AIMD
algorithm is showing its limits in a number of areas, including but not
limited to:

 - insufficient dynamic range to handle high-speed wide-area networks
   (especially with few sources using them)

 - poor performance over links with unpredictable characteristics,
   such as some forms of wireless link.

 - poor latency characteristics for competing real-time flows.

The network research community has been very active in designing
modifications and alternatives to TCP's basic AIMD algorithm,
especially when it comes to high-speed congestion control.  A
non-exhaustive list of examples includes High-speed TCP, Scalable TCP,
H-TCP, FAST, and XCP.  However the network research community cannot,
by itself, effectively evaluate any such solution for Internet-scale
deployment.  To do this requires the involvement of equipment vendors,
network operators, and other IETF participants, in addition to the
research community.

The key goal of the ICCRG therefore is to move towards consensus on
which technologies are viable long-term solutions for the Internet
congestion control architecture, and what an appropriate cost/benefit
tradeoff is.

To achieve this goal will require extensive evaluation of different
mechanisms in a wide range of network conditions, using a mix of
simulation, analysis, and experiment.  It is unclear at this stage
whether any single proposed solution is viable, or whether there needs
to be a synthesis of ideas from many places.

Such an evaluation is especially difficult, given that some
mechanisms involve changes to queuing algorithms, or to packet
forwarding, whereas others only require end-system modifications.  It
is difficult therefore to compare like with like.  There is an
opportunity when making any widespread change to go further than the
simplest incremental modifications, but such larger changes have
costs, and so critical to the relevance of any recommendations from
ICCRG will be that any proposed solutions are considered to be
economically viable.  If router modifications are proposed, collecting
them and the tradeoff underlying them would be an important service of
the ICCRG.

There are many different aspects to congestion control that ICCRG
should consider.  For example, different real-time media applications
have (to a greater or lesser extent) a difficult time with dynamic
congestion control mechanisms, especially if changes must be made on
short timescales.  The rise of Internet telephony and the expected
rise of high-bandwidth Internet television will therefore
significantly impact the congestion control landscape.  The ICCRG
should therefore consider such applications, both in terms of how to
best support these various classes of application, and in terms of how
this impacts the overall emerging congestion control architecture.

Also within scope for ICCRG should be consideration of how congestion
control interacts with QoS mechanisms, with traffic engineering, and
with lower-layer technologies such as optical-burst-switching. Finally,
of significant importance is the interaction between denial-of-service
attacks targeted at bandwidth exhaustion, any mechanisms intended to
prevent such attacks, and the congestion control architecture.  Thus
the context for the work of this group is necessarily wide-reaching,
and touches on both architecture and mechanism.

Milestones
----------

It is hard to forecast exactly how the consensus process will play
out, and therefore precisely what milestones to expect.  However, as a
starting point to achieve focus for the group, ICCRG will produce an
RFC describing the nature of the emerging congestion control problems
that any future congestion control architecture must face.

An eventual goal is to produce a recommendation to the IETF on a
solution that would be appropriate for Internet-scale deployment.  It
is possible that more than one solution will be recommended - this is
likely if the solutions can gracefully co-exist.

It is also expected that ICCRG will produce IETF AD-sponsored RFCs
detailing good practice for how real-time applications might best
operate in a best-effort Internet.


Process
-------

ICCRG will hold 2-3 meetings per year, typically meeting for two days
at a time.  Critical to success is close involvement between the IETF
community and the ICCRG.  To this end, the ICCRG should make a
presentation at each IETF (probably in the TSVWG) summarizing progress
made, and what input is needed from the IETF.

Membership Policy
-----------------

Open




_______________________________________________
IRTF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/irtf-announce