[re-ECN] Fwd: Pls bash: Congestion Exposure (re-ECN) BoF in Hiroshima?

[Bob Briscoe <[e-mail]>]

Folks,

Attached is my attempt so far. I started again - I'm happy with it so 
far, but it needs the specifics added at the end, where indicated.

I'm sending in case I don't get good connectivity while travelling. 
Once I'm done, I'll send a complete copy. But this gives something 
for you to push back on or for you to propose alternative text.

Apologies for sending an attachment (in a hurry).


Bob


>Date: Sat, 05 Sep 2009 13:31:14 +0100
>To: "Woundy, Richard" <[e-mail]>om>, 
>"COURCOUBETIS, Costas" <[e-mail]>gr>, Steven BLAKE 
><[e-mail]>s.com>, Marcelo BAGNULO BRAUN 
><[e-mail]>3m.es>, "MONCASTER, Toby" <[e-mail]>om>, 
>"Agarwal, Anil" <[e-mail]>om>, Tom Taylor 
><[e-mail]>s.com>, Ken Carlberg <[e-mail]>
>From: Bob Briscoe <[e-mail]>
>Subject: RE: [re-ECN] Fwd: Pls bash: Congestion Exposure (re-ECN) 
>BoF inHiroshima?
>Cc: re-ECN unIETF list <[e-mail]>

[snip]

>I'm off to a wedding for the rest of the day. I'll get back to this 
>first-thing (UK time) Sunday.

>Here's a suggested proposal outline:
>I'm aiming for something as brief as possible (e.g. 1-2pp).
>
>1. Intro
>   1 para top level motivation: Accountability for Congestion
>   1 para ambitious, so we have to bite off smallest self-contained chunk
>   1 para which particular bites to take (using an expt approach like LISP):
>     a) (INF) recording motivation(s)
>     b) (EXP) base congestion exposure protocol
>     c) (STD) process pre-requisites to do (b)
>     d) (INF) reports on experiments
>   1 para where other stuff is getting done, e.g. ICCRG
>
>2. A little more on each proposed working-group activity
>2.1 Motivation
>     Accountability for Congestion
>     Good fences make good neighbours
>     - IETF not been good at doing this (NATs, firewalls)
>     - this is a chance to do it well
>     Vision
>     - ECN gives all traffic tiny jitter & loss
>     - congestion accountability handles other QoS dimension; b/w allocation
>     - that's QoS sorted :)
>2.2 Protocol work
>        prob re-ECN, but open to suggestions
>        IPv4, IPv6 & TCP as example transport (for now)
>2.3 IETF Process
>     Depends on protocol encoding chosen
>     Current view:
>       need bit 48 in IPv4 hdr & IPv6 extension hdr + clash with ECN nonce
>     Planned assignment of required field(s) as experimental
>     Guidelines on how to confine experimental values (in space & time)
>2.4 Reports on Experiments
>     This w-g NOT designed to standardise uses of the protocol
>     - e.g. policers, new congestion controls, simpler QoS,
>       inter-domain metering, traffic engineering, DDoS miitigation
>     But w-g will act as a focus for expts & trials in using its protocol
>     Will produce reports on role of congestion exposure in trials, issues,
>     recommendations, re-thinks, etc.
>     Informs any future move from experimental to stds track
>2.5 (Optional) Focused work on deployment?
>     This is more than the minimum work that the w-g needs to bite off
>     But it's the most important gating factor
>     Therefore, it could form a focused piece of work in its own right
>     Survey of middleboxes that will break ECN, re-ECN etc.
>     Permanent partial deployment (user & net choice to expose congestion)
>     Incremental deployment outline & incentives
>
>3. Proposed BoF Agenda
>    Motivations (which main motivation?)
>    Demo (what demo?)
>    Misconceptions
>     - congestion (with ECN) != impairment
>     - uncongested path != good (a symptom of broken transport protocols)
>     - exposing congestion != operator privacy concerns
>    Brief protocol outline
>    Relationship to other w-gs
>    Community - who's doing what; who's planning what
>    Questions to put to a vote
>
>
>Bob



