Re: [re-ECN] Draft Agenda

[<[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Woundy, Richard
Sent: 08 October 2009 20:10
To: Moncaster,T,Toby,DEE1 R
Cc: [e-mail]
Subject: Re: [re-ECN] Draft Agenda

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

-- Rich 

-----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
_______________________________________________
re-ECN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/re-ecn