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

From: "Francois Audet" <[email-masked]>
Date: Thu, 28 Oct 2004 09:52:19 -0700 (PDT)

> Hi,
> 
> In Section 3.2, there is a talk about port parity preserving.
> 
> - First I think the description on what is required by RTP is a bit 
> unclear. I think it should be clarified that for RTP sessions that do 
> not have explicit signalling of RTCP ports, the RTP ports 
> needs to use 
> an even port and RTCP the next port number, which is odd. Thus simple 
> preserving the parity is not sufficient as this could result in RTP 
> port: 2040 -> 4126 RTCP port: 2041 -> 4789 which would still not help 
> the RTP based application to get working RTCP traffic.
> 
> - 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.

Yeah, we did discuss this earlier. It's all on the archive.

Basically we can't really do anything that will absolutely ensure that the port
are contiguous in all cases, so there is no point in defining a rule that does not
result in deterministic behavior. If an application is not smart enought to 
negotiate the RTP and RTCP separately, the worst case scenario is that RTCP won't go
through which is not "good" but at least the call still works.

The parity problem is slightly different. The reason is described in the archives.
Basically, depending on how you read the RTP standard, you might end-up with
applications adjusting the port number unilaterally to the parity it expects, which
would be a problem.

Perhaps we should explain the reasonning in the document in the next release.

> However I do agree with the previous discussion that trying to do 
> something smarter would be difficult and probably create 
> worse problems. 
> The main argument is that transmission of RTP and RTCP are 
> not closely 
> dependent, and the either could proceed the other with at 
> least seconds, 
> up to minutes or never in cases when a receiver do only later 
> or not at 
> all transmit RTP packets.
> 
> Cheers
> 
> Magnus Westerlund
> AVT Chair
> 
> 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
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

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

Actually, I checked in draft-ietf-behave-nat-00 and it does already explain
the port parity problem I described below. See paragraph 6 of 3.2.

There is no talk about port sequence preservation.

There is no discussion about that in the document. Perhaps we need to have something
along those lines:

        Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. These NATs
        do things like sequential assignment, port reservation and so forth. Sequential
        port assignment assumes that the application will open a binding for RTP first and
        then open a binding for RTCP. It is not practical to enforce this requirement
        on all applications. Furthermore, there is a glare problem if many applications
        (or endpoints) are trying to open binding simultaneously. Port reservation is
        also problematic since it is wasteful, especially considering that a NAT can
        not reliably distinguish between RTP over UDP and other UDP traffic that does
        not have a contiguity rule. For those reasons, it would be too complex to attempt
        to preserve the contiguity rule by suggesting specific NAT behavior, and it would
        certainly break the deterministic behavior rule.

I'm not sure if we need to put a requirement REQ-4c for this because it seems to me to be more
of an application rule instead ("An application shall not assume that port contiguity will be
preserved") which is out of scope of this document. If we did, the rule would say something
like "It is RECOMMENDED that a NAT does not attempt to preserve the RTCP=RTP+1 port contiguity
rule".

What do people think?

> -----Original Message-----
> From: Audet, Francois [SC100:9T51:EXCH] 
> Sent: Thursday, October 28, 2004 09:52
> To: 'Magnus Westerlund'; 'Behave WG'
> Subject: RE: [Ietf-behave] draft-ietf-behave-nat-00: RTP 
> behavior description
> 
> 
> 
> > Hi,
> > 
> Basically we can't really do anything that will absolutely 
> ensure that the port are contiguous in all cases, so there is 
> no point in defining a rule that does not result in 
> deterministic behavior. If an application is not smart enought to 
> negotiate the RTP and RTCP separately, the worst case 
> scenario is that RTCP won't go through which is not "good" 
> but at least the call still works.
> 
> The parity problem is slightly different. The reason is 
> described in the archives. Basically, depending on how you 
> read the RTP standard, you might end-up with applications 
> adjusting the port number unilaterally to the parity it 
> expects, which would be a problem.
>

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 28 Oct 2004 10:30:19 -0700 (PDT)

At 01:09 PM 10/28/2004 -0400, Francois Audet wrote:

Actually, I checked in
draft-ietf-behave-nat-00 and it does already explain 
the port parity problem I described below. See paragraph 6
of 3.2. 

        Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. These NATs 
        do things like sequential assignment, port reservation and so forth. Sequential 
        port assignment assumes that the application will open a binding for RTP first and 
        then open a binding for RTCP. It is not practical to enforce this requirement 
        on all applications. Furthermore, there is a glare problem if many applications 
        (or endpoints) are trying to open binding simultaneously. Port reservation is 
        also problematic since it is wasteful, especially considering that a NAT can 
        not reliably distinguish between RTP over UDP and other UDP traffic that does 
        not have a contiguity rule. 
Did you mean port reservation is wasteful because NATs would reserve some ports
that is never used? If so, that is true but only until a timeout happens. That may not
be a huge issue, IMO. Secondly, NAT is told (by an ALG) that it need to allocate two 
consecutive ports, so in that sense it is aware that some protocol requires consecutive
ports.

For those reasons, it would be too complex to attempt 
        to preserve the contiguity rule by suggesting specific NAT behavior, and it would 
        certainly break the deterministic behavior rule. 

I'm not sure if we need to put a requirement REQ-4c for this because it seems to me to be more 
of an application rule instead ("An application shall not assume that port contiguity will be 
preserved") which is out of scope of this document. If we did, the rule would say something 
like "It is RECOMMENDED that a NAT does not attempt to preserve the RTCP=RTP+1 port contiguity 
rule". 
Adding this recommendation would cause some applications not to work well behind NATs 
anymore. Maybe it should be an option where the NATs can work in both modes one is
to preserve the ports and another one not needed to preserve, with the default being 
don't preserve.

Senthil

What do people think?

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 29 Oct 2004 11:51:15 -0700 (PDT)

Agreed.

When we do the "application requirement" document, we should explain
this further.

> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jon Ringle
> Sent: Friday, October 29, 2004 10:23
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: RTP 
> behavior descript ion
> 
> 
> On Friday 29 October 2004 12:51 pm, Francois Audet wrote:
> > Is this good? Any suggested improvements?
> 
> I think this text is good. I'd just like to point out that as 
> soon as an 
> application negotiates RTP and RTCP independantly, there is 
> no technical 
> requirement by that application to maintain port parity. But since 
> maintaining port parity by a NAT shouldn't be difficult, I 
> see no problem in 
> keeping that.
> 
> Having the +1 reservation requirement is frought with 
> potential problems, as 
> you've pointed out and race conditions.
> 
> Jon

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 1 Nov 2004 08:40:42 -0800 (PST)

The problem is that the "correction" in RFC 3550 (which supercedes
RFC 1889) failed to fix the problem. 

Therefore there is still an issue with RTP/RTCP. RTP/RTCP is also
very widespread and many of the applications that use it
assume that the rule is true.

The parity rule in the NAT does not add undue complexity to
a NAT. It is quite trivial.

We've already decided against the RTCP=RTP+1 rule because that was
too complex for a NAT.

> Sent: Thursday, October 28, 2004 12:32
> 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:
> > > 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:
> >
> > ...
> >
> > >   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.
> >
> > ...
> >
> > 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: "Francois Audet" <[email-masked]>
Date: Tue, 2 Nov 2004 08:21:57 -0800 (PST)

Yes, 
this document (Dec 05) is the one what should describe things like "Don't 
expect RTP to be necessary even, and RTCP to be necessary odd, and that 
RTCP=RTP+1, and negotiate them separately both for IP address and 
port".
<FONT face=Arial color=#800000 
size=2> 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  
  <FONT 
  face=Tahoma size=2>-----Original Message-----From: 
  ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
  [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Spencer 
  DawkinsSent: Tuesday, November 02, 2004 05:25To: 
  ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: Re: [Ietf-behave] 
  draft-ietf-behave-nat-00: RTP behavior descript ion
  I am confused. This may not be news, but ...
   
  Looking at the current charter for Behave, the closest thing 
  to "the Application Document" that I see a milestone for is

      Dec 05
        
      Produce a BCP that discusses protocol design techniques 
        for using the existing set of NAT traversal approaches 

  Is this the same thing (doesn't sound like it to me), or is 
  "the Application Document which we will tackle next" out of scope for the 
  existing charter?
   
  The document being discussed below sounds more like "a BCP 
  that discusses application protocol design techniques for avoiding issues with 
  NAT traversal" - ALSO a worthy goal, just a different one.
   
  Spencer
  <BLOCKQUOTE 
  style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    ----- Original Message ----- 
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From: 
    <A title=audet@xxxxxxxxxxxxxxxxxx 
    href="mailto:audet@xxxxxxxxxxxxxxxxxx">Francois Audet 
    To: <A title=baford@xxxxxxx 
    href="mailto:baford@xxxxxxx">'Bryan Ford' ; <A 
    title=ietf-behave@xxxxxxxxxxxxxxxxxxx 
    href="mailto:'ietf-behave@xxxxxxxxxxxxxxxxxxx'">'ietf-behave@xxxxxxxxxxxxxxxxxxx' 
    
    Sent: Friday, October 29, 2004 12:52 
    PM
    Subject: RE: [Ietf-behave] 
    draft-ietf-behave-nat-00: RTP behavior descript ion
    
    Hi Bryan, 
    It's out of scope of THIS document. 
    It's in the scope of the Application Document which we will 
    tackle next. 
    > -----Original Message----- > 
    From: <A 
    href="mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx">ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
    > [<A 
    href="mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx">mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
    On Behalf Of > Bryan Ford <FONT 
    size=2>> Sent: Friday, October 29, 2004 10:30 <FONT 
    size=2>> To: <A 
    href="mailto:ietf-behave@xxxxxxxxxxxxxxxxxxx">ietf-behave@xxxxxxxxxxxxxxxxxxx 
    > Subject: Re: [Ietf-behave] draft-ietf-behave-nat-00: 
    RTP > behavior descript ion <FONT 
    size=2>> > > On 
    Friday 29 October 2004 09:35, Melinda Shore wrote: <FONT 
    size=2>> > 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 <FONT 
    size=2>> 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 <FONT 
    size=2>> > friendlier NAT behaviors and that defining new, desirable 
    > application > > 
    behavior is quite, quite, quite far out-of-scope. <FONT 
    size=2>> > 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 <FONT 
    size=2>> that they work robustly and deterministically over 
    > BEHAVE-compliant NATs.  If 
    > this information is only available encoded in a 
    form oriented > entirely toward <FONT 
    size=2>> NAT implementors, then application protocol designers are 
    > much less likely to <FONT 
    size=2>> 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 > 
    _______________________________________________ > 
    Ietf-behave mailing list > 
    Ietf-behave@xxxxxxxxxxxxxxxxxxx > <A 
    href="https://list.sipfoundry.org/mailman/listinfo/ietf-behave" 
    target=_blank>https://list.sipfoundry.org/mailman/listinfo/ietf-behave 

    _______________________________________________Ietf-behave 
    mailing 
    listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave