General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: "Bjørn Ivar Teigen" <bjorn@domos.no>
To: Michael Richardson <mcr@sandelman.ca>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] PhD thesis with results related to buffering needs on variable-capacity links
Date: Tue, 3 Jan 2023 17:41:36 +0100	[thread overview]
Message-ID: <CAKf5G6L0=NRHugrQcwiqrM4s0QEtwsg0BPbF9GCtW9TmWDRRpw@mail.gmail.com> (raw)
In-Reply-To: <27202.1672758483@localhost>

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

Hi Michael,

On Tue, 3 Jan 2023 at 16:08, Michael Richardson <mcr@sandelman.ca> wrote:

>
> Thank you for sharing your thesis!
>
> Bjørn Ivar Teigen via Bloat wrote:
>     > The thesis begins by investigating which performance issues are most
>     > prevalent in today's WiFi networks. We show that both queuing latency
>     > and the WiFi protocol specification itself are significant
>     > contributors. By building a model of the WiFi protocol behavior we
>     > quantify the performance of the protocol in terms of quality
>     > attenuation. We find that significant performance variability is an
>     > inherent consequence of the protocol design.
>
> I guess that your thesis is mostly technical.
> (I haven't clicked on the link yet)
>
You are right. It is focused on analyzing models of the WiFi MAC layer to
calculate how good (or bad!) latency and packet loss gets in various
scenarios, and how that latency and packet loss in turn affects congestion
control algorithms.

>
> I wonder if there is work that might occur from the business department end
> of things.  Why do we have 15 years of WiFi optimization, which seem to be
> taking us further away from low latency.  Are the new protocols actually
> improving the situation for the end consumer?  My impression is no.
> Nobody notices because the quality is so unpredictable.
>

Through my work in Domos I have at least some insight into this. My
impression is that it starts with business decisions, where the focus has
been on maximum throughput numbers because that's what consumers think they
want. It also takes effort, focus, and (most importantly) money to remove
bufferbloat, so unless there is sufficient incentives from the commercial
side of things it doesn't happen.
I do think there is increasing awareness of latency (under load) as an
important factor for user experience. We certainly see that from some of
the (dare I say thought-leading) ISPs we're working with.

I think there's hope we will see more good low-latency solutions deployed
in the near future.

Cheers,
-- 
Bjørn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no <name@domos.no> | www.domos.no

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

  reply	other threads:[~2023-01-03 16:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03  9:57 Bjørn Ivar Teigen
2023-01-03 15:08 ` Michael Richardson
2023-01-03 16:41   ` Bjørn Ivar Teigen [this message]
2023-01-04  7:08     ` Taraldsen Erik
2023-01-03 23:52 ` Toke Høiland-Jørgensen

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='CAKf5G6L0=NRHugrQcwiqrM4s0QEtwsg0BPbF9GCtW9TmWDRRpw@mail.gmail.com' \
    --to=bjorn@domos.no \
    --cc=bloat@lists.bufferbloat.net \
    --cc=mcr@sandelman.ca \
    /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