Subject: Re: [re-ECN] Draft Agenda

From: Leslie Daigle <[email-masked]>
Date: Tue, 06 Oct 2009 18:14:02 -0400

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.

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:

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

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.

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

 > 10 mins     demonstration

?

 > 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

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

---

From: <[email-masked]>
Date: Wed, 7 Oct 2009 09:59:20 +0100

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

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

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

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

> 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

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

> 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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Oct 2009 17:29:42 +0200

Hi,

> help people to see that a solution is possible and actually works...).

I not sure how you gone make a demo (of re-ECN) without any technical details 
of re-ECN. The mechanism that there are re-ECN markings which have been 
insert by  the sender into the network based on the number of ECN markings 
the receiver has seen and that ECN marking are set by a router to signal 
congestion (usually bases one the current queue length) needs to be 
mentioned. And than you basically explained Re-ECN....?

Then I would like to know if I understood the scenario right: There will be 
one (TCP)-connection (with some congestion control ?) and a way to insert 
congestion (just set marking with a certain probability or start some other 
transmissions...?). I have a couple of these simple scenarios in my 
simulation and either I define the congestion (=setting markings with a 
certain pattern, but what realistic here..?) or the congestion level is 
varying very strong (because of TCP congestion control and most of the time 
there might be no congestion in these simple scenarios).

And how do you actually calculating the current congestion level? Because 
usually there are a couple of markings at one time and than it take more than 
one RTT that the Re-ECN markings balance it. If the congestion level is 
varying strongly, the delay might be a problem for getting a concrete values 
for the current congestion level in one network component...? 
Please correct me if I'm wrong. 

Mirja

---

From: <[email-masked]>
Date: Wed, 7 Oct 2009 16:45:52 +0100

First, the key thing is not to give a full demo of the capabilities of
re-ECN. All that is needed is something that shows congestion exposure
can be done and HAS been done...

> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: 07 October 2009 16:30
> To: [email-masked]
> Cc: Moncaster,T,Toby,DEE1 R; [email-masked]

You are right of course that there will need to be some explanation of
re-ECN. However this will be at the level of "ECN marks packets that
have been congested. We then re-insert that mark in the next round trip
and you can then use the difference between the two to measure the
downstream congestion". This will be shown graphically either using
simple counters or "gauges" on a screen. What we will avoid doing is
explaining any protocol details (e.g. bit 48 issues, how the count of
ECI is carried back to sender, etc).

> there might be no congestion in these simple scenarios).

One idea is to extend our testbed here in the UK out to Japan. We have a
high-speed traffic generator that generates up to ~30,000 stateful TCP
flows at Gbps speeds across 2 different physical links (+ countless
VLANs). We will set up a client at one end of the network (prob in
Hiroshima) and a server at the other with a number of applications
available (e.g. FTP, streaming video, web browsing). Across the
bottleneck we will be able to inject and remove traffic using the
traffic generator. The bottleneck will be an ECN-enabled router. At the
client end we can show that you can see the rate of ECN marks arriving
and that this balances the rate of re-ECN marks. At the server end we
can show re-ECN marks being inserted. If we are more clever we can add a
second bottleneck and demonstrate that you can see the downstream
congestion being caused by this second bottleneck.

> Please correct me if I'm wrong.

We would probably use some form of moving average for this (which gives
a kind of congestion rate). Or an absolute count that steadily increases
(congestion volume)

Hope that makes more sense?

Toby

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 7 Oct 2009 18:30:10 -0400

Toby,

>One idea is to extend our testbed here in the UK out to Japan. We have
a high-speed traffic generator that generates up to ~30,000 stateful TCP
flows at Gbps speeds across 2 different physical links (+ countless
VLANs). We will set up a client at one end of the network (prob in
Hiroshima) and a server at the other with a number of applications
available (e.g. FTP, streaming video, web browsing).

If you plan to perform a full re-ECN demo at Hiroshima, I would strongly
suggest coordination with the IETF 76 organizing committee; email them
at ietf76-operation at wide.ad.jp. The IETF 76 folks already have plans
for a few experiments during the meeting; see
http://www.inet.info.hiroshima-cu.ac.jp/ietf76-exp/.

If you are really considering a demo to send 1 Gbps worth of traffic
from the UK to Hiroshima, the folks running the IETF Meeting Network
will have to approve and support this. Here are two critical IETF
meeting network requirements from
http://iaoc.ietf.org/network_requirements.html:

"The primary link MUST provide at least 45Mb bandwidth in both
directions, and SHOULD have at least 100Mb bidirectionally. (Note:
Historically, bandwidth utilization peaked at 80Mb and averaged 35Mb.
Recent events have peaked at 50 Mbs and averaged in the 25Mb range.) The
backup link MUST have 10 Mb bandwidth in both directions and SHOULD have
at least 45 Mb bandwidth in both directions."

"The network provider MUST NOT view the IETF network as an experimental
facility at the risk of impacting the IETF attendee experience. (Do not
experiment with his/her favorite pet technology.)"

