Subject: [Simple] draft-ietf-simple-interdomain-scaling-analysis

From: "victoria beltran" <[email-masked]>
Date: Mon, 8 Oct 2007 17:55:02 +0200

Hi,

I am interested in presence systems and presence traffic load in these 
systems. I have read the draft 
draft-ietf-simple-interdomain-scaling-analysis-01.txt and the versions in 
http://www.nostrum.com/~rjsparks/draft-ietf-simple-interdomain-scaling-analysis-02.txt 
and http://www.nostrum.com/~rjsparks/SIMPLE_message_computation-02.xls of 
draft and message computation excel file sent by Houri. I have comments 
about some computations and assumptions done in the draft that are not clear 
for me. Also I describe some contributions that, in my view, could improve 
the quality of message computations.

1. Although in the excel file the calculation of I07 variable is correct, in 
the draft (in 2.3.2 section) I07 is described as 
(I03*C06*C09)+((C04/C05)*C11) which is a mistake. This variable is computed 
as I03*C06*(C09+(C04/C05)*C11) in the excel file.

2. The draft focuses on studying presence traffic between presence systems. 
Then, in my point of view, in order to be more accurate in the computation 
of presence traffic when a RLS is used we should take the following presence 
traffic into account.

            a) Traffic due to initial SUBSCRIBE messages sent by the RLS to 
each resource of the list when the user subscribes to his resource list. 
This traffic should be included in I09 variable.

            b) Traffic due to SUBSCRIBE messages sent by the RLS to each 
resource of the list in order to keep presence subscriptions alive. This 
traffic should be included in S09 variable

            c) Traffic due to terminating SUBSCRIBE messages (with Expires 
header equal to zero) that are sent by the RLS to each resource of the list 
in order to terminate presence subscriptions. This traffic should be 
included in T09 variable.

3. I am not sure if the computation of S03 variable takes account of RLS 
case. In this computation NOTIFY messages only include one presence 
document. It can be due to partial RLMI documents are used and then only 
presence about the presentity whose state has changed is notified. In other 
case, if full state RLMI documents are used, S03 variable should be 
calculated as following: (S01*(C9+(C04/C05)*C11)+S02*C10)*C06*C04

4. In T07 variable computation only one presence document is included in 
terminating NOTIFYs, including when RLS is used. However RFC 4662 (A SIP 
Event Notification Extension for Resource Lists) states that any terminating 
NOTIFY should be full state containing presence about all the presentities 
in the resource list. Then, Why is only one presence document included in 
the terminating NOTIFY when RLS is used? According to RFC 4662 the 
computation of T07 variable should be:  T03*C06*(C09+(C04/C05)*C11).

In addition, when partial notification is applied the presence document in 
terminating NOTIFYs is partial as we can see in 
http://www.nostrum.com/~rjsparks/SIMPLE_message_computation.xls, but this 
document should be full state according to RFC 4662. Sending partial 
documents in terminating NOTIFYs should be an optimization independent of 
standard partial presence notification.

5. The NOTIFY optimization in the draft only avoids NOTIFY messages for 
refreshing subscriptions, however the draft draft-eitf-sip-subnot-etags-01 
indicates that this method also avoids NOTIFY messages due to terminating 
SUBSCRIBE's. Then, when NOTIFY optimization is used, T07 and T08 variables 
should be zero. If we update excel file of messages computation setting T07 
and T08 variables to zero,  the total bytes of terminating NOTIFY messages 
(T09 variable) is 16,400,400,000 instead of 93,800,000,000. The reduction of 
bytes is important.

6. When partial notification is applied the size of presence documents is 
200 bytes. I consider this size too small since examples of partial presence 
documents in draft-ietf-simple-partial-pidf-format-08 are quite bigger. Only 
root tag in these examples are about 300 bytes. In my point of view, a 
bigger average size of partial presence documents, like 500 bytes, should be 
more appropriate.

7. When a RLS is used, the calculations of bytes do not care all elements of 
notifications. A NOTIFY message contains a multipart body formed by one RLMI 
document and several presence documents. The draft does not include the RLMI 
document and multipart boundaries when it computes total bytes of RLS's 
notifications. Each presentity whose presence document is included in the 
notification is associated  to one "resource" tag in the RLMI document. An 
average size of this tag could be 160 bytes according to  examples in RFC 
4662. In addition other elements have to be taken into account, like the 
root node (also called root tag) of the RLMI document and multipart 
boundaries. In a RLMI notification a multipart boundary indicates the start 
of the RLMI document or a presence document. An average size for both root 
node and multipart header could be 144 bytes according to examples in RFC 
4662. The inclusion of these considerations into the computation of bytes 
could increase the number of total bytes significantly when RLS is used. For 
this reason, I have modified the excel file to take these bytes into 
account. I have defined new constants and modified some variables. Now, when 
RLS is used, different computations are necessary:

C13= item size per contact in RLMI document = 160 bytes

C14= size of multipart boundary in RLMI notifications = 144 bytes

C15 = size of XML root node in RLMI document = 144 bytes

I07= bytes_without_rls: I03*C06*(C09*C11)

         bytes_with_rls: I03*C06*(C09+C14+C15+C04*(C13+C14+C11))

S03= bytes_without_rls: (S01*(C09+C11)+S02*C10)*C04*C06

          bytes_with_rls: 
