From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from complete.lackof.org (complete.lackof.org [198.49.126.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.lackof.org", Issuer "CAcert Class 3 Root" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CBB8421F3E8; Thu, 5 Mar 2015 12:38:12 -0800 (PST) Received: from taggart.lackof.org (c-67-183-84-60.hsd1.wa.comcast.net [67.183.84.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "taggart.lackof.org", Issuer "CAcert Class 3 Root" (verified OK)) by complete.lackof.org (Postfix) with ESMTPS id B7F7D33E00F5; Thu, 5 Mar 2015 13:38:09 -0700 (MST) Received: by taggart.lackof.org (Postfix, from userid 1000) id 0818D1F1; Thu, 5 Mar 2015 12:38:13 -0800 (PST) X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0-4) with nmh-1.6 From: Matt Taggart To: Dave Taht In-reply-to: References: Comments: In-reply-to Dave Taht message dated "Sun, 01 Mar 2015 19:57:37 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Mar 2015 12:38:13 -0800 Message-Id: <20150305203813.0818D1F1@taggart.lackof.org> X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on complete.lackof.org Cc: "aqm@ietf.org" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] ping loss "considered harmful" X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 20:38:41 -0000 Dave Taht writes: > wow. It never registered to me that users might make a value judgement > based on the amount of ping loss, and in looking back in time, I can > think of multiple people that have said things based on their > perception that losing pings was bad, and that sqm-scripts was "worse > than something else because of it." This thread makes me realize that my standard method of measuring latency over time might have issues. I use smokeping http://oss.oetiker.ch/smokeping/ which is a really nice way of measuring and visualizing packet loss and variations in latency. I am using the default probe type which uses fping (ICMP http://www.fping.org/ ). It has been working well, I set it up for a site in advance of setting up SQM and then afterwards I can see the changes and determine if more tuning is needed. But if ICMP is having it's priority adjusted (up or down), then the results might not reflect the latency of other services. Fortunately the nice thing is that many other probe types exist http://oss.oetiker.ch/smokeping/probe/index.en.html So which probe types would be good to use for bufferbloat measurement? I guess the answer is "whatever is important to you", but I also suspect there is a set of things that ISPs are known to mess with. HTTP? But also maybe HTTPS in case they are doing some sort of transparent proxy? DNS? SIP? I suppose you could even do explicit checks for things like Netflix (but then it's easy to go off on a tangent of building a net neutrality observatory). On a somewhat related note, I was once using smokeping to measure a fiber link to a bandwidth provider and had it configured to ping the router IP on the other side of the link. In talking to one of their engineers, I learned that they deprioritize ICMP when talking _with_ their routers, so my measurement weren't valid. (I don't know if they deprioritize ICMP traffic going _through_ their routers) -- Matt Taggart matt@lackof.org