Re: [re-ECN] Draft Agenda

[Leslie Daigle <[e-mail]>]

Hi,

In-line (trimming just to points of discussion):

[e-mail] wrote:
> 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...!
> 

I agree a BoF can get itself pretty lost in too long a slot, but I am 
hopeful that this work is far enough along that we could/should make use 
of the full slot.  But, we'll see!


>>
>> 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

Right.  But, the "R"-word often comes up in BoFs.   If the first part of 
the agenda goes well, this will be short & to the point.  (If the first 
part does not go well, people in the room will be confused about what 
the point is, and someone will throw down the "R" word).

So -- action items are: to be clear on a tight set of objective, 
functional requirements in advance of the BoF, and make sure the first 
part of the agenda goes well.

> 
>>
>>  > 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...

Agreed.


> 
>>  > 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...).

Let me offer a "+1" to Rich's sensible comments in a separate message in 
the thread.

I don't see how a demonstration could be effective in a BoF setting, 
though I think it would be useful at this juncture to have some slides 
with graphs of data from such a demonstration, as an illustration and 
invitation to come see the demo at some other time/location.

> 
> 
>>  > 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...
> 

Agreed.

Leslie.

> 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
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------