Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Waher]

Hello Kevin
We will not exclude the list of course. But not everybody are on the list, or 
listens to the list at all times. And it is good to discuss things with 
interested parties who have interests in the field before, to brainstorm. We 
will not consciously exclude people, on the contrary.
Best regards,
Peter


From: Kevin Smith [mailto:ke...@kismith.co.uk]
Sent: den 30 oktober 2013 10:57
To: XMPP Standards
Subject: Re: [Standards] Standard for Throttling/Queueing Stanzas



On Wed, Oct 30, 2013 at 1:44 PM, Peter Waher 
mailto:peter.wa...@clayster.com>> wrote:
Anybody interested in these questions, please let me know, and I'll include you 
when the time comes to start working on the extensions. (People who have 
already expressed their interest are already added to the list.)

Wouldn't it make most sense to work on this on this list?

/K

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Kevin Smith]

On Wed, Oct 30, 2013 at 1:44 PM, Peter Waher wrote:

>  Anybody interested in these questions, please let me know, and I’ll
> include you when the time comes to start working on the extensions. (People
> who have already expressed their interest are already added to the list.)
>
> **
>

Wouldn't it make most sense to work on this on this list?

/K

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Daniele Ricci]

Hi Peter,
I'm working on a mobile IM based on XMPP, I'd like to be there when you
start. Please include me in your list.

Thanks

Daniele
On 30 Oct 2013 14:44, "Peter Waher"  wrote:

>  Hello Mark & Dave.
>
> ** **
>
> Thanks for the info. I’ve added it to the list of ideas to study before we
> produce the proposal for battery sensors.
>
> ** **
>
> As you say, there are various things you might need to think about when it
> comes to battery powered devices. Bandwidth, packet size, memory, cpu (CPU
> drains battery), etc. The most important is battery life time. Many sensors
> might have work for up to 10 years without replacing battery. For this to
> work you also need to take sleeping into account, and how systems interact
> with devices that are only intermittently (albeit regularly) connected to
> the network, etc. Then of course, there’s the problem of bandwidth
> throttling. If a device is in a low power mode (which is a higher state
> than sleep mode), how can you make sure you can still send important
> messages to it?
>
> ** **
>
> Anybody interested in these questions, please let me know, and I’ll
> include you when the time comes to start working on the extensions. (People
> who have already expressed their interest are already added to the list.)*
> ***
>
> ** **
>
> Best regards,
>
> Peter Waher
>
> ** **
>
> ** **
>
> *From:* Dave Cridland [mailto:d...@cridland.net]
> *Sent:* den 29 oktober 2013 17:23
> *To:* XMPP Standards
> *Subject:* Re: [Standards] Standard for Throttling/Queueing Stanzas
>
> ** **
>
> On Tue, Oct 29, 2013 at 6:41 PM, Mark Rejhon  wrote:**
> **
>
>   You might want to peek at:
>
> http://xmpp.org/extensions/xep-0286.html
>
> It's deferred, but it also pertains to efficiency for battery powered
> devices.  
>
> Most of what it says also applies to battery powered sensor, with a few
> modifications.
>
>  ** **
>
> Mostly it concerns itself with power drain due to 3G radio levels.
>
> ** **
>
> I'd imagine that for sensor devices, the memory/bandwidth tradeoffs may be
> different for compression, for example.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Waher]

Hello Mark & Dave.

Thanks for the info. I've added it to the list of ideas to study before we 
produce the proposal for battery sensors.

As you say, there are various things you might need to think about when it 
comes to battery powered devices. Bandwidth, packet size, memory, cpu (CPU 
drains battery), etc. The most important is battery life time. Many sensors 
might have work for up to 10 years without replacing battery. For this to work 
you also need to take sleeping into account, and how systems interact with 
devices that are only intermittently (albeit regularly) connected to the 
network, etc. Then of course, there's the problem of bandwidth throttling. If a 
device is in a low power mode (which is a higher state than sleep mode), how 
can you make sure you can still send important messages to it?

Anybody interested in these questions, please let me know, and I'll include you 
when the time comes to start working on the extensions. (People who have 
already expressed their interest are already added to the list.)

Best regards,
Peter Waher


From: Dave Cridland [mailto:d...@cridland.net]
Sent: den 29 oktober 2013 17:23
To: XMPP Standards
Subject: Re: [Standards] Standard for Throttling/Queueing Stanzas

On Tue, Oct 29, 2013 at 6:41 PM, Mark Rejhon 
mailto:marky...@gmail.com>> wrote:
You might want to peek at:
http://xmpp.org/extensions/xep-0286.html
It's deferred, but it also pertains to efficiency for battery powered devices.
Most of what it says also applies to battery powered sensor, with a few 
modifications.

Mostly it concerns itself with power drain due to 3G radio levels.

I'd imagine that for sensor devices, the memory/bandwidth tradeoffs may be 
different for compression, for example.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Tue, Oct 29, 2013 at 6:41 PM, Mark Rejhon  wrote:

> You might want to peek at:
> http://xmpp.org/extensions/xep-0286.html
> It's deferred, but it also pertains to efficiency for battery powered
> devices.
> Most of what it says also applies to battery powered sensor, with a few
> modifications.
>

Mostly it concerns itself with power drain due to 3G radio levels.

I'd imagine that for sensor devices, the memory/bandwidth tradeoffs may be
different for compression, for example.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Mark Rejhon]

On Mon, Oct 28, 2013 at 11:47 AM, Peter Waher wrote:

>  The envisioned XEP however is not IOS specific, but rather concerns
> battery-powered sensors, but can be applied to sensors in resource
> constrained networks (where bandwidth is constrained). The same solutions
> can be applied in the IOS case you mentioned, since it can be seen as a
> resource constrained device, when the application runs in the background.
>

You might want to peek at:
http://xmpp.org/extensions/xep-0286.html
It's deferred, but it also pertains to efficiency for battery powered
devices.
Most of what it says also applies to battery powered sensor, with a few
modifications.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Kim Alvefur]

On 2013-10-29 17:47, Spencer MacDonald wrote:
> Thats correct, compared to SIFT I want:
> 
> - All stanzas to be buffered by the server
> - On receiving an "allowed" element the server should flush its buffer
> upto and including that stanza, opposed to just letting that stanza through.

I tried implementing google:queue support as a part of prosodys XEP-198
plugin.  What I did there was:

- Headline messages and available/unavailable presence is buffered.
- Other stanzas flushes the queue.
- A limit of how many stanzas are buffered before it is flushed.
- No reordering.

I thougt this made sense.

--
Kim



signature.asc
Description: OpenPGP digital signature

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

On Tue, Oct 29, 2013 at 5:19 PM, Dave Cridland  wrote:

> Right. I think I have just about enough for a proposal; unless anyone else
> is working on it I'll scribble out a buffer/hush/discard proposal.
>

I would of been happy to do a buffer proposal, but it sounds like you want
to role the 3 solutions into one XEP, so il leave it in your capable hands.

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Tue, Oct 29, 2013 at 5:05 PM, Peter Saint-Andre wrote:

> Do message hints apply only to  stanzas?
>
>
Actually, XEP-0334 doesn't explicitly say that, but it's certainly implied.
But as I say, very easy to change.


> We'll also want some kind of presence hush.
>
>
Right. I think I have just about enough for a proposal; unless anyone else
is working on it I'll scribble out a buffer/hush/discard proposal.

Dave.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/29/13 11:02 AM, Dave Cridland wrote:
> On Tue, Oct 29, 2013 at 4:47 PM, Spencer MacDonald 
>  > wrote:
> 
> 
>> I think a simple buffer protocol would do, with a way of clients 
>> specifying what type of packets (like SIFT) which would cause a 
>> server flush... but due to the limitations on iOS that would 
>> probably only be Jingle.
> 
> Is there something in SIFT that doesn't meet the requirements? For 
> instance, does it need to say that filtered / intercepted stanzas
> are indeed buffered?
> 
> 
> Thats correct, compared to SIFT I want:
> 
> - All stanzas to be buffered by the server - On receiving an
> "allowed" element the server should flush its buffer upto and
> including that stanza, opposed to just letting that stanza
> through.
> 
> 
> 
> What worries me about SIFT is that it's too complex, and too open
> ended.
> 
> By too complex, I mean both that it relies on XPath processing by
> the server, and also it relies on complex rule creation by the
> client. We can remove the former by simply matching the immediate
> child elements of a stanza against namespace and element local
> name, which at least reduces it to one or two string compares, but
> I still think it'll require a lot of work by client developers to
> use it effectively. In any case, file transfers will end up being
> treated like voice calls by their nature.
> 
> By contrast, XEP-0334 does the work elsewhere. I've an odd
> suspicion that most hints will be added by a server, actually. The
> difficulty here is that we can hint message and presence stanzas,
> though the latter isn't in XEP-0334, but we have no similar
> solution for hinting IQ stanzas. Disco (and caps) tend to work
> effectively for suppressing entirely unwanted IQ traffic, but for
> hinting that buffering is acceptable, we'd need some other
> mechanism. Of course, for Jingle, this could be a nice byproduct of
> using message stanzas for the session-initiate.

Simpler is better.

Do message hints apply only to  stanzas?

We'll also want some kind of presence hush.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSb+rbAAoJEOoGpJErxa2pEu0P/ix1ThOrr6x0tNdL8C/Yr/LL
TrfAEn0SzugZiFO1y+SNGW9tfq/rDJlL3nPDbrBUgi/URCPUAFldyYC8IFURX3sU
YRSJIKgAQahWk4I1hmzgAuaIstZXIi6PtkyVmqStrjselYzl+/tRrsow6UFVNGth
Bgxz9FkOgTzb6qY8y0yHrbm4Xo4NPP13LmbrhIgOMo98xPTYPAnh8BcRRCiCuxd1
L7ge/toy7VHx+vg/FnIQyrahzXUwdXTy0Mwi2P2VTt61Nu7QlVu5CObAluIGRf8o
X7Zb9A7zVqJvFIsPURNZafrG4+BHDcZ6121OQ+Xcbob7/j4f1dq1hadcOvsqbA7M
U31xuXXbp2ytaEQwIgV7OzosrKn2iB9CEFb9EpoPDb0TtHkY/r0x6jIqqfFnAhLc
y7C1UAO0aabKlPARTkibwvTyhsD02RY5Lq03pcsYF/DhGVonyR+KCeRXH67uYNqd
cZTat5vS2aMG9hVsKvyN0YJyWh01yxEwgbrKN/DsFWaisTYKkHXJJYA35m9AGvnX
vfT0/26tex38ug0pw04TeVtz39BwJ6ZF/BD2WnKJVAmv+IFwaz9Zc7GTPk91kyST
J6TymFmIVlLGCj2y1kTirSME5HCbmjB54G0M/wNEE+oL6eAYOWDKk+0WYetDgqzX
M0sgVpeS0JU+UgYGagpI
=ubNS
-END PGP SIGNATURE-

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Tue, Oct 29, 2013 at 4:47 PM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

>
> > I think a simple buffer protocol would do, with a way of clients
>> > specifying what type of packets (like SIFT) which would cause a
>> > server flush... but due to the limitations on iOS that would
>> > probably only be Jingle.
>>
>> Is there something in SIFT that doesn't meet the requirements? For
>> instance, does it need to say that filtered / intercepted stanzas are
>> indeed buffered?
>
>
> Thats correct, compared to SIFT I want:
>
> - All stanzas to be buffered by the server
> - On receiving an "allowed" element the server should flush its buffer
> upto and including that stanza, opposed to just letting that stanza through.
>
>

What worries me about SIFT is that it's too complex, and too open ended.

By too complex, I mean both that it relies on XPath processing by the
server, and also it relies on complex rule creation by the client. We can
remove the former by simply matching the immediate child elements of a
stanza against namespace and element local name, which at least reduces it
to one or two string compares, but I still think it'll require a lot of
work by client developers to use it effectively. In any case, file
transfers will end up being treated like voice calls by their nature.

By contrast, XEP-0334 does the work elsewhere. I've an odd suspicion that
most hints will be added by a server, actually. The difficulty here is that
we can hint message and presence stanzas, though the latter isn't in
XEP-0334, but we have no similar solution for hinting IQ stanzas. Disco
(and caps) tend to work effectively for suppressing entirely unwanted IQ
traffic, but for hinting that buffering is acceptable, we'd need some other
mechanism. Of course, for Jingle, this could be a nice byproduct of using
message stanzas for the session-initiate.

Dave.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

On Tue, Oct 29, 2013 at 4:44 PM, Peter Saint-Andre wrote:

> I see two things:
>
> 1. Hey, wake up, you've got some data buffered up at the server! (use
> push notifications for this)
>

> 2. Ah, great, you're awake -- here's some data for you. (use XMPP for
> this)
>
> Is that disallowed by Apple policy?
>
> Peter
>


As long as you don't send too many stanza's over the TCP socket while the
app is in the background your fine.

To be clear, Push Notifications don't wake the app up unless the user acts
upon them.

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

On Tue, Oct 29, 2013 at 3:44 PM, Peter Saint-Andre wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/29/13 8:03 AM, Spencer MacDonald wrote:
> > Yeah, thats what I have done without the jingle exception (I use
> > SIP for VoIP).
>
> I'd be curious to hear what you think about this document about
> guidelines for dual-stack SIP/XMPP clients:
>
> https://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/
>
> It's been approved for publication as an RFC, but if there's something
> horribly wrong in there I'd appreciate hearing about it.
>

I had a brief look previously but il give it another once over :)


>
> > I think a simple buffer protocol would do, with a way of clients
> > specifying what type of packets (like SIFT) which would cause a
> > server flush... but due to the limitations on iOS that would
> > probably only be Jingle.
>
> Is there something in SIFT that doesn't meet the requirements? For
> instance, does it need to say that filtered / intercepted stanzas are
> indeed buffered?


Thats correct, compared to SIFT I want:

- All stanzas to be buffered by the server
- On receiving an "allowed" element the server should flush its buffer upto
and including that stanza, opposed to just letting that stanza through.

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/29/13 10:40 AM, Spencer MacDonald wrote:
> 
> On Tue, Oct 29, 2013 at 3:16 PM, Peter Saint-Andre
> mailto:stpe...@stpeter.im>> wrote:
> 
> Does this mean that all messaging apps are disallowed? That
> doesn't actually seem to be the case.
> 
> Peter
> 
> 
> They all use Push Notifications to notify the user of new
> messages.

I see two things:

1. Hey, wake up, you've got some data buffered up at the server! (use
push notifications for this)

2. Ah, great, you're awake -- here's some data for you. (use XMPP for
this)

Is that disallowed by Apple policy?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSb+XzAAoJEOoGpJErxa2pT4EP/1dI2REJ7rPJCW5eNMp33OaF
SQRMEtvFgnHNEg7r9zd1YGOexSFM2j7tqM/VdZzplviB53oqNtg5JC6m/ZZiq7B1
wmM34IxO5WrRKx2G0ukogbA4sPpDlflpnxh/HHOCXRElxfBOrR6MMBGaGAvL4nrw
oY4C7WlHrCqlDDrwi3DHgi3tAhKGk0N0d6uOx79CbRDC/jH+/7Rqv0vbS1f3mk5s
dFIttI1slY516qlsgDFUQ4/n3REL+R5rysEPwXMALvF3oACA3YBoKNfxZ7lJebBw
Qpmc0FWRlN9TgiFHQeP+EmpSfJQQ2HHs9B8e4i7fjWNNw2DPBWHs09007RhfFkIn
yB9gLkXCyWutHgbw6D6bDOompYpJkgd0cqjlyNywWMpgwEAhr3IuyElW586QPjJ2
dYrBzBgz5tCEfCmWSzH8bUl8m15qm7RWuegKhEPd8LyB8v8fv5dMkRak/dHlfkZN
ASL0Ybx/DMcKSaOBsW9O486EJFgQzfaRF5B4TfZxpc+cbrbHBuUeoRa0yVl6/KYf
0eMt9XGL7/snW1tCiEJ+c4UWtPxFgHvdFeZ1Uag0Q7r+Mf5A0BtZlf41La9qM0HZ
q80em4IHuBmgWECgJuHYW8Zn8aPB35gr2e2tv4nvZ1XuOH1hYo0xAbvYJDoSh0dw
HWQtsOpIXwyR9dfPmOY1
=78hp
-END PGP SIGNATURE-

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

On Tue, Oct 29, 2013 at 3:16 PM, Peter Saint-Andre wrote:

> Does this mean that all messaging apps are disallowed? That doesn't
> actually seem to be the case.
>
> Peter
>

They all use Push Notifications to notify the user of new messages. If they
also offer VoIP they are doing what I suggested or disconnecting from the
XMPP Server when the app is put into the background.

Regards

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/29/13 8:03 AM, Spencer MacDonald wrote:
> Yeah, thats what I have done without the jingle exception (I use
> SIP for VoIP).

I'd be curious to hear what you think about this document about
guidelines for dual-stack SIP/XMPP clients:

https://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/

It's been approved for publication as an RFC, but if there's something
horribly wrong in there I'd appreciate hearing about it.

> I think a simple buffer protocol would do, with a way of clients 
> specifying what type of packets (like SIFT) which would cause a
> server flush... but due to the limitations on iOS that would
> probably only be Jingle.

Is there something in SIFT that doesn't meet the requirements? For
instance, does it need to say that filtered / intercepted stanzas are
indeed buffered?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSb9f3AAoJEOoGpJErxa2p1qIP/1PPsp+DX3cMJ9U6WcsYjv5q
DR6lCbZLY5tvBLpd1FwbM4d2gt1AryWRkp+yn4Y3/DkAjqmEH4kemBidVeE6X8hd
HTdwZsDGhfPOT5rIRnY3AwTe7dzKg+dRVuwhr07t8WjLZhZB1Zm/axsAXEGryuxL
mKsWQrehxEQOJqVmEhATMQtPOGqSph6cKPiz9935cQQZPGlXP/nAgaDmiiwIjJA3
W4rB7S2DE//HAvkwm8jaCY70reVyyZayy3o9ApZOj/lsqg00QLHG8SV7/yAcDQZT
mwJiGSr8mauVcVpzmbzhRfMMZ60f7xE0nlA9RXSbsCD3vrV2AnPvqA6LZd6ZnY0A
H41d+dSjamDMtSSp27VLh08t3/69vnoNZ+T5NvqIcQ9887fEYX5PSyj5Co83wp7x
Fok1dLzJR8T97UIRiJuswn8XLCEjrd4utBFS2upd/LMwl60DFnDG4bRVmfU5mJh6
eDjzGGSg9pP+xVVIeAqA9RzzAJiU6W8I91zQOjiRUKVeqXUvc/J88Q+YhUw2JYR3
j+MGdVnt0hXiOeOnWdAAFY+7cuRi6OMtwg9UQ/oNOAa4y14cbtimzr2TVJOcTZ5U
EeNNcxP5qKG+kzLt73449XMaY6I2yNGaXYHEa/kdjmmRqY960bhWWckSpu3ZesmE
Q1gxW6GS+8Kmug5OI9R3
=jufQ
-END PGP SIGNATURE-

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/29/13 3:02 AM, Spencer MacDonald wrote:

> Also (iOS specific again, sorry) your not allowed to use the
> background socket for "messages" anyway, thats what push
> notifications are for. Also the user is not informed in any way
> that the app has been killed so they wouldn't bother to relaunch
> it, thus not resuming the stream until the next time they want to
> send a message.

Does this mean that all messaging apps are disallowed? That doesn't
actually seem to be the case.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSb9FmAAoJEOoGpJErxa2pFCoP+watCcX7cypqEAJR2UkIeVbm
n/jNnIkCGTcaPEBIVqVH1+CSnellMxri7Nx1rMtXOe73LslR5STgeUxwzBBbbqoL
oMqshcAunfLFO2XeX8u5EmQ9JfxWIZqp1U11Qi/rKeIsZ9aE/4PJ8NGXU6PbIadZ
AwcWaXoPEJNXKeuVm6yGMoOmKgWa+TKqwz2FDHzKIf0x+nNAVnmw7pGGfd2/w5wh
8s1o4IGS1aKuB1q0J6UIBR7X98bYEkxDv41HaHWcS3tHc6DctwCi9BevfY/NPk8L
VKwTXBI/JnWX+qLLp3kuT/ogWOeAE5H2n6Is+6J1OdG1XMzbpCa+nRwbl1KAZ0+L
nKLfvX5d9Rl3o1NMRi87fHHT9OW6Iyuh31NR9fjsAH5eOHa5OlihdLX4DsZqtKFJ
re4x2ysOvxRV9mYSfQK04n97EXVn9AF0Fo4d7WBJow63j8ATRpWotD602YB2CdD5
QjZPrwJxdn7rqXxb+zRy5GCnHlsmN22xo7G9Z5Fjp/KGOvHTanV3oYuD+sw5+9yr
ID6AQeJXM9saMU/Bx1J4zy0fgpaSLrFXyIzdCJfcFMX2/BhCP+yJRWaW1dqQLN2g
ggJeQUHA0gF2u78qX1d5nd/1cWtDwRjK98VFUlV9ans8wtwPV/HYnUHeNstFbZ9G
HHodIuTSbZKNiTxBeWud
=PNJi
-END PGP SIGNATURE-

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

