Re: [Cerowrt-devel] [Bloat] [aqm] ping loss "considered harmful"

[Rich Brown <richb.hanover@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]


On Mar 5, 2015, at 1:56 PM, Curtis Villamizar <curtis@ipv6.occnc.com> wrote:

> In message <CAA93jw4F7iffbTRUt5RFsF0wgoOAXPUVHdu7JESVq4uM17cm7A@mail.gmail.com>
> 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... 

For an easy (but imprecise) way test the HTTP response times, try Blip - http://gfblip.appspot.com/ (or read about it on github: https://github.com/apenwarr/blip) Blip sends short http requests to a couple hosts and measures the response time of the error pages. 

> 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
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]