Subject: [Ietf-behave] NAT behave draft

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 10 Aug 2004 04:53:45 -0700 (PDT)

<span style='font-size:
12.0pt'>Some comments/questions:

<span style='font-size:
12.0pt'> 

 <font size=3
     face="Times New Roman">REQ-3 comes up with
     a min-timeout of 2 minutes for UDP dynamic bindings. Is there data
     somewhere on the internet which can back this up ? 
 <font size=3
     face="Times New Roman">REQ-4 suggests that
     refreshes MUST be based outbound traffic only. This seems to be linked to
     REQ-1, since for symmetric firewalls, the security problem cited as reason
     is not quite valid. Also, inbound refreshes pose a problem with setting
     and maintaining the session. For example, a voice mail server which is
     outside the firewall cannot assume that simply sending traffic is good
     enough. For the offer/answer model, the sdp attribute of recvonly in an
     offer coming from behind the firewall is inapplicable, so this requirements
     affects how SIP sessions would be setup (or any other protocol…). 

<span style='font-size:
12.0pt'> 

<span style='font-size:
12.0pt'>-Medhavi.

<span style='font-size:
12.0pt'> 

<span style='font-size:
12.0pt'>Medhavi Bhatia

<span style='font-size:
12.0pt'>Chief Architect

<span style='font-size:
12.0pt'> 

<span style='font-size:
12.0pt'>NexTone Communications

<span style='font-size:
12.0pt'>****Pioneering Global Communications with Excellence, Integrity and
Flawless Execution****

<span style='font-size:
12.0pt'>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Sep 2004 10:09:23 -0700 (PDT)

Medhavi raises a good point, how long should the binding times be and more
importantly, any particular reason why?

Lacking any other good reason, we will likely pick times that are consistent
with what devices do today only because these somewhat match what customers
seem comfortable with.

On 8/10/04 7:53 AM, "Medhavi Bhatia" <mbhatia@xxxxxxxxxxx> wrote:

> Some comments/questions:
>  
> 1. REQ-3 comes up with a min-timeout of 2 minutes for UDP dynamic bindings. Is
> there data somewhere on the internet which can back this up ?
.. snip...
> Medhavi Bhatia
> Chief Architect
>  
> NexTone Communications
> ****Pioneering Global Communications with Excellence, Integrity and Flawless
> Execution****
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Sep 2004 19:04:41 -0700 (PDT)

I think the most important thing is that there is a deterministic 
minimum that you can count on; the actual value is far less important.

In principal, you'd like to tie the timeout to typical maximum activity 
intervals for UDP-based applications. That is, normal outbound packet 
activity for applications should keep the bindings active withot 
requiring additional keepalives. For RTP, even a much smaller number 
would typically suffice. For SIP over UDP, packet retransmits can be 
spaced as large as 16s towards the tail end of the transaction. If you 
want the binding to be active for a transaction lifetime without special 
keepalives, you'd want a minimum of 20s or so.

It'd be interesting to look at other UDP based protocols and see what 
timeouts would be appropriate. Of course, who knows what future apps 
would do. Again, the key thing is really determinism.

-Jonathan R.

Cullen Jennings wrote:

Some comments/questions:

Medhavi Bhatia
Chief Architect
NexTone Communications

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
--
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: "Dan Wing" <[email-masked]>
Date: Wed, 15 Sep 2004 08:40:34 -0700 (PDT)

> keepalives, you'd want a minimum of 20s or so.

With such short binding lifetimes, wouldn't you need SIP keepalives
(<CR><LF>.<CR><LF>) to keep the binding open so you can be signaled
for an incoming call?  

That's a lot of silly keepalive traffic for a SIP proxy.

> would do. Again, the key thing is really determinism.

I agree.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Sep 2004 20:15:47 -0700 (PDT)

inline.

Dan Wing wrote:

With such short binding lifetimes, wouldn't you need SIP keepalives
(<CR><LF>.<CR><LF>) to keep the binding open so you can be signaled
for an incoming call?  
Sure, but that's different. My argument was that it made sense to set 
the binding timeout so that it was large enough to not require 
additional keepalive traffic for UDP applications. I probably should 
have been clear that I meant client/server applications - ones for which 
an infinite binding lifetime is not required.

For those cases where the binding effectively needs to be infinitely 
long, such as receiving a SIP call, I think there is no way to avoid 
keepalives. In such a case, the following might make a reasonable metric 
for choosing the lifetime: the binding lifetime should be large enough 
such that a reasonable keepalive message, sent at intervals equal to 
that binding lifetime, would only represent a fraction of the overall 
bandwidth for the application protocol itself in its typical usage - 
say, no more than 5%.

Again looking at SIP, if we assume (REGISTER,200) refreshes of (1kB,1kB) 
every hour,  plus a SIP call every other hour (INV/200/ACK/BYE/200) with 
rough sizes of (1k,1k,.5k,1k,.5k), thats 4kB/hour. 5% of that is 
200B/hr. Assuming STUN for keepalives, its roughly 50B for a minimal 
request/response transaction. That gives you 4 of them per hour, which 
would argue for a relatively large keepalive interval - 15m.

The tradeoff, of course, is that increasing the keepalive increases the 
memory required for a certain volume of user traffic, and thus the cost.

-Jonathan R.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 16 Sep 2004 10:28:46 -0700 (PDT)

> that binding lifetime,

The keepalives need to be sent a little more aggressively than the
timeout.  If you consider the keepalive itself could get dropped
between the application and the NAT (such as a noisy WiFi connection
or a busy Ethernet segment or an over-taxed NAT), the keepalives
need to be even more aggressive.

> would only represent a fraction of the overall

Most NATs have a keepalive of 30 seconds, and the current BEHAVE I-D
suggests 2 minutes.  15 minutes is quite a long way from where we are today.

Are you perhaps suggesting that certain ports, such as the SIP port (UDP
5060) should be required, by BEHAVE, to have long keepalives?

> memory required for a certain volume of user traffic, and thus the cost.

Are you referring to the memory in the NAT to keep the state?  It's not just
memory, of course, but also the increased 'security exposure' of this
binding staying open a long time that causes many NATs to want to have
aggressive binding timeouts.

-d