Subject: [Simple] Comments to draft-rang-simple-problem-statement-01.txt

From: "Willekens, Marc" <[email-masked]>
Date: Mon, 6 Nov 2006 14:24:18 +0100

Hi,
 
Some comments to the draft http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statement-01.txt
 
This document clearly indicates the main problem for the existing presence systems which are closed systems for a "limited" amount of users. Inter-domain peering on a very large scale basis is even not possible with the existing standards. It is not yet possible to provide the presence service on a world-wide scale basis with different domains and sub-domains.
 
Some comments to this draft document:
 
§3.2
"o  Complexity of presence & frequency of presence change"
=> Complexity: it is important to consider the different possible presence states of the network, device, application, end-user.
=> Frequency: the probability of being in a certain state and the intensity of state changes, i.e. having many different possible presence states does not always imply a high amount of presence state change messages. Instead, it can even help to reduce the amount of required messages.
 
"o  (A2) Presence state changes / hour ... We assumed 3 times an hour for most calculations. Note that for some users in consumer messaging systems, the actual numbers are likely to be much higher."
=> I agree that 3 changes/hour is a very optimistic approach. However, for the existing presence servers, the amount of presence states and presence state changes is still quite limited, certainly in cases where the IM service, making use of the presence info, is used on fixed network broadband connections. For a "mobile" use of the IM service, the network availability state also becomes a major concern: i.e. hot spot coverage, handover between cellular and WLAN networks, ... application transfer between different end user devices, etc...
 
"o  (A12) ... the number will be (A1/A3)*A5."
=> Should this not be 2*(A1/A3)*A5?  (2 Messages: Notify + 200 OK)
 
"o (A16)  ...(A7+A8)*A6"
=> Is it not better to use the definition (A14+A15)*A6 to make the distinction between the un-subscribe and the subscription phase?

§3.3
=> For the optimizations, only two optimization options, i.e. for (A05) and (A12) are considered. Is it not possible to consider also the optimization option for (A15), i.e. avoiding sending a NOTIFY for the un-subscribe? However, I agree that the additional performance gain is very limited (< 1%). 
 
=> The calculations show the effect for optimizations in a reduction of the total amount of messages for the different deployment models with indicated optimizations of 38.6%, 44.1%, 27.6% and 42.7%.
 
However, these models only consider a moderate status change of 3 or 6 presence state changes per hour. This could be considered as a kind of "normal" usage. However, when a higher intensity of presence state changes is considered the indicated optimization effects becomes very small: for a "medium" kind of presence state change with an intensity of  5 min, the optimization effect becomes lower as 15% and for a "high" intensity of 5 sec, the optimization effect is only 0,3%! This clearly indicates the bottleneck for the server-to-server communication and not only between inter-domains but also between presence servers in an own proprietary intra-domain.
 
In the document, only the amount of messages is considered. For the network resource usage, it is also important to consider the required bandwidth for the information transfer. For the very large network peering, this requires ca. 6 Gbps for the "normal" intensity, 10 Gbps for the "medium" intensity and even 640 Gbps for the "high" intensity.
 
Conclusion:
When we want to have a presence system which can be used on a world-wide scale basis with 6 billion potential users, the existing client/server dialog concept is not adequate. Further, it is very hard to predict the amount of generated traffic due to many unknown factors, e.g. which new future applications will make use of this presence information, what will be the end-user acceptance and behavior? As such, a concept architecture is needed which puts no constraints on the expansion of the system and which allows for higher presence state change intensities (normal, medium, high intensity changes).
 
Best regards,
 
Marc Willekens
Mailto:[email-masked] <mailto:[email-masked]> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 8 Nov 2006 09:20:22 +0200

Marc,

Thanks for the valuable comments. See more inline.

--Avshalom

"Willekens, Marc" <[email-masked]> wrote on 06/11/2006 
15:24:18:

> Hi,
> 
> Some comments to the draft http://www.ietf.org/internet-
> drafts/draft-rang-simple-problem-statement-01.txt
> 
> This document clearly indicates the main problem for the existing 
> presence systems which are closed systems for a "limited" amount of 
> users. Inter-domain peering on a very large scale basis is even not 
> possible with the existing standards. It is not yet possible to 
> provide the presence service on a world-wide scale basis with 
> different domains and sub-domains.

Interdomain only highlights the issue more, scaling to millions of
users in the same domain will have similar scaling issues.
> => Complexity: it is important to consider the different possible 
> presence states of the network, device, application, end-user.
> => Frequency: the probability of being in a certain state and the 
> intensity of state changes, i.e. having many different possible 
> presence states does not always imply a high amount of presence 
> state change messages. Instead, it can even help to reduce the 
> amount of required messages.

Will clarify in the next version

> 
> "o  (A2) Presence state changes / hour ... We assumed 3 times an 
> hour for most calculations. Note that for some users in consumer 
> messaging systems, the actual numbers are likely to be much higher."
> => I agree that 3 changes/hour is a very optimistic approach. 
> However, for the existing presence servers, the amount of presence 
> states and presence state changes is still quite limited, certainly 
> in cases where the IM service, making use of the presence info, is 
> used on fixed network broadband connections. For a "mobile" use of 
> the IM service, the network availability state also becomes a major 
> concern: i.e. hot spot coverage, handover between cellular and WLAN 
> networks, ... application transfer between different end user devices, 
etc...
> => Should this not be 2*(A1/A3)*A5?  (2 Messages: Notify + 200 OK)

We multiply by 2 later - e.g. E07, E08, E10

> 
> "o (A16)  ...(A7+A8)*A6"
> => Is it not better to use the definition (A14+A15)*A6 to make the 
> distinction between the un-subscribe and the subscription phase?

Agree.

> 
> 
> §3.3
> => For the optimizations, only two optimization options, i.e. for 
> (A05) and (A12) are considered. Is it not possible to consider also 
> the optimization option for (A15), i.e. avoiding sending a NOTIFY 
> for the un-subscribe? However, I agree that the additional 
> performance gain is very limited (< 1%). 

It is very limited and it may be better not to make the model more complex

> 
> => The calculations show the effect for optimizations in a reduction
> of the total amount of messages for the different deployment models 
> with indicated optimizations of 38.6%, 44.1%, 27.6% and 42.7%.
> 
> However, these models only consider a moderate status change of 3 or
> 6 presence state changes per hour. This could be considered as a 
> kind of "normal" usage. However, when a higher intensity of presence
> state changes is considered the indicated optimization effects 
> becomes very small: for a "medium" kind of presence state change 
> with an intensity of  5 min, the optimization effect becomes lower 
> as 15% and for a "high" intensity of 5 sec, the optimization effect 
> is only 0,3%! This clearly indicates the bottleneck for the server-
> to-server communication and not only between inter-domains but also 
> between presence servers in an own proprietary intra-domain.

Agree. The inter domain helps to demonstrate the problem more easily
since in intra-domain there may be ways to load balance between the
servers etc. but the bottom line is that the same issues exist in intra
domain. 
It is true that if the intensity of changes increases then the considered
optimizations will have less affect.
> 
> In the document, only the amount of messages is considered. For the 
> network resource usage, it is also important to consider the 
> required bandwidth for the information transfer. For the very large 
> network peering, this requires ca. 6 Gbps for the "normal" 
> intensity, 10 Gbps for the "medium" intensity and even 640 Gbps for 
> the "high" intensity.

Agree, will add that calculation to the next version.
> 
> Conclusion:
> When we want to have a presence system which can be used on a world-
> wide scale basis with 6 billion potential users, the existing 
> client/server dialog concept is not adequate. Further, it is very 
> hard to predict the amount of generated traffic due to many unknown 
> factors, e.g. which new future applications will make use of this 
> presence information, what will be the end-user acceptance and 
> behavior? As such, a concept architecture is needed which puts no 
> constraints on the expansion of the system and which allows for 
> higher presence state change intensities (normal, medium, high 
> intensity changes).

It seems that we need to think about the problem in a different way.
We need to think about scalability as part of the protocol design.
The IETF tends not to think about actual deployments when designing
a protocol but in this case it seems that if we do not think about
scalability with the protocol design it will not be possible to scale
since the issues that we have are inherent to the protocol and will not
be solved by smart architecture.

> 
> Best regards,
> 
> Marc Willekens
> Mailto:[email-masked]