> On 24 Oct, 2019, at 2:51 pm, <erik.tarald...@telenor.com> > <erik.tarald...@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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
