Delay/Disruption Tolerant Newtorking (dtn) WG
IETF 118, Prague
2023-10-07, 13:00-15:00 CET, Prague
Area Director: N/A
Chairs: Edward Birrane, Rick Taylor
Secretary: Adam Wiethuechter
YouTube Recording:
https://www.youtube.com/watch?v=a1x1xK4Vqsk&pp=ygULaWV0ZjExOCBkdG4%3D
Agenda:
Speaker: Chairs
Document: N/A
Last minute updates for open discussion. Last two items are part of the
open discussion.
Speaker: Sarah Heiner
Document: https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/
Quick overview as gone through WGLC
OPSAREA and DTN comments
Removal of management model and operational data models
cEB: today is last day of WGLC
Speaker: Scott Burleigh
Document: N/A
BIBE decks is 5 years old, not much has changed
Getting started with BIBE with revised charter
2009 motivations
EB: is it always case that BIBE that there is a single enacpsulated
bundle or multi?
Always assumed at this time it is a single, can talk about aggregating
multiple in
EB: makes sense. is there in BIBE a relationship between extension
blocks?
No mandatory relationship. intent is encap bundle is brand new and
configured however makes sense. Might entail borrowing some config but
not required to. Very important things can do with BIBE would be
disabled if you were required to carry over encaped bundle
configurations.
EB: bundle age, previous, etc. was thinking
RT: do you see encap/decap pair of nodes having the same implementation
or forsee BIBE as specification?
Fully expect encap/decap to be different implementations. BIBE defined
protocol specification as any other CL
To my knowledge no other BIBE implementations at this time
Chat: Felix Walter: We have a prototypical BIBE implementation (albeit
without Custody Transfer) in uD3TN
EK: 62 and 19 are other topology?
Yes, any number of nodes between sources and dest.
sign/encrypt source bundle
transient qos
" critical forwarding
multicast
cRT: lots of work around forming similiar caps at IP layer that we
should consider reading. half-protections in DETNET. strong framework to
cover previous 4-slides.
Standardizing BIBE itself is an activity and std these applications
merits its own RFC
cRT: completely agree
BIBE is a a way to accomplish these things in a DTN manner
cEB: this specification has been adopted by DTNWG, BIBECT? Getting BIBE
is one of the charter items.
Why removed from BPv7?
Concept of CT is not retransmission. Its an exception/adaption of
end-to-end principle.
"hand it forward"
CT for reliability is no NACKs. routing signal mechanism.
EK: count down timer is not only way, depending on CLA might be able to
see other layer failures?
Correct, absent signaling from CLA is a timeout. CT doesn't give you
anything to work with.
BPv6 nodes never required to accept custody
fragmentation causes more issues
multicast is hopeless
BPv7 alternative was not to do this, just rely on reliable CLAs
Exception to all this; when CLA fails either retransmit or send back
(forward) upstream to run an alt route
save copies for retransmit?
CCSDS DTN WG status reports could add mechanism for this signal?
cEB: thanks. this wg choose not to do work as others (ccsds) were in
process. perhaps wrap or profile later
Speaker: Rick Taylor
Document: https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/
Stuck around governance, so changes to move document forward
Cull text advice to DEs about governance policy
left technical considerations (CBOR)
If text about governance needs to exist it should be its own document
rather than hiding it in a tech document
cEB: questions or concerns?
None.
Speaker: Sarah Heiner
Document:
https://datatracker.ietf.org/doc/draft-sipos-dtn-edge-zeroconf/
To address existing protocols for lightweight BP edge nodes
BPA/CLA needs external config to bootstrap into BP network
"plug my box in and have it work on BP network"
draft identifies existing items and changes needed to create behavior
new behavior is router to offer edge node to use TCPCL service
intent is not to solve everyones problem - single edge node with single
application
feedback welcome
RT: very good work and valuable
Speaker: Ed Birrane
Document: N/A
toleant network does not help intolerant apps
latency for intermittency
Deep Space Considerations
focus on next 5-10 years
power constraints dominate
do we have enough material for
add or update RFC4838?
SF: need to reread 4838. not clear what message sending to wg (being so
expensive)?
Barrier to entry is different. Not everyone has billions of dollars.
They want a stable baseline at time of proposal. lock in for something
to exist next 50 years
SF: sometimes an RFC might not be used until 5 years after publication
Lots of private companies interested, but bigger agencies might not
EK: value if outcome is API
I wanna read that
RT: no submission API
Speaker: Rick Taylor
Document: N/A
gentle, tounge and cheek
why use quic/ip in deep space?
TJ:
cEB: 3gpp work done to build dtn in a 4g/lte scenario to help with
understanding
TJ: onboard satellite
cEB: deferred bearer, local apps could send data to proxy. tested on
iss.
TJ: 5g the way to transmit not store
RT: leo comment - think it is an interesting case. big fat bundles
probably not for leo. big buffers and delay.
SF: confused.
Keep going, great stuff! everyone calm down
SF: first bullet not in charter
First yes, second is in scope
SF: tension assumes that we end up with hour glass.
MB: not only quic. whole stack and all pieces.
Zahed: nice AD. we are understanding ourselves. related, not same thing.
inspires the talk. like quic to be more general purpose (as quic ad)
JF: introduce myself a bit better. Ip background, wife/fiends space.
working on container format and trying to find WG
RT: RFC9171 for container format