Bob


________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research  

IETF BoF Proposal: Congestion Exposure (re-ECN)

The Internet is all about sharing capacity between multiple users -
that's what packet multiplexing is all about. But the IETF (and the
wider industry) is realising we really don't understand how best to
share out capacity.

In Nov 2008, the Transport Area of the IETF asked the IRTF Congestion
Control Research Group (ICCRG) to set direction on this challenge and
good progress is being made. In parallel, this BoF proposal brings
together those who want to form a working group to experiment with one
of the more promising approaches. The aim is not to pre-judge the
outcome of the ICCRG's deliberations, but to investigate the practical
issues that will arise in defining and using one of the more promising
options: congestion exposure.

The relationship between the LISP w-g in Int Area and the IRTF Routing
Research Group provides a close analogy for the proposed process.

Congestion Exposure?

The premise is that we are having trouble sharing capacity because the
information needed to share capacity properly isn't made visible at the
internetwork layer. Specifically, the idea is to make expected
congestion on the rest of the path visible in the IP header of each
packet as it enters the internetwork. A protocol called re-ECN
(re-inserted explicit congestion notification) has been proposed to do
this. Re-ECN is the strongest candidate for adoption, but of course the
proposed working group might want to redesign it, or adopt an
alternative if one surfaces.

Whatever protocol is adopted, it should be possible for a network
operator to count the volume of congestion about to be caused by an
aggregate of traffic, as easily as it can count the volume of bytes
entering its network today - it just counts only the volume of those
packets that carry a congestion marking. This can be done for each user,
or for whole attached networks.

There is no intent to change the existing approach, where congestion is
detected and responded to by transports on endpoints (e.g. congestion
control in TCP, RTP/RTCP). The only difference is that network operators
will be able to discourage the one factor that causes grief to their
other customers: the volume of congestion.

The proposed working group will NOT define how exposed congestion should
be used. It will confine itself to the focused task of defining the
protocol for exposing congestion. However, it will definitely encourage
informational descriptions of how exposed congestion was used in various
experiments, to assess whether the way the protocol exposes congestion
is fit for purpose - where different people will have different
purposes.

Congestion exposure seems a rather unexpected direction to take, but a
growing community is realising just how powerful this approach can be;
and it sheds light on why we have misunderstood capacity sharing in the
past.

The work of the LEDBAT working-group (low extra delay background
transport) is a good example of the direction we ought to be taking, and
it also highlights that congestion exposure will be needed. LEDBAT is a
congestion control intended for background traffic. It yields far more
than TCP does to competing traffic. It senses congestion earlier than
other congestion controls (by noticing an increase in round trip time),
so it uses a smaller share of capacity when other traffic is present.

LEDBAT illustrates two points:
1. It is not appropriate (`fair') for all flows to get the same rate as
TCP would through a bottleneck (TCP-friendliness);
2. It would not be fair for an ISP to count the volume of bytes
transferred in order to limit heavy users. A certain volume of LEDBAT
bytes causes significantly less harm to other uses of the Internet than
the same volume of bytes transferred using TCP (and an unresponsive UDP
would be even worse).

In a Transport Area plenary straw poll at the March '09 IETF, there was
zero support for TCP-friendliness as a way forward for the IETF. But we
also need to recognise that LEDBAT is only a first step, not the whole
answer. For instance, a 100kB flow will want 10MB flows to yield into
the background, but similarly, the 10MB flow will want a 10GB flow to
yield further into the background. And operators need a metric to ensure
transports have the incentive to push back or yield as appropriate.
Getting this right will allow the smaller flows to complete much sooner,
but then free up capacity earlier so that the larger flows can still
complete nearly as quickly.

TBA: Vision. Relax transport constraints. Congestion != impairment.

TBA: Proposed working group deliverables

TBA: Proposed BoF Agenda.