From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (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 D1F7121F286 for ; 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" 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: <7B3E53F5-2112-4A50-A777-B76F928CE8F2@trammell.ch> <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 Cc: Brian Trammell , bloat , "aqm@ietf.org" , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] [Bloat] [aqm] 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: Mon, 02 Mar 2015 12:44:48 -0000 On my own web server (running nginx) I provide an HTTP 1.1 accessible stati= stics service. It returns a single JSON structure with the underlying pack= et 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 sta= tistics and a single-round-trip "ping" that can measure queue delay on dema= nd.=0A=0AChanging 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 measu= rements of the client side must be obtained indirectly, but simple JavaScri= pt code in a web page can access this with standard HTML5 code.=0A=0AI'm no= t looking to support this code or enhance it. I've thought about putting i= t up on GitHub.=0A=0AIn any case, it's easy to add a little widget to the c= orner of all the web pages from a site that displays latency and net statis= tics at various levels in a very pretty user-understandable form.=0A=0ATo s= ee how this works, just go to the alt.reed.com site (preferably using an iP= hone or Android phone) to see a trivial test app I put out a number of year= s ago for my personal zeroth-order diagnostics.=0A=0Anginx (as most know) i= s an incredibly tight, low overhead HTTP 1.1 server that lets you add plugi= ns 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 HT= TPS quite well, too.=0A=0A=0A=0A=0AOn Monday, March 2, 2015 5:54am, "Jonath= an Morton" said:=0A=0A> =0A>> On 2 Mar, 2015, at 12= :17, Mikael Abrahamsson wrote:=0A>>=0A>> On Mon, 2 Mar 2= 015, Brian Trammell wrote:=0A>>=0A>>> Gaming protocols do this right - late= ncy measurement is built into the protocol.=0A>>=0A>> I believe this is the= only way to do it properly, and the most likely easiest way=0A>> to get th= is deployed would be to use the TCP stack.=0A>>=0A>> We need to give users = an easy-to-understand metric on how well their Internet=0A>> traffic is wor= king. So the problem here is that the users can't tell how well=0A>> it's w= orking without resorting to ICMP PING to try to figure out what's going on.= =0A>>=0A>> For instance, if their web browser had insight into what the TCP= stack was doing=0A>> then it could present information a lot better to the= user. Instead of telling=0A>> the user "time to first byte" (which is L4 i= nformation), it could tell the less=0A>> novice user about packet loss, PDV= , reordering, RTT, how well concurrent=0A>> connections to the same IP addr= ess are doing, tell more about *why* some=0A>> connections are slow instead= of just saying "it took 5.3 seconds to load this=0A>> webpage and here are= the connections and how long each took". For the novice user=0A>> there sh= ould be some kind of expert system that collects data that you can send=0A>= > to the ISP that also has an expert system to say "it seems your local con= nection=0A>> delays packets", please connect to a wired connection and try = again". It would=0A>> know if the problem was excessive delay, excessive de= lay that varied a lot,=0A>> packet loss, reordering, or whatever.=0A>>=0A>>= We have a huge amount of information in our TCP stacks that either are loc= ked in=0A>> there and not used properly to help users figure out what's goi= ng on, and there=0A>> is basically zero information flow between the applic= ations using TCP and the TCP=0A>> stack itself. Each just tries to do its b= est on its own layer.=0A> =0A> This seems like an actually good idea. Seve= ral of those statistics, at least,=0A> could be exposed to userspace withou= t incurring any additional overhead in the=0A> stack (except for the querie= s themselves), which is important for high-performance=0A> server users. T= CP stacks already track RTT, and sometimes MinRTT - the difference=0A> betw= een these values is a reasonable lower-bound estimate of induced latency.= =0A> =0A> For stacks which don=E2=80=99t already track all the desirable da= ta, a socket option=0A> could be used to turn that on, allocating extra spa= ce to do so. To maximise=0A> portability, therefore, it might be necessary= to require that option before=0A> statistics requests will be valid, even = on stacks which do collect it all anyway.=0A> =0A> Recent versions of Windo= ws, even, have a semi-magic system which gives a little=0A> indicator of wh= ether your connection has functioning Internet connectivity or not.=0A> Th= is could be extended, if Microsoft saw fit, to interpret these statistics a= nd=0A> notify the user that their connection was behaving badly in the ways= we now find=0A> interesting. Whether Microsoft will do such a thing (whic= h would undoubtedly piss=0A> off every major ISP on the planet) is another = matter, but it=E2=80=99s a concept=0A> that can be used by Linux desktops a= s well, and with less political fallout.=0A> =0A> Now, who=E2=80=99s going = to knuckle down and implement it?=0A> =0A> - Jonathan Morton=0A> =0A> ____= ___________________________________________=0A> Cerowrt-devel mailing list= =0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://lists.bufferbloat.net/= listinfo/cerowrt-devel=0A> =0A