Delay/Disruption Tolerant Networking (dtn) WG
IETF 121, Dublin
2024-11-06, 09:30-11:30 UTC
Area Director: Erik Kline
Chairs: Edward Birrane, Rick Taylor
Secretary: Adam Wiethuechter
Speaker: Chairs
Document: N/A
Standard admin, note well, note really well, tools
agenda bash
Brian Sipos: CCSDS, BPv7 bluebook update if possible.
cEB: anyone wishing to volunteer? Brian, if you wish to tack to end of
your proposed work that can work.
cRT: lots of document in RFC editor queue
cose context is ready, need a shepard. we welcome volunteer or will
volunteer someone
new documents now adopted: amp, dtn-eid, udpcl, bp-sand
Speaker: Ed Birrane
Document: N/A
Looking at RFC4838
Question for today, how much of this document from 2007 do we agree with
in 2024?
Refresh could re-affirm elements or revist and update
Some IP does not work well in some envirorments, not that they can't but
that by making them do so could be ineffecient
Nature of applications running over DTN may still hold
Does WG agree that an arch. out of IETF WG (instead of IRTF) is
something that would be worth pursing?
Alberto Montilla:
Supportive, but what would be the main benefit at this stage?
RFC4838 is product of IRTF thus no standing in IETF. Those trying to
understand DTN find this document first and then things do not match in
BPv7. So something that tracks things that have been made since 2007.
Rick Taylor: consider RFC4838 an orange book and convert to a blue book?
Ronald in't Velt: keep saying has no standing in IETF? but first charter
said no violation of 4838 or similiar work?
EB: when say no standing, I mean the banner online.
cRT: it was and stuck by it and can draw a dependecy tree back. over the
years thing have moved on and a refresh to ietf info.
EB: this is a proposal.
cRT: does doing such a document refresh make sense?
adEK: its an interesting time. could be useful to verify behavior
requirements and differniate from what a deepspace ip wg would do. Lou
asked about track, it would be informational.
cRT: misspoke when said standard track.
EB: in contact with all original authors they are willing to
participate.
Speaker: Jenny Cao, Justin Ethier, Brian Sipos
Documents: https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/,
https://datatracker.ietf.org/doc/draft-ietf-dtn-amm/,
https://datatracker.ietf.org/doc/draft-ietf-dtn-ari/,
https://datatracker.ietf.org/doc/draft-ietf-dtn-adm-yang/,
https://datatracker.ietf.org/doc/draft-birrane-dtn-amp/
DTNMA is now RFC9675, leaving Editor queue
AMM/ADM/ARI adopted
New open source library on github. Using ACE and CACE. Reference CA/DM
in C99
cEB: there is a need for this work, part to take spacecraft autonomy
models into network management models. CCSDS to adapt these documents
into orange book. we encourage mailing list discussion around any
comments.
cRT: there is official liason for this interworking
Lou Berger: dtn-yang-syntax instead of model or base-model?
cEB: intent is to make model, not forking yang
Lou: speaking as netmod chair, the language is making it sound as a
fork, know not its the goal just need to make sure we arent
Jenny: how to use yang syntax for our models.
Lou: its more than just the title. model is overall use of yang, modules
is formal scheme being defined for something. can swap from model to
module.
Brian Sipos: in SMI there is a strong distiction between syntax and
model, in yang there is not.
Lou: thought was on same page until you spoke.
cEB: review?
Lou: yang doctor early review?
cRT: can you scan and mark the areas of contention and send an email.
Speaker: Brian Sipos
Documents:
https://datatracker.ietf.org/doc/draft-sipos-dtn-eid-pattern/,
https://datatracker.ietf.org/doc/draft-sipos-dtn-bp-sand/,
https://datatracker.ietf.org/doc/draft-sipos-dtn-edge-zeroconf/,
https://datatracker.ietf.org/doc/draft-sipos-dtn-udpcl/,
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-cose/
Topics are organized by maturity level.
No changes since last IETF, been through IANA early review
Draft implemented and shown interop
Early allocation of BPSec Context ID requested
cRT: we approve of this, just dropped ball on this.
cRT: we will reach out to COSE chairs for a quick review
eid-patterns: dtn scheme has been removed, any match(?)
udpcl: extensions in main draft and others deferred?
RT: fully approve the udpcl adoption. open questions of extensability?
personal opinion udp is weakest form of CL. question the extensions.
Can use multicast which is unique. fills in gaps
RT: perfectly sensible to include all those things with udp and
multicast capability. interested to see where it goes.
Puts the port number registration into document and formal service name,
etc.
Scott Johnson: curious, describe what dependecy between UDPCL and SAND?
sand:
more open ended document at the moment, transport agnostic
sand broken down into top level things that can be advertised; eid
patterns used for data types
modes of messaging; non-specific destination (i.e. multicast logic)
discovery peer via other means, then perform direct advertisement
zeroconf:
was no adopted
full procedural
co-authors and prototypes welcome
RT: yes to both
Can be tacked on to existing
RT: can start one of the multiple dns converstations we need to have.
feeds into how applications talk bundles in elegant way in a
terresterial envirornment.
good topic for hackathon, prior that router implementation(?)
cRT: sometime next year we can do some hackathon items
any interactions and feedback welcome. working on dp security
association management draft (not yet published)
RT: eid-patterns have been implemented and a great useful thing. dlep
was mentioned before, dlep extension for bundle stuff?
udpcl: positive visible path characterization
RT: comment on that, wary of require of using specific cl for
information. cross layer violation?
sand least developed but concepts seem good and use manet nhdp as a good
starting mechanism/guidance.
cEB: would love to see discussion of sand on mailing list. provide bpv7
bluebook status?
Specific to draft blue book not public. allocation of new ltp client
service id for bpv7. it exists in sana allocation range, so not exposed
elsewhere. ccsds profiling is a strict narrowing and straightforward.
Speaker: Joshua Deaton
Documents: N/A
Within CCSDS currently working on experimental Interplanetary
Multi-Destinary Communication (IMC)
Multiple destinations without duplicates
Borrows IP multiple concepts but is distinct
Derivation of Scott Burleigh CBHE
Restricting URI schemes and basic routing
Based on original IPN scheme, discussion on moving to new IPN authority;
initial book will stay with original ipn concept at this time
Operating at bundle layer not IP layer
Not standardizing duplicate suppression, implementation specific on how
cRT: admin questions; would you be requesting an eid scheme point for
imc or number from iana?
Suggestion in orange book is on private range.
cRT: complex, text might be hard to avoid collision...
Brian Sipos: registreation of code points are specification required and
orange book after publication is enough to do the allocation for IANA.
adEK: two registrations, one for bundle protocal scheme and uri scheme.
cEB: question about duplicate supression, do you inspect your local
storage and reject or do you look at other attributes?
Down to implementation but notes in orange book to create a map source
eid, creation timestamp and other. hold onto routing info bundles that
have passed, not full bundle.
Brian Sipos: group numbering; this space is private use currently. would
need carve out space for private, useful numbers, source specific imc.
there needs to be control authorities for ranges. is there a technical
convient way to do such allocation without affecting late adopters.
RT: post experimental status, wondering if imc is roled under ipn space
and a multicast address?
Brian: imc use consideration; eid and what do you do with this
destination and seperation falls into late binding principle.
Those are curious, you could use this on top of IP multicast in UDPCLv2.
does not prohibt underlying cl's
Alberto: preallocation of service ids or node ids?
RT: not service numbers. half baked idea and relevant after "get it
working" phase. eid can be singleton or group and was wondering if there
was need for scheme or do similiar to ip land. interesting discussion
and open question.
Scott Burleigh: feedback
Speaker: Rick Taylor
Document: N/A
Reliability end to end in DTN exploration
A lot of material is "custody transfer exists and is brillaint"
Not sure if we have looked to see what it means for reliability
Proposing: CT has good elements but maybe need a new name?
CT was dropped from BPv6 to BPv7, due to some implementation experiences
CCSDS has been exploring CT and improving the signaling
CT helps to avoid retransmission, but it is not enough to prevent bundle
loss
Long productive emails with Scott Burleigh on these topic
Reliability is certainty of a bundle getting to the other end (maximize
this value) from perspective of originator
CT is a useful part of the whole picture for reliability
The current work on CT on making it better is important and should
continue, looking beyond for e2e relability
Felix Flentge: no audio
Alberto Montilla: thanks for this presentation. based on testing.
largest issue with CT mechanisms is not signaling overhead, algorithms
that control it and overflow of network and retransmission of data
bundles. Link failures and discrepancies to them. way less concerned of
topics highlighted big case is potentional overflow of network of the
data retransmission. what do you consider custody or when?
I agree with everything said. The failure link problem is huge.
Ronald in't Velt: mention do not want to go to multicast, that is even
more difficult. multi-copy strategies. this group has been avoiding
routing, i.e. forwarding. do support getting rid of it.
Support thinking larger and thinking that CT does not solve all our
problems.
RV: fair enough.
Felix: no audio
Scott Johnson: since talking reliability, what is scope? ensuring that
data fragments getting to end destination, in order?
How long do I wait as an HTTP gateway to a response for my request? That
is what I mean by reliability.
Felix(chat): Yes, custody transfer != reliability but still needed for
efficiency (hop-by-hop re-transmission); so should not be 'historical'
but should be well-defined in the architecture document.
Scott Johnson: out of order delivery, so an ack.
Not necessarily an ACK, just needs a mechanism to say "it got there or
not"
Erik Kline: is this ack mechanism application end to end or agent?
See it as a BP capability that a BPA provides.
Felix(chat): For 'E2E reliability' we can use (compressed) reporting of
deletions of delivery. This can be based on common mechanisms like a
revised custody. Typically, we would combine custody with E2E
reliability.
Speaker: Jens Finkhaeuser
Documents: N/A
Lots of similiar things for different reasons, exciting.
Goal is not video streaming but anything low latency, high bandwidth
This is research, willing to break things
Overlap is upper layers
Unicast is just group communication with exactly two parties
BP could be a convergance layer?