Subject: Re: [BEHAVE] TURN 07: Header bits (Section 11)

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 3 Mar 2008 09:59:05 +0200

Hello,

Le Friday 29 February 2008 17:18:12 ext Magnus Westerlund, vous avez écrit :
> F. Section 11.2: What about IPv6 behavior?
> If I understand this correctly, this specification does allow relaying
> IPv4 to IPv4 and IPv6 to IPv6, but not either of IPv4 to IPv6 nor IPv6
> to IPv4 which is what draft-ietf-behave-turn-ipv6 is for.

I believe earlier drafts specified relaying to IPv4 by default regardless of 
the version on the client side. That may be an issue if protocol translators 
resurface (nevermind that some people probably still use old ones). If 
turn-ipv6 is mandatory to support, then client could simply always request a 
protocol family explicitly. But otherwise, I feel a little better 
with "always-IPv4" by default than "always-the-same-version" default.

(Of course, TURN clients behind protocol translator would need to handle 
peer-derived addresses from different protocol version in any case)

> G. Section 11, More IPv6.
>
> What about the IPv6 Flow label in forwarding? Taking a look at RFC 3697
> is recommened to ensure that TURN will fulfil the requirements.

I think I hinted at this one a while ago. Unfortunately, the FL is not nearly 
as easy as the DSCP - it is a "per-flow" value, NOT a per-packet value. This 
is reflected in the flow label API - on OSes that do have such an API anyway.

My understanding is, the FL should probably be tied to channels rather than 
copied from either side of the TURN relay, but I may be wrong. I suspect FL 
are not used by anyone for anything at the moment, hence it is a bit 
difficult to get a significant idea how to really implement them in TURN.

> J. Proposal instead of bad compromise:
> I think we mostly know what a good TURN relay should do with the IP
> header fields. We also know what they can't do from user land. Why don't
> we define two behavior profiles. One for user land implementations that
> clearly explains what they loose. Then one for full relaying that does
> everything right. That way we can even include a "port req" attribute
> for requesting "full relay". Because if you are implementing a TURN
> server within the operating system you can set all the fields in the
> right way. I do want to indicate what the right thing to do would be,
> well knowing that it will mostly not be used. But there clearly are some
> deployments that could have advantage of "full relay". For full relay I
> would also like to look into what can be done on getting the ICMP
> relaying working.

Some things will be do-able in userland on some OSes and not on other OSes. On 
Linux, you can set the DSCP, ECN and TTL bits, and you have decent control on 
the fragmentation mechanism used. Still, I am not sure we will be able to do 
all the stuff that a "full relay" ought to do.

-- 
Rémi Denis-Courmont
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Mon, 3 Mar 2008 10:54:19 -0500

Just to let people know that Magnus, Lars, Jonathan and I discussed  
this issue today and came up with a proposal whereby the TURN  
document would specify 'proper' UDP-to-UDP forwarding which preserves  
most bits in the IP header. If a TURN server cannot provide this, or  
if the TURN server is doing TCP-to-UDP forwarding, then the document  
would state that this is suitable only for certain types of  
applications (e.g., applications that use only small packets).

Look for more details on this once I get a chance to write this up in  
the next few days.

- Philip

On Fri, 29-Feb-08, at 10:18 , Magnus Westerlund wrote:

> Hi,
>
> I have now reviewed what you have written in section 11 and have the
> following comments and observations:
>
> A. Section 11.1, last paragraph on page 32:
> Why is this paragraph here? I find it very strange. If you can read it
> sometimes you should be able to read it all the times. Also I think
> allowing something like this for efficiency reasons is the wrong  
> reason.
> If there exist other reasons then that may make more sense.
>
> B. Section 11.1: It is missing what behavior you should have if you
> can't read the DSCP field. Defaulting to best effort seems to be the
> least harmful you can do.
>
> C. Section 11.2, first paragraph:
>     When the client sends a Data indication or ChannelData message  
> to the
>     server using UDP IPv4, it SHOULD NOT set the DF (Don't  
> Fragment) bit
>     unless the application explicitly requests the bit to be set.
>
> I don't understand the motivation behind this. I the transport from  
> TURN
> client to server any fragmentation that occur will trigger an ICMP
> towards the TURN client, that at least has no additional issues  
> compared
> to non-related session to deal with this ICMP message. So why is this
> recommended?
>
> D. Section 11.2, Third paragraph:
>     When using TCP or TLS over TCP, the client and the server MAY  
> let the
>     setting of the DF bit be determined by the TCP/IP stack.
>
> I think this MAY should be changed to SHOULD. There are no reason for
> the TURN server to interfere with the TCP connection and its selection
> of the TCP segment size which after all is what has the most  
> relation to
> how large TCP packets are generated.
>
> E. Section 11.2, Second paragraph:
>     When the server sends a UDP datagram to a peer over IPv4, or when
>     sends a Data indication or a ChannelData message to the client  
> using
>     UDP over IPv4, the server SHOULD NOT set the DF bit.
>
> I agree that this is the right choice unless one actually are going to
> start generate ICMP messages in the relay. However, I think that  
> one can
> point out that this is relying on the IPv4 fragmentation mechanism and
> affects loss probability, especially considering that NAT's capability
> to forward them.
>
> to IPv4 which is what draft-ietf-behave-turn-ipv6 is for. I am missing
> how an IPv6 is going to deal with the fragmentation issue. That as any
> fragmentation needs to happen on the outgoing interface of the TURN
> server for traffic going to the TURN client.
>
> H. Section 11.3:
>     The server SHOULD NOT preserve the ECN (Explicit Congestion
>     Notification) field, and MAY preserve thee TTL (Time-To-Live)  
> fields
>     when relaying application data.
>
> It is not that simple as not preserving the ECN field. One actually  
> have
> to mandate that the forwarded packets have the ECN field set to non- 
> ECN
> capable. Otherwise you are indicating that you are capable but not
> listing to the information. That is not acceptable. In fact you  
> have to
> to mandate that TURN clients (unless using TCP) SHALL NOT indicate  
> that
> they are ECN capable. Also the Peers should if they now that they are
> being relayed by TURN not use ECN for UDP/IP.
>
> I. Section 11.4: I am missing the obvious recommendation that
> application that now that they are using TURN in the communication  
> take
> some worst case figures into account when generating the packets. And
> those worst case figures should be shown how to calculate in this  
> section.
>
> Cheers
> Magnus Westerlund
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
>