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

From: Victoria Beltrán Martínez <[email-masked]>
Date: Wed, 23 Jan 2008 13:23:43 +0100

Hi,

I have read 
http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-03.txt 
and I would like to comment some issues:

1.- Each time you compute the number of bytes of NOTIFY messages when 
dialog optimization is used, you don't add the size of the multipart 
boundary associated with the RLMI document. If you see RFC 4662, you 
will see that there is a multipart boundary just before the RLMI 
document. For example, in the computation of I07 variable, I think that 
the most correct calculation of bytes for NOTIFY messages should be 
(I03*C06*(C09+C15+C14))+(I03*C06*C04*(C11+C13+C14)), instead of 
(I03*C06*(C09+C15))+(I03*C06*C04*(C11+C13+C14)). Anyway the difference 
between both formulas is small.

2.- In S08 variable calculation, you calculate the bytes of NOTIFY 
messages by the following way:

If dialog optimization is not used: C06*(SO6*(C09+C15+C11+C13+C14))
If dialog optimization is used: C06*(S06*((C09+C15)+(C04*(C11+C13+C14))))

I don’t understand these formulas. I think that the computation should 
be C06*(SO6*(C09+C11)) without dialog optimization, because C13, C14 and 
C15 variables don’t make sense in this case.

When dialog optimization is used you say "See section 4.5 in [12]. The 
fact that the full state needs to be returned in a NOTIFY response...". 
However, in section 4.5 of RFC 4662 there are no signs of necessity or 
requirement of full state, but full state is only recommended via the 
following sentence: "Immediate notifications triggered as a result of 
subsequent SUBSCRIBE messages SHOULD include an RLMI document in which 
the full state is indicated". SHOULD word indicates recommendation, not 
requirement. We can't state that full state is required on the basis of 
section 4.5 of RFC 4662. However, in section 5.2 of the same RFC the 
following is stated: "The first NOTIFY sent in a subscription MUST 
contain full state, as must the first NOTIFY sent after receipt of a 
SUBSCRIBE request for the subscription". I think that the authors wanted 
to say that a full state NOTIFY message after both initial and 
subsequent SUBSCRIBE messages is required. It means that only NOTIFY 
messages due to presence changes can contain partial state. If I am 
right, both sentences (in 4.5 and 5.2 sections) are a bit contradictory. 
Nevertheless, if the sentence in 5.2 section means what I think, would 
it be better to refer to section 5.2 in the draft (not to section 4.5). 
What do you think?

3.- In the computation of T07 variable, it is assumed that only a single 
presentity is changed when dialog optimization is used. I don’t 
understand why this assumption is done. RFC 4662 does not make 
difference between subsequent and terminating SUBSCRIBE messages. Then, 
the previous reason to include full state in NOTIFY messages (triggered 
by receipts of subsequent SUBSCRIBE messages) is also applicable to 
terminating SUBSCRIBE messages. I don't find any reason to treat 
terminating messages differently. In my opinion terminating NOTIFY 
messages had better containing full state RLMI lists in which 
presentities have “terminated” state. By "terminated" state the 
presentities’ presence documents don’t need to be added into the NOTIFY 
message. With this consideration the computation of bytes due to 
terminating NOTIFYs would be:

T03*C06*(C09 +C14+C15+C04*C13)
(I have included C14 variable for the boundary after RLMI document)

Victoria Beltrán

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

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 23 Jan 2008 17:29:00 +0200

Victoria,

Many thanks for your continuos review. Comments below.

--Avshalom

Victoria Beltrán Martínez <[email-masked]> wrote on 23/01/2008 

> between both formulas is small.

Correct. Will add this.

> If dialog optimization is used: 
C06*(S06*((C09+C15)+(C04*(C11+C13+C14))))
> 
> I don?t understand these formulas. I think that the computation should 

> C15 variables don?t make sense in this case.
> 
Correct. Strange mistake.

> it be better to refer to section 5.2 in the draft (not to section 4.5). 

Agree that I should refer to section 5.2 instead of 4.5.
I have interpreted this to mean that the first NOTIFY MUST contain the 
full state
while subsequent ones (even due to subscription refreshes and/or 
termination) may
contain partial state. This alludes to question 3 below also.
I am not sure if my interpretation is correct. I think that you can submit 
a question
to the list for clarification.

> presentity is changed when dialog optimization is used. I don?t 
> presentities have ?terminated? state. By "terminated" state the 
> presentities? presence documents don?t need to be added into the NOTIFY 

See answer to question 2.