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

Raymond Burkholder <ray@oneunified.net> Wed, 23 February 2022 20:44 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 C1EB03A0C3C for <etosat@ietfa.amsl.com>; Wed, 23 Feb 2022 12:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.614
X-Spam-Level:
X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 n788h1vlLHMe for <etosat@ietfa.amsl.com>; Wed, 23 Feb 2022 12:44:21 -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 689983A0C32 for <etosat@ietf.org>; Wed, 23 Feb 2022 12:44:21 -0800 (PST)
X-One-Unified-MailScanner-Watermark: 1646253852.19309@fYtT0aYbmYMsoRH47Axq1Q
X-One-Unified-MailScanner-From: ray@oneunified.net
X-One-Unified-MailScanner: Not scanned: postmaster@oneunified.net
X-One-Unified-MailScanner-ID: 21NKi95x020849
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 21NKi95x020849 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Feb 2022 20:44:11 GMT
To: Arashmid Akhavain <arashmid.akhavain@gmail.com>, Nicolas Kuhn <nicolas.kuhn.ietf@gmail.com>
Cc: Tomaso.deCola@dlr.de, etosat@ietf.org
References: <CAC4j5ERK9D9QsoQeF=4CxJ0eJeNs+kN3Zq0+GPKPmnPFW=977w@mail.gmail.com> <f0210e6b-5519-44ff-c102-beaa91f8a9ad@oneunified.net> <85aa1a9d30c745c08598384bb68bdcf9@dlr.de> <CAL0D2oRBmEF0J8=3OJ0UNi7TfLkKJudvhVVsGg9wAEw4H-V8RQ@mail.gmail.com> <CAC4j5ET9988rpnq0GrrGspY9HEnc+YoLRP0-1DdQmdTSPsjZ3w@mail.gmail.com>
From: Raymond Burkholder <ray@oneunified.net>
Organization: One Unified Net Limited
Message-ID: <0b0b3ea4-da9d-c94c-b4e5-3d2e19fa46e7@oneunified.net>
Date: Wed, 23 Feb 2022 13:44:09 -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: <CAC4j5ET9988rpnq0GrrGspY9HEnc+YoLRP0-1DdQmdTSPsjZ3w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/wFS0IQSjDjyr9mregvTPGSUNl-s>
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 20:44:25 -0000

On 2022-02-23 1:36 p.m., Arashmid Akhavain wrote:
> That could be another alternative.
> The question that I have been struggling with is whether and how 
> satellite networks can benefit from standardisations. These networks 
> are proprietary (at least for the time being). It is difficult to 
> imagine satellites in a multi-vendor ecosystem.

In the not too distant future (as in, it is being worked on right now), 
some operators will be carrying the traffic of other operators.  ie, 
backbone operators in the sky will have a good foot print of ground 
stations, and will be providing backbone operations to satellite 
operators who don't have a large ground footprint (this is the sky to 
sky to ground scenario, vs the broadband up-down scenario).

There then needs to be some sort of interoperability of the carrier vs 
the end-user in terms of how to get a endnode-satellite's data 
encapsulated across a carrier's satellite network down to the ground and 
then over to the subscriber's site in a real-time fashion.

>
> That's why I asked what the authors of this draft intended to do.
>
> Arashmid
>