deepspace BOF
IETF 121 (Dublin)
THURSDAY, November 7, 2024
====================================
Chairs:
Area Director:
o Introduction, Chairs
o Use Cases and Problem Statement
o Lunar IP networking, Wesley Eddy, MTI Systems
Looking initially at lunar communications, RTTs of about 1300ms
(close to older cable modems that inspired buffer bloat
discussions).
All links are in the slides (e.g.
https://ntrs.nasa.gov/api/citations/20200001555/downloads/20200001555.pdf
)
LunaNet Service Providers (LNSPs) Routing could initially be
PCE-like, with time-varying static routes (small network size).
Q: How much overlap is there with existing DTN? - Reply: Not so
much, this is about performance of IP applications.
o Moon Mobile Provider Requirements, Atsushi Tagami
Internet protocols will be used on the moon and between Earth and
the moon.
Network operation and maintenance on the moon.
Interoperability between the moon and the earth.
Several areas of interest relating to routing, transport and
applications.
Q: Do you have any place which details things that are not working?
- Reply: For example, things relating to Path RTT (PRTT), etc that
make assumptions.
o Protocol Architecture of Earth-Moon Integrated Network, Xiongwen He,
CAST
Current architectures use different layerings (layer interfaces may
be at slightly different points in the stack, different numbers of
'formal' layers) and different protocols.
Q: You envision a heterogeneous network? What is the heterogeniety?
- Reply: Different architectures.
Q: Do you foresee IPv4 or IPv6? - Reply: Ground network uses IP and
translation from IPv4 to IPv6; Current TCP protocol may not work
very well, but something like LTP can be used on top of UDP/IP.
Q: Do you have performance testing results? - Reply: we have seen
LTP is better than TCP. We plan more tests.
o Architecture and Work Items, Marc Blanchet, Viagenie
Use case/deployment scenarios. Space links can encapsulate IP in
CCSDS frames. Use of UDP transport, QUIC, etc over the path with
adaptation.
Q: Philip Hallam-Baker: Great talks. On HTTP, cache assumptions were
that the data is not confidential, do we need to think about
ecrypted content?
Q: Josh Cohen: Can you deploy more relay satellites? Why not the
endpoints on the surface. - Reply: a relay on mars is expensive,
could happen sooner for Moon.
Q: Gorry Fairhurst: How much of the QUIC protocol state machine
remains? You specifically said you tuned things, and use
Flow-Control. - Reply: None in the protocol, only transport config
parameters at connection establishment. Flow control may be used or
not, depends on the use case. The moon more likely than Mars.
Q: Joerg Ott: The code that uses HTTP is often the problem. I
thought this was about code re-use. Reply - Typical Internet
applications may not work since assume connectivity. We are talking
about specific space applications.
Q: Keith Scott: How do you manage security protocols and not do
end-to-end communication. - Reply: Either BP or IP stack, one need
to be careful about key lifetimes.
Q: Alexander Pelov: Relating to IoT. We spoke about is this still
IP? I think you can tune timers and things like SSH work. - Reply:
We tried SSH and this didn't work in our testbed. Was expecting SSH3
to work since it is over HTTP, but this work has not been accepted
yet in IETF.
Q: Alexander Pelov: You might need proxies, such as we have in CoAP
- e.g. with OSCORE, I think you can't take things as we have today,
some slight adaptations need to be done potentially in this future
WG. Reply: agree. Last slide talked about proxies at space edges,
which makes sense. Another case that was discussed (by Magnus)
during side meetings was a MASQUE proxy at space edges.
Q: Rick Taylor: We heard that space missions are looking at a dual
stack with BP and IP. You seem to have moved to a proxy and store
and forward architecture? - Reply: Yes, until we have more orbiters
then this is a problem. The storage might be at layer-2 (so
transparent to IP) or layer-3 (modified version of IP forwarders
that allows for storage), or using proxies or application-layer
gateways.
Q: Alan DeKok: If there is hours or days for the path, then the
transport looks more like Fedex than IP. - Reply: TCP is a little
out for mars. QUIC properly configured worked. Since point-to-point
links are used to mars, we can use header compression.
Q: Shuhas Nanfakumer: What sort of applications do you expect? How
do media applications work with the store and forward platform.-
Reply: Applications include: File transfers; Images; Videos;
Real-Time (delayed); and Control information. We have a rich toolset
for queue management in the IP toolstack, and we can do things in
proxies at the space edge. There are no restrictions - we can have a
mix of scenarios and use methods such as Masque.
o Charter Review, Chairs
There are some overlaps and questions. There is a proposed charter.
Q: Stephen Farrel: The scope including mars distance is that I think
this is a bad idea, I would be happier with Moon distance. It is dozens
times more effort to go to Mars. - Reply: There was an original ambition
to include the Mars use case.
Q: Alberto Montilla: There are two questions: How do you connect to the
remote network? How do you deploy on the surface of another celestial
body? Reply: We assumed both.
Q: Alberto Montilla: The charter does not include BP. - Reply: There was
a discussion about what will be done in the DTN working group.
Q: Philip Hallam-Baker: I think protocols will need extended as well as
some profiled (e.g., HTTP). Reply: There are expected extensions also
that might need to be done in specific WGs.
Q: Felix Flentge: The second paragraph seems to assert that space
agencies are trying to build an IP end-to-end network. I think this
needs to be clarified. Reply: We will think about re-phrasing.
Q: Suhas: What does end-to-end mean? Reply: We mean between IP
addresses.
Q: Rick: I think store and forward ouught to be out of scope. There are
security at rest issues here that have been worked upon. Reply: There is
a spectrum here. Solutions where simple mechanisms can be used to manage
queues could be in scope, but more complicated mechanisms would be out
of scope.
Q: Gorry: I think all these paths can be slightly complex, so we need
to do something here. Reply: OK, we can resphape to low-complexity
rather than direct line of sight.
Q: Alexander: The paths need to sit in relays to build the path.
Q: Stephen: It's not clear we want to develop a architecture. Reply:
The intention is to develop a profile.
Q: Rick Taylor (and chat comment from Erik Kline): We don't need bullet
one (already done).
Q: Max Franke (?): Does space include LEO? Reply: No.
Q: David Lamparter: Can we allow moon-only for the moment? Reply: Lunar
is the initial goal.
Q: Britta Hale: We can be more specific about what “work on” means? Is
this design of protocols and related specifications or only aggregation
of preexisting options?
Q: Albero Mantilla: The technical problem is delay and interruptions -
we can say this. Reply: We can make sure it says this.
Q: Jenny Coe: I think we need to support Mars.
Q: Keith Scott: There could be lots of solutions that could work for
the moon that won't work further out. I think extending an end-to-end IP
architcture to Mars is difficult.
Q: Keith Scott (?) : We can focus on the moon and do not preclude use
to Mars.
Q: Josh Deaton : Is security going to be considered?
Q: Britta Hale: The TLS handshake is designed for Internet use. The
handshake doesn't have to be used, we will be looking at different uses
cases. Reply: Are you saying we could use a different handshake or
something else? - Yes, all of these.
Q: Sauli: There is tuning we can do. This slide seems to assert that
QUIC is the ony transport to use. Previous presentation shown the use of
different Transport protocols, only to focus on QUIC is not adecuated.
Reply: This is the discussion we had to scope the use.
Q: Stephen Farrel: Is DNS the only thing needed for QUIC? Reply - there
will be other things.
Q: Keith Scott: How do these things impact the Internet, are these
things going to be used in the Internet? Reply: This might be a
sector-specific/domain-specific applications
Q: Jenny: Can we highlight the difference with BP? I think we need
these to work together. Reply: We can look at the DTN WG outputs that
help to define the inputs here.
Q: Britta Hale: TLS isn't suited for this use-case.
[Note from the chat by Ines Robles: "I think it is good idea to remain
open to the possibility considering various transport protocols. If we
focus only in quic we might exclude relevant protocols from the design
and discussion process.As in the Mailing List was suggested, it could be
added as a Milestone"]
Chairs: Please comment via email on the Charter if you have further
claifications or we are missing something.
o Next Steps, Chairs/AD
The Mars use-case could be kept in mind.
Who is willing to review documents and participate in a WG? (Yes:
36, No: 12)
Is this work that ought to be done in the IETF? (Yes: 68, No: 7, No
Opinion: 2)