Re: [Deepspace] comments on draft-many-deepspace-ip-assessment (section 2, 3)

[Kiran Makhijani <[e-mail]>]

Yes, prefix carving should work.


On September 25, 2023 at 1:10:35 PM, Dean Bogdanovic ([e-mail])
wrote:


On 25 Sep 2023, at 15:46, Christian Huitema wrote:

> Encoding properties in addresses looks tempting at first sight, but is
generally considered misguided. Before we even try doing that, it would be
much simpler to carve out an IPv6 prefix for use by space devices. That
would achieve pretty much all the stated goals without the added cost of
fracturing the address space.

In agreement.

> -- Christian Huitema
>
> On 9/25/2023 12:29 PM, Kiran Makhijani wrote:
>> Haoyu,
>>
>> Very good observation about long-term evolution vs earth-centric DTNs.
>> The use cases I considered are of the nature where (1) very large
>> scientific data “returned” from very far space-objects to be sent to
>> earth, (2) remote operation on space-objects (command-response) but
>> they should not have large data transmission requirements. Both these
>> are near-term (say next 5 to 30 years span).
>>
>> Perhaps, the current document could make an explicit statement about
>> this. It is relatively straight-forward when one endpoint is
>> terrestrial device. The reachability, addressing and routing will need
>> to consider such scenarios.
We are considering example like this, scientist are planning to launch
multiple space crafts that will act as single scientific object, (radio
telescope). There will be a need to create a network for communication
between the space crafts and between that constellation and Earth. Probably
each space craft in the constellation should be able to communicate to the
Earth and provide GW functionality to Earth.
This is typical routing problem that existing routing protocols can solve,
with some modifications.

Dean

