[deepspace] Review comments on draft-ietf-tiptop-ip-architecture-01

["Martine S. Lenders" <[e-mail]>]

Hi,

find below my review for draft-ietf-tiptop-ip-architecture-01. Since I 
am coming from an IoT background, I focussed on that but also found some 
other things.

Cheers
Martine

---

The figure in Section 2 
(https://www.ietf.org/archive/id/draft-ietf-tiptop-ip-architecture-01.html#section-2-6, 
figure number missing) does not show the scheduling/orchestration 
systems. Even if they are out-of-band from application flows, adding it 
to the illustration (besides the flow, above the flow, ...) would help 
grasping an early overview using this graphic.

You use MOC in the figure but then "Comm Svc Provider" while you shorten 
the latter to CSP in the text. Use CSP instead of introducing yet 
another abbreviation.

The parenthesized numbers in 
https://www.ietf.org/archive/id/draft-ietf-tiptop-ip-architecture-01.html#section-2-7 
should show up in the Figure.

---

Coming primarily from an IoT background, I am not 100% familiar with the 
link layer protocols utilized in space, so please forgive me if this a 
non-issue. IMHO it should at least be mentioned in Section 4: The draft 
discusses header compression, but does not discuss if the minimum MTU of 
1280 bytes with IPv6 [RFC8200, Section 5] poses a general problem or 
not. Is something like 6LoWPAN or SCHC fragmentation needed? There is 
just a vague reference in the following sentence.

> The additional overhead of an IPv6 packet will have a bandwidth and 
 > performance impact that needs to be considered early in mission
 > planning.

An overview table of the MTUs expected for certain link layers might 
help to clarify.

---

Section 4.1 in 
https://www.ietf.org/archive/id/draft-ietf-tiptop-ip-architecture-01.html#section-4.1-2:

> This queuing may be implemented at layer 2 as currently done by the 
 > Mars orbiters, where frames are stored, regardless of payload type.

Might be the researcher in me but: Citation needed ;-) (also just to 
satiate my personal curiosity).

---

Section 4.1 in 
https://www.ietf.org/archive/id/draft-ietf-tiptop-ip-architecture-01.html#section-4.1-5 
says:

 > Given the use of end to end reliable transport, [...]

Might be worth pointing out in Section 7.1.1 that Confirmable messages 
for CoAP are recommended.

---

Section 5.2: Was RPL [RFC6550] considered in previous iterations? Might 
be worth a look as it was designed for lossy links (originally sleeping 
nodes, but this could also be abstracted to intermittent links).

---

Section 6.1 mentions 0-RTT. Getting into the MTU topic again: Apart from 
replay attacks (and the necessity that context already needs to be 
established), it is also worth noting that QUIC 0-RTT packets are 
considerably larger than 1-RTT packets and might not be suitable for 
small link layers with MTUs. See also [1], Section 5.5.

---

Section 6.1 again: It might be impossible to take RTT measurements. 
However, given that we work in orders of magnitude of minutes, sometimes 
even hours, an upper bound for the RTT could be estimated based on the 
current time and the position of the plenetary bodies. At least when we 
are talking distances between planets/asteroids/etc., no? Maybe this 
could be added to the discussion.

---

Section 7.1.1 calls CoAP a "specialized web transfer" protocol. Given 
that I was in the past also criticized for calling CoAP a web protocol 
(is HTTP even still a web protocol given that it does not exchange that 
much hypertext anymore :P?) I think I would prefer calling it a 
specialized REST protocol here.

---

Section 8.2: Given that CoAP is talked about in the draft, CORECONF 
[I-D.ietf-core-comi] could also be mentioned here.

---

Section 10: PSKs might have a use case with such long distances and 
should be mentioned in. Also OCSP is not a well known abbreviation in 
https://rpc-wiki.rfc-editor.org/doku.php?id=abbrev_list and should be 
resolved.

---

References:

> [ntn6g3gpp]
>     3GPP, "Non-Terrestrial Networks (NTN)", 
<hhttps://www.3gpp.org/technologies/ntn-overview>.

URL broken (s#hhttps#https#)

---

[1] https://doi.org/10.1145/3609423