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

[<[e-mail]>]

Hi Bob,

I'm working on a "Problem Statement" that I hope to have in some sort of
shape to send to the list by Monday morning. Whilst it is not directly
part of the BoF proposal it is a document that will be essential to get
a working group going.

More inline

Toby

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Bob Briscoe
> Sent: 02 September 2009 17:32
> To: [e-mail]
> Subject: [re-ECN] Pls bash: Congestion Exposure (re-ECN) BoF in
> Hiroshima?
> 
> Hi Folks,
> 
> I'd like to try to arrange a Congestion Exposure (re-ECN) BoF in Nov
> at the Hiroshima IETF. Pls bash the following proposals.
> 
> A/ Basic idea: Expose Congestion at network layer, so operators can
> encourage endpoint behaviours that minimise congestion while
> maximising performance (e.g. LEDBAT).

Agree, but let's make it clear that re-ECN provides a safety net which
will in turn lead operators to feel they can give their customers
freedom to do what they want, go as fast as they want, use whichever
congestion control they want, send as much data as they want, AS LONG AS
they take responsibility for the congestion they have caused

> 
> B/ Which Area?
> I suggest we should notify Int Area & Transport Area, but I imagine
> Transport Area would own this.

Transport definitely, but I imagine we would give regular updates to Int
area... Also might be of interest to applications or RAI as this could
give them some nice freedoms. I think we should also identify WGs that
might find this interesting (e.g. LEDBAT, MPTCP (being chartered at the
moment), etc

> 
> C/ Community (see separate mail)
> 
> D/ Ultimate documents to deliver (draft charter milestones):...?
> 1. (INF) Motivating cases for congestion exposure

Not sure we need this as a specific document. Perhaps make it a bit more
general to cover the idea of congestion transparency

> 2. (EXP) protocol spec (re-ECN is one proposal)
>     - choosing an encoding in IP, plus alternative encodings in an
> appendix

Yes

> 3. <if the encoding uses bit 48 in IPv4>
>     (STD) Reassign value 1 of bit 48 from 'reserved' to 'experimental
> use'
>     Also describe conditions on experiments, e.g.:
>     - confined in space and in time
>     - multiple simultaneous experiments with same value would need v
> strong case

This could be one of the most challenging things... Might almost be
better to just grab it for a specific experiment...

> 4. (INF) Report(s) on experimental uses of protocols
> 

These come later (after all the work is done)

> E/ Supporting text to work on
> - BoF Description     (by 07 Sep 09 BoF deadline - Monday!!)

Good Luck! I think we have the broad outline, just need to flesh it out,
but keep it concise (less than 3 pages ideally).

Also need a supporting document on how to gauge success of BoF. E.g.
What are the specific questions we want to hum on at the BoF...

> - Proposed BoF Agenda (by 28 Oct 09 WG agendas deadline)
> - Problem statement   (by 19 Oct 09 I-D deadline)

See above

> - Protocol proposal(s) (by 19 Oct 09 I-D deadline)
> - have I missed anything?
> 
> F/ Other requirements
> - What's the "elevator pitch"?
> - Demo? Of what? The protocol, or a use of the protocol? What use?

I reckon a use of the protocol. Will try and send a separate email about
this later on


> - BoF Chairs x2 (Rich Woundy has volunteered)

So ideally we need someone else from a completely different background.
Ideally with lots of IETF experience who has run successful BoFs. I
guess this will probably end up with approaching people direct. 3 names
that spring to mind are Gorry Fairhurst, Mark Handley and Marcelo
Bagnulo Braun

> 
> _____
> Minutes of Stockholm Bar BoF where we discussed this, and links to
> supporting docs so far:
> <http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN>
> 
> 
> 
> Bob
> 
> 
> ________________________________________________________________
> Bob Briscoe,               Networks Research Centre, BT Research
> 
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn