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

[Jamie Lokier <[e-mail]>]

Vladimir Katardjiev wrote:
> On 19 apr 2010, at 14.10, Jamie Lokier wrote:
> Take, for no particular reason, the case of a web-based Tic Tac Toe
> application. Suppose it is the opponent's turn to move, but he went
> afk. Meanwhile, some NAT on the path decided it wants to close the
> connection. Since it's not my turn to move, my client should not have
> any reason to send traffic over the connection. It also doesn't have
> any set time it expects a response (because the other party is human
> the application has no way to know when he'll move).

Yes, that's the main way in which WebSocket Tic Tac Toe breaks.

> - The client can actually be told when a connection is dropped by
> onclose(wasClean=false) being triggered, and thus reestablish the
> connection. I mean, if you open a connection, surely you want to
> know if it's no longer available...

Sounds like a good plan :-)

> - Our hypothetical amateur programmer, testing his websocket
> connection against localhost, won't see the need for keepalives, but
> the protocol requiring them will stop his application from failing
> on the Wild Web. All he needs to do is echo back the bytes the
> browser sent, and the expert browser programmer handles the rest.

Keepalives are great, but this isn't a nice way to implement them.

If they are required by the protocol, then the protocol should
implement them itself.  (Besides, echo-reply isn't always bandwidth
efficient, depending on keepalive the needs of client and server).

> So I'd rather say I am having trouble seeing what applications would _not_ want keepalive functionality as part of the base offering of WebSockets.

Well, there may be disagreement over what type of keepalive, because
the optimal choice is both application dependent _and_ network link
dependent.

At the moment, it can be implemented by the WebSocket application
(albeit suboptimally, and any network link dependency has to be known
to the application as well).

> >>   but I bet NATs are smart enough to break even there too.  Data is
> >>   needed....
> > 
> > I can give you personal experience.  Yes: NATs do break connections
> > with traffic on them.
> 
> Of course, that's not the only thing that can fail silently. Lost
> connections due to other issues than NATs are also prevalent,
> anything from a cord being cut to someone using a wireless
> connection and going into a tunnel.

Yes, although those might be considered less transient errors :-)

The thing with NAT reset is that TCP won't recover, but reconnection
works immediately.

If you go into a tunnel and come out, TCP will recover.  If you cut a
cord, TCP won't recover but neither will reconnection work immediately.

So NAT reset is a bit different from other network faults.
Quick detection and recovery is useful with it.

> (This only appears to contradict what I said above on mobile keepalives if you assume all mobile networks are equal. They're not. What I want to say though is that even though we assume a general case where the connection WILL fail if it's left on its own, we should make it possible to make the transfer more efficient)

Making the failure event more efficient by pushing keepalive or other
link detection down to the lowest reliable level is generally a good idea.

> > There is currently no consensus on whether the application should
> > handle these network issues itself, or if the WebSocket implementation
> > should play a role.
> > 
> > [...]
> > 
> > Proxy and server implementers seem to prefer that WebSockets handles
> > it, so application programmers get a robust pipe without having to deal
> > with these issues (and it might use the network a bit better).
> 
> This really depends on how you define "robust". I'm okay with
> WebSockets failing because the recovery conditions aren't
> necessarily easy to define, and for some values of robustness you
> need to do stuff like deferring messages on the server-side, and
> then you need to identify the connection that requested them, and
> then authenticate it (if needed) and then you need to determine when
> you're NOT waiting for the robustness recovery, and it just goes on
> and on forever, much like this sentence.

In general you *can't* make a protocol fully robust.  There is always
a failure mode.  But:

> So, yeah. Failure is good. My preference, though, is that the
> protocol itself takes care of the failing part if the failure is due
> to the network conditions, so anything written on top of the
> protocol doesn't have to keep doing the same old networking traps
> every. single. time.

There are very good reasons to distinguish certain classes of failure:

   - Non-failures!  (Peer closes connection due to timeout / resource limit)

   - Those you can recover from quickly and safely (NAT reset)

   - Those which are recoverable but need user conformation (POST data again?)

   - Those which are treated as unrecoverable (DNS failed, or 404 Not Found)

Some of the above list is best done in the WebSocket using
application, but graceful close and NAT reset detection are debatably
better helped by lower layers.

The key characteristic is which ones result in different *desirable*
behaviour from WebSocket application code.

When a condition is an expected behaviour of the network (server
closes connection, NAT reset) *and* it's possible to reopen a
connection and repeat the same messages without causing any problems -
those are particularly useful to distinguish.

Server timeout is also useful to distinguish for a user-interface
reason: User should not be told there is an error when something
happens in normal operation and is not an error.

-- Jamie