IETF Logo Mail Archive

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

Arashmid Akhavain <arashmid.akhavain@gmail.com> Wed, 23 February 2022 15:39 UTC

Return-Path: <arashmid.akhavain@gmail.com>
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 B56053A10CE for <etosat@ietfa.amsl.com>; Wed, 23 Feb 2022 07:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bm-XwvDmzu27 for <etosat@ietfa.amsl.com>; Wed, 23 Feb 2022 07:39:13 -0800 (PST)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3ECE3A10CB for <etosat@ietf.org>; Wed, 23 Feb 2022 07:39:12 -0800 (PST)
Received: by mail-pj1-x1031.google.com with SMTP id b8so2998118pjb.4 for <etosat@ietf.org>; Wed, 23 Feb 2022 07:39:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0mK5L1FqIl4eTgmETKLCJip57zs4CAJvv5qY2MO31xg=; b=pyaE8iKwYF0hZyacuqqYO7BG4qJBCbv7dOT2v+//NkLtQ0a3N6KFnIVPRNPpHpIgh3 Xf6E+OZYRMRxpqLHWGRrtgSQV8qSL1HV2/+GQkKu4Em8Ia9FNFo4grOlgGqv4jml3I67 KqlG6vMF0crX7AFegfN0vBl0ULHyQjUsuCCnpM6oTvD8SAuQU9G7LwzD/HBHgcedGKwf UMBvlFBplhZAOOQKdM98emSbRZwh0NaIN1CHwyBrj7AYStHYrwdjX59wEFNZ4F9u46sl n3H5JGvaqKr6nl86BHPMWys39UtER1NxCbXSqGaHC9qXS0zxIOxMqD6DCN1oGEW4UhqX ybcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0mK5L1FqIl4eTgmETKLCJip57zs4CAJvv5qY2MO31xg=; b=fMMvabQKRhHK6Exqk/iSxy7pw3wdNeaAsSya808J8m2yhTK0NgsbPMwRIbnqwxo5T0 ppgx9NV3Cld3X6gmlDLpr2NgL8B/YF48EnPxf352HX+CJ7+N7wv/srG8muYXQ1KBgqKV +DT3tznmF1HgSsjqBou4Io9z16JHHdE5SQ0XWmLIeRcbPPq87K47rAhLYs1h/iC3tlxn 7J92ei0LMRO9ZyZooN2cunEin8kDI72nNh7p51F8bNNNUWVcGKw+mI3vRme2diAJTaO7 pnRu6ySNIGbD0jGTCsWxRm2/TAyR92Gba/DAGTIAl7DmebJ6Mbck5DZYG2zL+K0ChbbY 4RnQ==
X-Gm-Message-State: AOAM533Q75lWOnjXBTK0VAI9VX4aqscESndFEMjba+o8FxtizwoU2oWV Vkm+LROy+mZbZLBf7UGRN76WT4X1KZ0fdLAewctPhjFu
X-Google-Smtp-Source: ABdhPJw+aZ9wGTIqZvEyuFYhGTvHjI15Ofy+NLOlV2luYwI7zpWpCY44aGKsfT2T/pjWkbPil+6VBDqyzVfAixEga4k=
X-Received: by 2002:a17:902:8ec6:b0:14f:a7cd:7dfa with SMTP id x6-20020a1709028ec600b0014fa7cd7dfamr109366plo.141.1645630751743; Wed, 23 Feb 2022 07:39:11 -0800 (PST)
MIME-Version: 1.0
References: <CAC4j5ERK9D9QsoQeF=4CxJ0eJeNs+kN3Zq0+GPKPmnPFW=977w@mail.gmail.com> <f0210e6b-5519-44ff-c102-beaa91f8a9ad@oneunified.net>
In-Reply-To: <f0210e6b-5519-44ff-c102-beaa91f8a9ad@oneunified.net>
From: Arashmid Akhavain <arashmid.akhavain@gmail.com>
Date: Wed, 23 Feb 2022 10:38:59 -0500
Message-ID: <CAC4j5ER6Pp6P3Ey4tminiDxkHwrX5161y66jhi5QWfy4Bfqung@mail.gmail.com>
To: Raymond Burkholder <ray@oneunified.net>
Cc: etosat@ietf.org
Content-Type: multipart/alternative; boundary="00000000000063a1f405d8b14463"
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/2yPpudqFqYuZSwnInOIARZ5f9aw>
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 15:39:18 -0000

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?

On Tue, Feb 22, 2022 at 10:07 PM Raymond Burkholder <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 listEToSat@ietf.orghttps://www.ietf.org/mailman/listinfo/etosat
>
>
> _______________________________________________
> EToSat mailing list
> EToSat@ietf.org
> https://www.ietf.org/mailman/listinfo/etosat
>

v2.23.0 | Report a Bug | By Email