Minutes of the Explicit Congestion Notification (ecn) BOF
Notes are from Naganand Doraswamy (Bay Networks), Pawan Goyal (AT&T Labs. Research), K. K. Ramakrishnan and Sally Floyd.
Documentation is available from the ECN BOF Web Page at:
"http://www-nrg.ee.lbl.gov/floyd/ecn/ecn_bof.html". This documentation includes the viewgraphs from the presentations.
I. Explicit Congestion Notification - ECN: Birds of a Feather Session
The BOF session on the use of Explicit Congestion Notification (ECN) in IP and TCP was co-chaired by Sally Floyd and K.K. Ramakrishnan. K.K. opened the session with an introduction to ECN. One of the motivations for ECN is to separate the mechanisms used to indicate congestion (e.g., either dropping a packet, or setting an ECN bit in the packet header) from the router mechanisms for queue management and congestion detection. It was stated that it is particularly timely to consider ECN now because of the current focus on queue management mechanisms such as RED, in that ECN complements and builds upon the functionality offered by RED for queue management. RED detects incipient congestion before the buffer overflows, but in the current Internet environment is limited to packet loss as the mechanism for indicating congestion to the end-nodes. ECN would give routers the ability to indicate congestion without dropping the packet.
II. The Detailed Proposal for ECN and IP
Sally Floyd described the semantics of the ECN bits and presented the detailed proposal for ECN and IP. The question was asked of why ECN was being considered for IPv4, since it was originally discussed in the context of IPv6. Sally answered that we are now considering the use of ECN both for IPv6 and in IPv4, because of a decision in IPv6 to make the IPv6 Class of Service byte consistent with IPv4's TOS byte, which is now under proposed modification both here and in the Differentiated Services Working Group.
The proposed semantics for ECN notification were given as follows: If a packet is marked as ECN-Capable, routers set the packet's CE (Congestion Experienced) bit if the routers would otherwise drop the packet and the queue is not in imminent danger of overflowing.
A question was asked about why ECN used two bits instead of one in the IP header. One of the important reasons given was that of incremental deployment, for an environment where some traffic is ECN-Capable and other traffic is not.
There was some discussion of exactly which bits should be used in the IP header. It was proposed that the positions of the ECT (ECN-Capable Transport) and the CE bit in the IP header be swapped, so that the ECT bit would be bit 7, which is currently the unused bit. This would be to avoid users misusing the ECT bit as a result of user-level switches. There was also a comment that some routers perform shift operations on the ToS byte, so that what starts as bit 7 could end up as bit 0.
There was a question about the incentives for ISP A to deploy ECN, given that ECN gives a competing ISP more information about ISP A's internal levels of congestion. The answer given was that, even in the absence of ECN, ISPs can make inferences about levels of congestion for competing ISPs. In addition, although ECN does give a downstream router more information about upstream levels of congestion, this information does not appear to introduce any security problems.
III. Mechanisms for Active Queue Management
Raj Jain raised the question of whether ECN's notification of congestion should be tied to the policies RED uses for dropping a packet, or whether these two issues should be separated. The question was raised of whether RED is the only queue averaging method that can be used with ECN. There was considerable discussion of this issue of how the semantics of the CE bit should be defined. One view expressed was that the router mechanisms for active queue management should be standardized along with the standardization of ECN, and that the two issues are inextricably intertwined. A comment made was that the router's semantics for setting the CE bit need to be defined better, because, while different routers may treat packets differently, the end hosts need to react the same way.
An alternate perspective was that the mechanism used for active queue management is largely orthogonal to the mechanism used to indicate congestion (e.g., either packet drop or ECN), and that it is sufficient to standardize the semantics of the CE bit as equivalent to a single packet drop, in terms of the indication of congestion to the end nodes. It was noted that active queue management based on RED is currently being implemented and deployed in the Internet in the absence of ECN. The chairs commented that ECN has been designed to be deployed incrementally, and that ECN can complement the effort on active queue management that is already underway.
Apart from the issue of active queue management's relationship to ECN (e.g., orthogonal, or inextricably intertwined), there were a range of opinions expressed about the desirability (or not) of IETF standardization of mechanisms for active queue management. The view was expressed that active queue management mechanisms do not raise issues of interoperable protocols, and that historically the queuing and scheduling mechanisms in a router have not been standardized in the IETF. At the same time, there was some opinion expressed about the desirability of further standardization of active queue management mechanisms (as initiated by RFC 2309 on "Recommendations on Queue Management and Congestion Avoidance in the Internet"). The chairs commented that their expectation is that routers would only mark packets when they have reliably determined the onset of congestion.
A related concern was raised of different routers implementing RED differently, with the Congestion Experienced bit having different meanings for different implementations. One answer given was that as long as the Congestion Experienced bit is used only when the router would otherwise have dropped a packet, that fact that different routers were using different RED implementations should not be a problem.
IV. Misbehaving Users
The question was raised of what should be done if the router sets the CE bit in the packet header, but the end system does not react. Sally addressed this as follows: For TCP applications, the presence of ECN does not make it easier for end nodes to disable TCP congestion control. For TCP applications, the benefit of lying about ECN capability is small, in part because routers with severe congestion will drop the packet rather than setting the CE bit in any case. In the case of UDP applications, many UDP applications already don't use end-to-end congestion control. For UDP applications in the absence of Forward Error Correction, there would be some benefit to applications of lying about ECN capability. It was agreed that this issue needs further experimental work.
The related question was raised of whether we were allowing congestion collapse by introducing ECN. The opinion expressed by the chairs was that the danger of congestion collapse exists without ECN, and that adding ECN does not make the situation significantly worse. The chairs' opinion was that there is already a risk to the Internet of flows not using end-to-end congestion control, and that this risk would have to be addressed by appropriate router mechanisms, with or without the addition of ECN.
Steve Bellovin asked about the use of ECN for UDP applications such as reliable multicast. The answer was that it was assumed that the first deployment of ECN would be for TCP, and that the use of ECN for UDP applications, while highly promising, is the subject of future work.
VI. The Detailed Proposal for ECN and TCP
Sally presented the detailed proposal for ECN and TCP. A comment was made that the ECN proposal hinges on the assumption that end-system protocol stacks will be changed appropriately to enable TCP to benefit from ECN. The chairs agreed.
The question of how many TCP acknowledgement (ACK) packets should have the ECN-Echo bit set was left for further study.
VII. Implementing ECN for TCP/IPv6
Hariharan Krishnan from UCLA made a presentation on their implementation work on ECN. He discussed the implementation at UCLA and the modifications to existing TCP. This involved adding two new TCP states, TCPS_SYN_RECEIVED_ECN and TCPS_ESTABLISHED_ECN. The environment was Free BSD 2.2.2, the host was RenoTCP for IPv6 (INRIA), and the router used RED queue management. They modified the router code for RED by writing a new device /dev/ecn to mark packes rather than drop them.
Hariharan also presented results of a simulation study. Simulations of short web transfers showed that the use of ECN reduced transfer times. With ECN there were fewer retransmissons and higher overall throughput. Fairness between ECN-Capable and non-ECN-Capable flows was also examined (in an environment that used RED). The results can be summarized as generally showing performance improvements when ECN was incorporated in addition to RED at the routers. A pointer to the work and software is: "www.cs.ucla.ed/~hari/software".
VIII. ECN versus IPsec?
Steve Bellovin gave a brief introduction on IPsec, including a description of the various headers and encapsulations. He said that for IPsec in transport mode with AH, there are no interactions with ECN. However, IPsec in tunnel mode does have impact on ECN, in that the ToS byte is currently copied to the outer IP header for tunneling, but not copied back to the inner header at tunnel termination. Steve pointed out that this group should give input on the mechanisms for handling ToS byte.
Questions raised for further investigation included the performance of ECN in heterogeneous environments, where some routers support ECN and some do not.
IX. Next Steps
There was unanimous agreement from the group at the end of the BOF session that we should revise the internet draft on "A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP", incorporating the comments received from the group attending the BOF. Further, it was agreed that experimental work on ECN should continue with the draft progressing to "experimental status."
ECN web page: http://www-nrg.ee.lbl.gov/floyd/ecn.html
ECN Mailing list: email@example.com
go to list