Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt

Raymond Burkholder <ray@oneunified.net> Wed, 23 February 2022 16:17 UTC

Return-Path: <ray@oneunified.net>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C5C3A1134 for <etosat@ietfa.amsl.com>; Wed, 23 Feb 2022 08:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.389
X-Spam-Level: **
X-Spam-Status: No, score=2.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIM9QqFcYNyl for <etosat@ietfa.amsl.com>; Wed, 23 Feb 2022 08:17:08 -0800 (PST)
Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B9F3A112E for <etosat@ietf.org>; Wed, 23 Feb 2022 08:17:07 -0800 (PST)
X-One-Unified-MailScanner-Watermark: 1646237821.47518@DtKC/KcxTPt/PHUy9YIKDQ
X-One-Unified-MailScanner-From: ray@oneunified.net
X-One-Unified-MailScanner: Not scanned: postmaster@oneunified.net
X-One-Unified-MailScanner-ID: 21NGGvKf017046
X-OneUnified-MailScanner-Information: Please contact the ISP for more information
Received: from [10.55.90.10] (host96-45-2-121-eidnet.org [96.45.2.121] (may be forged)) (authenticated bits=0) by mail1.oneunified.net (8.14.4/8.14.4/Debian-4) with ESMTP id 21NGGvKf017046 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Feb 2022 16:17:00 GMT
To: Arashmid Akhavain <arashmid.akhavain@gmail.com>
Cc: etosat@ietf.org
References: <CAC4j5ERK9D9QsoQeF=4CxJ0eJeNs+kN3Zq0+GPKPmnPFW=977w@mail.gmail.com> <f0210e6b-5519-44ff-c102-beaa91f8a9ad@oneunified.net> <CAC4j5ER6Pp6P3Ey4tminiDxkHwrX5161y66jhi5QWfy4Bfqung@mail.gmail.com>
From: Raymond Burkholder <ray@oneunified.net>
Organization: One Unified Net Limited
Message-ID: <edba36e1-af33-b57c-c1d1-7d2d0e655eac@oneunified.net>
Date: Wed, 23 Feb 2022 09:16:57 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CAC4j5ER6Pp6P3Ey4tminiDxkHwrX5161y66jhi5QWfy4Bfqung@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------2EB51B47BACD8E88DC91C4B9"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/67MslDC96dafexyfobNIZmshahI>
Subject: Re: [EToSat] New Version Notification for draft-lhan-problems-requirements-satellite-net-02.txt
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2022 16:17:13 -0000

On 2022-02-23 8:38 a.m., Arashmid Akhavain wrote:
> This sounds like an interesting approach. The routing system has to 
> deal with both predictable (majority) and unpredictable link events. 
> Traditional SDN systems might not be able to perform as the number of 
> nodes goes up drastically. Is this work public, or proprietary?

Their implementation is proprietary, but many of the concepts are common 
knowledge:

  * based upon TLE information, ground stations can compute satellite
    feasible neighbors
  * using network flow algorithms, feasible paths can be computed
  * there is now enough satellite-local compute available such that
    multiple ground stations can compute these paths and advertise
    upwards, and satellites pick the 'best' suggestion for paths to
    ground (based upon local awareness of rf and link capability/capacity)
  * the flow calculations take in to consideration the sum of path
    latencies on the ground, earth-sky, and satellite-satellite
  * multiple ground stations perform the computation as not all are
    connected upwards at all times

Is there a 'forum' where some of this could be developed in public?


>
> On Tue, Feb 22, 2022 at 10:07 PM Raymond Burkholder 
> <ray@oneunified.net <mailto:ray@oneunified.net>> wrote:
>
>     On 2022-02-22 1:27 p.m., Arashmid Akhavain wrote:
>>     I agree that existing IP routing protocols can face convergence
>>     issues when it comes to satellite networks. IP and existing
>>     routing protocols rely on hierarchy to minimise the impact of
>>     link events. Establishing hierarchy in satellite networks can be
>>     very complex due to various movements especially when it comes to
>>     massive constellations.
>>
>>     In polar constellations, the movement at the poles, and the seam
>>     plane will be problematic for existing routing protocols. The
>>     issue of course gets exacerbated in the Walker Delta
>>     constellation as the seam effect exists between every other orbit.
>>
>>     A new method of routing might be required to address this issue.
>>     What are your plans w.r.t to this draft? Have you discussed some
>>     of these issues with any of the working groups?
>     Using standard routing protocols are problematic as they are
>     reactive.  And due to inter-satellite delays, can take time to
>     re-converge.  I was working with a company to come up with an SDN
>     solution where we used TLE (Two Line Elements) to compute
>     satellite nearness and then pre-populate neighbor entries for
>     installation at pre-arranged times.
>
>     In addition, to do this properly, these neighbor entries and
>     routing table entries need to be populated based upon distributed
>     path computation capabilities (due to the fact that the same
>     ground stations are not always in view, and paths need to be
>     adjusted as necessary).
>
>>
>>     Best regards,
>>     Arashmid
>>
>>
>>     _______________________________________________
>>     EToSat mailing list
>>     EToSat@ietf.org  <mailto:EToSat@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/etosat  <https://www.ietf.org/mailman/listinfo/etosat>
>
>     _______________________________________________
>     EToSat mailing list
>     EToSat@ietf.org <mailto:EToSat@ietf.org>
>     https://www.ietf.org/mailman/listinfo/etosat
>     <https://www.ietf.org/mailman/listinfo/etosat>
>