Subject: [BEHAVE] TURN and the IP header fields

From: Philip Matthews <[email-masked]>
Date: Wed, 12 Mar 2008 10:43:07 -0400

Below is a new proposal for how to handle the IP header fields in  
TURN. This proposal was developed in conjunction with Magnus, Lars,  
and Jonathan. I will be discussing this proposal in the BEHAVE  
meeting on Thursday.

- Philip

A UDP allocation is "fully compliant with the TURN IP header  
requirements" if the TURN server sets the fields in the outgoing IP  
header as follows. [Note: Need a better term; suggestions welcome.]

For IPv4:
* The TTL field is set to (incoming TTL - 1).
* The ECN field is set to the incoming ECN field UNLESS the server is  
doing Active Queue Management, the incoming ECN field is 01 or 10,  
and the server wishes to indicate that congestion has been  
experienced, in which case it sets the outgoing ECN field to 11.
* The DSCP field is set to the incoming DSCP UNLESS the server,  
though configuration or other means, believes that a different  
setting is more appropriate.
* Various fragmentation fields (identification, fragment offset, last/ 
more fragments) are set as appropriate for a packet originated by the  
server. [Since the incoming UDP datagram must be re-assembled before  
it can be processed].
* The DF field is set to the incoming DF field.
* The options are empty (i.e., not copied).

For IPv6:
* The Flow Label field is set to the incoming Flow Label field
* The treatment of IPv6 extension headers is TBD.

In addition, a "fully compliant" implementation will relay ICMP  
messages between the peer and client.

A UDP allocation is only "partly compliant" if it does not set one or  
more of the fields as indicated above, or does not relay ICMP messages.

Where possible, a "partly compliant" UDP allocation should set each  
field in the outgoing IP header as described above. Where a specific  
field cannot be set as described above, it SHOULD be set as described  
below.

For IPv4:
* ECN field: set to 00 (ECN not supported).
* DSCP field: set to best effort
* DF field: set to fragmentation allowed

For IPv6:
  TBD

A client SHOULD set the fields in the IP header as directed by the  
local application. If no direction is received, then the fields are  
set as described under the "partly compliant" description above.

Bit 8 (currently unused) in the REQUESTED-PROPS attribute is  
redefined. If this bit is set to 1, then the client is requesting  
that the allocation be fully compliant with the TURN IP header  
requirements. If the server cannot provide an allocation that is  
fully compliant, then the server MUST reject the allocation request.  
It is a "Bad Request" error to set this bit when requesting a non-UDP  
allocation.

When should a client request a fully-compliant allocation?
* When the client wishes to use ECN or a specific DSCP along the  
entire path, OR
* When the client wishes to determine the precise Path MTU (using  
Packetization Layer PMTUD).
In general, a client can use a partly-compliant allocation over IPv4  
if the application is happy with best effort service, does not need  
ECN, and sends only small packets (i.e., less than 576 - <max TURN  
overhead of 32 bytes>). If the application sends larger packets, then  
the packets may get fragmented along the way. This may result in the  
packets being dropped along the path; for example, if fragments are  
delivered out-of-order to certain NATs that do not handle out-of- 
order fragments properly. If the client uses the Packetization Layer  
PMTUD algorithm, then it may not discover the true path MTU, since  
the server may not set the DF bit. In these cases, it will instead  
discover the maximum packet size that will be delivered successfully  
to the peer.
Some clients and applications that send larger packets may be able to  
operate successfully in these situations. Others may not, and thus  
require a fully-compliant allocation.
[Any other suggestions for what to say here??]

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

---

From: Philip Matthews <[email-masked]>
Date: Thu, 20 Mar 2008 17:15:03 -0400

The proposal described in my e-mail message of 12 March (see the  
bottom of this message) was discussed in the BEHAVE session to mostly  
favorable reception. However, Cullen suggested a modification that I  
would like to get input on.

At presently envisioned, in a partly-compliant allocation, if the  
server cannot read the value of the incoming DF bit, then it SHOULD  
clear the DF bit on the outgoing packet. This increases the chances  
that a large packet will be successfully delivered to the peer (or  
the client). However, this also breaks Path MTU Discovery, which  
requires the DF bit to be set.

Cullen is interested in trying to make Path MTU Discovery work even  
for partly-compliant allocations. Here are a couple of options for  
doing this:

1) [Cullen's proposal] Add a way for the client to indicate, on a per- 
packet basis, that the server should set the DF bit when forwarding  
the user data to the peer.
This would apply ONLY to Send indications, which would include a bit  
that specifies the setting of the DF bit. This bit could either be  
contained in a new attribute, or could be one of the 8 currently  
unused bits in the PEER-ADDRESS attribute.

2) Add a way for the client to indicate that the server should set  
the DF bit on ALL packets relayed by the server for this allocation.
This might be done when the allocation is created, using a bit in the  
REQUESTED-PROPS attribute.

3) Similar to option (2), but settable on a per-peer basis via some  
new to-be-defined transaction.

Option (1) allows the setting on a per-packet basis, but only in the  
client-->peer direction. Thus the peer could not do Path MTU Discovery.

Option (2) allows the peer to do Path MTU Discovery as well, but  
reduces somewhat the chances of a large packet getting through if the  
peer chooses not do PMTUD.

Option (3) sets the DF bit on a per-peer basis, which might be useful  
if some peers do PMTUD and others do not. However, it is the most  
complex to specify, since it requires a new transaction type.

What do people think of either of these options? Is anyone besides  
Cullen interested in this question?

Personally, I am leaning slightly towards (2), but have no strong  
option. If no one but Cullen cares, then I will probably just drop  
this idea entirely.

- Philip

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Mar 2008 14:28:01 +0100

> Cullen interested in this question?

Yes

> option. If no one but Cullen cares, then I will probably just drop  

I think this is a better way than what has previously been considered.

I think option 2 is fine as if you are implementing PMTUD you know 
better than to send larger amount of data using a non confirmed PMTU.

With his individual hat on.

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