[Starlink] Finite-Buffer M/G/1 Queues with Time and Space Priorities

[Sebastian Moeller]

Hi all,


> On Jul 28, 2022, at 11:26, Bjørn Ivar Teigen via Starlink <starlink at 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 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, 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 *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 at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
> 
> 
> -- 
> Bjørn Ivar Teigen
> Head of Research
> +47 47335952 | bjorn at domos.no | www.domos.no
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink