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

dpreed@reed.com Mon, 02 March 2015 12:44 UTC

Return-Path: <dpreed@reed.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427C01A7017 for <aqm@ietfa.amsl.com>; Mon, 2 Mar 2015 04:44:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy9ag80SCc-Y for <aqm@ietfa.amsl.com>; Mon, 2 Mar 2015 04:44:19 -0800 (PST)
Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3830C1A001A for <aqm@ietf.org>; Mon, 2 Mar 2015 04:44:19 -0800 (PST)
Received: from smtp10.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6E17F280346; Mon, 2 Mar 2015 07:44:18 -0500 (EST)
Received: from app31.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 446EA28027F; Mon, 2 Mar 2015 07:44:18 -0500 (EST)
X-Sender-Id: dpreed@reed.com
Received: from app31.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Mon, 02 Mar 2015 12:44:18 GMT
Received: from reed.com (localhost.localdomain [127.0.0.1]) by app31.wa-webapps.iad3a (Postfix) with ESMTP id 2ECB080012; Mon, 2 Mar 2015 07:44:18 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 2 Mar 2015 07:44:18 -0500 (EST)
Date: Mon, 2 Mar 2015 07:44:18 -0500 (EST)
From: dpreed@reed.com
To: "Jonathan Morton" <chromatix99@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: <802AFC8C-B59B-4971-A4ED-5C0375E683B1@gmail.com>
References: <CAA93jw7KW=9PH002d3Via5ks6+mHScz5VDhpPVqLUGK2K=Mhew@mail.gmail.com> <7B3E53F5-2112-4A50-A777-B76F928CE8F2@trammell.ch> <alpine.DEB.2.02.1503021108270.20507@uplift.swm.pp.se> <802AFC8C-B59B-4971-A4ED-5C0375E683B1@gmail.com>
X-Auth-ID: dpreed@reed.com
Message-ID: <1425300258.188832362@apps.rackspace.com>
X-Mailer: webmail/11.3.13-RC
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/6z6tdpLeeJltZZIcEUJKTf_pi6c>
Cc: Brian Trammell <ietf@trammell.ch>, bloat <bloat@lists.bufferbloat.net>, "aqm@ietf.org" <aqm@ietf.org>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>, Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: [aqm] [Cerowrt-devel] [Bloat] ping loss "considered harmful"
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2015 12:44:21 -0000

On my own web server (running nginx) I provide an HTTP 1.1 accessible statistics service.  It returns a single JSON structure with the underlying packet statistics for the server and the current connection. Since this packet is inserted into the HTTP 1.1 stream upon request, it provides both the statistics and a single-round-trip "ping" that can measure queue delay on demand.

Changing server code is a lot easier than changing browser code.  Anyone who would like to develop a "standards-track" option for HTTP 1.1 is quite welcome to do so...  right now it is a "RESTful" interface, so measurements of the client side must be obtained indirectly, but simple JavaScript code in a web page can access this with standard HTML5 code.

I'm not looking to support this code or enhance it.  I've thought about putting it up on GitHub.

In any case, it's easy to add a little widget to the corner of all the web pages from a site that displays latency and net statistics at various levels in a very pretty user-understandable form.

To see how this works, just go to the alt.reed.com site (preferably using an iPhone or Android phone) to see a trivial test app I put out a number of years ago for my personal zeroth-order diagnostics.

nginx (as most know) is an incredibly tight, low overhead HTTP 1.1 server that lets you add plugins for lots of things other than retrieving web pages from disk.  It's not the pile of spaghetti that Apache has become. It supports WebSockets and HTTPS quite well, too.




On Monday, March 2, 2015 5:54am, "Jonathan Morton" <chromatix99@gmail.com> said:

> 
>> On 2 Mar, 2015, at 12:17, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>>
>> On Mon, 2 Mar 2015, Brian Trammell wrote:
>>
>>> Gaming protocols do this right - latency measurement is built into the protocol.
>>
>> I believe this is the only way to do it properly, and the most likely easiest way
>> to get this deployed would be to use the TCP stack.
>>
>> We need to give users an easy-to-understand metric on how well their Internet
>> traffic is working. So the problem here is that the users can't tell how well
>> it's working without resorting to ICMP PING to try to figure out what's going on.
>>
>> For instance, if their web browser had insight into what the TCP stack was doing
>> then it could present information a lot better to the user. Instead of telling
>> the user "time to first byte" (which is L4 information), it could tell the less
>> novice user about packet loss, PDV, reordering, RTT, how well concurrent
>> connections to the same IP address are doing, tell more about *why* some
>> connections are slow instead of just saying "it took 5.3 seconds to load this
>> webpage and here are the connections and how long each took". For the novice user
>> there should be some kind of expert system that collects data that you can send
>> to the ISP that also has an expert system to say "it seems your local connection
>> delays packets", please connect to a wired connection and try again". It would
>> know if the problem was excessive delay, excessive delay that varied a lot,
>> packet loss, reordering, or whatever.
>>
>> We have a huge amount of information in our TCP stacks that either are locked in
>> there and not used properly to help users figure out what's going on, and there
>> is basically zero information flow between the applications using TCP and the TCP
>> stack itself. Each just tries to do its best on its own layer.
> 
> This seems like an actually good idea.  Several of those statistics, at least,
> could be exposed to userspace without incurring any additional overhead in the
> stack (except for the queries themselves), which is important for high-performance
> server users.  TCP stacks already track RTT, and sometimes MinRTT - the difference
> between these values is a reasonable lower-bound estimate of induced latency.
> 
> For stacks which don’t already track all the desirable data, a socket option
> could be used to turn that on, allocating extra space to do so.  To maximise
> portability, therefore, it might be necessary to require that option before
> statistics requests will be valid, even on stacks which do collect it all anyway.
> 
> Recent versions of Windows, even, have a semi-magic system which gives a little
> indicator of whether your connection has functioning Internet connectivity or not.
>  This could be extended, if Microsoft saw fit, to interpret these statistics and
> notify the user that their connection was behaving badly in the ways we now find
> interesting.  Whether Microsoft will do such a thing (which would undoubtedly piss
> off every major ISP on the planet) is another matter, but it’s a concept
> that can be used by Linux desktops as well, and with less political fallout.
> 
> Now, who’s going to knuckle down and implement it?
> 
>  - Jonathan Morton
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>