Subject: RE: [BEHAVE] TURN major issues and proposed fixes

From: "Brian Stucker" <[email-masked]>
Date: Sat, 10 Feb 2007 01:24:08 -0600

Comments inline. 

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Wednesday, January 24, 2007 1:25 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: [email-masked]; Rohan Mahy; Rohan Mahy
> Subject: Re: [BEHAVE] TURN major issues and proposed fixes
> 
> Hi Brian,
> 
> Thanks for your comments.  My responses are inline.
> 
> On Jan 22, 2007, at 16:21, Brian Stucker wrote:
> >> -----Original Message-----
> >> From: Rohan Mahy [mailto:[email-masked]]
> >> Sent: Friday, January 19, 2007 10:03 PM
> >> To: [email-masked]
> >> Cc: Rohan Mahy
> >> Subject: [BEHAVE] TURN major issues and proposed fixes
> >>
> >> Hi Folks,
> >>
> >> The following issues have all come up from implementors of 
> TURN and 
> >> are big enough issues that I wanted to get some list 
> feedback before 
> >> incorporating these in a new rev.
> >>
> >> 1. Allocations, Bindings, Permissions, Timeouts, and the Active 
> >> Destination.
> >>
> >> The current text is still a bit fuzzy and inconsistent 
> about what is 
> >> a difference between permission and a binding and what 
> keeps bindings 
> >> open. Also, many implementors have expressed confusion between the 
> >> behavior of an ordinary NAT binding and a "STUN Relay 
> binding", so I 
> >> am proposing we skip the binding terminology in favor of 
> >> "permission".
> >> Much of the following came from consensus at one of the meetings. 
> >> I've come up with the following proposal which fills out a 
> consistent 
> >> set of rules:
> >> - Remove the terminology "binding" altogether inside the 
> TURN server.
> >> Only use "binding" when talking about a "real" NAT (ex:
> >> between the TURN client and the TURN server)
> >
> > Sounds good.
> >
> >> - All requests and indications except for initial 
> Allocation requests 
> >> are sent in the context of a matching valid allocation, otherwise 
> >> they are rejected (requests) or discarded silently (Indications).
> >
> > Sounds good.
> >
> >> - Allocations are explicitly refreshed via subsequent allocation 
> >> requests.  Allocation timeout values are on the order of minutes. 
> >> Send and Data indications do not refresh Allocations. Allocation 
> >> timers are based on the LIFETIME attribute.
> >
> > I'm confused. What's the relation between LIFETIME and 
> > REFRESH-INTERVAL below? If the allocation expires, then the 
> > permissions go with it because the permissions were created 
> in the context of an allocation.
> 
> I expect that the LIFETIME might be on the order of 15 
> minutes, and the REFRESH-INTERVAL for a UDP permission might 
> be on the order of 30 seconds.
> 
> Under the proposal here, you need to send data to the target 
> of each permission at least every 30 seconds to keep the 
> permission alive.  I assume this also is likely to have the 
> side effect of keeping NAT bindings alive as well.  You 
> separately need to send a (re)Allocate Request to the TURN 
> server at least every 15 minutes to refresh the allocation.  
> As you pointed out, if you don't do this, the whole 
> allocation goes away and all the related permissions with it.

Hmm... I still don't see the value of sending a (re)Allocate Request to
the TURN server if there are active permissions for that allocation. Why
should a TURN client have to tell the TURN server twice (effectively)
that it wants a particular permission to remain active: once by
remembering to send data to it every so often, and again by refreshing
the allocation that allows the permission to exist. Just seems like
extra overhead without a clear purpose. What is the problem you're
trying to solve here? 

