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

[<[e-mail]>]

OK here is my attempt at something a bit better. Feel free to bash it
hard:

-----------------
Congestion Transparency

It is increasingly clear that the current approach to sharing capacity
between users of networks isn't working. As a consequence ISPs feel they
have to police "heavy users" to free up resources for the bulk of their
customers. This involves making assumptions about the wishes of their
customers which in turn is fuelling tension between ISPs, customers,
content providers and application writers.

Other work at the IETF [LEDBAT, ALTO] and IRTF [ICCRG] is looking at new
approaches to controlling bulk data transfer rates. But these new
approaches will only work with the cooperation of the operators. What is
lacking is a mechanism to build trust between operators and end-users
and between different tiers of operators. In short the Internet lacks a
system for accountability.

This Congestion Transparency BoF focuses on exposing the congestion
information that end systems use to determine their transmission. By
sharing this information in an open manner among the many users on the
Internet it can provide the foundations for trust and accountability
throughout the network. Specifically, the protocols to be considered by
this BoF will expose the expected rest-of-path congestion in the IP
header of each packet such that nodes downstream of the source can see
the impact that will be caused by any packet they forward.

Currently 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 is
expected to redesign and thoroughly test alongside any alternative if
one surfaces. Whatever protocol is adopted, it should be possible for a
network operator to count the volume of congestion that is attributable
to an aggregate of traffic, as easily as it can count the volume of
bytes today. This can be done for each user, or for whole attached
networks. The defined protocol should work with minimal changes to the
existing network, in particular it should work with unmodified routers,
but in the long run it is envisaged these small changes will make a big
impact to how the limited resource of the network are shared.

This is not about changing the existing approach to congestion control,
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, if they choose, to monitor and control
the one factor that causes grief to their other customers: the volume of
congestion caused. In turn they can be monitored and controlled by their
providers. The proposed working group will NOT mandate how exposed
congestion should be used. It will confine itself to the focused task of
defining the protocol for exposing congestion. However, it will strongly
encourage experiments into how this information can be used and will
ultimately produce guidance on the dos and don'ts of using this
information. 

The proposed work items for this group are:
1)	An informational document giving the motivations for congestion
transparency and specifying the requirements for any protocol
2)	An experimental protocol for congestion transparency. This will
probably be based upon the proposed re-ECN protocol as significant
research work has already been done to understand and test this
protocol.
3)	One or more informational documents reporting the results of
experiments on applications of the congestion transparency protocol.
Specifically these experiments are likely to look at means to force
honest disclosure of congestion information and the impact of rationing
the congestion volume a given user or network can cause.

The initial goal is that all the output of the working group will be
informational or experimental, but once the experiments have been
completed then they will be used to determine if this approach should be
standardised within the IETF.
------------


I purposely omitted anything about congestion != impairment although I
did write the following paragraph. It just didn't seem to fit in with
the rest though...

-----
There is a common misconception that congestion is a bad thing.
Congestion != impairment... congestion is a necessary side-effect of
using a shared resource efficiently. This is implicitly recognised in
TCPs classic congestion avoidance strategy which is constantly probing
the network to find the current congestion level, with the aim of
running at a sufficient rate to efficiently utilise the available
bandwidth. With that in mind we simply seek to make end hosts openly
declare this information to the rest of the network so that everyone has
full visibility of all the information that matters.
-----

I was also wondering about making explicit mention of the causes of
this, but chose not to as it is likely to be contentious. For the same
reason I didn't explicitly mention Net Neutrality

Enjoy the rest of your Labor Day if you're in the States... 

Toby



> -----Original Message-----
> From: Woundy, Richard [mailto:[e-mail]]
> Sent: 07 September 2009 14:06
> To: Moncaster,T,Toby,DER3 R; Briscoe,RJ,Bob,XVR9 BRISCORJ R;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail];
[e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in
> Hiroshima?
> 
> I have to agree with Toby's comments.
> 
> The charter should be a declarative document, e.g. "this is what we
> will do and how we will do it". We don't have to review the history of
> the process that led to the BoF/WG being set up. No one will care
about
> that two years from now.
> 
> If you look at the first paragraph of the LEDBAT WG charter, it is a
> simple statement of the goal of the WG: "The LEDBAT WG is chartered to
> standardize a congestion control mechanism that should saturate the
> bottleneck, maintain low delay, and yield to standard TCP."
> 
> If we want something similar, we could say: "This BoF xxx is focused
on
> exposing information needed to share capacity among many users on the
> Internet. Specifically, the protocols to be considered by this BoF
will
> expose the expected congestion on the rest of the end-to-end path
> visible in the IP header of each packet." (stealing Bob's words of
> course)
> 
> The charter should say briefly (one sentence) how other stakeholders
> benefit from re-ECN et al, particularly end users and application
> providers.
> 
> As for an alternative BoF title, why not use 'Congestion Transparency'
> or 'Congestion Exposure' for now? We can come up with a 'cute acronym'
> like contran or conexp later in the process.
> 
> -- Rich, heading back to my Labor Day holiday,
> http://en.wikipedia.org/wiki/Labor_day for those in the UK
> 
> ________________________________
> 
> From: [e-mail] [mailto:[e-mail]]
> Sent: Mon 9/7/2009 6:36 AM
> To: [e-mail]; Woundy, Richard; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail];
[e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in
> Hiroshima?
> 
> 
> 
> Immediate top-level comment - drop the re-ECN from the title. This is
a
> BoF where we are trying to get the IETF to agree there is a need to
> introduce congestion transparency. Re-ECN is a specific protocol for
> doing that but there may be others so we shouldn't put it in the
title.
> 
> I really fear the overall order of things is wrong as well. The bulk
of
> the first 3 paragraphs is just about IETF processes and the IRTF...
The
> first paragraph is fine but you need to expand on that and get quickly
> towards a summary of the problem (the IETF hasn't provided a proper
> system on which to build network accountability so ISPs have started
to
> bodge their own, with dire consequences for the future of the
network).
> 
> I think we need to re-phrase quite a bit of the detailed stuff as
well,
> but that is a matter of editing rather than complete change of meaning
> so I will leave it for now...
> 
> Final thing - this is already starting to get too long. The MPTCP BoF
> description was ~600 words in total, TANA 9pre-cursor to LEDBAT) was
> ~450 total). You are already at 750 and you have 3 major bullets with
> no
> text! In other words we need to cut by about 50%...
> 
> Toby
> 
> > -----Original Message-----
> > From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> > Sent: 07 September 2009 11:19
> > To: Woundy, Richard; COURCOUBETIS, Costas; Steven BLAKE; Marcelo
> > BAGNULO BRAUN; Moncaster,T,Toby,DER3 R; Agarwal, Anil; Tom Taylor;
> Ken
> > Carlberg; Leslie Daigle; BOWMAN Don
> > Cc: re-ECN unIETF list
> > Subject: Fwd: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in
> > Hiroshima?
> >
> > 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
>