Subject: [BEHAVE] TURN: Magnus's ICMP proposal

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Feb 2009 16:15:34 -0500

In his message to the mailing list on Jan 19, Magnus proposed to add  
the following to the _preferred_ fragmentation behavior:

If the server goes to send a packet with the DF bit set, either  
because it was copied from the incoming packet (when this is possible)  
or because the incoming packet included the DONT-FRAGMENT attribute,  
and if the outgoing link's MTU will not permit the packet to be  
transmitted without fragmentation, then the server sends an ICMP  
message (Type=3, Code=4 (Fragmentation needed and DF set)) back  
towards the sender of the incoming packet.

Note that Magnus proposes to add this only to the preferred behavior  
-- the alternate behavior would not include this.

This preferred behavior would most likely require OS support -- I  
don't know of any OSes that allow applications to send ICMP messages.

Here are my thoughts on this proposal:
This proposes that the server generate an ICMP message when the  
outgoing packet is too large, but does not propose that the server  
relay ICMP messages.  However, in order for the client to use an ICMP- 
based Path MTU Discovery algorithm, I think the server would have to  
do both.

Consider a client that uses an ICMP-based Path MTU Discovery  
algorithm. If the client uses a server that does NOT do this proposal,  
then the client can only discover the MTU along the path to the  
server. If the client uses a server that DOES do this proposal, then  
the client can discover the MTU along the path to the server, plus the  
server's outgoing link. However, in neither case can the client  
discover the MTU along the rest of the path.

By contrast, a client that uses a Path MTU Discovery algorithm that is  
based on packet loss can detect the MTU along the entire path to the  
peer (by using the DONT-FRAGMENT attribute). Furthermore, that  
algorithm will also work through NATs that filter out ICMP messages --  
recall that the client is using TURN in the first place because it is  
behind a "nasty" NAT, and I am speculating that "nasty" NATs often  
don't relay ICMP message.

(Cullen: Do you have any stats on the percentage of symmetric NATs  
that relay ICMP messages?)

For these reasons, I am wondering how useful this proposal would be.

Does anyone else have any comments or insights?

- Philip

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 5 Feb 2009 10:29:13 +0200

> don't know of any OSes that allow applications to send ICMP messages.

As long as the source address of the outer IP header of the ICMP message 
belongs to the TURN server... Windows can do this, or at least it did at some 
point. Virtually all BSD/POSIX-based system can; this requires "root", but no 
kernel changes.

This will be a problem for some consumer embedded operating systems. But I 
think these would only have TURN clients, rather than TURN servers anyway.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

---

From: Philip Matthews <[email-masked]>
Date: Sun, 22 Feb 2009 13:56:59 -0500

In private e-mail exchanges, Magnus and I agreed that there didn't  
seem to be any WG support for this, so the proposal to add ICMP  
relaying to TURN has been dropped.

- Philip

On Wed, 4-Feb-09, at 16:15 , Philip Matthews wrote:

> because it was copied from the incoming packet (when this is  
> possible) or because the incoming packet included the DONT-FRAGMENT  
> attribute, and if the outgoing link's MTU will not permit the packet  
> to be transmitted without fragmentation, then the server sends an  
> ICMP message (Type=3, Code=4 (Fragmentation needed and DF set)) back  
> relay ICMP messages.  However, in order for the client to use an  
> ICMP-based Path MTU Discovery algorithm, I think the server would  
> have to do both.
>
> algorithm. If the client uses a server that does NOT do this  
> proposal, then the client can only discover the MTU along the path  
> to the server. If the client uses a server that DOES do this  
> proposal, then the client can discover the MTU along the path to the  
> server, plus the server's outgoing link. However, in neither case  
> can the client discover the MTU along the rest of the path.
>
> By contrast, a client that uses a Path MTU Discovery algorithm that  
> is based on packet loss can detect the MTU along the entire path to  
> the peer (by using the DONT-FRAGMENT attribute). Furthermore, that  
> algorithm will also work through NATs that filter out ICMP messages  
> -- recall that the client is using TURN in the first place because  
> it is behind a "nasty" NAT, and I am speculating that "nasty" NATs  
> often don't relay ICMP message.
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>