Re: [hybi] NAT reset recovery? Was: Extensibility mechanisms?

[Jamie Lokier <[e-mail]>]

[e-mail] wrote:
> Mobile clients would often want to send keepalives as infrequently
> as possible to save battery. They may use intelligent
> (unstandardized) mechanisms to learn what the mimimum rate
> acceptable for their access network NATs and firewalls are and use
> it. (As of today I believe the ballpark for TCP is something like a
> once per 10 minutes of idleness.)
>
> The servers on the other hand want to get rid of unused connections
> as fast as possible and may want to check the connection liveliness
> even faster. (I heard that some major XMPP servers send keepalives
> every 30 seconds.)

That depends a lot on the server, the application, and how loaded it is.

> For many clients (running in PCs etc.) this is probably fine but
> really bad for the clients in mobile devices. If the same device has
> multiple apps (websockets, XMPP, SIP, IMAP, ...)  running it can
> even synchronize the keepalives it sends for all of them (so that
> radio is active only once during the cycle),

Excellent idea :-)

> but for the server initiated keepalives it can't do the same.

That's an excellent reason to use per-hop keepalives with a proxy
on the other side of the mobile link...

Timing needs are highly application dependent.  If you are offering a
web-based chat service, the server might want to know aggressively so
it can update "users online", but if it's just a channel to send
interactive wiki updates out, the server might have a long timeout -
reducing when the server is loaded.

> I've always wondered if all those warnings and nice words in RFCs
> help, but if/when we specify the server-initiated keepalive frame,
> the above case should be explained, so the servers would not use if
> carelessly. I think the gist should be so that the client is in
> charge of keeping NATs, firewalls, proxies and all that stuff (which
> is mostly related to the clients current point of attachment) happy,
> while the server should only worry about its own resources and those
> related to it, such as the load balancers.

Exactly: Both sides should worry about their own resources, and their
own application-specific needs.

I don't think the client is more special than the server in that way.

Negotiation is not essential, and it could be made an optional
extension.  It's useful because it reduces the overheads compared with
pings.  Up front negotation is not as good as a "send me keepalives
every N seconds of idle time" which can be sent by either side at any
time and override the previous setting.

-- Jamie