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)   {#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)   {#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)   {#bibecustody-transfer-30-mins}

Speaker: Scott Burleigh  
Document: N/A

## BIBE   {#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   {#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)   {#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)   {#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)   {#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)   {#open-discussion-50-mins}

## Deep Space (20 mins)   {#deep-space-20-mins}

## BCP for Applications over DTN Links (15 mins)   {#bcp-for-applications-over-dtn-links-15-mins}

## QUIC CLA (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)   {#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