Re: [re-ECN] Draft Agenda

["Woundy, Richard" <[e-mail]>]

>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: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, October 08, 2009 5:11 AM
To: Woundy, Richard
Cc: [e-mail]
Subject: RE: [re-ECN] Draft Agenda

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

> -----Original Message-----
> From: Woundy, Richard [mailto:[e-mail]]
> Sent: 07 October 2009 23:30
> To: Moncaster,T,Toby,DEE1 R; [e-mail]
> Cc: [e-mail]
> Subject: RE: [re-ECN] Draft Agenda
> 
> 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/.

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

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

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.

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

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

> 
> -- Rich
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf
> Of [e-mail]
> Sent: Wednesday, October 07, 2009 11:46 AM
> To: [e-mail]; [e-mail]
> Subject: Re: [re-ECN] Draft Agenda
> 
> 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...
> 
> 
> > -----Original Message-----
> > From: Mirja Kuehlewind
[mailto:[e-mail]]
> > Sent: 07 October 2009 16:30
> > To: [e-mail]
> > Cc: Moncaster,T,Toby,DEE1 R; [e-mail]
> > Subject: Re: [re-ECN] Draft Agenda
> >
> > Hi,
> >
> > some questions regarding the demonstration:
> >
> > > >  > 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...).
> >
> > 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....?
> 
> 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).
> 
> 
> >
> > 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).
> 
> 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.
> 
> >
> > 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.
> 
> 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
> 
> >
> > Mirja
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn