General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Matt Mathis <mattmathis@google.com>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
Cc: bloat <bloat@lists.bufferbloat.net>,
	 "rpm@lists.bufferbloat.net" <rpm@lists.bufferbloat.net>
Subject: Re: [Bloat] [Rpm] Airbnb
Date: Mon, 16 Aug 2021 10:00:17 -0700	[thread overview]
Message-ID: <CAH56bmAMGRHwVSnRFf5CcJPgw=TFBpNN5gfgE3MSxddVdpB_RA@mail.gmail.com> (raw)
In-Reply-To: <7D90BFF4-3A67-4A96-B0B0-37B41A72A4B5@cable.comcast.com>

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

I think you misunderstood:  The metric that I am testing can be computed in
real time within the current NDT (the only wire change is to carry an
additional result in the progress reports) and across our entire archive,
including both web100 and tcp_info data.  Furthermore it can be
validated/calibrated by counting actual network rounds, reconstructed from
packet captures.  However it does not include the OS contribution, which
can have a huge impact on the responsiveness seen by the user.

The MIT paper boosts another item that has been on my forever todo list:
add automated diagnostic analysis to NDT.  Ideally, NDT could localize the
bottleneck:

   - Client (e.g. insufficient CPU or buffers)
   - Last yard (WiFi)
   - Last  Mile (Access provider)
   - Middle mile (Interconnects)
   - Server load

(The original NDT did a limited version of something like this.  Most of
the above have well known signatures, except there are some really
weird corner cases.)   We could then better inform the user ("Fix your
WiFi"), and label the data in the archive according to the nature of the
likely bottleneck.


Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.


On Fri, Aug 13, 2021 at 11:59 AM Livingood, Jason <
Jason_Livingood@comcast.com> wrote:

> Great news, Matt! If I may make a recommendation, IMO a standalone working
> latency test would have greater utility than integrating such a measurement
> into an existing test & so it may have the opportunity of more widespread
> usage.
>
>
>
> JL
>
>
>
> *From: *Bloat <bloat-bounces@lists.bufferbloat.net> on behalf of Matt
> Mathis via Bloat <bloat@lists.bufferbloat.net>
> *Reply-To: *Matt Mathis <mattmathis@google.com>
> *Date: *Tuesday, August 10, 2021 at 00:52
> *To: *"dave.collier-brown@indexexchange.com" <
> dave.collier-brown@indexexchange.com>
> *Cc: *bloat <bloat@lists.bufferbloat.net>
> *Subject: *Re: [Bloat] [Rpm] Airbnb
>
>
>
> I am part of the M-Lab team.
>
>
>
> For years we published a "jitter" metric that I considered to be bogus,
> basically max_rtt - min_rtt, (which were builtin Web100 instruments).
>
>
>
> In 2019, we transitioned from web100 to "standard" linux tcp_info, which
> does not capture max_rtt.   Since the web100 jitter was viewed as bogus, we
> did not attempt to reconstruct it, although we could have.   Designing and
> implementing a new latency metric was on my todo list from the beginning of
> that transition, but chronically preempted by more pressing problems.
>
>
>
> It finally made it to the top of my queue which is why I am suddenly not
> lurking here and the new rpm list.  I was very happy to see the Apple
> responsiveness metric, and realized that M-Lab can implement a TCP
> version of it, that can be computed both in real time on future tests and
> retroactively over archived tests collected over the last 12 years.
>
>
>
> This quick paper might be of interest: *Preliminary Longitudinal Study of
> Internet Responsiveness*
> <https://urldefense.com/v3/__https:/docs.google.com/document/d/1HkeJTgwLdbbdHe0dF9SWrpr8Vt7ngnovLpdDTScuUtk/edit*heading=h.sy6m01i6oa9a__;Iw!!CQl3mcHX2A!WTavRmT2GnSUSVpvPCPdmBuNtOJI_zDP1WOHE-jy8tMiXBE-CxDospZUjNote1PXn0DhWQ$>
>
> .
>
> Thanks,
>
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
> We must not tolerate intolerance;
>
>        however our response must be carefully measured:
>
>             too strong would be hypocritical and risks spiraling out of
> control;
>
>             too weak risks being mistaken for tacit approval.
>
>
>
>
>
> On Mon, Aug 9, 2021 at 5:27 PM Dave Collier-Brown <
> dave.collier-brown@indexexchange.com> wrote:
>
> Knowing programmers, I'd more likely assume latency when it's easiest to
> measure. At a guess, either
>
>    - average of upload or download
>    - average of download (as it comes first)
>
> --dave (call me "Wally" (:-)) c-b
>
>
>
> On 2021-08-09 4:24 p.m., Jonathan Morton wrote:
>
> On 9 Aug, 2021, at 10:25 pm, Dave Collier-Brown <dave.collier-brown@indexexchange.com> <dave.collier-brown@indexexchange.com> wrote:
>
>
>
> My run of it reported latency, but without any qualifiers...
>
> One would reasonable assume that's idle latency, then.
>
>
>
>  - Jonathan Morton
>
> _______________________________________________
>
> Bloat mailing list
>
> Bloat@lists.bufferbloat.net
>
> https://lists.bufferbloat.net/listinfo/bloat <https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!WTavRmT2GnSUSVpvPCPdmBuNtOJI_zDP1WOHE-jy8tMiXBE-CxDospZUjNote1Oa4DQV1Q$>
>
> --
>
> David Collier-Brown,         | Always do right. This will gratify
>
> System Programmer and Author | some people and astonish the rest
>
> dave.collier-brown@indexexchange.com |              -- Mark Twain
>
>
>
> *CONFIDENTIALITY NOTICE AND DISCLAIMER** : This telecommunication,
> including any and all attachments, contains confidential information
> intended only for the person(s) to whom it is addressed. Any dissemination,
> distribution, copying or disclosure is strictly prohibited and is not a
> waiver of confidentiality. If you have received this telecommunication in
> error, please notify the sender immediately by return electronic mail and
> delete the message from your inbox and deleted items folders. This
> telecommunication does not constitute an express or implied agreement to
> conduct transactions by electronic means, nor does it constitute a contract
> offer, a contract amendment or an acceptance of a contract offer. Contract
> terms contained in this telecommunication are subject to legal review and
> the completion of formal documentation and are not binding until same is
> confirmed in writing and has been signed by an authorized signatory.*
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> <https://urldefense.com/v3/__https:/lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!WTavRmT2GnSUSVpvPCPdmBuNtOJI_zDP1WOHE-jy8tMiXBE-CxDospZUjNote1Oa4DQV1Q$>
>
>

[-- Attachment #2: Type: text/html, Size: 10876 bytes --]

  reply	other threads:[~2021-08-16 17:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BY5PR11MB42574D4BBC71FF2049F7E544DEEC9@BY5PR11MB4257.namprd11.prod.outlook.com>
2021-08-07 18:57 ` [Bloat] Fwd: Airbnb Dave Taht
2021-08-09 16:44   ` [Bloat] [Rpm] Airbnb oesh
2021-08-09 19:25     ` Dave Collier-Brown
2021-08-09 20:24       ` Jonathan Morton
2021-08-10  0:27         ` Dave Collier-Brown
2021-08-10  4:51           ` Matt Mathis
2021-08-10 11:51             ` Jonathan Morton
2021-08-13 18:58             ` Livingood, Jason
2021-08-16 17:00               ` Matt Mathis [this message]
2021-08-13 18:56   ` [Bloat] Fwd: Airbnb Livingood, Jason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH56bmAMGRHwVSnRFf5CcJPgw=TFBpNN5gfgE3MSxddVdpB_RA@mail.gmail.com' \
    --to=mattmathis@google.com \
    --cc=Jason_Livingood@comcast.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=rpm@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox