[dtn-interest] Last call of TCP CL draft: Proposal to add reason for refusal to BUNDLE_REFUSE message

[Elwyn Davies <[e-mail]>]

Hi.

On reviewing the TCP Convergence Layer draft, it occurred to me that in
order for both bundle sender and receiver to determine the consequences
of a REFUSE_BUNDLE message, the message should have a reason for the
refusal associated with the message.

Section 3 of the draft currently says:

>    Another optional feature is that a receiver may interrupt the
>    transmission of a bundle at any point in time by replying with a
>    REFUSE_BUNDLE message which causes the sender to stop transmission of
>    the current bundle, after completing transmission of a partially sent
>    data segment.  Note: This enables a cross-layer optimization in that
>    it allows a receiver that detects that it already has received a
>    certain bundle to interrupt transmission as early as possible and
>    thus save transmission capacity for other bundles.

In order to actually save transmission capacity, the sender needs to
understand why the receiver wants to cancel the transmission, and needs
to act differently depending on what the reason was.  There seem to be
three cases:
1. The receiver already has all of the bundle (fragment) or what has
been received so far completes the bundle (fragment) because the
receiver already had fragment(s) that can be combined with what has just
been received.
- The sender need not try to send the bundle (fragment) again.
2. The receiver can store what it has already received but cannot take
any more for the moment.
- The sender and receiver can do reactive fragmentation and the sender
can try to send the remaining fragment later.
3. The receiver either has no (more) resources to store the bundle or
resources that it thought it had have been preempted (e.g., by a higher
priority bundle on another link) during reception, and needs to discard
what has already been received, if anything.
- The receiver should retry sending the whole bundle later.

If the sender isn't told the reason explicitly then it will have to
assume one of the cases. This would probably be case 1 if we assume that
the 'note' in the current version of the draft is the primary intention
of the REFUSE_BUNDLE message.  This means that the receiver has no way
to request a retransmission other than a peremptory shutdown of the link
which may not be a very efficient way of handling temporary resource
shortage. 

Suggestion:
The flags in the REFUSE_BUNDLE message (currently unused) are used to
encode the three cases above.  This is backwards compatible assuming
that standard IP prectice of ignoring unused flags has been adopted.

Question to implementors:
DTN2 does not currently implement REFUSE_BUNDLE: It never sends
REFUSE_BUNDLE messages and treats a received REFUSE_BUNDLE as a protocol
error, breaking contact immediately. So.. do any other bundle protocol
implementations actually implement REFUSE_BUNDLE?