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

[Kiran Makhijani <[e-mail]>]

Hi Authors,

Thank you for sharing this work. An interesting read and a very clearly
written  document. 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. 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.

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. E.g. Will there be more traffic coming
downstream? Or aggregation will happen on nodes closer to terrestrial nodes?

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.

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.

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.
Second, you maybe interested in BGP over QUIC (draft-retana-idr-bgp-quic)
based on discussion Section 4.


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.
HTH,
Kiran