IETF DTN Interim Meeting September 28th, 2016, 10h00-12h00 Eastern Meeting Notes Adam Schlesinger Aloizio Auric Schiltknecht Brian Sipos Charles Sheehe Edward Birrane Eitaro Ueda Felix Walter Fred Templin John Dowdell Jorg Ott Juan Fraire Keith Scott Kevin Fall Marc Blanchet Rick Taylor Ronald in ’t Velt Scott Burleigh Spencer Dawkins Meeting materials here: https://datatracker.ietf.org/meeting/interim-2016-dtn-02/session/dtn # Intro (Mark Blanchet) Milestones # Bundle Protocol Update (Scott Burleigh) [Recording starts here] Changes: - Include encoding in the Bundle Protocol Specification - Split custody transfer into - Rerouting service (includes only custody refusal signals) - Retransmission service (omits custody refusal signals, includes new custody delegation signals) - Extra signal for nodes that forward bundles that request custody retransmission but don’t take custody. - The two services can be requested independently and are NOT mutually exclusive ## Rick Taylor — CBOR encoding. - Have you considered using a data definition language as Carsten suggests? - Scott prefers to not, if the document can be unambiguous. Maybe put something in an appendix? - Have you considered using the CBOR built-in Boolean type instead of a 0/1 integer? - Seem like it’s still a byte, may as well use CBOR built-in type - Translating the flags field into CBOR is a bit complicated. Is there a better way to do that? Rick to look at it. ## Jorg Ott Do we really need the expressiveness that CBOR offers? Jorge wants to run at O(10Gbps) with moderately-sized packets, which might be difficult with CBOR encoding. Would prefer a ‘bad’ (suboptimal) encoding rather than multiple encodings. Stick with just one (wg consensus). More benefit in keeping things simple (don’t let people go nuts with multiple encoding mechanisms) ## Keith Scott Question about the rerouting service. Why is this something that the end users get to / have to request? It seems like it’s something that can improve performance in the network, but doesn’t really change the end-user experience. Kevin seems to have a similar question. Ronald: this seems to only be useful in the context of single-copy routing, does anyone see utility in a multi-copy routing scheme? - If destination is multiple nodes, this is all undefined. Kevin has some uneasiness. What if the custodian doesn’t know the topology? Rick Taylor sees real utility in being able to turn this option on as a diagnostic tool to identify terrible badness in the network. Kevin: Can’t bundle status reports provide the same kinds of information? Mark calls an audible to go on to the next presentation. Discuss this on the list. Scott suggests maybe removing the rerouting service is the best thing to do - It’s only an optimization away - Simplifies the spec (get rid of everything except custody delegation signal and retransmission timer) - Rick Taylor ALMOST entirely agrees, but sees some utility in a custody refusal signal (I got your bundle but I don’t want it) - If there’s a need for source routing you might be able to define a block like Ed Birrane’s source routing stuff, or use Bundle-in-Bundle encapsulation # TCPCLv4 (Brian Sipos) Goals of TCPCL - Keep things the same (ac tcpclv3) as much as possible Comments from draft posted to list: - Front matter and editorial - Interoperation with TCPCLv3 - v4 agent can either revert to v3 or shutdown the connection when it receives a message from a v3 tcpcl - Combined BPv6 and BPv7 operation (open question) - No, CLA doesn’t know anything about what it’s carrying. - Use this (tcpclv4) CLA to support multiple underlying transports? - Rick Taylor: No — different underlying protocols should be different drafts. - Contact Header Comments - Rick Taylor on options: Either fixed-length everything OR CBOR. TLV with optional flags but DIFFERENT from the stuff in BP seems odd. So either No options or go CBOR. - Have everything in the contact header be fixed-length, fixed formatting. If you want anything site-specific, it’s not tcpclv4 - Doesn’t look like there’s any way to maintain backward compatibility w/ tcpclv3 with TLS - Bundle Exchange Messages (Bundle IDs) - - Security Requirements # Actions ## bpbis - Switch CBOR booleans to built-in types not 0/1 integers. - Add an appendix describing the CBOR in a data description language? - Carsten could do this? - General agreement that this would be useful (several in favor, none opposed) - Rick Taylor to look at ‘better’ / different encodings for the flags fields. - Doesn’t seem like there’s a better way. - Benefit of a byte string is that you can expand past 64 bits (not likely!) - Drop the rerouting service - Add a status reporting capability for ‘custody refusal’ ## tcpclv4 - No variable negotiation in contact header; moved to fixed header content. - Move to 64-bit bundle identifiers - Remove CL knowledge of bundle formatting - rename bundleID to something else (to deconflict with bundle id in bpbis) - Move this to a WG item