This mailing list is mainly used for the developers. If you wish to discuss something technical about tinc, you can do it on this list. ()

headers

Daniel Schall | 26 Nov 2010 08:19

PMTU Discovery Question

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.

<div><div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi Guus,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">while checking the source code, I stumbled upon PMTU Discovery.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">I&rsquo;ve got a question regarding the process of sending/receiving PMTU packets.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">As I understand, the packet flow is like this:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">1 .Tinc creates a packet with a specific payload length to send it as an PMTU probe.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (The data part is just some random bytes.)<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">2. This packet gets compressed and sent over UDP.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">3. The packet is received from the other node and gets decompressed.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">4. The uncompressed length of the packet is taken as MTU value.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">My question is, whether it is reasonable to compress a PMTU packet, since the payload length, that gets transferred over the wire changes.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">In my opinion, tinc must not compress the PMTU packet to keep the original length as desired for probing.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Best,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Daniel<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">PS: As you may have noticed, I am still developing the multicast/local part.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">As soon as I&rsquo;ve fixed the errors, I&rsquo;ll try to merge my changes with your most recent git version.<p></p></span></p>
</div></div>

headers

Michael Tokarev | 26 Nov 2010 08:36

Re: PMTU Discovery Question

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

headers

Daniel Schall | 26 Nov 2010 10:03

RE: PMTU Discovery Question

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

headers

Guus Sliepen | 26 Nov 2010 12:02

Re: PMTU Discovery Question

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

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