From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id DAD5F21F72B for ; Thu, 28 Aug 2014 18:57:23 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id s7T1vLhN023506; Thu, 28 Aug 2014 18:57:21 -0700 Date: Thu, 28 Aug 2014 18:57:21 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: Message-ID: References: <000001cfbefe$69194c70$3b4be550$@duckware.com> <000901cfc2c2$c21ae460$4650ad20$@duckware.com> <2A5BB518-351B-4598-AF79-7088D640AA06@gmail.com> <000301cfc2db$f655d3c0$e3017b40$@duckware.com> <53FF6E56.8070800@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-910901421-1409277441=:23856" Cc: bloat Subject: Re: [Bloat] The Dark Problem with AQM in the Internet? 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: Fri, 29 Aug 2014 01:57:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-910901421-1409277441=:23856 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 28 Aug 2014, Dave Taht wrote: > On Thu, Aug 28, 2014 at 11:00 AM, Jan Ceuleers wrote: >> On 08/28/2014 06:35 PM, Fred Baker (fred) wrote: >>> When a message is lost due to an error, how do you determine whose fault >>> it is? >> >> Links need to be engineered for the optimum combination of power, >> bandwidth, overhead and residual error that meets requirements. I agree >> with your implied point that a single error is unlikely to be indicative >> of a real problem, but a link not meeting requirements is someone's fault. >> >> So like Jerry I'd be interested in an ability for endpoints to be able >> to collect statistics on per-hop loss probabilities so that admins can >> hold their providers accountable. > > I will argue that a provider demonstrating 3% packet loss and low > latency is "better" than a provider showing .03% packet loss and > exorbitant latency. So I'd rather be measuring latency AND loss. Yep, the drive to never loose a packet is what caused buffer sizes to grow to such silly extremes. David Lang > One very cool thing that went by at sigcomm last week was the concept > of "active networking" revived in the form of "Tiny Packet Programs": > see: > > http://arxiv.org/pdf/1405.7143v3.pdf > > Which has a core concept of a protocol and virtual machine that can > actively gather data from the path itself about buffering, loss, etc. > > No implementation was presented, but I could see a way to easily do it > in linux via iptables. Regrettably, elsewhere in the real world, we > have to infer these statistics via various means. > > > >> Jan >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > > > -- > Dave Täht > > NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --680960-910901421-1409277441=:23856--