RE: [Ietf-behave] UDP binding timeouts
> > 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,
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
> 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.
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?
> The tradeoff, of course, is that increasing the keepalive increases the
> 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
