Subject: Re: [Simple] Comments on interdomain scaling analysis

From: Avshalom Houri <[email-masked]>
Date: Wed, 4 Apr 2007 12:38:50 +0300

Ben,

Thanks a lot for your comments. I encourage others to review
the scaling analysis part of the document so we will be able to
progress to WGLC as soon as possible.

Started to reply to your email last Thu (22nd March) when my
computer crashed. It took more a week to recover...

--Avshalom

Ben Campbell <[email-masked]> wrote on 22/03/2007 11:42:02:

> Hi,
> 
> Here are some comments on draft-ietf-simple-interdomain-scaling- 
> analysis-00.txt.
> 
> One big concern is this draft claims to be standards track. That 
> seems incorrect. The only milestone I see in the new charter that 
> this could fall under is for an informational RFC.
> 
> I have a few nits on the model for the non optimized model, and a 
> concern about the approach for the optimized models.

It is a typo. It should infromational.

> 
> First the approach concern:
> 
> I'm starting to be uncomfortable with the idea of this draft talking 
> about optimizations at all. We're doing sort of a backwards strawman 
> here--putting up a potential optimization that has not been thought 
> through by the work group as a whole, then assigning a value to it 
> through optimization. This risks sending us down some false trails, 
> or going down rat-holes arguing about the optimizations in the draft. 
> it also risks getting us prematurely attached to a particular 
> optimization, which could later turn out to be technically unfeasible.
> 
> Bottom line is, I think discussion of particular optimizations should 
> be treated in a separate document than the analysis of the status quo.
> 
> Analysis model for non-optimized SIMPLE:
> 
> I think there are at least 2 errors and two areas that are likely to 
> be misinterpreted.

As we said in the meeting we will separae the current document into
3 docs:
- Scaling analysis - WG doc - informational
- Requirements doc - Personal - SIPPING
- Suggestions doc - Personal - More as a place holder until we will
progress with the requirements work.
 
> 
> Errors:
> 
> 1) I think we have one too many rounds of subscription refreshes in 
> the 8 hour period.  Looking at a timeline, there should be an initial 
> subscription at t=0, one refresh at each of t=1 through t=7, and one 
> tear-down at t=8. That's 1 initiation, 1 teardown, and _7_ refreshes, 
> not 8.

Agree. It's like how many cuts you need to cut a bread to get N slices.
Will fix.

> 
> 2) The bandwidth calculation multiplies the number of messages times 
> a size factor that includes an assumed request and response for each. 
> But we already accounted for responses in the previous calculations 
> on which this depends. Doing it here again causes a false doubling. 
> (Not really quite double, since we assume a different size for 
> responses than requests.)
> 
Will fix.

> Areas that should be clarified:
> 
> 1) There are several lines labeled in the form of  <Method>/200 OK. 
> That makes me think we are counting transactions. But in fact, we are 
> counting messages. I think messages are the appropriate choice for 
> this analysis, so it might make more sense to have a line item for 
> each request type and a separate line for the associated responses. A 
> misinterpretation here will make people think the numbers are twice 
> as bad as they really are.
>
Yes. I need to work on the way that the calculations are presented to make
them clearer.

> 2) The population is listed as 20,000. But there is a buried 
> assumption in the calculation that one domain has 20K people, and the 
> peer domain also has 20K people, and the interdomain link is carrying 
> traffic from all 40K people. People are likely to misinterpret this 
> so that the numbers appear twice as bad as they really are. I suggest 
> just acknowledging the population is 40K and removing the multiplier.
> 
> Keep in mind that if people fall into _both_ of this traps, they will 
> misinterpret the numbers by a factor of 4.
Will fix.
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: David Viamonte <[email-masked]>
Date: Wed, 04 Apr 2007 13:10:07 +0200

Hi,

Following your
encourage to review, I provide some feedback I've gathered in the last
weeks. It
is in line with previous comments posted in the past, so will
appreciate if you
can share your point of view on them.

Extracted
from section 7.2 in the I-D:

o Content Indirection [7] enables sending only the URI of
the presence document to the watcher thus offloading the presence
server from sending the presence document to the watcher. This
optimization may be useful in some cases but in reality it may have
several drawbacks:

1.
Due to partial/privacy/filtering and other functionalities, it will be
relatively a rare case where many watchers will get exactly the same
presence document.

2.
There should be a mechanism that will enable removing the content from
the content server at the appropriate time. Defining the appropriate
time is far from trivial since the removal should be synchronized with
all the watcher that need to get the content.

Two comments on the above statement:

1. "Partial
/ privacy / filtering"

Privacy
policies are -in the current model- handled by the PS. So I agree that
due to
privacy reasons different Presence docs may be shared between the PS
and the RLS
through the interdomain link.

However,
partial and filtering mechanisms could be fully handled in the "watcher
domain" (e.g.: section 4.5 of RFC 4662), so this does
not justify the creation of new Presence documents
between the PS and the RLS (documents can be created in the "watcher
domain" and delivered differently to each Watcher; thus it does not
constitute an "interdomain" issue).

Now, if we
consider only Privacy filtering and think about "common sense"
implementations, let us consider a Presentity that has W subscribed
Watchers.
In such case, it seems reasonable that, through Privacy, the Presentity
may
have P "privacy profiles". For large W, it seems unrealistic to think
that the Presentity will have exactly P=W "privacy profiles" (NOTE). If
you
agree with this comment, then the actual Presence document may only
need to be
sent (approximately) W/P times, instead of W times. The rest of times
(up to W)
the RLS can reuse the information already downloaded from the content
server. For
example, for W=25 subscribed watchers, and P=5 profiles, the Presence
document
needs to be uploaded 5 times to the content server, but then the
remaining 20
times the RLS can reuse the cached document directly, without having to
download it again. Observe that the W/P optimization applies to each
and every NOTIFY message sent by the PS, so it may end-up representing
a meaningful improvement.

(NOTE) Having a
tailor-made Presence privacy setting for each Watcher would be too
complex, technically challenging and unpractical for the Presentity, as
W grows.

2. Regarding
the mechanism to remove the content, I don't really see any big issue
not
already covered by the Content Indirection RFC and the existing
Subscribe/Notify
framework. Observe that content is kept in synch via NOTIFY and Etag
values, so
RLS's can be certain that information is up-to-date, regardless of
having
received it directly or via Indirection.

I don't
want to complicate things further and include more calculations in the
draft. However, I think the current way Content Indirection is
presented is too
pessimistic. I reckon it does not reduce the number of dialogs, but it
is fair
to acknowledge it can reduce the amount of info exchanged in the
interdomain
link, and it can be quite interesting in some cases. Further, the
currently stated drawbacks, IMMO are not fully justified, as I explain
above.

Regarding
some proposed "potential new optimizations", a very brief comment,
since I understand these will probably go into another RFC and the
current one
be dedicated only to analysis of the current situation (please, correct
if this assumption is not valid):

- The
"many-to-many" subscription list concept outlined in the doc (section
7.2) seems to be an interesting idea, with a lot of technical
challenges to be
thought of. So fully agree with evaluating it separately.

- The
"consolidated subscription" concept may imply sharing of privacy
documents between the PS and the RLS. This idea poses new
challenges in terms of: a) is the full privacy document shared accorss
domains
or: b) only the sections relevant for a given domain?

If a) applies this seems to be an important privacy issue.

If b) applies (i.e.: only the privacy settings
relevant
for an RLS according to the users it serves), then:

b.1) a mechanism to construct "partial" privacy documents
should be developed (probably this is trivial but should be described
somewhere?)

b.2) how to manage "black-lists" thatcontain TEL URL addresses?
Should the PS ENUM all TEL URL's to determine the SIPv domain they
belong to, in order to share the document? This might represent a new
architectural issue.

b.3) a mechanism to keep the
distributed document in synch across all trusted domains must be
designed.

b.4) I am not sure if policies and existing
regulation would easily allow worldwide sharing –even between trusted
domains– of
a "privacy" document that "belongs" to a served user, and
is directly managed by the user (via XCAP). This is already outlined in
section 7.2.

Conclusion
(just joining what other list members have indicated): moving away from
the RLS-PS challenges, will probably lead into having to carefully
design this
mechanism, which –after careful analysis– may pose additional technical
challenges that have not been though of yet. Hence, it may be
too optimistic to calculate any numbers assuming that some proposed
estimations will effectively be implemented, since new challenges may
arise when carefully designing those optimizations.

Hope this
helps. Please let me know your opinions about these comments.

Kind
Regards,

David

Avshalom Houri escribió:

Ben,

Thanks a lot for your comments. I
encourage
others to review

the scaling analysis part of the
document
so we will be able to

progress to WGLC as soon as
possible.

Started to reply to your email last
Thu (22nd March) when my

computer crashed. It took more a
week
to recover...

--Avshalom

Ben Campbell <[email-masked]> wrote on

> be misinterpreted.

As we said in the meeting we will separae the current
document into

3 docs:

- Suggestions doc - Personal - More as a place holder
until we will

> not 8.

Agree. It's like how many cuts you need to cut a bread
to get N slices.

Will fix.

Will fix.

> 1) There are several lines labeled in the form of
<Method>/200
OK.

> each request type and a separate line for the associated
responses.
A

Yes. I need to work on the way that the calculations
are presented to make

them clearer.

Will fix.