Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP behavior descript ion

From: "Francois Audet" <[email-masked]>
Date: Thu, 28 Oct 2004 10:31:27 -0700 (PDT)

> - I am lacking experience from deployed scenarios, do the parity 
> preservation actually help? Also is there any other UDP user that 
> benefit from this? I trying to understand if REQ-4 actually 
> provide any 
> benefit.

To answer this particular point, "yes".

I have seen SIP applications that interpreted the following paragraph
from RFC 3550 as saying that they should uniterally adjust the value 
of the UDP port¨negotiated in SIP/SDP to fit the parity rule:

   RTP relies on the underlying protocol(s) to provide demultiplexing of
   RTP data and RTCP control streams.  For UDP and similar protocols,
   RTP SHOULD use an even destination port number and the corresponding
   RTCP stream SHOULD use the next higher (odd) destination port number.
   For applications that take a single port number as a parameter and
   derive the RTP and RTCP port pair from that number, if an odd number
   is supplied then the application SHOULD replace that number with the
   next lower (even) number to use as the base of the port pair.  For
   applications in which the RTP and RTCP destination port numbers are
   specified via explicit, separate parameters (using a signaling
   protocol or other means), the application MAY disregard the
   restrictions that the port numbers be even/odd and consecutive
   although the use of an even/odd port pair is still encouraged.  The
   RTP and RTCP port numbers MUST NOT be the same since RTP relies on
   the port numbers to demultiplex the RTP data and RTCP control
   streams.

The parity rule is thus a very inexpensive way to deal with this particular
problem.

The port sequencing rule is much harder to fix. You really need the application
itself to account for it, which will be done in another "application guidelines"
document.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Oct 2004 12:17:40 -0700 (PDT)

> of the UDP port¨negotiated in SIP/SDP to fit the parity rule:
...
>   next lower (even) number to use as the base of the port pair.
...

I would interpret it that way, too.

I'm frankly surprised that RFC3550 says that, because it really means
"if an even port is signaled, it's wrong and you should ignore that
port and instead use the next-lower odd port".  I guess it's good that
there are exceptions all around the sentence, but it makes an implementation
unnecessarily complex.  The text in RFC3550 appears derived from this
text in RFC1889, which states:

...
   For UDP and similar protocols, RTP
   uses an even port number and the corresponding RTCP stream uses the
   next higher (odd) port number. If an application is supplied with an
   odd number for use as the RTP port, it should replace this number
   with the next lower (even) number.
...

and doesn't have exceptions around it.  So RFC1889-compliant devices
are what are causing the problem here (that is, devices which don't
have separate signaling for the RTCP port [RFC3605]).

> The parity rule is thus a very inexpensive way to deal with this
> particular problem.

I agree that additional text needs to be added to BEHAVE to explain
why the parity rule is helpful with RTP.

-d

---

From: Jon Ringle <[email-masked]>
Date: Thu, 28 Oct 2004 12:32:10 -0700 (PDT)

I seems to me that it would be better for legacy RFC1889 devices to change 
their behaviour so that there is a separately advertised RTCP port. Quite 
frankly, I fail to see what the motivation is behind having RTP and RTCP to 
have port parity and RTCP=RTP+1 constraints. If the signaling protocol 
advertises the RTP and RTCP independantly, why does RTP/RTCP need to have a 
port parity at all (other than for legacy compatability)? To me, this looks 
like an anti-pattern that shouldn't be encouraged by BEHAVE, and puts 
unnecessary processing and book keeping on the shoulders of a NAT device, 
just to accomodate a single application: RTP/RTCP. Are there any other 
protocols that practice this NAT unfriendly attribute?

Jon

On Thursday 28 October 2004 03:17 pm, Dan Wing wrote:
> there are exceptions all around the sentence, but it makes an
> implementation unnecessarily complex.  The text in RFC3550 appears derived
> from this text in RFC1889, which states:
>
> ...
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Oct 2004 02:04:12 -0700 (PDT)

Hi,

I agree that explicit signalling of the RTCP port should be encouraged. 
However there is quite a large number of applications out there that do 
follow the even-odd rule and the RTCP signalling mechanism for SIP/SDP 
is quite new. There are also several other applications and their 
signalling protocol that do not yet support explicit RTCP port 
signalling. One of them is RTSP, where we are working on an update to 
resolve the issue, but it is not yet available.

Based on the less fortunate formulation about replacing an odd port in 
RFC 3550, I think that recommending port parity is the right choice. At 
least it avoids that problem.

