Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On 19 July 2011 21:42, Glenn Maynard gl...@zewt.org wrote: On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller linuxw...@outer-planes.net wrote: Sending at that rate will result in a disconnected socket for most of the networks I've seen. There are still an exorbitant number of routers, proxies, firewalls, and load balancers deployed and configured such that they will (silently!) drop a connection if there is no traffic for 5-10 minutes. I've never encountered a network that'll disconnect with 10-15-minute keepalives; there may be some, but I doubt most. A few weeks ago I was completely with you. But I just moved into an office where idle connections randomly die - I now have 15 *second* ping-pongs on SSH connections just to make sure they stay open. It's looking like I'm going to have to do the same for XMPP too. I'm sharing the office with a fairly competent technology company, the last place I would have expected such a broken network configuration - but there you have it. Some people think HTTP is the internet :) Regards, Matthew
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Jul 26, 2011, at 16:57, Matthew Wild wrote: On 19 July 2011 21:42, Glenn Maynard gl...@zewt.org wrote: On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller linuxw...@outer-planes.net wrote: Sending at that rate will result in a disconnected socket for most of the networks I've seen. There are still an exorbitant number of routers, proxies, firewalls, and load balancers deployed and configured such that they will (silently!) drop a connection if there is no traffic for 5-10 minutes. I've never encountered a network that'll disconnect with 10-15-minute keepalives; there may be some, but I doubt most. A few weeks ago I was completely with you. But I just moved into an office where idle connections randomly die - I now have 15 *second* ping-pongs on SSH connections just to make sure they stay open. It's looking like I'm going to have to do the same for XMPP too. I'm sharing the office with a fairly competent technology company, the last place I would have expected such a broken network configuration - but there you have it. Some people think HTTP is the internet :) I tried to warn y'all... (-: - mm http://goo.gl/voEzk smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, Jul 26, 2011 at 4:57 PM, Matthew Wild mwi...@gmail.com wrote: I've never encountered a network that'll disconnect with 10-15-minute keepalives; there may be some, but I doubt most. A few weeks ago I was completely with you. But I just moved into an office where idle connections randomly die - I now have 15 *second* ping-pongs on SSH connections just to make sure they stay open. It's looking like I'm going to have to do the same for XMPP too. I'm sharing the office with a fairly competent technology company, the last place I would have expected such a broken network configuration - but there you have it. Some people think HTTP is the internet :) But that's the rare exception, not most. -- Glenn Maynard
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Jul 20, 2011, at 15:05, Glenn Maynard wrote: On Wed, Jul 20, 2011 at 3:50 PM, Matthew A. Miller linuxw...@outer-planes.net wrote: If a server is sending (in)frequent keepalives, and the client knows it should have them (more) less, then this protocol allows for that to be opted-in on a per-connection basis. Both servers and clients should use as infrequent keepalives as their network and local network policy allows, and the other side shouldn't need to ask the other side to send keepalives *more* frequently. As I said before, Your Milage May Vary. Many of the networks I deal with an certain keepalive frequencies are good for one set of conditions but not another. It almost seems you're suggesting a service should effectively run a separate connection manager for each variant of device/platform/network/solar activity/phase of moon/etc. That doesn't sound very scalable to me. (I said nothing of the sort.) Then my apologies. Sending at the same rate usually means each end will detect a stale connection at roughly the same time. That's a Good Thing™. I don't see any significant problem if one side detects a disconnection more quickly than the other; it's going to happen anyway. With any reasonable keepalive interval, they're likely to be many minutes apart anyhow, and the common causes of disconnections are always going to be asymmetric (losing a WiFi/mobile connection; a PC crashing). There are architectures where knowing sooner can improve As Ben stated, it's an optional feature; if you don't want it, don't use it. Add everything under the moon; it's okay since it's all optional is no sane development strategy. I would agree adding something just for adding's sake is not sane. I don't think this is one of those cases. Maybe we can agree to disagree. Also, I'm not sure what you mean by stalled. XEPs -0124 and -0206 are DRAFT, updated with implementation experience. Are you suggesting we should progress them to FINAL, or do you have a specific set of problems that need immediate attention? I gave a detailed, specific list of feedback several months ago. I received no (editorial) reply. http://mail.jabber.org/pipermail/bosh/2011-May/000380.html Thank you for the reference. I don't regularly monitor the more focused lists. I'll read it through and try to respond. - mm http://goo.gl/voEzk smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On 7/19/11 7:42 PM, Glenn Maynard wrote: On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller linuxw...@outer-planes.net mailto:linuxw...@outer-planes.net wrote: Sending at that rate will result in a disconnected socket for most of the networks I've seen. There are still an exorbitant number of routers, proxies, firewalls, and load balancers deployed and configured such that they will (silently!) drop a connection if there is no traffic for 5-10 minutes. I've never encountered a network that'll disconnect with 10-15-minute keepalives; there may be some, but I doubt most. A number of clients will send a keepalive (whitespace or otherwise) every 60-120 seconds; a number of server deployments will send their own at roughly the same rate. This is great for desktops, but less than ideal for mobile. But, this doesn't require negotiation. If a client needs to send keepalives more frequently (due to broken routers) or less frequently (battery life), it doesn't need to discuss that with the server; it can just do it. If a server is unfortunate enough to be behind broken software that drops connections too quickly, it can likewise adjust its own keepalive interval to compensate, without any negotiation; otherwise it should send them infrequently (if at all). Servers shouldn't be sending keepalives every 60-120 seconds. This just seems like an overcomplication that isn't likely to actually negotiate values that make sense. It also seems to assume that the client and server will always send keepalives at the same rate. (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, but it seems like the bosh/xbosh specs have stalled...) Glenn- It makes me chuckle to read you say that this negotiation protocol seems like an overcomplication and then immediately follow that with a suggestion that folks should be using BOSH. ;-) Regardless, this is an optional feature and if you feel it is too burdensome for your project, then you're welcome to skip its implementation, but that doesn't mean it doesn't have technical merits for the protocol community, at-large. Cheers, Ben
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Jul 19, 2011, at 19:42, Glenn Maynard wrote: On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller linuxw...@outer-planes.net wrote: Sending at that rate will result in a disconnected socket for most of the networks I've seen. There are still an exorbitant number of routers, proxies, firewalls, and load balancers deployed and configured such that they will (silently!) drop a connection if there is no traffic for 5-10 minutes. I've never encountered a network that'll disconnect with 10-15-minute keepalives; there may be some, but I doubt most. YMMV My employer has plenty of customers that like to keep the network reigns rather tight. This optional-to-negotiate proposal is one suggestion for dealing with them real-world deployments. A number of clients will send a keepalive (whitespace or otherwise) every 60-120 seconds; a number of server deployments will send their own at roughly the same rate. This is great for desktops, but less than ideal for mobile. But, this doesn't require negotiation. If a client needs to send keepalives more frequently (due to broken routers) or less frequently (battery life), it doesn't need to discuss that with the server; it can just do it. If a server is unfortunate enough to be behind broken software that drops connections too quickly, it can likewise adjust its own keepalive interval to compensate, without any negotiation; otherwise it should send them infrequently (if at all). Servers shouldn't be sending keepalives every 60-120 seconds. If a server is sending (in)frequent keepalives, and the client knows it should have them (more) less, then this protocol allows for that to be opted-in on a per-connection basis. It almost seems you're suggesting a service should effectively run a separate connection manager for each variant of device/platform/network/solar activity/phase of moon/etc. That doesn't sound very scalable to me. This just seems like an overcomplication that isn't likely to actually negotiate values that make sense. It also seems to assume that the client and server will always send keepalives at the same rate. Sending at the same rate usually means each end will detect a stale connection at roughly the same time. That's a Good Thing™. As Ben stated, it's an optional feature; if you don't want it, don't use it. (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, but it seems like the bosh/xbosh specs have stalled...) I don't agree with that statement, as others have already indicated reasons for. Also, I'm not sure what you mean by stalled. XEPs -0124 and -0206 are DRAFT, updated with implementation experience. Are you suggesting we should progress them to FINAL, or do you have a specific set of problems that need immediate attention? - mm smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Wed, Jul 20, 2011 at 3:50 PM, Matthew A. Miller linuxw...@outer-planes.net wrote: If a server is sending (in)frequent keepalives, and the client knows it should have them (more) less, then this protocol allows for that to be opted-in on a per-connection basis. Both servers and clients should use as infrequent keepalives as their network and local network policy allows, and the other side shouldn't need to ask the other side to send keepalives *more* frequently. It almost seems you're suggesting a service should effectively run a separate connection manager for each variant of device/platform/network/solar activity/phase of moon/etc. That doesn't sound very scalable to me. (I said nothing of the sort.) Sending at the same rate usually means each end will detect a stale connection at roughly the same time. That's a Good Thing™. I don't see any significant problem if one side detects a disconnection more quickly than the other; it's going to happen anyway. With any reasonable keepalive interval, they're likely to be many minutes apart anyhow, and the common causes of disconnections are always going to be asymmetric (losing a WiFi/mobile connection; a PC crashing). As Ben stated, it's an optional feature; if you don't want it, don't use it. Add everything under the moon; it's okay since it's all optional is no sane development strategy. Also, I'm not sure what you mean by stalled. XEPs -0124 and -0206 are DRAFT, updated with implementation experience. Are you suggesting we should progress them to FINAL, or do you have a specific set of problems that need immediate attention? I gave a detailed, specific list of feedback several months ago. I received no (editorial) reply. http://mail.jabber.org/pipermail/bosh/2011-May/000380.html -- Glenn Maynard
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue Jul 19 21:19:15 2011, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Whitespace Keepalive Negotiation FWIW, this one seems sensible for the XSF to adopt. I'd like to make some observations: 1) I think the negotiation should be more like resource binding - the client offers a suggestion, the server sets the interval based on that suggestion. I don't see a need for a back-and-forth where the client's value is rejected as being out of range. 2) If either party sends any data, including whitespace, the timer MUST be restarted. 3) Typically, I'd expect a client to negotiate a high keepalive, and then issue the whitespace itself, in order to control transmission timing. (A mobile client will want to send all its keepalive traffic at once). 4) Servers SHOULD use XEP-0199 or XEP-0198 to actively solicit traffic from silent clients, and SHOULD only terminate the connection of unresponsive clients, rather then merely silent ones. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
Thanks for the time Dave. I'm going to check out the API. We will definitely be using your software. The Gears software sounds great. Let me know what you can sell the IP30 for. We will be low quantity at the outset. An order of 5 would be likely. Charlie Youakim Partner cell: 651-343-4692 fax: 888-804-1783 web: www.passportparking.com On Wed, Jul 20, 2011 at 5:27 PM, Dave Cridland d...@cridland.net wrote: On Tue Jul 19 21:19:15 2011, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Whitespace Keepalive Negotiation FWIW, this one seems sensible for the XSF to adopt. I'd like to make some observations: 1) I think the negotiation should be more like resource binding - the client offers a suggestion, the server sets the interval based on that suggestion. I don't see a need for a back-and-forth where the client's value is rejected as being out of range. 2) If either party sends any data, including whitespace, the timer MUST be restarted. 3) Typically, I'd expect a client to negotiate a high keepalive, and then issue the whitespace itself, in order to control transmission timing. (A mobile client will want to send all its keepalive traffic at once). 4) Servers SHOULD use XEP-0199 or XEP-0198 to actively solicit traffic from silent clients, and SHOULD only terminate the connection of unresponsive clients, rather then merely silent ones. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/**byowner/user/dwd/bookmarks/http://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
My apologies. Wrong Dave! Charlie Youakim Partner cell: 651-343-4692 fax: 888-804-1783 web: www.passportparking.com On Wed, Jul 20, 2011 at 5:31 PM, Charles Youakim charlie.youa...@passportparking.com wrote: Thanks for the time Dave. I'm going to check out the API. We will definitely be using your software. The Gears software sounds great. Let me know what you can sell the IP30 for. We will be low quantity at the outset. An order of 5 would be likely. Charlie Youakim Partner cell: 651-343-4692 fax: 888-804-1783 web: www.passportparking.com On Wed, Jul 20, 2011 at 5:27 PM, Dave Cridland d...@cridland.net wrote: On Tue Jul 19 21:19:15 2011, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Whitespace Keepalive Negotiation FWIW, this one seems sensible for the XSF to adopt. I'd like to make some observations: 1) I think the negotiation should be more like resource binding - the client offers a suggestion, the server sets the interval based on that suggestion. I don't see a need for a back-and-forth where the client's value is rejected as being out of range. 2) If either party sends any data, including whitespace, the timer MUST be restarted. 3) Typically, I'd expect a client to negotiate a high keepalive, and then issue the whitespace itself, in order to control transmission timing. (A mobile client will want to send all its keepalive traffic at once). 4) Servers SHOULD use XEP-0199 or XEP-0198 to actively solicit traffic from silent clients, and SHOULD only terminate the connection of unresponsive clients, rather then merely silent ones. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/**byowner/user/dwd/bookmarks/http://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On 07/19/2011 10:19 PM, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Whitespace Keepalive Negotiation Abstract: This specification defines a method for negotiating how to send keepalives in XMPP. URL: http://www.xmpp.org/extensions/inbox/keepalive.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. hmm I'm not sure this XEP is really usefull. How can server guess the network configuration between client and server? Client may be on a network that cuts connections after 30 seconds of inactivity and server propose a timeout between 60 and 120. That means we cannot connect to this server? Or send whitespace every 30 seconds and be a bad client? the 2nb point of implementation notes is hard to respect: server and client may not know network configuration between them. Whitespace are very small things, is it really usefull for the server to say don't send that too often? I can understand that for xmpp ping (XEP-0199), but for whitespace ... I'm not sure very vague information re usefull. Like a period of time significantly longer than the negotiated value That doesn't help implementors to choose this time. But maybe it's not good to force this time in the XEP. Conclusion: I can understand this XEP for xmpp ping (quite long stanza), but I don't find it very usefull for whitespace ping. Just my opinion -- Yann
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, Jul 19, 2011 at 6:31 PM, Yann Leboulanger aste...@lagaule.orgwrote: Whitespace are very small things It doesn't matter how small the things are, if a single packet causes a battery-powered device to wake up WiFi and drain battery for a while before it goes back into a power saving state. Bursting ten packets isn't likely to be much more expensive than sending one. I'm not sure why the server needs to be involved in this, though. Keepalives should be sent from client to server; that's enough to keep the TCP connection and, more importantly, any NAT alive. I don't know why the server would also send keepalives to the client--and without that there's nothing to negotiate. -- Glenn Maynard
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tuesday, July 19, 2011 05:02:30 PM Glenn Maynard wrote: On Tue, Jul 19, 2011 at 6:31 PM, Yann Leboulanger aste...@lagaule.orgwrote: Whitespace are very small things It doesn't matter how small the things are, if a single packet causes a battery-powered device to wake up WiFi and drain battery for a while before it goes back into a power saving state. Bursting ten packets isn't likely to be much more expensive than sending one. I'm not sure why the server needs to be involved in this, though. Keepalives should be sent from client to server; that's enough to keep the TCP connection and, more importantly, any NAT alive. I don't know why the server would also send keepalives to the client--and without that there's nothing to negotiate. Whitespace keepalives serve two purposes: 1) Keep connections from being killed by routers. 2) Inducing TCP cleanup, in the event the peer is gone but you were never notified. If a client leaves the network without disconnecting from the XMPP server, then in theory the client session could last forever. The session will only terminate when the server's TCP stack fails while sending data to it, which will happen either at the next stanza or with whitespace. Justin
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, Jul 19, 2011 at 8:19 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: Whitespace keepalives serve two purposes: 1) Keep connections from being killed by routers. Client-originated keepalives normally deal with this, so negotiation isn't needed here--just send keepalives at the needed rate (typically 10-15 minutes). 2) Inducing TCP cleanup, in the event the peer is gone but you were never notified. The server might want to send keepalives for this, but infrequently; on the order of 30-60 minutes. I don't think negotiation is useful in either case, since the keepalives of each side are determined by that side's own requirements. -- Glenn Maynard
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Jul 19, 2011, at 18:55 , Glenn Maynard wrote: On Tue, Jul 19, 2011 at 8:19 PM, Justin Karneges justin-keyword-jabber.093...@affinix.com wrote: Whitespace keepalives serve two purposes: 1) Keep connections from being killed by routers. Client-originated keepalives normally deal with this, so negotiation isn't needed here--just send keepalives at the needed rate (typically 10-15 minutes). 2) Inducing TCP cleanup, in the event the peer is gone but you were never notified. The server might want to send keepalives for this, but infrequently; on the order of 30-60 minutes. I don't think negotiation is useful in either case, since the keepalives of each side are determined by that side's own requirements. Sending at that rate will result in a disconnected socket for most of the networks I've seen. There are still an exorbitant number of routers, proxies, firewalls, and load balancers deployed and configured such that they will (silently!) drop a connection if there is no traffic for 5-10 minutes. A number of clients will send a keepalive (whitespace or otherwise) every 60-120 seconds; a number of server deployments will send their own at roughly the same rate. This is great for desktops, but less than ideal for mobile. - mm
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller linuxw...@outer-planes.net wrote: Sending at that rate will result in a disconnected socket for most of the networks I've seen. There are still an exorbitant number of routers, proxies, firewalls, and load balancers deployed and configured such that they will (silently!) drop a connection if there is no traffic for 5-10 minutes. I've never encountered a network that'll disconnect with 10-15-minute keepalives; there may be some, but I doubt most. A number of clients will send a keepalive (whitespace or otherwise) every 60-120 seconds; a number of server deployments will send their own at roughly the same rate. This is great for desktops, but less than ideal for mobile. But, this doesn't require negotiation. If a client needs to send keepalives more frequently (due to broken routers) or less frequently (battery life), it doesn't need to discuss that with the server; it can just do it. If a server is unfortunate enough to be behind broken software that drops connections too quickly, it can likewise adjust its own keepalive interval to compensate, without any negotiation; otherwise it should send them infrequently (if at all). Servers shouldn't be sending keepalives every 60-120 seconds. This just seems like an overcomplication that isn't likely to actually negotiate values that make sense. It also seems to assume that the client and server will always send keepalives at the same rate. (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, but it seems like the bosh/xbosh specs have stalled...) -- Glenn Maynard
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
On Tue, 2011-07-19 at 19:13 -0600, Matthew A. Miller wrote: This is great for desktops, but less than ideal for mobile. Perhaps a generic please apply resource policy $foo-spec could be thougt up? So you could tell the server that you're on a constrained link and have it activate various measures. Or do we have this already? identity category=client type=phone/ ? How about a Informal XEP about applying ping/keepalive/buffering based on that? -- Kim Alvefur z...@zash.se
Re: [Standards] Proposed XMPP Extension: Whitespace Keepalive Negotiation
Hi, Following are the thoughts: Each side can send its own keep-alive whitespace packet intelligently considering the traffic and the reqmt to keep persistent connections. Devices specifically should intelligently see the n/w behind which they are and keep on calibrating the keep alive whitespace until they reach a point where connection does not break. So this is application specific reqmt and would differ from app to app. Thanks Regds, Amandeep On Wed, Jul 20, 2011 at 7:17 AM, Kim Alvefur z...@zash.se wrote: On Tue, 2011-07-19 at 19:13 -0600, Matthew A. Miller wrote: This is great for desktops, but less than ideal for mobile. Perhaps a generic please apply resource policy $foo-spec could be thougt up? So you could tell the server that you're on a constrained link and have it activate various measures. Or do we have this already? identity category=client type=phone/ ? How about a Informal XEP about applying ping/keepalive/buffering based on that? -- Kim Alvefur z...@zash.se
