Subject: [Ietf-behave] TURN Issue #11: Return of odd/even RTP/RTCP

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 6 Jul 2006 05:44:02 -0700 (PDT)

Hello again,

I see that the odd/even allocation "feature" was re-introduced into the TURN 
draft as it switched to the BEHAVE wg.

I understand people want to be interoperable (in this case with very old RTCP 
implementations), but there are some big problems with the whole odd/even 
ports thing.

First, that does really not fit at all within the BSD socket API, which 
virtually every body uses nowadays; you have no way to request a odd port 
(it's either one particular port though it might be in use by another agent, 
or any available port). The idea of linking the RTCP port to the RTP port is 
OK when sending multicast (where there is no port allocation from the socket 
API), but it's quite disturbing when doing unicast, regardless of the NAT 
traversal issue (and hence even with IPv6).

Secondly, introducing support for this into TURN (besides extra complexity) 
means people will have to use TURN *always* if they are behind a NAT. It is 
my understanding that we want UAs to limit usage of TURN to when there is 
really no other options (as determined via ICE). Yet, there is obviously no 
way to support a odd/even port tuple from one's NAT, meaning the only way to 
get it to work are UPnP and TURN. If one stick to relaying-less STUN, that 
does not work anyhow, so why implement it in TURN at all?

Ultimately, there is no way to be 100% compatible with old NAT-unfriendly UAs 
(asymmetric RTP UA being another case of backward compatibility breakage). 
Besides, RTCP should not be absolutely required for RTP to basically work in 
most real-life cases.

IMHO, the extra complexity of implementing this into TURN implementations, the 
fact that it incites blind use of TURN regardless of otherwise better NAT 
traversal solutions, and the lack of simple way to determine when it is 
actually needed pretty much outweigh the little benefit provided.

-- 
Rémi Denis-Courmont <Remi.Denis-Courmont@xxxxxxxxx>

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 11 Jul 2006 07:36:50 -0700 (PDT)

Rémi,

TURN includes odd/even port conventions because there is a large
community that wants to be able to communicate with hosts that still
use the odd/even convention.  We have consensus from the previous
meeting to do this.
What are the consequences for your UA?
- You don't have to allocate your own ports using the old convention
- You have the choice to ask or not to ask the TURN server for ports
using the convention
- You can tell if the peer doesn't need the convention if it has an
a=rtcp attribute.
What are the consequences for your TURN server?
- You need to do a small amount of additional work to allocate ports
using the convention when the TURN client asks.  This number will be
small and will get smaller and smaller over time.
- You need to manage your port number space in TURN.
thanks,
-rohan

On 7/6/06, Rémi Denis-Courmont <Remi.Denis-Courmont@xxxxxxxxx> wrote:
        Hello again,

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 12 Jul 2006 02:38:35 -0700 (PDT)

> - You need to manage your port number space in TURN.

That's unfortunately not the only consequence. The more worrysome (to me) side 
effect is that we end up with an incentive for UAs behind even very friendly 
(e.g. full cone) NATs to use TURN regardless of the availability of 
connectivity mechanisms that would be less costly to maintain for network 
operators. Indeed, by *mandating* that TURN servers support this feature, we 
break the idea that TURN is the last/worst resort for UDP connectivity, by 
making it somehow "better" than UDP hole punching, in the sense that TURN 
will provide even/odd port preservation, and hence:
1/ save UAs from the extra burden of implementing RFC 3605.
2/ provide compatibility with RFC 3605-unaware UAs.

Sure if people wants to use TURN outside ICE or ICE-like mechanisms, this 
makes sense, and I'm perfectly fine with this feature. But in the ICE use 
case, that seems very wrong: you need RFC 3605 with ICE anyway...

If it can't be removed, it should be made optional for servers, such as 
through an error code to explicitly refuse the port alignment options, if 
only to ensure that TURN remains less interesting than relay-less candidates 
within ICE, so that relays are less likely to be abused by lazy UAs 
implementors or what not.

-- 
Rémi Denis-Courmont <Remi.Denis-Courmont@xxxxxxxxx>
Assistant Research Engineer

---

From: Adam Roach <[email-masked]>
Date: Wed, 12 Jul 2006 10:00:33 -0700 (PDT)

Rémi Denis-Courmont wrote:
The more worrysome (to me) side effect is that we end up with an incentive for UAs behind even very friendly (e.g. full cone) NATs to use TURN regardless of the availability of connectivity mechanisms that would be less costly to maintain for network operators.
Are you honestly arguing for removal of a protocol feature because it is 
useful?

/a

---

From: Aki Niemi <[email-masked]>
Date: Wed, 12 Jul 2006 11:47:15 -0700 (PDT)

On ke, 2006-07-12 at 13:00 -0400, ext Adam Roach wrote:
> RÃmi Denis-Courmont wrote:
> > The more worrysome (to me) side effect is that we end up with an incentive 
> > for UAs behind even very friendly (e.g. full cone) NATs to use TURN 
> > regardless of the availability of connectivity mechanisms that would be 
> > less costly to maintain for network operators.
> 

It's a matter of pain vs. benefit. If we were to always add all useful
features imaginable, we'd be busy boiling the ocean with every spec we
produce.

If it's a pain to implement, and provides minimal (and diminishing)
returns, let's not put it in. It's as simple as that.

-- 
Aki Niemi
Nokia Research Center

---

From: Adam Roach <[email-masked]>
Date: Wed, 12 Jul 2006 11:58:22 -0700 (PDT)

Aki Niemi wrote:
  
The specific argument that RÃmi made -- the one to which I responded -- 
had nothing to do with implementation complexity.

His thesis was that the feature under discussion is _so_ useful that it 
would cause problems -- that somehow failing to cripple the protocol 
makes it an attractive nuisance.

/a

---

From: [email-masked]
Date: Wed, 12 Jul 2006 12:05:04 -0700 (PDT)

The port pair feature will be required to talk to non-ice supporting 3605
compliant endpoints when endpoint using TURN/ICE is behind a symmetric
NAT.

I doubt the implementation cost will be onerous, and I think not having it
will delay adoption of TURN.

--Derek

Aki Niemi said:
> > > The more worrysome (to me) side effect is that we end up with an
>> incentive for UAs behind even very friendly (e.g. full cone) NATs to
>> use TURN regardless of the availability of connectivity mechanisms
>> that would be less costly to maintain for network operators.
> >

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 13 Jul 2006 03:27:07 -0700 (PDT)

Le Wednesday 12 July 2006 20:00, vous avez écrit :
> > incentive for UAs behind even very friendly (e.g. full cone) NATs to use
> > TURN regardless of the availability of connectivity mechanisms that would
> > be less costly to maintain for network operators.

> Are you honestly arguing for removal of a protocol feature because it is

Well... No! my original point was that it is useless, painful to implement, 
and might induce UAs into doing things that I think would be bad. But it was 
argued that people found it useful; well, I cannot decide for someone else 
whether a feature is useful to him/her.

My point is that this provides an incentive to implement and use the 
suboptimal solution (TURN alone instead of ICE with TURN as the worst 
candidate)..

Also, how many user agents are there that:
- do implement RTCP properly,
- do require that the peer send RTCP properly,
- do NOT support RFC 3605,
- do send symmetric RTP (since asymmetric is fatal) and RTCP, and,
- do have a public IPv4 address (otherwise they'll need RFC3605 too)?

Probably very very few.

I can accept that some people deadly want this feature in TURN anyhow... but I 
don't want to bloat "my" TURN servers neither do I want to incite UAs 
implementors into using TURN servers blindly in hope of getting interop with 
the "very very few" obsolete user agents at stake. As such, I'm not happy 
that this feature exists, and I'm even less happy that this feature is a 
*mandatory* requirement for TURN servers.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Jul 2006 07:46:08 -0700 (PDT)

> - do have a public IPv4 address (otherwise they'll need RFC3605 too)?

I wanted to throw out a comment on your last point:  a UA can be 
behind a NAT with a SIP-aware ALG, or behind an SBC, in which case it'll
have a public IPv4 address and will have adjacent RTP and RTCP ports 
without RFC3605.  I expect that, today, there are a lot of UAs 
behind SBCs or behind NATs with SIP-aware ALGs.

-d

---

From: Aki Niemi <[email-masked]>
Date: Thu, 13 Jul 2006 08:35:44 -0700 (PDT)

> behind SBCs or behind NATs with SIP-aware ALGs.

So, what breaks? They can't correctly send RTCP? Is that *really* such a
big problem? I'm not seeing RTCP used that much anyhow.

An implementor has indicated that the protocol has been added a
mandatory to implement feature that makes the implementation a lot more
complex without giving a clear benefit.

At this point, I think there needs to be more concrete reasons to
justify the added complexity than that there might be a scenario that
could need this. Like, that something breaks without it.

Otherwise, take it out, or make it optional (in which case we won't
implement it, BTW).

-- 
Aki Niemi
Nokia Research Center

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 18 Jul 2006 16:52:48 -0700 (PDT)

Jonathan,

There is a glitch in the section numbers for section 12 on STUN Usages.

Sections 12.1.1.9-12.1.1.11 should really be 12.1.2-12.1.4.