[dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct

[Michael Welzl <[e-mail]>]

Sorry for the long delay of this one...


> Michael Welzl wrote:
> >>>>>> pages 12/13: what is the rationale behind delivery options such as
> >>>>>> these:
> >>>>>>
> >>>>>>    - Report When Bundle Forwarded - requests a Bundle Forwarding
> >>>>>> Status
> >>>>>>       Report be generated when the subject bundle departs a DTN node
> >>>>>>       that has forwarded it.
> >>>>>>
> >>>>>>    - Report When Bundle Deleted - requests a Bundle Deletion Status
> >>>>>>       Report be generated when the subject bundle is deleted at a DTN
> >>>>>>       node.
> >>>>>>
> >>>>>> If I would propose something like these reports for the general
> >>>>>> Internet,
> >>>>>> it would immediately be rejected for obvious reasons ("how would
> >>>>>> this scale?
> >>>>>> why do you need this?" etc.) - why would this then be acceptable
> >>>>>> for a DTN?
> >> I'm mainly replying to this question because I think it's the crux of the
> > review.
> > 
> > I agree - but note that there's one more technical issue which I addressed:
> > the fragmentation mechanism. But first things first.
> 
> Okay, but I read that comment as asking just for more detail in the document.

Maybe. Based on the text I wrote, I couldn't see how this would
work, e.g. it mentions a report which I couldn't find elsewhere.
There may be something wrong with the mechanism (which I doubt),
or indeed some more details suffice (more likely).

[ removed a few paragraphs where I raised concerns about there being
  a BSR "when a gateway forwards a datagram" and a BSR which I
  considered to resemble source quench, both of which you addressed
  by explaining that these are merely status reports. This is fine
  with me as an explanation; the issue with these messages is the
  key problem which we agree on: that this greatly exacerbates the 
  potential for traffic storms. So I just comment on your suggested
  solution for this problem.]
  
 
> > Hm, does that mean that any node that generates a BSR of any kind would have
> > know in advance whether that message can reach its destination? That doesn't
> > seem like a realistic assumption to me. Or am I misinterpreting the "members
> > characterize the BSR issuance opportunity" part?
> 
> Right, a two-sentence description of this notion isn't quite enough.  The intent is that BRLs are pre-placed in some or all of the nodes of the network (by some delay-tolerant mechanism that's maybe similar to the pre-placement of encryption keys or the pre-placement of routing information) and each BRL is in effect a statement that "This node is authorized to issue a BSR in the course of processing a bundle with status reporting flag X turned on, provided the source EID of the bundle is Y and the bundle's report-to EID is Z."  The BRL would say nothing about the likelihood that the BSR would reach the report-to, only about whether or not the BSR may be issued.  Where BSRs are absent, no BSRs are ever issued.

That sounds very good to me - but I would suggest to realize this
as per-flow *soft* state in the intermediate nodes, and not store
BSRs in all nodes *in the network* but *along the path*. Now I know
that paths are not supposed to stay up for long in DTNs, but maybe
the assumption could be relaxed for this mechanism, as it's only
for BSRs of a diagnostic nature anyway. By the way, I would only
require this soft state mechanism for the per-bundle BSRs that
we discussed, not for all BSRs.



> My thinking is that the owners of endpoints Y and Z would work out ahead of time which nodes they want to get BSRs back from and pre-place BRLs accordingly.  If a bundle is routed through a node that is outside of this little diagnostic association and something untoward happens to it, too bad.  It's a simple device, but some complex network management relationships could grow out of it; like anything else, this could be good or bad depending on how it's used.
> 
> And there are some little details to be worked out, of course: we would probably want some way to wild-card X and/or Y and/or Z, and we'd need to think about what to do when Y is "dtn:none".  But the general idea is simply to provide a mechanism for BSRs to be issued when they're needed and suppressed when they would be destructive.

I agree.

Cheers,
Michael