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

[Kostas Pentikousis]

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