revolutions per minute - a new metric for measuring responsiveness
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: Dave Taht <dave.taht@gmail.com>, Rpm <rpm@lists.bufferbloat.net>,
	 Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
	 bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Rpm] [Bloat] retransmit cost over cellular
Date: Mon, 18 Sep 2023 12:17:19 -0700 (PDT)	[thread overview]
Message-ID: <po0s1p0q-n393-5437-66o2-n56nn748n8pn@ynat.uz> (raw)
In-Reply-To: <874jjrsmc8.wl-jch@irif.fr>

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

what apps do you have on the phone and what are they configured to update? that 
will make a huge difference.

'idle' probably isn't nearly as passive as you think it is.

David Lang

On Mon, 18 Sep 2023, Juliusz Chroboczek via Bloat wrote:

> Hi Dave!
>
>> https://nickvsnetworking.com/mobile-ipv6-tax/
>
> « This means my Android phone consumes 4.5 MB of cellular data in an hour
>  while sitting on the desk, with 16,889 packets in/out. »
>
> So even discounting the headers, the phone receives 70 Commodore C64 worth
> of data when idle.  Every freaking hour.
>
> « We have 16,889 packets, 6,417,732 bytes in total, minus 97 bytes from
>  each gives us 1,638,233 of headers to drop (~1.6MB) giving us a total of
>  4.556 MB traffic to/from the phone itself. »
>
> The average packet size is 269 bytes.  Even if we assume that every second
> packet is a pure ACK, that's still on the order of just 500 bytes for data
> packets.
>
> Conclusions:
>
> 1. The amount of data being received is outrageous, which indicates the
>   use of JSON or XML to encode the data.  (See RFC 3252.)  (Just kidding,
>   please see RFC 8949 instead.)
>
> 2. The packet size is small, which indicates the use of a chatty REST-like
>   API rather than a streaming protocol.  The use of streaming has been
>   known since at least the 1970s, and well-documented since the 1990s.
>   For example, both IMAPv4 and Caldav can do streaming synchronisation
>   just fine.
>
> 3. The « IPv6 tax » could be reduced by 70% if the packets were reasonably
>   sized.  By 90% if the application-layer protocol were efficient enough
>   to allow delack to trigger.
>
> Conclusion of the conclusions:
>
> 4. The « IPv6 tax » is negligible when compared to the JSON/XML/REST tax.
>
> -- Juliusz
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

  reply	other threads:[~2023-09-18 19:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-17 19:12 [Rpm] " Dave Taht
2023-09-17 22:09 ` Robert McMahon
2023-09-18 12:21 ` [Rpm] [Bloat] " Juliusz Chroboczek
2023-09-18 19:17   ` David Lang [this message]
2023-09-18 19:37     ` Juliusz Chroboczek

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/rpm.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=po0s1p0q-n393-5437-66o2-n56nn748n8pn@ynat.uz \
    --to=david@lang.hm \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=jch@irif.fr \
    --cc=rpm@lists.bufferbloat.net \
    --cc=starlink@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