Hi Guus,
while checking the source code, I stumbled upon PMTU Discovery.
I've got a question regarding the process of sending/receiving PMTU packets.
As I understand, the packet flow is like this:
1 .Tinc creates a packet with a specific payload length to send it as an
PMTU probe.
(The data part is just some random bytes.)
2. This packet gets compressed and sent over UDP.
3. The packet is received from the other node and gets decompressed.
4. The uncompressed length of the packet is taken as MTU value.
My question is, whether it is reasonable to compress a PMTU packet, since
the payload length, that gets transferred over the wire changes.
In my opinion, tinc must not compress the PMTU packet to keep the original
length as desired for probing.
Best,
Daniel
PS: As you may have noticed, I am still developing the multicast/local part.
As soon as I've fixed the errors, I'll try to merge my changes with your
most recent git version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20101126/e6f251b9/attachment.htm>
26.11.2010 10:19, Daniel Schall wrote:> Hi Guus, > > while checking the source code, I stumbled upon PMTU Discovery. > > I?ve got a question regarding the process of sending/receiving PMTU packets. > > As I understand, the packet flow is like this: > > 1 .Tinc creates a packet with a specific payload length to send it as an > PMTU probe. > > (The data part is just some random bytes.) > > 2. This packet gets compressed and sent over UDP. > > 3. The packet is received from the other node and gets decompressed. > > 4. The uncompressed length of the packet is taken as MTU value.Yes, that's how it works.> My question is, whether it is reasonable to compress a PMTU packet, > since the payload length, that gets transferred over the wire changes. > > In my opinion, tinc must not compress the PMTU packet to keep the > original length as desired for probing.The thing is: original protocol does not let only some packets to be compressed while other not: it's all or none, being negotiated at the start. So we can't just omit compression for some packets, or else the receiving end wont be able to decode them and will never reply. I once tried to get a "zero compression" implemented - to keep data uncompressed but still wrap it into compression structure. It's quite easy with zlib (level=0), and it can be done in a separate routine too, without calling zlib functions (since changing compression level on the fly does not work well), but I weren't able to figure out how to do that for lzo compressor. And later I forgot about that issue ;) We can't change the protocol now either, without breaking compatibility with older versions. And during negotiation, there isn't even version exchange happens currently, so it isn't possible to base this decisison on the peer version either. /mnt
On Fri, Nov 26, 2010 at 08:19:10AM +0100, Daniel Schall wrote:> My question is, whether it is reasonable to compress a PMTU packet, since > the payload length, that gets transferred over the wire changes. > > In my opinion, tinc must not compress the PMTU packet to keep the original > length as desired for probing.Tinc uses the size after compression, minus compression overhead, to set the PMTU. This means that if you have compression enabled, the PMTU will always be set small enough so that a completely incompressible packet can go through. Of course, for normal packets this means the PMTU is smaller than optimal, but there is nothing one can do about that. In src/net_packet.c, mtu_probe_h() takes a "len" parameter that is set to the safe size by the code at the end of receive_udppacket(). -- 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/20101126/622f9977/attachment.pgp>