Proposals for UDP information transport over the metagraph

[Guus Sliepen]

On Sun, Sep 28, 2014 at 07:29:49PM +0200, Etienne Dechamps wrote:

> While working on SPTPS UDP relaying I realized that there is one issue
> I didn't account for, which is that the sending node only knows the
> PMTU to the first relay node. It doesn't know the PMTU of the entire
> relay path beyond the first hop, because the relay nodes don't provide
> their own PMTU information over the metaprotocol.
> 
> Now, in the legacy protocol this is not really an issue, because TCP
> MSS clamping (which is really what matters in practice) is applied on
> a hop-per-hop basis,

Actually, it's not only MSS clamping but also the generation of ICMP
Fragmentation Needed/Message Too Big packets. But the effect is the
same.

> Therefore it appears we need a way to figure out, for a specific node,
> what the "indirect PMTU" (i.e. PMTU when relaying) is. This
> information would presumably be stored in an "indirect_mtu" field (or
> something like that) in node_t, and maintained separately from the
> "mtu" field which is set by the normal discovery process.

I don't think we need another field for this. Instead, I think we should
try to do end-to-end PMTU discovery. If SPTPS UDP relaying is
implemented, this should be quite easy. This would also solve the
freshness issue, as normal PMTU discovery already handles PMTU shrinking
or growing. It could be optimised by having intermediate nodes send the
equivalent of an ICMP Fragmentation Needed/Packet Too Big message back
in case the next hop has a smaller PMTU than the packet that has to be
relayed.

Pros: no need to change/amend the meta or UDP protocol. Reuses the
existing PMTU code. Same quality as the existing PMTU code.

Cons: more probes are being sent than with the legacy protocol.

What do you think?

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20141002/7511ec43/attachment.sig>