Subject: RE: [Ietf-behave] New draft: Application Design Guidelines

From: "Francois Audet" <[email-masked]>
Date: Thu, 17 Feb 2005 11:37:15 -0800 (PST)

Good job. This is great.

Some minor comments:

- Section 1.2: More importantly than "so far none of these protocols have
  become widely accepted", it should be stated that it may not be feasible
  or desireable in many architectures to have the application controlling
  the NAT.

- It's a little unclear to me what REQ-6 is trying to say.

- Need a value for XX in REQ-7. Something smaller than half of 2 minutes
  (to match nat-behave). My guess is 30s. We could also talk about detecting 
  the timeout. I think that there were text about that in either STUN or ICE, 
  I forget. In any case, should be marked as "opened issue" for now.

Also, we probably need to add some material on RTP/RTCP usage. For example,
we need to discuss the fact that if RTP/RTCP address/port pairs do not
respect the parity and contiguity rule, the application MUST list them
separately (and not derive them algorithmically). Also, that if they
are advertized seperately, media must be sent to those addresses, and rules
on substracting one (as per RFC 3550 do not apply). Maybe list RFC 3605 as
as the mechanism used by SDP to list them separately.

I agree with Dan on the symmetric RTP draft being folded in.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Bryan Ford
> Sent: Thursday, February 17, 2005 08:37
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: [Ietf-behave] New draft: Application Design Guidelines
> 
> 
> The second new draft is intended to provide a starting point for the 
> "recommendations for application designers" document that has 
> already been 
> brought up several times on this list, and which I believe 
> represents the Dec 
> 05 milestone in the original BEHAVE WG timeline.  As such, 
> I'd like to ask 
> the group to review it and consider adopting it as an 
> official WG document 
> for thus purpose.  This document is not too closely tied to 
> the NAT behavior 
> documents, so it could move toward eventual publication on 
> its own schedule.
> 
> 
> "Application Design Guidelines for Traversal of Network 
> Address Translators" 
> http://www.ietf.org/internet-drafts/draft-ford-behave-app-00.txt
> 
> Abstract:
>     This document defines best current practices by which application 
> designers can create applications that communicate reliably 
> and efficiently 
> in the presence of network address translators (NAT), 
> particularly when the 
> application has a need for "peer-to-peer"-style (P2P) 
> communication patterns 
> in addition to traditional client/server-style communication. 
> There is no 
> single NAT traversal algorithm that will make a P2P 
> application reliably work 
> over all deployed NATs. Following the guidelines described in 
> this document, 
> however, allows a P2P application to work reliably over a majority of 
> existing NATs, as well as all future NATs that conform to the 
> requirements 
> specified in companion documents. The NAT traversal 
> techniques described here 
> do not require the use of special proxy or relay protocols, 
> do not require 
> specific knowledge about the network topology or the number 
> and type of NATs 
> in the path, and do not require any low-level modifications to IP or 
> transport-layer protocols that might require special 
> privileges on the end 
> hosts.
> 
> Thanks,
> Bryan
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Bryan Ford <[email-masked]>
Date: Fri, 18 Feb 2005 03:38:03 -0800 (PST)

> Good job. This is great.

Thanks! :)

>   or desireable in many architectures to have the application controlling

Sounds good.  How about this rewritten Section 1.2:

1.2. Explicit Communication with NATs

   Several protocols exist that allow applications to obtain external
   communication endpoints through explicit interaction with NATs in the
   path [SOCKS, RSIP, MIDCOM, UPNP].  None of these protocols have yet
   become widely accepted, however, and in many network scenarios it may
   not be feasible or desirable for applications to identify, locate, or
   control NATs in their communication path.  This document therefore
   leaves such protocols out of scope, focusing exclusively on NAT
   traversal techniques that do not require the application to
   communicate explicitly with NATs in the path.

> - It's a little unclear to me what REQ-6 is trying to say.

REQ-6 is admittedly a little vague at the moment, and perhaps should be either 
made more specific or removed.  One particular thing I had in mind when 
writing this requirement was that if an application wants to subject NATs in 
the path to a long complicated battery of tests in order to traverse 
symmetric NATs and such, the application ideally shouldn't force the user to 
wait until all these tests are done before even being able to traverse 
BEHAVE-compliant NATs.  In other words, the task of gathering information for 
or setting up fancy non-BEHAVE traversal procedures shouldn't unduly delay 
the operation of the simple BEHAVE traversal procedure over BEHAVE-compliant 
NATs.

But this probably isn't a very critical issue, and if we can't come up with a 
clear way to state it, I would be happy with eliminating at least the 
"formal" recommendation and just leaving the informal discussion text in the 
body of 2.5.

>   I forget. In any case, should be marked as "opened issue" for now.

Sure.  30s sounds reasonable to me.  This keepalive period would obviously be 
too long for some existing NATs that have timeouts as short as 20 seconds, 
but 20 seconds is so unreasonably short that we can probably just classify 
such NATs as "broken" and assume the NAT-BEHAVE timeout.

I also agree that we probably need some text discussing timeout detection, 
though it's not yet obvious to me what the specific recommendation(s) should 
be on that.  I'll take a look back at STUN and ICE; thanks for the pointers.

> I agree with Dan on the symmetric RTP draft being folded in.

Yes, these suggestions all sound good to me.  Since (as I mentioned to Dan) 
I'm not yet very familiar with RTP/RTCP, would you guys mind providing some 
initial text on this topic to be added to the draft?

Thanks,
Bryan