Subject: [dtn] Raw nootes from interim meeting

From: "Scott, Keith L." <[email-masked]>
Date: Wed, 28 Sep 2016 16:08:16 +0000

IETF DTN Interim Meeting
Adam Schlesinger
Keith Scott
Aloizio
Auric Schiltknecht
Brian Sipos
Charles Sheehe
Eitaro Ueda
Felix Walter
Fred Templin
John Dowdell
Jorg Ott
Kevin Fall
Rick Taylor
Ronald in ’t Velt
Scott Burleigh
Spencer

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

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 28 Sep 2016 13:29:55 -0400

Thanks Scott. I posted them to the proceedings website. 
(https://datatracker.ietf.org/meeting/interim-2016-dtn-02/session/dtn)

Group: if you find any issues/changes/comments about the minutes, please 
send corrections to the co-chairs  [email-masked].

Regards, Marc.

On 28 Sep 2016, at 12:08, Scott, Keith L. wrote:

> IETF DTN Interim Meeting
> Adam Schlesinger
> Keith Scott
> Aloizio
> Auric Schiltknecht
> Brian Sipos
> Charles Sheehe
> Eitaro Ueda
> Felix Walter
> Fred Templin
> John Dowdell
> Jorg Ott
> Kevin Fall
> Rick Taylor
> Ronald in ’t Velt
> Scott Burleigh
> Spencer
>
> Meeting materials here: 
> https://datatracker.ietf.org/meeting/interim-2016-dtn-02/session/dtn
>
> # Intro (Mark Blanchet)
> Milestones
>
>                 - 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.
>                 - Scott prefers to not, if the document can be 
> unambiguous.  Maybe put something in an appendix?
> - 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).
>
> 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.
>
> Ronald: this seems to only be useful in the context of single-copy 
> routing, does anyone see utility in a multi-copy routing scheme?
>
> Rick Taylor sees real utility in being able to turn this option on as 
> a diagnostic tool to identify terrible badness in the network.
>
> - 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
>                 - v4 agent can either revert to v3 or shutdown the 
> connection when it receives a message from a v3 tcpcl
>                 - 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