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

[<[e-mail]>]

Hi Martin,

What you say probably makes sense. So, it would be good to define the keepalive frame so that both the client and the server can send it. I'm just worrying about the following tradeoff:

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.) 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), but for the server initiated keepalives it can't do the same.

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. 

Markus


>-----Original Message-----
>From: ext Thomson, Martin [mailto:[e-mail]] 
>Sent: 20 April, 2010 10:10
>To: Isomaki Markus (Nokia-CIC/Espoo); [e-mail]; 
>[e-mail]
>Cc: [e-mail]
>Subject: RE: [hybi] NAT reset recovery? Was: Extensibility mechanisms?
>
>Responses are of some use at the application layer, so the 
>second option might make some sense.
>
>However, negotiation seems like overkill for this sort of 
>mechanism.  Each peer has some expectations and constraints 
>that it knows best.  Let them each take whatever action they 
>need to ensure that the connection stays alive.
>
>If a keep-alive frame is defined, either peer could 
>unilaterally initiate it.  There's no technical reason why 
>this shouldn't be allowed.  If the server cares, and it 
>doesn't see any activity from the client, it could use the 
>keep-alive too.
>
>As Jamie points out, the server frequently doesn't care.  More 
>to the point - the server can't do little about it if the 
>connection does go away.  (I can imagine use of other channels 
>to prod the client into wakefulness, but that's not something 
>inherent to WS.)  Rather than outright prohibition, I'd 
>instead prefer to discourage server use of keep-alive (SHOULD NOT).
>
>Servers might know better - we have a server that has a 5 
>minute TCP "go dead" interval on the load balancer in front of 
>it.  That server should not be outright prevented from sending 
>a 4:55 keep-alive if it sees nothing from a client.
>
>--Martin
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Tuesday, 20 April 2010 4:51 PM
>> To: Thomson, Martin; [e-mail]; [e-mail]
>> Cc: [e-mail]
>> Subject: RE: [hybi] NAT reset recovery? Was: Extensibility 
>mechanisms?
>> 
>> Hi,
>> 
>> Martin Thomson wrote:
>> >
>> >Furthermore, you don't need a response, TCP provides ACKs.  
>A one-way 
>> >exchange of as little as a single byte should be enough to keep any 
>> >bindings alive in (TCP) intermediaries.
>> >
>> 
>> This is true.
>> 
>> I would say there are two options to do keepalives:
>> i) Define a keepalive frame that the client sends. There is no 
>> websocket level response but the TCP ACK is still enough to 
>keep NATs, 
>> firewalls etc. open.
>> Ii) Define a keepalive request frame that the client sends and 
>> keepalive response that the server uses to respond to it. 
>The response 
>> is not really necessary for NATs etc., but might help the client to 
>> notice a broken connection faster. (I'm not sure if this is 
>true but I 
>> remember this was an argument in another protocol, SIP, why 
>keepalive 
>> over TCP was done in that way.) The response may make the protocol 
>> more complicated, though, as people have commented.
>> 
>> I would not want to make the keepalives peer-to-peer in a sense that 
>> also the server could send keepalives. I think the client 
>should be in 
>> charge. The reason is that as a client developer for a 
>mobile device I 
>> would like to be able to send keepalives as infrequently as possible.
>> We have had some bad experiences with IMAP servers sending stuff 
>> frequently back to the client (presumably because not all 
>clients are 
>> clever enough to do any keepalives themselves - this is a risk of 
>> course if we don't specify this at all in websocket spec), and the 
>> client has no way to affect their rate, which has been fixed.
>> 
>> 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.
>> 
>> Markus
>