From: Jonathan Morton <chromatix99@gmail.com>
To: erik.taraldsen@telenor.com
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Bufferbloat on 4G Connexion
Date: Thu, 24 Oct 2019 15:14:25 +0300 [thread overview]
Message-ID: <92FE162A-653A-4E6B-BC2F-3A2AB873939E@gmail.com> (raw)
In-Reply-To: <1571917896021.11761@telenor.com>
> On 24 Oct, 2019, at 2:51 pm, <erik.taraldsen@telenor.com> <erik.taraldsen@telenor.com> wrote:
>
>> The key thing in both BQL and AQL is that instead of treating all packets the
>> same, you account for how long it will take to transmit them.
>>
>> In Wifi, your transmission rate can vary by a factor of 1000x (1Mb to over 1Gb
>> per second), so just counting bytes as BQL does is no longer good enough.
>>
>> how much does the actual over-the-air transmission rate vary in 4G? I'd bet that
>> it varies less than wifi does because wifi must retain compatibility with the
>> earliest equipment while 4G no longer supports 2G protocols.
>
> So in a scenario with a fixed (wall mounted outdoor unit) LTE device BQL could work
> quite well as the radio will not fluctuate too much.
>
> But for a mobil "pocket router" being carried around an AQL approach would be needed?
Even in a fixed application, there's a lot of variation in where the unit is installed - from practically underneath the cell site tower to several miles away behind some trees - and service outages at the primary cell site could cause large, temporary changes of link bandwidth as the unit switches to a more distant cell. Also, over the course of a day I personally observe tenfold variations in available bandwidth due to congestion at peak times, though I'm not quite certain whether that's due to radio contention on this particular cell site, or on my ISP's backhaul.
AQL would correct for these variations automatically. All it needs in addition to BQL is some indication of how many bytes are appropriate to queue in the hardware at any given moment.
- Jonathan Morton
next prev parent reply other threads:[~2019-10-24 12:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.865.1571824497.1240.bloat@lists.bufferbloat.net>
2019-10-23 11:56 ` Rich Brown
2019-10-23 12:27 ` Toke Høiland-Jørgensen
2019-10-24 7:26 ` Luca Muscariello
2019-10-24 9:34 ` Toke Høiland-Jørgensen
2019-10-24 12:55 ` Luca Muscariello
2019-10-24 14:02 ` Toke Høiland-Jørgensen
2019-10-23 17:52 ` David Lang
2019-10-24 11:51 ` erik.taraldsen
2019-10-24 12:14 ` Toke Høiland-Jørgensen
2019-10-24 12:14 ` Jonathan Morton [this message]
2019-10-11 14:56 Guillaume ROBIER
2019-10-22 21:02 ` Jonathan Morton
2019-10-23 7:28 ` erik.taraldsen
2019-10-23 8:24 ` David Lang
2019-10-23 8:37 ` Sebastian Moeller
2019-10-23 9:54 ` Jonathan Morton
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=92FE162A-653A-4E6B-BC2F-3A2AB873939E@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=erik.taraldsen@telenor.com \
/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