Re: [aqm] Is bufferbloat a real problem?
KK <kk@cs.ucr.edu> Sat, 28 February 2015 02:10 UTC
Return-Path: <kk@cs.ucr.edu>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC731A1B2C for <aqm@ietfa.amsl.com>; Fri, 27 Feb 2015 18:10:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQr_n7V6_PXc for <aqm@ietfa.amsl.com>; Fri, 27 Feb 2015 18:10:33 -0800 (PST)
Received: from send.cs.ucr.edu (send.cs.ucr.edu [169.235.30.36]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543B91A00D1 for <aqm@ietf.org>; Fri, 27 Feb 2015 18:10:33 -0800 (PST)
Received: from [138.23.169.174] (dhcp-169-174.cs.ucr.edu [138.23.169.174]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by send.cs.ucr.edu (Postfix) with ESMTP id 17FCE1FA0495; Fri, 27 Feb 2015 18:10:33 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Fri, 27 Feb 2015 18:16:12 -0800
From: KK <kk@cs.ucr.edu>
To: davecb@spamcop.net, aqm@ietf.org
Message-ID: <D11664D4.2EEC%kk@cs.ucr.edu>
Thread-Topic: [aqm] Is bufferbloat a real problem?
References: <201502271852.t1RIqekh018253@maildrop31.somerville.occnc.com> <54F1212D.3040703@rogers.com>
In-Reply-To: <54F1212D.3040703@rogers.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/rHteORwHgShKRPO5yWSUQXJB9II>
Subject: Re: [aqm] Is bufferbloat a real problem?
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Feb 2015 02:10:36 -0000
This could also be done by not having to depend on loss¹ as the primary source of feedback... -- 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 2/27/15, 6:00 PM, "David Collier-Brown" <davec-b@rogers.com> wrote: >IMHO, removing latency is the aim of FQ. Once done, buffer sizes can be >unbounded (save by price (;-)) > >--dave > >On 02/27/2015 01:52 PM, Curtis Villamizar wrote: >> In message >><2134947047.1078309.1424979858723.JavaMail.yahoo@mail.yahoo.com> >> Daniel Havey writes: >> >>> >>> I know that this question is a bit ridiculous in this community. Of >>> course bufferbloat is a real problem. However, it would be nice to >>> formally address the question and I think this community is the right >>> place to do so. >>> >>> Does anybody have a measurement study? I have some stuff from the FCC >>> Measuring Broadband in America studies, but, that doesn't address >>> bufferbloat directly. >>> >>> Let me repeat for clarity. I don't need to be convinced. I need >>> evidence that I can use to convince my committee. >>> >>> ...Daniel >>> >>> _______________________________________________ >>> aqm mailing list >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >> >> Daniel, >> >> You are convinced. So am I but we need to temper the message to avoid >> going too far in the opposite direction - too little buffer. >> >> If you are not interested in the details, just skip to the last >> paragraph. >> >> Bufferbloat should in principle only be a problem for interactive >> realtime traffic. Interactive means two way or multiway. This is >> SIP, Skype, audio and video conferencing, etc. In practice it is also >> bad for TCP flows with short RTT and max window set small. >> >> One way realtime (such as streaming audio and video) should be >> unnafected by all but huge bufferbloat. That is should be. For >> example, youtube video is carried over TCP and is typically either way >> ahead of the playback or choppy (inadequate aggregate bandwidth or >> marigninal and/or big drop with TCP stall). It would be nice if >> marginal aggregate bandwidth was dealt with by switching to a lower >> bandwidth encoding, but too often this is not the case. This doesn't >> mean that some streaming formats don't manage to get this wrong and >> end up delay sensitive. >> >> TCP needs buffering to function correctly. Huge bufferbloat is bad >> for TCP, particularly for small transfers that never get out of TCP >> slow start and for short RTT flows. For long RTT flows too little >> buffer causes problems. >> >> [ aside: For example, if TCP starts with 4 segments at 1K segment >> size, it will take 4 RTT to hit 64KB window, the typical max window >> without TCP large window (TCPLW) option. During that time, 60KB will >> be sent. After that 64KB will be sent each RTT. With geographic RTT >> is 70 msec (approximate US continental RTT due to finite speed of >> light in fiber and fiber distance), 60 KB is sent in the first 280 >> msec and 64KB gets sent every 70 msec yielding 7 mb/s. OTOH if there >> is a server 2 msec RTT away (1 msec one way is 125mi = 200km), then >> 60KB in first 8 msec and 256 Mb/s after that. If there is 100 msec >> buffer at a bottleneck, then this low RTT TCP flow will be slowed by a >> factor of 50. OTOH, if bottlenecks have a lot less than 1 RTT of >> buffer, then the long TCP flows will get even further slowed. ] >> >> One of the effects of some buffer, but not excessive, is short RTT >> flows which given the no-TCPLW max window get slowed down while longer >> RTT are less affected. This becomes more fair wrt to transfer rates >> among TCP flows. The same holds true if TCPLW gets turned on in >> commodity gadgets and the commonly deploed max window increases, but >> the number change. >> >> If the buffer grows a little and the deployed window sizes become the >> limiting factor, then this is very light congestion with delay but >> absolutely zero loss due to queue drops (not considering AQM for the >> moment). >> >> Some uses of TCP increase the window to work better over long RTT. It >> takes a bit longer to hit the max window but the rate once it has been >> hit is greater. Setting TCP window large on short RTT flows is >> counterproductive since one or a small number of flows can cause a >> bottleneck on a slow provider link (ie: 10-100 Mb/s range typical of >> home use). On a LAN RTT can be well under 1 msec on Ethernet and >> highly variable on WiFi. On WiFi larger window can contribute to some >> real trouble. So best that the default window be changed. >> >> [ Note that the work on automatic sizing of tcp_sndbuf and scp_recvbuf >> may create a tendency to saturate links as the window can go up to 2MB >> with default parameters. Has this hit consumer devices yet? This >> could be bad it this rolls out before widespread use of AQM. ] >> >> When a small amount of loss occurs, such as one or much less than the >> current window size, TCP cuts the current window size in half and >> retransmits the packet for the window in flight (ignoring selective >> acknowledgment extension aka SACK for the moment). >> >> If the buffer is way too small, then a large amount of premature drop >> occurs when the buffer limit is hit. Lots of TCP flows slow down. >> The long RTT flows slow down the most. Some retransmission occurs >> (which doesn't help congestion). If there is a long period of drop >> relative to a short RTT, then a entire window can be dropped and this >> is terrible for TCP (slow start is initiated after delay based on an >> estimate of RTT and RTT stdev, or 3 sec if RTT estimate is stale - >> this is a TCP stall). So with too little buffer some TCP flows get >> hammered and stall. TCP flows with long RTT tend to stall less but >> are more sensitve to the frequency of drop events and can get >> extremely slow due to successively cutting window in half and then >> growing the window linearly rather than exponentially. >> >> With tiny buffers really bad things tend to happen. The rate of >> retransmission can drive goodput (the amount of non-retransmit traffic >> per time) can drop substantially. Long RTT flows can become >> hopelessly slow. Stalls become more common. In the worst case (which >> has been observed in a ISP network during a tiny buffer experiment >> about a decade ago, details in private email) TCP synchronization can >> occur, and utilization and goodput drop dramatically. >> >> A moderate amount of buffer is good for all TCP. A large buffer is >> good for long RTT TCP flows, particularly those that have increased >> max window. As mentioned before, any but a very small buffer is bad >> for interactive real time applications. >> >> Enter AQM. A large buffer can be used but with a lower target delay >> and some form of AQM to introduce a low rate of isolated drops as >> needed to slow the senders. Avoiding queue tail drop events where a >> lot of drops occur over an interval lowers the amount of >> retransmission and avoids stalls. Long RTT flows tend to get >> penalized the most. >> >> Fairness is not great with a single queue and AQM but this is much >> better than a single queue with either small or large buffer and tail >> drop. Fairness is greatly improved with some form of FQ or SFQ. >> >> Ideally with FQ each flow would get its own queue. In practice this >> is not the case but the situation is greatly improved. A real time >> flow, which is inherently rate limited, would see minimal delay and no >> loss. A short RTT flow would see a moderate increase in delay and a >> low level of loss (ie: typically much less than 1%) enough to slow it >> down enough to avoid congestion. a long RTT flow would see a moderate >> increase in delay and no loss if still running slower than the small >> RTT flows. This does wonders for fairness and provides the best >> possible service for each service type. >> >> In practice, some FQ or SFQ queues have a mix of real time, low RTT >> TCP, and high RTT TCP. If any such queue is taking a smaller share >> than other queues, delay is low and loss is low or zero. If such a >> queue is taking more than its share, then the situation is similar to >> the single queue case. Less flows end up in such a queue. Cascaded >> queues have been proposed and in some cases (no longer existing) have >> been implemented. In a cascaded SFQ scheme, the queues taking more >> than their share are further subdivied. Repeat the subdivision a few >> times and you can end up with the large bandwidth contributors in >> their own queue and getting a fair share of capacity. >> >> So excuse the length of this but solving bufferbloat is *not* a silver >> bullet. Not understanding that point and just making buffers really >> small could result in an even worse situation than we have now. >> >> Curtis >> >> ps - Some aspects of this may not reflect WG direction. IMHO- the >> down sides of just making buffers smaller and/or setting low delay >> targets may not be getting enough (or any) attention in the WG. Maybe >> discussion wouldn't hurt. >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm >> > > >-- >David Collier-Brown, | Always do right. This will gratify >System Programmer and Author | some people and astonish the rest >davecb@spamcop.net | -- Mark Twain > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm
- [aqm] Gathering Queue Length Statistics Ryan Doyle
- Re: [aqm] Gathering Queue Length Statistics Fred Baker (fred)
- Re: [aqm] Gathering Queue Length Statistics Dave Taht
- Re: [aqm] Gathering Queue Length Statistics Daniel Havey
- Re: [aqm] Gathering Queue Length Statistics Jesper Dangaard Brouer
- Re: [aqm] Gathering Queue Length Statistics Dave Taht
- Re: [aqm] Gathering Queue Length Statistics grenville armitage
- Re: [aqm] Gathering Queue Length Statistics Ryan Doyle
- Re: [aqm] Gathering Queue Length Statistics Mikael Abrahamsson
- Re: [aqm] Gathering Queue Length Statistics Toke Høiland-Jørgensen
- [aqm] Is bufferbloat a real problem? Daniel Havey
- Re: [aqm] Is bufferbloat a real problem? Curtis Villamizar
- Re: [aqm] Is bufferbloat a real problem? Daniel Havey
- Re: [aqm] Is bufferbloat a real problem? Daniel Havey
- Re: [aqm] Is bufferbloat a real problem? David Collier-Brown
- Re: [aqm] Is bufferbloat a real problem? KK
- Re: [aqm] Is bufferbloat a real problem? David Collier-Brown
- Re: [aqm] Is bufferbloat a real problem? Mikael Abrahamsson
- Re: [aqm] Is bufferbloat a real problem? Curtis Villamizar
- Re: [aqm] Is bufferbloat a real problem? Curtis Villamizar
- Re: [aqm] Is bufferbloat a real problem? Curtis Villamizar