Minutes interim-2016-dtn-02: Wed 10:00
minutes-interim-2016-dtn-02-201609281000-00

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