Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit

From: Philip Matthews <[email-masked]>
Date: Thu, 3 Apr 2008 11:39:52 -0400

Just a reminder that I am still interested in getting feedback on  
these options. So far, I have only gotten one response. Not doing any  
of these is also an option, so feel free to say "I am not interested  
in this idea".
- Philip

On Thu, 20-Mar-08, at 17:15 , Philip Matthews wrote:
> 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
>
>
>
>
> On Wed, 12-Mar-08, at 10:43 , Philip Matthews wrote:
>> 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
>>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 4 Apr 2008 07:33:26 +0300

> of these is also an option, so feel free to say "I am not interested

I am fine with the proposal, but I am confused as to whether/how this is 
supposed to solve the "unprivileged" server problem.

I know Linux supports both RFC1191 and RFC4821 path MTU discovery (look for 
IP_MTU_DISCOVER at ip(7)) without privileges, but that seemed like the 
exception rather than the norm.

-- 
Rémi Denis-Courmont

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 00:56:25 -0400

I am (probably predictably) for the KISS principle, where the last S is for Server, so I would prefer option 4: not interested.

-hadriel "PITA" kaplan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Philip Matthews
> Sent: Thursday, April 03, 2008 11:40 AM
> To: Behave WG
> Subject: Re: [BEHAVE] TURN: Cullen's suggestion for setting the DF bit
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Apr 2008 08:16:14 -0700

I'd like to discuss the implications of doing nothing on the call  
today if we can.

On Apr 3, 2008, at 9:56 PM, Hadriel Kaplan wrote:
>
> I am (probably predictably) for the KISS principle, where the last S  
> is for Server, so I would prefer option 4: not interested.
>
> -hadriel "PITA" kaplan
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Apr 2008 11:21:17 -0400

Yes, I'm sure we could do nothing on the call today, without any implications.
;)

> From: Cullen Jennings [mailto:[email-masked]]
>