7. Non-compliance by the End Nodes
7. Non-compliance by the End Nodes
This section discusses concerns about the vulnerability of ECN to non-compliant end nodes (that is, end nodes that set the ECT codepoint in transmitted packets but do not respond to received CE packets). We believe that adding ECN to the IP architecture does not significantly increase the current vulnerability of that architecture to unresponsive flows.
Even without ECN environments, there is serious concern about the damage that could be done by unresponsive or non-compliant flows (that is, flows that do not respond to congestion indications by reducing their arrival rate at a congested link). For example, end nodes could "turn off congestion control" by not responding to packet drops by reducing their congestion window. This is a concern with the current Internet. It has been suggested that routers will have to deploy mechanisms for detecting and differentiating packets from non-compliant flows [RFC2309,FF99]. It has also been suggested that techniques such as per-flow scheduling and isolation of one flow from another at end-to-end, differentiated services, or end-to-end reservation could remove some of the more destructive effects of unresponsive flows.
It would seem that packet dropping itself is a sufficient deterrent to non-compliance, and that the use of ECN removes this deterrent. Our response is that (1) ECN-capable routers retain the packet dropping behavior at high congestion; and (2) that even at high congestion, packet dropping itself is not a sufficient deterrent to non-compliance.
First, ECN-capable routers only mark packets (instead of dropping them) when the packet marking rate would be reasonably low. During periods when the average queue size exceeds the upper threshold, and therefore the potential packet marking rate would be high, our recommendation is that routers drop packets instead of setting the CE codepoint in the packet header.
At the low to moderate packet marking rates where ECN would be deployed, there is little deterrent effect of dropping instead of marking these packets for unresponsive flows. For example, delay-insensitive flows using reliable transport might have an incentive to increase rather than decrease their sending rate in the presence of dropped packets. Similarly, delay-sensitive flows using unreliable transport might respond to increased packet drop rates by increasing their use of FEC, increasing rather than decreasing their sending rate. For the same reason, we don't believe that packet dropping itself is an effective deterrent to non-compliance even in high packet loss rate environments, when all flows share the same packet drop rate.
Several approaches have been proposed to identify and limit unresponsive or non-compliant flows. Adding ECN to the network environment does not make the design and deployment of such mechanisms any more difficult in any way. If anything, adding ECN to the architecture makes the job of identifying unresponsive flows slightly easier. For example, in an ECN-capable environment, a router is not limited to information about packets dropped or set with the CE codepoint at that router itself; in such an environment, a router can also take note of arriving CE packets, which indicate congestion encountered by that packet earlier in the path.