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

From: Bryan Ford <[email-masked]>
Date: Thu, 17 Feb 2005 08:36:54 -0800 (PST)

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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 18 Feb 2005 10:24:42 -0800 (PST)

OK. It looks like we are in synch.

One minor point: I believe that you may also want to list NSIS
in your list of NAT control protocol that are out-of-scope.

> -----Original Message-----
> From: Bryan Ford [mailto:baford@xxxxxxx] 
> Sent: Friday, February 18, 2005 03:38
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: Re: [Ietf-behave] New draft: Application Design Guidelines
> 
> 
> On Thursday 17 February 2005 20:36, Francois Audet wrote:
> > Good job. This is great.
> 
> Thanks! :)
> 
> > 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.
> 
> 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.
> 
> > - 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.
> 
> 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.
> 
> > 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.
> 
> 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
> 
>