Re: [re-ECN] Draft Agenda

[<[e-mail]>]

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