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

[Mirja Kuehlewind <[e-mail]>]

Hi,

I really like this version. I think this approach doesn't focus too early on 
re-ECN and gives a more general motivation to the problem. 
I think its good to bring accountability into the game even though it probably 
would go beyond the scope of this draft to explain what this actually means 
and how it helps for the whole situation...

One (useful) comment though: I would go for Congestion Exposure as the name, 
too. Because with re-ECN you can't really reveal the current congestion 
situation. It's more or less an estimation of the expected congestion given 
by the information collected in the last RTT. So this feels to me it is more  
exposing to have congestion at all (in a certain range) than actually showing 
up the exact level of current congestion.

I hope this helps a little,
Mirja
 


On Monday 07 September 2009 18:03:25 [e-mail] wrote:
> 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
>
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn



-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

web: www.ikr.uni-stuttgart.de
email: [e-mail]
tel: [phone]
-------------------------------------------------------------------