At 7:34 AM -0800 12/17/08, Bruce Lowekamp wrote: > > >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.
First off, I've never been a fan of having to have two code paths where one will do. This seems to say that return path state is preferred but hop-by-hop reassembly works in all cases. Why is the trade-off preferring return path state enough to overcome the ick factor of having to maintain two code paths and switch between them? >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. This seems to guarantee that a packet requiring fragmentation MUST create head of line blocking until all fragments are sent. What are the cases where interleaving messages might have occurred? >(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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
