Subject: Re: [xmpp] 3921bis: probe + unavailable

From: Jonas Lindberg <[email-masked]>
Date: Mon, 1 Feb 2010 20:17:51 +0100

On Sun, Jan 31, 2010 at 2:41 AM, Jonathan Schleifer
<[email-masked]> wrote:
> Am 30.01.2010 um 23:29 schrieb Jonas Lindberg:
>
>> While I agree this would simplify the protocol a little, I am not
>> convinced it is a change worth making.
>>
>> First of all, not responding to probe when unavailable is a pretty good
>> optimization. A large part of Xmpp traffic is presence. This change would
>> further significantly increase the presence traffic, making scaling more
>> challenging and adding load to c2s and s2s connections. For example, a cell
>> phone xmpp client may be better off not getting potentially thousands of
>> presence unavailable stanzas for offline friends when connecting over gprs.
>>
>> I'm also not convinced this change make it significantly easier to
>> implement xmpp clients/servers. Especially if we are going to recommend that
>> clients and servers SHOULD cope with no response for legacy reasons.
>
> I think you got something wrong here: We are not talking about what happens
> when you connect. We are talking about presence probes sent from one client
> to a server. A mobile client would not get any unavailable presence more
> than it would get now, expect it requests it by doing a probe.

"4.3.2. Server Processing of Inbound Presence Probe", seems to apply
to probes sent from clients as well as server generated probes,
including those generated on initial presence. Not sure what I'm
missing?

How do I tell if "<presence from=[email-masked]/balcony'
to=[email-masked]' type='probe'/>" is sent by client or server
generated?

> --
> Jonathan

---

From: "Ben Schumacher" <[email-masked]>
Date: Mon, 1 Feb 2010 11:56:37 -0800

On 01/30/2010 03:29 PM, Jonas Lindberg wrote:
> First of all, not responding to probe when unavailable is a pretty
> good optimization. A large part of Xmpp traffic is presence. This
> change would further significantly increase the presence traffic,
> making scaling more challenging and adding load to c2s and s2s
> connections. For example, a cell phone xmpp client may be better off
> not getting potentially thousands of presence unavailable stanzas for
> offline friends when connecting over gprs.
>
> implement xmpp clients/servers. Especially if we are going to
> recommend that clients and servers SHOULD cope with no response for
> legacy reasons.
>

Jonas-

I agree with your points -- it would likely result in extra traffic. 
That being said, I much prefer this to the ambiguity (and potential 
presence leak) of the prior language. As it happens, servers and clients 
will *always* have to cope with no response as this is a network'd 
service and packets can get lost, etc, so I'm not sure the language 
should be "SHOULD" re: legacy services, but rather maybe a note that 
indicates that you may not get a response.

Ben

---

From: Jonas Lindberg <[email-masked]>
Date: Mon, 1 Feb 2010 21:34:24 +0100

> indicates that you may not get a response.

While one can argue it's a little prettier, I don't think it's very practical.

Making this change at scale requires very significant work and comes
at a significant cost in traffic increase (consider user with >1000
mostly offline friends). It will also result in worse user experience
for users with large rosters on low bandwidth connections, like the
common scenario of a cell phone.

Clients will need to deal with presence leaks as long as delivery
isn't guaranteed.. How about just adding an probe answer-required
extension?

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Feb 2010 13:46:52 -0700

> indicates that you may not get a response.

Version -03 of 3921bis currently reads:

   2.  Else, if the contact has no available resources, then the server
       SHOULD reply to the presence probe by sending to the user the
       full XML of the last presence stanza of type "unavailable"
       received by the server from the contact (however, the server MAY
       opt to not reply at all).

My working copy of 3921bis proposes:

   2.  Else, if the contact has no available resources, then the server
       MUST reply to the presence probe by sending to the user a
       presence stanza of type "unavailable"; this presence stanza MAY
       include the full XML of the last unavailable presence stanza that
       the server received from the contact, if appropriate in
       accordance with local security policies, otherwise it will
       indicate only that the contact is unavailable.

   CS: <presence from=[email-masked]'
                 to=[email-masked]'
                 type='unavailable'/>

I understand that the MUST here is an imposition on servers. IMHO the
deterministic nature of the unavailable has many benefits, but I can see
why large service providers would prefer to return a stanza to the
probing user only if the contact is online. So I think it's good that we
discuss the tradeoffs here.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 01 Feb 2010 21:46:50 +0100

