From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B08C020064E for ; Fri, 13 Apr 2012 17:44:45 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g6t0186.atlanta.hp.com (Postfix) with ESMTP id 791EC2C1E3; Sat, 14 Apr 2012 00:44:44 +0000 (UTC) Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id E2A91143D9; Sat, 14 Apr 2012 00:44:43 +0000 (UTC) Message-ID: <4F88C87B.6040806@hp.com> Date: Fri, 13 Apr 2012 17:44:43 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Fred Baker References: <20120406213725.GA12641@uio.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 14 Apr 2012 00:44:45 -0000 On 04/07/2012 07:17 AM, Fred Baker wrote: > > 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 >> 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 = 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. Since cwnd will never be more than SO_SNDBUF, apart from complications getting the rtt, I think one can probably do something close to that from user space with setsockopt(SO_SNDBUF). I'm ass-u-me-ing that getsockopt(TCP_MAXSEG) will track PTMU, but I'm not sure if one can get the RTT portably - I think a getsockopt(TCP_INFO) under Linux will get the RTT, but don't know about other stacks. (Looks like Linux will also return a pmtu value). rick jones