I have two suggestions, based on my previous experience (as part of the
host committee for IETF 71, and with several previous tech demos at IETF
meetings), that you can modify or reject as you like.

1. Keep the high bandwidth traffic for the re-ECN demo off the IETF
meeting network. I predict that the IETF meeting network folks will NOT
allow this traffic that would potentially affect the rest of the
participants' Internet experience. Use remote GUIs etc to manage and
show re-feedback mechanisms on heavy network traffic isolated to your UK
lab, for example.

2. Schedule the re-ECN demo prior to the BoF timeslot, in a separate
room allocated by the IETF meeting organizers. First, that will give the
demonstrators time to set up and tear down the demo equipment, without
impacting other WG/BoF sessions. Second, you don't have to worry about a
'last minute glitch' (or other demo failure) impacting the rest of the
BoF session; the folks in the BoF session ought to focus on the problem
statement and charter, not live debugging. Third, demo visitors can ask
as many questions about re-ECN technology as they like, without
derailing the BoF session discussions.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, October 07, 2009 11:46 AM
To: [email-masked]; [email-masked]
Subject: Re: [re-ECN] Draft Agenda

Toby

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 07 Oct 2009 18:59:41 -0400

Hi,

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

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

> Agree that would be useful, but only if we can focus in on a tight set

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.

> congestion in every header...

Agreed.

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

> so we will have some flexibility here...

Agreed.

Leslie.

--

---

From: <[email-masked]>
Date: Thu, 8 Oct 2009 10:10:45 +0100

Hi Rich,

Thanks for the useful info and advice. I have BCC'ed the 2 guys here
working on this. Don't worry - we aren't going to bring down the whole
network by sending 1Gbps round the globe from Ipswich, UK... The idea is
to have a relatively small data flow going e2e (e.g. a 50Mbyte file and
a 1Mbps stream). The vast bulk of the network will remain in our lab
which is where the ECN congestion will happen. We were then intending
running a VPN tunnel out to Hiroshima where we will have a laptop as a
router and network tap connected to a client laptop...

inline

> From: Woundy, Richard [mailto:[email-masked]]
> Sent: 07 October 2009 23:30
> To: Moncaster,T,Toby,DEE1 R; [email-masked]
> Cc: [email-masked]
> Subject: RE: [re-ECN] Draft Agenda
> 
> Toby,
> 

Good advice. We should at least notify the powers that be what is
happening...

> show re-feedback mechanisms on heavy network traffic isolated to your

As I say above we will be keeping all the really heavy traffic here in
the UK. Hopefully the IETF folks will be OK with the relatively modest
and short-term burst of data we will want to send through their network.
We will also do a recorded version of the demo in case it all goes wrong
when Bob gets to Japan.

> derailing the BoF session discussions.

We were already thinking of offering to do more detailed demos for
smaller groups and this is worth looking at. I guess it all comes down
to how big an impact a live demo will have on the audience. If it will
sway lots of people to change their view of this from "it's just Bob's
pipe dream" to "Ahh - it really works" then it is worth doing. If it
won't change minds then it isn't worth doing it in the BoF...

Toby

> Behalf
> > From: Mirja Kuehlewind
[mailto:[email-masked]]
> > > it is possible to reveal congestion both upstream and downstream
at
> > any
> > I not sure how you gone make a demo (of re-ECN) without any
technical
> > details
> > congestion (just set marking with a certain probability or start
some
> > other
> > simulation and either I define the congestion (=setting markings
with
> a
> > varying very strong (because of TCP congestion control and most of
> the
> > time
> a
> > varying strongly, the delay might be a problem for getting a
concrete
> > values

---

From: <[email-masked]>
Date: Thu, 8 Oct 2009 10:11:43 +0100

The demos we have planned will involve at most 2 flows between the UK
and Japan. The traffic generator will be sending traffic only across a
router in our lab in order to congest it and hence cause packets on our
flows to become congestion marked. 

If we successfully collaborate with Huawei then they will provide a
congestible network in Hiroshima, but again the bulk of the traffic will
be confined to that demonstration network.

I had considered the demo in the BOF meeting would be very basic - a
proof that a protocol is possible that would also aid understanding.
Anything additional to this could be shown in separate side meetings,
but I will leave it to the people attending to decide on this.

Alan

-----Original Message-----
Of Woundy, Richard

Toby,

-- Rich

-----Original Message-----

Toby

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 8 Oct 2009 15:09:55 -0400

Toby, thanks for responding.

I looked for some additional information about IETF meeting
demonstrations, and found this paragraph in "Hosting an IETF Meeting" at
http://www.ietf.org/meeting/hosting-an-ietf.html:

Demonstrations

All on-site demonstrations must be approved by the Secretariat. The
determination will be based entirely on the subject matter and its
applicability to the IETF. The opinion of the IESG may be solicited as
well. Approval must be also given by local host, if, the individual
giving the demo asks to use Terminal Room resources (i.e., equipment,
power and/or space). The local host may decline to accommodate requests
to support demonstrations on-site, especially if there is no physical
room, facilities or personnel available to support the effort.

Here is the contact info for the Secretariat:
http://www.ietf.org/secretariat.html. I'm not sure if you should contact
Ray Pelletier (IETF Administrative Director) first, or go through
[email-masked].

-- Rich 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 08, 2009 5:11 AM
To: Woundy, Richard
Cc: [email-masked]
Subject: RE: [re-ECN] Draft Agenda

Hi Rich,

inline

Toby

at
technical
some
with
concrete

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 8 Oct 2009 15:56:24 -0400

>I guess it all comes down to how big an impact a live demo will have on
the audience. If it will sway lots of people to change their view of
this from "it's just Bob's pipe dream" to "Ahh - it really works" then
it is worth doing. If it won't change minds then it isn't worth doing it
in the BoF...

My perspective is slightly different than this. As I understand, some
people assimilate new ideas by reading about them, some by hearing about
them, some by seeing it in action, and others by hands on experience. A
demo may help the third and fourth groups (learn by seeing and learn by
hands on experience) to conceptualize what is being proposed, and
therefore to motivate them to read the charter and problem statement and
participate in the BoF discussion. The third group (learn by seeing) can
be accommodated by a demo during the BoF or outside of the BoF, but the
fourth group (learn by hands on experience) should be accommodated by a
demo outside of the BoF (due to time restrictions).

I am not optimistic that a skeptic, e.g. "it's just Bob's pipe dream",
will be convinced by a short scripted demo during the BoF. At the same
time, it seems way too early in the IETF process to reject a concept
based on implementation issues, so I'm not sure the skeptic's objection
would be valid in any case.

That's my input on the demo -- I'll leave it to your and Alan's best
judgment about where to go from here.

-- Rich

P.S. Here is what I used as a basis for learning styles:
http://en.wikipedia.org/wiki/Learning_style#Other_models and
http://www.metamath.com/lsweb/fourls.htm. I am not a psychologist or
neuroscientist, so your mileage may vary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 08, 2009 5:11 AM
To: Woundy, Richard
Cc: [email-masked]
Subject: RE: [re-ECN] Draft Agenda

Hi Rich,

inline

Toby

at
technical
some
with
concrete

---

From: <[email-masked]>
Date: Fri, 9 Oct 2009 09:39:02 +0100

Toby,

As part of the establishing of a BOF has anyone formally mentioned a
demo? Is there a protocol for requesting space, connectivity, etc? I
mean from founders, presenters, chairs, etc? I ask just before I go
ahead and do it.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Woundy, Richard
Sent: 08 October 2009 20:10
To: Moncaster,T,Toby,DEE1 R
Cc: [email-masked]
Subject: Re: [re-ECN] Draft Agenda

Demonstrations

-- Rich 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 08, 2009 5:11 AM
To: Woundy, Richard
Cc: [email-masked]
Subject: RE: [re-ECN] Draft Agenda

Hi Rich,

inline

Toby

at
technical
some
with
concrete

---

From: Lars Eggert <[email-masked]>
Date: Sun, 11 Oct 2009 12:28:40 +0300

Hi,

I believe this text deals with demos that the organization *hosting*  
an IETF meeting might want to show on-site. For example, if Nokia were  
to host an IETF and we wanted to show some new phones, the secretariat  
- or the IESG? - would need to OK this. We don't want the hosts to do  
too much advertising at the venue.

I don't think this applies to demos done in the scope of a WG or BOF -  
there, it is up to the chairs to decide what is appropriate IMO.

> room, facilities or personnel available to support the effort.

Lars

---

From: "Woundy, Richard" <[email-masked]>
Date: Sun, 11 Oct 2009 16:23:22 -0400

Thanks Lars, I see your point about vendor demos.
 
>I don't think this applies to demos done in the scope of a WG or BOF 
 
Actually, folks in my group have coordinated several dual stack lite demos at IETF meetings; dual stack lite is being standardized in the Softwires working group. They definitely had to coordinate with the IETF meeting network engineers. That demo didn't generate much extra traffic, but it did require extra devices in the IETF meeting network.
 
Their concerns would seem to be proportional to the volume of traffic generated and/or the additional complexity in the IETF meeting network.
 
Again, I will defer to you and the BoF chairs.
 
-- Rich

________________________________

From: Lars Eggert [mailto:[email-masked]]
Sent: Sun 10/11/2009 5:28 AM
To: Woundy, Richard
Cc: [email-masked]; [email-masked]
Subject: Re: [re-ECN] Draft Agenda

Hi,

Lars

---

From: Matt Mathis <[email-masked]>
Date: Mon, 12 Oct 2009 14:16:26 -0400

I would like to point out  that  "[Need to confirm that the] demo
didn't generate much extra traffic." is just one symptom of the very
problem that we are trying to address....

and represents perhaps the easiest way to win the argument  "Is this
really needed?"  If the Internet had a proper sharing architecture,
such a demo would pose no risk to other users (at least not from
traffic)  --- but then I assume I am preaching to the choir.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://staff.psc.edu/mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.