From: David Lang <david@lang.hm>
To: "David P. Reed" <dpreed@deepplum.com>
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] SIGCOMM MIT paper: Starvation in e2e congestion control
Date: Mon, 8 Aug 2022 15:37:42 -0700 (PDT) [thread overview]
Message-ID: <3n65o07q-p244-7032-q2ps-7391s6621qp4@ynat.uz> (raw)
In-Reply-To: <1659994794.324713695@apps.rackspace.com>
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
To quote from Tom Clancy (Hunt for Red Octover IIRC), it's possible to both
increase security and increase access as a marine at a gate beats a padlock for
both
In computer security especially there are many examples of things that increase
security while decreasing error, increasing availablity, and (overall)
decreasing cost.
sometimes it's 'pick 2', but all to frequently people actually opt for 'none of
the above' (i.e. sub-optimal in all areas)
David Lang
On Mon, 8 Aug 2022, David P. Reed via Starlink wrote:
> 2) I absolutely hate folks who invent "theorems" that say you can have "any two of three" properties. It's become popular in computer systems research, but it actually creates a huge intellectual mess.
> The CAP theorem, for example has some very peculiar definitions in order to make C, A, and P "independent" axes. Of course they are NOT independent in engineering practice. In fact, they aren't even "binary" - there's no "yes" or "no" to C, A or P - they are not even spectra that map to some increasing sequence.
> Yes, you can't always get what you want. But you can almost always get what you need, and that is never a specific two out of three.
> Especially not in queue management algorithms.
> Goddamn cutesy anti-intellectuals.
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
next prev parent reply other threads:[~2022-08-08 22:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.3.1659715201.24001.starlink@lists.bufferbloat.net>
2022-08-08 21:39 ` David P. Reed
2022-08-08 22:37 ` David Lang [this message]
2022-08-08 22:41 ` Dave Taht
2022-08-11 14:29 ` Hesham ElBakoury
2022-08-17 21:34 ` Dave Taht
[not found] <mailman.562.1660228174.1281.starlink@lists.bufferbloat.net>
2022-08-11 19:34 ` David P. Reed
2022-08-11 20:22 ` Ulrich Speidel
2022-08-11 20:24 ` Ulrich Speidel
2022-08-12 14:21 ` Livingood, Jason
2022-08-12 14:23 ` Hesham ElBakoury
2022-08-25 20:26 ` Dave Taht
2022-08-04 19:05 Dave Taht
2022-08-07 4:28 ` Venkat Arun
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/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3n65o07q-p244-7032-q2ps-7391s6621qp4@ynat.uz \
--to=david@lang.hm \
--cc=dpreed@deepplum.com \
--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