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

[Haoyu Song <[e-mail]>]

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

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.


Best,
Haoyu



From: Deepspace <[e-mail]> On Behalf Of Marc Blanchet
Sent: Monday, September 25, 2023 10:44 AM
To: Kiran Makhijani <[e-mail]>
Cc: [e-mail]
Subject: Re: [Deepspace] comments on draft-many-deepspace-ip-assessment (section 2, 3)




Le 24 sept. 2023 à 07:00, Kiran Makhijani <[e-mail]<mailto:[e-mail]>> 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