From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 894733B2A4 for ; Wed, 9 Jun 2021 06:20:04 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 923DFB3; Wed, 9 Jun 2021 12:20:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1623234002; bh=4q4ZmPTMsG8FwytCeI4y17uQdj7AhZzRsdZ4XUjF8Wc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Bma8uX/NDqxG1EByLE7kiZ26mRBf4Tws+DehFwd5S6dc+Y/wa8bOGZAsxv3Od7FIo RbCrF65DtRrBkjlzn1n2d2wm6jvN7Fppt+ovDW9taZwXlLCmYlARUnbNFgFAF1bqyS 88rextGtKy7chI4sA+bc2ts6sqXlahwZDGKzp3Fo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8FEA6B1; Wed, 9 Jun 2021 12:20:02 +0200 (CEST) Date: Wed, 9 Jun 2021 12:20:02 +0200 (CEST) From: Mikael Abrahamsson To: Dave Taht cc: Nathan Owens , starlink@lists.bufferbloat.net In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-719994514-1623231731=:13354" X-Mailman-Approved-At: Wed, 09 Jun 2021 10:10:13 -0400 Subject: Re: [Starlink] dynamically adjusting cake to starlink 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: Wed, 09 Jun 2021 10:20:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-719994514-1623231731=:13354 Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT On Wed, 9 Jun 2021, Dave Taht wrote: > … and a meeting with some starlink execs at 11AM today. Nice! The solution space you're working on ("one device knows its next-hop speed and adjacent device needs to know this") is applicable to for instance cable, DSL, PON, wifi etc. I seem to remember there has been work in BBF to have the BNG know the sync-up speed of DSL in order to do proper buffering, what you need to do is to come from "the other end". Would be nice if there was a generic mechanism for this but since several of these devices use L2 I think it'd have to be something LLDP like (also on L2). Dave, how often does information regarding rate/scheduler need to be distributed from the scheduling node to the node that is trying to not use the upstream buffer? I presume this is in the 0.1 to 1s range, because the scheduler might change quite frequently and substantially? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-719994514-1623231731=:13354--