Proposals for UDP information transport over the metagraph

[Etienne Dechamps]

On Thu, Oct 2, 2014 at 7:10 PM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> 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.

You actually need a UDP wire format change to accomplish this, because
now you need to be able to distinguish between MTU probes and actual
data packets without having to decrypt the packet first (currently
this is encoded in the type field which undergoes SPTPS encryption),
because relays would need access to that information. Otherwise MTU
probes that are larger than some link's MTU would just get relayed
over TCP, which defeats the whole purpose.

However, relays that need to fall back to TCP because they don't have
any way to reach the next hop over UDP would still relay the MTU probe
over TCP (because there might be some UDP link further down the relay
chain). So at some point you end up sending MTU probes (which by
definition are large) over TCP metaconnections. That's significantly
less efficient than simply sending the MTU size over the metagraph.
I'm not sure we care, though.

In addition, freshness it actually worse with your proposal, because
MTU probing takes more time than getting periodic information
messages, depending on the intervals.

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

This would require a new datagram type as well, which would need to be
unauthenticated (otherwise you would need to negotiate a key just to
get the "packet too big" message, and that's just silly). I think it
would simply be simpler (not to mention more reliable) to send that
"packet too big" message over the metagraph... but at that point we
might just as well implement the "periodic UDP info messages" proposal
because it basically does the same thing but in a cleaner and faster
way.

> What do you think?

Well, conceptually my "periodic UDP info messages" and your
"end-to-end MTU probing" proposal are actually quite similar: in the
former "pings" are simply the data packets, and "pongs" are UDP info
messages sent over the metagraph; in the latter "pings" are MTU probes
and "pongs" are MTU probe responses. The former is way more efficient
(very small messages and there are very few of them), the latter
requires less changes (that's debatable though because we would need a
new type of datagram).

Honestly, as I mentioned in my first post, something that I'm also
quite interested in is getting fresh, regularly updated UDP address
information, because in some circumstances (e.g. UDP hole punching
with blind port translation) that could allow nodes to establish UDP
communications where they otherwise can't. I really don't think the
current ANS_KEY solution for that is good enough because of freshness
issues. In my proposal we can simply use UDP info messages to
transport UDP address information alongside the indirect MTU and keep
that information fresh, whereas there is no way to convey that
information just by using end-to-end MTU discovery.