> Abstract > > This document describes the potential benefits when applications > enable Explicit Congestion Notification (ECN). It outlines the > principal gains in terms of increased throughput, reduced delay and > other benefits when ECN is used over network paths that include > equipment that supports ECN-marking. It also identifies some > potential problems that might occur when ECN is used. The document > does not propose new algorithms that may be able to use ECN or > describe the details of implementation of ECN in endpoint devices, > routers and other network devices.
Dumb question: Is there any intention to comment on DCTCP, which has its own interpretation of ECN? > 1. Introduction > A network device (router, middlebox, or other device that forwards > packets through the network) that does not support AQM, typically > uses a drop-tail policy to discard excess IP packets when its queue > becomes full. For the record, the device sending the packet should implement something regarding its own queues. One alternative is to freeze a process that presents a packet to a queue that is full until the queue opens up, but another way is to mark the packet. > 2.2. Bleaching and middlebox requirements to deploy ECN > [snip] > Some network devices have been observed to implement a policy that > erases or "bleaches" the ECN marks at a network edge (resetting these > to zero). This may be implemented for various reasons (including > normalising packets to hide which equipment supports ECN). This > policy prevents use of ECN by applications. A network device should > therefore not remark an ECT(0) or ECT(1) mark to zero. Is this RFC 2119 “SHOULD”? > A network device must not change a packet with a CE mark to a zero Is this RFC 2119 "MUST NOT”? Section 3 and 4; my one point of puzzlement was that there was no reference to a test or paper supporting the relevant values. > 4.1. Avoiding Capacity Overshoot > > Internet transports do not know apriori how much capacity exists > along a network path. Transports therefore try to measure the > capacity available to an application by probing the network path with > increasing traffic to the point where they detect the onset of > congestion (such as TCP or SCTP Slow Start). > > ECN can help capacity probing algorithms (such as Slow Start) from > significantly exceeding the bottleneck capacity of a network path. This statement is a case in point of “can you point to a paper?”. Imagine, if you will, that the best value of cwnd for some session is N. A TCP session starts with IW packets in a burst. In the second RTT, as acks come back, 2*IW packets are sent, followed by 4*IW, 8*IW, and 16*IW packets until either cwnd crosses ssthresh or there is a loss. Suppose, just for fun, that for k a power of 2, N = k*IW+1. At least in theory, I shouldn’t see a lot of congestion on that RTT, and in the subsequent RTT I could see cwnd/2-1 packets marked and perhaps quite a few lost. That is no different than slow-start terminated by loss. I’m not sure I see how ECN avoids the case. > 6.2. Detecting ECN receiver feedback cheating > The transport at endpoint receivers must not try to conceal reception Is this RFC 2119 “MUST NOT”? > of CE-marked packets in the ECN feedback information that they > 7. Conclusion This fairly screams “RFC 2119”... I think the document is well-written and clear. Primarily, I have two questions: to what extent is it an academic paper making assertions, and needing to justify them, and to what extent is it a “considerations” document that gives guidance on the use of ECN in a network (RFC 2119).
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
