PMTU Discovery Question

[Michael Tokarev]

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