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.