* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dtn Status Pages

Delay/Disruption Tolerant Networking (Active WG)
Tsv Area: Mirja K├╝hlewind, Spencer Dawkins | 2014-Nov-07 —  

IETF-101 dtn minutes

Session 2018-03-23 0930-1130: Palace C - Audio stream - dtn chatroom


minutes-101-dtn-01 minutes

          IETF DTN Working Group Minutes
          March 23rd, 2018
          IETF101, London
          Chairs: Marc Blanchet & Rick Taylor
          - Ed Birrane will take notes.
          - Brian Haberman will by the Jabber scribe.
          - Notewell noted.
          Agenda Bashing
          - No changes.
          - Confirmed that review of the TCPCLv4 was a WG priority.
          1. Ask WG to remove reactive fragmentation and segments from TCPCLv4.
          2. Brian Sipos to clarify reason codes, add state diagram for TCPCLv4.
          3. Victoria to draft shutdown text for TCPCLv4
          4. Have interim meeting (May?) to discuss progress on TCPCLv4.
          Items from last mtg that were brought up in this mtg:
          5. Ask WG to adopt BPSec Interoperability Cipher Suites draft as a WG
          6. Ask Security directorate to review BPSec
          7. Ask WG to place BPSec in WG last call
          Questions (Q), Answers (A), and Comments (C):
          Presentation 1: TCPCLv4 (Brian Sipos)
          Reviewed updated to TCPCLv4, which includes a v-07 draft that was
          after the internet-draft cut off. Updated were document cleanup, discuss
          variations of fragmentation, incorporate comments from previous
          drafts. There
          exists a working implementation of TCPCLv4.
          Q: Brian Haberman: When you shutdown for version mismatch do you lose
                             connectivity if you know how to speak an older
                             version? Should
                             contact header have info on supported versions so
                             you can
                             negotiate which one to use?
          A: Brian Sipos: We start at highest version and work down. It is not
          clear that
                          you want o expose, up front, which version you support.
          C: Brian Haberman: You could keep the TCP session open and re-send the
                             header instead of having to keep doing a three-way
          C: Brian Sipos: Ok. This was held over from prior version.
          C: Brian Haberman: There are many places where "should" is used without
                             indication of when you "shouldn't". If these things
                             really "shoulds" then you should give an example of
                             it would be true and cases where it would not be true.
                             Absent that you will get lots of comments from IESG.
          C: Brian Haberman: It would be very useful to add a state diagram to the
                             document and what decisions would have to be made to
                             change states.
          Presentation 2: TCPCLv4 Comments (Victoria Pritchard)
          Comments, including the most recent changes (v07) with focus on reactive
          fragmentation and partial transfers and areas where draft is not clear.
          C: Rick Taylor: We have a fundamental question of what is in scope for
                          This appears to be a layering issue.
          C: Scott Burleigh: Clean layering is important. TCPCL is not only
                             layer. Others will also do reactive fragmentation
                             and clean
                             layering makes a common framework possible.
          C: Scott Burleigh: There may be a simpler way to do this - not a flag
          in the
                             bundle as that would mean the CL would have to parse
                             bundle. Instead, a flag in the segments of the CL
                             set by the sender and different hop by hop. If set,
                             require you to reactively fragment. Doesn't need the
                             to comply, just notes the sender's intent. If receiver
                             determines incomplete reception (and able to) it does
                             reactive fragmentation. Signals to sender by presence
                             absence of an ack. An interim ack can happen to signal
                             fragmentation. If the flag is not set, or receiver
                             is unable
                             to reactively fragment, then no progress ack would
                             back (just an ack at the end, or none). This would
                             make the
                             negotiation pretty simple.
          Q: Rick Taylor: With chair hat off. Can we change the flag during
                          Can a sender start setting the bit when it thinks it
                          has sent
                          enough data?
          A: Scott Burleigh: Exactly. It is hop by hop.
          Q: Ron in t Velt: Why is reactive fragmentation coming back? At start
          of the
                            working group we established that here were security
          A: Scott Burleigh: Not a fan of reactive fragmentation. Security concern
                             away when we agreed payload block is last black in the
                             bundle. We no longer have to wait for whole payload
                             doing authentication.
          Q: Ed Birrane: This seems similar to the discussion of custody transfer
                         BPbis where we extracted it to a separate document because
                         everyone needs it and it doesn't need to be part of the
                         spec. Should we similarly treat reactive fragmentation
                         as an
                         extension to a TCPCL?
          A: Scott Burleigh: Proactive fragmentation at least as good a way to deal
                             with this problem as reactive fragmentation. But,
                             it would
                             be OK to implement if it was as simple as what I had
          C: Brian Haberman: I worry about applications repeating responsibilities
          of the
                             underlying protocol. TCP will do max segment and IP
                             will be
                             doing fragmentation. You will see strange orderings
                             of packets.
          C: Brian Haberman: The reactive fragmentation in the current spec may
          not cover
                             all cases correctly. May not be enough information
                             in each
                             segment to make reassembly efficient. You may want
                             take this
                             out and built another CL like rsync over TCP to do
                             correctly and recovery quickly.
          C: Rick Taylor: That would be a new CL.
          Q: Rick Taylor: This is complex and needs more thought and will take
          time to
                          get right. We could strip TCPCL back to basic
                          and not allude to reactive fragmentation at all. Let's
          In favor of continuing to work on reactive fragmentation in TCPCL:
          NO HUMS
          In favor of stripping it out
          SEVERAL HUMS
          C: Rick Taylor: The hums are in favor of removing reactive fragmentation.
          C: Ed Birrane: Similar to BPSec we added extensibility on how to add new
                         types of security blocks. We could add an extensibility
                         mechanism to TCPCL - perhaps with some reserved bits in
          Q: Victoria Pritchard: If so, do we keep the acks or not?
          A: Brian Sipos: The simplest thing to do is remove language about
                          We could also remove the notion of segmentation - right
                          only a single extension area (contact header). Sounds
                          there is an idea of adding an extension area to each
                          init message so some kind of extension policy could be
                          This depends on how CL is used - do we use it in a 1
                          1 session way (lots of overhead but lots of control)
                          or keep
                          a single session and negotiate multiple transfers.
          C: Scott Burleigh: Adding extension area to individual transfer header
          has merit.
                             We aren't only ones who will think of enhancements.
                             an extension mechanism things will be more awkward. If
                             used - ok - make the overhead small. I am in favor.
          C: Scott Burleigh: The only point of interim acks is to support reactive
                             fragmentation. Propose we remove those. Say the
                             length is always the entire length of the transfer. In
                             future there may be extension stating conditions
                             where the
                             length value in an ack might be something other than
                             length of the transfer.
          Q: Marc Blanchet: Will this have an impact on BPbis?
          A: Scott Burleigh: No. Re-assembly happens in BPbis so if something
                             there we would need to re-assess reassembly in BPbis,
                             think we are OK here.
          C: Vitoria Pritchard: Intermediate acks allow inspection of a bundle by
                                BPA to see if we are interested in the transfer
                                or not.
          C: Scott Burleigh: We are removing the ack back to the sender. Signalling
                             the BPA on the receive side can still happen. How it
                             is purely implementation, but don't need that
                             information on
                             the sending side.
          C: Rick Taylor: I don't see the point in segments anymore. Agree with
          the idea
                          of an extension point in the transfer header and the
                          header. TCP is already doing receiver acks, etc..
          C: Brian Haberman: I agree with Rick. If you have segmentation in TCPCL
                             TCP is already doing it, you get interesting behavior
                             overlapping control oops, especially with long
                             It makes sense to strip segmentation stuff out into
                             type of extension.
          C: Scott Burleigh: I agree.
          Q: Brian Sipos: Would the current protocol messaging structure be the
          same, just
                          removing the logic about multiple segments for
                          transfer? A
                          single transfer would be 1 transfer init and 1 transfer
          A: Scott Burleigh: Yes.  A stream between TCPCLs would be a stream of
                             transmissions punctutated by transmisson headers. At
                             end of
                             the header, send data. At end of data, new transmit
                             Reverse traffic is same ack messgaes already in the
          C: Scott Burleigh: Suggest when sender gets a refusal, if still sending
                             should stop. If it has already finished, too bad.
          C: Rick Taylor: That needs to be clarified in the document.
          C: Brian Sipos: The mexhanics still exist. I will add explanations.
          Q: Victoria Pritchard: There are several comments related to shutdown.
          C: Rick Taylor: A state transition diagram would help with cases around
          Q: Brian Haberman: What relation exists between TCPCL shutdown and the
          TCP close
                             that happens with the underlying connection?
          A: Brian Sipos: Intent. The CL is bidirectional - once established there
          is no
                          orientation between peers. Spec language should be when
                          send a shutdown neither peer is allowed to initiate a new
                          transfer. Either peer, if they see the initiation of a
                          transfer, would be treated as invalid. Allow an existing
                          to complete on the request for a shutdown.
          C: Brian Haberman: When separating TCPCL shutdown from TCP shutdown, some
                             applications call this a "close".
          C: Brian Sipos: Until the ack, transfer hasn't completed. The receiver
                          has to send out TCP socket data to ack the transfer.
          C: Brian Haberman: Clarify that in the spec. When I read description of
                             shutdown I see a TCP close happening. You need to
                             that the TCP connection needs to stay up.
          Q: Rick Taylor: Should Vicky suggest a block of text here?
          A: Brian Sipos: Yes.
          C: Scott Burleigh: If not already clear in the spec, language to remove
                             distinction between clean/unclean shutdown should be
                             Shutdown always means ordered (completed current
                             transfer of
                             which there is 1 because we are serialized). Shutdown
                             finshed until transfer complete in both directions
                             so not
                             authorized to close TCP socket. Stopping TCP in any
                             way is an anomaly already covered in error correction.
          C: Victoria Pritchard: Sender may want to shut down before finshing the
          C: Ed Birrane: Case where 100 bytes into a 2 GB bundle, how do you stop
          C: Scott Burleigh: Since the use cases that drive this are not practical,
                             would at best happen infrequently. The cost of closing
                             socket is reasonable to achieve the
                             simplification. Adding
                             some kind of stop semantics is probably too much work.
          C: Rick Taylor: Sending the value of 0 in shutdown to mean "never
          reconnect" is
                          dangerously abuseable. Someone might say I could do
                          with this.
          C: Scott Burleigh: Fine with removing special value 0.
          C: Brian Sipos: We should remove 0 as a valid value in reconnection
          delay and
                          any text related to that value.
          C: Brian Sipos: The reason exhaustion reason code never specifes what
          resource is
                          being exhausted. Can likely be removed.
          C: Rick Taylor: With removal of segmentation and no shutdown in transfer,
                          of the additional comments go away. Many shutdown codes
                          really just aborts anyway. Reason codes should just be
                          the other end could make use of".
          Presentation 3: DTKA (Scott Burleigh)
          Reviewed updated to DTKA.
          Q: Rick Taylor: Are you asking for WG adoption?
          A: Scott Burleigh: Premature at this time. Will eventually ask for it,
                             in Montreal.
          Q: Marc Blanchet: Who generates the bulletin?
          A: Scott Burleigh: Generated by aggregate key authority - cooperation
          amongst all
                             agents. Members must be on a non-DTN network and must
                             timely. Part of that is coordination of bulletin #s.
          Q: Marc Blanchet: So, I need a new # and others agree?
          A: Scott Burleigh: Key authorities in aggregate generate bulletins
                             say daily. At a given time each day they exchange
                             contributing to development of a bulletin.
          C: Marc Blanchet: This seems fragile.
          C: Scott Burleigh: I think it is OK.
          Presentation 4: BPSec (Ed Birrane)
          Reviewed interoperability cipher suites
          Presentation 5: AMA/ADM (Ed Birrane)
          Reviewed updates for ADM data modeling in JSON and YANG.
          Presentation 6: BPbis Implementation (Felix)
          At hackathon: check if BPbis implementation in uPCB meets latest BPbis
          So, wrote alternative BPbis in python as proof of concept. As result of
          hackathon, communicated with uPCN, built RESTful API to push contact
          plan and
          bundles. Built a test setup in docker containers.
          Also updated uPCN to latest draft (v10 from v6).
          Switched CL to TCPCLv3.
          No issues een with BPbis specification.

Generated from PyHt script /wg/dtn/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -