From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 BB4AE3B29D; Fri, 29 Jul 2022 10:55:56 -0400 (EDT) Received: by mail-wr1-x436.google.com with SMTP id p10so2098909wru.8; Fri, 29 Jul 2022 07:55:56 -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=7oDUhhyBupVVWPeXFfagdU9oUBNvEkiTSXgn3LUulRA=; b=CYyIk3m9CpI5k9P6S/+DSN3I5RatgI8khas//iEwEX5Snw45imh1O3R/lQaBkeUGkJ nZEdOI7u2VLCoo5sosL2eKVGh8wTdhQznakfvmCHz+UO7gOEzONXmKMFeL/3SvQVtRRV bF4bnWzj/OOfHDVsDbdpRuEMdeIdx7nBljpfPdEmgEdgNv/SlAZSYViJ4ZiPsZOqNQ6b A5u8s76ZGlxEYpg0pIJjyC5Yi4z/8FoXte7nRYlJqWVxPr/C1PR7Aaww5YC4LZ/lVlTj GA+k0B7LK/1GAFA5djIWqcW4XOmWEDXYCH91tJ6n/2Ccfj7uXrcMV9T5VW/hCl8hp7xn 3o1w== 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=7oDUhhyBupVVWPeXFfagdU9oUBNvEkiTSXgn3LUulRA=; b=trbY0ZLqYtXFyVlK9FRcPUNpCecYQGsZO7IrIgcxgwKv/yz5Ba5rKwDYsWKrc3hIVN oyyPxCjxtzX//L+puuO35Tdp3x4mMqlLXXRr66VMzaaIr9LwUc+l6NDX54qQRPxKsbbq 1KVl4Njvh7rPTT516cv68fwrLTu5C23lFGoRxOZF9xi+Sxks/7BGIG/D/SSEdPPDZNr0 tBD3YEEPAEEtE83k7AQActf9dNdf6t+wktjspvXf/I7/Oeg2Lc43qmxFcwOcsSM1CUXI 3UPLHiNoqKOdi9+2btwD7n9wNGFG7aYTBGMWqME24k4rKGkvHzN7R9z76XNq9oNjL5Si zqRg== X-Gm-Message-State: ACgBeo0Lt6KGX3q4QGNIzPRJzuaQ1MbHjbia/vZ5Bh8O0pewm+0HmkNO 0ffyUrG7HJcwf9GASFOpg61XV8DmB8GrJmdw0pA= X-Google-Smtp-Source: AA6agR5m81u4JNcO60czVLiYZtAfYVWI0+gIA4xwdxD84YueH1PAArNyqBh6IBovPVo5/64U38QpaooQ4hg/T0U2SbE= X-Received: by 2002:a5d:488a:0:b0:21e:d477:6555 with SMTP id g10-20020a5d488a000000b0021ed4776555mr2758658wrq.380.1659106555397; Fri, 29 Jul 2022 07:55:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Fri, 29 Jul 2022 07:55:42 -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: Fri, 29 Jul 2022 14:55:57 -0000 To give credit where credit is due, "packet chirping" had been explored before in the context of the l4s early marking ecn effort: https://www.bobbriscoe.net/presents/1802paced-chirps/1802paced-chirps.pdf It died here: https://bobbriscoe.net/projects/netsvc_i-f/chirp_pfldnet10.pd= f For now. On Thu, Jul 28, 2022 at 6:50 AM Dave Taht wrote: > > 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 dela= y equal loss?". As you say, too much latency (causing reordering for instan= ce, or triggering an algorithm to smooth over missing data), is functionall= y equivalent to loss, and therefore buffering beyond that point is making t= hings worse by delaying more traffic. The point at which this kicks in vari= es 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 treat= ing 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 = 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 occa= sional lost or delayed packets (if the delay is large enough to say be re-o= rdered with the temporally next data packet (voice sample in VoIP, server-t= ick update in games), that packet's data will likely not be evaluated at al= l). And large scale bulk downloads are both tolerant to delay and occasiona= l loss. So if we think about a state space spanned by a delay and a loss-se= nsitivity axis, I predict most real traffic types will cluster somewhat aro= und 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 allow= s 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 Mar= kov chain of the queuing system. This means the metrics are averages over *= all of time*, and thus there can be shorter periods (seconds, minutes, hour= s) 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 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 sourc= es). > >> > > >> > 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 affecti= ng 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. Feed= back 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=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 i= n > >> > > 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 que= ues > >> > > with time and space priority, where service times are identical an= d > >> > > exponentially distributed for both types of traffic, in our model = we > >> > > assume that service times are different and are generally distribu= ted > >> > > 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-tim= e > >> > > distributions. For the proposed queueing model, we derive the > >> > > queue-length distributions, loss probabilities, and mean waiting t= imes > >> > > 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 > > > > -- > FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_co= del/ > Dave T=C3=A4ht CEO, TekLibre, LLC --=20 FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_code= l/ Dave T=C3=A4ht CEO, TekLibre, LLC