From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay009.isp.belgacom.be (mailrelay009.isp.belgacom.be [195.238.6.176]) by huchra.bufferbloat.net (Postfix) with ESMTP id 049A721F72D for ; Thu, 28 Aug 2014 11:01:21 -0700 (PDT) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoIADht/1NR9HVy/2dsb2JhbABbgw23UZo2gxoEAgGBGxd3hAQBBVYGHBELCw0JFg8JAwIBAgERFh4TCAEBiCkBGAGtBoxAChmBGoRIF45+VRaENgEEkjCKKoc3jWaDYDuCfgEBAQ Received: from 114.117-244-81.adsl-dyn.isp.belgacom.be (HELO zotac.xperim.be) ([81.244.117.114]) by relay.skynet.be with ESMTP; 28 Aug 2014 20:01:19 +0200 Received: from [192.168.1.172] (mordor.xperim.be [192.168.1.172]) by zotac.xperim.be (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id s7SI0scg008915 for ; Thu, 28 Aug 2014 20:00:55 +0200 Message-ID: <53FF6E56.8070800@gmail.com> Date: Thu, 28 Aug 2014 20:00:54 +0200 From: Jan Ceuleers User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <000001cfbefe$69194c70$3b4be550$@duckware.com> <000901cfc2c2$c21ae460$4650ad20$@duckware.com> <2A5BB518-351B-4598-AF79-7088D640AA06@gmail.com> <000301cfc2db$f655d3c0$e3017b40$@duckware.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Thu, 28 Aug 2014 18:01:22 -0000 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. Jan