Two of the topics that came up several times in the recent discussion about fragmentation were HoL blocking and the performance impact of reassembling messages other than at the destination peer. These questions are significant well beyond the question of UDP fragmentation.
I've been giving these concerns a lot of thought, and (regardless of the other issues related to fragmentation) I think there's an underlying large message/performance question here that we need to address. I thought that this issue had been resolved in MSP, but want to confirm consensus and the scope of that consensus. At MSP, we agreed not to support "large" messages, leaving it up to the overlay configuration to specify the notion of large. For most deployments that essentially store and retrieve pointers to resources and set up connections, my current belief is that messages wind up being in the 2000-4000 byte range, so 2-3 fragments on a 1500 MTU network. HoL blocking and latency penalties were raised as objections to my proposal that the simplest way to solve issues with UDP fragmentation was to reassemble the message at every hop and to not interleave fragments from different messages on transmission. However, I think it's important to note that what I proposed we should do with UDP is exactly what the TCP link protocol does. So if those are performance concerns, we need to redesign the TCP link protocol, at the least. My belief from MSP is that we want to ignore all of these issues currently, and we believe that the current message size is "small enough" that we don't need to worry about the performance issues. There are solutions we can apply for dealing with larger messages and maximizing performance, but that's not the goal of the current protocol. (though could be added as new overlay link protocols) OTOH, if there is consensus in the group that we need to solve these, then we should do it, but we need to address it as a problem with all of our link protocols, not just UDP. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
