> >> Yeah, unfortunately, the growth is an issue and I don't think the above > >> method > >> can be guaranteed to work. Short of the sending nodes being able to > >> estimate > >> the size of the overlay and hence extrapolate the expected number of > >> entries > >> in a via list and adjust the message size accordingly, we may have a > >> problem. > > > > IMHO, some statistics data from diagnostic procedure may be helpful for a > sending node to estimate the possible hops for the request to be sent. For > example, in Chord, the peer can periodically to send ping message to collect > the hops needed to random keys which are located in difference scope in the > circle. With this statistics data in mind, if a node wants to send a request > keyed by key A, it can estimate the most accurate hops. More statistics data > collected, more accurate number of the possible hops. OTOH, the peer also > could > record the maximum hop number, which is also be helpful to avoid future > fragmentation. > > > > Unfortunately, it's growth of the via list that's the biggest concern > here, so using diagnostics to solve the problem is hard since all > those messages have via lists (and you have no guarantee that all of > the vias will fit in the first frag even if you put nothing else in > it.
DRR or RPR proposed in relay draft do not require via-list to route the response, so the diagnostic message can rely on DRR or RPR to be routed. _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
