Subject: [BEHAVE] TURN Issue #4: Port Adjacency

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Dec 2007 17:41:47 -0500

This didn't get covered in the WG meeting but was discussed in the ad-hoc.

TURN allows a client to request an even port, and along with it, ask the 
TURN server to allocate the odd port one higher. However, the spec 
currently has the following confusing words in it:

    As such, it is a request for the server to allocate an even
    port whose next higher port is also available, and furthermore, a
    request for the server to not allocate that one higher port to any
    other request except for one that asks for that port explicitly.  The
    server can honor this request for adjacency at its discretion.  The
    only constraint is that the allocated port has to be even.

This would seem to imply that a server could respond with an OK 
response, allocate the even port, but not even bother with the odd port. 
Thus, when the client tries the odd port, it gets rejected. So the 
client has to try again. This non-deterministic behavior would 
complicate the client.

The options were:

1. ditch the feature
2. make it so that the server MUST allocate the even port and the next 
higher odd port, and if it can't do both, reject the request. After 
allocating both, it holds onto the odd port, waiting for the client to 
request it, for:
     a. some fixed time, say 30s
     b. the duration of the allocation

Folks still wanted this feature since it is used in practice. In the 
interests of avoiding another timer, there was agreement on 2b.

Please comment if you agree (or if you don't) on this conclusion.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

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

---

From: Bob Andreasen <[email-masked]>
Date: Mon, 10 Dec 2007 12:52:21 -0500

Any chance of taking options 1 and 2b -- by making
REQUESTED_PORT_PROPS an optional attribute?  I do understand that this
is needed for many environments -- but it isn't need for all.  Given
that #1 was on the table (even if only for completeness), making it
optional seems like a reasonable change.

-
Bob

---

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 10 Dec 2007 18:37:07 -0800

My experience is that this is often needed in all deployments w/
heterogeneous endpoints.  Of course, a counterargument is that an endpoint
going through a NAT which does not tend to map ports adjacently has no way
of guaranteeing this.

The question is: is there a concern that turn will be used to dodge
implementing 3605?  I suspect that RTCP is generally failing in environments
where the NAT is doing many concurrent allocations.

So, a new turn open issue:

Should adjacent port allocation be in scope for TURN?

-Derek

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 Dec 2007 23:21:07 -0500

The problem with doing both is that the client needs to discover if the 
server supports this option, and if it wanted it, have fallback logic to 
handle the case where the server doesn't support it. It is my preference 
to keep TURN simple by eliminating options, since options tend to 
complicate protocols.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 12 Dec 2007 23:22:49 -0500

Well, the argument has always been that TURN is used in conjunction with 
ICE as the default candidate, and thus gets used when talking to non-ICE 
peers - the same ones that won't have 3605. I can't see folks using TURN 
as an excuse to avoid 3605, since it means you have to actually route 
all your media through the TURN server, and that is much worse than just 
implementing 3605.

So my preference remains #2b.

-Jonathan R.

Derek MacDonald wrote:
> heterogeneous endpoints.  Of course, a counterargument is that an 
> endpoint going through a NAT which does not tend to map ports adjacently 
> has no way of guaranteeing this.
> 
> implementing 3605?  I suspect that RTCP is generally failing in 
> environments where the NAT is doing many concurrent allocations.
> 
> On Dec 10, 2007 9:52 AM, Bob Andreasen <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Dec 2007 14:55:51 +0200

On 2007-12-8, at 0:41, ext Jonathan Rosenberg wrote:
> TURN allows a client to request an even port, and along with it, ask  
> the TURN server to allocate the odd port one higher.

Given that we're about to recommend that end hosts implement port  
randomization and most OSs do this already (draft-ietf-tsvwg-port- 
randomization), this seems to be an anachronism. So ditch it.

(Or does anyone have a convincing use case?)

Lars (as an individual)

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 13 Dec 2007 17:38:05 +0200

Le Saturday 08 December 2007 00:41:47 ext Jonathan Rosenberg, vous avez 
>     only constraint is that the allocated port has to be even.

To restate my preference, I'd rather ditch the feature completely.

First, it puts an extra incentive for people to use TURN as the default 
candidate, which is not necessarily such a great idea.

Second, it conflicts with the way the traditional sockets API allocates port 
number on the server side: it allows you to request "any" available port, or 
one specific port, but "any" available even port. That practically means any 
TURN server implementation would have to reinvent a port allocation schema 
bypassing the OS one, which sounds bad. Futhermore, this is bound to 
introduce problems if the TURN server runs any other service using dynamic 
port numbers as well (FTP data, SOCKS, ...).
Not a show-stopper, but an annoyance anyway.

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Dec 2007 00:07:27 -0500

The use case is communicating between an ICE agent and a non-ICE 
traditional Voip client, like a PSTN gateway. Those endpoints frequently 
implement the old original 1889 and do RTP and RTCP on adjacent ports. 
Since ICE recommends TURN as the default candidate, when communicating 
with these peers, we'd be able to get RTCP. WIthout this feature, RTCP 
will not work.

There are still a LOT of endpoints in real deployment that assume 
RTP/RTCP port adjacency.

-Jonathan R.

Lars Eggert wrote:
> randomization and most OSs do this already 
> (draft-ietf-tsvwg-port-randomization), this seems to be an anachronism. 
> So ditch it.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Dec 2007 00:10:41 -0500

inline:

> candidate, which is not necessarily such a great idea.

Well, hang on, ICE recommends it. I know folks want to use STUN when 
possible but ICE is built on the model that reliability is job #1, and 
using a STUN default candidate is not going to be as reliable as TURN.

> Not a show-stopper, but an annoyance anyway.

RTP/RTCP port adjacency has been implemented all over the place ontop of 
existing socket APIs. Some implementations do their own port allocation. 
Others basically allocate an arbitrary port till they get an even one, 
and then ask for the next higher one. If that fails, start over. Ugly 
but it works. I personally implemented an RTP stack that way back a long 
time ago.

What is your comment on the argument that this is needed to make RTCP 
work with legacy endpoints?

-Jonathan R.