On Wed, Dec 17, 2008 at 2:17 AM, jiangxingfeng <[email protected]> wrote: > >> 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. > > >> Well, you are, however, potentially increasing the lookup latency. The via >> list is probably the only reason that an intermediate node may be required to >> fragment the message. An alternative might be for each node to maintain >> state >> about the previous hop instead of including a via list. > > My concern about the state maintaining mechanism for symmetric recursive is > still security issues. If a malicious peer controls a couple of peers, it can > let peer A sends a great number of requests which is destined to peer B. Upon > receiving the request, the peer B won't give the response intentionally. In > this case, all intermediate peers are full of state which could be only be > cleared by timeout, so that the overlay will experience the DoS. Am I > missing something? > No, that was the security concern I had in my last response, and I agree with you. After further thought, I don't believe we can require storing return path state as the solution, however, there is another option I think will work in all cases. Here's my proposal. There are two options that work that don't require major changes to the header structure to handle corner cases. Basically, I think that in most cases storing state will be OK (except when you're under attack). However, since we're prohibiting large messages from the overlay (or at least not supporting them now), really, hop-by-hop reassembly isn't that bad anyway. Almost all messages will be 2 or 3 frags on the typical (1500 MTU) network. A peer using UDP (or other) for an overlay link protocol MUST either maintain return path state or perform hop-by-hop reassembly. It is RECOMMENDED that a peer be configured with a maximum amount of state it is willing to maintain for return paths for messages, and if that amount is exceeded, fall back to hop-by-hop reassembly. In defining the UDP overlay link protocol, the spec will say that a peer fragmenting a message MUST NOT interleave other messages with the fragments, and for reassembly will specify a maximum number of out-of-order packets that must be buffered before discarding the partial message. (more careful wording of the two paragraphs is required, but I think that captures the core) That way, any peer is allowed to reassemble, and that can be done with a finite amount of buffer space, so that approach is safe from attack. Storing return path state is a slight optimization that can be done when space is available to store return state. There's a corner case where a peer doing reassembly after several hops of peers storing state might see more interleaving packets that have built up on the intermediate hops. However, the hop-by-hop ACKs will take care of that. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
