Subject: [BEHAVE] TURN issue: Exceeding PMTU size

From: Philip Matthews <[email-masked]>
Date: Thu, 20 Dec 2007 15:14:52 -0500

Using TURN increases the size of an application's data packet by  
either 4 bytes (when using the channel number header) or by  
approximately 36 bytes (when using Send or Data Indication) on the  
path between the client and the server. This extra overhead has the  
potential of bumping the size of an application's data packet to a  
value above the PMTU on the path between the client and the server,  
thus resulting in IP fragmentation. And IP fragmentation is known to  
cause problems with some NATs.

The question is: Does TURN need to handle this problem, or do we just  
say that it is the application's problem?

In my opinion, this is the application's problem. According draft- 
ietf-tsvwg-udp-guidelines, applications that use UDP should either  
use Path MTU Discovery, or restrict themselves to packets of size 576  
bytes or less (over IPv4). Applications that do the former will  
discover the true Path MTU (including the TURN overhead), while  
applications doing the latter will be safe in most cases, since most  
Path MTUs are much larger than 576.

Comments?

- Philip

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Dec 2007 15:43:24 -0800

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]] 
> Sent: Thursday, December 20, 2007 12:15 PM
> To: Behave WG; Lars Eggert
> Subject: [BEHAVE] TURN issue: Exceeding PMTU size
> 

I have some comments as an individual:

1. Imagine a situation where where endpoint-a is using its TURN server, and
endpoint-b is not using a TURN server.  This would occur if endpoint-b is
behind a BEHAVE-compliant NAT, or if endpoint-b isn't behind a NAT, or
endpoint-b doesn't support ICE.

Here is a digram:

   +------+
   | TURN +<-------------------+
   +---+--+                    |
       |                       |
       V                       |
    +--+--+                    |
    | NAT |                    |
    +--+--+                    |
       |                       |
       V                       |
 +-----+------+          +-----+------+
 | endpoint-a |          + endpoint-b |
 +------------+          +------------+

Let's imagine both endpoint-a and endpoint-b are able to do UDP path MTU
discovery.  endpoint-b will learn the MTU between itself and the TURN server.
Both the TURN server and endpoint-a are aware of the TURN shim (4 bytes or 36
bytes) between them, and can reduce their MTU accordingly.

However, what is missing is that the TURN server needs to inform endpoint-a of
this TURN shim (4 bytes / 36 bytes).  If the TURN server receives a UDP packet
that is too large, it would need to respond with an ICMP 'too big' error to
endpoint-b, so that endpoint-b has an opportunity to reduce its path MTU to
the TURN server.

2. Worse is when the path between the TURN server and endpoint-a has a small
MTU.  Let's assume for a moment that it is really small, like 576 bytes, and
the MTU between endpoint-b and the TURN server is a gigabit ethernet network
with a 9000 byte MTU.  If you don't like 9000 or don't like gigabit ethernet,
please substitute the value 1500; the problem is the same.

   +------+
   | TURN +<-------------------+
   +---+--+                    |
       |                       |
       | MTU=576               | MTU=9000
       |                       |
       V                       |
 +-----+------+          +-----+------+
 | endpoint-a |          + endpoint-b |
 +------------+          +------------+

In this case, following my suggestion above, when the TURN server receives a
9000-byte packet, it will respond with an ICMP 'too big' message suggesting
the MTU is 9000-36=8964 bytes.  However, that is clearly not correct:  the
TURN server needs to continue refusing large datagrams until endpoint-b sends
576-byte datagrams (or smaller).

To do this, the TURN server needs to learn the path MTU with endpoint-a, so
that the TURN server can intelligently accept only 576-byte (or smaller)
datagrams from endpoint-b.

3. are there any applications that perform UDP Path MTU Discovery?  I am not
aware of any, but there must be some because we talk about it a lot in the
IETF.  I checked RFC3530 (NFSv4) and all of draft-ietf-nfsv4*, but nothing
mentions "MTU".  A pointer to such a protocol would be helpful.

3a. When I read Section 10.3 and Section 5.2 of RFC4821, it seems doing
RFC4821 with RTP would be difficult-to-impossible.  Some additional discussion
of this -- outside of the context of TURN -- might be useful.  This is not a
problem with TURN, per se, but rather a problem of how we would use those
techniques with RTP.  Perhaps something to bring up in AVT?

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 21 Dec 2007 10:30:29 +0200

> say that it is the application's problem?

FYI, SOCKS UDP uses some *application-layer* fragmentation to handle this.
I am not advocating this - just pointing it out.

> Path MTUs are much larger than 576.

Agreed.

What if the path MTU is yet smaller beyond the TURN server than it is between 
the TURN server and the TURN client? TURN does not relay ICMP... even then 
PTMU through NAT is fairly unreliable.

To me this sounds like any application that would have practical problems with 
this is *broken*. If you need to send dangerously large messages, use TCP.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Fri, 21 Dec 2007 08:31:06 -0500

First, to be clear, by "Path MTU Discovery" I was assuming  
"Packetization Layer Path MTU Discovery" (RFC 4821), and not classic  
Path MTU Discovery which relies on ICMP. This was because TURN  
currently does not relay ICMP messages.

Your message seems to assume that endpoints would do Path MTU  
Discovery to the TURN server. I was assuming that endpoints would do  
Path MTU Discovery to each other. That is, they would send  
progressively larger probe packets to each other to determine the MTU  
of the entire path between the TURN client and the remote peer.

However, your question about which applications actually do this is a  
good one. I don't know of any.

- Philip

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 21 Dec 2007 11:22:54 -0800

> currently does not relay ICMP messages.

ietf-tsvwg-udp-guidelines refers to both styles.

> Path MTU Discovery to each other.

But they communicate through the TURN server.  For RFC4821-style
PMTUD to be effective, the TURN server needs to do something
(see below for what I think it needs to do).

> That is, they would send  

So, you are expecting the clients to perform RFC4821-style UDP
PMTUD.  That would need to be clarified in the TURN specification
because you can't rely on ietf-tsvwg-udp-guidelines for that
clarification.

Additionally, for RFC4821 to work across the TURN server, the 
TURN server would need to preserve the DF bit from the 
incoming packet.

> However, your question about which applications actually do 
> this is a good one. I don't know of any.

In another message I was told that Cisco's L2TP does UDP PMTUD.  
Here is a brief discussion,
http://www.cisco.com/warp/public/471/l2tp_mtu_tuning.html#automatic

-d

> > this TURN shim (4 bytes / 36 bytes).  If the TURN server 
> receives a  
> > UDP packet
> > with a 9000 byte MTU.  If you don't like 9000 or don't like 
> gigabit  
> > ethernet,
> > 3. are there any applications that perform UDP Path MTU 
> Discovery?   
> > I am not
> > aware of any, but there must be some because we talk about 
> it a lot  
> > in the
> > RFC4821 with RTP would be difficult-to-impossible.  Some 
> additional  
> > discussion
> > of this -- outside of the context of TURN -- might be 
> useful.  This  
> > is not a
> > problem with TURN, per se, but rather a problem of how we 
> would use  
> > those

---

From: Philip Matthews <[email-masked]>
Date: Fri, 21 Dec 2007 17:08:09 -0500

So my modified proposal is:

It is the application's job to ensure that its data packets with not  
exceed the Path MTU (including the MTU on portion of the path between  
the client and the TURN server). This can be done by either (a)  
implementing "Packetization Layer Path MTU Discovery" (RFC 4821), or  
(b) by restricting themselves to packets of size 576 or less (over  
IPv4).

To support RFC 4821, a TURN server must either set or preserve the DF  
bit when relaying packets.

- Philip