From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp112.iad3a.emailsrvr.com (smtp112.iad3a.emailsrvr.com [173.203.187.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 731DF3B29E for ; Mon, 3 Oct 2022 13:09:15 -0400 (EDT) Received: from app6.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp15.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 05E54426A for ; Mon, 3 Oct 2022 13:09:15 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app6.wa-webapps.iad3a (Postfix) with ESMTP id E3FB4E1106 for ; Mon, 3 Oct 2022 13:09:14 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 3 Oct 2022 13:09:14 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Mon, 3 Oct 2022 13:09:14 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20221003130914000000_54041" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1664816954.930829937@apps.rackspace.com> X-Mailer: webmail/19.0.20-RC X-Classification-ID: b322e3cc-aacc-4158-b3b2-116cea597017-1-1 Subject: Re: [Starlink] =?utf-8?q?mike=27s_starlink_2=2E0_sim_is_up_=28Dave_Ta?= =?utf-8?b?aHQp?= 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, 03 Oct 2022 17:09:15 -0000 ------=_20221003130914000000_54041 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0AI read through all of Mike Puchol's materials. Quite elaborate, and = interesting theoretical work.=0A =0AHowever, I have to say I am quite disap= pointed for two reasons:=0A =0A1. the system being modeled here does not ap= pear to be based on facts about the actual implementation of the link and "= satellite" switching protocols. Instead, it is based on calculating RF band= width availability, getting a *maximum achievable rate*. It's analogous to = looking at 802.11ax or 802.11ac systems and assuming that the "channel" use= d by the access point can be fully utilized using whatever OFDM modulation = scheme is being used. That is, it ignores what we in Ethernet land call the= MAC protocol.=0A =0A2, There's an assumption that the dishys are "full dup= lex" - that is, that they can transmit and receive at the same time. While = I don't know for sure, I'm pretty certain that the current dishy arrays tha= t people have dissected cannot transmit and receive at the same time. This = is for the same reason that the MIMO arrays on 802.11 stations cannot, in p= ractice, transmit and receive at the same time. The satellite altitude impo= ses a significant power difference between sent and received signals. =0A = =0ATo me this is confirmed by all the bufferbloat observations being made i= n the field.=0A =0AThe problem with the kind of analysis that Mike Puchol i= s doing is that it assumes "wire speed" transmission without considering th= e problem of managing end-to-end latency at all.=0A =0ASome of you have hea= rd me call this the "hot rodder attitude" to performance. Yes, you can desi= gn a car that only accelerates at full acceleration for a quarter mile. But= that same car is worse than terrible for ordinary driving needs - it canno= t stop, it cannot maintain speed easily, ...=0AWhat we have if we look at f= requency-bandwidth based simulations is a *terrible* network for carrying I= nternet traffic. Completely irrelevant.=0A =0AThis Starlink constellation i= s used in a packet-switching mode. Lowest possible end-to-end latency is re= quired, even more than throughput. When 100 stations want to send a packet= through the satellite to the "cell" ground station, they can't all send at= once. They want latency for their voice frame (if they are using Zoom) to = be under 100 msec. from the PC to the Zoom headend and back to another PC. = Voice frames are typically very small numbers of bits (whatever is needed t= o represent 10-30 msec. of high quality audio.=0A =0AIf the packets can't d= o that 100 msec. round trip, quality is degraded to useless.=0A ------=_20221003130914000000_54041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

=0A

I read through all of Mike Puchol's materials. Quite elaborate= , and interesting theoretical work.

=0A

 

= =0A

However, I have to say I am quite disappointed for = two reasons:

=0A

 

=0A

1= . the system being modeled here does not appear to be based on facts about = the actual implementation of the link and "satellite" switching protocols. = Instead, it is based on calculating RF bandwidth availability, getting a *m= aximum achievable rate*. It's analogous to looking at 802.11ax or 802.11ac = systems and assuming that the "channel" used by the access point can be ful= ly utilized using whatever OFDM modulation scheme is being used. That is, i= t ignores what we in Ethernet land call the MAC protocol.

=0A

 

=0A

2, There's an assumption that t= he dishys are "full duplex" - that is, that they can transmit and receive a= t the same time. While I don't know for sure, I'm pretty certain that the c= urrent dishy arrays that people have dissected cannot transmit and rec= eive at the same time. This is for the same reason that the MIMO arrays on = 802.11 stations cannot, in practice, transmit and receive at the same time.= The satellite altitude imposes a significant power difference between sent= and received signals. 

=0A

 

=0A

To me this is confirmed by all the bufferbloat observations = being made in the field.

=0A

 

=0A

The problem with the kind of analysis that Mike Puchol is doin= g is that it assumes "wire speed" transmission without considering the prob= lem of managing end-to-end latency at all.

=0A

 = ;

=0A

Some of you have heard me call this the "hot r= odder attitude" to performance. Yes, you can design a car that only acceler= ates at full acceleration for a quarter mile. But that same car is worse th= an terrible for ordinary driving needs - it cannot stop, it cannot maintain= speed easily, ...

=0A

What we have if we look at fr= equency-bandwidth based simulations is a *terrible* network for carrying In= ternet traffic. Completely irrelevant.

=0A

 =0A

This Starlink constellation is used in a packet-sw= itching mode. Lowest possible end-to-end latency is required, even more tha= n throughput.  When 100 stations want to send a packet through the sat= ellite to the "cell" ground station, they can't all send at once. They want= latency for their voice frame (if they are using Zoom) to be under 100 mse= c. from the PC to the Zoom headend and back to another PC. Voice frames are= typically very small numbers of bits (whatever is needed to represent 10-3= 0 msec. of high quality audio.

=0A

 

=0A

If the packets can't do that 100 msec. round trip, quality= is degraded to useless.

=0A

 

------=_20221003130914000000_54041--