From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450: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 F294C3B29E; Thu, 28 Jul 2022 09:50:43 -0400 (EDT) Received: by mail-wr1-x42b.google.com with SMTP id l4so2240364wrm.13; Thu, 28 Jul 2022 06:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oJAQkAdFoRQskJja9mGQsEshB7WxAFgxYvRTPV4YwUU=; b=hD7XUdtk1TC9EaME4xMWg62wTogXXyg0D0EQi7UC17VkTpVtVDZ4GAYI0RseOm8Ab9 FCLu441V9K3ifrIghHIyFt4zk3QYOJr4AbJ1TqcGRkk/jDDTM7Zd41KeINdpLV6oQgE9 4TVFR7nxbOXxuGjo9+zWUbF8MYne+wMB5W47U0dd6ziX5DL7/I5Qmhi2bC26lP42LAHo 9FDThMh6w9EEao86RvPI0srELgaSTycYYBZmE2T/9D6AqZY3CoryucR8+whkjFEM626X JQO0gBnXJVFduo5I173cm54Z+cKVvgVhNMRT99diEtXNX4qV1PDfTlgxQHxTpW//5UfX HhNg== 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:content-transfer-encoding; bh=oJAQkAdFoRQskJja9mGQsEshB7WxAFgxYvRTPV4YwUU=; b=C4sfPXeQp0xsM5DV4J9dZ/qjFKjom0+jmT4AwNHeEdwWm6nftTXWTwlXPMRpg6dZVu sLAlP3bQK2JQPLYHFOTPpNpzOq+cSWJD4ImV2UNjtsWk2X4YWrkaDQF/nVAPW2Ii0P0m YwhKFuYw83dt5ajA2gWvcA2Tlu34wttLCtSe9/23PaNItheAqEcbKMPWVlQ7jwAL6M6l hlXSNHfr16pg8iM9zWXyHXnHE7cvLfWokJELziJnwqD0nsW35V/h5ASmlzrtdfPCaZyv ShAX+rHpLAJSsAfBCeb2ERyklleeWrknbBZFPc0A433APTO0jBOLoFSME30/lwsPDrIZ S4wQ== X-Gm-Message-State: AJIora9xyANs9qAl97LleHqS4jlz+MuZS7Ox+wql4LyrTNiXKxoD3443 +yk2HXpkK3jon0vyaQEwlSJNYzWkVsaKpJIgSy0= X-Google-Smtp-Source: AGRyM1sgcZ+x0svK5NJ6BezqHeyj+z4py7g7P45bejetgudaTO7ctLK9t5cLzZLFBfVjJzt+jk5nPzlieNiGgU4T81E= X-Received: by 2002:adf:df8e:0:b0:21e:4f87:6b42 with SMTP id z14-20020adfdf8e000000b0021e4f876b42mr17551139wrl.5.1659016242407; Thu, 28 Jul 2022 06:50:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Thu, 28 Jul 2022 06:50:30 -0700 Message-ID: To: =?UTF-8?Q?Bj=C3=B8rn_Ivar_Teigen?= Cc: Sebastian Moeller , Dave Taht via Starlink , codel@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] [Starlink] Finite-Buffer M/G/1 Queues with Time and Space Priorities X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2022 13:50:44 -0000 thx for the comments everyone! On Thu, Jul 28, 2022 at 3:16 AM Bj=C3=B8rn Ivar Teigen via Starlink wrote: > > 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 thi= ngs worse by delaying more traffic. The point at which this kicks in varies= a lot between applications though, so some kind of classification might st= ill make sense. > > In a way, I think FQ_Codel does this classification implicitly by treatin= g sparse and non-sparse flows differently. the implicit flow analysis of fq_codel paper toke did is here: http://www.diva-portal.org/smash/get/diva2:1251687/FULLTEXT01.pdf It's a really nice feature!, and helps a lot when also applied to wifi station scheduling. I have sometimes thought that increasing to quantum to account for two paced packets in a row (at high rates) was a good idea, other times having paced transports analyze the "beat frequency" of sending packets through fq_codel vs a vs the ack flow characteristics (for example, filtering) might be useful. Imagine that instead of sending packets on a fixed but increasing pacing schedule within an RTT thusly PPPPPPPPPP # IW10 burst PP PP PP PP PP # often about 24 packets in what we think the RTT is PP PP PP PP PP PP PP PPPPPPPPPPPPPPPPPP PPPPPPPPPPPPPPPPPPPPPPP stready buffering and ultimately a drop (and yes this is inaccurate a model in a zillion ways, forgive me for purposes of extrapolation in ascii text) If instead... You broke up the pacing within an RTT on an actual curve, selecting some random segment out of PI as your actual starting point, say, at 3.14596 here. PPPPPP PPPPP PPP PPPPP PPPPPPPP PPPPPPPPP PPP PP 3.14159265358979323846264338327950288419716939937510 58209749445923078164062862089986280348253421170679 82148086513282306647093844609550582231725359408128 48111745028410270193852110555964462294895493038196 44288109756659334461284756482337867831652712019091 45648566923460348610454326648213393607260249141273 72458700660631558817488152092096282925409171536436 78925903600113305305488204665213841469519415116094 33057270365759591953092186117381932611793105118548 07446237996274956735188575272489122793818301194912 98336733624406566430860213949463952247371907021798 60943702770539217176293176752384674818467669405132 00056812714526356082778577134275778960917363717872 14684409012249534301465495853710507922796892589235 42019956112129021960864034418159813629774771309960 51870721134999999837297804995105973173281609631859 50244594553469083026425223082533446850352619311881 71010003137838752886587533208381420617177669147303 59825349042875546873115956286388235378759375195778 18577805321712268066130019278766111959092164201989 what could you learn? > - 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 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 de= lay- or loss-sensitive)... e.g. for "real-time" games you have both delay a= nd loss sensitivity (similarly for VoIP), however both can deal with occasi= onal lost or delayed packets (if the delay is large enough to say be re-ord= ered with the temporally next data packet (voice sample in VoIP, server-tic= k 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-sens= itivity axis, I predict most real traffic types will cluster somewhat aroun= d the diagonal (more or less closely). >> >> About the rest of the paper I have nothing to contribute, since I did no= t 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 t= ime 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_Q= ueueing_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 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 affecting= the results though. Even if the distributions are general in the paper, th= ey still assume samples are IID which is not true for real networks. Feedba= ck loops make real traffic self-correlated, which makes the short periods o= f worse than average performance worse and more frequent than IID models mi= ght 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 queue= s >> > > 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 distribute= d >> > > 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 tim= es >> > > 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 >> > > > -- > 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 FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_code= l/ Dave T=C3=A4ht CEO, TekLibre, LLC