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.]
> >
> > 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?
>
>
> I have seen two requests for the simpler alternative described in the
> last paragraph, and no requests for my more complex proposal. Since I
> really don't care either way, I will go with the simpler proposal.
>
>
>
> On Mon, 11-Aug-08, at 03:08 , Rémi Denis-Courmont wrote:
> >
> > 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.
>
>
> The original request was for a way to do some sort of Path MTU
> discovery when the server operated entirely in userland. Always
> setting the DF bit doesn't interfere with this, it just means the the
> Path MTU is smaller than it might otherwise be.
>
> To be precise, if the SET-DF (or DONT-FRAGMENT, as Simon suggests)
> attribute is not present, then I propose the text say that the server
> SHOULD clear the DF bit, with a note that clearing the DF bit may not
> be possible in some situations.
>
> - Philip
>
>
>

Uh, what sitituations is it not possible to clear the DF bit?