[e2e] Mixed ECN and Non-ECN traffic flows.
Jon.Crowcroft at cl.cam.ac.uk
Tue Oct 15 14:19:01 PDT 2002
In message <Pine.GSO.4.33.0210150140320.27315-100000 at compserv3>, Kostas Pentikousis typed:
>>On Fri, 11 Oct 2002, Chong Poh Kit wrote:
>> | I've done some simulations using a mixture of ECN and non-ECN capable TCP
>> | flows over NS-2 and I've discovered that at a bottleneck link with a single
>> | FIFO queue, ECN flows tend to grab more than their fair share of the
>> | bandwidth when an AQM (RED,BLUE) is used at the router.
>> | I believe this is due to the fact that ECN traffic needs more aggressive
>> | marking to control the rate of congestion while the non-ECN traffic suffers
>> | from the increased packet drops. Furthermore, the packet drops results in
>> | constant retransmissions and thus, a hit in the goodput of the non-ECN
>> | flows.
>>The literature (for example, Slim and Ahmed (RFC 2884), and Zhang and Qiu),
>>indicates that when TCP/ECN senders compete with ECN-unaware TCP senders (Reno
>>or SACK), the TCP/ECN ones have an advantage. *On the average*, TCP/ECN
>>senders can achieve up to 30% more goodput (according to Zhang and Qiu).
>>Intuitively, a TCP/ECN sender becomes cognizant of congestion earlier.
>>Effectively, it posses more information, which reduces the number of times
>>TCP has to guess if there is congestion or not.
>>Be that as it may, a TCP/ECN sender does not attempt to increase its
>>congestion window more aggressively than an ECN-unaware one. TCP/ECN senders
>>(see RFC 3168) do not react to congestion in a way different than any TCP post
>>Reno: a TCP/ECN sender will react to congestion incidents only once per window
>>of data. Indeed, a Reno-based TCP/ECN will be slightly more aggressive than
>>Reno, but not more than, say, SACK. In sum, TCP/ECN does not open it's window
>>faster and it doesn't reduce it by a fraction smaller than "standard" TCP.
>>Therefore, I don't see why you think that TCP/ECN flows must be "marked" more
>>Of course, any given TCP/ECN sender will, most likely, suffer fewer drops and
>>will avoid some RTOs, but this does not mean that it is bound to achieve a
>>higher goodput in the end. We found that, in a variety of scenarios, a given
>>TCP/ECN sender is not guaranteed increased goodput. This means that if you
>>enable ECN in your protocol stack, it is not so sure that you will enjoy
>>better goodput. Fewer packet drops? Yes. But this does not always translate
>>into better goodput.
>> | My opinion is that as the percentage of ECN capable end hosts increases this
>> | would pose a problem of unfairness in the future.
>>We have tried some "transitional" scenarios and found that "overall" fairness
>>improves when the number of TCP/ECN senders increases and network resources
>>are utilized more efficiently.
>>On Fri, 11 Oct 2002, Kacheong Poon wrote:
>> | Included message from "David P. Reed" <dpreed at reed.com>:
>> | >----
>> | >Seriously, though, will any major OS vendor deploy ECN this century?
>> | >----
>> | By deployment, do you mean supporting ECN in the OS? Then I
>> | know that at least Linux and Solaris both support ECN for TCP.
>>Linux kernels 2.4.x support ECN. In fact, production machines have been ECN
>>enabled for more than 18 months
>>(http://lwn.net/2001/0503/a/kernel.org-ecn.php3). And it was faulty boxes in
>>the middle that delayed deployment (http://www.aplawrence.com/Linux/ecn.html),
>>and forced developers to have the default kernel option for ECN set to OFF
>>As people in the Linux community like to say, they were too much ahead of the
>>crowd. But people reacted and things have started to straighten out
>>(http://gtf.org/garzik/ecn/). And now Cisco IOS 12.2(8)T seems to be RFC
>>Unfortunately, I have no references on Solaris support for ECN. Any pointers
>>will be appreciated.
>>On Sat, 12 Oct 2002, Chong Poh Kit wrote:
>> | On Fri, 11 Oct 2002 13:44:56 -0400, Mutlu Arpaci wrote:
>> | >In addition, for a given max_p, the performance improvement of ECN flows
>> | >increases as the number of NonECN flows increases.
>> | I found the same thing in my simulations and I think that this is due
>> | to the fact that the ECN flows are contending for bandwidth with flows
>> | that react slower to congestion and suffer multiple RTOs thus giving
>> | ECN flows opportunity to dominate the AQMs packet marking/dropping
>> | probability to favour themselves. Because of the fact that ECN traffic
>>I think instead of trying to figure out how to "restrain" TCP/ECN senders, it
>>is more interesting to investigate what happens in an all-ECN network. Do TCP
>>senders achieve better performance in such a network? If yes, which metrics
>>indicate so, and how is this achieved? Are resources shared more "fairly"? Is
>>"wasted effort" minimized?
>>Just my $0.02,
>>Kostas Pentikousis @ CS Stony Brook @ http://www.cs.sunysb.edu/~kostas
More information about the end2end-interest