However I would like to point out that failure of the RTCP should result 
in that many application should throttle down its own transmission. 
There is a requirement on congestion control for RTP that is not that 
well followed, and a very basic mechanism for not being totally ignorant 
of the network condition is to actually use RTCP. But I think the right 
future is explicit signalling and probably ICE.

Cheers

Magnus

Jon Ringle wrote:

--

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx

---

From: Jon Ringle <[email-masked]>
Date: Fri, 29 Oct 2004 06:22:15 -0700 (PDT)

By specifying that a BEHAVE-compliant NAT has a means to provide port parity 
and +1 reservation, then BEHAVE does NOT encourage a change by applications 
requiring such behaviour.

Not only should there be a notion of BEHAVE-compliant NATs, but also 
BEHAVE-compliant applications. I don't think it's unreasonable to say that an 
application is not BEHAVE-compliant if it requires port parity/+1 
reservation. Such an application would become BEHAVE-compliant once such 
restriction are removed by the application.

I agree that ICE is providing a path that applications could follow to become 
BEHAVE-compliant.

Jon

On Friday 29 October 2004 05:03 am, Magnus Westerlund wrote:
> > I seems to me that it would be better for legacy RFC1889 devices to
> > change their behaviour so that there is a separately advertised RTCP
> > port. Quite frankly, I fail to see what the motivation is behind having
> > RTP and RTCP to have port parity and RTCP=RTP+1 constraints. If the
> > signaling protocol advertises the RTP and RTCP independantly, why does
> > RTP/RTCP need to have a port parity at all (other than for legacy
> > compatability)? To me, this looks like an anti-pattern that shouldn't be
> > encouraged by BEHAVE, and puts unnecessary processing and book keeping on
> > the shoulders of a NAT device, just to accomodate a single application:
> > RTP/RTCP. Are there any other protocols that practice this NAT unfriendly
> > attribute?
> >
> > Jon

---

From: Melinda Shore <[email-masked]>
Date: Fri, 29 Oct 2004 06:35:44 -0700 (PDT)

On Friday, October 29, 2004, at 09:22 AM, Jon Ringle wrote:
Not only should there be a notion of BEHAVE-compliant NATs, but also
BEHAVE-compliant applications. I don't think it's unreasonable to say 
that an
application is not BEHAVE-compliant if it requires port parity/+1
reservation. Such an application would become BEHAVE-compliant once 
such
restriction are removed by the application.
If we could go back and change every protocol that has NAT problems,
it would probably make more sense to change them so that they have
no NAT problems rather than having a different set of NAT problems.
My sense is that the working group is focused on defining a set
of friendlier NAT behaviors and that defining new, desirable application
behavior is quite, quite, quite far out-of-scope.
However, it seems reasonable to me to describe the limitations of
the behaviors defined by the working group, and this might be an
example.
Melinda

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 29 Oct 2004 08:19:15 -0700 (PDT)

Hi Jon,

Jon Ringle wrote:

By specifying that a BEHAVE-compliant NAT has a means to provide port 
parity
and +1 reservation, then BEHAVE does NOT encourage a change by applications
requiring such behaviour.
I will clarify that I don't think it will be good, even to try, to put a 
requirement that RTP and RTCP is kept together. That is to complex and 
to brittle to work. However to avoid any clients from failing into the 
pitfall of renumbering their RTP port number to an even number, I think 
that preserving port parity makes sense. However, port parity is NOT 
enough to make RTP work over a BEHAVE-compliant NAT. An application will 
be required to have further traversal mechanisms. Thus, any application 
will need to adopt a explicit RTCP port signalling rule.

Removing the port parity rule, will only result in that NATs break even 
more sessions. If there is very little cost associated with the 
requirement I don't see a reason, why one can avoid having these 
failing. There will be sufficient amount of sessions failing anyway that 
transition to applications with traversal capacity will be used.

Best Regards

Magnus Westerlund

---

From: Bryan Ford <[email-masked]>
Date: Fri, 29 Oct 2004 10:30:10 -0700 (PDT)

> behavior is quite, quite, quite far out-of-scope.

It does not seem at all out of scope to me that the BEHAVE group should define 
a set of design guidelines for new or updated applications that will ensure 
that they work robustly and deterministically over BEHAVE-compliant NATs.  If 
this information is only available encoded in a form oriented entirely toward 
NAT implementors, then application protocol designers are much less likely to 
read it or to understand how to make their applications work robustly over 
NATs.  This group needs to address both sides of the equation in order to 
solve the overall problem it was formed to solve.

Bryan