From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from maildrop31.somerville.occnc.com (bh3vm1.somerville.occnc.com [192.34.84.171]) (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 103B021F3DB; Thu, 5 Mar 2015 11:00:32 -0800 (PST) Received: from harbor31.somerville.occnc.com (harbor31.somerville.occnc.com [IPv6:2001:4830:c400:203::3231]) (authenticated bits=128) by maildrop31.somerville.occnc.com (8.14.9/8.14.9) with ESMTP id t25IuXok099060; Thu, 5 Mar 2015 13:56:34 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201503051856.t25IuXok099060@maildrop31.somerville.occnc.com> To: Dave Taht From: Curtis Villamizar In-reply-to: Your message of "Tue, 03 Mar 2015 21:24:59 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99058.1425581793.1@harbor31.somerville.occnc.com> Content-Transfer-Encoding: quoted-printable Date: Thu, 05 Mar 2015 13:56:33 -0500 X-Spam-Status: No, score=-101.5 required=5.0 tests=ALL_TRUSTED,MISSING_MID, RP_MATCHES_RCVD, USER_IN_WHITELIST autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on maildrop31.somerville.occnc.com X-Mailman-Approved-At: Thu, 05 Mar 2015 11:14:36 -0800 Cc: Wesley Eddy , bloat , "Fred Baker \(fred\)" , "cerowrt-devel@lists.bufferbloat.net" , "aqm@ietf.org" Subject: Re: [Cerowrt-devel] [aqm] [Bloat] ping loss "considered harmful" X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: curtis@ipv6.occnc.com 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 19:01:01 -0000 In message Dave Taht writes: = > My point was A), I have seen tons of shapers out there that actually > prioritize ping over other traffic. I figure everyone here will agree > that is a terrible practice, but I can certainly say it exists, as it > is a dumb mistake replicated in tons of shapers I have seen... that > makes people in marketing happy. > = > Already put up extensive commentary on that bit of foolishness on > "wondershaper must die". Its possible to detect such a shaper prioritizing ICMP echo/reply by doing a an HTTP fetch concurrent with a ping and then and see if the TCP data packet get significantly delayed relative to the ICMP echo and echo reply packets. You'd have to do a tcpdump and match the ICMP echo to the echo reply and see if later the ICMP RTT looks very different from the TCP RTT. It might be that the SYN and SYN ACK are not delayed but the plain old TCP date packets are. If anyone has a small amount of spare time and wants to put together a shell script its certainly doable. Curtis