Re: [re-ECN] Draft Agenda

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

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: [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