Re: Proposed resolutions for TURN open issues

On Sat, 9-Aug-08, at 08:43 , Marc Petit-Huguenin wrote:
> Philip Matthews wrote:
>>
>> On Fri, 8-Aug-08, at 20:08 , Marc Petit-Huguenin wrote:
>>>>> if this is really required, I would suggest moving the attribute/ 
>>>>> bit
>>>>> to the allocate request instead. setting the DF-bit is normally  
>>>>> done
>>>>> when opening a socket (setsockopt IP_MTU_DISCOVER)
>>>>
>>>> Cullen Jennings, who was the person who pushed strongly for this
>>>> feature, would like to set the DF bit on some packets but not  
>>>> others.
>>>>
>>>
>>> I also support this feature.
>>
>> After thinking about this feature a bit, and taking Alfred's comment
>> into account, it seems to me that there might be a platform where  
>> this
>> feature cannot be implemented with an unprivileged user-space
>> implementation. For example, a quick web search on how to do this for
>> MacOS seemed to indicate that there might be a problem. Without  
>> getting
>> into a discussion of which platforms can and cannot do it, it seems  
>> wise
>> to me to treat this as a feature which an implementation might not be
>> willing or able to support.
>>
>> Hence I have the following proposal for how to define this feature:
>>
>> 1) TURN would define a new attribute, call it SET-DF. The attribute
>> would have a value length of 0. The attribute would be in the
>> comprehension-required range.
>>
>> 2) A client MAY include the SET-DF option in an Allocate request.
>> Including this option means that the client is requesting an  
>> allocation
>> that supports this feature.
>>
>> 3) If the server cannot create an allocation that supports the  
>> feature,
>> the Allocate request is rejected with a 420 Unknown Attributes and  
>> the
>> UNKNOWN-ATTRIBUTES attribute would list this attribute. [Note that in
>> this case, the SET-DF attribute may not really be unknown, but simply
>> cannot be supported.]
>>
>> 4) If the server accepts the Allocate request, then the client MAY  
>> use
>> the SET-DF attribute in a Send request or a Send indication. If the
>> attribute is included, then the server sets the DF bit in the
>> corresponding UDP datagram towards the peer. If the attribute is not
>> included, the server does not set the DF bit.
>>
>> 5) Using the SET-DF attribute in a Send request or Send indication  
>> on an
>> allocation that does not support it causes the Send request to be
>> rejected and the Send indication to be silently ignored (= standard
>> behavior for a unknown comprehension-required attribute).
>>
>> An alternative to this would be to drop points (2) and (3), and say  
>> that
>> the server rejects a Send request if it cannot     support the SET-DF
>> attribute. This is a bit simpler, but delays the point at which the
>> client discovers that the attribute is not supported.
>>
>> Comments?
>
> Here's an alternate proposal:
>
> - Use bit 3 in REQUESTED-PROPS for the support of the DF bit.  This is
> consistent with the usage of REQUESTED-PROPS to query/request  
> allocation
> properties.

Perhaps I didn't make things clear in an earlier message.
Jonathan and I had a phone discussion about REQUESTED-PROPS. He argued  
(as Simon Perreault also argued) that using REQUESTED-PROPS as a set  
of bit flags meant that TURN had two different ways to define  
extensions (one by defining a new attribute and one using REQUESTED- 
PROPS) and he did not like this at all. He pushed very strongly for  
removing this use of REQUESTED-PROPS. Eventually, I agreed reluctantly  
to go along with this and remove this use REQUESTED-PROPS as part of  
the removal of Preserving allocations.
If the working group disagrees, we can put back in the use of  
REQUESTED-PROPS as a way to define new features, but for now it is out.

>
>
> - Redefine the reserved first 8 bits of PEER-ADDRESS to use bit 7 to
> carry the DF bit.  It can then be used in a Send indication/ 
> transaction
> and even in a ChannelBind transaction if one wants DF bit set in all
> packets.

We could do this (I had originally proposed something like this some  
time ago), but others objected saying that using a new attribute was  
cleaner and saving bytes was not important since the SET-DF attribute  
would only be used on certain special packets. Hence my proposal.

- Philip