Subject: [hybi] Keep-Alive, was: Hello frames?

From: Greg Wilkins <[email-masked]>
Date: Sun, 6 Mar 2011 08:01:49 +1100

On 5 March 2011 18:54,  <[email-masked]> wrote:
> Anyways, I just thought we may want to look into SIP's solution to
> this issue....

Well I think the first thing we need to decide is if we want to do
something about this either now or in an early rev of the spec.

The characteristic of this problem is that it is very hard to solve
well (send keep alives at just the right frequency), very easy to
solve badly (send keep alives very frequently or reopen after every
close(which you might not detect)) and really easy to not solve at all
(and hope the user is busy enough to keep the connection alive and not
fussy enough to care if it locks up when idle).

Given that bad or non solutions are easy, then if we leave this
problem to the applications, then we can expect a large number bad and
non solutions to be deployed.    Worse still, once applications have
been deployed with a bad solution, it will make it harder for future
work on the protocol to fix the problem, because the applications will
be out there pinging away at 15s intervals and will remain there until
all the old browsers are replaced.

I believe that it is the goal of websockets to provided long lived
bidirectional connections.   It strikes me as counterproductive if the
standard provides no mechanism to ensure that the connection are
either long lived or still connected.  It is going to result in many
many frustrated tic tack toe players who are waiting for hours for
their opponent to move, when  a NAT router has just timedout silently.

If we don't want to complicate the base protocol, then we should have
standard keep-alive extension that will use a combination of dynamic
timeouts and connection retries to both keep a connection alive and to
discover the best timeout to use for a given destination.

regards

---

From: [email-masked]
Date: Sat, 5 Mar 2011 17:42:44 -0800

> all the old browsers are replaced.

Right. Very important point.

> their opponent to move, when  a NAT router has just timedout silently.

Indeed.

> discover the best timeout to use for a given destination.

I am OK with having keep-alive extension separate from the base protocol.
But, as enabling long lived bidirectional connections is being one of 
the important goals of WebSocket, it is still a high priority issue 
especially when we can see possible bad user experience without 
addressing it.

Having said that, we are probably not able to come up with "the best"
ping intervals that stands forever since there would be many variable 
factors overtime that could invalidate our best assumption we can
currently make. Therefore, we should define a framework that can let 
us later adjust keepalive timeouts, perhaps as BCP as we find something 
better in the future.

How about introducing something like in the handshake:

   Sec-WebSocket-KeepAlive: interval=120, timeout=10

Client MAY add this in its request(handshake) if these values are 
important for the client, then the server SHOULD add the same header
with final values which was determined considering what client 
requested for if any, as well as server side arbitrary factors such as 
current load. Then the client MUST follow the final values provided
by the server, if the header is present in 101 response.

We should also recommend default values in the base protocol that we
think best for the time being (e.g. 120 sec/10 sec, as in SIP).

- Yutaka

---

From: Andy Green <[email-masked]>
Date: Sun, 06 Mar 2011 09:31:17 +0000

On 03/06/2011 01:42 AM, Somebody in the thread at some point said:

Hi -

> think best for the time being (e.g. 120 sec/10 sec, as in SIP).

Right it'd be nice to do it in the header, because in addition to the 
client being able to propose, and the server being able to decide, it's 
possible for intermediaries to rewrite the client numbers downwards as 
they pass it through if in fact they have a shorter close-on-idle policy 
themselves.  There's no point the server mandating an idle timeout that 
can never be reached because an intermediary will drop the connection 
before.  So it can serve as a probe to find the smallest idle timeout 
period amongst websocket-aware guys anyway.

Also the header is definitely always talking about things that apply to 
the whole connection, which is appropriate for connection idle timeout.

How about this definition of what this "keep alive" or "idle timeout" 
means -->

If either side saw any kind of websocket traffic come from their peer, 
they can reset their idle timeout on their side (because they know the 
channel is working).  So if there is even slow periodic data coming from 
the peer you never have to send a PING.

