From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 7F4A83B29E for ; Wed, 9 Jun 2021 17:37:06 -0400 (EDT) Received: by mail-il1-x12e.google.com with SMTP id x18so28030006ila.10 for ; Wed, 09 Jun 2021 14:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nathan.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eTLhXYzAqy8oPAr3WQ1i3unSRrgenPKiV3UOAE8Gz6I=; b=fhFwWWuUZeaunjIzhiuK0EOM0MjiY35e1R+NSCPbjxO2pDzvPunx2ythYAAoTtZm/h h/86TIN8FmncllnOkMdLKkqUwcPR2KwEUDreEiWKwRdT7W2tEfLjC2I1DjHm4guSvD4I AJjHeyaFSMxYyAbdTSLGqpGm2ZSXOWMDt8Dvb5nZnnFCWojPG6zb9f9PXvfHgsnwklk6 G5XxTguDsPa4hbbXef+F9RuOBx/qBOeNgxApeKxpaGnwFNbT/jvWVDg1KUbcdAt6GQ8f FH1Hotje+6pLaUl8n02DcUE9VdGupHqe+V62Hx5ufM5tVJWSBTh7zg2uuXWDQ0UTB3j5 icFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eTLhXYzAqy8oPAr3WQ1i3unSRrgenPKiV3UOAE8Gz6I=; b=LtESX8neXS40LLpbU+zislYuHQodmv32iek8wCYadElKt4fqm/sxRH6eqEgXUKaBoZ nOrNBYLPBE4sPuNl5CwdXkJk2Gv7kCgJ1IHk9EzjEWcuCA0210E6mfsh8jHaWkDD32/R qUZ4XmT5qBGGGV9KX4PN/FOLC8eGKUmw4BIAM7J4wWgDXCPis399D790VSYylakwn4h6 tV/SIRZZV1drK9qf861G4MrqerYumU+VXjdcjbhr88R1NnbySzd9+Wg7AiG2QgOVPsqF 8KY2NhRh65bYSyUbslvkCHitlj3zDAUVG5NVnPadOp0IejqI5Le5NWzwImORyjJ5lwPW /wPA== X-Gm-Message-State: AOAM532rgy0Fk6DuOGJg8Eo7aBsbcsadBB8ldbxP6qgeB5JvCvFC+qbU 09l/OuoiQPzx9a1nEdzDtoOzowT2yHxjnDJEnNwmFgQJH8zsC3pGleM= X-Google-Smtp-Source: ABdhPJzguNXcfrvjEwz2C+O1jO1xZfR4GuKEZYITTr4TIsa7QiEXUMeOYNmmN207vI6xIRfzpMInTIG8X+lw1yTfup0= X-Received: by 2002:a92:c808:: with SMTP id v8mr1270208iln.280.1623274625424; Wed, 09 Jun 2021 14:37:05 -0700 (PDT) MIME-Version: 1.0 References: <901ae36f-c5f1-4b0d-af17-90d29c212f78@Spark> <22686.1623247935@localhost> <12105.1623273530@localhost> In-Reply-To: <12105.1623273530@localhost> From: Nathan Owens Date: Wed, 9 Jun 2021 14:36:54 -0700 Message-ID: To: Michael Richardson Cc: Mike Puchol , Dave Taht , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000006bf58105c45c133f" 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 21:37:06 -0000 --0000000000006bf58105c45c133f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > This would seem to wind up overloading the downlink to the gateway, as well as causing hard to predict fluctuations in bandwidth. This is definitely = a complex situation where I can see buffers being added looks like a good cure-all. We'll find out soon enough... Polar launches start in July. > Do you know how traffic is being steered? I.e. how does the Gateway say which terminal traffic is to? All we know is that tweet "Simpler than IPv6= " Some kind of SDN, but based upon what kind of discriminators? Are there circuits involved (ala ATM or PPPoE), tags like MPLS or 802.1Q? My intuition would be that traffic is encap'd when it enters a PoP based on the destination IP, and the state of the constellation. The encapsulation could just be MPLS with a segment routing-like approach, it would contain the desired gateway, satellite, and terminal ID. On Wed, Jun 9, 2021 at 2:18 PM Michael Richardson wrote: > > Mike Puchol wrote: > > This is correct, with a few twists once you throw in inter-satellit= e > > links. In future satellite versions, optical > > links will allow satellites within the same orbital plane to use ea= ch > > other as relays, thus providing coverage in areas not within a > > gateway=E2=80=99s coverage. > > This would seem to wind up overloading the downlink to the gateway, as we= ll > as causing hard to predict fluctuations in bandwidth. This is definitel= y > a > complex situation where I can see buffers being added looks like a good > cure-all. > > Allowing for direct terminal to terminal traffic would ultimately help > as many of the latency sensitive things like gaming and video calls are > often > rather local. > > mcr> (Also, we talk about uplink/downlink from the point of view of > the the end > mcr> user station. But, are there better terms from the satellite's > point of > mcr> view to distinguish traffic to/from the end user?) > > > In general, downlink is anything from satellite to ground, be it > > satellite -> gateway or satellite -> terminal, and uplink the rever= se > > path. These are the clearest terms to use IMHO. Thus, if satellite = to > > terminal has 75/25 DL/UL duty cycle, the satellite to gateway link > will > > be reversed, with 25/75 DL/UL duty cycle. > > Yeah, so in order to speak usefully about some of this stuff, I think we > need > to distinguish between traffic going "up" which is going towards the > Gateway, > from traffic which might be going "up" from the Gateway (or across from > another satellite). Some additional terms would help. I had hoped that > there were some :-) > > Do you know how traffic is being steered? I.e. how does the Gateway say > which terminal traffic is to? All we know is that tweet "Simpler than > IPv6" > Some kind of SDN, but based upon what kind of discriminators? > Are there circuits involved (ala ATM or PPPoE), tags like MPLS or 802.1Q? > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > --0000000000006bf58105c45c133f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> This would seem to wind up overloading the downl= ink to the gateway, as well
as causing hard to predict fluctuations in bandwidth.=C2=A0 =C2=A0This is d= efinitely a
complex situation where I can see buffers being added looks like a good
cure-all.

