> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Eric Rescorla > Sent: Friday, December 12, 2008 10:09 AM > To: [email protected] > Subject: [P2PSIP] RELOAD fragmentation > > The author team has been trying to flesh out the RELOAD fragmentation > model and > we're considering whether it needs a rethink. This is principally an > issue for UDP. > > Briefly, the current model is as follows: > > - Nodes communicate to each other by encapsulating every RELOAD message > in a FramedMessage (see 5.4.1.2). These are acknowledged at the > hop-by-hop level. Each FramedMessage contains a complete RELOAD > message > or ACK. > - If a message exceeds the maximum size that a node feels it can send > to an adjacent node (this principally is an issue for UDP), it is > expected > to fragment it. Each fragment replicates the ForwardingHeader. > - Intermediate nodes are not expected to reassemble fragments. > > The bits on the wire aren't fully fleshed out, but this is what we had > in > mind. > > Unfortunately, it's not clear that this works. Unlike IP (except with > LSRR), > the RELOAD header grows and could potentially exceed the MTU all on its > own. So, it's not clear how to handle that case. >
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. > The reason we didn't go for intermediate node reassembly was that (by > analogy > to IP) we didn't want to impose excessive burdens on the intermediate > nodes). However, it's not clear that this is a good analogy. After all, > you're already consuming reasource for the TLS and other state for > the adjacent peer anyway, and it's quite straightforward for them > to force you to chew up buffer space by sending a very large partial > message, so it's not clear there is a security issue here that > can't be solved just by having some sort of trivial timeout and > maximum size on the receiver side. > I do think security issues can be handled using timeouts; but, as a general philosophy, I don't think it is good to pile on more functionality on intermediate nodes just because they are already doing something else. In this particular case though, when symmetric routing is in use, I'm not sure there is a good alternative - I describe one option below, but I can't say that's necessarily good either. > Aside from state, the major disadvantage of hop-by-hop fragmentation > is performance for larger messages, since it becomes effectively a > stop-and-wait protocol instead of a windowed protocol. I'm not sure > how big a deal that is, 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. This still provides symmetric routing; however, each node will have to maintain state to route the response back. Security issues with state maintenance will be handled using similar timeouts as you mention above. > since I think we more or less agreed in MSP > that it's not a good idea to push lrge messages across the overlay, > but I thought it should be mentioned. > I think we should have a design that helps avoiding large messages across the overlay - I'll take this up in a separate thread. Thanks, Vidya > -Ekr > > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