(S01*(C09+C14+C15+C04*(C13+C14+C11)+S02*C10)*C04*C06

S08=  bytes_without_rls= (S04*C07+S05*C08+S06*(C09+c11)+S07*C10)*C06

          bytes_with_rls= (S04*C07+S05*C08+S06*(C09+ 
C14+C15+C04*(C13+C14+C11)) +S07*C10)*C06

T07= bytes_without_rls = (T03*C06*(C09+C11)).

         bytes_with_rls =  (T03*C06*(C09+ C14+C15+C04*(C13+C14+C11)).

8. The enclosed file called "normal_SIMPLE_message_computation.xls" is a 
file that contains the changes described in section 7, and assumes full 
state RLMI notifications (due to comments in sections 3 and 4). This file 
can be compared with SIMPLE_message_computation-02.xls ( without NOTIFY 
optimization. With the constants of the second figure in the draft (section 
2.5, "SIMPLE with Dialog Optimization")- 4 presentities, 3 presence changes 
per hour and 40000 watchers - the following total bytes (B01 variable) are 
obtained:

normal_SIMPLE_message_computation.xls:  56,066,320,000

SIMPLE_message_computation-02.xls without NOTIFY optimization: 
18,190,800,000

We can see that the considerations in section 7 increase the total bytes 
significantly. This fact is due to this considerations assume that the RLS 
always notifies full state RLMI documents. In the enclosed file called 
"normal_partialRLMI_SIMPLE_message_computation.xls" the RLS notifies partial 
RLMI documents when a presentity changes its presence state. In this way, 
when RLS is used the total bytes computed are 21,176,080,000. Partial state 
RLMI documents reduce a lot of presence traffic, but still this number is 
bigger than 18,190,800,00. This fact shows that the draft should care the 
comments explained in section 7.

9.- The enclosed file called 
"NOTIFY_PRLMI_PNotification_SIMPLE_message_computation.xls" takes 
considerations in section 5, 6 and 7 into account. Partial Notification is 
applied with an average size of 500 bytes for partial presence documents and 
also NOTIFY optimization is used. I have modified 
SIMPLE_message_computation-02.xls to include partial notification, and the 
resulting file is "SIMPLE_message_computation-03.xls" which is enclosed. 
Then, we can compare  "SIMPLE_message_computation-03.xls" and 
"NOTIFY_PRLMI_PNotification_SIMPLE_message_computation.xls". Considering the 
constants in section 2.9 of the draft - 10 presentities, RLS, 6 presence 
changes per hour, notify and partial notification optimizations - the 
following value for B01 variable is obtained:

"NOTIFY_PRLMI_PNotification_SIMPLE_message_computation.xls" : 
19,029,560,000,000

"SIMPLE_message_computation-03.xls" : 10,630,400,000,000

I am studying methods for reducing and estimating  presence traffic so i 
would be grateful to any response that help me to understand better this 
draft and achieve good analytical studies of presence traffic.

Thanks

Victoria Beltrán
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 18 Oct 2007 20:23:27 +0200

Victoria,

Thanks for the comments. I did not have time to go through them yet but it 
is
very good timing as I am working on the next version of the draft.

Will respond specifically to the comments next week.

Thanks
--Avshalom

"victoria beltran" <[email-masked]> 
08/10/2007 17:55

To
<[email-masked]>
cc

Subject
[Simple] draft-ietf-simple-interdomain-scaling-analysis

 Hi,

and http://www.nostrum.com/~rjsparks/SIMPLE_message_computation-02.xls of 
draft and message computation excel file sent by Houri. I have comments 
about some computations and assumptions done in the draft that are not 
clear 
for me. Also I describe some contributions that, in my view, could improve 

1. Although in the excel file the calculation of I07 variable is correct, 
in 
the draft (in 2.3.2 section) I07 is described as 
(I03*C06*C09)+((C04/C05)*C11) which is a mistake. This variable is 
computed 
as I03*C06*(C09+(C04/C05)*C11) in the excel file.

2. The draft focuses on studying presence traffic between presence 
systems. 
Then, in my point of view, in order to be more accurate in the computation 

of presence traffic when a RLS is used we should take the following 
presence 
traffic into account.

            a) Traffic due to initial SUBSCRIBE messages sent by the RLS 
to 
each resource of the list when the user subscribes to his resource list. 
This traffic should be included in I09 variable.

header equal to zero) that are sent by the RLS to each resource of the 
list 
in order to terminate presence subscriptions. This traffic should be 
included in T09 variable.

presence about the presentity whose state has changed is notified. In 
other 

4. In T07 variable computation only one presence document is included in 
terminating NOTIFYs, including when RLS is used. However RFC 4662 (A SIP 
Event Notification Extension for Resource Lists) states that any 
terminating 
NOTIFY should be full state containing presence about all the presentities 

should be zero. If we update excel file of messages computation setting 
T07 
and T08 variables to zero,  the total bytes of terminating NOTIFY messages 

(T09 variable) is 16,400,400,000 instead of 93,800,000,000. The reduction 
of 
bytes is important.

6. When partial notification is applied the size of presence documents is 
200 bytes. I consider this size too small since examples of partial 
presence 
documents in draft-ietf-simple-partial-pidf-format-08 are quite bigger. 
Only 
root tag in these examples are about 300 bytes. In my point of view, a 
bigger average size of partial presence documents, like 500 bytes, should 
be 
more appropriate.

7. When a RLS is used, the calculations of bytes do not care all elements 
of 
notifications. A NOTIFY message contains a multipart body formed by one 
RLMI 
document and several presence documents. The draft does not include the 
RLMI 
document and multipart boundaries when it computes total bytes of RLS's 
notifications. Each presentity whose presence document is included in the 
notification is associated  to one "resource" tag in the RLMI document. An 

boundaries. In a RLMI notification a multipart boundary indicates the 
start 

node and multipart header could be 144 bytes according to examples in RFC 
4662. The inclusion of these considerations into the computation of bytes 
could increase the number of total bytes significantly when RLS is used. 
For 
this reason, I have modified the excel file to take these bytes into 
account. I have defined new constants and modified some variables. Now, 
when 
RLS is used, different computations are necessary:

          bytes_with_rls: 

8. The enclosed file called "normal_SIMPLE_message_computation.xls" is a 
file that contains the changes described in section 7, and assumes full 
state RLMI notifications (due to comments in sections 3 and 4). This file 
can be compared with SIMPLE_message_computation-02.xls ( without NOTIFY 
optimization. With the constants of the second figure in the draft 
(section 
2.5, "SIMPLE with Dialog Optimization")- 4 presentities, 3 presence 
changes 
per hour and 40000 watchers - the following total bytes (B01 variable) are 

obtained:

always notifies full state RLMI documents. In the enclosed file called 
"normal_partialRLMI_SIMPLE_message_computation.xls" the RLS notifies 
partial 
RLMI documents when a presentity changes its presence state. In this way, 
when RLS is used the total bytes computed are 21,176,080,000. Partial 
state 
RLMI documents reduce a lot of presence traffic, but still this number is 
bigger than 18,190,800,00. This fact shows that the draft should care the 
comments explained in section 7.

applied with an average size of 500 bytes for partial presence documents 
and 
also NOTIFY optimization is used. I have modified 
SIMPLE_message_computation-02.xls to include partial notification, and the 

"NOTIFY_PRLMI_PNotification_SIMPLE_message_computation.xls". Considering 
the 

Thanks

Victoria Beltrán
[attachment "normal_SIMPLE_message_computation.xls" deleted by Avshalom 
Houri/Haifa/IBM] [attachment 
"normal_partialRLMI_SIMPLE_message_computation.xls" deleted by Avshalom 
Houri/Haifa/IBM] [attachment 
"NOTIFY_PRLMI_PNotification_SIMPLE_message_computation.xls" deleted by 
Avshalom Houri/Haifa/IBM] [attachment "SIMPLE_message_computation-03.xls" 
deleted by Avshalom Houri/Haifa/IBM] 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Avshalom Houri <[email-masked]>
Date: Mon, 29 Oct 2007 15:19:50 +0200

Victoria,

Many thanks for the deep review.
Please see comments in-line

--Avshalom

clear 
computed 
> as I03*C06*(C09+(C04/C05)*C11) in the excel file.
Correct. This is a typo, will fix in next version.
systems. 
presence 
to 

list 
> included in T09 variable.

This will be internal traffic and will not affect the domain to domain
traffic. Analogues to this is the traffic from the client to the server
and back, traffic to the XDMS to get the resource list and many more.

other 
> calculated as following: (S01*(C9+(C04/C05)*C11)+S02*C10)*C06*C04
See text for I07. We assume that the full NOTIFY is sent in the initial
NOTIFY.

terminating 
> computation of T07 variable should be:  T03*C06*(C09+(C04/C05)*C11).

Could not find where 4662 says so. Can you point to the text?

> standard partial presence notification.

Could not find where 4662 says so. Can you point to the text?

T07 
> (T09 variable) is 16,400,400,000 instead of 93,800,000,000. The 
reduction of 
Correct, will fix.
presence 
Only 
> bigger average size of partial presence documents, like 500 bytes, 
should be 

In the example in draft-ietf-simple-partial-pidf-format-08 the number of 
bytes
is actually bigger then 900... On the other hand people said that the 3000 
bytes
that we have used in for presence document size is too big.
So I will change probably both numbers in the next version.

RLMI 
RLMI 

start 
For 
when 
>          bytes_with_rls =  (T03*C06*(C09+ C14+C15+C04*(C13+C14+C11)).
You seem to be correct also here. Many thanks for the suggested formulas.
Will verify this again and fix it in the next version.

(section 
changes 

partial 
state 
> comments explained in section 7.
See my replies to points 3 and 4.
and 

the 

> [attachment "normal_SIMPLE_message_computation.xls" deleted by 
> Avshalom Houri/Haifa/IBM] [attachment 
> "normal_partialRLMI_SIMPLE_message_computation.xls" deleted by 
> Avshalom Houri/Haifa/IBM] [attachment 
> "NOTIFY_PRLMI_PNotification_SIMPLE_message_computation.xls" deleted 
> by Avshalom Houri/Haifa/IBM] [attachment 
> "SIMPLE_message_computation-03.xls" deleted by Avshalom Houri/Haifa/
> IBM] _______________________________________________
> Simple mailing list
> [email-masked]