Subject: [Simple] SIMPLE presence scaling

From: "Willekens, Marc" <[email-masked]>
Date: Wed, 25 Jul 2007 19:58:56 +0200

Hi Avshalom,
I agree with your "red statement" in your slides. All the current
proposed optimizaton techniques only delays the problem a little bit in
time but do not solve the real issue, certainly when presence will be
used with higher frequency ranges and with more equipment.
 
Is the main problem not related to the fact that no differentiation can
be made for the same notification for all the different subscribers,
e.g. maybe some watchers want to be informed immediatly, and maybe some
others don't always need the latest status change. The SIMPLE and even
the XMPP protocol does not support this as far as I know. So, we
certainly have to look at the problem from another point of view.
 
br,
Marc.
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 25 Jul 2007 21:10:31 +0300

Hi Marc,

What you suggest is one way to look at the issue differently.
If my memory is correct I think that Henning has suggested similar 
approach.

We really need to move on in the requirements work and start working on 
suggestions as soon as possible.

--Avshalom

"Willekens, Marc" <[email-masked]> 
25/07/2007 20:58

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
[email-masked]
Subject
[Simple] SIMPLE presence scaling

Hi Avshalom,
I agree with your "red statement" in your slides. All the current proposed 
optimizaton techniques only delays the problem a little bit in time but do 
not solve the real issue, certainly when presence will be used with higher 
frequency ranges and with more equipment.
 
Is the main problem not related to the fact that no differentiation can be 
made for the same notification for all the different subscribers, e.g. 
maybe some watchers want to be informed immediatly, and maybe some others 
don't always need the latest status change. The SIMPLE and even the XMPP 
protocol does not support this as far as I know. So, we certainly have to 
look at the problem from another point of view.
 
br,
Marc._______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Willekens, Marc" <[email-masked]>
Date: Wed, 25 Jul 2007 20:36:02 +0200

Hi Avshalom,
Are you referring to the "Timed presence" proposal from Henning which
basically plays with the "Subscription' state to enable/disable the
notification based on automatic trigger points.
 
There are indeed many different end-user requirements. Mostly, all
people want to be informed directly, until they have to pay in addition
for that. In practice however, there is something as "directly", "as
soon as possible", "as late as possible", "not after a certain moment in
time", etc. Both the Presence server of the presentity and the presence
server of the watcher can make use of these practices to optimize their
traffic to serve the user as close as possible with their whishes. When
the capacity of the servers and the networks is there, why not use this
capacity to serve the end-user even better? 
 
Br,
Marc.

________________________________

From: ext Avshalom Houri [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2007 13:11
To: Willekens, Marc
Cc: [email-masked]
Subject: Re: [Simple] SIMPLE presence scaling

Hi Marc, 

--Avshalom

25/07/2007 20:58 

To

Hi Avshalom, 

br,

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 25 Jul 2007 21:52:49 +0300

Hi Marc,

I am referring to timed presence and also the on demand presence mentioned 
in 2.4 of
draft-houri-simple-interdomain-scaling-optimizations-00.txt

The current assumption is that if I put a user in my BL I really want to 
know everything about that user. It is not really true.

Regards
--Avshalom

25/07/2007 21:36

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
[email-masked]
Subject
RE: [Simple] SIMPLE presence scaling

Hi Avshalom,
 
There are indeed many different end-user requirements. Mostly, all people 
want to be informed directly, until they have to pay in addition for that. 
In practice however, there is something as "directly", "as soon as 
possible", "as late as possible", "not after a certain moment in time", 
etc. Both the Presence server of the presentity and the presence server of 
the watcher can make use of these practices to optimize their traffic to 
serve the user as close as possible with their whishes. When the capacity 
of the servers and the networks is there, why not use this capacity to 
serve the end-user even better? 
 
Br,
Marc.

Hi Marc, 

--Avshalom

To

Hi Avshalom, 

br,