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

[<[e-mail]>]

Hi Dave,

Thanks for your review. See comments inline.

Dave Thaler [mailto:[e-mail]] 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