From: Jonathan Morton <chromatix99@gmail.com>
To: Leonard Kleinrock <lk@cs.ucla.edu>
Cc: "David P. Reed" <dpreed@deepplum.com>,
Cake List <cake@lists.bufferbloat.net>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
Bob McMahon <bob.mcmahon@broadcom.com>,
starlink@lists.bufferbloat.net, codel@lists.bufferbloat.net,
cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>,
Ben Greear <greearb@candelatech.com>
Subject: Re: [Codel] [Bloat] Little's Law mea culpa, but not invalidating my main point
Date: Sat, 10 Jul 2021 02:56:46 +0300 [thread overview]
Message-ID: <A2CB0701-E08F-46ED-8579-CC24F1444E9C@gmail.com> (raw)
In-Reply-To: <8C38E940-8B97-4767-A39B-25F043AE0856@cs.ucla.edu>
> On 10 Jul, 2021, at 2:01 am, Leonard Kleinrock <lk@cs.ucla.edu> wrote:
>
> No question that non-stationarity and instability are what we often see in networks. And, non-stationarity and instability are both topics that lead to very complex analytical problems in queueing theory. You can find some results on the transient analysis in the queueing theory literature (including the second volume of my Queueing Systems book), but they are limited and hard. Nevertheless, the literature does contain some works on transient analysis of queueing systems as applied to network congestion control - again limited. On the other hand, as you said, control theory addresses stability head on and does offer some tools as well, but again, it is hairy.
I was just about to mention control theory.
One basic characteristic of Poisson traffic is that it is inelastic, and assumes there is no control feedback whatsoever. This means it can only be a valid model when the following are both true:
1: The offered load is *below* the link capacity, for all links, averaged over time.
2: A high degree of statistical multiplexing exists.
If 1: is not true and the traffic is truly inelastic, then the queues will inevitably fill up and congestion collapse will result, as shown from ARPANET experience in the 1980s; the solution was to introduce control feedback to the traffic, initially in the form of TCP Reno. If 2: is not true then the traffic cannot be approximated as Poisson arrivals, regardless of load relative to capacity, because the degree of correlation is too high.
Taking the iPhone introduction anecdote as an illustrative example, measuring utilisation as very close to 100% is a clear warning sign that the Poisson model was inappropriate, and a control-theory approach was needed instead, to capture the feedback effects of congestion control. The high degree of statistical multiplexing inherent to a major ISP backhaul is irrelevant to that determination.
Such a model would have found that the primary source of control feedback was human users giving up in disgust. However, different humans have different levels of tolerance and persistence, so this feedback was not sufficient to reduce the load sufficiently to give the majority of users a good service; instead, *all* users received a poor service and many users received no usable service. Introducing a technological control feedback, in the form of packet loss upon overflow of correctly-sized queues, improved service for everyone.
(BTW, DNS becomes significantly unreliable around 1-2 seconds RTT, due to protocol timeouts, which is inherited by all applications that rely on DNS lookups. Merely reducing the delays consistently below that threshold would have improved perceived reliability markedly.)
Conversely, when talking about the traffic on a single ISP subscriber's last-mile link, the Poisson model has to be discarded due to criterion 2 being false. The number of flows going to even a family household is probably in the low dozens at best. A control-theory approach can also work here.
- Jonathan Morton
next prev parent reply other threads:[~2021-07-09 23:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-01 0:12 [Codel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board Dave Taht
[not found] ` <1625188609.32718319@apps.rackspace.com>
2021-07-02 17:07 ` [Codel] [Cerowrt-devel] " Dave Taht
[not found] ` <CAHb6LvrjgKnfe_jaGgx7_B1VDTkZfTmP0OyTmxL9ojWoxogrsA@mail.gmail.com>
2021-07-06 13:46 ` [Codel] [Starlink] [Make-wifi-fast] " Ben Greear
[not found] ` <CAHb6LvqSkcGZBZ+iHY-g0vSunqe1sFHmvoFXGjWSoYvtwHeHaA@mail.gmail.com>
2021-07-06 21:24 ` Ben Greear
[not found] ` <CAHb6LvodW0WNeHAfRHLB6NhDT6+maWVnoR14+setpzCWnwiPTQ@mail.gmail.com>
2021-07-07 13:34 ` Ben Greear
[not found] ` <1625773080.94974089@apps.rackspace.com>
[not found] ` <FDF5C7A7-47A6-4123-A948-352C07C35F02@cs.ucla.edu>
2021-07-09 10:05 ` [Codel] [Make-wifi-fast] [Starlink] " Luca Muscariello
[not found] ` <CAHb6LvqsZFDDkC1qjr9ccXNjFtq1qnAevQpccNFydP4BOVVL1Q@mail.gmail.com>
2021-08-02 23:16 ` [Codel] [Cake] " David Lang
2021-08-02 23:55 ` Ben Greear
[not found] ` <CAHb6Lvp851pVCt+zUv1PZgpHafCG4RPXEwMn6=CJFXhVf9fK8w@mail.gmail.com>
2021-08-03 3:12 ` David Lang
[not found] ` <CAHb6LvqfRxKU0BW04ypRcPDpCcWymnS6qzb3gneQSbBrAbRhHQ@mail.gmail.com>
2021-08-03 4:30 ` David Lang
[not found] ` <CAHb6LvpcawqCvgt5MmhXADYG=oaY5rbdaC=7ETwOVzpHXak2kQ@mail.gmail.com>
2021-08-03 4:44 ` David Lang
[not found] ` <202108101410.17AEAR4w075939@gndrsh.dnsmgr.net>
[not found] ` <5AF5551E2A7041168E7071FDA0F6B8EC@SRA6>
[not found] ` <CAHb6LvpAmUKgsMAoZGrbAvS01DF=yWyJj56ox+FrDM_tEc=0Ng@mail.gmail.com>
[not found] ` <03CA2CDA3EC5415DA229F835BE039994@SRA6>
[not found] ` <CAHb6LvoiVZq91m-C3iJFC95fYLPHCY3zQo6O0XTUDAJquu5KbQ@mail.gmail.com>
[not found] ` <92A399A23FEE4C52ADFC1734E6840756@SRA6>
[not found] ` <CACw=56K_Sj24FAO17cY4vDYhe1-gAXW_fQKLSBKSMqSE0kCRmA@mail.gmail.com>
2021-08-10 20:44 ` [Codel] [Starlink] Anhyone have a spare couple a hundred million ... Elon may need to start a go-fund-me page! David Lang
[not found] ` <CAHb6LvpK48u+8coP1pWJVjva_jYaQa-bGuArAGnf8ku-=xoSBw@mail.gmail.com>
2021-08-03 3:06 ` [Codel] [Cake] [Make-wifi-fast] [Starlink] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board David Lang
[not found] ` <8677F5C4-1893-4A61-A13C-3C8BE17CB789@cs.ucla.edu>
[not found] ` <CAHb6LvpQP_jCiHeNJAD9qt+wB-HqUAW7N6aGJ+6-PXg+KE5Z2Q@mail.gmail.com>
[not found] ` <4F6EFB347C08475A9F53B24E0D8BEAE2@SRA6>
[not found] ` <CAHb6LvqUctN5SMcqgZNh5u7=nJhtWOuXEmh59PPYag2g+xVrtw@mail.gmail.com>
2021-08-08 18:36 ` [Codel] [Make-wifi-fast] [Starlink] [Cake] " Aaron Wood
2021-08-08 18:48 ` [Codel] [Bloat] " Jonathan Morton
[not found] ` <1625859083.09751240@apps.rackspace.com>
[not found] ` <BCD9F979-341F-4292-9D11-FAE91FC3967E@akamai.com>
2021-07-09 23:37 ` [Codel] [Bloat] Little's Law mea culpa, but not invalidating my main point Toke Høiland-Jørgensen
[not found] ` <8C38E940-8B97-4767-A39B-25F043AE0856@cs.ucla.edu>
2021-07-09 23:56 ` Jonathan Morton [this message]
2021-07-17 23:56 ` [Codel] [Make-wifi-fast] " Aaron Wood
[not found] ` <EF8D7620-438A-4F65-94D9-B35FDB76FBBD@cable.comcast.com>
[not found] ` <1626111630.69692379@apps.rackspace.com>
[not found] ` <CAHb6LvoD+ACc+17WhTVmS8HYnYyboJrCg5zQF8uXtzrmqqKfPA@mail.gmail.com>
2021-07-12 19:07 ` [Codel] " Ben Greear
[not found] ` <CAHb6LvpyQtGg3sMF2RV_gMpEcaY32A70VaEwtsnoeq4DHtv7EA@mail.gmail.com>
2021-07-12 20:32 ` Ben Greear
2021-07-12 20:36 ` [Codel] [Cake] " David Lang
2021-07-17 23:29 ` [Codel] " Aaron Wood
2021-07-12 21:54 ` [Codel] [Make-wifi-fast] " Jonathan Morton
2021-09-20 1:21 ` [Codel] " Dave Taht
[not found] ` <257851.1632110422@turing-police>
2021-09-20 4:09 ` [Codel] [Bloat] [Cerowrt-devel] " David Lang
[not found] ` <CABf5zv+yq_oJ7O7YqVeSbZ2Qns3C4hESzNA2V0zNb0L1Zg-mgw@mail.gmail.com>
[not found] ` <CAHxHggd-4rZ5Nc4raaoRUjjL17MVh8UsNu_5eL8eiLJ=R_68wA@mail.gmail.com>
[not found] ` <CAHb6Lvp86iw=DQMN8Z+f7yUJu-5pmVUxsM1_1Jw8RJb2XRcMcg@mail.gmail.com>
[not found] ` <1632680642.869711321@apps.rackspace.com>
[not found] ` <CAHb6Lvp1dxnbuCNiE5FKC-yRyD6HGkb0H1ZQAm_nSxANwJg2pA@mail.gmail.com>
[not found] ` <E3373586-EF4C-40DF-885B-0D6134E6EAF1@apple.com>
2021-10-26 4:24 ` [Codel] [Bloat] [Make-wifi-fast] TCP_NOTSENT_LOWAT applied to e2e TCP msg latency Eric Dumazet
[not found] ` <CAHb6Lvomc+2y++qOm9v3OzYCdmWDUEROJb+unybj0Mir0faXQQ@mail.gmail.com>
[not found] ` <CAKf5G6JpeaxRkbwhuNE5zUb7tX3H4eo0HOuX+C0DCSrcg4Byhg@mail.gmail.com>
[not found] ` <CAHb6LvpUBKFGUTnuafGxQAJBfNEO=zS20SvxTJ88e6VJAP54=g@mail.gmail.com>
2021-10-27 14:29 ` [Codel] [Make-wifi-fast] [Starlink] " Sebastian Moeller
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/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A2CB0701-E08F-46ED-8579-CC24F1444E9C@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=bob.mcmahon@broadcom.com \
--cc=cake@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=dpreed@deepplum.com \
--cc=greearb@candelatech.com \
--cc=lk@cs.ucla.edu \
--cc=make-wifi-fast@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