If you don't see any other traffic come from the peer for, say, 0.5 of 
the idle timeout period and each 0.1 additionally if needed, you should 
try to provoke incoming traffic by sending a PING.  If still no incoming 
traffic is coming from the peer by the idle timeout period, they should 
close the connection from their side.  At that time, it doesn't seem to 
make sense to try to use the controlled close stuff because we just 
identified the link won't carry any traffic, so just close the socket.

-Andy

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 8 Mar 2011 00:01:25 +0000

> > Sec-WebSocket-KeepAlive: interval=120, timeout=10

[gab] This issue is not specific to websockets, so it seems to me that it should be addressed in a more general fashion, otherwise there will be more keepalives than necessary (if there is independent treatment instead of coordination among websockets, comet, etc). I'd say we only keep the basic mechanisms in the draft (Ping/Pong, unsolicited Pong), and leave the rest for another separate draft which could be pursued either in HyBi or elsewhere.

---

From: [email-masked]
Date: Mon, 7 Mar 2011 20:00:57 -0800

> [gab] This issue is not specific to websockets, so it seems to me
> that it should be addressed in a more general fashion, otherwise

Yes, I totally agree. We all wish there was a way to reliably keep TCP 
connection open in a generic way...
 
> there will be more keepalives than necessary (if there is 
> independent treatment instead of coordination among websockets, 
> comet, etc).

If some negotiation is desired, though, then it would be protocol
specific, wouldn't it?

> I'd say we only keep the basic mechanisms in the draft 
> (Ping/Pong, unsolicited Pong), and leave the rest for another 
> separate draft which could be pursued either in HyBi or elsewhere. 

I understand, getting the base protocol out asap is most critical 
for now, and addressing this with another draft is fine by me.

With my implementer's hat on, I'd still hope WS-layer could flexibly 
and (more) reliably handle the connection lifetime 
before applications start implementing their own arbitrary 
keep-alives, which could be a mess and/or such a burden for lazy
developers.

Best.
- Yutaka

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 8 Mar 2011 15:06:57 +1100

On 8 March 2011 11:01, Gabriel Montenegro
<[email-masked]>wrote:

> [gab] This issue is not specific to websockets, so it seems to me that it
> should be addressed in a more general fashion,

the negotiation/declaration of connection timeouts can indeed be done more
generically and I hope that some common headers for that can be agreed.

But the actual keep alive process, once idle times are known, will have to
protocol specific.

>  I'd say we only keep the basic mechanisms in the draft (Ping/Pong,
> unsolicited Pong), and leave the rest for another separate draft which could
> be pursued either in HyBi or elsewhere.
>

I think we keep the basic mechanisms in the base protocol, but that we have
a standard extension for keep-alive in the draft, so as to prevent bespoke
solutions being developed and widely deployed.

cheers

---

From: [email-masked]
Date: Tue, 8 Mar 2011 13:03:41 -0800

http://datatracker.ietf.org/doc/draft-thomson-hybi-http-timeout/
Nice move! Particularly, Connection-Timeout header can be reused for 
WebSocket connection lifetime management and good candidate for a work 
item to this group.

One thing left unclear to me is whether timeout for 'Pong' needs to be 
defined within WebSocket (either base protocol or extension) as ping/pong 
is WebSocket specific.

- Yutaka

> that it should be addressed in a more general fashion, 
> 
> the negotiation/declaration of connection timeouts can indeed be 
> done more generically and I hope that some common headers for that 
> can be agreed.
> 
> But the actual keep alive process, once idle times are known, will 
> have to protocol specific.
> 
>  
> unsolicited Pong), and leave the rest for another separate draft 
> which could be pursued either in HyBi or elsewhere.
> 
> I think we keep the basic mechanisms in the base protocol, but that 
> we have a standard extension for keep-alive in the draft, so as to 
> prevent bespoke solutions being developed and widely deployed.
> 
> cheers