From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id E334521F36B for ; Thu, 23 Apr 2015 09:00:16 -0700 (PDT) Received: from 199-116-72-167.public.monkeybrains.net ([199.116.72.167] helo=[192.168.0.16]) by masada.superduper.net with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YlJXv-0003qU-Ck for bloat@lists.bufferbloat.net; Thu, 23 Apr 2015 17:00:13 +0100 Message-ID: <5539170B.20903@superduper.net> Date: Thu, 23 Apr 2015 09:00:11 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> <1429710657.18561.68.camel@edumazet-glaptop2.roam.corp.google.com> <25065_1429716388_5537BDA4_25065_2328_1_63pyislbvtjf653k3qt8gw2c.1429715929544@email.android.com> <1429717468.18561.90.camel@edumazet-glaptop2.roam.corp.google.com> <5537CDB7.60301@orange.com> <1429722979.18561.112.camel@edumazet-glaptop2.roam.corp.google.com> <5537DA20.1090008@orange.com> <5537DE4D.8090100@orange.com> <553882D7.4020301@orange.com> <1429771718.22254.32.camel@edumazet-glaptop2.roam.corp.google.com> <1429798255.22254.48.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050301020303030408040504" X-Spam-Score: -2.9 (--) Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in 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, 23 Apr 2015 16:00:45 -0000 This is a multi-part message in MIME format. --------------050301020303030408040504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Same thing applies for WiFi - oftentimes WiFi with poor signal levels will cause drops, without congestion. This is something I'm working to fix from the WiFi / L2 side. What are the solutions in L3? Some kind of hybrid delay & drop based CC? Simon On 4/23/2015 8:52 AM, Jonathan Morton wrote: > > > By curiosity, what is now responsible for the drops if not the > congestion? > > I think the point was not that observed drops are not caused by > congestion, but that congestion doesn't reliably cause drops. > Correlation is not causation. > > There are also cases when drops are in fact caused by something other > than congestion, including faulty ADSL phone lines. Some local loop > providers have been known to explicitly consider several percent of > packet loss due to line conditions as "not a fault", to the > consternation of the actual ISP who was trying to provide a decent > device over it. > > - Jonathan Morton > > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --------------050301020303030408040504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Same thing applies for WiFi - oftentimes WiFi with poor signal levels will cause drops, without congestion. This is something I'm working to fix from the WiFi / L2 side. What are the solutions in L3? Some kind of hybrid delay & drop based CC?

Simon

On 4/23/2015 8:52 AM, Jonathan Morton wrote:

> By curiosity, what is now responsible for the drops if not the congestion?

I think the point was not that observed drops are not caused by congestion, but that congestion doesn't reliably cause drops. Correlation is not causation.

There are also cases when drops are in fact caused by something other than congestion, including faulty ADSL phone lines. Some local loop providers have been known to explicitly consider several percent of packet loss due to line conditions as "not a fault", to the consternation of the actual ISP who was trying to provide a decent device over it.

- Jonathan Morton



_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--------------050301020303030408040504--