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

["victoria beltran" <vbeltran at entel.upc.edu>]

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

Attachment: normal_SIMPLE_message_computation.xls
Description: MS-Excel spreadsheet

Attachment: normal_partialRLMI_SIMPLE_message_computation.xls
Description: MS-Excel spreadsheet

Attachment: NOTIFY_PRLMI_PNotification_SIMPLE_message_computation.xls
Description: MS-Excel spreadsheet

Attachment: SIMPLE_message_computation-03.xls
Description: MS-Excel spreadsheet

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple