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. 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. 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, 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. -Ekr _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
