On Wed, Dec 17, 2008 at 1:53 PM, Salman Abdul Baset <[email protected]> wrote: > > Unless, overlay and nodes can somehow enforce message size, we cannot assume > minimal size messages (2-3 frags). >
We decided in MSP that we will require that. In fact, overlay config already restricts resource size. Technically it doesn't currently apply to messages, but we had clear consensus in MSP that we would do so. (more below) > The return path state is simply a back pointer to the node (IP address, > message identifier) from which the message was received. > > The concern about return path state is that it may tremendously increase the > use of memory because: > 1. a significant portion of inprogress messages timeout wasting memory. > 2. peers are under DoS so that there a lot of inprogress messages. > > However, for fragmentation: > (1) 1. is still a problem. > (2) peers can also be under DoS using fragmentation. > a) A peer(s) try to store a large data object or > b) send many messages within the desired fragment count (2 or 3) to > chew up memory space at the next hop. > > > For return path state, a solution to 2. is to limit the inprogress messages > from a certain peer to a configured number. If the peer still sends more > messages, it can be informed to do ROUTE-QUERY. > > For fragmentation, a solution to (2-a) is that nodes limit the number of > maximum fragments per message. However, that does not address (2-b). > > (2-b) requires the same scheme as for return path state, i.e., rate-limit > and ask the exceeding sender to perform ROUTE-QUERY. > > Reassembly is still e2e. > > It is not clear to me that space-wise, why per-hop reassembly of 2-3 1500 > bytes segment is better than storing a <10 byte message identifier and a > 4-byte IP address of the node from which the message was received. > The implication of the requirement that a peer MUST NOT interleave one message with another is that the amount of buffer required for reassembly is capped per connection. It's # of connections * MTU * max tolerated out-of-order arrival (which for TCP for example is 4). That's a deterministic amount of space that scales per connection, so it's pretty small. > Observe that return-path state or via-lists are required to maintain > symmetric routing. However, it is not clear to me why this should be a MUST. > If sender->destination routing is done on object-ID and destination->sender > routing is done on sender ID, then there is no need for via-lists or > return-path states. Such scheme utilizes existing connections between peers. This has been discussed repeatedly on the mailing list and the discussion is in the appendix of the base draft. Please refer to those other discussions. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