Jonas Lindberg wrote:
[...]
> mostly offline friends). It will also result in worse user experience

actually, what is the estimate for average online friends per user?
0.3 or even lower?

A sensible approach might be for the contacts server to reply with 
unavailable if the contact has been online recently (within the last
24 hours?) and not to reply at all if the contact has been offline for
weeks.
Anyway... -1 on "MUST".

> common scenario of a cell phone.

The users server might filter the unavailable presence if that is the
"expected" or known state of that contact.

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Feb 2010 13:58:53 -0700

> common scenario of a cell phone.

I would find SHOULD acceptable here. How about the following text?

   2.  Else, if the contact has no available resources, then the server
       SHOULD reply to the presence probe by sending to the user a
       presence stanza of type "unavailable" (although sending
       unavailable presence here is preferable because it results in a
       deterministic answer to the probe, it is not mandatory because it
       can greatly increase the number of presence notifications
       generated by the contact's server); this presence stanza MAY
       include the full XML of the last unavailable presence stanza that
       the server received from the contact, if appropriate in
       accordance with local security policies, otherwise it will
       indicate only that the contact is unavailable.

Peter

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

---

From: Justin Karneges <[email-masked]>
Date: Mon, 1 Feb 2010 17:03:36 -0800

> discuss the tradeoffs here.

A large benefit is to prevent a jabber:iq:last storm.  We don't want there to 
be any reason for a client to poll its entire roster.

I can see why a mobile client might not be interested in having that 
information pushed at it on login, to reduce resource usage.  Jonas' 
suggestion of making this a client-controlled option is probably best, but I 
don't know what the default behavior should be.

Also, there has been discussion in the past about sending presence only of 
certain contacts, groups, etc, when mobile, so the solution for filtering out 
unavailable presence might fit right in with that maybe.

Another thing: this issue is actually two-part: 1) should remote servers reply 
to probes if the contact is unavailable?  and 2) should the local server send 
unavailable presence to contacts that just logged in?  Both of these have 
resource usage implications, but only the second one impacts the client.

-Justin

---

From: Jonas Lindberg <[email-masked]>
Date: Tue, 2 Feb 2010 11:08:58 +0100

Peter's new proposal sounds good to me.

A few more comments inline below:

> don't know what the default behavior should be.

I wouldn't want to change the default behavior in a way that breaks
the user experience on clients that work well today.

> resource usage implications, but only the second one impacts the client.

I'd prefer continuing to treat these as one in the spec to keep it
simple. I also would not want it to be a MUST for (1).

> -Justin
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Feb 2010 17:35:16 -0700

> be any reason for a client to poll its entire roster.

I completely agree with that sentiment!

> don't know what the default behavior should be.

Right now we have no protocol for management of account settings such as
this (although we could use ad-hoc commands, XEP-0050). I don't think we
want to introduce such a dependency now, at least not for core delivery
semantics.

> unavailable presence might fit right in with that maybe.

Maybe. :)

> resource usage implications, but only the second one impacts the client.

I agree with Jonas that these are so closely connected as to be worth
keeping together in the spec.

Peter

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

---

From: Jonathan Schleifer <[email-masked]>
Date: Wed, 10 Feb 2010 17:30:35 +0100

Am 01.02.2010 um 20:17 schrieb Jonas Lindberg:

> Not sure what I'm

Your mobile client would not get any presence of type unavailable when  
you did not do a probe from your client. So how exactly should it  
increase traffic for mobile clients? If you don't probe, you don't get  
a reply, simple as that.

--
Jonathan

---

From: Jonas Lindberg <[email-masked]>
Date: Wed, 10 Feb 2010 17:53:30 +0100

On Wed, Feb 10, 2010 at 5:30 PM, Jonathan Schleifer
<[email-masked]>wrote:

> Your mobile client would not get any presence of type unavailable when you
> did not do a probe from your client. So how exactly should it increase
> traffic for mobile clients? If you don't probe, you don't get a reply,
> simple as that.
>

Servers send probes on clients' behalf, for example when receiving initial
presence from a client.

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 10 Feb 2010 13:59:41 -0700

> I completely agree with that sentiment!

As do I, however without a timestamp in the unavailable presence (which in
itself is a presence leak), I see many clients still doing iq:last scans --
which are themselves a presence leak, but an unplugged one in many servers.

-- 
Joe Hildebrand