[e2e] Mixed ECN and Non-ECN traffic flows.

[Jon Crowcroft]

content analysis


now multicast?
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
 >>aggressively.
 >>
 >>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
 >>(http://lists.debian.org/debian-devel/2001/debian-devel-200109/msg00082.html).
 >>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
 >>3168-compliant
 >>(http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ftwrdecn.htm)
 >>
 >>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
 >>______________________________________________________________________
 >>Kostas Pentikousis @ CS Stony Brook @ http://www.cs.sunysb.edu/~kostas
 >>
 >>
 >>
 >>
 >>
 >>

 cheers

   jon