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

["Reinaldo Penno (repenno)" <[e-mail]>]

Hello,

Comments inline...

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

>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.

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:
>--> 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
>_______________________________________________
>pcp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp