Subject: [Iccrg] Draft Report - Study of Proposed Internet Congestion-Control Mechanisms
From: [email-masked] (Saverio Mascolo)
Date: Sat Sep 19 16:01:24 2009

dear kevin,

there is a lot of litearture (and results)  that you are not aware. only few
points:

1. TCP scalable does not work at all! If you try few connections (few as 3
or 4) you will get starvation of flows. This TCP cannot be used because it
does not work not because of efficiency.
2. with TCP you should consider reverse traffic, always, due to the effect
on ack, which in turns drive the TCP

saverio

On Thu, Sep 10, 2009 at 4:14 PM, Kevin Mills (comcast) <
[email-masked]> wrote:

> Dear Colleagues,
>
> On May 20, 2009, I briefed the ICCRG on NIST research related to modeling
> and analysis of large distributed systems. Recall that as a challenge
> problem we investigated several Internet congestion-control mechanisms
> proposed to replace TCP. I attach our conclusions related to the
> congestion-control algorithms that we studied. A more-or-less complete
> draft
> of the study (including our supporting data and analysis) is now available
> for public review and comments. If you have the time to look this over and
> provide feedback, then I would appreciate it. Also, feel free to distribute
> this information to others who you think might be interested.
>
> Here is the URL:
>
>
> http://www.antd.nist.gov/Measurement%20Science%20for%20Complex%20Information
> %20Systems_files/ICC-study-Draft.htm<http://www.antd.nist.gov/Measurement%20Science%20for%20Complex%20Information%0A%20Systems_files/ICC-study-Draft.htm>
>
>
> Kevin
>
> NIST
> 100 Bureau Drive Stop 8920
> Bldg. 222/B218
> Gaithersburg, MD 20899-8920
>
> Tel: (301) 975-3618
> Fax: (301) 975-6238
> email: [email-masked]
> web: http://w3.antd.nist.gov/~mills <http://w3.antd.nist.gov/%7Emills>
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked] <[email-masked]>

http://c3lab.poliba.it

=================================
This message may contain confidential and/or legally privileged information.
 If you are not the intended recipient of the message, please destroy it.
Any unauthorized dissemination, distribution, or copying of the material in
this message, and any attachments to the message, is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090919/4434e064/attachment.html
>From [email-masked]  Mon Sep 21 05:18:29 2009
From: [email-masked] (Lawrence Stewart)
Date: Mon Sep 21 05:05:20 2009
Subject: [Iccrg] Re: CUBIC congestion control module for FreeBSD
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Lisong,

Lisong Xu wrote:
> Lawrence,
> 
> Thanks for implementing CUBIC for FreeBSD! Do you have a report showing 
> the "interesting differences" between Linux CUBIC and FreeBSD CUBIC?

Not at this stage. I simply haven't had the time to digest the FreeBSD 
vs Linux differences. From the data I recall looking at (some months ago 
now mind you), the FreeBSD CUBIC was more likely to be in the TCP 
friendly region than was the Linux CUBIC. I checked the behaviour of the 
FreeBSD CUBIC code with detailed logging output, and as far as I could 
tell it was doing the right thing.

It definitely warrants further investigation, but I'm afraid I'm 
unlikely to get to it for sometime yet. If anyone is keen to take the 
lead, I would be very happy to collaborate with them to get to the 
bottom of things.

Cheers,
Lawrence

From: [email-masked] (Lisong Xu)
Date: Sat Sep 19 15:14:38 2009
Subject: [Iccrg] Re: CUBIC congestion control module for FreeBSD
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Lawrence,

Thanks for implementing CUBIC for FreeBSD! Do you have a report showing 
the "interesting differences" between Linux CUBIC and FreeBSD CUBIC?

Thanks!
Lisong

Lawrence Stewart wrote:
> Hi All,
> 
> Late last year I wrote to the list with some feedback [1] on the CUBIC 
> draft, based on my work hacking on a clean-room implementation of CUBIC 
> for FreeBSD. I recently got around to cleaning up the code and releasing 
> it after numerous distractions since that correspondence with the list. 
> I also spoke at the IETF 75 ICCRG meeting in Stockholm [2] about some of 
> this work and various thoughts/observations.
> 
> The code was developed to fully implement the algorithm specified in 
> [3], and my initial testing indicates the code is working in accordance 
> with the spec. Directly comparing the FreeBSD CUBIC dynamics to those 
> seen with Linux reveals some interesting differences, which would be 
> good to investigate further.
> 
> The FreeBSD modular congestion control framework and HTCP/CUBIC 
> congestion control modules are available as patches from [4]. The work 
> is being carried out in the main FreeBSD Subversion repository, 
> available from [5,6], which is where you can always find the latest code.
> 
> The work will be incorporated into the mainline FreeBSD source tree in 
> the not too distant future. In the meantime, I encourage people to 
> experiment with the code and other tools available from [4], and welcome 
> any feedback, comments and suggestions.
> 
> 
> Cheers,
> Lawrence
> http://caia.swin.edu.au
> 
> 
> [1] http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-October/000580.html
> 
> [2] http://www.ietf.org/proceedings/75/slides/iccrg-3.pdf
> 
> [3] http://tools.ietf.org/id/draft-rhee-tcpm-cubic-02.txt
> 
> [4] http://caia.swin.edu.au/urp/newtcp/tools.html
> 
> [5] http://svn.freebsd.org/viewvc/base/projects/tcp_cc_8.x/
> 
> [6] http://svn.freebsd.org/viewvc/base/projects/tcp_cc_7.x/

-- 
Lisong Xu, Assistant Professor
Computer Science & Engineering
University of Nebraska-Lincoln
http://cse.unl.edu/~xu

From: [email-masked] (Lawrence Stewart)
Date: Sat Sep 19 00:33:23 2009
Subject: [Iccrg] CUBIC congestion control module for FreeBSD
Message-ID: <[email-masked]>

Hi All,

Late last year I wrote to the list with some feedback [1] on the CUBIC 
draft, based on my work hacking on a clean-room implementation of CUBIC 
for FreeBSD. I recently got around to cleaning up the code and releasing 
it after numerous distractions since that correspondence with the list. 
I also spoke at the IETF 75 ICCRG meeting in Stockholm [2] about some of 
this work and various thoughts/observations.

The code was developed to fully implement the algorithm specified in 
[3], and my initial testing indicates the code is working in accordance 
with the spec. Directly comparing the FreeBSD CUBIC dynamics to those 
seen with Linux reveals some interesting differences, which would be 
good to investigate further.

The FreeBSD modular congestion control framework and HTCP/CUBIC 
congestion control modules are available as patches from [4]. The work 
is being carried out in the main FreeBSD Subversion repository, 
available from [5,6], which is where you can always find the latest code.

The work will be incorporated into the mainline FreeBSD source tree in 
the not too distant future. In the meantime, I encourage people to 
experiment with the code and other tools available from [4], and welcome 
any feedback, comments and suggestions.

Cheers,
Lawrence
http://caia.swin.edu.au

[1] http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-October/000580.html

[2] http://www.ietf.org/proceedings/75/slides/iccrg-3.pdf

[3] http://tools.ietf.org/id/draft-rhee-tcpm-cubic-02.txt

[4] http://caia.swin.edu.au/urp/newtcp/tools.html

[5] http://svn.freebsd.org/viewvc/base/projects/tcp_cc_8.x/

[6] http://svn.freebsd.org/viewvc/base/projects/tcp_cc_7.x/

From: [email-masked] (Lachlan Andrew)
Date: Sat Sep 12 22:59:38 2009
Subject: [Iccrg] Re: [e2e] What's wrong with this picture?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings David,

2009/9/12 David P. Reed <[email-masked]>:
>
>
> On 09/11/2009 05:41 PM, Lachlan Andrew wrote
>>
>> No, IP is claimed to run over a "best effort" network. ?That means
>> that the router *may* discard packets, but doesn't mean that it
>> *must*. ?If the delay is less than the IP lifetime (3 minutes?) then
>> the router is within spec (from the E2E point of view).
>
> I disagree with this paragraph. No one ever claimed that IP would run over
> *any* best efforts network. ?One could argue that routers that take pains to
> deliver packets at *any* cost (including buffering them for 10 seconds when
> the travel time over the link between points is on the order of 1
> microsecond, and the signalling rate is > 1 Megabit/sec) are not "best
> efforts" but "heroic efforts" networks.

You are right that "good" isn't one-dimensional.  I have always found
it odd that people use "best effort" to mean something less that
"trying as hard as is possible" (because best is a superlative --
nothing is better than the best).  It was only in formulating a reply
that I realised "best" could also mean "most appropriate".

Still, a quick search for "discard" in the "Requirements for Internet
Hosts" standard doesn't say that they *have* to discard packets.

Again, my main motivation for writing a provocative email was that I'm
frustrated at people saying "We're allowed to specify TCP to behave
badly on highly-buffered links, but link designers aren't failing if
they design links that behave badly with highly-aggressive E2E
protocols".

TCP congestion control was only ever intended as an emergency  hack.
It is remarkable that it has worked as well as it has, but why do we
have to keep designing networks to support the hack?  As I said in
reply to Detlef, a good TCP can make link designers lazy.  However, we
shouldn't let good links make us as TCP / E2E designers lazy.

> In any case, research topics for future networks aside, the current IP
> network was, is, and has been developed with the goal of minimizing
> buffering and queueing delay in the network. The congestion control and
> fairness mechanism developed by Van Jacobson and justified by Kelly (on game
> theoretic grounds, which actually makes a great deal of sense, because it
> punishes non-compliance to some extent) is both standardized and dependent
> on tight control loops, which means no substantial queueing delay.

