From: Michael Welzl <michawe@ifi.uio.no>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Dave Taht <dave.taht@gmail.com>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] the future of tcp - train wreck or evolution?
Date: Thu, 16 Jun 2022 09:27:19 +0200 [thread overview]
Message-ID: <A538F214-E888-467F-8E4D-DE0574A40E98@ifi.uio.no> (raw)
In-Reply-To: <0E865241-B9DF-4383-A99B-4C6BA1D1C467@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
> On Jun 16, 2022, at 9:22 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>
> HI MIchael,
>
>
>> On Jun 16, 2022, at 07:48, Michael Welzl via Bloat <bloat@lists.bufferbloat.net <mailto:bloat@lists.bufferbloat.net>> wrote:
>>
>> … but I’m excited about slide 15 !
>>
>> "Heat, CO2, and radioactive waste are becoming measurable by-products of TCP inefficiency
>> Fix TCP => Save the World!”
>>
>> People don’t yet focus enough on this -
>
> The slide deck however omits presenting the evidence for that hypothesis...
>
>
>
>> and it’s not only relevant in a data center context. See also:
>>
>> Michael Welzl: "Not a Trade-Off: On the Wi-Fi Energy Efficiency of Effective Internet Congestion Control", IEEE/IFIP WONS 2022, virtual, 30 March - 1 April 2022.
>> Preprint: https://folk.universitetetioslo.no/michawe/research/publications/wons2022_authors_version.pdf <https://folk.universitetetioslo.no/michawe/research/publications/wons2022_authors_version.pdf>
>>
>> A couple of IETFs ago, I did sign up to present something along these lines at an ICCRG meeting, but I asked late and got squeezed into an “if time permits” slot; some day in the future I’ll ask for a “proper slot” to elaborate on this.
>
> Curious, should such an observation not look at the aggregate energy consumption of senders and receivers? And maybe also report the total energy consumption of those devices for reference to allow an estimate of how much "radioactive waste" can be easily avoided?
> Mind you, I am not arguing that saving energy (even small amounts) is not desirable, I just want to see how that stacks up with the total energy consumed by those systems.
I completely agree - one just needs to start somewhere. Baby steps :)
Cheers,
Michael
[-- Attachment #2: Type: text/html, Size: 9548 bytes --]
next prev parent reply other threads:[~2022-06-16 7:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 2:35 Dave Taht
2022-06-16 5:48 ` Michael Welzl
2022-06-16 7:22 ` Sebastian Moeller
2022-06-16 7:27 ` Michael Welzl [this message]
2022-06-16 16:39 ` Dave Taht
2022-06-16 20:23 ` Michael Welzl
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=A538F214-E888-467F-8E4D-DE0574A40E98@ifi.uio.no \
--to=michawe@ifi.uio.no \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=moeller0@gmx.de \
/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