Re: [dtn] [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

[Ben Schwartz <[e-mail]>]

On Fri, Feb 7, 2020 at 1:02 PM Alexey Melnikov <[e-mail]>
wrote:

>
> > Correctness: If two nodes both opt to return failed bundles, how are
> > they to avoid a ping-pong loop?
> >
> >               But on what basis would you terminate the ping pong, since
> on one of
> > those cycles a way out of the loop might appear?
> >               I think the answer is that the bundle lifetime and hop
> count
> > mechanisms will eventually cause the bundle to be destroyed, stopping
> > the routing loop.
>
> Fair enough. I agree that hop count should be sufficient. So it would be
> worth pointing this out in the document.
>

I'm still concerned with this type of solution.  This tight loop situation
is a problem that is likely to happen often in some applications, creating
serious inefficiencies when bundle lifetimes are large.  A more efficient
solution could be straightforward, e.g. don't update the "Previous Node"
block when returning the bundle on failure.  Then receipt of a block with
Previous Node == my Node ID indicates that this is not an ordinary
forward-routed bundle, and I can choose to drop this bundle instead of
continuing to route it.

A more explicit indication of return-on-failure would probably be even
better.

More generally, this is an example of how this draft's scope of intended
applications is hard to understand.  The Bundle Protocol makes some
assumptions about the topology and dynamics of its routing layer, but those
requirements are not made explicit anywhere, and the protocol is presented
as suitable for DTN applications universally.  For example, the behavior of
concern here would make Bundle extremely inefficient on large tree-shaped
networks.

> [[Alexey]]: I included these in the DISCUSS portion of my ballot.
> >
> > ##Section 5.6
> >
> > Error handling: What about CBOR parsing failures?
> >
> >               Please see my response to the DISCUSS item.
> >
> > [[Alexey]]: I included these in the DISCUSS portion of my ballot.
> >
> > ## Section 5.8
> >
> > Clarity: The insistence, here and earlier, that a bundle is only
> > fragmented into two packets, and that this can then be performed
> > recursively, seems unhelpful.  Bundles can be fragmented into
> > arbitrarily many pieces, and this binary subdivision concept is not
> > actually present in the protocol.  I suggest removing it from the text
> > as well.
> >
> >               Why is this unhelpful?  It's the formal procedure by which
> bundles
> > are fragmented.  Let's not remove it.
>
> I think saying that a bundle can only be fragmented into 2 pieces is a
> lie, because the algorithm says that it can be fragmented into more than 2.
> I found this text to be confusing as well. Just say that it can be
> fragmented into 2 or more non overlapping fragments.
>

The text on fragmentation in RFC 791 seems reasonably clear, and might be a
good basis for this description.