From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4BEC83B2A4; Thu, 28 Jul 2022 05:55:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1659002129; bh=XbsRKetCVBz+ZwRDkRIQhDjwYyXbuW5IuE5Uyv6sZXA=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=iM/W0OkEUyq48gXQtoX+UyKYPqZXHY1Fx5P7V3XtRldWWnfUtodKuT//ws5iCpW+g N/rqM94sy5KR5ODmvgAOUa3x+k77t2F4sw0ImZUyFHYjceYZz6Vvih2vigfUuMQzaV S1htEKLmkBuSmINin54DA/akzvg73F4rFqVLtN9g= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MZTqW-1nvV7H0j38-00WVlJ; Thu, 28 Jul 2022 11:55:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 28 Jul 2022 11:55:28 +0200 Cc: "Bless, Roland (TM)" , Dave Taht via Starlink , codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Bj=C3=B8rn_Ivar_Teigen?= X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:CHNCdsgubZ5We0VB/RGs1dvmMx08+Hn5qjxUV+nsbyL8A59MbRJ 7CbXG5EEaa9xhSL3FCesD3XeIl2cCUxyY85X31J0yQsZNI9/FCF/D/uoH6BS4ohV8Z7RzOA wMJzd0pfgj6isUbQStEaBmQiVe3rZYjOb3fyXO8s0uN9EwlHKmnFhz0zFYvMTXmyxpkxw7n dlaqZND/QVS9GUq/YNo8A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:36tn2jEyzuE=:W2CArCiR/8lAGZrqVuDXwr F5aAGqbLr1l1iOAVnXhCKyPMO2nppIM1160qHEemWwrrGr6zKEV145GrXALT7WgYEvakBZ6I5 AeUqReKnC+uJqAjd5eCTd3oRsV8B7IaT7HXpe1jKQL9VDJxG2t9FXt42Ahq63NtSB+y8guP0d pFIk7oQjKsY+u5hfoyVm79V/AseGSvwf6SanL23cHi23LTOBUQENTHGwSAmBgLAQzZUfwnBKN QkaXb7+KUYj32crrqFZ+xkaX8Ir7N4WzCVpLuAsgXWylEfXBQs538oxXjxBjeyIVFo7Cc0tXz Ns9qPPkgdLh0J4zteD04aGOnpFceq3pmS7qWE7OWdxYooD4kM6Z407b6zlqjXxM3E5yvZcKiA EEoNNMxfLMabBOeE3vHVfW15ifE7Zn7TwjphYB1dW1gkr9GsjsoBGzC1Lb6XUxbxB2r/mNAaf oU4gh8rJSF4mjkoQttokDmMp5cF4hZhH6R1+Ek5zpCBD/lBNgfNVg/M14KfUYzOUYzKMi2slZ auygbfbnTqfxykTYIv3deJidPv/fjHm21KZkdq+/VoqDnC4KkhChYjJ2+YvqUTBWg1j3hRSVO bubqgCNj11puRh/RqFU/q48j9ls1YWZWY73m2Ck/xbDWq3G609MidalkwxReLdTd0EaP75Xel 7Ucx0xjtSyTL6t+tsLF3Nyk1VXumn6DqKK2oCtMOvNta8oMV9EYkr4cSsv1r6DeMQvwDEfi8i CKlBL2UhUVQXppnIAMXrrS0Kc4xiIawZfxrq3rc0PXcJyaEkJDDc3oKHb3w+vu6EErIqZIPE4 j1431mHH3suG8eKCYknNCCvSIJyNTShVxqn0bYs1CFXz7NvL9okUNMlZsy5U6GmDU412lG9lR 9nOrJ6cT2yKRMH6lOHFD9qOrNIrtRR2g6OSs8PJt8h7aBjdmho6fA6htqS7bcIQDrBCsCTHeB M24KmLMAycNKSI0CtntujSO2n+oz4tovl5Rmxq0NY4R+HPg3s7IujzHpJiGCDHu5c5xJ2AFyD T1akdjCzP4lx2Pwhaqedy9NpUbOLhNxhzkbr0ggbRr71LPegupi18VVHnteO1n1BO/Jgw97/2 N2f82v03rcKCaGEnXkPJu8rd3eYdKBVppzhAd/vtNrIHnZoEFRpn277bQ== 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 09:55:33 -0000 Hi all, > On Jul 28, 2022, at 11:26, Bj=C3=B8rn Ivar Teigen via Starlink = wrote: >=20 > Hi everyone, >=20 > Interesting paper Dave, I've got a few thoughts: >=20 > 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_t= hat_Enables_Control_of_Loss_and_Delay_of_Traffic_at_a_Network_Switch)=20 >=20 > 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. >=20 > On Thu, 28 Jul 2022 at 10:45, Bless, Roland (TM) via Starlink = wrote: > Hi Dave, >=20 > 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=20= > congestion control feedback loops that drive the bottleneck link > to saturation (unless you consider application limited traffic = sources). >=20 > 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. >=20 > Regards, > Bj=C3=B8rn Ivar > =20 >=20 > Regards, > Roland >=20 > 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. > >=20 > > https://www.hindawi.com/journals/mpe/2022/4539940/ > >=20 > > 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 >=20 >=20 > --=20 > 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