Unless, overlay and nodes can somehow enforce message size, we cannot
assume minimal size messages (2-3 frags).
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.
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.
-salman
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
