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

[Avshalom Houri <[e-mail]>]

Victoria,

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

--Avshalom





"victoria beltran" <[e-mail]> wrote on 08/10/2007 17:55:02:

>  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.
> 
Correct. This is a typo, will fix in next version.
> 
> 
> 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.
> 

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.

> 
> 
> 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
> 
> 
See text for I07. We assume that the full NOTIFY is sent in the initial
NOTIFY.

> 
> 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).

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

> 
> 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.

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

> 
> 
> 
> 
> 
> 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.
> 
Correct, will fix.
> 
> 
> 
> 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.
> 

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.

> 
> 
> 
> 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)).
> 
You seem to be correct also here. Many thanks for the suggested formulas.
Will verify this again and fix it in the next version.
> 
> 
> 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.
> 
> 
See my replies to points 3 and 4.
> 
> 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" 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple