Subject: [tcpm] ECN feedback discussion

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 7 Nov 2012 13:10:21 +0000

Hi,

I just wanted to keep a record of these interesting remarks on the list, for further discussion.

We discussed ECN both in TCPM and ICCRG, and this post is to start the discussion on the working group lists.

During the TCPM session, Matt Mathis made an interesting remark on the microphone. To paraphrase (my understanding), current marking schemes (RED, CoDel, PIE,...) assume that ECN marks get treated like loss by the end systems.  Therefore, they employ a "low density" marking scheme, with marks expected at an (average) rate of around 3% or so at maximum.

Alternative schemes, that start getting deployed at this time, have very simple marking schemes in the network, and give more information to the end systems for processing and reaction there. As a side effect, these newer schemes may run as high as 100% marking for certain periods (longer than a single flows RTT), so they could be classified as "high density" marking scheme.

Later on, Bob noted, that since ECN Nonce is virtually nonexistent (I know only one stack with partial support), why not re-define ECT(1) to be used by high density marking schemes, keeping ECT(0) for low density schemes (as deployed today). For newer stacks, this would allow an even more fine grained reaction to ECN marking levels...

However, ECN security aspects (Nonce) and legacy uses (ECT(1) has the same meaning for existing ECN stacks as ECT(0)) would not be addressed, but then again, current ECN is also virtually not deployed, according to recent studies.

Of course, such a shift in the semantics of ECT(0) vs ECT(1) would also need to have an impact on the future signaling  / feedback scheme used for TCP (DCCP and SCTP would be able to cope already, afaik).

Best regards,

Richard Scheffenegger

---

From: Michael Welzl <[email-masked]>
Date: Wed, 7 Nov 2012 14:14:06 +0100

Great idea, I'd love for this semantic shift to happen!

On Nov 7, 2012, at 2:10 PM, Scheffenegger, Richard wrote:

> We discussed ECN both in TCPM and ICCRG, and this post is to start  
> the discussion on the working group lists.
>
> During the TCPM session, Matt Mathis made an interesting remark on  
> the microphone. To paraphrase (my understanding), current marking  
> schemes (RED, CoDel, PIE,…) assume that ECN marks get treated like  
> loss by the end systems.  Therefore, they employ a “low density”  
> marking scheme, with marks expected at an (average) rate of around  
> 3% or so at maximum.
>
> Alternative schemes, that start getting deployed at this time, have  
> very simple marking schemes in the network, and give more  
> information to the end systems for processing and reaction there. As  
> a side effect, these newer schemes may run as high as 100% marking  
> for certain periods (longer than a single flows RTT), so they could  
> be classified as “high density” marking scheme.
>
>
> Later on, Bob noted, that since ECN Nonce is virtually nonexistent  
> (I know only one stack with partial support), why not re-define  
> ECT(1) to be used by high density marking schemes, keeping ECT(0)  
> for low density schemes (as deployed today). For newer stacks, this  
> would allow an even more fine grained reaction to ECN marking levels…
>
> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has  
> the same meaning for existing ECN stacks as ECT(0)) would not be  
> addressed, but then again, current ECN is also virtually not  
> deployed, according to recent studies.
>
> Of course, such a shift in the semantics of ECT(0) vs ECT(1) would  
> also need to have an impact on the future signaling  / feedback  
> scheme used for TCP (DCCP and SCTP would be able to cope already,  
> afaik).
>
> Best regards,
>
> Richard Scheffenegger
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: John Leslie <[email-masked]>
Date: Wed, 7 Nov 2012 12:59:18 -0500

Scheffenegger, Richard <[email-masked]> wrote:
> 
> During the TCPM session, Matt Mathis made an interesting remark on the
> microphone. To paraphrase (my understanding), current marking schemes
> (RED, CoDel, PIE,...) assume that ECN marks get treated like loss by
> the end systems. Therefore, they employ a "low density" marking scheme,
> with marks expected at an (average) rate of around 3% or so at maximum.

   Actually, 3% loss is pretty bad, and 3% ECN-marking would be very much
worth avoiding. Nonetheless, "low-density" can rise that high without
seriously damaging the transport.

> very simple marking schemes in the network, and give more information
> to the end systems for processing and reaction there. As a side effect,
> these newer schemes may run as high as 100% marking for certain periods
> (longer than a single flows RTT), so they could be classified as
> "high density" marking scheme.

   DCTCP fits this model. Alas, I don't think we all understand it...

> (I know only one stack with partial support), why not re-define ECT(1)
> to be used by high density marking schemes, keeping ECT(0) for low
> density schemes (as deployed today).

   This would have been a much better initial design!

> For newer stacks, this would allow an even more fine grained reaction
> to ECN marking levels...

   With 100% deployment, yes...

> However, ECN security aspects (Nonce) and legacy uses (ECT(1) has the
> same meaning for existing ECN stacks as ECT(0)) would not be addressed,

   It might be possible to define a protocol for sender and receiver to
agree to treat ECT(1) this way; but I'm not optimistic about adoption.
It should be workable for research, though...

> but then again, current ECN is also virtually not deployed, according
> to recent studies.

   There's quite a bit of "deployed but disabled" AFAICT.

> also need to have an impact on the future signaling  / feedback scheme
> used for TCP (DCCP and SCTP would be able to cope already, afaik).

   I believe SCTP could, with near-trivial changes, get both ends to
agree on this difference for ECT(1). I'm not familiar enough with DCCP
to say for sure, but at first blush it appears there are enough
reserved bits to adapt. (It looks non-trivial, though.)

   Looking ahead, I doubt that two flavors of ECN will be sufficient
for all needs. Getting beyond one flavor is _very_ much worth doing;
but I think we need a final target of at least eight flavors.

--
John Leslie <[email-masked]>

---

From: [email-masked]
Date: Thu, 8 Nov 2012 12:30:24 -0000

I'm also really interested in doing better than current ECN.

ECN Nonce behaviour using ECT(1) was defined in RFC 3168, and the reaction
is defined in the (still) experimental RFC 3540.

The ECN nonce can detect remarking NON-ECT packets to ECT and can also
detect misbehaving transport receivers hiding CE from the transport
sender. My own opinion is that if we do see more deployment of ECN (I do
hope so) - we do need this sort of mechanism, not to verify every segment,
but at least to be able to detect paths/endpoints where the ACK
information is simply invalid.

DCCP was mentioned in the thread, RFC 4340, took the view that ECN nonce
needed to be supported and the ECN Nonce Echo field is encoded in
acknowledgement options.  "Each DCCP sender SHOULD set ECN Nonces on its
packets and remember which packets had nonces."

Gorry

P.S. Also note, if we do get to plans for new use of ECN this is likely to
be a TSVWG item - since it effects much more than TCP.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 8 Nov 2012 13:59:09 +0100

... but the nonce could still be used, somehow - it's just that you  
risk more queue growth with every ECT(0) packet.

So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s  
and ECT(1)'s. In doing so, you risk some more queue growth - but this  
tests the receiver and might be good enough in the long run, as the  
notion is to stop believing the receiver once the receiver was found  
to cheat.

Cheers,
Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 8 Nov 2012 13:08:03 +0000

Hi Michael,

If both ect1 and ce signify some kind of congestion, having the sender "probe" ect1 is a noisy business (in the sense that there is no guarantee that the ect1 from the sender makes it all the way to the receiver. Hypothetically, the first part of the path might "eat" ect1 
And the 2nd half expirience congestion...

(probing would mask true marks always. A mechanism to probabilistically test this is still possible)

Rgds
    Richard

Von meinem iPhone gesendet

Am 08.11.2012 um 07:59 schrieb "Michael Welzl" <[email-masked]>:

> ... but the nonce could still be used, somehow - it's just that you risk more queue growth with every ECT(0) packet.
> 
> So you could mostly use ECT(1)'s, but occasionally, use both ECT(0)'s and ECT(1)'s. In doing so, you risk some more queue growth - but this tests the receiver and might be good enough in the long run, as the notion is to stop believing the receiver once the receiver was found to cheat.
> 
> Cheers,
> Michael
> 
>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 8 Nov 2012 14:22:08 +0100

Ah,

Sorry, I had misunderstood Bob's proposal. My interpretation was:
ECT1 tells routers to apply a high density marking scheme.

Yes this leads to unexpected behavior for current ECN-capable end  
systems, but given that nobody (except for you!  :-)))   )   uses ECN,  
maybe we can just update that behavior and not worry about this  
problem much?

To have a better basis for such a decision, it could be useful to look  
at some data from the backbone, or from popular servers, on how many  
packets arrive with ECT0 or ECT1 set. We should agree to not worry  
about it if the value is below a certain percentage   :-)

Cheers,
Michael

On Nov 8, 2012, at 2:08 PM, Scheffenegger, Richard wrote:

> Hi Michael,
>
> If both ect1 and ce signify some kind of congestion, having the  
> sender "probe" ect1 is a noisy business (in the sense that there is  
> no guarantee that the ect1 from the sender makes it all the way to  
> the receiver. Hypothetically, the first part of the path might "eat"  
> ect1
> (probing would mask true marks always. A mechanism to  
> probabilistically test this is still possible)
>
> Rgds
>    Richard
>
>> So you could mostly use ECT(1)'s, but occasionally, use both  
>> ECT(0)'s and ECT(1)'s. In doing so, you risk some more queue growth  
>> - but this tests the receiver and might be good enough in the long  
>> run, as the notion is to stop believing the receiver once the  
>> receiver was found to cheat.
>>
>> Cheers,
>> Michael
>>
>>

---

From: Michael Welzl <[email-masked]>
Date: Thu, 8 Nov 2012 15:05:33 +0100

On Nov 8, 2012, at 2:50 PM, Steve Bauer wrote:

>> To have a better basis for such a decision, it could be useful to  
>> look at some data from the backbone, or from popular servers, on  
>> how many packets arrive with ECT0 or ECT1 set.
>
> In our IMC 2011 paper,
>
> Measuring the State of ECN Readiness in Servers, Clients, and Routers
> http://rbeverly.net/research/papers/ecn-imc11.pdf
>
> We reported that "Across all of our data sets, we see no instances of
> ECN nonce support. Manual inspection of arriving packets with ECT1 set
> reveals that these ﬂows always set ECT1, even when ECN is not
> negotiated by TCP."

I have read this paper, and also had it open while I wrote my previous  
email  :-)   but I managed to miss that statement.

> So any packets with ECT1 set are evidence of something broken along  
> the path.

Well... up to now, it is. I don't see how what you describe would  
limit us to not have a sender set ECT1?
It would break the nonce interpretation though. Tricky. But should we  
design for such equipment faults? A quick look at your paper doesn't  
reveal how often you saw that; maybe I'm missing it again...

Another thought: in my previous email, addressing Richard, I wrote:
"Yes this leads to unexpected behavior for current ECN-capable end  
systems, but given that nobody (except for you!  :-)))   )   uses ECN,  
maybe we can just update that behavior and not worry about this  
problem much?"

- this made me think: Richard would certainly not run an old kernel.
=> given that ECN is probably not on by default in any system, isn't  
it fair to assume that folks who'd turn it on would run an up-to-date  
system?

Sure, lots of assumptions, but we're talking of blowing life into a  
dead corpse here! You can't do that without doing ugly stuff, such as  
having a zombie bite it...

Cheers,
Michael

---

From: [email-masked]
Date: Thu, 8 Nov 2012 14:06:44 -0000

Yes - and I plan to write an I-D on this, because I think we could perhaps
move forward with this discussion in parallel with the more accurate ECN.

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Thu, 8 Nov 2012 15:11:56 +0100

If your plan is to, in doing so, update RFC3540, I'd love to be a part  
of it. If the ECN nonce is used, it's a low hanging fruit to also use  
it to sometimes detect spurious loss events:
http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html

I have been thinking of writing a draft that updates RFC3540 to  
incorporate this for many years now, but never seriously pursued it  
because I thought it would be best to wait until Bob Briscoe is done  
with all his bit thievery. But he will never stop, will he?  :-)

So, if possible, I'd love to be a part of this.

Cheers,
Michael

---

From: [email-masked]
Date: Thu, 8 Nov 2012 14:19:47 -0000

Let's talk. I already have some text and we could maybe make a strawman
quickly -if nothing more, this may help understand the background for
quick moving forward with more accurate ECN...

Gorry

---

From: Steve Bauer <[email-masked]>
Date: Thu, 8 Nov 2012 08:50:52 -0500

> To have a better basis for such a decision, it could be useful to look at some data from the backbone, or from popular servers, on how many packets arrive with ECT0 or ECT1 set.

In our IMC 2011 paper,

So any packets with ECT1 set are evidence of something broken along the path.

Steven Bauer
MIT

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 8 Nov 2012 16:10:38 -0500

Playing devil's advocate: what's the goal of advanced ECN feedback?
what and whose problems are we solving?

My worries are that we can design fancier stuff, in the end if it does
not matter for applications, it does not matter. Is today's basic ECN
not being used b/c it's too basic?

---

From: Michael Welzl <[email-masked]>
Date: Thu, 8 Nov 2012 17:43:46 -0500

We wanna have less delay, dude!

Sent from my iPhone

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 9 Nov 2012 05:49:48 +0100 (CET)

> not being used b/c it's too basic?

I'd imagine ECN isn't used today because nobody knows what it is and why 
it's good to use. It's like IPv6, it doesn't really solve anything for the 
individual entitiy (ISP|user|equipment vendor), but as a whole, it would 
be good if we had it.

I would also venture to say that congestion used to happen in the core and 
distribution. This is not really the case anymore, now congestion happens 
much closer to the edge, which is also the place where there is least 
homogenous control and thus harder to coordinate any technology.

I have been running with ECN on, on most my machines for years now, just 
to make sure it doesn't break anything. When it was first implemented in 
the Linux kernel, ECN broke a lot of things. PIX firewalls for instance, 
dropped ECN packets. This is not the case anymore as far as I can tell, I 
haven't noticed any ECN related problem at all since I re-enabled it, hm, 
3-4 years ago perhaps.

To get ECN (and other more advanced tech) into production networks, we 
need to be able to explain to users and manufacturers (and ISPs) what good 
it does, and how it can make their life metter. From the bufferbloat 
discussion, I'd say this is quite hard, since most don't even know how TCP 
works in conjunction with large buffers, much less the difference between 
different TCP algorithms. So teaching about benefits of ECN is quite 
hard.

ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly) 
because IPv4 ran out. Nothing happened really for 5-10 years because IPv6 
didn't really solve any problem people thought they had. ECN is the same 
thing. ECN makes the network more efficient, in that it doesn't drop the 
packet if there is congestion. But how does that help the individual end 
user? That's harder to explain.

Sorry for not being able to give any constructive suggestions on how to 
solve the problem of lack of ECN support, but if we can get some consensus 
about why ECN hasn't been implemented, perhaps that helps us making future 
decisions?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 9 Nov 2012 09:32:56 +0100

> I have been thinking of writing a draft that updates RFC3540 
> to incorporate this for many years now, but never seriously 
> pursued it because I thought it would be best to wait until 
> Bob Briscoe is done with all his bit thievery. But he will 
> never stop, will he?  :-)

While I really enjoy the technical ideas in this discussion, I am somehow concerned about the tone here... I think the community must really understand that *burglary* is not at all an appropriate approach for getting the beloved bits in the TCP header. Instead, quite obviously, the right thing to do is bribery of the TCPM chairs ;)

Michael

---

From: Emmanuel Lochin <[email-masked]>
Date: Fri, 9 Nov 2012 11:27:05 +0100

Hi all,

I wish to come back on the discussion concerning a "more accurate ECN
feedback".
I utterly support the following draft
draft-kuehlewind-tcpm-accurate-ecn-option and the idea that this binary
signal is not enough to clearly take an optimal decision concerning the
sending rate.

Two years ago, we drove a study to illustrate that the use of a simple ECN
counter might open the door to several schemes and methods allowing to
better assess the level of congestion and thus, react to losses in a
consistent way. See : Diana, Rémi and Lochin, Emmanuel *ECN verbose mode: a
statistical method for network path congestion estimation.* (2011) Computer
Networks, vol. 55 (n° 10). pp. 2380-2391. ISSN 1389-1286 available here :
http://oatao.univ-toulouse.fr/4779/

Enhancing ECN feedback would greatly help us to collect statistical
information in order to optimize the TCP reaction to this signal.

Emmanuel

On 9 November 2012 09:32, Scharf, Michael (Michael) <
[email-masked]> wrote:

> While I really enjoy the technical ideas in this discussion, I am somehow
> concerned about the tone here... I think the community must really
> understand that *burglary* is not at all an appropriate approach for
> getting the beloved bits in the TCP header. Instead, quite obviously, the
> right thing to do is bribery of the TCPM chairs ;)
>
> Michael

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 9 Nov 2012 10:06:08 -0500

On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson <[email-masked]> wrote:
>> My worries are that we can design fancier stuff, in the end if it does not
>> matter for applications, it does not matter. Is today's basic ECN not being
>> used b/c it's too basic?
>
>
> individual entitiy (ISP|user|equipment vendor), but as a whole, it would be
> good if we had it.
>
> I have been running with ECN on, on most my machines for years now, just to
> make sure it doesn't break anything. When it was first implemented in the
> Linux kernel, ECN broke a lot of things. PIX firewalls for instance, dropped
> ECN packets. This is not the case anymore as far as I can tell, I haven't
> noticed any ECN related problem at all since I re-enabled it, hm, 3-4 years
> ago perhaps.
>
> To get ECN (and other more advanced tech) into production networks, we need
> to be able to explain to users and manufacturers (and ISPs) what good it
> does, and how it can make their life metter. From the bufferbloat
> different TCP algorithms. So teaching about benefits of ECN is quite hard.
>
+1

ECN has many good things but it's not used. If we are going to develop
a "useful" ECN+ maybe we should ask why the operators don't use ECN.
And I know many ops guy that know extremely well about TCP so maybe
they have valid reasons.

Thanks.

---

From: Michael Welzl <[email-masked]>
Date: Fri, 9 Nov 2012 16:11:08 +0100

> And I know many ops guy that know extremely well about TCP so maybe

Chicken-egg, I suppose: why support something that noone uses?

Cheers,
Michael

---

From: Emmanuel Lochin <[email-masked]>
Date: Fri, 9 Nov 2012 17:54:31 +0100

Sorry but "none" means TCP? Because I use ECN (I take my network
engineer hat). And I am not the only one ... at least all my
sys/network admin colleagues are using it too. I use it to take QoS
decisions and to collect statistics on my network (the rationale of
using a counter comes from this observation).

Ok, ECN might be not used inside the whole network but who cares? All
my core devices are ECN compliant so why not using inside my own
network?
We know, following "The power of explicit congestion notification", A.
Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings
out benefit for the end-user. My GNU/Linux stack does not react to
ECN? Not a problem ... my access network does.

On my side, I use specific mechanisms conjointly with ECN inherited
from the QoS epoch. For instance, I can shape ECN feedbacks to slow
down connexions or to give a delay penalty to a specific flow.
Basically I use ECN like an "alert".

The problem is that we do not propose the right tools to operate with
ECN. ECN* was an attempt, Re-ECN is also a good example of a practical
usage of ECN.

Emmanuel

On 9 November 2012 16:11, Michael Welzl <[email-masked]> wrote:
>>>> not
>>> be
>>> to
>>> need

---

From: Michael Welzl <[email-masked]>
Date: Fri, 9 Nov 2012 18:02:31 +0100

Hi,

Yes I meant TCP. Sorry if my message got across as meaning "ECN is  
useless". This is certainly not what I was trying to say: my point is,  
we're perhaps facing a chicken-egg problem where operators won't have  
much incentive to support ECN as they probably don't see many ECN- 
capable packets in their path.

I'm all for changing that!

 From anecdotal evidence (including yours, based on the email below!)  
as well as the IMC'11 paper:
Measuring the State of ECN Readiness in Servers, Clients, and Routers
http://rbeverly.net/research/papers/ecn-imc11.pdf

it seems to me that turning on ECN support in general won't cause you  
harm (although it's apparently common to have it disabled somewhere  
along the path). I think this was perhaps different in the past.

Cheers,
Michael

On Nov 9, 2012, at 5:54 PM, Emmanuel Lochin wrote:

>>> On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson <[email-masked] 
>>> >
>>> wrote:
>>>>
>>>>> matter for applications, it does not matter. Is today's basic  
>>>>> ECN not
>>>>> being
>>>>> used b/c it's too basic?
>>>>
>>>>
>>>>
>>>> it's good to use. It's like IPv6, it doesn't really solve  
>>>> anything for
>>>> the
>>>> I would also venture to say that congestion used to happen in the  
>>>> core
>>>> and
>>>> Linux kernel, ECN broke a lot of things. PIX firewalls for  
>>>> instance,
>>>> dropped
>>>> noticed any ECN related problem at all since I re-enabled it, hm,  
>>>> 3-4
>>>> years
>>>> ago perhaps.
>>>>
>>>> discussion, I'd say this is quite hard, since most don't even  
>>>> know how
>>>> TCP

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 9 Nov 2012 18:56:49 +0100 (CET)

> my core devices are ECN compliant so why not using inside my own

What core devices are that? When I last looked at platforms such as Cisco 
CRS-1 / ASR9k, Juniper MX/P-series, Huawei 5000, none of them supported 
ECN. This was a few years ago, so I'd be happy to be enlightened about 
progress! The only platform I have encountered so far that does ECN are 
Cisco processor based platforms such as the 7200.

> ECN? Not a problem ... my access network does.

What devices are those?

> Basically I use ECN like an "alert".

But how many flows do you have that are ECN enabled? What host systems 
uses ECN by default?

I have this on my linux boxes:

$ grep -i ecn /etc/sysctl.conf
net.ipv4.tcp_ecn = 1
net.ipv6.tcp_ecn = 1

(I believe the ipv6 line is redundant, just put it in there to be future 
proof). I do not believe this is the standard setting? Please correct me 
if I'm wrong.

---

From: Emmanuel Lochin <[email-masked]>
Date: Fri, 9 Nov 2012 20:00:07 +0100

On 9 November 2012 18:56, Mikael Abrahamsson <[email-masked]> wrote:
> CRS-1 / ASR9k, Juniper MX/P-series, Huawei 5000, none of them supported ECN.
> This was a few years ago, so I'd be happy to be enlightened about progress!
> The only platform I have encountered so far that does ECN are Cisco
> processor based platforms such as the 7200.

Hi Mikael

Well ... I should precise that I use only GNU/Linux or *BSD. For ECN
marking I use tc on GNU/Linux.

>> ECN? Not a problem ... my access network does.

All my routers are Linux or BSD boxes (HP Proliant blades or simple
PC), obvioulsy I need to tune both BSD or Linux kernels to be able to
correctly manage the trafic.

> But how many flows do you have that are ECN enabled? What host systems uses
> ECN by default?

All are GNU/Linux boxes except some *BSD. Most of them are used by
students/researchers that access to simulation servers or educational
ressources.
All my network is ECN-enabled. I have also used to enable an ECN path
over a link between Reunion Island university and Paris
VI university in 2004 and paced the traffic following the marking with
a penalty box.

> proof). I do not believe this is the standard setting? Please correct me if
> I'm wrong.

This is the standard setting. Today kernels enable CUBIC and ECN. But
as far as I know, CUBIC does not react to ECN.

Manu

---

From: Rick Jones <[email-masked]>
Date: Fri, 09 Nov 2012 12:53:58 -0800

> as far as I know, CUBIC does not react to ECN.

It may not be "today's" Linux kernel, but I think the default setting 
for TCP's use of ECN is "Accept, but do not initiate"

ubuntu@server-1351900909-az-3-region-a-geo-1:~$ sudo sysctl -a | grep ecn
net.ipv4.tcp_ecn = 2
ubuntu@server-1351900909-az-3-region-a-geo-1:~$ uname -a
Linux server-1351900909-az-3-region-a-geo-1 3.2.0-23-virtual #36-Ubuntu 
SMP Tue Apr 10 22:29:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Actually, I can get close to what I suppose in essence is "today's" 
linux kernel, at least as far as linux networking is concerned - a 
kernel from a davem net-next tree pulled somewhat recently (within the 
last week or so):

raj@tardy-ubuntu-1204:~$ sudo sysctl -a | grep ecn
error: permission denied on key 'net.ipv4.route.flush'
net.ipv4.tcp_ecn = 2
raj@tardy-ubuntu-1204:~$ uname -a
Linux tardy-ubuntu-1204 3.7.0-rc1+ #4 SMP Sat Nov 3 13:12:18 PDT 2012 
x86_64 x86_64 x86_64 GNU/Linux

Here is the description from Documentation/networking/ip-sysctl.txt in 
that net-next tree:

tcp_ecn - INTEGER
         Enable Explicit Congestion Notification (ECN) in TCP. ECN is only
         used when both ends of the TCP flow support it. It is useful to
         avoid losses due to congestion (when the bottleneck router supports
         ECN).
         Possible values are:
                 0 disable ECN
                 1 ECN enabled
                 2 Only server-side ECN enabled. If the other end does
                   not support ECN, behavior is like with ECN disabled.
         Default: 2

I suppose that could be worded a bit more explicitly though.

happy benchmarking,

rick jones