[SAFE] Fwd: A simpler way to reduce keepalive traffic

[Bryan Ford <baford at MIT.EDU>]

[For reference, this is the beginning of the thread Dan Wing's message  
on keepalive battery consumption derives from - I originally posted my  
message to the BEHAVE list because I didn't realize there was a SAFE  
mailing list: I learned about the SAFE BOF from the meeting 70 agenda  
and the mailing list isn't mentioned there.]

In the "SAFE" BOF today it emerged that (a) there seems to be a clear  
consensus that the IETF needs to do something to reduce the  
"chattiness" of NAT traversal mechanisms due to the keepalive traffic  
they use to keep their (especially UDP) bindings open; and (b) there's  
definitely no consensus yet on the best approach to accomplish that.   
(At least that was my personal take-away from the BOF.)

Although for various reasons I would love to see a decent "explicit  
NAT control" or "listener discovery" protocol get standardized and  
deployed widely, I wanted to suggest an alternative way the one small,  
specific problem of keepalive chattiness might be addressed without  
any such explicit protocol.  The solution has two elements:

1. An amendment to BEHAVE-UDP, basically affecting only section 4.3 of  
RFC 4787 and in a backward-compatible way, recommending that NATs  
multiplicatively increase each mapping's timeout over the mapping's  
lifetime.  For example, if the NAT initially uses a 2-minute timer for  
a brand-new mapping (the minimum allowed), then if the mapping is  
still alive after 2 minutes the NAT increases the timeout by (say)  
2.5x to 5 minutes; then if the mapping is still alive after that 5  
minutes the timeout is again increased by 2.5x to 12.5 minutes, and so  
on.  This is the only change required to NATs.

2. Applications that wish to minimize their keepalive chattiness can  
now use the following technique.  They initialize their keepalive  
transmission timer to something safely small for all "reasonable" NATs  
- e.g., on the order of 10 seconds - and then in the background  
initiate a binding lifetime discovery mechanism analogous (but not  
identical) to that described in section 4.5 of draft-ietf-behave-nat- 
behavior-discovery-02.  In particular, instead of assuming the NAT's  
binding lifetime is fixed and doing a binary search for it as the  
draft suggests, the application just probes successively larger  
lifetimes in progression, increasing the probe by a multiplicative  
factor of (say) 1.5x each time.  When the application has verified  
that the NAT seems to have a binding lifetime of "at least" x, the  
application sets its keepalive period for the "main" UDP session it's  
actually using to that value and continues on to probe larger values.

Now, when the path contains one or more "legacy" NATs with a fixed  
binding lifetime, the above application behavior will find that  
lifetime and use a suitably-matched keepalive period on an ongoing  
basis - thus, even with no modifications to existing NATs, the  
application effectively minimizes its chattiness to whatever the NATs  
on the path will permit.  On the other hand, when the path contains  
only NATs that behave as proposed in #1 above, as long as the  
application's starting period and multiplicative increase factor is  
less than the NAT's, then both periods will continue to increase  
indefinitely, resulting in O(log t) instead of O(t) keepalive traffic  
over a long-lived binding with a total actual lifetime of t.  Once the  
application eventually terminates, the time it takes the NAT to notice  
this is now proportional to the amount of time the application's  
binding was actually active: so even though the NAT might take a while  
to garbage-collect a long-lived binding, any given binding can be in  
such a "dead" state for only a constant percentage of its total  
lifetime.  Thus, the scheme guarantees both logarithmic keepalive  
chatter over a binding's lifetime, and an easily-computable  
"efficiency ratio" if you compare a binding's total lifetime against  
the amount of time the application actually uses that binding.

Of course there are plenty of details to work out, such as what the  
multiplicative factors are, and whether the application should use a  
single UDP session for both application use and binding lifetime  
discovery probing as the behavior-discovery draft suggests, or a  
separate UDP session for each purpose.  Using a single UDP session is  
obviously more efficient in terms of NAT state and absolute keepalive  
traffic load, but has the disadvantage of allowing the application's  
main UDP session to "go dead" for some period as the application's  
binding lifetime probe period exceeds the binding lifetime of some  
legacy NAT in the path, perhaps leaving the SIP client temporarily  
unreachable from the outside world for example.

Cheers,
Bryan




_______________________________________________
SAFE mailing list
SAFE at ietf.org
https://www1.ietf.org/mailman/listinfo/safe