The IETF may have standardised TCP, but what if the IEEE
"standardises" a reliable link protocol (like data centre ethernet),
or the ITU standardises high-reliability ATM (used by DSL modems,
which also get the blame for TCP's excessive aggressiveness)?  Should
we change their standards, or ours?  The IETF isn't the only
standards body, or even the supreme one.  If there are standards that
don't interact well, we should revisit all standards, starting with
the ones we can control.

> It's not the buffer capacity that is the problem. ?It's the lack of
> signalling congestion. And the introduction of "persistent traffic jams" in
> layer 2 elements, since the drainage rate of a queue is crucial to recovery
> time.

Perhaps it is the lack of the IETF protocol paying attention to the
congestion signals.  As I mentioned, VJ's breakthrough was realising
that TCP should listen more closely to what the network was telling
us.  Why should we not keep doing that?  When the link is screaming
with high delay, why don't we back off?

> One can dream of an entirely different network. ?But this is NOT a political
> problem where there is some weird idea that layer 2 networks offering layer
> 3 transit should have political rights to just do what they please. ?It's
> merely a matter of what actually *works*.

It is exactly a political problem, between different standards bodies.

But closer to your analogy, who gives TCP the right to send just what
it pleases?  I'm not talking about "an entirely different network",
but one which exists and on which you took measurements.  The network
has problems, caused by poor interaction between an IETF protocol and
the hardware one which it runs.  One has to change.  Why close our
eyes to the possibility of changing the protocol?

> Your paragraph sounds like the statements of what my seagoing ancestors
> called "sea-lawyers" people who make some weird interpretation of a "rule
> book" that seems to be based on the idea that the design came from "god" or
> the "king". ?Nope - the design came from figuring out what worked best.

At the risk of being repetitive, I see the same thing in reverse:  I'm
hearing "we can't change TCP to work over the current network, because
TCP is standardized, and it used to work".  I'm not saying that we
should have links with excessive buffers.  I'm not even saying that
they shouldn't unnecessarily drop packets (although it sounds odd).
I'm just saying that we should *also* be open to changing TCP to work
over the links that people build.

> Now, I welcome a fully proven research activity that works as well as the
> Internet does when operators haven't configured their layer 2 components to
> signal congestion and limit buildup of slow-to-drain queues clogged with
> packets.

Great.  I agree that my mindset is more IRTF than IETF, and so I'm
Cc'ing this to ICCRG too.

However, I'm arguing that the layer 2 links *are* signalling
congestion very strongly, if only we'll listen.

Links with slow-to-drain queues are certainly a problem if there is a
high load of traffic which doesn't have proper congestion control, but
that isn't a reason not to design proper congestion control which
doesn't fill all available buffers.

> You are welcome to develop and convince us to replace the Internet with it,
> once it *works*.

I'm not talking about replacing the internet, any more than RFC2851 /
RFC5681 replace RFC753.  I'm only suggesting that we design protocols
which work on the network that is out there, and that you measured.
If the link you mention is an isolated case, then we can simply call
it misconfigured.  However, I don't believe it is an isolated case,
and we should take responsibility for TCP's poor behaviour on such
links.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837

From: [email-masked] ([email-masked])
Date: Thu Sep 10 04:18:33 2009
Subject: [Iccrg] {SPAM?} Ganar un bono de 100 Euros con Grupo BBVA !
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090910/5af9b9cd/attachment.html
>From [email-masked]  Thu Sep 10 15:14:42 2009
From: [email-masked] (Kevin Mills (comcast))
Date: Fri Sep 11 08:12:33 2009
Subject: [Iccrg] Draft Report - Study of Proposed Internet
	Congestion-Control Mechanisms
Message-ID: <004701ca3221$0ad41060$207c3120$@net>

Dear Colleagues,

On May 20, 2009, I briefed the ICCRG on NIST research related to modeling
and analysis of large distributed systems. Recall that as a challenge
problem we investigated several Internet congestion-control mechanisms
proposed to replace TCP. I attach our conclusions related to the
congestion-control algorithms that we studied. A more-or-less complete draft
of the study (including our supporting data and analysis) is now available
for public review and comments. If you have the time to look this over and
provide feedback, then I would appreciate it. Also, feel free to distribute
this information to others who you think might be interested.

Here is the URL:

http://www.antd.nist.gov/Measurement%20Science%20for%20Complex%20Information
%20Systems_files/ICC-study-Draft.htm

Kevin

NIST
100 Bureau Drive Stop 8920
Bldg. 222/B218
Gaithersburg, MD 20899-8920

Tel: (301) 975-3618
Fax: (301) 975-6238
email: [email-masked]
web: http://w3.antd.nist.gov/~mills

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Chapter 10v2a.pdf
Type: application/pdf
Size: 88930 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090910/618bbacd/Chapter10v2a-0001.pdf
>From [email-masked]  Sat Sep 12 21:54:08 2009
From: [email-masked] (Lachlan Andrew)
Date: Sat Sep 12 21:41:13 2009
Subject: [Iccrg] Re: [e2e] What's wrong with this picture?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Greetings,

I'm glad my provocative comments stimulated a response.

I'm happy to agree that they're not a sound way to make incremental
changes to the current network, but they reflect a particular hobby
horse of mine, that the "inter" has been forgotten in the internet.

An internet is not a network, but a collection of networks.  There has
been much confusion because people think that Ethernet networks are
"link" instead of networks.  That has caused people to misinterpret
topology data and all sorts of problems.

2009/9/12 Detlef Bosau <[email-masked]>:
> Lachlan Andrew wrote:
>>
>> No, IP is claimed to run over a "best effort" network. ?That means
>
> To run? Or to hobble? ;-)

Definitely to hobble...

>> that the router *may* discard packets, but doesn't mean that it
>> *must*.
>
> This is not even a theoretical debate.
>
> A router's storage capacity is finite, hence the buffer cannot keep an
> infinite number of packets.

I never mentioned an infinite number of packets.  If links have
token-based congestion control then it is possible to have a lossless
network.  Token-based control was proposed for ATM, and is (correct me
if I'm wrong) being reintroduced for "Data Centre Ethernet".  If we
say "IP will not run over Data Centre Ethernet, because it doesn't
drop packets, therefore Data Centre Ethernet is wrong", then we are in
serious trouble.  *That* sounds like we're taking our IETF rule-book
as god-given.

Granted, Data Centre Ethernet isn't being offered as a public
"internet" service, but surely we should be looking at the issue of
TCP-over-reliable-networks.

> However, we're talking about TCP here. And TCP simply does not work properly
> without any kind of congestion control.

RFC 793 does.  The current TCP congestion control mechanism was a very
useful hack to solve an immediate problem.  Why are we so keen to
defend a 20 year old kludge?  (I know: "because it works".  But what
if there are cases where it *doesn't* work.  Why say "Those cases
shouldn't exist.  Next problem"?)

VJ's radical insight was "the network is telling us something" when it
drops a packet.  That brought about a radical improvement.  Why is it
so hard to say "the network is telling us something" when it delays
packets?  Perhaps this debate should be in the IRTF/ICCRG (Cc'd)
instead of the IETF, but

> Hence, there is a strong need to have a sender informed about a congested
> network.

Doesn't an 8-second delay inform the sender?  Of course, by the time
it has reached 8 seconds it is too late.  However, we can detect 100ms
of delay after a mere 100ms...  Delay gives *instant* per-packet
feedback, whereas loss only gives feedback every few packets (or every
few thousand packets on high BDP links).

Pure delay-based TCP has many problems, since we don't understand all
of the possible causes of delay, but delay should definitely be
considered as information.

>> If the delay is less than the IP lifetime (3 minutes?) then
>> the router is within spec (from the E2E point of view).
>
> I don't know a router who checks a packet's lifetime with the clock,
> although some stone-aged specification proposes a temporal interpretation of
> lifetime ;-) Practically, in IPv4 the lifetime is a maximum hop count. In
> IPv6, this is even through for the specs.

I'm not talking about TTL.  I'm talking about the maximum segment
lifetime (MSL), which, as recently as 2008
(draft-touch-intarea-ipv4-unique-id-00.txt) was "typically interpreted
as two minutes".

>> No, it is not "WRONG" to claim a high bit-rate service is high-speed,
>> even if it has high latency.
>
> Do we talk about rates? Or do we talk about delays? Or do we talk
> about service times?

"speed" = "rate".  A concord is fast, even if I have to book my ticket
a day in advance.

> In packet switching networks, we generally talk about service times and
> nothing else.
> Any kind of "rate" or "throughput" is a derived quantity.

True, but it is the derived quantity which was being advertised.  The
service was not being advertised as a low-delay service, but as a
high-speed service.

I'm not trying to defend a service which has these appalling delays;
just to get us out of the mindset that they're doing something "wrong"
as distinct from "stupid".

>> ?High-speed is not equivalent to low-delay.
>
> However, a high speed network will necessarily have small service times.

Yes, but not small latency.  See the concord example.

>>> The entire congestion control mechanism (and approximate fairness
> From the days, when VJ wrote the congavoid paper, up to now TCP works fine
> about congested reliable networks ;-)
> (What, if not "reliable", are wirebound links?)

Wirebound IP links are "best effort", not "reliable".  "Reliable"
(when applied to a protocol) means that it guarantees to deliver each
packet exactly once.  That is what is meant by RFC 3366's "TCP
provides a reliable byte-stream transport service, building upon the
best-effort datagram delivery service provided by the Internet
Protocol"  It has nothing to do with whether we can actually rely on
the protocol to get the job done usefully...

> Dave's problem arises from unreliable networks (yes, I intendedly use a
> somewhat strange definition of reliability here ;-)), i.e. from wireless
> ones.

No, it is a "reliable" network running over an unreliable physical
link.  The problem is that it tries too hard to be reliable.

