[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Victoria,

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

--Avshalom

"victoria beltran" <vbeltran at entel.upc.edu> 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
> Simple at ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple