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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Feb 2008 16:18:12 +0100

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.

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

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.

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.

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.

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

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