From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mtv-iport-2.cisco.com", Issuer "Cisco SSCA2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AB38E202295 for ; Sat, 7 Apr 2012 07:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1873; q=dns/txt; s=iport; t=1333808321; x=1335017921; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=uN8mhqJMS71UMg/znVBJ+7eQ3pr7w45A5KfhiUZ7PO0=; b=dAM0+BOBBlLOtDjW+WH6tcfDDkEppUt2Ab47z5OvqiLhLzeUriR5mk8Z tkInB17mklBD3LKb649cFfG8S523OdsEnrk8h1n4NLdMm7yuuDwYsd3jh xIQKBN9MCEpBoFfncZ03MTwuIW73sCOZnOTG/kJ26dV3YgdBUHziKExV/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANlLgE+rRDoI/2dsb2JhbAA/BrkfgQeCCQEBAQMBEgEnPwULC0ZXBjWHZwSaDZ9OiycBDoRBYwSIWo0ShXKIW4FpgweBNAE X-IronPort-AV: E=Sophos;i="4.75,385,1330905600"; d="scan'208";a="39504482" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 07 Apr 2012 14:18:40 +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 q37EIdVm003583; Sat, 7 Apr 2012 14:18:39 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Sat, 07 Apr 2012 07:18:39 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Sat, 07 Apr 2012 07:18:39 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 7 Apr 2012 07:17:43 -0700 Message-Id: References: <20120406213725.GA12641@uio.no> To: Neil Davies X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: bloat@lists.bufferbloat.net 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 14:18:42 -0000 On Apr 7, 2012, at 4:54 AM, Neil Davies wrote: > The answer was rather simple - calculate the amount of buffering = needed to achieve > say 99% of the "theoretical" throughput (this took some measurement as = to exactly what=20 > that was) and limit the sender to that. So what I think I hear you saying is that we need some form of ioctl = interface in the sockets library that will allow the sender to state the = rate it associates with the data (eg, the video codec rate), and let TCP = calculate f(rate in bits per second, pmtu) cwnd_limit =3D ceiling (--------------------------------) + C g(rtt in microseconds) Where C is a fudge factor, probably a single digit number, and f and g = are appropriate conversion functions. I suspect there may also be value in considering Jain's "Packet Trains" = paper. Something you can observe in a simple trace is that the doubling = behavior in slow start has the effect of bunching a TCP session's data = together. If I have two 5 MBPS data exchanges sharing a 10 MBPS pipe, = it's not unusual to observe one of the sessions dominating the pipe for = a while and then the other one, for a long time. One of the benefits of = per-flow WFQ in the network is that it consciously breaks that up - it = forces the TCPs to interleave packets instead of bursts, which means = that a downstream device on a more limited bandwidth sees packets arrive = at what it considers a more rational rate. It might be nice if In its = initial burst, TCP consciously broke the initial window into 2, or 3, or = 4, or ten, individual packet trains - spaced those packets some number = of milliseconds apart, so that their acknowledgements were similarly = spaced, and the resulting packet trains in subsequent RTTs were = relatively small.=