From: "Bjørn Ivar Teigen" <bjorn@domos.no>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Dave Taht <dave.taht@gmail.com>,
starlink@lists.bufferbloat.net, codel@lists.bufferbloat.net
Subject: Re: [Starlink] Finite-Buffer M/G/1 Queues with Time and Space Priorities
Date: Thu, 28 Jul 2022 11:26:36 +0200 [thread overview]
Message-ID: <CAKf5G6L8_sKGtSQ-0RaiQdTkwd=7shjtKi9HKq0k+D+SXGu0=w@mail.gmail.com> (raw)
In-Reply-To: <ae7a9f3e-6f94-1953-20dd-3d2140a4e49d@kit.edu>
[-- Attachment #1: Type: text/plain, Size: 3363 bytes --]
Hi everyone,
Interesting paper Dave, I've got a few thoughts:
I like the split into delay-sensitive and loss-sensitive data. Different
applications can have different needs and this split allows a queuing
algorithm to take those differences into account. Not the first time I've
seen this kind of split, but the other one I've seen used M/M/1/k queues
(document here:
https://www.researchgate.net/publication/2452029_A_Queueing_Theory_Model_that_Enables_Control_of_Loss_and_Delay_of_Traffic_at_a_Network_Switch
)
That said, the performance metrics are derived from the embedded Markov
chain of the queuing system. This means the metrics are averages over *all
of time*, and thus there can be shorter periods (seconds, minutes, hours)
of much worse than average performance. Therefore the conclusions of the
paper should be taken with a grain of salt in my opinion.
On Thu, 28 Jul 2022 at 10:45, Bless, Roland (TM) via Starlink <
starlink@lists.bufferbloat.net> wrote:
> Hi Dave,
>
> IMHO the problem w.r.t the applicability of most models from
> queueing theory is that they only work for load < 1, whereas
> we are using the network with load values ~1 (i.e., around one) due to
> congestion control feedback loops that drive the bottleneck link
> to saturation (unless you consider application limited traffic sources).
>
To be fair there are queuing theory models that include packet loss (which
is the case for the paper Dave is asking about here), and these can work
perfectly well for load > 1. Agree about the CC feedback loops affecting
the results though. Even if the distributions are general in the paper,
they still assume samples are IID which is not true for real networks.
Feedback loops make real traffic self-correlated, which makes the short
periods of worse than average performance worse and more frequent than IID
models might suggest.
Regards,
Bjørn Ivar
>
> Regards,
> Roland
>
> On 27.07.22 at 17:34 Dave Taht via Starlink wrote:
> > Occasionally I pass along a recent paper that I don't understand in
> > the hope that someone can enlighten me.
> > This is one of those occasions, where I am trying to leverage what I
> > understand of existing FQ-codel behaviors against real traffic.
> >
> > https://www.hindawi.com/journals/mpe/2022/4539940/
> >
> > Compared to the previous study on finite-buffer M/M/1 priority queues
> > with time and space priority, where service times are identical and
> > exponentially distributed for both types of traffic, in our model we
> > assume that service times are different and are generally distributed
> > for different types of traffic. As a result, our model is more
> > suitable for the performance analysis of communication systems
> > accommodating multiple types of traffic with different service-time
> > distributions. For the proposed queueing model, we derive the
> > queue-length distributions, loss probabilities, and mean waiting times
> > of both types of traffic, as well as the push-out probability of
> > delay-sensitive traffic.
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
--
Bjørn Ivar Teigen
Head of Research
+47 47335952 | bjorn@domos.no <name@domos.no> | www.domos.no
[-- Attachment #2: Type: text/html, Size: 6017 bytes --]
next prev parent reply other threads:[~2022-07-28 9:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-27 15:34 Dave Taht
2022-07-27 17:23 ` Luca Muscariello
2022-07-28 8:45 ` Bless, Roland (TM)
2022-07-28 9:26 ` Bjørn Ivar Teigen [this message]
2022-07-28 9:55 ` Sebastian Moeller
2022-07-28 10:16 ` Bjørn Ivar Teigen
2022-07-28 13:50 ` Dave Taht
2022-07-29 14:55 ` Dave Taht
2022-07-29 15:29 ` Sebastian Moeller
2022-07-29 17:08 ` Dave Taht
2022-07-29 17:41 ` Sebastian Moeller
2022-07-29 15:29 ` Sebastian Moeller
[not found] <mailman.461.1659002134.1281.starlink@lists.bufferbloat.net>
2022-07-29 19:38 ` David P. Reed
2022-07-29 20:34 ` Bjørn Ivar Teigen
2022-07-30 12:55 ` Juliusz Chroboczek
2022-07-30 16:17 ` David Lang
2022-07-29 20:36 ` Bless, Roland (TM)
2022-07-31 11:58 ` Sebastian Moeller
2022-07-31 20:22 ` David P. Reed
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='CAKf5G6L8_sKGtSQ-0RaiQdTkwd=7shjtKi9HKq0k+D+SXGu0=w@mail.gmail.com' \
--to=bjorn@domos.no \
--cc=codel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=roland.bless@kit.edu \
--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