The discussion about adding buffers and the impact of buffers should be considered relative to the time scales when congestion occurs and when it is relieved by the dynamics of the end-system protocols. The reason we have buffering is to handle transients at the points where there is a mismatch in available bandwidth. We don¹t look to just throw buffers in front of a bottleneck for long run¹ overload.
While active queue management undoubtedly seeks to keep the backlog build-up at a manageable level so as to not allow latency to grow and still keep the links busy to the extent possible, the complement that ECN provides is to mitigate the impact of the drop that AQM uses to signal end-points to react to the transient congestion. ECN has the benefit when you have flows that have small windows, where the impact of loss is more significant. As you say, "when a packet is lost it causes a 'large' amount of latency as the sender times out and retransmits, but if this is only happening every few thousand packets, it's a minor effect.². But this is the case for flows that are long-lived. If the flows are short-lived (and I believe empirical evidence suggests that they are a significant portion of the flows), then it is not a minor effect any more. Thanks, -- K. K. Ramakrishnan Professor Dept. of Computer Science and Engineering University of California, Riverside Rm. 332, Winston Chung Hall Tel: (951) 827-2480 Web Page: http://www.cs.ucr.edu/~kk/ On 3/27/15, 12:18 PM, "David Lang" <da...@lang.hm> wrote: >If your link is the bottleneck, adding buffers (allowing latency to >increase) >doesn't decrease loss over the long run, it just hides it in the short >run. > >If you don't have the bandwidth to send the packets, nothing you do with >buffers >or latency will let you get more packets through. > >If you push too hard to decrease latency, then you run into times when >the link >is idle, so throughput can suffer a little bit. > >But right now, real-world buffers commonly get into tens of seconds worth >of >traffic. Far beyond what's needed or reasonable to keep the links busy. >Using >active queue management to keep the links busy without letting the >backlong >build up results in both increased throughput for users, and decreases of >latency of a couple orders of magnatude. > >by comparison, ECN on a network that's operating without excessive >buffering and >has a large number of flows, is going to only have a small effect on >latency and >througput overall. > >Yes, when a packet is lost it causes a 'large' amount of latency as the >sender >times out and retransmits, but if this is only happening every few >thousand >packets, it's a minor effect. > >David Lang > >On Fri, 27 Mar 2015, Vishal Misra wrote: > >> If you reduce latency, the dynamics of TCP are such that it will >>necessarily >> increase loss rate. On a bottlenecked link, the relationship of >>throughput to >> the RTT and loss rate of TCP is roughly the following (happy stop >>supply link >> to papers): >> >> throughput = K/(RTT*sqrt(p)) >> >> where K is some constant, p is the loss rate and RTT is the round trip >>time. If you reduce latencies, to maintain the same throughput (that of >>the bottlenecked link), the loss rate has to necessarily go up. >> So reducing latencies has the impact of increasing loss rates which >>affects things in bad ways as has been pointed out. >> >> With ECN, it is the _marking_ rate that goes up and TCP follows the >>same dynamics. Nothing is dropped, no harm done. >> That¹s why ECN widely adopted is a win-win. >> >> -Vishal >> -- >> http://www.cs.columbia.edu/~misra/ >> >> >>> On Mar 27, 2015, at 2:36 PM, John Leslie <j...@jlc.net> wrote: >>> >>> Scheffenegger, Richard <r...@netapp.com <mailto:r...@netapp.com>> wrote: >>>> >>>> ... At the least when you are using TCP, a drop will cause >>>>head-of-line >>>> blocking on the receiver, for at least 1 RTT; >>> >>> Yes. >>> >>> This is a trade-off: many folks believe that a good AQM has enough >>> benefits for typical TCP flows to overcome that. (YMMV) >> >>_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm