Subject: Re: [pcp] Comments on draft-reddy-pcp-optimize-keepalives-00

From: <[email-masked]>
Date: Mon, 5 Nov 2012 02:16:42 +0000

Hi Dave,

Thanks for your review. See comments inline.

Dave Thaler [mailto:[email-masked]] wrote:
>
>1) The document is nominally about optimizing keepalives to conserve
>power, and Section 3.3 is the core section about keepalive optimization.
>However,
>that section doesn't actually say anything that would result in any
>optimization.

True. The current version misses this explanation. And I agree it should be pretty much the crux of the draft.

>It basically just says you can send PCP messages instead of application layer
>messages, but just changing the packet format doesn't save power.  The main
>issues that it needs to discuss are as follows:
>* Simply using PCP instead of an app-layer message doesn't optimize for
>power.
>Power is optimized if keepalive messages (whether PCP or app-layer) are sent
>less often
>* App-layer keepalive messages typically still need to be sent to keep server
>state alive
>* Sending PCP messages less frequently than the application needs to keep
>the server state alive isn't useful, since the keepalives to refresh server state
>will refresh middlebox mappings.
>* Thus using PCP only optimizes power if the PCP message interval is strictly
>longer than what the app would normally use the keep middlebox state alive,
>and strictly shorter than the server state refresh interval.
>* Since PCP is not ubiquitously deployed in every middlebox already
>(obviously) an app has to have its own app-layer algorithm regardless.  And to
>optimize power, some apps already do their own dynamic detection algorithm
>(e.g., [RFC4380]
>section 5.2.7 has one such algorithm, and undoubtedly there are others).
>Where
>power is important (where isn't it? :) such algorithms are what all apps
>probably ought to be doing anyway.
>* With such an algorithm, using PCP for keepalive interval detection only
>provides benefit when a middlebox gives a longer mapping timeout as a result
>of using PCP than connections without PCP.
>
>Since we want PCP to be successful [RFC5218] for keepalive optimization, I
>believe it follows that we need to strongly encourage middleboxes to grant a
>noticeably longer timeout when refreshed with PCP messages than when
>refreshed with
>data packets.   But I'm not sure such a requirement/recommendation is in any
>document (maybe it is, but I didn't see it from a quick glance).
>
>(Of course this might also beg the question of what happens if every
>connection Then uses PCP, does that cause any problems?)
>
>Separately, there is a potential argument that using PCP can help an app's
>keepalive interval detection algorithm converge more quickly, but that's
>usually a startup-time thing and not a steady-state thing and so any power
>savings due to faster convergence may be negligible.
>

I agree with the above. In most cases the application will need to send some kind of end-to-end heartbeat anyway. What we need is a way to set the NAT/FW timers long enough so that no *additional* keep-alives would be needed just for their sake. 

I admit it is not entirely clear to me how PCP can or should be best used for this purpose. If I've understood correctly PCP actually can't be used to tell the NAT "keep this binding as long as you see any traffic on it at least every N seconds", i.e., control the implicit mapping timeout. It can only tell the NAT "keep this binding for the next N seconds". Is this correct? If so, the best approach is probably to set the binding lifetime as long as possible via PCP so that the PCP refreshes would be as infrequent as possible, and set the application heartbeat timeout to maximum value. A further optimization is to send the PCP refresh and the app timeout at the same time when appropriate. 

If the PCP binding lifetime were for example 4 hours, and app heartbeats would be sent once an hour, the message sequence would thus be:
--> app connection setup (t=0)
--> PCP PEER (t=0)
--> app heartbeat (t=1h)
--> app heartbeat (t=2h)
--> app heartbeat (t=3h)
--> PCP PEER + app heartbeat (t=4h)

Without PCP the app would have to send heartbeats (or other types of keep-alives) as frequently as needed by the NAT, most likely more often. And even if the NAT would have a default binding lifetime of >1 hour, it might be hard for the app to *reliably* detect this.

>2) The document does not explain how to detect firewalls.  Indeed it says that
>"Firewalls can not be detected this way" and then goes on to say what would
>happen
>if the app determines that "all NATs and Firewalls on its path support PCP".
>The
>obvious problem is that if there's no way to know whether all firewalls on the
>path support PCP, then you cannot use this draft.
>

Yes, this would be major showstopper. My co-authors have some ideas how we could solve it, I believe.

>3) Section 4.2 discusses HTTP and websockets.   Such protocols are used for
>persistent connections because they go through HTTP proxies.   However the
>section only discusses NATs, without any mention of HTTP proxies (or
>firewalls, for that matter).  I believe it needs to discuss having HTTP proxies be
>PCP servers, and how the client then uses PCP in that case.
>

Proxies also complicate the detection of PCP-unaware NATs, as we can't ask the proxy which source IP:port it sees on the TCP connection in the same way as we can do with an HTTP server. 

>Note that since hosts do have ways to discover and/or be configured with
>proxy addresses, this would be another potential PCP server discovery
>mechanism
>besides DHCP and default router list.   Should proxy addresses be used when
>DHCP and the default router don't respond to PCP?
>

Interesting. I haven't thought that we could use PCP to set the HTTP proxy TCP connection lifetimes. Would the PCP semantics be compatible with what is needed for that usage?

>-Dave

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 5 Nov 2012 10:56:22 +0000

Hello,

Comments inline...

On 11/4/12 9:16 PM, "[email-masked]" <[email-masked]>
wrote:

>I agree with the above. In most cases the application will need to send
>some kind of end-to-end heartbeat anyway. What we need is a way to set
>the NAT/FW timers long enough so that no *additional* keep-alives would
>be needed just for their sake.
>
>I admit it is not entirely clear to me how PCP can or should be best used
>for this purpose. If I've understood correctly PCP actually can't be used
>to tell the NAT "keep this binding as long as you see any traffic on it
>at least every N seconds", i.e., control the implicit mapping timeout.

Interesting, please see below.

>It can only tell the NAT "keep this binding for the next N seconds". Is
>this correct? If so, the best approach is probably to set the binding
>lifetime as long as possible via PCP so that the PCP refreshes would be
>as infrequent as possible, and set the application heartbeat timeout to
>maximum value. A further optimization is to send the PCP refresh and the
>app timeout at the same time when appropriate.

In the case of PCP PEER if the client misses a refresh, the NAT reverts
back to its normal operation and outbound packets would trigger a refresh

"If a PEER-created or PEER-managed mapping is not renewed using PEER,
   then it reverts to the NAT's usual behavior for implicit mappings,
   e.g., continued outbound traffic keeps the mapping alive, as per the
   NAT or firewall device's existing policy."

Is that what you need?

> 
>
>If the PCP binding lifetime were for example 4 hours, and app heartbeats
>would be sent once an hour, the message sequence would thus be:
>Without PCP the app would have to send heartbeats (or other types of
>keep-alives) as frequently as needed by the NAT, most likely more often.
>And even if the NAT would have a default binding lifetime of >1 hour, it
>might be hard for the app to *reliably* detect this.
>
>Proxies also complicate the detection of PCP-unaware NATs, as we can't
>ask the proxy which source IP:port it sees on the TCP connection in the
>same way as we can do with an HTTP server.
>
>Interesting. I haven't thought that we could use PCP to set the HTTP
>proxy TCP connection lifetimes. Would the PCP semantics be compatible
>with what is needed for that usage?
>
>>-Dave
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: <[email-masked]>
Date: Mon, 5 Nov 2012 13:03:34 +0000

Hi Reinaldo,

See inline.

Reinaldo Penno (repenno) [mailto:[email-masked]] wrote:
>>maximum value. A further optimization is to send the PCP refresh and
>>the app timeout at the same time when appropriate.
>
>
>In the case of PCP PEER if the client misses a refresh, the NAT reverts back to
>its normal operation and outbound packets would trigger a refresh
>

This is how I assumed it works. Thanks. (Not having read the pcp-base for a while...). And I think we can optimize keep-alives that way reasonably well. There are however a couple of additional questions this raises:
- It could be useful if there was an explicit way to learn what the "outbound traffic driven" binding timeout is in a NAT or a firewall. Today some apps try to do this by trial and error and it's not very reliable. Of course it may be that if the NAT/FW supports PCP, this information becomes irrelevant as the client can set the binding lifetime as long as it wants. But perhaps there could still be some scenarios where the NAT/FW would not allow PCP to set the lifetime, but just ask what it is. And that could be supplied to the apps. 
- As many people have commented, apps often want/need to do end-to-end hearbeating regardless of NAT/FWs. A typical rate could be for instance once in 30 or 60 minutes, which would still be reasonable e.g. for cellular radio power consumption. So we would like to optimize that pattern with PCP. As discussed, the best option seems to be to set the PCP binding lifetime as long as possible, and synchronize its refresh with the app heartbeats, so that for instance radio would have to be activated as few times as possible. And in practice that might be as good as is needed. However, in theory you could be able to leave the PCP refreshes out altogether, if you had a way to find out that in this particular case the NATs traffic-driven timeout is, say, 65 minutes, or even better, set it to 65 for the duration of the binding. 

The much bigger issue than the detailed optimization of the keep-alive/refresh pattern is the detection of when PCP can be relied upon. NATs beyond the outmost PCP-contolloable NAT can be detected by the application, but in reality that is a bit tricky. Firewall detection is even more challenging. It seems quite a burden for every app to do these checks, especially if it can't be done in a client alone. Perhaps some checking could be performed on the host level and apps could use the results. 

Markus