Subject: [BEHAVE] TURN: Avoiding IP Fragmentation

From: Philip Matthews <[email-masked]>
Date: Sun, 12 Apr 2009 16:27:35 -0400

As part of the IESG evaluation of TURN, Lars wrote:
> Discuss:
> Because TURN doesn't translate the ICMP messages necessary for PMTU  
> discovery,
> persistent fragmentation can occur. When we discussed this in the  
> WG, I thought
> we had come to an agreement that the document should say that TURN is
> NOT RECOMMENDED for applications that exchange UDP packets larger than
> the minimum PMTU (500-odd bytes), unless they implement RFC4821.

Hi Lars:

I don't actually remember this agreement, but I think it is a good  
point. I have tried to address it by rewriting the last part of the  
Overview section to include (amongst other changes) the following  
subsection:

2.7.  Avoiding IP Fragmentation

    For reasons described in [Frag-Harmful], applications, especially
    those sending large volumes of data, should try hard to avoid having
    their packets fragmented.  Applications using TCP can more-or-less
    ignore this issue because fragmentation avoidance is now a standard
    part of TCP, but applications using UDP (and thus any application
    using this version of TURN) must handle fragmentation avoidance
    themselves.

    The application running on the client and the peer can take one of
    two approaches to avoid IP fragmentation.

    The first approach is to avoid sending large amounts of application
    data in the TURN messages/UDP datagrams exchanged between the client
    and the peer.  This is the approach taken by most VoIP
    (Voice-over-IP) applications.  In this approach, the application
    exploits the fact that the IP specification [RFC0791] specifies that
    IP packets up to 576 bytes should never need to be fragmented.

    The exact amount of application data that can be included while
    avoiding fragmentation depends the details of the TURN session
    between the client and the server: whether UDP, TCP, or TLS  
transport
    is used, whether ChannelData messages or Send/Data indications are
    used, and whether any additional attributes (such as the DONT-
    FRAGMENT attribute) are included.  Another factor, which is hard to
    determine, is whether the MTU is somewhere along the path is reduced
    for other reasons, such as the use of IP-in-IP tunneling.

    As a guideline, sending a maximum of 500 bytes of application data  
in
    a single TURN message (by the client on the client-to-server leg) or
    a UDP datagram (by the peer on the peer-to-server leg) will  
generally
    avoid IP fragmentation.  To further reduce the chance of
    fragmentation, it is recommended that the client use ChannelData
    messages when transferring significant volumes of data, since the
    overhead of the ChannelData message is less than Send and Data
    indications.

    The second approach the client and peer can take to avoid
    fragmentation is to use a path MTU discovery algorithm to determine
    the maximum amount of application data than can be sent without
    fragmentation.

    Unfortunately, because servers implementing this version of TURN do
    not relay ICMP messages, the classic Path MTU Discovery algorithm
    defined in [RFC1191] is not able to discover the MTU of the
    transmission path between the client and the peer.  (Even if they  
did
    relay ICMP messages, the algorithm would not always work since ICMP
    messages are often filtered out by combined NAT/firewall devices).

    So the client and server need to use a path MTU discovery algorithm
    that does not require ICMP messages.  The Packetized Path MTU
    Discovery algorithm defined in [RFC4821] is one such algorithm.

    The details of how to use the algorithm of [RFC4821] with TURN are
    still under investigation.  However, as a step towards this goal,
    this version of TURN supports a DONT-FRAGMENT attribute.  When the
    client includes this attribute in a Send indication, this tells the
    server to set the DF bit in the resulting UDP datagram that it sends
    to the peer.  Since some servers may be unable to set the DF bit,  
the
    client should also include this attribute in the Allocate request --
    any server that does not support the DONT-FRAGMENT attribute will
    indicate this by rejecting the Allocate request.

How does this sound? Do you think it provides enough guidance to  
application designers?

The recommendation to send no more that 500 bytes came after I did a  
bit of math to see what the Path MTU might be in various situations.  
Depending on the situation, I got an application MTU ranging from 512  
(using Send/Data indications over UDP) to 544 (using ChannelData  
messages over UDP). To be conservative, I rounded these down to 500.

The comment that we are still investigating the use of RFC4821 came  
from spending a bit of time thinking about how it might be used. I  
came up with a number of issues. One issue is that we have tried to  
allow TURN to be implemented in user space, and it seems (from e-mails  
to the mailing list about a year ago) that some operating systems  
don't support setting the DF bit by unprivileged applications. Another  
is that there are situations with ICE where two TURN relays end up  
talking with each other; in these situations, we don't currently have  
a way to determine the MTU of the last leg of the path. I have some  
ideas on how one might work around these issues, but I personally  
think these issues should be investigated as part of a separate  
document.

- Philip

---

From: Lars Eggert <[email-masked]>
Date: Tue, 14 Apr 2009 17:12:57 +0300

Hi,

I like this text, thanks! (And I cleared.)

Lars