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

[Bryan Ford <baford@xxxxxxx>]

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