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:

Introduction, Note Well & Milestones (5 mins)

Speaker: Chairs
Document: N/A

Last minute updates for open discussion. Last two items are part of the
open discussion.

DTNMA WGLC Update (10 mins)

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

• Focus as Arch document
  Terminology tweaked to be consistent
  ACL

cEB: today is last day of WGLC

BIBE/Custody Transfer (30 mins)

Speaker: Scott Burleigh
Document: N/A

BIBE

BIBE decks is 5 years old, not much has changed
Getting started with BIBE with revised charter
2009 motivations

• content centric networking
• multicast retransmission
• security tunneling
  Resurrected 2013 as CL
• distangle routing from security
  Detemined custodial retransmission not effecient
• some unicast scenarios need asym acks
  build custody transfer into BIBE
  aggregate custodial transfer
• used on iss
  2018 - acs added into BIBE

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.

Custody Transfer

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

IPN URI Update (10 mins)

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.

Zero-Configuration Edge Node (10 mins)

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

• good hackathon activity

RT: very good work and valuable

Delay-Tolerant Application Considerations (10 mins)

Speaker: Ed Birrane
Document: N/A

toleant network does not help intolerant apps
latency for intermittency

• delay could mean lost contact
• latency solved with extending timers and saving data
• intermittency can not be solved extending timers
  transport vs comm security
• comm sec is e2e and property of data itself
• independent of transport layers
• data at rest security
  assumptions
• system capable and powered
• long RTTs only affect timers
• local procssing is sufficient
• single secure transports
  when consider BP-inclusive?
• intermittency not latency
• e2e with multiple transports
• resource constrained env

Deep Space Considerations
focus on next 5-10 years
power constraints dominate

do we have enough material for

• how to write delay-tolernat apps?
• how to adapt protocols for DTN env?
• problems that define the area?

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

Open Discussion (50 mins)

Deep Space (20 mins)

BCP for Applications over DTN Links (15 mins)

QUIC CLA (15 mins)

Speaker: Rick Taylor
Document: N/A

gentle, tounge and cheek
why use quic/ip in deep space?

• IP works
• hard/soft ware existsd
• quic capable to handle long-lived sessions and RTTs
• ip management exists and can handle complexity
  but, what is deep space?
  size matters as it introduces physical problems
• delay is measured in AU
• disruption as planets get in the way
• power budgets are the name of the game and the primary concern
  current approach is store and forward
  "information centric store and forward overlay network"
• rude observation - email done right
• information centric: basic unit is an infogram
• store and forward: no e2e a lot of the time, so don't expect it.
  @rest and @transit
• overlay network: BP rides on other transports
  assert(BP != IP)
  JF: new to group but not problem. no relation to CCSDS protocols
  IETF has only standardized as standard track TCPCL
  repprochment
• quic would be an ideal CL (as laid out in draft)
• ip in leo/geo and other planets
• TCP/CL details primitives and can be forwarded to QUIC
  Suggestions
• keep working out how to make long RTTs work
• CL for QUIC
• roll out IP + QUIC + BP
• one mailing list

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)

Open Mic (5 mins)

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