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

[Avshalom Houri <AVSHALOM at il.ibm.com>]

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