From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.vyatta.com (mail.vyatta.com [76.74.103.46]) by huchra.bufferbloat.net (Postfix) with ESMTP id A4E6E21F107 for ; Mon, 17 Dec 2012 10:56:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.vyatta.com (Postfix) with ESMTP id 0E7A11410451; Mon, 17 Dec 2012 10:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at tahiti.vyatta.com Received: from mail.vyatta.com ([127.0.0.1]) by localhost (mail.vyatta.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf-tsI-MbN+N; Mon, 17 Dec 2012 10:56:22 -0800 (PST) Received: from nehalam.linuxnetplumber.net (static-50-53-80-93.bvtn.or.frontiernet.net [50.53.80.93]) by mail.vyatta.com (Postfix) with ESMTPSA id D44551410176; Mon, 17 Dec 2012 10:56:21 -0800 (PST) Date: Mon, 17 Dec 2012 10:55:05 -0800 From: Stephen Hemminger To: Jim Gettys , Dave Taht Subject: Bufferbloat in 3G/4G Message-ID: <20121217105505.05eeed00@nehalam.linuxnetplumber.net> Organization: Vyatta Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bloat-devel X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:56:23 -0000 Injong Rhee pointed me to this paper published at IMC. http://research.csc.ncsu.edu/netsrv/sites/default/files/p329.pdf Interesting tidbit is yet another hack to avoid bufferbloat. "Our investigation into the open source Android platform reveals that a small untold trick has been applied to mitigate the issue: the maximum TCP receive buffer size parameter (tcp rmem max) has been set to a relatively small value although the physical buffer size is much larger. Since the advertised receive window (rwnd) cannot exceed the receive buffer size and the sender cannot send more than what is allowed by the advertised receive window, the limit on tcp rmem max effectively prevents TCP congestion window (cwnd) from excessive growth and controls the RTT (round trip time) of the flow within a reasonable range. However, since the limit is statically configured, it is sub-optimal in many scenarios, especially considering the dynamic nature of the wireless mobile environment. They propose doing receiver adjustment which might help avoid the "big buffer is at my stupid ISP" problem. "In this paper, we propose dynamic receive window adjustment (DRWA), a light-weight, receiver-based solution that is cheap to deploy. Since DRWA requires modifications only on the receiver side and is fully compatible with existing TCP protocol, carriers or device manufacturers can simply issue an over-the-air (OTA) update to smart phones so that they can immediately enjoy better performance even when interacting with existing servers. Is anyone interested in integrating and testing this?