Re: [Sipping] FW:WGLC Review: draft-ietf-sipping-presence-scaling-requirements-01.txt

["Jean-Francois Mule" <[e-mail]>]

Hi,

On Friday, September 19, 2008 3:26 AM, Gonzalo wrote:
> the authors are already working on the comments received from Vijay
> and
> Hisham. In any case, per my email below, we would like to get an
> additional reviewer for this draft. Any volunteers?

   Find below a review of
   draft-ietf-sipping-presence-scaling-requirements-01.

   The companion scaling analysis document is very informative and
   captures many things that folks see as scaling issues.  As I wrote
   below, it may be good to just outline these issues or shortcomings
   clearly in the introduction.

   It is difficult to write requirement documents and what I've
   focused on during my review is whether a solution designer can go
   back to the document and say: have I met this? what does this mean
   for my solution?

   Disclaimer: I've not followed the list with details on this and I'm
   not building or working with users/operators of such large systems.
   If some of these comments have been discussed on the list or are
   off-track, fine with me, just ignore.

Jean-Francois.
[e-mail]

--- page 3, Intro
  | These optimizations should reduce the traffic in
  | interdomain presence subscriptions.  The requirements
  | are based on a separate scaling analysis document
  | [I-D.ietf-simple-interdomain-scaling-analysis].

This text begs the question of what "traffic" reduction is this about?
reduce the amount/size of traffic as in bandwidth?  or the amount of
messages? the amount of small message? what about memory footprint and
the CPU load as this was a goal of the quoted analysis document?

It would be good to have a more precise introduction.  Based on the
content, and the scaling analysis, something like this would seem to
fit:
	- the requirements described in this document should lead to
	  protocol optimizations that reduce the amount of bandwidth
          exchanged between presence systems, both in terms of the
          number of the messages and their sizes (bytes on the wire).
          It is also a goal that the management of steady states by
          presence servers implementing these optimizations should be
          significantly improved.


It would be good to also have more information in the introduction on
the scaling analysis, and one or two examples.  For example:
   "based on a scaling analysis of the ... of presence systems,
especially for the amount of messages required during busy hours of
presence systems of ... users, the following has been document:
	o the bandwidth required to update ... can reach x GB.
	o the amount requests per second typically reach ...
	o steady states...


--- page 3, "Suggested" requirements
I'd remove "suggested" in the title: when this document becomes RFC,
those are no longer suggested I think.  May be "proposed"?
Also, the next sentence implies an "initial" set of requirements: if
this document is ready for publication, this is the set for now so I
would again make it more assertive:
   This section lists requirements for a solution that will optimize
   the interdomain presence traffic.

--- page 3, section 3.1
| o  REQ-001: The solution SHOULD NOT hinder the ability of existing
|    SIMPLE clients and/or servers from peering with a domain or
|    client implementing the solution.  No changes may be required of
|    existing servers to interoperate.

   I read this as: if a new solution is defined that optimizes things,
   the SIMPLE entities supporting this new solution SHOULD also
   interoperate with existing versions of the SIMPLE/SIP
   implementations.
   So, in a way, are you saying?
	- the solution should not deprecate existing protocol
	  mechanisms defined in SIMPLE
	- the solution should define new extension mechanisms that
	  would allow SIMPLE entities to improve performance
   It may be worthwhile spelling this out more clearly so that folks
   designing the solution can go back and say without a doubt whether
   they met the requirement.


--- page 3, section 3.2
   o  REQ-004: The solution SHOULD NOT limit the ability for
      presentities to present different views of presence to different
      watchers.
   o  REQ-005: The solution SHOULD NOT restrict the ability of a
      presentity to obtain its list of watchers.
   o  REQ-006: The solution MUST NOT create any new or make worse any
      existing privacy holes.
 
These 3 requirements could benefit from being turn into positive
requirements with more precision.  

REQ-004: I'm not quite sure what you are driving to:
Is it that
  - the solution should continue to allow presentities to provide
    different views of presence to different watchers 
    (I thought this was covered in the backward compatibility
     requirement), or,
  - the new solution must provide an enhanced mechanism for view
    sharing but that this new mechanism must still allow different
    views for different watchers?

REQ-005 has the same ambiguity: either it is covered by the backward
compatibility case (and you can put this sentence as an example under
REQ-001 I think, or you mean something like this:
  - The solution must allow a presentity to obtain its list of watchers

I guess what I'm confused about is to see where are the new
requirements you're imposing on the solution vs. keep what is already
possible in simple.


--- page 4
REQ-006: this is vague.
Are there any high-level requirements that you could derive from the
view sharing draft and its ACLs that would give solution designed more
information on what security properties to preserve?
If the presence data model is changed, any pointer to another document
that contains some privacy or security considerations?
==> I think the goal of such a requirement is to list a bunch of
things that the solution designer checks afterwards.


--- page 4, section 3.3
| o  REQ-008: The solution SHOULD NOT require significantly more
|    state in order to implement the solution.
The sentence needs to say "more state than ___" and you should
consider removing "in order to implement the solution".

| o  REQ-009: It MUST be able to scale to tens of millions of
|    concurrent users in each domain and in each peer domain.
"It" points to systems here I think when the previous sentences are
using "the solution". Consider wordsmithing: "The solution MUST allow
presence systems to scale..." 

REQ-011: consider rewording to:
   o  REQ-011: Protocol changes MUST NOT prohibit optimizations in
      deployment models where there is a high level of cross
      subscriptions between the domains.

--- page 4, section 3.4
| o  REQ-013: The solution SHOULD allow for arbitrary federation
|    topologies including direct peering and intermediary routing.

s/direct peering and intermediary routing/ direct and indirect peering
per speermint terminology, I believe you mean "intermediary routing"
as having a SIP service provider through which messages would transit
between two peers.


--- page 4, section 4
This whole section would benefit from a first paragraph highlighting
the areas to consider for optimization.  You have a succession of
paragraphs that cover various dimensions (taking scaling requirements
into consideration, server-to-server vs. client-to-server protocol
requiremetns, transport protocol considerations and TCP-only use, etc.
One or two sentences introducing the various dimensions to look at
would be helpful.

--- page 5, paragraph 1
nit picking the sentence that starts with however, consider changing
to:
However, it is apparent that additional protocol optimizations are
possible and further work is needed in the IETF in order to provide
better scalability of large presence systems.


--- page 5, paragraph 2
I think most of this paragraph must be deleted from the RFC-to-be.
This is ok in a draft and has been well taken in sipping, but this has
got to go:
  "The IETF sometimes does not give the right priority
   to actual deployments when designing a protocol but in this case it
   seems that if we do not think about scalability with the protocol
   design it will be very hard to scale." 
Check:
http://www.ietf.org/internet-drafts/draft-iab-protocol-success-04.txt

--- page 5, other paragraphs
There are various nits that should be fixed; including a few here but
this is not exhaustive:

s/(e.g. do not use unreliable protocol as UDP but only TCP)/(for
example, do not use unreliable protocol like UDP but rely on TCP)


s/When a server is connecting to another server using current
protocol,/When a presence server connects to another server using the
current SIP/SIMPLE protocol [xxx]

s/Another issue that is more concerning protocol design is/Another
issue related to protool design is/

s/notifies/notifications



--- page 5
Is it necessary to reference individual drafts like
I-D.houri-simple-interdomain-scaling-optimizations when the authors
list has intersections?  
It might be prefereable to summarize the key points in one paragraph
and not carry this I-D dependency.


--- IANA
see http://tools.ietf.org/html/rfc5226#section-6.1

--- check Idnits prior to submitting next rev

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP