Re: [re-ECN] Draft Agenda

[<[e-mail]>]

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