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 protected] [mailto:[email protected]] 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, > > 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 protected]>: > > 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 protected] > > https://www.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
