Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document

From: "Francois Audet" <[email-masked]>
Date: Thu, 2 Sep 2004 10:41:24 -0700 (PDT)

I'm interpreting this as a vote for "conservative".

I'm OK with that.

Any other views?

> -----Original Message-----
> From: Melinda Shore [mailto:mshore@xxxxxxxxx] 
> Sent: Thursday, September 02, 2004 10:23
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Behave'
> Subject: Re: [Ietf-behave] Two suggestions for BEHAVE document
> 
> 
> On Thursday, September 2, 2004, at 01:08 PM, Francois Audet wrote:
> > What is your preference: "deterministic" or "conservative"?
> 
> I think the answer to that depends on what kind of model 
> you're working from.  If you've got a best-effort view of the 
> world, it's probably best to go with conservative.  If you've 
> got a reliable delivery view of the world, it probably best 
> to go with deterministic. My own feeling is that it's 
> probably a mistake to allow UDP- encapsulated IPSec to fail 
> even though you've got resources available 
> when
> those available resources don't conform to what you'd need for voice.
> 
> Melinda
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Sep 2004 19:33:22 -0700 (PDT)

Yep, makes sense

> From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx] 
> Sent: Wednesday, September 08, 2004 11:08
> Cc: 'Melinda Shore'; 'Behave'
> Francois Audet wrote:
> > Sounds reasonable. Do you think we should define the 
> failure mode? (I 
> > personally think we should, so that our document is 
> deterministic). Or 
> > do you think we should just do a RECOMMEND?
> 
> I think you want to define it. If you define it as "fall back to 
> providing a port on the other address", then a client would 
> know that it 
> should probably implement RFC 3605 (the RTCP address/port 
> attribute in 
> SDP) anyway, allowing it to still get RTCP to work in the 
> event that the 
> peer supports RFC 3605.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@xxxxxxxxxxxxxxx                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Sep 2004 10:28:27 -0700 (PDT)

> I can understand this position.  However, wasn't RTCP thought 
> of a means to communicate packet loss rates?  If I put this 
> in context with the IAB problem statement on congestion 
> control, I doubt it is a good idea to just silently prevent 
> RTCP from working.

Agreed: the question is do we do anything on the NAT, or do we
leave it strictlly to the application itself (e.g., in SDP-based protoctols
like SIP, use RFC 3605 plus STUN-type discovery for both RTP and
RTCP), or do also try to load the dice so the NAT will use consecutive
ports.

> Well, there are developers working on a SIP ALG for 
> netfilter, and they asked us to include infrastructure for 
> consecutive port number reservation into the netfilter NAT 
> core.  Our current position on this is 
> 
> 1) consecutive port numbers are a bad idea, somebody should LART the
>    protocol designers
> 2) now that we are facing the problem, we have to come up with a
>    solution (i.e. implement it).
> 
> > I think that there is a very good chance based on past 
> experience that 
> > if NAT vendors use different algorithms for preserving consecutive 
> > port numbers, we will end-up in trouble.
> 
> We'd just chose any two (or even four in the case of A/V 
> streams?) consecutive port numbers that are available.  Just 
> like we would chose any single available port number.

That works well with ALGs, but not so well with the non-ALG based
BEHAVE is addressing.

> > So I think that we need to discuss the issue in the document.
> > 
> > Perhaps it's as simple as saying that we don't recommend 
> putting hacks 
> > in the NAT to address the issue because of reasons X, Y, Z.
> 
> I would definitely like that.  It saves us from those hacks 
> in the code. However, it should then be considered to alter 
> the RTP/RTCP specification to not require those consecutive 
> port numbers in the first place.
> 
> Either the protocol changes, or the NAT's will have to adress 
> it.  I don't see any way in between.

So I'm counting this as a vote for "don't attempt to do complicated
consecutive port preservation algorithms on the NAT"? 

Is this correct?