Dear Guus, while improving the PMTU Discovery algorithm, I found the following behavior in the method "send_udppacket": 1) The code checks, whether the data size is smaller than the MTU, thus if it fits into a single UDP packet. If not, you send the packet via TCP. 2) The data is compressed, changing its size. (Usually, making it smaller, but that's not always true.) 3) The compressed data is sent. My question is: What use is it, to check the data size prior to compression? In a worst-case scenario, the uncompressed data could fit into a single UDP packet, while the compressed data does not. (This is especially true for encrypted data, which can only be compressed badly.) That would result in sending two fragmented UDP packets to the destination, increasing overhead and making packet delivery more unreliable. I suggest to implement a check, if the compressed data really is smaller than the uncompressed one and decide, what to send over the wire. To distinguish between compressed and uncompressed data, we could introduce a flag in vpn_packet. As you might have seen, I already included some flags in my commit, there'd be enough room to add another, indicating whether compression was used or not. Best, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20110105/237c47da/attachment.htm>
On Wed, Jan 05, 2011 at 11:23:16AM +0100, Daniel Schall wrote:> while improving the PMTU Discovery algorithm, I found the following behavior > in the method "send_udppacket": > > 1) The code checks, whether the data size is smaller than the MTU, thus > if it fits into a single UDP packet. > > If not, you send the packet via TCP. > > 2) The data is compressed, changing its size. (Usually, making it > smaller, but that's not always true.) > > 3) The compressed data is sent. > > My question is: What use is it, to check the data size prior to compression?The PMTU discovery process already takes compression into account, and the MTU it sets is always small enough so that even an incompressible packet that will expand somewhat can still be safely sent via UDP. Furthermore, ICMP packets will have been sent and PMTU clamping will be used so that the sender will usually not send packets that are larger than the PMTU tinc found. The fallback to TCP is only used when the PMTU discovery has not yet finished, and when someone still sends a packet that is too large and cannot be handled otherwise (for example, non-IP protocols or some routing protocols that add their own footer to IP packets).> I suggest to implement a check, if the compressed data really is smaller > than the uncompressed one and decide, what to send over the wire.Although that could be done I don't think it is worth the effort for the few packets that might benefit from it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20110105/3f2b2c64/attachment.pgp>