Re: [re-ECN] Draft Agenda

[<[e-mail]>]

Hi Leslie,

Thanks for this. More inline

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Leslie Daigle
> Sent: 06 October 2009 23:14
> To: [e-mail]
> Subject: Re: [re-ECN] Draft Agenda
> 
> 
> Hi,
> 
> I'm wondering if there's been further (offlist) progress on the bof
> agenda?  I've a few comments on the proposed agenda, below.

Thus far the only significant discussions on the agenda have been those
you highlight below...

> 
> I think these are about the right goals for now/the BoF:
> 
> [e-mail] wrote:
> > 1) Decide what questions we will ask at the BoF in order to get
clear
> > hums that result in a WG being forms.
> > 2) Define EXACTLY the problem we are addressing (by writing a
problem
> > statement document). And keep this concise and focussed (e.g. only
> > concentrate on a single aspect).
> > 3) Write a BRIEF email summarising the key points from the BoF
> proposal
> > which can be used to publicise the BoF on a bunch of other lists.
> > 4) Find a couple of experienced people to chair this - ideally both
> > having chaired successful BoFs and at least 1 having some experience
> in
> > this space.
> > 5) Work out an agenda - I envisage at most 3 presentations - the
> > problem, re-ECN as a potential solution (but without ANY protocol
> > detail) and a summary of what the WG would do. Then work out who
> > presents these.
> 
> 
> But I'm a little concerned that discussion on the list/the draft
agenda
> to date are, instead, vectoring towards a general introduction to the
> topic which will imply a 2nd BoF at a future IETF.  Since I don't
think
> we need to go there (bar bof already; plenty of momentum on this
list),
> let me suggest some agenda tightening:

Incidentally, since posting this draft agenda I notice that we have
provisionally been given a slot that spans the Tuesday afternoon break
and runs from 1520-1810 (with the break at 1700-1710). I personally feel
2h50 is probably too long for the BoF and there is always a risk of
losing some of the audience to clashing WGs (hokey, simple and pim).
However 1h40 is probably too short...!


> 
> 
>  > 5 mins      administrivia
>  > 10 mins     introduction by chairs
>  > 20 mins     the problem
> 
> I think 20min is a little optimistic, particularly given that the room
> will feature people who have not read the mailing list and/or drafts,
> and are there to "cross pollinate".  There are 2 levels of problem to
> expose/discuss/agree on, IMO:
> 
> 1/ the real world problem that needs to be addressed
> 	. challenges with congestion and fairness
> 	. this is really only motivation
> 
> 2/ the technology problem that is going to be solved
> 	. equipping IP with some mechanism to carry additional
> 	  information that will allow network routing mechanisms to
> 	  make more "informed" choices, and account for network activity
> 	. might include discussion of implications for other protocols
> 	  and deployment
> 
> "1/" is necessary for motivation, but it is subjective, and the folk
in
> the room are not there to discuss *all* possible ways to solve
> congestion/fairness issues, but rather a narrow set of (objective)
> technical possibilities ("2/"), and that's where you want the focus.

Sounds extremely sensible. One idea here might be to have 2 different
presenters. One does a brief background bit (your "1/") and then the
other focuses in as per your "2/"

> 
> 
> If there was going to be a discussion of requirements (per a comment
> from Rich Woundy on an earlier draft of the problem statement
> document),
> this might be a logical place to do it, in the agenda.

Agree that would be useful, but only if we can focus in on a tight set
of requirements by then

> 
> 
>  > 15 mins     towards a solution
> 
> So, with agreement that there is an IETF-tractable problem, and some
> sense of requirements on the table, people would have a basis to
> reasonably evaluate re-ECN (and any other proposal that found its way
> to
> the discussion) in the context of determining how it fits into the
plan
> for a WG -- which is its only purpose in being on the agenda of this
> BoF.  (Bob already knows its a great idea ;-) ).

I think we need to avoid going into any technical details of re-ECN (as
these are likely to lead to distracting side-debates that are not
directly relevant to the BoF). Instead any presentation should
concentrate on the principle that you can show downstream congestion if
you arrange things so that packets carry the upstream and whole-path
congestion in every header...

> 
>  > 10 mins     demonstration
> 
> ?

We are trying to put together a very simple demo of re-ECN to show that
it is possible to reveal congestion both upstream and downstream at any
point in the network. The idea was not to go into any technical detail
(after all the BoF isn't here to rubberstamp a solution, but it will
help people to see that a solution is possible and actually works...).


> 
>  > 40 mins     discussion
> 
> Assuming focus has remained on the question of whether there is IETF
> tractable work here, this discussion should be about whether or not
> there is a draft charter which adequately supports the sense of the
> room
> for progress to be made.
> 
>  > 10 mins     sumnmary
>  > 10 mins     questions and hums
> 
> 
> So, can I suggest:
> 
>   5 mins     administrivia
>   5 mins     introduction by chairs
> 40 mins     the problem
> 		context/motivation
> 		technical problem
> 20 mins     requirements
> 20 mins     towards a solution
> 		overview of re-ECN
> 		demonstration?
> 20 mins     draft charter discussion
> 10 mins     questions and hums

That sounds like a good agenda to me... The only thing that slightly
worries me is that some people may want longer for the discussion,
however as I pointed out the slot we currently have is longer than this
so we will have some flexibility here...

Toby


> 
> 
> 
> Leslie.
> 
> [e-mail] wrote:
> > As promised, here is the start of a discussion on the draft agenda
> for
> > the BoF... This is making the assumption that we will get 2 hours of
> > meeting time. I personally feel 2 hours is plenty - if we got more
> than
> > that the risk is that we will lose the focus (and lose our
audience).
> >
> > 5 mins      administrivia
> > 10 mins     introduction by chairs
> > 20 mins     the problem
> > 15 mins     towards a solution
> > 10 mins     demonstration
> > 40 mins     discussion
> > 10 mins     sumnmary
> > 10 mins     questions and hums
> >
> > Details:
> >
> > "The problem" will give the background to why we want to do this
> work,
> > and why now. It will probably be split into two halves - the general
> > problem for the Internet and the specific problem as seen by an
> > operator. It should largely cover the first half of the problem
> > statement document we are jointly working on.
> >
> > "towards a solution" will cover the second half of the problem
> statement
> > document. It will describe an overview of re-feedback and show how
> this
> > can allow congestion to be exposed by end-users. It WON'T have
> details
> > of re-ECN itself, however it could explain briefly the concept of
> > policing to a congestion rate.
> >
> > The "demonstration" should really take 5 mins, but allowing 10 mins
> > allows for things going wrong. At the moment the plan is to show a
> > simple re-ECN system where a series of different size files are
> > transferred across a link. At the BoF end there is a monitor that
> will
> > display the congestion level. We will be able to insert extra
> congestion
> > and show that the monitor can give you the congestion upstream and
> > downstream. The idea is to show that this is not just research but
> that
> > it is ready for the IETF - we aren't trying to impose our solution,
> we
> > just need to show that there is a solution possible...
> >
> > The "discussion" will need to be led by the chairs to prevent it
> going
> > off into protocol details or other dead-ends. The key thing is to
> work
> > towards getting agreement that the CONCEPT of exposing congestion
> (and
> > thus correcting the information asymmetry) is a good thing, and that
> it
> > is the starting point towards a more open and transparent means of
> > controlling the use of the Internet by monitoring the one thing that
> > actually impacts all users... One of the key things here will be to
> show
> > there is already an active community working in this area.
> >
> > "summary" just needs to bring together any loose ends from the
> > discussion and try and leave people with a clear set of messages,
for
> > instance: congestion is a key metric, currently congestion is hidden
> > from the layer that needs to know about it, revealing this
congestion
> > will correct the information asymmetry and lead to better control of
> the
> > Internet, etc
> >
> > "The questions" will need a whole email thread of their own, but
that
> > can wait till a bit nearer the day. The key thing is to have very
> clear
> > closed questions- that is questions that only have a yes or no
> answer...
> >
> > Toby
> > _______________________________________________
> > re-ECN mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/re-ecn
> >
> 
> --
> 
> -------------------------------------------------------------------
> "Reality:
>       Yours to discover."
>                                  -- ThinkingCat
> Leslie Daigle
> [e-mail]
> -------------------------------------------------------------------
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn