Minutes IETF101: dtn
minutes-101-dtn-01

IETF DTN Working Group Minutes
March 23rd, 2018
IETF101, London
Chairs: Marc Blanchet & Rick Taylor
================================================================================

Administrativia
--------------------------------------------------------------------------------
- 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.


SUMMARY
--------------------------------------------------------------------------------
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 document
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 uploaded
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 potential
                   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 contact
                   header instead of having to keep doing a three-way handshake.

C: Brian Sipos: Ok. This was held over from prior version.


C: Brian Haberman: There are many places where "should" is used without any
                   indication of when you "shouldn't". If these things are
                   really "shoulds" then you should give an example of when
                   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 TCPCL.
                This appears to be a layering issue.

C: Scott Burleigh: Clean layering is important. TCPCL is not only convergence
                   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 the
                   bundle. Instead, a flag in the segments of the CL protocol,
                   set by the sender and different hop by hop. If set, would
                   require you to reactively fragment. Doesn't need the receiver
                   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 or
                   absence of an ack. An interim ack can happen to signal the
                   fragmentation. If the flag is not set, or receiver is unable
                   to reactively fragment, then no progress ack would come
                   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 transmission?
                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
                  complications.

A: Scott Burleigh: Not a fan of reactive fragmentation. Security concern went
                   away when we agreed payload block is last black in the
                   bundle. We no longer have to wait for whole payload before
                   doing authentication.

Q: Ed Birrane: This seems similar to the discussion of custody transfer in
               BPbis where we extracted it to a separate document because not
               everyone needs it and it doesn't need to be part of the core
               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 suggested
                   before.

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 this
                   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 functionality
                and not allude to reactive fragmentation at all. Let's hum.

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
               headers.

Q: Victoria Pritchard: If so, do we keep the acks or not?

A: Brian Sipos: The simplest thing to do is remove language about fragmentation.
                We could also remove the notion of segmentation - right now
                only a single extension area (contact header). Sounds like
                there is an idea of adding an extension area to each transfer
                init message so some kind of extension policy could be applied.
                This depends on how CL is used - do we use it in a 1 transfer
                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.  Without
                   an extension mechanism things will be more awkward. If not
                   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 received
                   length is always the entire length of the transfer. In the
                   future there may be extension stating conditions where the
                   length value in an ack might be something other than total
                   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 changed
                   there we would need to re-assess reassembly in BPbis, but
                   think we are OK here.

C: Vitoria Pritchard: Intermediate acks allow inspection of a bundle by the
                      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 to
                   the BPA on the receive side can still happen. How it happens
                   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 contact
                header. TCP is already doing receiver acks, etc..

C: Brian Haberman: I agree with Rick. If you have segmentation in TCPCL and
                   TCP is already doing it, you get interesting behavior with
                   overlapping control oops, especially with long latencies.
                   It makes sense to strip segmentation stuff out into some
                   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 segment?

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 header.
                   Reverse traffic is same ack messgaes already in the spec.

C: Scott Burleigh: Suggest when sender gets a refusal, if still sending it
                   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 shutdown.

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 you
                send a shutdown neither peer is allowed to initiate a new
                transfer. Either peer, if they see the initiation of a new
                transfer, would be treated as invalid. Allow an existing transfer
                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 still
                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 explain
                   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 the
                   distinction between clean/unclean shutdown should be added.
                   Shutdown always means ordered (completed current transfer of
                   which there is 1 because we are serialized). Shutdown not
                   finshed until transfer complete in both directions so not
                   authorized to close TCP socket. Stopping TCP in any other
                   way is an anomaly already covered in error correction.

C: Victoria Pritchard: Sender may want to shut down before finshing the transfer.

C: Ed Birrane: Case where 100 bytes into a 2 GB bundle, how do you stop the
               transmission?

C: Scott Burleigh: Since the use cases that drive this are not practical, this
                   would at best happen infrequently. The cost of closing a
                   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 routing
                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, many
                of the additional comments go away. Many shutdown codes are
                really just aborts anyway. Reason codes should just be "stuff
                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, likely
                   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 be
                   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 regularly,
                   say daily. At a given time each day they exchange messages
                   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 draft.
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.