TIPTOP Agenda for IETF 122
Chairs: Padma Pillay-Esnault (padma.ietf AT gmail.com), Zaheduzzaman
Sarker (zahed.sarker.ietf AT gmail.com)
Technical Advisor: Marc Blanchet (marc.blanchet AT viagenie.ca)
INT AD: Eric Vyncke (evyncke AT cisco.com)
Session: 1/1 (90 minutes)
Date & Time: Thursday, March 20, 15:00 - 16:30 ICT (UTC+7)
Location: Sala Thai Ballroom
Agenda
Introduction (15 minutes)
Presentations (60 minutes)
IP in Deep Space: Key Characteristics, Use Cases, and Requirements - (Wesley Eddy, 15 minutes)
Questions:
-
Britta Hale: Security is a consideration that needs to have more
contributions.
- Wesley: security is currently preliminary in the draft. Asks for
people to read and provide text
-
Ines Roble: (from chat relayed by Zahed) What would be also
important to characterize is packet loss (or bit error) rates for
the use-cases
- Wesley: long distances and radio power may mean high bit-error
rate, but strong FEC is used at the link layer and there is
high-margin, which it prevents packet loss. Agrees this would be
good to include in draft
-
Zaheduzzaman: Are we making a difference between when humans are
communicating vs machines communicating?
- Wesley: We have to accomodate both cases. Draft discusses that.
For a human mission you want continuous communication while a
robot mission could have periods without communication.
-
Padma: Classification of trafic is not listed, should it be?
-
Jorge Amodio: How the uses cases match the LNIS requirements?
- Wesley: no real effort to align them, but should not be
misaligned. Shouldfollow up
-
Rick Taylor: For classification (from Padma question), can't we use
standard IP classification?
- Wesley: yes that's what I assumed she meant.
An Architecture for IP in Deep Space - (Tony Li, 15 minutes)
Questions:
-
Martin Duke: Does the architecture support real-time communication
within a celestial body network?
- Tony: You could within a limited distance, such as Moon surface
to surface.
-
Martin Duke: Scope of the document?
- Tony: handling delay, that is where the interest is.
-
Erik Kline: Addressing - wouldn't the RIR system just work?
- Tony: I'd like to defer this question to my talk later in this
session.
-
Rick Taylor: Non-goals: ssh and tcp are interactive, so out. Network
management protocols like Netconf/Restconf are interactive - what
about that?
- Tony: Some network management don't need to be interactive. You
can have a controller bundles up the config and ship it in
whatever form.
- Rick: might need to profile the RPC to ship it
- Tony: absolutely, but this is not rocket science.
-
Brian Trammell: Operational considerations in scope for backup
configuration for routers?
- Tony: Well backup config is a solved problem
- Brian: maybe a line or two in the draft
- Tony: certainly doable
- Padma/Tony: routers rollback to previous config in various
scenarios, so solved issue.
-
Scott Burleigh: How limited is the scope of a limited domain?
- Tony: Up to the agencies and what they agree on. In the IETF
parlance, limited domain boundaries are defined by the
providers.
-
Brian Sipos: Do you have considerations for multihoming,
multipathing?
- Tony: Multihoming is a topic discussed in IETF for 30 years, and
got it wrong. Until we revisit that discussion, we are stuck.
-
Rick Taylor: With my DTN Chair hat on, there are a number of drafts
in DTN about backup configuration and what to do. We could consider
sharing that work.
- (someone from Huawei): What about practice in routing protocols for
LEO?
- Tony: I would remind you of the charter slide that LEOs are out
of scope. About LEO, please see RFC9717.
QUIC Simulation Results and Profile - (Marc Blanchet, 15 minutes)
Questions:
-
Mirja Kühlewind: Clarification question - what is the problem with
flow control?
- Marc: No problem with flow control. Moon use case is different
than Mars. We need to be careful how we use it.
- Mirja: It's still needed.
- Marc: agreed.
-
Lars Eggert: This is a good starting point, but I think there is
significantly more nuance for all the points on your list.
- Marc: I agree there is more work to do.
- Lars: There is more work here than individuals have cycles to
do. We need to see simulation results and discuss. Probably
needs research groups or other groups with engineering budget.
Difficult to spend time even with personal interest, because web
browser QUIC engineers can not spend cycles on this topic.
-
Pavel Farhan: Since QUIC includes TLS, how would you deal with key
management? Are there strategies for secure key exchange in long
delay without excessive handshake?
- Marc: TLS doesn't have much mention in current version of draft.
Key handshake of QUIC TLS is based on number of packets before
doing key exchange, therefore not depending on delay or time.
This way of key exchange is actually well suited for space.
-
Éric Vynke: Similar to Lars, I don't think this group should spend
time on simulations but getting the results of simulations is
useful. Need other groups.
Key Exchange Customization for TIPTOP - (Britta Hale, 15 minutes)
-
Subtitle: Implementing MLS inside QUIC
-
Draft: None
- Slides
-
Presented by Ben Dowling (remote)
-
Key question: Is the WG interested in this approach?
Questions:
-
Zahed: Are you aware of the similar work on this in TLS wg? TLS
Extended Key Update draft
- Ben: no
- Zahed: please look at it
-
Lars Eggert: Do you see this as the biggest issue for using QUIC in
space (the handshake)?
- Ben: using quic with long lived keys means you can't recover
from key compromise.
- Lars: Is this the thing we need to prioritize now?
- Ben: If we don't do this now, it will be an issue.
- Britta: It is a priority now.
-
Mirja Kühlewind: This is a significant change to the QUIC protocol -
needs to happen in QUIC WG.
- Ben: Yes, it would need to happen there. I want to get sense of
WG before taking it there.
- Zahed: Yes. Please take it there.
- Britta/Zahed: (discussion about process of bringing it to QUIC)
Wrap-up (15 minutes)
- Returning to Chair's slides starting on slide 12
- Proposed Contribution Model - work will be via GitHub with merger of
PRs will be done by authors under chairs supervision
- Poll about model - 24 yes, 5 no, 19 no opinion
- Zahed asked if the no's wanted to clarify
- Tony Li: Shared GitHub repo is not necessary. Authors should
be free to develop their drafts wherever.
- Zahed: asking for working group documents
- Tony Li: even for working group documents. unnecessary and
too restrictive. perfectly acceptable to do in a private
repo.
- Marc Blanchet: agree with Tony: IETF process does not rely
on github, we should not change the process. I'm fine witu
using repos with issues. All the drafts presented are
actually managed with github repos. I have issues on another
wg draft with co-authors from some country that cannot
access github, it makes work very difficult. Moreover,
chairs supervision is not appropriate and too much. We want
easy flow. I'm not against but don't think we need this.
- Zahed: I agree that chairs supervision was too restrictive.
But that is not the intention. This just to have some extra
eyes in the beginning till we establish a github ways of
working.
- Randy Bush: You forgot to specify what font must be used!
- Zahed : :-) that would be a RSWG topic (laugh)
If ahead on schedule
IP Address Space for Outer Space - (Tony Li, 10 minutes)
draft-li-tiptop-address-space
CoAP in Space- (Carles Gomez, 10 minutes)
draft-gomez-core-coap-space-02