From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-03-ewr.dyndns.com (mxout-241-ewr.mailhop.org [216.146.33.241]) by lists.bufferbloat.net (Postfix) with ESMTP id 54B282E04C5 for ; Tue, 8 Feb 2011 07:54:29 -0800 (PST) Received: from scan-01-ewr.mailhop.org (scanner [10.0.141.223]) by mail-03-ewr.dyndns.com (Postfix) with ESMTP id CCF5B787E3D for ; Tue, 8 Feb 2011 15:54:27 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 74.125.82.171 Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by mail-03-ewr.dyndns.com (Postfix) with ESMTP id 6A8CC787C6A for ; Tue, 8 Feb 2011 15:54:27 +0000 (UTC) Received: by wyb38 with SMTP id 38so5682375wyb.16 for ; Tue, 08 Feb 2011 07:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AY2bY3eASw/CSxJx4BxX3sgNSlaU/0zAgJNMYwaMltw=; b=sBB6EjuzLxlaTwDfGo66Iy2YyB3s9JaMOklFH8gK3SdLTtd1XrPRmwGI6R3Fe1OrFo bBAYkbPLLHHAu7TT8L1A6EWxp2d1l+2qoHDv6vW/yIfqWd/yQYfSLThpD6TLirGWsCgx n3NTfZJ5BQ0z0hwxomyn2CJZn66buWqJ/bVCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Bi/GBnGd95wbVCN50jocG/zGiN8EwJ8ae/jUppPNimNwBIGpSPY5+VvvFRgosdDRZ5 paK/tyCSdEr4fNksKbfLcr4m+15lElj04o3/Y01zB+JZ3KzmIb8bjuS8gKUTPQ0GVswq jbo8jBsnINk4GFCUSC1j0LxESHSjX9zk1lsXM= MIME-Version: 1.0 Received: by 10.227.153.204 with SMTP id l12mr15922094wbw.81.1297180466373; Tue, 08 Feb 2011 07:54:26 -0800 (PST) Received: by 10.227.2.208 with HTTP; Tue, 8 Feb 2011 07:54:26 -0800 (PST) In-Reply-To: <8739o0f5cu.fsf@cruithne.co.teklibre.org> References: <87oc6pf4bc.fsf@cruithne.co.teklibre.org> <8739o0f5cu.fsf@cruithne.co.teklibre.org> Date: Tue, 8 Feb 2011 10:54:26 -0500 Message-ID: From: Justin McCann To: =?ISO-8859-1?Q?Dave_T=E4ht?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bufferbloat list Subject: Re: [Bloat] The wireless problem in a nutshell X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 15:54:29 -0000 On Mon, Feb 7, 2011 at 6:31 AM, Dave T=E4ht wrote: >... > How long can the RTT get before TCP throughput drops? > > Good question. > > That depends on your tolerance for latency and packet loss. You can > increase your RTT, and reduce packet drops, by using buffering at the > expense of latency. ... There's a rule of thumb for the upper bound in two SIGCOMM-award papers; I generally use the simple one from the Mathis paper. bandwidth =3D (MSS / RTT) * (C / sqrt(loss)) MSS =3D maximum segment size RTT =3D round trip time C =3D a constant between 0.87 and 1.31, depending on the ACK strategy and type of loss sqrt(loss) =3D square root of the probability of losing a packet So, for a given connection, your expected throughput scales linearly with the size of your packets, and inversely with the RTT and sqrt(loss). I have an unverified/untested Python implementation of the equations at http://www.cs.umd.edu/~jmccann/tcp_tput.py I wonder how jumbo frames play into bufferbloat. When queues are in terms of number of packets (not bytes), jumbo frames make the problem even worse. Justin * The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm, by Matthew Mathis, Jeffrey Semke, Jamshid Mahdavi, and Teunis Ott, CCR 27(3), 1997. (pdf: http://ccr.sigcomm.org/archive/1997/jul97/ccr-9707-mathis.pdf) * Modeling TCP Throughput: A Simple Model and Its Empirical Validation, by Jitendra Padhye, Victor Firoiu, Don Towsley, and Jim Kurose, Proc. of ACM SIGCOMM 1998. (pdf: http://conferences.sigcomm.org/sigcomm/1998/tp/paper25.pdf)