From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mtv-iport-4.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 49F5C201044 for ; Sat, 7 Apr 2012 14:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1435; q=dns/txt; s=iport; t=1333835468; x=1335045068; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=BIdHiDfCo3zuSxgLRRAFn4EYKOoGT8+X/ZhI8Q9GYOw=; b=Q04yXYRYro1bpWThxl0VtOUbdN2W9+4o2huCaWya1YIbjPgOIRMb7arH M8gPpNkBnzPCnD59+yIZ9E/T/eDOyOF4H8yfET07rhqu/oasYDD4Xhdvt WIfKPoy3KIog7iSzu1/D0wtlXhYrIm7x8liOrXntP8NC8wXlnQCJ6CaMj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHC2gE+rRDoI/2dsb2JhbABFuSOBB4IKAQEEEgEnPwULCy0ZVwYBGxmHawyaF58hjSqCTWMEiFqNEoVyiFuBaYMH X-IronPort-AV: E=Sophos;i="4.75,388,1330905600"; d="scan'208";a="39437892" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 07 Apr 2012 21:51:07 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q37LofHH030381; Sat, 7 Apr 2012 21:51:06 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Sat, 07 Apr 2012 14:51:07 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Sat, 07 Apr 2012 14:51:07 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 7 Apr 2012 14:49:53 -0700 Message-Id: <6D19B807-1B09-4AB5-A727-E9A7449C6A1D@cisco.com> References: <20120406213725.GA12641@uio.no> <20120406222138.GB12641@uio.no> <1333811327.30705.4.camel@edumazet-laptop> <20120407153548.GC21452@uio.no> <20120407181034.GD21452@uio.no> To: Dave Taht , "Steinar H. Gunderson" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] Best practices for paced TCP on Linux? 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: Sat, 07 Apr 2012 21:51:08 -0000 On Apr 7, 2012, at 11:50 AM, Dave Taht wrote: > http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html >=20 > 64-256k seems about right but the math is eluding me this morning. For a 5 MBPS data stream, Path MTU =3D 1460, 100 ms RTT, you're looking = at rate in bps rtt in microseconds cwnd_limit =3D ceiling ( ----------- * ------------------- )=20 8*pmtu 1e6 5e6 100 e 3 =3D ceiling ( ------ * ------------------- )=20 8*1460 1e6 =3D ceiling ( 428 * 0.100 )=20 =3D 43 you probably want to bump that by one or two to account for 43*40 bytes = of IP and TCP headers. 43*1460 is 62780 bytes per RTT, which is frightfully close to 65K bytes = per RTT, 524,280 bits per RTT, or 5,242,800 bits per second with the = stated RTT. Hmmm. Speaking strictly for myself, I would throw in one caveat, which is that = a variable bit rate codec that averages 5 MBPS sometimes sends faster, = and there may be good reason to allow it to. I think I'd recalculate for = 6 MBPS on average, and carefully insert the RTT I cared about into the = calculation. Doing that also accounts for the Mathis formula, which is = far more complex and requires a lot more assumptions, but will come up = with a number below 6 MBPS for a .1% loss rate.=