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

[Jamie Lokier <[e-mail]>]

Dave Cridland wrote:
> First, in IMAP, we've found that the client needs to be in control,  
> as it often knows better - however, others (including Mark Crispin)  
> found that having the server send keepalives when it'd otherwise be  
> shutting down the session is useful. Note that in IMAP, there are  
> technically no actual keepalives, but servers can send an ignorable  
> "* OK", and in extreme cases, can fake a delivery to cause a client  
> to do something. Clients have a NOOP command. I suspect a lot of the  
> issues with IMAP relate to there being no simple way for the server  
> to ping the client built-in to the protocol.
> 
> In XMPP, however, we've found that having the ability to ping the  
> client from the server is very useful. In XMPP, there's two distinct  
> protocol features which enable TCP-level keepalive. Firstly, either  
> side may send a SP character between stanzas. Secondly, each side may  
> actually ping the other. Having the server send a SP on an idle  
> session is useful for defeating NAT timeouts, whereas the ping  
> (XEP-0199) is extremely useful to definitively check reachability.

That is an excellent description, thank you.  I think you got it spot
on with XMPP, having both idle one-way keepalives and a ping option
that either side can use at any time.

The ability to definitively check reachability with a ping is useful
in some situations.  Especially with long keepalives giving a
"probably online (may be 2 minutes out of date)" state, sometimes
you need to upgrade that to "definitely online".

Due to keepalives being the primary bandwidth cost in mostly-idle
applications, I've studied optimising them.  I found one-way keepalive
on idle connections are most packet-efficient if there are asymmetric
timeout requirements; expediting a keepalive when you think the local
TCP is about to send a delayed ACK (i.e. when you just received
something after an idle period) increases packet-efficiency, and that
magically settles into a one-way request-response pattern when there
is a symmetric timeout requirement and no real data happening.  That
can be assembled into a single simple algorithm, but it's not the one
people tend to come up with when they first think about it.

> >If there really is a requirement for the server to see keepalives  
> >at a certain minimum rate (for instance so that it can abandon  
> >stale connections), I would then have that negotiated so that the  
> >server can tell that back to the client who would still do the  
> >sending. But I'm not sure if that's needed.
> 
> I think we need all cases possible, then some sensible advice to  
> implementors. In the XSF, we've learned a lot about how to defeat NAT  
> timeouts and get early failure detection, and the main thing we've  
> learned is that things change - only a year or two back using  
> long-lived TCP over mobile networks was really difficult, whereas now  
> it's much better.

+1, twice!

> What's more interesting, to me, is what to do if the connection does  
> break.
> 
> If each connection is granted an identifier, and - moreover - the  
> client can request a specific identifer to be reattached during the  
> HTTP Upgrade negotiation at a known sequence point, then in principle  
> a WebSocket needn't be conceptually broken even if connectivity is  
> entirely lost due to a NAT reboot.
> 
> Something very similar happens with XEP-0198, where XMPP clients can  
> reacquire a running XMPP session after TCP is lost.

I've looked at something very similar in my multiplexing/tunnelling
applications, and that is indeed a useful feature.

I'm not sure if it's stated as a requirement, but some of the
WebSocket discussion implies it is *intended* to provide a
quasi-reliable connection between web applications and server.

Unfortunately TCP does not provide that reliability on current networks.

I suspect automatic session resumption would be welcomed with open
arms by application developers, especially those who don't want
anything complicated, just something that's reliable.

HTTP and XHR effectively does provide it: The browser retries GET
requests automatically after a timeout if it doesn't get a response.
So web application authors are used to expecting some level of
automatic robustness.

It looks like XMPP people have valuable implementation experience that
is directly relevant.

-- Jamie