Yeah, thats what I have done without the jingle exception (I use SIP for
VoIP).

I think a simple buffer protocol would do, with a way of clients specifying
what type of packets (like SIFT) which would cause a server flush... but
due to the limitations on iOS that would probably only be Jingle.

Regards

Spencer


On Tue, Oct 29, 2013 at 12:40 PM, Dave Cridland  wrote:

> On Tue, Oct 29, 2013 at 12:29 PM, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>>
>>> 2) You will no longer receive VoIP Calls, which is the real purpose of
 the background socket.


>>> Wouldn't mobile push solutions handle that if properly integrated?
>>>
>>
>> The issue is that push notifications take anywhere between 1 and 20
>> seconds to reach a device under normal circumstances, so by the time the
>> recipient sees the notification, launches the app, the app connects to the
>> server etc the callee has probably hung up.
>>
>>
> Oh. That's a bit pants, then.
>
> It'd be easier to solve these problems if the overriding concerns were
> technical, of course, but it's looking like you'll need to handle a case
> where pretty much all traffic is fully buffered, except for Jingle
> session-initiate.
>
> We can call it Broken Apple Mode.
>
> Dave.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Tue, Oct 29, 2013 at 12:29 PM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

>
>> 2) You will no longer receive VoIP Calls, which is the real purpose of
>>> the background socket.
>>>
>>>
>> Wouldn't mobile push solutions handle that if properly integrated?
>>
>
> The issue is that push notifications take anywhere between 1 and 20
> seconds to reach a device under normal circumstances, so by the time the
> recipient sees the notification, launches the app, the app connects to the
> server etc the callee has probably hung up.
>
>
Oh. That's a bit pants, then.

It'd be easier to solve these problems if the overriding concerns were
technical, of course, but it's looking like you'll need to handle a case
where pretty much all traffic is fully buffered, except for Jingle
session-initiate.

We can call it Broken Apple Mode.

Dave.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

>
>
> 2) You will no longer receive VoIP Calls, which is the real purpose of the
>> background socket.
>>
>>
> Wouldn't mobile push solutions handle that if properly integrated?
>

The issue is that push notifications take anywhere between 1 and 20 seconds
to reach a device under normal circumstances, so by the time the recipient
sees the notification, launches the app, the app connects to the server etc
the callee has probably hung up.

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Tue, Oct 29, 2013 at 11:47 AM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

> The other 2 problems with your app getting killed is:
>
> 1) Your presence will be unavailable, so people are potentially less
> likely to contact you.
>

Possibly not - XEP-0198 allows for a logical session to continue despite
the TCP layer closing. I think a server that knows it can still contact the
client and have the session reconnected would be likely to keep the
presence available for much longer.


> 2) You will no longer receive VoIP Calls, which is the real purpose of the
> background socket.
>
>
Wouldn't mobile push solutions handle that if properly integrated?


> Maybe we are talking about 2 different problems with 2 different solutions?
>

Oh, for sure. We're talking about several interrelated problems, which is
why i'm suggesting addressing them with several interrelating toolbox-style
extensions.

Dave.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

The other 2 problems with your app getting killed is:

1) Your presence will be unavailable, so people are potentially less likely
to contact you.
2) You will no longer receive VoIP Calls, which is the real purpose of the
background socket.

Maybe we are talking about 2 different problems with 2 different solutions?

Spencer


On Tue, Oct 29, 2013 at 11:03 AM, Dave Cridland  wrote:

>
>
>
> On Tue, Oct 29, 2013 at 9:02 AM, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>> I think your under estimating the amount of messages somebody receives in
>> an active chat, especially when some people tend to split their messages up
>> like so:
>>
>
> I try not to talk to such people.
>
> But seriously, while it could easily be that my patterns are different, my
> message traffic is usually way lower than 3/min. I used to graph such
> things, but based on simple counting it doesn't seem that high.
>
>
>> Moreover if your mobile app has a Desktop counterpart you might end up
>> being a participant in one or more group chats, like you said could end up
>> generating a lot of traffic.
>>
>>
> Right, being able to distinguish from important messages and background
> traffic in a MUC environment is hard, of course, but possible - the clients
> manage to identify the user's nickname in messages, for instance, so
> therefore so could the server.
>
>
>> Also (iOS specific again, sorry) your not allowed to use the background
>> socket for "messages" anyway, thats what push notifications are for. Also
>> the user is not informed in any way that the app has been killed so they
>> wouldn't bother to relaunch it, thus not resuming the stream until the next
>> time they want to send a message.
>>
>>
> No, the user wouldn't be informed the app has been killed, but would see a
> notification that a message is deliverable when offline.
>
> Dave.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Tue, Oct 29, 2013 at 9:02 AM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

> I think your under estimating the amount of messages somebody receives in
> an active chat, especially when some people tend to split their messages up
> like so:
>

I try not to talk to such people.

But seriously, while it could easily be that my patterns are different, my
message traffic is usually way lower than 3/min. I used to graph such
things, but based on simple counting it doesn't seem that high.


> Moreover if your mobile app has a Desktop counterpart you might end up
> being a participant in one or more group chats, like you said could end up
> generating a lot of traffic.
>
>
Right, being able to distinguish from important messages and background
traffic in a MUC environment is hard, of course, but possible - the clients
manage to identify the user's nickname in messages, for instance, so
therefore so could the server.


> Also (iOS specific again, sorry) your not allowed to use the background
> socket for "messages" anyway, thats what push notifications are for. Also
> the user is not informed in any way that the app has been killed so they
> wouldn't bother to relaunch it, thus not resuming the stream until the next
> time they want to send a message.
>
>
No, the user wouldn't be informed the app has been killed, but would see a
notification that a message is deliverable when offline.

Dave.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

I think your under estimating the amount of messages somebody receives in
an active chat, especially when some people tend to split their messages up
like so:

Message 1:
Hi

Message 2:
How are you

Message 3:
?

Message 4:
:)

Moreover if your mobile app has a Desktop counterpart you might end up
being a participant in one or more group chats, like you said could end up
generating a lot of traffic.

Also (iOS specific again, sorry) your not allowed to use the background
socket for "messages" anyway, thats what push notifications are for. Also
the user is not informed in any way that the app has been killed so they
wouldn't bother to relaunch it, thus not resuming the stream until the next
time they want to send a message.

