Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Hesham ElBakoury <helbakoury@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] SIGCOMM MIT paper: Starvation in e2e congestion control
Date: Fri, 12 Aug 2022 07:23:22 -0700	[thread overview]
Message-ID: <ff84f8e6-a658-1290-8b69-29e5656cef25@gmail.com> (raw)
In-Reply-To: <717DCEA7-7701-462B-B5F1-D789531D34B0@cable.comcast.com>

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

I already notified the authors.

Hesham

On 8/12/2022 7:21 AM, Livingood, Jason via Starlink wrote:
>
> IMO this is all good feedback for the authors to have. I don’t know 
> them but will send them a note that this list may have feedback on the 
> paper as well as for future research*.
>
> JL
>
> * I will also note that this research is the kind of thing a grant 
> program I lead at work might be interested in for 2023.
>
> *From: *Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of 
> "David P. Reed via Starlink" <starlink@lists.bufferbloat.net>
> *Reply-To: *"David P. Reed" <dpreed@deepplum.com>
> *Date: *Thursday, August 11, 2022 at 15:34
> *To: *"starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
> *Subject: *Re: [Starlink] SIGCOMM MIT paper: Starvation in e2e 
> congestion control
>
> On Thursday, August 11, 2022 10:29am, 
> starlink-request@lists.bufferbloat.net said:
>
> > From: Hesham ElBakoury <helbakoury@gmail.com>
> > To: "David P. Reed" <dpreed@deepplum.com>,
> > starlink@lists.bufferbloat.net
> > Subject: Re: [Starlink] SIGCOMM MIT paper: Starvation in e2e
> > congestion control
> >
> > Hi David,
> >
> > I think someone such as Professor Hari who got many awards including the
> > sigcomm 2021 life-achievement award or his student Venkat need to be
> > educated on Fair Queuing. There are many publications and text books
> > which describe FQ. The results of this paper is for network paths that
> > do not use FQ or ECN. Venkat/Hari can provide more details.
>
> I would think that he knows about FQ in AQM, too. He should.
>
> My point is that this paper, which talks about *starvation*, doesn't 
> mention FQ at all, even though it is well known to mitigate 
> "starvation effects" - it was invented to solve exactly that problem!
>
> I'd suggest at minimum that the paper should point out that it 
> *excludes* FQ from consideration. And if possible, explain why it was 
> excluded...
>
> I can think of reasons for excluding FQ in the specific paper, but 
> shouldn't the title and abstract say  it applies only narrowly: 
> Proposed revised title: "Starvation in e2e congestion control if FQ is 
> excluded within the network"
>
> Particularly since the paper makes *broad* generalizations - the only 
> 2-out-of-3 argument is stated as if it applies to ALL congestion control.
>
> >
> > For the CAP theorem, do you think I can get C,A,P, if this is what I
> > need ? if this is the case, then this theorem is wrong or has limited
> > applicability, correct ?
>
> It has limited applicability for sure. Yet, it has become fashionable 
> to act as if it is a completely general truth.
>
> The CAP theorem, in the limited space of its assumptions, appears to 
> be correct. But because it is so easily trivialized, as encouraged by 
> the "you can have any two of C A an P, but not 3" without any 
> qualification, problems with the definitions of the words C A and P - 
> serious problems indeed that matter to a first order in real 
> distributed systems - it is often used to derive "impossibility".
>
> I'll give you another example of a serious misuse of a theorem outside 
> its range of applicability:
>
> Shannon proved a channel capacity theorem: C = W log(S / N). The proof 
> is mathematical, and correct.
>
> But hiding in the assumptions are some very strong and rarely 
> applicable conditions. It was a very useful result in founding 
> information theory.
>
> But... it is now called "Shannon's Law" and asserted to be true and 
> applicable to ALL communications systems.
>
> This turns out not to be correct. And it is hardly ever correct in 
> practice. An example of non-correct application turns out to be when 
> multiple transmissions of electromagnetic waves occur at the same 
> time. EE practice is to treat "all other signals" as Gaussian Noise. 
> They are not - they never are.
>
> So, later information theorists discovered that where there are 
> multiple signals received by a single receiving antenna, and only a 
> little noise (usually from the RF Front End of the receiver, not the 
> environment) the Slepian-Wolf capacity theorem applies C = W 
> log(\sum(S[i]. i=1,N) /W). That's a LOT more capacity than Shannon's 
> Law predicts, especially in narrowband signalling.
>
> And noise itself is actually "measurement error" at the receiver, 
> which is rarely Gaussian, in fact it really is quite predictable 
> and/or removable.
>
> So a theorem can be correct (based on its assumptions) and 
> inapplicable in most cases, because of its narrowness.
>
> And this is why a limited (not very general) theorem of the 2-out-of-3 
> form is dangerous.
>
> As for the CAP theorem, my Ph.D. thesis was in this very area - 
> multi-copy consistency in distributed data systems. That was in 1978, 
> 45 years ago.  I've followed that work since the time - both the 
> pragmatics and the theory. I think I fully understand both the context 
> and how the axioms chosen by Brewer simplify reality in radical ways.
>
> C A and P are not booleans or binary quantities. So in a real sense 
> the CAP theorem is always inapplicable. But worse, the proof structure 
> falls apart as a mathematical proof if you assume any metric for C A 
> or P that isn't homomorphic to boolean algebraic quantities.
>
> And worse, there is no standard measure of C A and P that captures 
> what matters on any dimension.
>
> So, aside from an intuition that maybe C, A, and P trade off in some 
> way in some model of reality, the theorem is meaningless, and not very 
> useful.
>
> I hope this helps understand what's behind my comments.
>
> At core, a referee ought to have asked - how is this conclusion 
> justified as a general conclusion about ALL e2e congestion control in 
> all networks, when it is only shown in a narrow, unrealistic case?
>
> In my nearly 50 years of publishing in the computing and 
> communications world, I've done a LOT of refereeing, and served on 
> program committees as well. The obligation of a referee is to look at 
> the conclusions of the paper, in the context of the state of the 
> science, and figure out if the conclusion is supported by the paper's 
> contents.
>
> I'm not sure why this didn't happen here.
>
> David
>
> PS: compared to the post-publication comments to my first CS 
> publication, in a letter to my mentor from Edsgar Dijkstra, I think 
> I'm being gentle. It's motivated by getting the science right.
>
> >
> > Thanks
> >
> > Hesham
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 20401 bytes --]

  reply	other threads:[~2022-08-12 14:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
2022-08-25 20:26   ` Dave Taht
     [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
2022-08-08 22:41     ` Dave Taht
2022-08-11 14:29   ` Hesham ElBakoury
2022-08-17 21:34   ` 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=ff84f8e6-a658-1290-8b69-29e5656cef25@gmail.com \
    --to=helbakoury@gmail.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