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