Regards

Spencer


On Mon, Oct 28, 2013 at 9:46 PM, Dave Cridland  wrote:

> On Mon, Oct 28, 2013 at 7:57 PM, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>> I have used a custom implementation that just had the following commands:
>>
>> - Enable (enable the buffer)
>> - Flush (flush the buffer)
>> - Disable (disable the buffer, which also flushes it)
>>
>> It worked great, but I wasn't using any time sensitive XEPs like Jingle
>> that you would want to let through.
>>
>> The major issue on iOS is if the device "wakes up" more than 15 times in
>> 5 mins your app would get killed, so letting through "important" messages
>> still wouldn't be a good idea.
>>
>>
> Right; the google:queue implementation I once wrote, in a past life,
> buffered up only presence. IQ, and messages, came through - but it was
> clever enough to figure out that local PEP at least was bufferable.
>
> I suspect though that most people would handle less than 3 messages a
> minute on mobile for at least most of the time. I only get that kind of
> level on desktop if I'm in a MUC or two.
>
> Even if the client was killed, the combination of mobile push and XEP-0198
> should make that fairly painless, too.
>
> Dave.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Mon, Oct 28, 2013 at 7:57 PM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

> I have used a custom implementation that just had the following commands:
>
> - Enable (enable the buffer)
> - Flush (flush the buffer)
> - Disable (disable the buffer, which also flushes it)
>
> It worked great, but I wasn't using any time sensitive XEPs like Jingle
> that you would want to let through.
>
> The major issue on iOS is if the device "wakes up" more than 15 times in 5
> mins your app would get killed, so letting through "important" messages
> still wouldn't be a good idea.
>
>
Right; the google:queue implementation I once wrote, in a past life,
buffered up only presence. IQ, and messages, came through - but it was
clever enough to figure out that local PEP at least was bufferable.

I suspect though that most people would handle less than 3 messages a
minute on mobile for at least most of the time. I only get that kind of
level on desktop if I'm in a MUC or two.

Even if the client was killed, the combination of mobile push and XEP-0198
should make that fairly painless, too.

Dave.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

I have used a custom implementation that just had the following commands:

- Enable (enable the buffer)
- Flush (flush the buffer)
- Disable (disable the buffer, which also flushes it)

It worked great, but I wasn't using any time sensitive XEPs like Jingle
that you would want to let through.

The major issue on iOS is if the device "wakes up" more than 15 times in 5
mins your app would get killed, so letting through "important" messages
still wouldn't be a good idea.

Regards

Spencer


On Mon, Oct 28, 2013 at 6:05 PM, Dave Cridland  wrote:

> On Mon, Oct 28, 2013 at 5:54 PM, Peter Waher wrote:
>
>> > How do we define "important"? There's the challenge. :-)
>>
>> True. But not only "how", but also "where" it is defined. The received
>> can define what it wants, the xmpp server can define what to forward under
>> certain conditions, and the sender can define the priority of a message.
>>
>> Many network protocols have solved this by letting the sender determine a
>> priority or QoS level for each message. The sender normally knows if
>> something is "important" (for instance an alarm, or a call or control
>> command) or "normal" (informational message) or "less important" (recurrent
>> status update), for instance, and so no complex logic for this is required.
>>
>> An objection could be made that an application could then choose to send
>> all messages as "important" messages, overriding any throttling logic. But
>> in practice, this would be counterproductive since users would quickly find
>> out what service/device/address works badly and stop using it or
>> unfriending misbehaving contacts.
>>
>> The above solution could then hypothetically be complemented by a simple
>> subscription mechanism on the client, or an automatic rule on the xmpp
>> server determining what messages to forward and when, and perhaps also with
>> bandwidth limits on different types of messages, and if messages not being
>> forwarded should be treated as offline messages or thrown away (based on
>> message priority).
>>
>
> I think this is XEP-0334, Messaging Processing Hints. Or ought to be, at
> any rate.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Mon, Oct 28, 2013 at 5:54 PM, Peter Waher wrote:

> > How do we define "important"? There's the challenge. :-)
>
> True. But not only "how", but also "where" it is defined. The received can
> define what it wants, the xmpp server can define what to forward under
> certain conditions, and the sender can define the priority of a message.
>
> Many network protocols have solved this by letting the sender determine a
> priority or QoS level for each message. The sender normally knows if
> something is "important" (for instance an alarm, or a call or control
> command) or "normal" (informational message) or "less important" (recurrent
> status update), for instance, and so no complex logic for this is required.
>
> An objection could be made that an application could then choose to send
> all messages as "important" messages, overriding any throttling logic. But
> in practice, this would be counterproductive since users would quickly find
> out what service/device/address works badly and stop using it or
> unfriending misbehaving contacts.
>
> The above solution could then hypothetically be complemented by a simple
> subscription mechanism on the client, or an automatic rule on the xmpp
> server determining what messages to forward and when, and perhaps also with
> bandwidth limits on different types of messages, and if messages not being
> forwarded should be treated as offline messages or thrown away (based on
> message priority).
>

I think this is XEP-0334, Messaging Processing Hints. Or ought to be, at
any rate.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Waher]

> How do we define "important"? There's the challenge. :-)

True. But not only "how", but also "where" it is defined. The received can 
define what it wants, the xmpp server can define what to forward under certain 
conditions, and the sender can define the priority of a message.

Many network protocols have solved this by letting the sender determine a 
priority or QoS level for each message. The sender normally knows if something 
is "important" (for instance an alarm, or a call or control command) or 
"normal" (informational message) or "less important" (recurrent status update), 
for instance, and so no complex logic for this is required.

An objection could be made that an application could then choose to send all 
messages as "important" messages, overriding any throttling logic. But in 
practice, this would be counterproductive since users would quickly find out 
what service/device/address works badly and stop using it or unfriending 
misbehaving contacts.

The above solution could then hypothetically be complemented by a simple 
subscription mechanism on the client, or an automatic rule on the xmpp server 
determining what messages to forward and when, and perhaps also with bandwidth 
limits on different types of messages, and if messages not being forwarded 
should be treated as offline messages or thrown away (based on message 
priority).

Best regards,
Peter Waher

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Dave Cridland]

On Mon, Oct 28, 2013 at 4:03 PM, Peter Saint-Andre wrote:

> How do we define "important"? There's the challenge. :-)
>

I think we had this discussion in Portland, but perhaps it was after you'd
left, while Lance, Matt and I were chatting about mobile push and all sorts
of things.

Basically, the existing-but-non-XSF google:queue specification says more or
less what Spencer wants - "Don't send me stuff. Update me when I ask".
That, XEP-0198, the mobile push stuff that Lance was sketching out (much
better than I would have), and Matt's hinting stuff gets us this:

Dramatis Personæ:

minstrel@wandering.example - A Wandering Minstrel.
executive@records.example   - His contact.

