Re: [Ietf-behave] UDP binding timeouts
inline.
Dan Wing wrote:
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.
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.
--
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
