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

[Jamie Lokier <[e-mail]>]

[e-mail] wrote:
>    Unfortunately, I bet may NATs just drop the connection without
>    notifying the endpoints (e.g. never sends a RST).

Correct.  I've never seen a NAT send a RST.

In fact they *can't* send RST if the drop is due to routing update or
equipment reboots / failure.

Automatic routing updates are the most annoyingly subtle, because
typically nobody realises there's a problem, only that connections
drop from time to time.

>    This could become problematic for websockets, I'm not sure.

Yes, it will, unless applications use timeouts and automatic
reconnection.

>    Keepalives may help some,

Keepalives have two roles, and they actually have *distinct* timing
requirements:

    1. To tell NATs / SPIs / TCP relays / HTTP proxies (CONNECT)
       not to drop the connection.

    2. To tell the client application that the connection is still
       present so it knows when to abort and make a *new* connection.

The timeout needed for 1 is typically larger than the timeout for 2
but it depends on the app.

1 is network dependent; 2 is application dependent.
   
>    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.

   - I see about 1000 such breakages very day, admittedly on the same
     corporate national private network.

   - I see them occasionally elsewhere when connecting to servers.

   - Whenever a router is rebooted, this happens.
     This happens a lot in some houses with flaky ADSL routers.
     Even Apple's kit...

     (A very few routers are smart enough to persist NAT state across
     reboots, but it's rare, and I've never heard of it in a home router.)

>    I agree this is an important point. If I'm writing an application on
>    top of the WebSocket API, is it my responsibility to deal with
>    keepalives and connection failures due to NAT timer resets or reboots,
>    or does the protocol do somethig for me in this regard? I suppose the
>    current draft (-75) is pretty silent on this, which means it's all up
>    to the application programmer. That sounds a bit unreasonable if we
>    want the app development to be really simple. Probably, even if the
>    app developers figured out how to do it, they probably would not do it
>    in an optimal manner. So, I suppose it would be good to have either an
>    extension (or a subprotocol) to deal with this. At least it's a piece
>    of code that all client side apps will need anyway. I am not sure to
>    which level it needs to be standardized, but there has to be some way
>    to get it done.
> 
>    Is this still an open issue or has it been discussed and resolved in
>    some way already?

It is still being debated with no clear tracking and no resolution in sight.

There is currently no consensus on whether the application should
handle these network issues itself, or if the WebSocket implementation
should play a role.

Approximate divide: Browser implementers and WHATWG editors { ;-) }
appear to prefer the application handles these issues or ignores them
as it chooses choose, so that WebSocket implementation itself is simple.

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

The current draft's direction is to push it to the application
programmer, either to keep WebSocket itself simple, or to make it a
thin wrapper around TCP (even though it's quite unlike TCP).

I suspect some supporters of latter approach are still thinking of the
80s and early 90s when a TCP connection was a reliable byte pipe.  It
isn't any more (it never was but the issues are more widespread now.)

-- Jamie