So minstrel@wandering.example/mobile connects to wandering.example. It
activates the queue (I'd call it buffer, but hey) extension, and so, when
the phone is switched away from the app, it buffers the connection such
that only "important" stuff gets through. It also activates the
per-connection aspect of the mobile push thing.

If executive@records.example sends our Wandering Minstrel a message, that's
assumed to be important, unless it's otherwise hinted, and the following
occurs:

1) If the session is online, the buffer is flushed, and this message sent
through, along with an  request.

2) If the ack times out, or the session was not online, the session is
assumed to be disconnected, and the mobile is sent a push (for that
connection, ideally - I may be wrong in us needing this). In this case, the
mobile wakes up, and either returns an , or else reconnects the session
via XEP-0198.

So what this needs is changes to a handful of specs:

a) We need to write a new replacement for google:queue, which does
everything that we actually need. This could be done as a replacement to
SIFT (which I always thought was over complexificated for what we actually
need) or as additions to it.

b) Matt's stanza hints need to include ways to indicate that a message is
not worth considering as a reason to flush the buffer, and/or wake the
mobile out-of-band. It also probably needs ways to insist that it is.

c) Lance's mobile push (which should provide essentially an XMPP API for
servers to talk to mobile developers' push services).

Given those three items (and (c) is by far the biggest), we've got mobile
covered, I think.

Dave.

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Waher]

Hello again.

Forgot to mention something that can be useful in this case. Since traffic (nr 
bytes) is important in this case, I would suggest you also look at compressing 
data. XEP 0322 (http://xmpp.org/extensions/xep-0322.html) provides a very 
efficient means to compress XML, better than conventional compression 
algorithms when used schemas are known. It is more efficient since it adapts 
itself to the structure of the XML being sent using knowledge from schemas 
used. It also has the ability to learn during the session making it even more 
efficient.

Best regards,
Peter Waher

From: Peter Waher [mailto:peter.wa...@clayster.com]
Sent: den 28 oktober 2013 12:48
To: XMPP Standards
Cc: i...@xmpp.org
Subject: Re: [Standards] Standard for Throttling/Queueing Stanzas

Hello Spencer

As Joachim mentioned, there is interest from the Internet of Things (IoT) 
community to create such a XEP. In fact, it is already planned because there's 
a need, but it is yet to be written. Anybody interested in co-authoring such a 
XEP is welcome to contact me.

The envisioned XEP however is not IOS specific, but rather concerns 
battery-powered sensors, but can be applied to sensors in resource constrained 
networks (where bandwidth is constrained). The same solutions can be applied in 
the IOS case you mentioned, since it can be seen as a resource constrained 
device, when the application runs in the background.

Peter Saint-André mentioned that the deferred XEP 0273 could solve part of this 
issue, by permitting the filtering of certain messages.

Forwarding of offline stanzas (XEP-0160) can also be used. I.e. the bandwidth 
can be controlled by the device, using the presence as an indication when the 
server can send information. (Here battery powered sensors often go into sleep 
mode and wake up regularly to perform a task. They can only receive messages 
when awake.)

Other solutions can be envisioned, for instance using presence=away to signal 
clients restricting them to send important messages only, queuing not as 
important messages for later when online, etc.

Ideas are welcome.

Best regards,
Peter Waher


From: Spencer MacDonald [mailto:spencer.macdonald.ot...@gmail.com]
Sent: den 27 oktober 2013 13:17
To: XMPP Standards
Subject: [Standards] Standard for Throttling/Queueing Stanzas

I have observed from the XMPPFramework mailing list and Github issues, that one 
of the biggest problems that iOS Developers have with including XMPP (alongside 
VoIP) in their iOS apps, is that their apps get terminated for receiving to 
much data while in the background.

There are proprietary solutions that allow an XMPP client to inform the XMPP 
Server that the app is going to be put in the background. The XMPP Server then 
queues the stanzas until the client in with the XMPP Server, which on iOS is 
less than or equal to 10 minutes. Some solutions also filter out presence 
packets so only the most recent one is queued for each jid.

I appreciate that the problem is iOS specific, but the solution can be generic.

Is this something that should be incorporated into an XEP? or is there already 
a solution for this issue?

Regards

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Olle E. Johansson]

On 28 Oct 2013, at 17:03, Peter Saint-Andre  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/28/13 9:58 AM, Adán Sánchez de Pedro Crespo wrote:
>> Hello everyone,
>> 
>>> Other solutions can be envisioned, for instance using
>>> presence=away to signal clients restricting them to send
>>> important messages only, queuing not as important messages for
>>> later when online, etc.
>> 
>> That's exactly what Loqui IM for Firefox OS does. When the app goes
>> to background or the phone is locked, the "show" is changed to
>> "away" and the server stops sending it presence stanzas.
>> 
>> It's not elegant at all, but fits the purpose of saving battery
>> and keeping the app from being killed by the system.
>> 
>> Do you know of any other better way to implement this? Shouldn't
>> we have a standard method to tell a server that it should send a
>> client important messages only?
> 
> How do we define "important"? There's the challenge. :-)

The - in my view - failed IETF wg SIMPLE worked on this for a while. Maybe 
their work can be some form of input, even though it is focused on SIP.

Filtering may be important:
http://tools.ietf.org/html/rfc4660
"
   This document describes the operations a subscriber performs in order
   to put filtering rules associated with a subscription to event
   notification information in place.  The handling, by the subscriber,
   of responses to subscriptions carrying filtering rules and the
   handling of notifications with filtering rules applied to them are
   also described.  Furthermore, the document conveys how the notifier
   behaves when receiving such filtering rules and how a notification is
   constructed."

There's also some queing/throttling in RFC 6665. Can't find a good event 
package that
defines throttling. The presence event package just says that a PA should not 
send a NOTIFY
more often than every 5th second. Maybe someone else have a better example.

Just some tidbits for the discussion.

/O

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/28/13 9:58 AM, Adán Sánchez de Pedro Crespo wrote:
> Hello everyone,
> 
>> Other solutions can be envisioned, for instance using
>> presence=away to signal clients restricting them to send
>> important messages only, queuing not as important messages for
>> later when online, etc.
> 
> That's exactly what Loqui IM for Firefox OS does. When the app goes
> to background or the phone is locked, the "show" is changed to
> "away" and the server stops sending it presence stanzas.
> 
> It's not elegant at all, but fits the purpose of saving battery
> and keeping the app from being killed by the system.
> 
> Do you know of any other better way to implement this? Shouldn't
> we have a standard method to tell a server that it should send a
> client important messages only?

How do we define "important"? There's the challenge. :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSborJAAoJEOoGpJErxa2pckUP+QFFs9sJAizMnhCSgib07yFS
vXS6vyOvDTYr/m+b7CupM2Zatv9lZfmaaWuxSMyLTmkTS0ddUKmNs03U52ttPnU5
6Uk53i6zuwdL61KLzMBV3PXND5Clacjfmq8pLaGXSAgzjxWhUte98Md3qg8sEgQa
EKTnpP5nbrOQn8U1L/ukfnU64mcegGW/5lCCeiV0hm+eAF2ErIyy99sVK7YkYKcZ
1vlFQy68wpsoHod8SPeSszG7WzhqfgG0cdOaN7TWno6c3OFGLTW8CMfLj2jD4knJ
oSmBwj6qTDjoccT00m1rnmEJUHOaAxOVAs/uBp1vdLTWlX0l4u2CE0Rqd8ZEndwx
rkVYSxSOU3S14baMYe2B7egUhm2ZaJzCntPiqDQg+AKSTqb/UmLXuLoWNufXzYQt
/iSSjHEI+WtFsazo1iV+O6qBdL3/U3biRXeQ+wVdOVUQzCE0/dzgb17g5+AFLEf0
rgge5SRxVCHAurY7gNtd714K/6ES+rRaPQQbaq7/y5BvElBhmhYRAhXxuZ5sbbXV
dU8ytzHzXfFFwntUBYuWdWNSjK+ImYCKrQBW3ogX2pJpeYTVeP9yJJaKavZomt/7
gRCkr753Z8Pb+2WuMzvcZWfmPw7/PfK1+Va5Blbg5npsHimPy+jiHpOjuuYnH+nl
fnez56ZhUnLaYex/Btxy
=AQRj
-END PGP SIGNATURE-

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

The difference between Sift and what people want on iOS, is for the stanzas
to be queued by the server and not discarded.

Having a filter so that certain Stanza's like Jingle get through would be
more ideal though.

Spencer


On Mon, Oct 28, 2013 at 3:50 PM, Kevin Smith  wrote:

>
>
>
> On Mon, Oct 28, 2013 at 3:49 PM, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>> I missed that XEP-0273 as it is Deferred,
>>
>> Is it Deferred for any particular reason or just because of inactivity?
>>
>
> Inactivity is the only reason XEPs get deferred.
>
> /K
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Adán Sánchez de Pedro Crespo]

Hello everyone,

> Other solutions can be envisioned, for instance using presence=away
> to signal clients restricting them to send important messages only,
> queuing not as important messages for later when online, etc.

That's exactly what Loqui IM for Firefox OS does. When the app goes to
background or the phone is locked, the "show" is changed to "away" and
the server stops sending it presence stanzas.

It's not elegant at all, but fits the purpose of saving battery and
keeping the app from being killed by the system.

Do you know of any other better way to implement this? Shouldn't we
have a standard method to tell a server that it should send a client
important messages only?

Regards,
-- 
*Adán Sánchez de Pedro Crespo*
/FLOSS Developer at Waaltcom/
PGP Public Key: CCABF8A0
Cel.: +34 663 163 375
Fix.: +34 912 69 22 00
PLN: +00 4200
VoIP: 2...@sip.waalt.com

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

I missed that XEP-0273 as it is Deferred,

Is it Deferred for any particular reason or just because of inactivity?

Regards

Spencer


On Mon, Oct 28, 2013 at 3:47 PM, Peter Waher wrote:

>  Hello Spencer
>
> ** **
>
> As Joachim mentioned, there is interest from the Internet of Things (IoT)
> community to create such a XEP. In fact, it is already planned because
> there’s a need, but it is yet to be written. Anybody interested in
> co-authoring such a XEP is welcome to contact me.
>
> ** **
>
> The envisioned XEP however is not IOS specific, but rather concerns
> battery-powered sensors, but can be applied to sensors in resource
> constrained networks (where bandwidth is constrained). The same solutions
> can be applied in the IOS case you mentioned, since it can be seen as a
> resource constrained device, when the application runs in the background.*
> ***
>
> ** **
>
> Peter Saint-André mentioned that the deferred XEP 0273 could solve part of
> this issue, by permitting the filtering of certain messages.
>
> ** **
>
> Forwarding of offline stanzas (XEP-0160) can also be used. I.e. the
> bandwidth can be controlled by the device, using the presence as an
> indication when the server can send information. (Here battery powered
> sensors often go into sleep mode and wake up regularly to perform a task.
> They can only receive messages when awake.)
>
> ** **
>
> Other solutions can be envisioned, for instance using presence=away to
> signal clients restricting them to send important messages only, queuing
> not as important messages for later when online, etc.
>
> ** **
>
> Ideas are welcome.
>
> ** **
>
> Best regards,
>
> Peter Waher
>
> ** **
>
> ** **
>
> *From:* Spencer MacDonald [mailto:spencer.macdonald.ot...@gmail.com]
> *Sent:* den 27 oktober 2013 13:17
> *To:* XMPP Standards
> *Subject:* [Standards] Standard for Throttling/Queueing Stanzas
>
> ** **
>
> I have observed from the XMPPFramework mailing list and Github issues,
> that one of the biggest problems that iOS Developers have with including
> XMPP (alongside VoIP) in their iOS apps, is that their apps get terminated
> for receiving to much data while in the background.
>
> ** **
>
> There are proprietary solutions that allow an XMPP client to inform the
> XMPP Server that the app is going to be put in the background. The XMPP
> Server then queues the stanzas until the client in with the XMPP Server,
> which on iOS is less than or equal to 10 minutes. Some solutions also
> filter out presence packets so only the most recent one is queued for each
> jid.
>
> ** **
>
> I appreciate that the problem is iOS specific, but the solution can be
> generic.
>
> ** **
>
> Is this something that should be incorporated into an XEP? or is there
> already a solution for this issue?
>
> ** **
>
> Regards
>
> ** **
>
> Spencer
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Kevin Smith]

On Mon, Oct 28, 2013 at 3:49 PM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

> I missed that XEP-0273 as it is Deferred,
>
> Is it Deferred for any particular reason or just because of inactivity?
>

Inactivity is the only reason XEPs get deferred.

/K

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Waher]

Hello Spencer

As Joachim mentioned, there is interest from the Internet of Things (IoT) 
community to create such a XEP. In fact, it is already planned because there's 
a need, but it is yet to be written. Anybody interested in co-authoring such a 
XEP is welcome to contact me.

The envisioned XEP however is not IOS specific, but rather concerns 
battery-powered sensors, but can be applied to sensors in resource constrained 
networks (where bandwidth is constrained). The same solutions can be applied in 
the IOS case you mentioned, since it can be seen as a resource constrained 
device, when the application runs in the background.

Peter Saint-André mentioned that the deferred XEP 0273 could solve part of this 
issue, by permitting the filtering of certain messages.

Forwarding of offline stanzas (XEP-0160) can also be used. I.e. the bandwidth 
can be controlled by the device, using the presence as an indication when the 
server can send information. (Here battery powered sensors often go into sleep 
mode and wake up regularly to perform a task. They can only receive messages 
when awake.)

Other solutions can be envisioned, for instance using presence=away to signal 
clients restricting them to send important messages only, queuing not as 
important messages for later when online, etc.

Ideas are welcome.

Best regards,
Peter Waher


From: Spencer MacDonald [mailto:spencer.macdonald.ot...@gmail.com]
Sent: den 27 oktober 2013 13:17
To: XMPP Standards
Subject: [Standards] Standard for Throttling/Queueing Stanzas

I have observed from the XMPPFramework mailing list and Github issues, that one 
of the biggest problems that iOS Developers have with including XMPP (alongside 
VoIP) in their iOS apps, is that their apps get terminated for receiving to 
much data while in the background.

There are proprietary solutions that allow an XMPP client to inform the XMPP 
Server that the app is going to be put in the background. The XMPP Server then 
queues the stanzas until the client in with the XMPP Server, which on iOS is 
less than or equal to 10 minutes. Some solutions also filter out presence 
packets so only the most recent one is queued for each jid.

I appreciate that the problem is iOS specific, but the solution can be generic.

Is this something that should be incorporated into an XEP? or is there already 
a solution for this issue?

Regards

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Joachim Lindborg]

This is also needed in the IoT world when small devices are connected.
where we have low level of computational power or are battery operated.
Also co posting to the IOT list




2013/10/27 Peter Saint-Andre 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/27/2013 10:16 AM, Spencer MacDonald wrote:
> > I have observed from the XMPPFramework mailing list and Github
> > issues, that one of the biggest problems that iOS Developers have
> > with including XMPP (alongside VoIP) in their iOS apps, is that
> > their apps get terminated for receiving to much data while in the
> > background.
> >
> > There are proprietary solutions that allow an XMPP client to inform
> > the XMPP Server that the app is going to be put in the background.
> > The XMPP Server then queues the stanzas until the client in with
> > the XMPP Server, which on iOS is less than or equal to 10 minutes.
> > Some solutions also filter out presence packets so only the most
> > recent one is queued for each jid.
> >
> > I appreciate that the problem is iOS specific, but the solution can
> > be generic.
> >
> > Is this something that should be incorporated into an XEP? or is
> > there already a solution for this issue?
>
> This is one reason we defined SIFT:
>
> http://xmpp.org/extensions/xep-0273.html
>
> However, that might be more than we need. Perhaps something simpler
> would be of interest?
>
> Peter
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSbZGaAAoJEOoGpJErxa2pg6UP/1PYUTvCcKo1kP5+7G+vRmkC
> h573r1zTOJg4qJQfUKs1I46tzkBmbL5295owf80KH0SsKJ5KTd2f+eqtOcJhj6w2
> 8PxYIFKkxj9uo4ToMlnv7SJHcl5dTIIQphrg4KxTUbf8VJ0G8KJz3zRw1hiHz2aM
> etiroiDL84KXLastoQnKKcpFleQfbhWHeSt9udvNSbWY7o+ySdOMfAUYZpfgy56+
> amYG1PDC9KPr32TEXzukoawdv/ILVrS51RGFsfMjTyaAKhIrhIEa3xm7+8IDlb1k
> kicuImmibo1Yd7kg+SD3ZVvSeR7yeYb6ENfHboLxIsxcPbzOg6PSVb1GQ0qYzEnE
> vZ5Z3wp2uvGt7HuedxXucbqHfJ+Io/oYId/d0n/fG8NXl+xWPa+Pb5+nkmD8zCa1
> l5pmHQkqAfVnvFItOEcYGi0whj9BXU1fngxAVRfHKfEMpFHPhd+XOLfOY9OzNgqw
> V5In7hT1yrtTUB9HMb3jeXUHNXb8aL26vI82MGKgXzUkm9+mprGVb4dcl1PMsizt
> 7QngxEX86rhUP2ByIQLxYW+9ptZ2B9xxkaHSnEFSZYKN/3Yo6ToEp8WwXGpDGbTD
> h0DUsdnpD8yO3IvzhfwW1pS3XQiE44x2/QsxjX9lrTIc0xCdbguotOWGIvM5HVfb
> ZMh/Yz5+oEaZTtFwX8FG
> =AyEt
> -END PGP SIGNATURE-
>



-- 
*Regards*
Joachim Lindborg
CTO, systems architect

*Keynote speaker at GoGonet live IPv6 conferens 12-14
november
 *

Sustainable Innovation AB
Adress: Box 55998 102 16 Stockholm
Besöksadress: Storgatan 31 (Malmgården)
Email: joachim.lindb...@sust.se, www.sust.se
linkedin: http://www.linkedin.com/in/joachimlindborg
Tel +46 706-442270

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/27/2013 10:16 AM, Spencer MacDonald wrote:
> I have observed from the XMPPFramework mailing list and Github
> issues, that one of the biggest problems that iOS Developers have
> with including XMPP (alongside VoIP) in their iOS apps, is that
> their apps get terminated for receiving to much data while in the
> background.
> 
> There are proprietary solutions that allow an XMPP client to inform
> the XMPP Server that the app is going to be put in the background.
> The XMPP Server then queues the stanzas until the client in with
> the XMPP Server, which on iOS is less than or equal to 10 minutes.
> Some solutions also filter out presence packets so only the most
> recent one is queued for each jid.
> 
> I appreciate that the problem is iOS specific, but the solution can
> be generic.
> 
> Is this something that should be incorporated into an XEP? or is
> there already a solution for this issue?

This is one reason we defined SIFT:

http://xmpp.org/extensions/xep-0273.html

However, that might be more than we need. Perhaps something simpler
would be of interest?

Peter

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSbZGaAAoJEOoGpJErxa2pg6UP/1PYUTvCcKo1kP5+7G+vRmkC
h573r1zTOJg4qJQfUKs1I46tzkBmbL5295owf80KH0SsKJ5KTd2f+eqtOcJhj6w2
8PxYIFKkxj9uo4ToMlnv7SJHcl5dTIIQphrg4KxTUbf8VJ0G8KJz3zRw1hiHz2aM
etiroiDL84KXLastoQnKKcpFleQfbhWHeSt9udvNSbWY7o+ySdOMfAUYZpfgy56+
amYG1PDC9KPr32TEXzukoawdv/ILVrS51RGFsfMjTyaAKhIrhIEa3xm7+8IDlb1k
kicuImmibo1Yd7kg+SD3ZVvSeR7yeYb6ENfHboLxIsxcPbzOg6PSVb1GQ0qYzEnE
vZ5Z3wp2uvGt7HuedxXucbqHfJ+Io/oYId/d0n/fG8NXl+xWPa+Pb5+nkmD8zCa1
l5pmHQkqAfVnvFItOEcYGi0whj9BXU1fngxAVRfHKfEMpFHPhd+XOLfOY9OzNgqw
V5In7hT1yrtTUB9HMb3jeXUHNXb8aL26vI82MGKgXzUkm9+mprGVb4dcl1PMsizt
7QngxEX86rhUP2ByIQLxYW+9ptZ2B9xxkaHSnEFSZYKN/3Yo6ToEp8WwXGpDGbTD
h0DUsdnpD8yO3IvzhfwW1pS3XQiE44x2/QsxjX9lrTIc0xCdbguotOWGIvM5HVfb
ZMh/Yz5+oEaZTtFwX8FG
=AyEt
-END PGP SIGNATURE-