We'll find out soon enough... Polar = launches start in July.

> Do you know how = traffic is being steered?=C2=A0 I.e. how does the Gateway say
which terminal traffic is to?=C2=A0 All we know is that tweet "Simpler= than IPv6"
Some kind of SDN, but based upon what kind of discriminators?
Are there circuits involved (ala ATM or PPPoE), tags like MPLS or 802.1Q?

My intuition would be that traffic is encap&#= 39;d when it enters a PoP based on the destination IP, and the state of the= constellation. The encapsulation could just be MPLS with a segment routing= -like approach, it would contain the desired gateway, satellite, and termin= al ID.

On Wed, Jun 9, 2021 at 2:18 PM Michael Richardson &l= t;mcr@sandelman.ca> wrote:

Mike Puchol <mike@= starlink.sx> wrote:
=C2=A0 =C2=A0 > This is correct, with a few twists once you throw in int= er-satellite
=C2=A0 =C2=A0 > links. In future satellite versions, optical
=C2=A0 =C2=A0 > links will allow satellites within the same orbital plan= e to use each
=C2=A0 =C2=A0 > other as relays, thus providing coverage in areas not wi= thin a
=C2=A0 =C2=A0 > gateway=E2=80=99s coverage.

This would seem to wind up overloading the downlink to the gateway, as well=
as causing hard to predict fluctuations in bandwidth.=C2=A0 =C2=A0This is d= efinitely a
complex situation where I can see buffers being added looks like a good
cure-all.

Allowing for direct terminal to terminal traffic would ultimately help
as many of the latency sensitive things like gaming and video calls are oft= en
rather local.

=C2=A0 =C2=A0 mcr> (Also, we talk about uplink/downlink from the point o= f view of the the end
=C2=A0 =C2=A0 mcr> user station. But, are there better terms from the sa= tellite's point of
=C2=A0 =C2=A0 mcr> view to distinguish traffic to/from the end user?)
=C2=A0 =C2=A0 > In general, downlink is anything from satellite to groun= d, be it
=C2=A0 =C2=A0 > satellite -> gateway or satellite -> terminal, and= uplink the reverse
=C2=A0 =C2=A0 > path. These are the clearest terms to use IMHO. Thus, if= satellite to
=C2=A0 =C2=A0 > terminal has 75/25 DL/UL duty cycle, the satellite to ga= teway link will
=C2=A0 =C2=A0 > be reversed, with 25/75 DL/UL duty cycle.

Yeah, so in order to speak usefully about some of this stuff, I think we ne= ed
to distinguish between traffic going "up" which is going towards = the Gateway,
from traffic which might be going "up" from the Gateway (or acros= s from
another satellite).=C2=A0 Some additional terms would help.=C2=A0 I had hop= ed that
there were some :-)

Do you know how traffic is being steered?=C2=A0 I.e. how does the Gateway s= ay
which terminal traffic is to?=C2=A0 All we know is that tweet "Simpler= than IPv6"
Some kind of SDN, but based upon what kind of discriminators?
Are there circuits involved (ala ATM or PPPoE), tags like MPLS or 802.1Q?
--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [

--0000000000006bf58105c45c133f--