From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <wes@mti-systems.com>
Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com
	[205.178.146.59])
	by huchra.bufferbloat.net (Postfix) with ESMTP id 68A84201A38
	for <bloat@lists.bufferbloat.net>; Wed, 27 Apr 2011 10:39:55 -0700 (PDT)
Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50])
	by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id
	p3RHef7Q012722
	for <bloat@lists.bufferbloat.net>; Wed, 27 Apr 2011 13:40:41 -0400
Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com;
	auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [94.75.220.253] ([94.75.220.253:5177] helo=[10.6.0.22])
	by cm-omr14 (envelope-from <wes@mti-systems.com>)
	(ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA
	id 22/DF-07497-71558BD4; Wed, 27 Apr 2011 13:40:41 -0400
Message-ID: <4DB85516.5040801@mti-systems.com>
Date: Wed, 27 Apr 2011 13:40:38 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: Bill Sommerfeld <wsommerfeld@google.com>
References: <BANLkTi=9Kgz4kXRzK_KC9LpSDBEoVQiseg@mail.gmail.com>	<BANLkTi=pOCQRdUA3_-_=q+m27H526rWK7w@mail.gmail.com>	<BANLkTimrxy6=8NQ+VpysJiRcWCX6RpbrWA@mail.gmail.com>	<4DB70FDA.6000507@mti-systems.com>	<BANLkTim-CpqBYg0bhecGzYYVt-+wdQVvdg@mail.gmail.com>	<4DB72934.9050700@mti-systems.com>
	<BANLkTim+HYGLv+=em5x=R=ZtnbyRhxkC1w@mail.gmail.com>
In-Reply-To: <BANLkTim+HYGLv+=em5x=R=ZtnbyRhxkC1w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Network computing article on bloat
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2011 17:39:55 -0000

On 4/27/2011 1:10 PM, Bill Sommerfeld wrote:
> On Tue, Apr 26, 2011 at 13:21, Wesley Eddy<wes@mti-systems.com>  wrote:
>> Ideally, you may have a path with ample bandwidth such that packet
>> losses don't occur and all connections are either application limited or
>> receive window limited and congestion control never kicks in.  In this
>> case, there's no loss and the Internet clearly works.
>
> This situation is not really "ideal" because it indicates an
> unbalanced system -- you've probably spent too much on link bandwidth
> and not enough on end system performance.
>
>

Many applications are inherently limited in max rate; e.g. VoIP and
video streams with fixed-rate codecs, telemetry, etc.

The elevator pitch should  be that optimizing for low loss is harmful
and needs to be balanced with optimizing latency.  It should not be
saying that loss is required.

-- 
Wes Eddy
MTI Systems