Subject: [Simple] Suggested next actions with draft-ietf-simple-interdomain-scaling-analysis

From: Avshalom Houri <[email-masked]>
Date: Mon, 23 Nov 2009 21:44:27 +0200

This did not get much attention when it was sent before the IETF.

We really need some input from actual deployments of SIMPLE regarding the
following in order to be able to address the IESG comment in a new
revision of this draft:

- Message sizes.

- Different refresh (re-subscribe) rates used and when they are used.

- Presence document data sizes

- Geolocation presence document data sizes.

- Size of data per subscription that the presence server needs to
  allocate

- Any other data that we can get from the field.

Any other comments are also welcome.

Thanks
--Avshalom

__________________

The IESG had substantial comments on the draft:
https://datatracker.ietf.org/idtracker/draft-ietf-simple-interdomain-scaling-analysis/comment/102863/

The following is a plan for revising the draft to address these comments.
The plan is based on discussions with Ben, Cullen and Robert.

One very important thing that will help us a lot in this work is getting
real data from actual deployments of SIMPLE regarding the following:

- Message sizes.

- Different refresh (re-subscribe) rates used and when they are used.

- Presence document data sizes

- Geolocation presence document data sizes.

- Size of data per subscription that the presence server needs to
  allocate

- Any other data that we can get from the field.

**** Any numbers here will be greatly appreciated and will help a lot
in creating the new revision of the document ****

Note that the above numbers are more SIP specific and we need to get 
them from actual SIP deployments. They are different from the 
general constants of buddy list size, rate of state changes per day etc.
which are more usage numbers.

General Changes:
----------------

* Remove subjective language as much as possible

* The document should not be written as a protocol comparison document
but as a document that provides input that will help deployment 
considerations for SIMPLE and directions for optimizations.

* Clarify the assumptions behind the chosen input values.

* Discuss elasticity of inputs and which inputs have more effect.

* Make it clear that we are talking only about inter-domain 
traffic.

* The document will have to go through the working group last call 
again.

Changes in Phase I
-------------------

* Separate the scenarios into enterprise and consumer related 
scenarios. Number as the time that a user will be logged in which is
reasonable to be 8 in an enterprise will be different for a consumer
network. The rate of status changes will be different also.

* Since we can not mention explicit numbers from actual deployments, 
we should say e.g. "hypothetical consumer service"...

* Add per active (logged in) user calculations

* Section 2.2: The 2000/4000 difference in login/logouts is probably 
a typo mistake that needs to be clarified. It does NOT affect the 
calculations.

* Add a section describing changes with different constants. Provide 
several points on the possible reasonable values.

* Add geolocation information as part of the model.

* Provide different calculations for the refresh time. The 3600 
seconds from the RFC is not the number that is usually used.
Provide both extremes.

* Message sizes: Need to do sanity check of messages. Talk to people 
that may have these numbers.

* Section 2.10 - Change to 48 changes per day from 24. It was done 
in order to show that the optimized protocol can be better even with
doubling the number notifications. This is probably confusing and need to
be fixed.

* Sizes for state calculations. Need to revisit the numbers that are 
used. Get actual numbers from the same sources that we will get message
sizes.

* Talk about the limits that are imposed by privacy constraints on 
the way that SIMPLE works and possible optimizations.

* Provide numbers for when SIGCOMP compression is used.

Phase II
--------

* Revisit Processing Complexities, Current Optimizations, Summary and
Conclusions sections after doing the changes in the main part of the 
document.

Thanks
--Avshalom