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

[Marc Blanchet <[e-mail]>]

> Le 25 sept. 2023 à 21:46, Christian Huitema <[e-mail]> a écrit :
> 
> 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.

100% agree.

Marc.

> 
> -- 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.
>> 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