Re: [dtn-interest] Comments on the bundling draft

[Scott Burleigh <[e-mail]>]

At 02:06 PM 12/19/2004, Manikantan Ramadas wrote:

>Some thoughts/comments/suggestions on
>draft-irtf-dtnrg-bundle-spec-02.txt :
>
>* Sec 2.3.2 We might need a RegistrationError.indication primitive to
>serve the case (for example) if the default failure action requested
>of deferring bundle delivery until a period of passive or active
>reception by the application was unacceptable to the bundle agent (for
>storage or other administrative considerations). A bundle-agent may
>also choose to reject a request by the application to run a procedure
>provided by the application while deferring bundles for security
>reasons, say. Besides the Register.request, a
>Change_registration.request requesting changes as in the above
>examples, may also deserve a RegistrationError.indication.

A good point, Mani, but it's a fine line: my preference is to limit 
prescriptions for error handling in a spec like this to those that pertain 
to the protocol itself, to indicate intent to the developer.  Certainly 
there are wide range of other anomalies that a sound implementation is 
going to have to handle somehow, but I don't think it's our job as protocol 
designers to make all those rules, since none of this Service Description 
stuff affects interoperability anyway.  We run the risk of over-specifying 
and unreasonably constraining the developer.

>* Sec 2.5.2 II para, II line, may be you want to call this one
>CancelBundle.request to be in Sync. with the title as we have with all
>other request primitives? Just caught my eye, thats all.

You mean in the "Semantics" paragraph, right?  Absolutely, good catch.

>* Sec 2.5.10 SendError.indication : Since the bundling application
>uniquely refers to each Send request with a SendTokenBinding, isn't it
>enough if we just return the SendTokenBinding parameter instead of all
>those parameters we are returning?

Good point; certainly simpler and more elegant.  It forces the application 
to remember all the transmission parameters that were associated with that 
Send.request, though.  I dunno, I could go either way on this question, but 
I'm leaning toward agreeing with you.

>* Closing out Section 2,  May be we need a table(s) of reason-codes to
>be sent back as a parameter along with SendError.indication and
>RegistrationError.indication primitives? Reason-codes for
>SendError.indication could include reasons like :
>
>  o No route to host (ever)
>  o Can't meet lifespan (if the bundle agent was aware of the link
>schedules)

Yes, a good idea.

>While RegistrationError.indication could include reason-codes for
>stuff like :
>  o Can't defer delivery
>  o Can't run user-specified procedure

Again, though, I disagree on this one.

>* This is just a curiosity question: Why have we left Reserved spaces
>for bundle header type values interspersed like 0x03, 0x04, 0x06
>instead of having all the Reserved values towards the end?

Well, the spec has gone through a lot of changes, and implementations have 
tracked those changes to some extent.  Since the header type numbers are 
arbitrary anyway, I think it just seemed as if we'd be somewhat less likely 
to break something somewhere if, whenever we deleted a header type, we 
simply retired the number and left it Reserved rather than reassigning that 
number and all subsequent type numbers.

>* Sec 3.3, ASCII diagrams illustrating bit allotment for Class of
>Service Flags and Payload Security would be nice!

You're right, a worthwhile picture to include.

>* Sec 3.7. This has been raised in a recent thread on DTN Security.
>But just for the sake of completeness : we need to clearly say what
>happens under reactive fragmentation when bundles authentication
>breaks at the receiver. Although reactive fragmentation is likely to
>be a rather corner case (at least for links with relatively long
>uptimes), we go thru' all this pain just to make sure NOT to lose bits
>that made all this way but were corrupted just because the link went
>down right in the middle of transmission, right? But this is all
>useless if the receiving bundle agent is going to throw such a
>fragmented bundle anyways since it was inauthentic.

Right, that issue surfaced after this version of the spec was 
submitted.  We clearly have to address this.

>* Sec 4.2 Step 1, last-but-1 line : you mean the "sending bundle
>agent" here right? Or, I don't understand whats going on here.

Yes, it would be the sending bundle agent that was enforcing these rules.

>* Sec 4.4 Bundle Fowarding : Before beginning with Step 2, how do we
>handle cases such as
>
>  o This bundle must have taken the wrong path to reach us because we
>have no route to the destination region (ever)
>
>  o We have a route to the destination region, but the link is down
>now, and  based on link schedules we know that we can't meet the
>TTL when the link would become available next. In such a case, it
>seems good not to bother saving the bundle, but rather send back an
>error message.

Yes, this is a place where we might want to beef up the anomaly handling 
procedures.  In the first case, I think we discard the bundle and, if it 
was custodial, we send back a "Failed" custodial signal as described in 
Step 3 of 4.2 (using reason codes as defined in Table 7).  In the second 
case, I would be inclined to simply hang on the bundle and see what 
happens, as sometimes we don't know all that we think we know.  But this 
could be a management decision supported by an implementation-specific 
hook, and a rejection decision could again result in one of those "Failed" 
custodial signals.

>* Sec 4.5.1 Bundle Fragmentation, towards the end when we discuss
>reactive fragmentation. All of this discussion seems to assume that
>reactive fragmentation happened while transmitting the final payload
>section of the bundle. May be a few lines on what to do when the link
>went down while transmitting say like the Dictionary Header could be
>useful?

We need to make it clear that this case does NOT result in reactive 
fragmentation: the receiver can't construct a fragmentary bundle unless it 
receives the entire bundle header and at least one byte of the payload.  I 
think this is implied by the first bullet in the first paragraph of 4.5.1 
but obviously it is possible to miss that.

>* Sec 5.1 Table 5. This one is rather a matter of style. The table
>only lists the value of status flag while the discussion below the
>table uses clauses like "if the bundle fragment bit is set..", "if the
>bundle-forwarded bit is set.." etc instead of saying "if the value was
>0x80.." etc.  While it is clear to me that the
>bundle fragment bit is the MSB and the bundle-forwarded bit is the
>third LSB, may be adding a "Bit" column by the side of the "Value"
>column or having a simple ASCII diagram instead of the table
>illustrating the flag assignment, would make me happy. But this is
>certainly a low priority objection/comment.

Sure, this is reasonable.

>* Sec 5.2 Table 7 The values 0x03 - 0x06 clearly don't go with a
>Status flag 0x01 (Custody Transfer Succeeded) (Table 6). May be we
>need a Status flag assignment in Table 6 that stands for Custody
>Transfer Failed (may be 0x00)?

I think calling the bit identified by mask 0x01 the "custody transfer 
succeeded" bit, with implicitly Boolean semantics, is actually a pretty 
efficient way to convey this information.  (Maybe that column heading 
should be "mask" instead of "value".)  But I do think we need to add value 
0x00 "No error" to Table 7.

Scott