From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E789D3B2A4 for ; Thu, 28 Jul 2022 06:16:44 -0400 (EDT) Received: by mail-pf1-x42b.google.com with SMTP id w185so1551538pfb.4 for ; Thu, 28 Jul 2022 03:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=domos-no.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kxVsescrroFL3bAeZIVTRjNWcU9IlcBiBE6owtaeZZY=; b=I6KseRAXcyYu7Wo2BVSrQ3BkNQBiH8yk8U7pxsHqT/vCgOXlI0AmAemViezPSS037N C4f5isxap+ax8HnT9EG32Vg+M/PSE07GM29h7x6slpUl5trAMURu6Yvk+TOdTWZ/TuKF k6gJthtkLqSUJSDKFRo4bIzhN9S/JAapjhUqF7KQO9u85r5/cAqwwspM01av9232H80g BLwFvK39laoi+1FZ+GsgnrcoYaCVnehKwDyZdqZ97Y7bI10nvcwnkUG9l5NvgZiFpZlq WX4KX+bZNjZmi5//aoWOabS17jusfa+8beljUG34SZjawfRmE2T7Eh4IPLIraors4K8u UVNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kxVsescrroFL3bAeZIVTRjNWcU9IlcBiBE6owtaeZZY=; b=GglcOQM1VEv5fxk6h7zMjTZu7LL067uNu10WrBiHAc2aAz0p+E36bBMYWtKBsFR5Au xiRX88ZcdFFCLhtLK1PWhti/FdiHwmSNUIRcZpj3IJ3HV5RLZtQO7uvzxqazwG6yjm6/ wfksGTED93BFPSe7HbzqzIqxYV3TOTq96DPccO4V+g4bu72cRVa8lNNakZRaKPmq7sHe 7oxPnMt8/xuQKn+2lp9Fp3W4yAvc0BW4RwoCOB0b65ISZ1b/pRzHOr0zu/teS47Fb6h+ sUWMnoFqkdQyzasRX91tmMSAqjjIE+hzFLRMMldgK9WG7zGbNiEDRcVWK7oGuMCe5W8c mhkw== X-Gm-Message-State: AJIora/P4SfcZu3MOTmmTOzLkFLhUG/3fIJ1C6nm3x1qAQjfwUrycblt gmnKOK/U3mOqcdMSFvDfKdDcioewhA6W8dpdKSFXpQ== X-Google-Smtp-Source: AGRyM1vFXqvf8U+ZEPKwSorynfBi2KRzNZd0PiE/s5/45BtIxBxYxqE+0N0LIg9W6qg8P4pyuXeVUEOvZ3k5YlLLBpc= X-Received: by 2002:a63:5620:0:b0:41a:4c1e:a821 with SMTP id k32-20020a635620000000b0041a4c1ea821mr22815594pgb.611.1659003403976; Thu, 28 Jul 2022 03:16:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Bj=C3=B8rn_Ivar_Teigen?= Date: Thu, 28 Jul 2022 12:16:32 +0200 Message-ID: To: Sebastian Moeller Cc: "Bless, Roland (TM)" , Dave Taht via Starlink , codel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000935c7605e4dad440" Subject: Re: [Starlink] Finite-Buffer M/G/1 Queues with Time and Space Priorities X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2022 10:16:45 -0000 --000000000000935c7605e4dad440 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Very good point. Perhaps we can think of it as "at what point does delay equal loss?". As you say, too much latency (causing reordering for instance, or triggering an algorithm to smooth over missing data), is functionally equivalent to loss, and therefore buffering beyond that point is making things worse by delaying more traffic. The point at which this kicks in varies a lot between applications though, so some kind of classification might still make sense. In a way, I think FQ_Codel does this classification implicitly by treating sparse and non-sparse flows differently. - Bj=C3=B8rn Ivar On Thu, 28 Jul 2022 at 11:55, Sebastian Moeller wrote: > Hi all, > > > > On Jul 28, 2022, at 11:26, Bj=C3=B8rn Ivar Teigen via Starlink < > starlink@lists.bufferbloat.net> wrote: > > > > Hi everyone, > > > > Interesting paper Dave, I've got a few thoughts: > > > > I like the split into delay-sensitive and loss-sensitive data. > > However often real data is slightly different (e.g. not nicely either > delay- or loss-sensitive)... e.g. for "real-time" games you have both del= ay > and loss sensitivity (similarly for VoIP), however both can deal with > occasional lost or delayed packets (if the delay is large enough to say b= e > re-ordered with the temporally next data packet (voice sample in VoIP, > server-tick update in games), that packet's data will likely not be > evaluated at all). And large scale bulk downloads are both tolerant to > delay and occasional loss. So if we think about a state space spanned by = a > delay and a loss-sensitivity axis, I predict most real traffic types will > cluster somewhat around the diagonal (more or less closely). > > About the rest of the paper I have nothing to contribute, since I did not > spend the time to work though it. > > Regards > Sebastian > > > > > 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 *al= l > 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 ca= n > work perfectly well for load > 1. Agree about the CC feedback loops > affecting the results though. Even if the distributions are general in th= e > paper, they still assume samples are IID which is not true for real > networks. Feedback loops make real traffic self-correlated, which makes t= he > short periods of worse than average performance worse and more frequent > than IID models might suggest. > > > > Regards, > > Bj=C3=B8rn 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 time= s > > > 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=C3=B8rn Ivar Teigen > > Head of Research > > +47 47335952 | bjorn@domos.no | www.domos.no > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > > --=20 Bj=C3=B8rn Ivar Teigen Head of Research +47 47335952 | bjorn@domos.no | www.domos.no --000000000000935c7605e4dad440 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Very good point. Perhaps we can think of it as "= at what point does delay equal loss?". As you say, too much latency (c= ausing reordering for instance, or triggering an algorithm to smooth over m= issing data), is functionally equivalent to loss, and therefore buffering b= eyond that point is making things worse by delaying more traffic. The point= at which this kicks in varies a lot between applications though, so some k= ind of classification might still make sense.

In a= way, I think FQ_Codel does this classification implicitly by treating spar= se and non-sparse flows differently.

- Bj=C3=B8rn = Ivar

On Thu, 28 Jul 2022 at 11:55, Sebastian Moeller <moeller0@gmx.de> wrote:
Hi all,


> On Jul 28, 2022, at 11:26, Bj=C3=B8rn Ivar Teigen via Starlink <starlink@l= ists.bufferbloat.net> wrote:
>
> Hi everyone,
>
> Interesting paper Dave, I've got a few thoughts:
>
> I like the split into delay-sensitive and loss-sensitive data.

However often real data is slightly different (e.g. not nicely either delay= - or loss-sensitive)... e.g. for "real-time" games you have both = delay and loss sensitivity (similarly for VoIP), however both can deal with= occasional lost or delayed packets (if the delay is large enough to say be= re-ordered with the temporally next data packet (voice sample in VoIP, ser= ver-tick update in games), that packet's data will likely not be evalua= ted at all). And large scale bulk downloads are both tolerant to delay and = occasional loss. So if we think about a state space spanned by a delay and = a loss-sensitivity axis, I predict most real traffic types will cluster som= ewhat around the diagonal (more or less closely).

About the rest of the paper I have nothing to contribute, since I did not s= pend the time to work though it.

Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian



> Different applications can have different needs and this split allows = a queuing algorithm to take those differences into account. Not the first t= ime I've seen this kind of split, but the other one I've seen used = M/M/1/k queues (document here: ht= tps://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 Marko= v chain of the queuing system. This means the metrics are averages over *al= l of time*, and thus there can be shorter periods (seconds, minutes, hours)= of much worse than average performance. Therefore the conclusions of the p= aper 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@li= sts.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 (w= hich is the case for the paper Dave is asking about here), and these can wo= rk perfectly well for load > 1. Agree about the CC feedback loops affect= ing 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. Fee= dback loops make real traffic self-correlated, which makes the short period= s of worse than average performance worse and more frequent than IID models= might suggest.
>
> Regards,
> Bj=C3=B8rn Ivar
>=C2=A0
>
> Regards,
>=C2=A0 =C2=A0Roland
>
> On 27.07.22 at 17:34 Dave Taht via Starlink wrote:
> > Occasionally I pass along a recent paper that I don't underst= and in
> > the hope that someone can enlighten me.
> > This is one of those occasions, where I am trying to leverage wha= t I
> > understand of existing FQ-codel behaviors against real traffic. > >
> > https://www.hindawi.com/journals/mpe/202= 2/4539940/
> >
> > Compared to the previous study on finite-buffer M/M/1 priority qu= eues
> > with time and space priority, where service times are identical a= nd
> > exponentially distributed for both types of traffic, in our model= we
> > assume that service times are different and are generally distrib= uted
> > 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-ti= me
> > 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<= br> > > delay-sensitive traffic.
> _______________________________________________
> Starlink mailing list
> St= arlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink<= /a>
>
>
> --
> Bj=C3=B8rn Ivar Teigen
> Head of Research
> +47 47335952 | bjo= rn@domos.no | www.domos.no
> _______________________________________________
> Starlink mailing list
> St= arlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink<= /a>



--
--000000000000935c7605e4dad440--