> 
> >> - Each allocation can have zero or more permissions
> >> - When allocations are destroyed all related permissions 
> are deleted.
> >> - Permissions are only created by Send Indications over UDP and 
> >> Connect Requests over TCP.
> >
> > This means that an offerer would have to generate RTP traffic to an 
> > answerer to get RTP traffic sent back to it. What if I want 
> to setup a 
> > one-way stream to me in which it's inappropriate to 
> generate traffic 
> > in the other direction, only to make the TURN server happy? Why not 
> > let Set Active Destination also create a permission?
> 
> This would be a change from the Applicability, Introduction, 
> and UNSAF considerations as I read them.  There is a lot of 
> text in those sections about how we only create a permission 
> when we have sent data to that target.

Yes, but is it the wrong thing to do? Is there a technical reason to not
allow people to setup one-way (receive-only) RTP sessions that don't
require them to "cheat" and send something to get their data.

> 
> >> - Data sent to a peer (via send Indications and 
> unencapsulated data 
> >> sent to the active destination) by the TURN client refresh the 
> >> relevant permission. Data to one permission does not refresh other 
> >> permissions associated with the same binding.
> >
> > Sounds good.
> >
> >> - The expected timeout interval for all permissions for an 
> allocation 
> >> is conveyed from the server to the client using the 
> REFRESH-INTERVAL 
> >> attribute in an initial successful Allocate Response.
> >
> > How does this relate to LIFETIME (see above)?
> >
> >> - The active destination is changed only with the Set Active 
> >> Destination Request for an allocation. The active destination is 
> >> completely independent of any permissions.
> >
> > There's some text about the Set Active Destination Request 
> creating a 
> > permission in section 9.2 that's been floating about on the list as 
> > being used to allow an originator to tell the TURN server to allow 
> > traffic from that destination. This would make it possible for a 
> > permission to be created without requiring the originator 
> to generate 
> > traffic to the actual intended destination. I think this should be 
> > allowed. Are you proposing changing this?
> 
> can you paste that into this thread please?

Here you go:

http://www1.ietf.org/mail-archive/web/behave/current/msg01896.html

> 
> >> 2. SetActiveDestination should not be limited to existing 
> permissions 
> >> Current text in some places says that the active 
> destination needs to 
> >> be an existing permission. This is actually unnecessary 
> however, and 
> >> loosening this restriction is useful.
> >> Take the case where the TURN client receives a SIP INVITE with an 
> >> offer, and the TURN client wishes to accept the offer. The TURN 
> >> client should be able to set the active destination immediately 
> >> before issuing its first Send request (to this destination). Using 
> >> this order of operations insures that the TURN client receives all 
> >> data traffic unencapsulated. This provides for more consistent 
> >> bandwidth usage in this case.
> >
> > This does not (to me) appear to mesh with some of the points you've 
> > made above.
> 
> Can you be more specific about that?
> This proposed change makes the active destination used by the 
> TURN server only for deciding when to send unwrapped data and 
> to decide how to process unwrapped data it receives.
> You can set the active destination to anything you'd like.  
> IIF traffic is received and there is a permission (because 
> you sent traffic there) it gets wrapped in a Data indication 
> unless it was received from the active destination.
> 
> Also, if you set the active destination, there may be no need 
> to wrap your first bit of outgoing data in a Send request.

Ah. Now I understand your point. I thought your statement contradicted
the notion of letting Set Active Destination create a permission to
receive data from a peer without having to first send data to it through
the TURN server.

> 
> 
> > I thought paragraph 5 on page 19 of the draft made the
> > expectation pretty clear:
> >
> >    If the Set Active Destination request contains a REMOTE-ADDRESS
> >    attribute, the IP address contained within it is added to the
> >    permissions for this allocation, if it was not already present.
> 
> This paragraph is later contradicted a few paragraphs later.  We need 
> to change one of the paragraphs.

Agree.

> 
> >> The proposal is to change the current text to completely
> >> decouple the active destination from any permissions.  A
> >> permission controls whether traffic flows.  The active
> >> destination controls whether traffic flowing over a binding
> >> is encapsulated of not.
> >>
> >> An alternative to this proposal is to create a new permission
> >> if no permission for the active destination exists.  The
> >> problem is that this does not result in sending any data to
> >> the peer (as described in the applicability statement and
> >> UNSAF considerations), it is completely implicit behavior,
> >> and the opposite operation (clearing the active destination)
> >> does not delete permissions.
> >
> > Why not add an operation to explicitly clear the active destination
> > then?
> 
> We can clear the active destination just fine now, its just that that 
> has no effect on permissions.
> 
> What we don't have is a way to explicitly delete a permission.  I 
> proposed a Close Binding Request verb back in Montreal and there was 
> pretty overwhelming reaction to get rid of it.

So, it seems that there's two separate mechanisms at work here:
encapsulation and permission. It would be best if we could control
encapsulation and permissions separately (because the two really have
nothing to do with one another). If permissions were created through an
explicit TURN request (and could be explicitly deleted as well, although
I'm not sure that we really need this unless the REFRESH-INTERVAL is
pretty long) *OR* by sending data to the peer that would make me happy.
Set Active Destination would be used strictly for encapsulation control.

My only concern with this is the number of round-trips involved to
receive data from a peer if the TURN client has nothing to send but
wants to get data. Perhaps a permissions attribute could be created that
could be piggybacked on the Set Active Destination or Allocation
Requests to define the expected permission behavior by the TURN client. 

I'm not trying to turn the TURN server into a general relay, but there
are issues in networks that have relatively slow best-effort signaling
paths during call setup that I want to make sure we're addressing. 

> 
> >> 3. SetActiveDestination changing destinations
> 
> Do you have any comments on proposals 3 or 4?
> 
> thanks,
> -rohan
> 
> >> Currently there are several pages of text devoted to a timer
> >> based state machine that needs to be implemented on both the
> >> server and the client to handle the case of switching the
> >> active destination from one address to another. The problem
> >> is that  over UDP, the client cannot tell which
> >> unencapsulated data is from the old active destination vs.
> >> the new active destination.
> >>
> >> However, requiring timers and a state machine on the server
> >> is a significant implementation burden which provides no
> >> benefit for the TURN server or its administrative domain.
> >>
> >> The proposal is to put this problem completely into the hands
> >> of the client.  Some clients may never wish to change the
> >> active destination for example and will have no need to
> >> implement anything special.
> >> Those clients that want to change the active destination over
> >> UDP are required to clear the active destination, wait for an
> >> appropriate interval (5 seconds is suggested), then set the
> >> active destination to the new address.
> >>
> >> Specific proposed text for items 2 and 3 and also delete 
> the TIMER-VAL
> >> attribute:
> >>
> >>
[snip proposed text]

Sounds good. The client is really in the best position to know when it's
likely to be 'safe' to set a new Active Destination anyhow. The TURN
server has no idea what the expected rate of arrival of data is for a
particular application at any given time so leaving it in the hands of
the client to figure out seems appropriate. Wonder what applications
that get a 439 to a SAD request do today? Close the connection, or just
ignore it and get encapsulated data from that point onward (which could
really screw up their rendering as the QoS settings they probably setup
the session with wouldn't account for continuously encapsulated data).

> >> 4. Opening TCP permissions
> >>
> >> Currently TCP to TCP traffic between TURN servers requires
> >> the TURN servers to implement simultaneous open.
> >>
> >> SYN ->
> >> <- SYN
> >> SYN-ACK ->
> >> <- ACK
> >>
> >> Option A is to leave this as is and to clarify this
> >> non-obvious implication to implementors (you cannot receive
> >> an incoming connection unless you first try to open one with
> >> the Connect request.  Option B is to include an explicit Open
> >> Permission Request to create a specific permission for the
> >> TURN server to receive a TCP SYN from one specific IP address
> >> and port number.
> >>
> >> I will implement Option A unless there is strong desire on
> >> the list to do something else.

How prevalent is support for simultaneous open in other settings?

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