RE: [BEHAVE] A simpler way to reduce keepalive traffic

[<[e-mail]>]

Hi Bryan,

These are certainly interesting ideas. It would be great if we had a
reliable way to determine what the minimum timeout on the path is and
adjust the keepalive rate accordingly. I like the proposal about
exponentially extending the timeout in NAT to support long-lived
connectivity.

It would be good to understand how reliably the timeout can be
determined in real networks. There seem to be a lot of middleboxes who
expire their states in very undeterministic ways. So, even if the
measurement suggest the timeout is at least X, it might be less. For
instance I'm aware of one particular firewall product, where state
deletion is done by a background process, causing considerable variance
across different flows. It depends on the application how critical
possible short connectivity failures are. For your primary telephony app
you want to be relatively conservative, but perhaps something like push
e-mail can survive from occational loss without users becoming more mad
than they become when their battery runs out in 8 hours.

As we can't hope many middleboxes to allow explicit query or control of
the timers in the near future, I think we should pursue the kind of
things you propose, for both TCP and UDP. It is surely useful for the
applications to know how often they need to send dummy traffic, and save
device battery.

Markus
 

>-----Original Message-----
>From: ext Bryan Ford [mailto:[e-mail]] 
>Sent: 04 December, 2007 02:56
>To: IETF BEHAVE WG
>Subject: [BEHAVE] A simpler way to reduce keepalive traffic
>
>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
>
>
>
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/behave
>


_______________________________________________
Behave mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/behave