19 Aug 2008 16:11
Re: Proposed resolutions for TURN open issues
Cullen Jennings <fluffy <at> cisco.com>
2008-08-19 14:11:23 GMT
2008-08-19 14:11:23 GMT
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?