>> ?There are many methods
>> which use delay as an indicator of congestion, as well as using loss.
>> ?(Should I plug Steven Low's FAST here?) ?We don't need anything very
>> fine-tuned in a case like this; just something very basic.
>
> delay is one of the worst indicators for network congestion one could
> even imagine.

Oh?  In that case, why are we assuming that this 8-second delay was
caused by congestion?

I'm not saying we should *only* consider delay, but that the problem
here is that TCP is *ignoring* delay, like RFC793 ignored loss.

> there is usually no
> reference delay which is related to a "sane" network.

True, that is a challenge, but we know that these delays are not sane,
and should define appropriate responses.

> The really problem with delay and delay variations is, that there are
> several possible causes for them:
> - congestion.
> - MAC latencies. (similar to congestion.)
> - high recovery latencies due to large numbers of retransmissions.
> - route changes.
> - changes in path properties / line coding / channel coding / puncturing
> etc.
>
> Without any particular knowledge of the path, you may not be able to
> determine "the one" (if it is one at all) reason for a delay variation.

Similarly, we don't know that "the one" reason for a packet loss is
congestion.  However, we can use the available information.  Take a
look at Doug Leith's recent work on debunking the myths about why we
can't use delay for congestion estimation.

> So, the consequence is that we should abandon the use of delays as
> congestion indicator.

No, we shouldn't rely on delay as the only source of information.  I
don't see why we should ever decide a priori to ignore information.

> The original meaning of "congestion" is that a path is full and cannot
> accept more data.
> And the by far most compelling indication for "this path cannot accept mor
> data" is that this "more data" is discarded.

True, it is compelling.  However, it isn't the only indication.  I'm
not saying that we should reject loss as an indicator of congestion.
I'm just saying that we shouldn't ignore other indicators.

>> Of course, fixing TCP to work over any IP connection (as it was
>> intended) does not mean that the underlying networks should not be
>> optimised. ?As Lloyd said, we already have recommendations.
>
> And we have the end-to-end recommendations which tell us, that underlying
> networks should not attempt to solve all problems on their own.

"Be liberal in what you accept, and conservative in what you send" (RFC1122).

Once again, I'm not saying that the link layer is good.  I'm just
saying that we should be open to improving TCP to make it accept that
there are bad links.

Of course, a valid argument against making TCP robust to bad links is
that it hides the badness of those links and makes link-designers
lazy.  However, I'm not going to argue against Moore's law just
because it makes programmers lazy.

Cheers,
Lachlan

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837

From: [email-masked] (Bob Briscoe)
Date: Fri Sep  4 18:48:08 2009
Subject: [Iccrg] Fwd: Pls respond: Do we have a Congestion Exposure community?
Message-ID: <[email-masked]>

Folks,

Apologies if you've seen this posting elsewhere. Pls don't reply on this list.

The posting below asks anyone interested in activity around a 
congestion exposure (re-ECN) BoF (or anyone who wants to say 
something supportive or damning) to declare their interest on the 
[email-masked] list.

List joining instructions are here:
<https://www1.ietf.org/mailman/listinfo/re-ecn>
But if you're not a member, the moderator will allow your post.

Cheers

Bob

>Date: Wed, 02 Sep 2009 17:33:36 +0100
>To: [email-masked]
>From: Bob Briscoe <[email-masked]>
>Subject: Pls respond: Do we have a Congestion Exposure community?
>
>Folks,
>
>I'd like to try to arrange a Congestion Exposure (re-ECN) BoF in Nov 
>at the Hiroshima IETF. If so, we have to notify the area directors v 
>soon - by 24:00 UTC Mon 7 Sep 09. #1 gating function for Area 
>Directors: activity on an ietf list.
>
>Therefore, pls respond preferably *on this list* if you're 
>interested in being involved, no matter how insignificantly, e.g.
>
>- you want congestion visibility for other stuff you're doing
>   (but don't intend to work on it itself)
>- reviewing docs,
>- alternative way to achieve congestion exposure
>- participate in mailing list discussion,
>- co-authoring docs
>- design ways to do incremental deployment
>- using code for other stuff you're doing
>- thinking up new uses for the protocol
>- breaking it
>- analysing benefits/costs
>- implement protocol
>- implement a demo
>- running or participating in trials
>- standing on the sidelines booing or clapping
>- whatever
>
>Perceived problem:
>Most people want to work on something finite like a new cool 
>non-TCP-friendly congestion control. Less people want to go into an 
>pseudo-infinite loop fixing IP to allow other cool stuff to happen. 
>If you want something like re-ECN to be there, but don't have the 
>bandwidth to work on it, that's cool too - please say this - it's 
>still palpable support. And you will be likely to have review 
>comments related to how you want to use it.
>
>Cheers
>
>
>Bob
>
>________________________________________________________________
>Bob Briscoe,               Networks Research Centre, BT Research

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research