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

[Scott Burleigh <[e-mail]>]

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.
 
>> I think the key idea here is that bundle status reports constitute a thin
>> “application”-layer diagnostic protocol on top of the bundle protocol in
>> (I believe) exactly the same way that ICMP messages constitute a thin
>> diagnostic protocol on top of IP.  BSRs are the payloads of bundles
>> just as ICMP messages are the data portions of IP datagrams.  They
>> are useful in more or less the same way that ICMP messages are useful.
> 
> That's also how I understood it.
> 
>> To quote from RFC 792:
>>
>> “ICMP, uses the basic support of IP as if it were a higher level protocol,
>> however, ICMP is actually an integral part of IP, and must be implemented
>> by every IP module.  ICMP messages are sent in several situations: for example,
>> when a datagram cannot reach its destination, when the gateway does not have
>> the buffering capacity to forward a datagram, and when the gateway can direct
>> the host to send traffic on a shorter route.”
>>
>> Substitute BSR for ICMP message and Bundle Protocol for IP and I think you
>> get more or less what the DTN documents say.
> 
> But "when a gateway forwards a datagram" is not a part of this text,

Right, this is one place where BSRs go beyond what ICMP messages do -- reporting not just on anomalies but also, in some cases, on routine events that we may want to track for network management purposes.  And, just as you say, this greatly exacerbates the potential for traffic storms.

> and "when a gateway does not have the buffering capacity" seems to me to refer to Source
> Quench, which is now known to be a bad idea.

It would be possible to interpret this sort of BSR as a Source Quench and use it as the basis for a congestion control protocol, provided the Report-to EID is always the same as the proximate sender's EID (which I think will mostly be unlikely).  I agree that this would be a bad idea -- source quench is a particularly unhelpful way to do congestion control over long delays -- but so far as I know nobody is doing it.

The significance of this BSR is something like "This bundle got deleted instead of delivered, so something may be busted somewhere.  In case it would be helpful to understand why, the reason is that the reporting router didn't have enough storage for it; maybe the router is congested or maybe the bundle is just too big to route down this path."  Like the other BSRs, it is mainly intended to be diagnostic.

>> Now, that is not to say that BSRs don’t constitute a potential DOS attack, in
>> part because -- as Michael points out -- BSRs can be triggered by some kinds
>> of wholly nominal events as well as by anomalies.  We haven’t given a lot of
>> thought to ways of mitigating this threat, and I think we should.  Here’s a suggestion.
>> The architecture and Bundle Protocol documents currently define the circumstances
>> under which BSRs must be issued.  I propose that we simply qualify all those
>> “must” statements with the additional clause “and a Bundle Reporting License [BRL]
>> is known to be applicable.”  A BRL is a 4-tuple of {my own EID, source EID,
>> report-to EID, status reporting flag}, and it is applicable if and only if its members
>> characterize the BSR issuance opportunity.  The propagation of BRLs is outside
> 
> 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.

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.
 
Scott