Subject: [P2PSIP] Add route log option to diagnostic draft for collecting diagnostic information

From: Roni Even <[email-masked]>
Date: Thu, 13 Aug 2009 10:00:23 +0300

Hi,

Route logging was removed entirely from the 03 base draft, due to the
problems it causes with fragmentation and message length. There was a
discussion  on the mailing list to use it for the diagnostics.

Currently the diagnostic draft suggests using the Path Track method to
retrieve diagnostic information. In order to collect diagnostic information
from all peers in a route the requesting peer must send a separate request
to each peer in the route.  

In past versions there was an option for the requesting peer to send one
request and each peer in the route would respond with his diagnostic
information, this option was removed due to security considerations (message
explosions attack) and we were looking for another method to optimize the
diagnostic information reporting.

I suggest adding a route log option to the Inspect method. This will enable
a requesting peer to send one request and collect diagnostic information
from the peers in the route. In order to limit the message length and
prevent fragmentation we can specify a fixed subset of diagnostic
information that will be reported when route log is requested. The full
diagnostics will still be collected using the Path Track method.

Does this looks  like a reasonable optimization for collecting the
diagnostic information

Thanks

Roni Even

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 17 Aug 2009 00:26:38 -0400

Roni,

I think the two things that really caused route log to be dropped were
the fragmentation problem and the lack of a real motivating scenario
to use it.

Could you describe some scenarios that motivate the route logging, in
particular over iterative queries?  The biggest argument that I can
see is that it captures a single path that might otherwise change
between queries.  There's possibly an efficiency advantage if the
fragmentation can be solved.   I'm not currently convinced either of
those motivate route logs being added, but I am open to the
possibility.

As far as fragmentation, could you be a bit more specific about what
information you want to store, and how much space it will take?  Your
thought would be to store the route log following the forwarding
header and split the first fragment as needed?

Bruce

2009/8/13 Roni Even <[email-masked]>:
> Hi,
>
> Route logging was removed entirely from the 03 base draft, due to the problems it causes with fragmentation and message length. There was a discussion  on the mailing list to use it for the diagnostics.
>
>
>
> Currently the diagnostic draft suggests using the Path Track method to retrieve diagnostic information. In order to collect diagnostic information from all peers in a route the requesting peer must send a separate request to each peer in the route.
>
>
>
> In past versions there was an option for the requesting peer to send one request and each peer in the route would respond with his diagnostic information, this option was removed due to security considerations (message explosions attack) and we were looking for another method to optimize the diagnostic information reporting.
>
>
>
> I suggest adding a route log option to the Inspect method. This will enable a requesting peer to send one request and collect diagnostic information from the peers in the route. In order to limit the message length and prevent fragmentation we can specify a fixed subset of diagnostic information that will be reported when route log is requested. The full diagnostics will still be collected using the Path Track method.
>
>
>
> Does this looks  like a reasonable optimization for collecting the diagnostic information
>
>
>
> Thanks
>
> Roni Even
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>

---

From: Roni Even <[email-masked]>
Date: Mon, 17 Aug 2009 09:06:59 +0300

Bruce,
The major motivation is having a simple way to collect data along the path. In the first versions of the diagnostic draft there was a method  that caused each peer in the route to send a respond to the requesting peer with the diagnostic information. This was removed because of security reason since this method could serve as a tool for message explosion attack. 
Currently using iterative mode you will need to send a message to each peer in the path to collect diagnostic information. 
I think that getting information like processing power, BW, status and uptime (this is less than 30 bytes per node)  from each node in the route (this can be on the forward or return path) can help the requesting peer with estimating the quality of the link. It is true that it applies to the current path which may change but this is also true for the case of iterative request. Yet this is a more efficient way. 
As for the information to collect, I gave an example since the first question is if this looks like a viable solution in general since it optimizes the current flow. If we think it is than we can discuss the information that may be collected using this method.

It would have been more precise to get this route log information in the requests but this option was removed from the base draft.

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Bruce Lowekamp
> Sent: Monday, August 17, 2009 7:27 AM
> To: Roni Even
> Cc: p2psip
> Subject: Re: [P2PSIP] Add route log option to diagnostic draft for
> collecting diagnostic information
> 
> Roni,
> 
> > Currently the diagnostic draft suggests using the Path Track method
> to retrieve diagnostic information. In order to collect diagnostic
> information from all peers in a route the requesting peer must send a
> separate request to each peer in the route.
> >
> >
> >
> > In past versions there was an option for the requesting peer to send
> one request and each peer in the route would respond with his
> diagnostic information, this option was removed due to security
> considerations (message explosions attack) and we were looking for
> another method to optimize the diagnostic information reporting.
> >
> >
> >
> > I suggest adding a route log option to the Inspect method. This will
> enable a requesting peer to send one request and collect diagnostic
> information from the peers in the route. In order to limit the message
> length and prevent fragmentation we can specify a fixed subset of
> diagnostic information that will be reported when route log is
> requested. The full diagnostics will still be collected using the Path
> Track method.
> >
> >
> >