headers
Alfred E. Heggestad | 2 Aug 2008 19:06

Re: Proposed resolutions for TURN open issues

Hi

please see inline for my comments:

Philip Matthews wrote:
> There was an ad-hoc meeting on TURN  on Wednesday, July 31. During this 
> meeting, all the open issues affecting TURN were discussed and proposals 
> for how to resolve them reached. Jonathan and I then held a phone call 
> to discuss and in a couple of cases made minor tweaks. This e-mail 
> documents the proposed resolutions. Please comment if you are not happy 
> with any of these.
> 
>    1.  Detecting in-use channels.  Do we need a way for a client to
>        determine if a channel is currently bound?  Right now, the only
>        way is to try to bind it to an address.
> 
> This issue was prompted by concerns that the client and server might get 
> out-of-sync over which channels were bound. A concrete example of this 
> concern was when a client retransmitted a ChannelBind msg over UDP. If 
> the first transmission generated a failure response, but the second 
> generated a success response, then the client would believe that the 
> channel was not bound, but the server would believe the channel is bound.
> 
> The proposed resolution to this issue is to not add any way for the 
> client to determine which channels are bound, but to add text explicitly 
> saying that a client should abandon an allocation if it receives an 
> error response to a ChannelBind command. The idea is that any mismatch 
> between the client and the server in this area is very serious, and 
> starting over is the best way to recover.
>
(Continue reading)

Permalink | Reply |
headers
Philip Matthews | 8 Aug 2008 22:35
Picon

Re: Proposed resolutions for TURN open issues

Thanks for your comments. Responses inline.
- Philip

On Sat, 2-Aug-08, at 13:06 , Alfred E. Heggestad wrote:
> Hi
>
> please see inline for my comments:
>
>
> Philip Matthews wrote:
>> There was an ad-hoc meeting on TURN  on Wednesday, July 31. During  
>> this meeting, all the open issues affecting TURN were discussed and  
>> proposals for how to resolve them reached. Jonathan and I then held  
>> a phone call to discuss and in a couple of cases made minor tweaks.  
>> This e-mail documents the proposed resolutions. Please comment if  
>> you are not happy with any of these.
>>   1.  Detecting in-use channels.  Do we need a way for a client to
>>       determine if a channel is currently bound?  Right now, the only
>>       way is to try to bind it to an address.
>> This issue was prompted by concerns that the client and server  
>> might get out-of-sync over which channels were bound. A concrete  
>> example of this concern was when a client retransmitted a  
>> ChannelBind msg over UDP. If the first transmission generated a  
>> failure response, but the second generated a success response, then  
>> the client would believe that the channel was not bound, but the  
>> server would believe the channel is bound.
>> The proposed resolution to this issue is to not add any way for the  
>> client to determine which channels are bound, but to add text  
>> explicitly saying that a client should abandon an allocation if it  
>> receives an error response to a ChannelBind command. The idea is
(Continue reading)

Permalink | Reply |
headers
Marc Petit-Huguenin | 9 Aug 2008 02:08
Picon
Favicon

Re: Proposed resolutions for TURN open issues

Philip Matthews wrote:
> Thanks for your comments. Responses inline.
> - Philip
> 

[...]

> 
>>
>>
>>
>>
>>> -- 
>>>   6.  PMTUD for non-preserving allocations.  Some people would like a
>>>       way to do PMTUD even if the allocation is non-preserving, and
>>>       have suggested that a way for the client to indicate to the
>>>       server (in a Send indication) that the DF bit should be set when
>>>       sending to the peer might allow this.
>>> There was hot discussion of this issue at the ad-hoc. Finally, it was
>>> agreed that the mechanism suggested by Cullen would be added to the
>>> TURN specification, to whit:
>>> a) A new attribute would be defined for use in a Send indication. If
>>> this attribute is present, then the server would set the DF bit when
>>> sending the UDP datagram to the peer.
>>
>> 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
(Continue reading)

Permalink | Reply |
headers
Philip Matthews | 9 Aug 2008 03:10
Picon

Re: Proposed resolutions for TURN open issues


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.
(Continue reading)

Permalink | Reply |
headers
Philip Matthews | 15 Aug 2008 20:51
Picon

Re: Proposed resolutions for TURN open issues


On Fri, 8-Aug-08, at 21:10 , Philip Matthews wrote:
>
> 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
(Continue reading)

Permalink | Reply |
headers
Cullen Jennings | 19 Aug 2008 16:11
Picon
Favicon
Gravatar

Re: Proposed resolutions for TURN open issues


On Aug 15, 2008, at 12:51 , Philip Matthews wrote:

>
> On Fri, 8-Aug-08, at 21:10 , Philip Matthews wrote:
> >
> > 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.]
(Continue reading)

Permalink | Reply |
headers
Rémi Denis-Courmont | 19 Aug 2008 16:18
Picon

Re: Proposed resolutions for TURN open issues

On Tuesday 19 August 2008 17:11:23 ext Cullen Jennings, you wrote:
> Uh, what sitituations is it not possible to clear the DF bit?

AFAIK, on a *BSD kernel (including MacOS X), all UDP datagrams have the DF bit 
_not_ set.

--

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
Permalink | Reply |
headers
Rémi Denis-Courmont | 11 Aug 2008 09:08
Picon

Re: Proposed resolutions for TURN open issues

On Saturday 09 August 2008 04:10:58 ext Philip Matthews, you wrote:
> 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?

What happens if SET-DF is *absent* and the OS does not support NOT setting the 
DF bit (from userland)? I recall BSDs, including OSX being in such situation.

--

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
Permalink | Reply |
headers
Cullen Jennings | 11 Aug 2008 03:08
Picon
Favicon
Gravatar

Re: Proposed resolutions for TURN open issues


I prefer the simpler version without the steps 2-4 for a few reasons

1) it is simpler

2) it is what we agreed to in the meeting

3) it is more likely to actually get implemented

4) a client that cases can send a 0 length send request with this to  
see if it gets an error or not as soon as it likes

Cullen <with my individual hat on>

On Aug 8, 2008, at 6:10 PM, 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.
(Continue reading)

Permalink | Reply |
headers
Simon Perreault | 9 Aug 2008 14:59
Picon
Favicon

Re: Proposed resolutions for TURN open issues

On Friday 08 August 2008 21:10:58 Philip Matthews wrote:
> 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.

I prefer this alternative. KISS. Logically, setting the DF bit is not an 
allocation attribute so it looks like a hack to save one round trip. Not a 
good enough reason IMHO.

BTW, instead of SET-DF perhaps DONT-FRAGMENT would be more appropriate.

--

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
Permalink | Reply |
headers
Marc Petit-Huguenin | 9 Aug 2008 14:43
Picon
Favicon

Re: Proposed resolutions for TURN open issues

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
(Continue reading)

Permalink | Reply |
headers
Philip Matthews | 13 Aug 2008 03:56
Picon

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.
>>
(Continue reading)

Permalink | Reply |

Gmane