From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 29CBA3B29E for ; Wed, 9 Jun 2021 10:12:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 36BA738AD7; Wed, 9 Jun 2021 10:13:04 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ooUzEsj5mU8L; Wed, 9 Jun 2021 10:13:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A1B0138AD6; Wed, 9 Jun 2021 10:13:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E8DA7486; Wed, 9 Jun 2021 10:12:15 -0400 (EDT) From: Michael Richardson To: Mike Puchol , Nathan Owens , Dave Taht , starlink@lists.bufferbloat.net In-Reply-To: <901ae36f-c5f1-4b0d-af17-90d29c212f78@Spark> References: <901ae36f-c5f1-4b0d-af17-90d29c212f78@Spark> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m 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 14:12:17 -0000 welcome! So happy to have you. Mike Puchol wrote: > As for the topic at hand, I understand the concept - in essence, if we > can find what the Dishy - satellite - gateway triumvirate is doing in > terms of capacity and buffering, we can apply that information into o= ur > own router=E2=80=99s buffer/queue strategy. I have taken a quick look= at the > document, and there is one assumption that is wrong, AFAIK, which is > that the satellites are =E2=80=9Cbent pipes=E2=80=9D - they actually = process packets, > which means they are an active component of buffering and queuing in > the path (for optical links to work, satellites would necessarily have > to process packets). So, when we say "bent pipe", we don't mean that literally. (I know that it was literally true at some point). We don't mean to imply that the satelli= te does not reconstruct the binary content of the packet from the baud's of symbols. What we primarily mean is that stuff goes in one side *ALL* comes out the other side, and that the satellite does not *at this time*, make nexthop decisions based upon (IP) packet content. Of course there are some kind of identifier to tell the satellite what end-user station to send data to in t= he direction towards the user. (Also, we talk about uplink/downlink from the point of view of the the end user station. But, are there better terms from the satellite's point of view to distinguish traffic to/from the end user?) It is my understanding that at some point, traffic between (end-user) stations will be possible via multiple satellite hops, and without a trip to the ground to a routing decision. But that isn't happening right now. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [