From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 F07E73B29D; Fri, 29 Jul 2022 13:08:39 -0400 (EDT) Received: by mail-wm1-x333.google.com with SMTP id c22so2860461wmr.2; Fri, 29 Jul 2022 10:08:39 -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=n6xN+ZWGjGbZMCrkoZKDUgvkZBF77azqtX8gTKuCHE0=; b=Z9YJyCrI6Dr7WB20Srmt8ogFPQatuv4U3jGUOXiSo2VLz1Dp2TJlIvKnXxN0r/3UKX 8Znnkv0ThgeH41IgYE7GWKKtToAmCozy5GGk++Q6jjQeGRQ5MgVnqPQFboknwztLt1+0 ycItPp0v31gNZcIzyAXk9wK0+1x3I4uFfidxBhjKGaScyYBKKCFigtBCvUSyc6VINoeP 7EikKMDQTG1CrmVvsAqLnx+SyKkGIRcw3jVn+8WRMUYEtwYrlBAdifw7AX0uR0AfOJC3 WlPbQgPLSFidCS25PPHhkycTbIoEcq6tyeBHirGB+qAuK17UI9kdx54UslsiVI/UzImE skGQ== 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=n6xN+ZWGjGbZMCrkoZKDUgvkZBF77azqtX8gTKuCHE0=; b=Q0gVRKhapRIM35NKjmVlNc0hJFyvI/U6VMxylIB+R2IGl24lA86bujGb/g+35l+TW9 79CyqFNCB7qKr1PEkpH0MfRygLrSczJqgnlDOuaejOiMvSIFVeSonJyIBikX1A7pL6xa 9vxsgdIn8hZMf0XcENOwYrIfO72taXRuxruUAsB9EtfAnEdV3HulRh2iMbFo0bbi5blc l1k2VVOq0AcX8hkQ51V4XqLe1+mMw3QeKkOYpUOeZszhJPFYbkCBOfN8GlwJ+7bGMkTS qwFuZzlKs/OMKYQ3lH5UEG+Wi70R1th8M+fDh2/JXc1mZGaSS8uP4AZ3o5oYXiijc5EG eJXQ== X-Gm-Message-State: AJIora/uSv+77WKTEMTpTJjsIJaasbZOSgWpfq6tLC7JrM7QqJyfe0fO zPj+z8jdXG09b3o5RvbW1CQhZS2r11V1KWuZ/zY= X-Google-Smtp-Source: AGRyM1tV6x8kqCwF6KkOBTsmz0Uqhk/YnAey+MARU2zj2f8nCiY6QDADaTl3qM1EuXCCChC74awOummAXP2ewI/pZJQ= X-Received: by 2002:a7b:c417:0:b0:3a3:236f:9f98 with SMTP id k23-20020a7bc417000000b003a3236f9f98mr3122499wmi.48.1659114518123; Fri, 29 Jul 2022 10:08:38 -0700 (PDT) MIME-Version: 1.0 References: <63E4019E-958A-4772-8D87-F972B67CD0AE@gmx.de> In-Reply-To: <63E4019E-958A-4772-8D87-F972B67CD0AE@gmx.de> From: Dave Taht Date: Fri, 29 Jul 2022 10:08:24 -0700 Message-ID: To: Sebastian Moeller Cc: =?UTF-8?Q?Bj=C3=B8rn_Ivar_Teigen?= , Dave Taht via Starlink , codel@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Fri, 29 Jul 2022 17:08:40 -0000 On Fri, Jul 29, 2022 at 8:29 AM Sebastian Moeller wrote: > > Hi Dave, > > I thought it was accepted knowledge that inter-packet delays across the i= nternet are not reliable? Why are paced chirps immune from that problem? Or= asked differently after all noise filtering required for robust and reliab= le operation over the existing internet, is this still going to be noticeab= ly faster than current slow-start? In spite of the slow in the name doublin= g every RTT is IMHO already a pretty aggressive growth function.... I would like to be able to slow "slow start" based on interpacket arrival t= imes. Elsewhere cloudflare is enabling packet pacing at IW1000.... https://blog.cloudflare.com/when-the-window-is-not-fully-open-your-tcp-stac= k-is-doing-more-than-you-think/ Increasingly it feels like there is going to be one network for the data center, and another for everyone else. > Sidenote, you really think the second paper nailed PCs coffin shut? No. It did outline the problems well. With a shift in perspective, instead of trying to smooth over the difference in behaviors in the underlying network to fit into an 90s isochronous packet switched network model, in the face of overwhelming differences in real world (overwhemingly wireless) behaviors... ... It seems easier to improve the transports than fix the routers at this point. Much as bbr models policers today perhaps it's best to try and model more network types. > > On 29 July 2022 16:55:42 CEST, Dave Taht wrote: >> >> 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.pd= f >> >> It died here: https://bobbriscoe.net/projects/netsvc_i-f/chirp_pfldnet10= .pdf >> 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 de= lay equal loss?". As you say, too much latency (causing reordering for inst= ance, or triggering an algorithm to smooth over missing data), is functiona= lly equivalent to loss, and therefore buffering beyond that point is making= things worse by delaying more traffic. The point at which this kicks in va= ries a lot between applications though, so some kind of classification migh= t still make sense. >>>> >>>> In a way, I think FQ_Codel does this classification implicitly by tre= ating 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 wro= te: >>>>> >>>>> >>>>> 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 eithe= r 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 oc= casional 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 occasio= nal 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 a= round the diagonal (more or less closely). >>>>> >>>>> About the rest of the paper I have nothing to contribute, since I di= d not spend the time to work though it. >>>>> >>>>> Regards >>>>> Sebastian >>>>> >>>>> >>>>> >>>>>> Different applications can have different needs and this split allo= ws a queuing algorithm to take those differences into account. Not the firs= t 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_a= t_a_Network_Switch) >>>>>> >>>>>> That said, the performance metrics are derived from the embedded Ma= rkov chain of the queuing system. This means the metrics are averages over = *all of time*, and thus there can be shorter periods (seconds, minutes, hou= rs) of much worse than average performance. Therefore the conclusions of th= e 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 sour= ces). >>>>>> >>>>>> 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 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 >>>>>> >>>>>> >>>>>> 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= _codel/ >>> Dave T=C3=A4ht CEO, TekLibre, LLC >> >> >> >> >> -- >> FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_c= odel/ >> Dave T=C3=A4ht CEO, TekLibre, LLC > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. --=20 FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_code= l/ Dave T=C3=A4ht CEO, TekLibre, LLC