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

From: Bryan Ford <[email-masked]>
Date: Mon, 3 Dec 2007 16:55:55 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 3 Dec 2007 19:50:18 -0700

Since I was not able to attend the BoF, could you provide a synopsis of why
this consensus was arrived at?  Specifically, can you describe any
deployment scenarios that were quantitatively presented that have difficulty
with the "chattiness" you are referring to?  I will assume that the
chattiness is primarily a problem for the STUN servers that are servicing
the keepalives.  What kind of data was presented to support this problem?

Thanks,
FM

-----Original Message-----
From: Bryan Ford [mailto:[email-masked]] 
Sent: Monday, December 03, 2007 5:56 PM
To: IETF BEHAVE WG
Subject: [BEHAVE] A simpler way to reduce keepalive traffic

Cheers,
Bryan

---

From: "David Barrett" <[email-masked]>
Date: Mon, 3 Dec 2007 22:14:14 -0800

Incidentally, we've been using the technique Bryan suggests for over a year
now across several hundred thousand computers and it works great.  Indeed, I
can confirm there are NATs out there that already have this property, though
they're not typical.

The only thing annoying about it is it requires two separate ports: one to
probe with (that you don't care if it loses its mapping), and one to
actually use.

If it's interesting to anybody, I could pull together some data on the
distribution of real-world NAT timeouts.  At the very least, that could help
shed light on whether or not the chattiness is really a problem.

(Off the cuff, I'd say that a 5M timeout window seems to be common, but I
really don't know for sure.)

-david

> From: Frank W. Miller [mailto:[email-masked]]
> Sent: Monday, December 03, 2007 6:50 PM
> To: 'Bryan Ford'; 'IETF BEHAVE WG'
> Subject: RE: [BEHAVE] A simpler way to reduce keepalive traffic
> 
>

---

From: <[email-masked]>
Date: Thu, 6 Dec 2007 00:26:06 +0200

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

>From: ext Bryan Ford [mailto:[email-masked]] 
>Sent: 04 December, 2007 02:56
>To: IETF BEHAVE WG
>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  
>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
>
>
>

---

From: <[email-masked]>
Date: Thu, 6 Dec 2007 00:35:19 +0200

David,

I would definitely be interested to know how reliable results you get by
doing timeout determination.

Currently chattiness is a real problem as keepalive rate has to be
usually adjusted according to the lower end of the distribution. And for
UDP even the center of the distribution seems also to be quite low, not
suitable for maintaining connectivity over a long period of time with a
battery-powered device, especially in certain type of radio networks. 

There may be many ways to address this problem, hopefully some more
simple than let's double the battery size, let's upgrade all WCDMA
networks or let's upgrade all NATs.

Markus

>From: ext David Barrett [mailto:[email-masked]] 
>Sent: 04 December, 2007 08:14
>To: 'Frank W. Miller'; 'Bryan Ford'; 'IETF BEHAVE WG'
>Incidentally, we've been using the technique Bryan suggests 
>for over a year now across several hundred thousand computers 
>and it works great.  Indeed, I can confirm there are NATs out 
>there that already have this property, though they're not typical.
>
>The only thing annoying about it is it requires two separate 
>ports: one to probe with (that you don't care if it loses its 
>mapping), and one to actually use.
>
>If it's interesting to anybody, I could pull together some 
>data on the distribution of real-world NAT timeouts.  At the 
>very least, that could help shed light on whether or not the 
>chattiness is really a problem.
>
>(Off the cuff, I'd say that a 5M timeout window seems to be 
>common, but I really don't know for sure.)
>
>-david
>
>> Since I was not able to attend the BoF, could you provide a synopsis 
>> of why this consensus was arrived at?  Specifically, can you 
>describe 
>> any deployment scenarios that were quantitatively presented 
>that have 
>> difficulty with the "chattiness" you are referring to?  I 
>will assume 
>> that the chattiness is primarily a problem for the STUN servers that 
>> are servicing the keepalives.  What kind of data was presented to 
>> support this problem?
>> 
>> Thanks,
>> FM
>> 
>> 
>> 
>section 4.3 of 
>draft-ietf-behave-nat-