PMTU Discovery Question

[Daniel Schall]

> > 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.

But in my opinion, sending a compressed MTU packet makes the whole process
of discovering the PMTU totally worthless.
After compressing the packet, is has an arbitrary length.
By sending this compressed packet, we can only determine whether the
compressed packet length was smaller or equal than the MTU, but we cannot
say something about the original packet length and how this fits in the MTU.
Therefore, as tinc takes a look at the original length only, it makes false
assumptions about the path MTU.

> 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.

I agree, that can't be done while keeping compatibility with older clients.
But since this version of PMTU Discovery seems to be broken anyway, I'd
really like a fix for that.

I suggest implementing a flag field, which comes prior to the seqno in the
packet.
That field will not be encrypted or compressed and is able to indicate,
whether compression is active or not.
Or it can be used to indicate, that this packet is an MTU packet, which tinc
handles separately (without compression).

Nevertheless, for implementing my own local/multicast version of tinc, I
need an (unecrypted) flag in the vpn_packet_t as well, to check if the
packet was sent to a local interface.
Therefore, I'd also be glad if the protocol could be changed  in the near
future.