>>
>> On the topic of Addressing, the goal is to adopt existing IP as much
>> to the extent possible. However, I think we could at least consider
>> the address-semantics or some other indication of a connection’s DTN
>> nature.
>>
>> Cheers,
>> Kiran
>>
>> On September 25, 2023 at 11:30:39 AM, Marc Blanchet
>> ([e-mail] (mailto:[e-mail])) wrote:
>>
>>>
>>>> Le 25 sept. 2023 à 20:23, Haoyu Song a écrit :
>>>> “(FYI, in space parlance, upstream is named « forward » and downstream
is named « return »)”
>>>>
>>>> I think such an earth-centric perspective would become outdated when
we consider the possibility of manned bases on other celestial bodies.
>>>>
>>>>
>>>
>>>
>>> Sure. I was saying that specific « parlance » because if one read any
current document related to space comm, it is written with those words.
>>>
>>>> For the addressing, even though IPv6 may support enough addresses, it
might be worth considering to put the outer space into different address
space other than the terrestrial Internet. While this requires some
protocol extension, it makes the architecture cleaner and more manageable.
>>>
>>> I’m not sure I get your point. Are you saying:
>>> a) use something different than the IPv6 protocol?
>>> b) carve out some IPv6 address space within the 2000::/3 current
allocated address space?
>>> c) carve out some IPv6 address space outside the 2000::/3 unallocated
space?
>>> d) else?
>>>
>>> I guess it depends on the first answer, but why it would require
protocol extensions?
>>>
>>> And what is the real gain?
>>>
>>> Marc.
>>>
>>>
>>>> Best,
>>>> Haoyu
>>>>
>>>>
>>>>
>>>> From: Deepspace On Behalf Of Marc Blanchet
>>>> Sent: Monday, September 25, 2023 10:44 AM
>>>> To: Kiran Makhijani
>>>> Cc: [e-mail] (mailto:[e-mail])
>>>> Subject: Re: [Deepspace] comments on
draft-many-deepspace-ip-assessment (section 2, 3)
>>>>
>>>>
>>>>
>>>>
>>>>> Le 24 sept. 2023 à 07:00, Kiran Makhijani a écrit :
>>>>>
>>>>> Hi Authors,
>>>>>
>>>>>
>>>>> Thank you for sharing this work. An interesting read and a very
clearly written document.
>>>>
>>>>
>>>> Thanks for taking the time to review it.
>>>>
>>>>
>>>>
>>>>> I thought I'd share my comments mainly for clarifications. Please
bear with me since I have not followed DTN work.
>>>>>
>>>>> My main take aways from the document is that the intention to use the
existing protocols as much through configuration knobs as possible. This is
apt and gives a very clear direction.
>>>>
>>>>
>>>> yes.
>>>>
>>>>
>>>>
>>>>> Hopefully, as the work matures we will see per protocol configurable
values in one place. My expectation is current protocol YANG models support
those as is.
>>>>
>>>>
>>>> Yes. Agreed.
>>>>
>>>>
>>>>
>>>>>
>>>>> Section 2:
>>>>>
>>>>>
>>>>> I do not know if DTN work has already covered this: I will find it
useful to document/understand the potential traffic profiles a bit more.
For example, upstream (towards nodes in space) vs downstream (towards
Earth) will have different behavior.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> (FYI, in space parlance, upstream is named « forward » and downstream
is named « return »)
>>>>
>>>>
>>>>
>>>>> E.g. Will there be more traffic coming downstream?
>>>>
>>>>
>>>> Typically now, « forward » is mostly used for command and control and
it is in kbps range. Return is telemetry and have much larger bandwidth.
But space link technology is changing also, for example with lasers that
will provide way different capabilities.
>>>>
>>>>
>>>>
>>>>> Or aggregation will happen on nodes closer to terrestrial nodes?
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Good question. I guess the « architecture » should not mandate
anything.
>>>>
>>>>
>>>>
>>>>>
>>>>> My comment is related to the discussion on
queue-management/dicipline. The text left me more curious about what and
why AQM (old or new) will be of interest. Again, maybe, DTN has covered it
already. The data rates and congestion will take different meaning in
deep-space networking and will vary between upstream and downstream. E.g.
How does an intermediate node QM can provide
>>>>> timely feedback to end-station, specifically what it dropped.
>>>>
>>>>
>>>> Good question. There is more work to be done on the queueing
discipline. It could be very simple and let QUIC takes care of congestion
and …
>>>>
>>>>
>>>>
>>>>> Since we need a delay-tolerant network, won't feedback about
queue-lengths arrive too late? My inclination is to focus discussion on
buffer management instead of queue disciplines (perhaps not needed unless
reassembly or ordering). Perhaps it is just a terminology issue.
>>>>
>>>>
>>>> Yes. You are right. There is definitely buffer management. The
queueing discipline could be very simple.
>>>>
>>>>
>>>>
>>>>>
>>>>> Section 3:
>>>>> You bring up BGP, perhaps more justification is required. First,
given that no topology reference is given, the usecase for the choice of
routing protocol is not clearly evaluated.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Agreed. Left as TBD.
>>>>
>>>>
>>>>
>>>>> Second, you maybe interested in BGP over QUIC
(draft-retana-idr-bgp-quic) based on discussion Section 4.
>>>>
>>>>
>>>> Yeah. These are also considerations for specific deployments. Would
one run BGP over space links? In the traditional sense, that would mean
crossing network boundaries. Or the use of BGP for all the various other
ways in internal networks used today. Some people say maybe static routes
with TVR adaptation is just fine. Or RIP. Routing for this use case is
really in scope for the TVR working group. We do not intend to copy what
TVR is doing, but reference it.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Minor editorial suggestions
>>>>>
>>>>> Section 1.
>>>>>
>>>>> In the abstract and intro, i think it is better to clarify upfront
that delay-tolerant IP stack is being scoped.
>>>>>
>>>>>
>>>>>
>>>>> OLD:
>>>>> This result lead to the definition of a new protocol stack based on a
store-and-forward
>>>>> NEW:
>>>>> This result lead to the definition of a new delay tolerant protocol
stack based on a store-and-forward
>>>>>
>>>>> I have comments on transport and beyond sections but can bring them
later to avoid lengthy email.
>>>>
>>>>
>>>> Thanks a lot, very appreciated.
>>>>
>>>>
>>>>
>>>> Marc.
>>>>
>>>>
>>>>
>>>>> HTH,
>>>>> Kiran
>>>>>
>>>>> --
>>>>> Deepspace mailing list
>>>>> [e-mail] (mailto:[e-mail])
>>>>> https://www.ietf.org/mailman/listinfo/deepspace
>>
>
> --
> Deepspace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/deepspace