From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) (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 2A67F3B2A4 for ; Mon, 2 Jan 2023 12:35:10 -0500 (EST) Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-1433ef3b61fso34247847fac.10 for ; Mon, 02 Jan 2023 09:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sQSymTzyqFCHEPyMO17BB2T2H9k7HKpLqqF4O79vHqM=; b=gZi7Vl/jvkXT/mCv92cBzqvcvdRyuofINMaWqCrO8SB7+1jlNaykmdFwVvs7QKxVCY X/OjbMl8T0ZxCdhe1Si5X7KuxWJ8eaPBSAHUwMJeqw7BusrOBoSLQVPthN92MKETIhTZ PiKC3CjwBjlS7yMqmn6J7wcS6KvdnU6+NzkrHaFPQXjAXXXe0u7+WGtzSjZxIXWqVyfx wexf425KDk9frY3t2uhpjGFr6EAJjQb6KxDzSMvi/0jaIRAkN6qVtNffLMrW0v4s8DvX RD1cnXzvGTWn1ubxwEeDokrvvia7ssPwhcRUp5y4ZvkQwRejzgN2nAo1G5KZs6wzJLWp 3eYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sQSymTzyqFCHEPyMO17BB2T2H9k7HKpLqqF4O79vHqM=; b=LlrbT0GEWOKhcSKwOq9QI6fd8r8cdO6AFxwLu+hn4J3Afaj+rCQvsCbBZ1kHifGXc8 +551r5Dc96hyNJ/OmLdZe8sjtV2aQ+xDx7/G36c/BYVa+sz0iWOLXTmix6wk7OZtEhnw VNa+tB1QuVpFX8GPp2uFYOxFGtClKK0k9BzPCGon3pQkyoncbPkJp4NiFsuhgMpriVlF c7Wcr41nzwRIcz03XRbWkJrvU+5rbfZAMO33mgUKcrC8M9jYLY5XKrQFazrKzlEvav/W 6vj1AIITiU34QWQiW8g3JChiPEC5LXyAkezm08CVnpVzR8AJ5T0MyrOr+/giUfUG9Q0G jQ6A== X-Gm-Message-State: AFqh2krdgsX5yzWih58J9ZJcpA/ZZqRSEFmvJwypQB1jQOLImasSXPtB 0RP/Hrp14+n7yZrOs+oPQ5xDeSlgaEvM+e36nPtbcEtleKV65g== X-Google-Smtp-Source: AMrXdXuU2hddNp2aMLzbAGA4bWc6TfDPmJLI41ukqmZqDol6ehxZ6pRHAUJx58+ZW76YIgYLN7brj2RDMQ1yXx4wD+Y= X-Received: by 2002:a05:6870:7d15:b0:150:7a14:87a7 with SMTP id os21-20020a0568707d1500b001507a1487a7mr731198oab.170.1672680909174; Mon, 02 Jan 2023 09:35:09 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6358:7e54:b0:e0:5763:fde6 with HTTP; Mon, 2 Jan 2023 09:35:08 -0800 (PST) From: =?UTF-8?Q?David_Fern=C3=A1ndez?= Date: Mon, 2 Jan 2023 18:35:08 +0100 Message-ID: To: starlink@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast 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: Mon, 02 Jan 2023 17:35:10 -0000 Just wondering how comes that buffering is not standardized. Wondering why buffer sizes are left to implementation decisions of possibly clueless vendors, which devices can worsen the performance of the network. > Date: Fri, 23 Dec 2022 19:00:56 -0500 (EST) > From: "David P. Reed" > To: starlink-request@lists.bufferbloat.net > Cc: starlink@lists.bufferbloat.net > Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast > Message-ID: <1671840056.20758968@mobile.rackspace.com> > Content-Type: text/plain;charset=3DUTF-8 > > Sorry for front posting. The L2 and L3 > are following the "end to end argument". The function of the L2 network i= s > to not queue more than absolutely necessary. > The function at L3 is to respond to congestion signals by reducing input = to > a fair share of available capacity, quickly, cooperating with other L3 > protocols. > > This is understood by clueful L2 and L3 folks. > > Clueless vendors dominate the L2 vendor space. Sadly. They refuse to stop > over buffering. > > > Date: Fri, 23 Dec 2022 16:02:03 +0100 > : David Fern=C3=A1ndez > To: starlink@lists.bufferbloat.net > Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast > > Hi, > > Sorry, maybe I did not craft the subject correctly. I am receiving the > daily digest of the list, not individual messages. > > I have seen before that the L2 engineers (Wi-Fi, DVB...) and the > Internet engineers (L3) are trying to solve the same issue (QoS, > congestion control) without being aware of what each other are doing > and not even getting coordinated. I am afraid that nowadays we have > even the application layer engineers doing their own stuff (DASH, > CDNs...). > > Some time ago, I worked in a project about cross-layer optimization > techniques for SATCOM systems, where one of the issues was to try to > optimize transport layer performance with L2 info. I was just a mere > observer of what academy people in the consortium where proposing. > > That was quite long ago: > https://artes.esa.int/projects/ipfriendly-crosslayer-optimization-adaptiv= e-satellite-systems > > Today I came across this: > https://www.elektormagazine.com/news/white-paper-why-wi-fi-6-goes-hand-in= -hand-with-cellular-to-enable-the-hyper-connected-enterprise-future > > "the performance uplift of Wi-Fi 6 over Wi-Fi 5 is substantial and > more than sufficient to support innovative use cases such as automated > guided vehicles, industrial robots and many other applications." > > This sound like Wi-Fi 6 will support low latency and will have a good > QoS support. Maybe... > > Regards, > > David > > 2022-12-21 8:54 GMT+01:00, Sebastian Moeller : >> Hi, >> >> See [SM] below. >> >> On 21 December 2022 08:37:27 CET, "David Fern=C3=A1ndez via Starlink" >> wrote: >>>What about this? >>>https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-wmm-programs >>> >>>Isn't this Wi-Fi MM (Multimedia) supposed to solve Wi-Fi QoS issues? >> >> [SM] In home network reality it failed to do so. I would guess >> partly because the admission control component is optional and as far as= I >> can tell not available in the usual WiFi routers and APs. A free for all >> priority system that in addition diminishes the total achievable >> throughput >> when the higher priority tiers are used introduces at least as much QoS >> issues a it solves IMHO. This might be different for 'enterprise WiFi >> gear' >> but I have no experience with that... >> >> Regard >> Sebastian >> >> P.S.: This feels like you might responded to a different thread than the >> iperf2 one we are in right now? >> >> >> >>> >>>> Date: Thu, 08 Dec 2022 11:04:13 -0800 >>>> From: rjmcmahon >>>> To: Sebastian Moeller >>>> Cc: rjmcmahon via Make-wifi-fast >>>> , Dave T=C3=A4ht >>>> , Rpm , libreqos >>>> =09 > , Dave Taht via Starlink >>>> , bloat >>>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast >>>> 2016 & crusader >>>> Message-ID: >>>> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed >>>> >>>> Thanks for the well-written response Sebastian. I need to think more >>>> about the load vs no load OWD differentials and maybe offer that as an >>>> integrated test. Thanks for bringing it up (again.) I do think a >>>> low-duty cycle bounceback test to the AP could be interesting too. >>>> >>>> I don't know of any projects working on iperf 2 & containers but it ha= s >>>> been suggested as useful. >>>> >>>> Bob >>>> >>>_______________________________________________ >>>Starlink mailing list >>>Starlink@lists.bufferbloat.net >>>https://lists.bufferbloat.net/listinfo/starlink >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> >