From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from trammell.ch (trammell.ch [5.148.172.66]) by huchra.bufferbloat.net (Postfix) with ESMTP id C58D121F1CE; Mon, 2 Mar 2015 06:45:43 -0800 (PST) Received: from [IPv6:2001:470:26:9c2:c174:5cb9:1a28:4f01] (unknown [IPv6:2001:470:26:9c2:c174:5cb9:1a28:4f01]) by trammell.ch (Postfix) with ESMTPSA id E51771A00F4; Mon, 2 Mar 2015 15:45:10 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_26AFCB9D-0C1F-4140-9A90-1860E63FF2F1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Brian Trammell In-Reply-To: <802AFC8C-B59B-4971-A4ED-5C0375E683B1@gmail.com> Date: Mon, 2 Mar 2015 15:45:10 +0100 Message-Id: References: <7B3E53F5-2112-4A50-A777-B76F928CE8F2@trammell.ch> <802AFC8C-B59B-4971-A4ED-5C0375E683B1@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2070.6) X-Mailman-Approved-At: Mon, 02 Mar 2015 06:55:41 -0800 Cc: 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 14:46:12 -0000 --Apple-Mail=_26AFCB9D-0C1F-4140-9A90-1860E63FF2F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 02 Mar 2015, at 11:54, Jonathan Morton = wrote: >=20 >=20 >> On 2 Mar, 2015, at 12:17, Mikael Abrahamsson = wrote: >>=20 >> On Mon, 2 Mar 2015, Brian Trammell wrote: >>=20 >>> Gaming protocols do this right - latency measurement is built into = the protocol. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >=20 > 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. >=20 > For stacks which don=E2=80=99t 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. So there seem to me to be three separate but related problems we want to = solve here: (1) How to get users who don't care what ping is useful information = about their applications' network performance. (2) How to get users who do care what ping is information that actually = reflects application performance when they type ping (or, more = generally, how to make sure that the common diagnostic tools neither (a) = provide misleading information or (b) require network misconfiguration = to ensure "proper" operation of the diagnostic tools (cf. speedtest.net = and its ilk). (3) How to get application developers tools they can use to integrate = network measurement into their apps without having to roll their own = (i.e., helping them to solve (1), and enabling the creation of tools for = (2) ). This is an approach to (3)... but (as with many things) the key to = getting it deployed and used on endpoints would be defining a universal = interface to it. "Yet another API to learn on every platform" =3D=3D = "I'm just going to use ping, thank you very much." > 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=E2=80=99s a concept that can be = used by Linux desktops as well, and with less political fallout. This is, I'm afraid, the kicker. As long as everyone has an interest in = pointing the finger at everyone else, people will choose to interpret = the metrics how they like, and fail to respond to metrics they don't, no = matter how good they are. > Now, who=E2=80=99s going to knuckle down and implement it? web10g.org is a start, for Linux anyway. Cheers, Brian --Apple-Mail=_26AFCB9D-0C1F-4140-9A90-1860E63FF2F1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU9Hd2AAoJENt3nsOmbNJc4s0H/02M37mo08fTRK3vZ3O2nfFe B18qWGthfS7NFcWgOgwDLS6a/fQPx7Cau/fB88qvghWVqh7wRz9HvmNfXLfieAhu 4mNrhluP9J3KGtZ8dG0zR8mNxQ/oJVU5Q8aAIkhZFVnU7av87kvrQWZmrhkPUz/e lkUCnrNHk1pUBcY5J7mFjkb87caHbTnHdKXQSKFuJodJrFvCQl22cgpfMb5ta9ff wUb+oaAnBVXP9un/N7DkG/xkXIl7ysUcgPGyMABozwzBN04yHPfjEUkQbO8LWFO/ yyAs1NSBwA91vc0HuTJ0kiCvG1krjK9Wemnp2/BIfUlrKPfjDUFg2UVma6MGIyI= =LN5U -----END PGP SIGNATURE----- --Apple-Mail=_26AFCB9D-0C1F-4140-9A90-1860E63FF2F1--