Minutes IETF104: dtn

Meeting Minutes Delay/Disruption Tolerant Networking (dtn) WG
Title Minutes IETF104: dtn
State Active
Other versions plain text
Last updated 2019-04-20

Meeting Minutes

IETF DTN Working Group Minutes
March 26th, 2019
IETF104, Prague
Chairs: Marc Blanchet & Rick Taylor

- Ed Birrane, Felix Walter, Ron in 't Velt will take notes.
- Notewell noted.

Agenda Bashing

- No changes.

YouTube link to proceedings:

1. DTNWG chairs will send request for BpBis publication.
2. Fred Templin will perform shepherd writeup for BpBis.
3. Brian Sipos to pose 16/32bit extension length encoding to mailing list and
   provide update as pursuant to list guidance.
4. Brian Sipos will post final update to TCPCLv4 pursuant to #3.
5. Once posted, chairs will send request for TCPCLv4 publication.
6. Ed Birrane will perform shepherd writeup for TCPCLv4.
7. Ed Birrane will post final update to BPSec.
8. Once posted, chairs will send request for BPSec publication.
9. Scott Burleigh will perform shepherd writeup.
10. DTNWG chairs will request last call for mTCPCL document.
11. DTNWG chairs will request last call for BPSec Interoperability Security 
    Context document.
12. Felix Walter to post to mailing list questions about redundant MTCPCL
    length encoding.
13. Martin Pilka, Stan Ratliff, Ronald in 't Velt to revive IPND draft.
14. Marin Pilka, Stan Ratliff to start discussion on general architecture for 
    neighbor discovery to DTNWG mailing list. 

Questions (Q), Answers (A), and Comments (C):

Presentation 1: Minimal TCP Convergence Layer (Scott Burleigh)
Brief overview of Minimal TCP CL (mTCPCL). Intent is to provide a convergence 
layer adapter simple enough for ready agreement to be provided with BPSec and 
BPBis. Spec is short, about 8 pages. 
Q: B. Sipos: What is policy on CBOR tagging? 
A: S. Burleigh: mTCPCL and BpBis state required elements. Neither preclude tags 
                such as in extension blocks. Both specs intentionally silent on 
Q: R. Taylor: Believe CBOR tags parsed as meta-data only. This might 
              need to be handled explicitly in a dissector or an FPGA 
              implementation, but tags do not alter content and shouldn't be 
              part of canonical spec. 
C: S. Burleigh: Current specs complete without tags, but no objection to them. 
Q; F. Walter: In mTCPCL spec there is a length value in front of CBOR byte 
              string, but CBOR byte string includes a length so this seems 

Q: R. Taylor: Does this have something to do with the problem of very large 
              (1-2GB PDUs?)
A: F. Walter: No. Last issue for BpBis was needing to serialize a block to gets 
              its length first making implementing a streaming serializer hard. 
              This issue is different because in mTCPCL you already have the 
              serialized bundle so length is easy to get from the binary string 
              and an extra length value is redundant.
A: S. Burleigh: Need to look into it but fine to remove if it is redundant.
C: R. Taylor: Classic mailing list question - please take it there.
Q: M. Blanchet: We have 2 TCPCLs. In TCPCLv4 we connect to a port # (4556) 
                which is the IANA designated port. Do we need one for mTCPCL?
A: S. Burleigh: mTCPCL doesn't specify a port. Says connection established by 
                management. Fine with assigning a port but it should be 
                different than TCPCLv4.
Q: R. Taylor: Do we need an IANA request for reserved port?
A: M. Westerlund: IANA would need to provide a port, but we try to keep port 
                  usage down. If there are other methods like local config 
                  and/or dynamic port may want to try that first.
C: S. Burleigh: mTCPCL considers this a local configuration and managed outside 
                of the protocol. Assigned port does not need to be part of the 
                standard. It can be added if necessary.
C: M. Westerlund: Recommend against a reserved port for mTCPCL. 
C: R. Taylor: Can add text to mTCPCL saying it is configured out of band.
C: S. Burleigh: Existing text says it is established out of band.  
Q; J. Ott: To fail safely, should TCPCLv4 and mTCPCL fail gracefully if they 
           use the same port?
A: S. Burleigh: I see no advantage to them sharing a port; if they are not 
                supposed to share a port you don't need to implement a way to 
                distinguish between the two.

C: R. Taylor: First bytes in both are length and payload so you could get intro 
              strange cases.
C. J. Ott: Things on the Internet are often mis-configured. Some minimal wisdom 
           in the spec may make failures graceful.
C: S. Burleigh: Individual implementations can do that, but not something that 
                needs to be added to the spec itself. 
Q: R. Taylor: Is there a unique enough header or preamble on connection to 
              distinguish the two? Do we need to add a preamble to mTCPCL?

A: S. Burleigh: Protocol will fail on misconfiguration. Adding more protocol 
                elements to diagnose the misconfiguration could be done but 
                prefer not to do that.
C: R. in 't Velt: TCPCLv4 needs a port number and consider keeping it 4556.

C: E. Birrane: mTCPCL by definition is the minimal needed to communicate and 
               that should be rubric to apply when considering other features.

Presentation 2: TCPCLv4 (Brian Sipos)
Spec just about done. No changes to background slides. Goal is to not change
workflow or scope. CL in v4 works much as in v3. Same phases, headers, type 
codes. Demonstrated performance metrics and showed wireshark dissector which
handles TLS in messages and re-assembling individual xfer segments. Presented
some open issues from slides for WG discussion:

Q. B. Sipos: Can we reduce 32bit extension item data length to 16bits? If a 
             field needs more they can stitch together 2 fields. 

Q: R. Taylor: What was vision for extensions? 

A: B. Sipos: Original concept was negotiated data (EIDs, small parms). EIDs
             related to URLs are single-digit thousands of octets. 

C. R. Taylor: That sounds like 16bits. Take to the mailing list. 

Q: M. Blanchet: Are all authors in agreement on latest spec?

A: J. Ott: We agree.

Q: M. Blanchet: Apart from small changes described, is it ready for IESG?

A: B. Sipos: Yes.

Q: M. Blanchet: Anyone opposed to sending for publication?


C: M. Blanchet: Ed Birrane will be doc shepherd. Get write-up done.

Q: M. Blanchet: Scott Burleigh, is the mTCPCL document ready for publication?

A: S. Burleigh: Yes. 

Q: M. Blanchet: Anyone opposed to sending mTCPCL for publication?


Presentation 3: BPSec and Interoperability Suites (Ed Birrane)
Recent updater to BPSec and Security Contexts. Did not adopt CCSDS 
recommendation to add security association block. Changes name of cipher
suite ID to security context. Will produce version -10 to capture editorial
comments from CCSDS.

C: R. Taylor: Will ask for WG adoption on the security context draft on the
              mailing list.

Presentation 4: Interfacing Async and Sync NM protocols (Jean Chorin)
Walked through the slides for the architecture and goals. 

C: E Birrane: Good work considering it must interface with existing ION AMP
              manager which is not a clean interface. New interfaces coming.

Q: E. Voidt: Do you handle DB lock on one side while queuing transactions on 
             the other side?

A: J. Chorin: No. NETCONF supposed to have commits on the DB and some small 
              support if comment is made and others waiting, this is not as 
              developed as in a real NETCONF DB, but something to look at.

Q: R. Taylor: Question for E. Voidt (got YANG push through NETCONF) which was 
              NETCONF notification on steroids. Do you have any advice for the 
              guys working on this on whether that push/pull thing? And could 
              that interface be more elegant?

A: E. Voidt: We can talk offline some. 2 types of NETCONF notifications 
             push events and yang-push subscribe to data store elements to get 
             push on change. Less relevant for writes looking more how to push 
             on a subscription. Diff between events when app knows something. 
             When some recipient cares say what they want to receive.

C: E Birrane: In example, command to generate data then followed by commands to
              get the data. With yang push could have NETCONF agent push data
              as it is received. Issue is when you reconnect after a long time
              you could get a lot of queued data.

Q: M. Westerlund: What happens if you cause more data to be produced than can
                  be delivered across the DTN?

A: E. Birrane: AMP currently does not do data throttling and concept is hard in
               a DTN. Passes to BP bundles with quality of service and TTL and
               lets lower layer address it. 

Presentation 5: AMP/CAMP walkthrough (Ed Birrane)
Ed walked through some architecture/goals. Screen shots of the nm_mgr, nm_agent
and camp scripts bundled in ION open source release 3.6.2. 

C: R. Taylor: For those not familiar, some of the parameterizations being 
              shown in AMP is because you really need single roundtrip because
              delays can be very long.

Presentation 6: pyDTN Hackathon Outbrief (Martin Pilka)
Reviewed of hackathon outputs and discussion of pyDTN for spacecraft. Request to 
resurrect IP Neighbor Discovery as it was needed to implement the pyDTN 
implementation. The draft is expired but information in it might still be valid.

Specific requests from hackathon: 
    - Get IPND draft up to date unless there is another means for discovery.
    - IPND should be updated to use CBOR.
    - Could we do non-IP discovery? Future CLAs. 

C: Rick Taylor: Neighbor Discovery is an active charter item. A DTN-ND using
                CLAs and maybe event-driven could be way to go. Others have
                proposed alternate designs. WOuld appreciate you working on it.

C: M. Pilka: We would volunteer to do that.

C: R. Taylor: Start a discussion on mailing list with ideas.

C: M. Pilka: We agree to update the draft. And to move to CBOR and cover more
             than just IP?

C: M. Blanchet: DTN may not be transported over IP anyway. 

C: M. Pilka: YTrue, but we need IP to help test with other implementations. 

C: Ron in 't Velt: The only CL we have is IP-based so we should do IPND first.
                   I presented something in Buenos Aires that was not adopted,
                   but can bring it back and work with you on it to have 
                   before Montreal. If we instead do a new architecture and
                   start over, then not interested in that.

C: R. Taylor: Do both. Refresh IPND as it is. In parallel investigate on the
              mailing list a generalized structure and approach for other CLs.

C: S. Ratliff: I will sign up for generalized structure work on the mailing
               list, but no non-IP based solution should come out of IETF.

C: R. Taylor: Other SDOs like CCSDS will want CLs for non-IP and will look to us
              for guidance.

C: S. Ratliff: An architecture to slide in different transports underneath it is
               good. Some other SDO can do the non-IP ones. 

C: S. Burleigh: Agree with Stan. An architecture can draw a clear interface
                between neighbor discovery and establishing a connection. Build
                an IP-based substrate for neighbor discovery. There is no
                advantage for a proliferation of vastly different ND protocols
                for different environments. Better to have a standard data
                exchange of ND info and, separate, connected through a
                well-defined interface. The CL connection management software
                can start with IP and maybe later do others (such as bluetooth
                and wifi) w/o IP. But mistake to say never anything other than 

C: M. Blanchet: Good to see people interested in next topics. Neighbor 
                discovery and addressing architecture are work to be done. We
                also have LTP as an RFC so not just IP.

C: M. Pilka: Lot of feedback from hackathon people asking if we can use this for 
             IoT. We cannot see sensors all the time. Seems to be of interest 
             from that part of the world for using this. ND is needed not just 
             in IP world, could be bluetooth or something else. 


C: M. Blanchet: Next steps: BPBis chair will send request for publication and
                Fred Templin will do shepherd writeup. Brian will post last
                version of TCPCLv4 and Ed Birrane will do shepherd writeup.
                Ed Birrane will post last version of BPSec. Scott Burleigh to
                do shepherd writeup. mTCPCL will go to WG last call and if
                approved need a shepherd. BPSec Security Context document will
                go to WG last call. If it passes it will need a shepherd.

C: S. Burleigh: I agree to shepherd BPSec Interoperability Security Contexts

C: M. Blanchet: Once all of this is time we will revisit milestones. Neighbor 
                discovery and management are good starting discussions. 

C: R. Taylor: Agreed. Get these out the door first.

C: J. Chorin: Have laptop if anyone wants to see please visit. 

C: R. Taylor: Big thank you to those who came and showed running code. It is
              really good to see these things happening in the working group.