Subject: Re: [re-ECN] Draft Agenda

From: [email-masked]
Date: Wed, 7 Oct 2009 09:33:40 EDT

I have a newbie question: Is the ECN-router to be designed a network  
topology aware router  (e.g. an OSPF-router ?) or not ?
 
Heiner

In einer eMail vom 07.10.2009 10:59:49 Westeuropäische Sommerzeit schreibt  
[email-masked]:

Hi  Leslie,

Thanks for this. More inline

> -----Original  Message-----
> From: [email-masked]  [mailto:[email-masked]] On
> Behalf Of Leslie Daigle
>  Sent: 06 October 2009 23:14
> To: [email-masked]
> 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:
> 
> [email-masked] 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.
> 
> [email-masked] 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
> > [email-masked]
> >  https://www.ietf.org/mailman/listinfo/re-ecn
> >
> 
>  --
> 
>  -------------------------------------------------------------------
>  "Reality:
>       Yours to discover."
>    -- ThinkingCat
> Leslie  Daigle
> [email-masked]
>  -------------------------------------------------------------------
>  _______________________________________________
> re-ECN mailing  list
> [email-masked]
>  https://www.ietf.org/mailman/listinfo/re-ecn
_______________________________________________
re-ECN  mailing  list
[email-masked]
https://www.ietf.org/mailman/listinfo/re-ecn

---

From: <[email-masked]>
Date: Wed, 7 Oct 2009 15:47:35 +0100

In theory this should work with any router that has ECN capability regardless of whether it is topology-aware or not. The bigger issue is that ECN is either not deployed or not turned on in much of the network.

Toby

____________________________________________________________________ 
Toby Moncaster, Senior Researcher, Network Infrastructure Practice
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

From: [email-masked] [mailto:[email-masked]] 
Sent: 07 October 2009 14:34
To: Moncaster,T,Toby,DEE1 R; [email-masked]; [email-masked]
Subject: Re: [re-ECN] Draft Agenda

I have a newbie question: Is the ECN-router to be designed a network topology aware router  (e.g. an OSPF-router ?) or not ?

Heiner

In einer eMail vom 07.10.2009 10:59:49 Westeuropäische Sommerzeit schreibt [email-masked]:

	Hi Leslie,

	
	
	clear
	problem
	agenda
	think
	list),

	in

	
	
	plan

	

	
	Toby

	audience).
	for
	congestion
	that