From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pv0-f171.google.com (mail-pv0-f171.google.com [74.125.83.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 726BF201A59 for ; Tue, 26 Apr 2011 11:28:05 -0700 (PDT) Received: by pva4 with SMTP id 4so852610pva.16 for ; Tue, 26 Apr 2011 11:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=NO69m1IVCqf5Dq9fhLX9MTKiRfJ2PhMMacjnnhONJwk=; b=LHYAIVY0uCtybvlAP9DgwfEkdMbBulSEpFJbkgi+S9m0mg7wNF1DlsNeJrtZggVf1B leN//M3cSuWsmQYIJI/FT/8svV5/L6lPOTfKy3RmvfI/EVPINsGpcTeylQjTpuyVq9+Y 2yLIEE2PsxmxcEWYuSieBppElJUTYUsWYOKMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=ApzUK7uI5ILw/0L1QMs+CDIDkNcN1fmY6HbiqXfZcEm9Jc8YKrPBFWCypzfNE9PgZR nXYu/10JwY5DB7hvX+8x7P1Fi1EKJwL8DDts2guvjqOvD2JcJRHW1+Gxl8T8oyRyTAr5 PikmIgx6+1VeBbTZbWZlwafHfvoljl+11lBZU= Received: by 10.68.26.7 with SMTP id h7mr1331680pbg.101.1303842505084; Tue, 26 Apr 2011 11:28:25 -0700 (PDT) MIME-Version: 1.0 Sender: netmagdave2@gmail.com Received: by 10.68.40.1 with HTTP; Tue, 26 Apr 2011 11:28:05 -0700 (PDT) In-Reply-To: References: From: dave greenfield Date: Tue, 26 Apr 2011 21:28:05 +0300 X-Google-Sender-Auth: pf076jzYVD40cg5Rc7CzAqcRhRA Message-ID: To: Dave Taht Content-Type: multipart/alternative; boundary=bcaec521567b5bcf1b04a1d67dcc X-Mailman-Approved-At: Tue, 26 Apr 2011 11:31:32 -0700 Cc: bloat 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 18:28:05 -0000 --bcaec521567b5bcf1b04a1d67dcc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Dave. I'm actually NOT under the impression that packet loss is the dark lord incarnate. Yes, I too would have preferred a different title, but editors have the last say sometimes. Oh, and insertion latency or insertion loss isn't all that new. I've seen it used in switch and device design for several years. Call it what you will, but it's important that IT understand= s the amount of latency introduced by a given device into the data path. This isn't always widely discussed in WAN opt circles..... Dave PS Can we please have someone else jump in here who's name is NOT Dave! On Tue, Apr 26, 2011 at 9:17 PM, Dave Taht wrote: > "Big Buffers Bad. Small Buffers Good." > > "*Some* packet loss is essential for the correct operation of the Interne= t" > > are two of the memes I try to propagate, in their simplicity. Even > then there are so many qualifiers to both of those that the core > message gets lost. > > > > On Tue, Apr 26, 2011 at 12:13 PM, Dave Hart wrote: > > On Tue, Apr 26, 2011 at 17:05 UTC, Dave Taht > wrote: > >> Not bad, although I can live without the title. Coins a new-ish phrase > >> "insertion latency" > >> > >> > http://www.networkcomputing.com/end-to-end-apm/bufferbloat-and-the-collap= se-of-the-internet.php > > > > The piece ends with a paragraph claiming preventing packet loss is > > addressing a more fundamental problem which contributes to > > bufferbloat. As long as the writer and readers believe packet loss is > > an unmitigated evil, the battle is lost. More encouraging would have > > been a statement that packet loss is preferable to excessive queueing > > and a required TCP feedback signal when ECN isn't in play. > > > > Cheers, > > Dave Hart > > > > > > -- > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://the-edge.blogspot.com > --=20 --- Dave Greenfield Principal Strategic Technology Analytics Research. Analysis. Insight dave@stanalytics.com | 1-908-206-4114 Netmagdave | @Netmagdave Blogs: ZDNet | Information Week --bcaec521567b5bcf1b04a1d67dcc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Dave. I'm actually NOT under the impression that packet loss is= the dark lord incarnate. Yes, I too would have preferred a different title= , but editors have the last say sometimes. Oh, and insertion latency or ins= ertion loss isn't all that new. I've seen it used in switch and dev= ice design for several years. Call it what you will, but it's important= that IT understands the amount of latency introduced by a given device int= o the data path. This isn't always widely discussed in WAN opt circles.= ....

Dave

PS Can we please have someone else jump i= n here who's name is NOT Dave!


On Tue, Apr 26, 2011 at 9:17 PM, Dave Taht = <dave.taht@gmail.com> wrote:
"Big Buffers Bad. Small Buffers Good.&= quot;

"*Some* packet loss is essential for the correct operation of the Inte= rnet"

are two of the memes I try to propagate, in their simplicity. Even
then there are so many qualifiers to both of those that the core
message gets lost.



On Tue, Apr 26, 2011 at 12:13 PM, Dave Hart <davehart@gmail.com> wrote:
> On Tue, Apr 26, 2011 at 17:05 UTC, Dave Taht <dave.taht@gmail.com> wrote:
>> Not bad, although I can live without the title. Coins a new-ish ph= rase
>> "insertion latency"
>>
>> http://www.netw= orkcomputing.com/end-to-end-apm/bufferbloat-and-the-collapse-of-the-interne= t.php
>
> The piece ends with a paragraph claiming preventing packet loss is
> addressing a more fundamental problem which contributes to
> bufferbloat. =A0As long as the writer and readers believe packet loss = is
> an unmitigated evil, the battle is lost. =A0More encouraging would hav= e
> been a statement that packet loss is preferable to excessive queueing<= br> > and a required TCP feedback signal when ECN isn't in play.
>
> Cheers,
> Dave Hart
>



--
Dave T=E4ht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.= blogspot.com



--
---
Dave Greenfield
Principal
Strategic Technology Analytics
R= esearch. Analysis. Insight

dave@stanalytics.com=A0|=A01-908-206-4114
=A0Netmagdave =A0| =A0@Netmagdave

--bcaec521567b5bcf1b04a1d67dcc--