On Wed, Dec 17, 2008 at 12:10 PM, Ted Hardie <[email protected]> wrote: > 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? >
Basically I view the return path state option as an optimization. If you want to optimize away the performance penalty of doing reassembly, you can, but I think the extra code is purely optional. From a spec level, I'm happy with that because I think it allows the simple single-path implementation to work fine, and those who wish to add multiple code paths to tune are free to do so. > > >>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? > I was thinking of in-network reordering being the only problem here. For short messages, I don't think HoL blocking is a concern here. If it becomes a concern, I think we're into the realm we need to look at for dealing with larger messages. (With relatively small messages being sent out at line rate, even if an implementation was to not do HoL blocking internally, the OS would still buffer the same amount, so it's something of a shell game here. Separate topic of whether we need to have congestion control in the overlay link protocol.) Bruce > > >>(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
