January 1998 Addendum to "ECN and defenses against evil applications":
Sally Floyd

Assume that we have agreed that mechanisms are needed in the network to
deter both ECN-capable and non-ECN-capable applications and transports
from not deploying end-to-end congestion control.  A separate question
is whether ECN would make it either easier or significantly more
attractive for applications to bypass end-to-end congestion control in
the absence of such mechanisms.  That is, should the deployment of ECN
in the Internet be delayed until mechanisms are in place in the network
to deter applications and transports from not deploying end-to-end
congestion control?  I would claim not.  In particular, I would contend
the following:


(1) ECN would not make it easier for TCP applications to disable
end-to-end congestion control.

For many people, it would be easy now to modify a TCP implementation to
disable the end-to-end congestion control.  The exact same procedure
would be required to disable the end-to-end congestion control of an
ECN-capable TCP implementation.  For the casual user, it would
be difficult to modify either an ECN-capable or a non-ECN-capable
TCP implementation.


(2) In the absence of mechanisms in the network to encourage end-to-end
congestion control, ECN would make it slightly more attractive 
for TCP applications to disable end-to-end congestion control.

Consider the performance of the following four TCP implementations:
"Good non-ECN": Non-ECN-capable, with end-to-end congestion control.  
"Bad non-ECN": Non-ECN-capable, without end-to-end congestion control.  
"Good ECN": ECN-capable, with end-to-end congestion control.  
"Bad ECN": ECN-capable, without end-to-end congestion control.  

The performance differences between "Good ECN" and "Good non-ECN" TCP
is small in terms of long-term bandwidth, for TCP implementations such
as NewReno or SACK that do not have performance problems with multiple
packets dropped from a window of data.  The main performance difference
is in terms of the end-to-end delay for individual packets, and in the
overall time to transmit a small file that encounters congestion.

However, the performance differences between "Good non-ECN" and "Bad
non-ECN" TCP can be dramatic.  In an environment of mild congestion,
the "Bad non-ECN" TCP will receive much more bandwidth than the "Good
non-ECN" TCP.  If the "Bad non-ECN" TCP drives the network to a state
of high congestion, then this reduces the benefit to the "Bad non-ECN"
TCP of having disabled end-to-end congestion control.

The performance differences between "Good ECN" and "Bad ECN" TCP can be
similarly dramatic.  In an environment of mild congestion, the "Bad
ECN" TCP will receive much more bandwidth than the "Good ECN" TCP.   If
the "Bad ECN" TCP drives the network to a state of high congestion, the
network routers will begin to drop packets instead of marking the ECN
bit, and the performance of the ECN TCPs will be identical to that of
the non-ECN TCPs.

The summary is that in a high-congestion environment, such as would
result if a significant number of flows were evading end-to-end
congestion control, the performance results of evading end-to-end
congestion control are exactly the same for "ECN" and "non-ECN" TCPs.

In an environment of mild congestion control, in the absence of
mechanisms in the network to encourage end-to-end congestion control,
either an "ECN" or a "non-ECN" TCP could receive considerable benefit
from evading end-to-end congestion control.  However, an "ECN" TCP
would receive a slightly higher benefit, in that it would not have to
retransmit the small fraction of packets that would be dropped for the
"non-ECN" TCP.

However, users do not necessarily have the option of evading end-to-end
congestion control and still remaining in an environment of mild
congestion.  Congestion is only likely to remain mild in the presence
of a non-cooperating TCP when that is the only TCP evading end-to-end
congestion control along that path, and when the receiver's advertised
window is not too large for the available bandwidth of the end-to-end
path.


(3) ECN would not make it easier for UDP applications to disable
or fail to deploy end-to-end congestion control.

It is easy and even common now for UDP applications to fail to 
deploy end-to-end congestion control.  The difference between
an ECN UDP application and a non-ECN application is that in times
of mild congestion, the ECN UDP application will not have its 
packets dropped.


(4) In the absence of mechanisms in the network to encourage end-to-end
congestion control, adding ECN to the API for UDP would make it
somewhat more attractive for UDP applications to disable or fail to
deploy end-to-end congestion control.

One of the ways for UDP applications to avoid the negative consequences
of packet drops would be to add FEC (Forward Error Correction) to the
UDP application.  (Some would argue that it is not easy for the casual
user to add FEC to a UDP application.)  We consider three orthogonal
variables:  "good" or "bad" UDP, "ECN" or "non-ECN" UDP, and "FEC" or
"non-FEC" TCP.

For UDP without any form of FEC, "bad ECN" UDP gives considerably
better performance than "bad non-ECN" UDP, for an environment
that for some reason is able to stay in a state of mild congestion.
With "bad non-ECN" UDP, a small fraction of packets will be dropped
and perhaps never retransmitted to the receiver.  With "bad ECN" UDP,
it is possible that no packets will be dropped.

However, given that ECN is only of benefit when congestion is mild, a
"bad non-ECN" UDP could achieve similar benefits as a "bad ECN" UDP
simply by adding some FEC, increasing the transmission rate slightly.
The FEC would compensate for the packet drops.

-----------------------------------------------------------------

This note is in part the result of a discussion at the January 1998
End-to-End Research Group.  It is, however, not necessarily the case
that all of the members of the group would agree with all of this
note.