Subject: [Sipping] updated overload-requirements

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2007 01:33:54 -0500

I've (finally) submitted an update to the overload requirements draft 
based on comments made during WGLC. The draft is available here:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-overload-reqs-01.txt

I'd like to highlight that I've removed the simulation model from this 
document. The reason is the following. Both Mary Barnes and Volker Hilt 
commented during WGLC that the model should be aligned with the model 
used by the design team. However, that model has been a moving target. 
It evolves as folks code it up and run simulations. We find holes in the 
model or questions that get discussed. Furthermore, it seemed that we'd 
need several models before we were done, focusing initially on the most 
simple models and then adding more complex ones later. We have even 
found it difficult to enumerate all of the details that in fact 
constitute the model; differences in simulation results have been the 
result of differing assumptions that took some time to ascertain.

The reasons for including the model were:

* Allow non-SIP experts to assist in understanding the problem and solution
     Request from TSVWG last two meetings
* Allow SIP WG to have a benchmark for evaluating alternative solutions
* Allow SIPPING/SIP WG to have a model for understanding the problem

These are all good goals but don't require the model to be here, in the 
overload requirements document itself. Indeed, it seems much better 
suited to place the model in a document which reports the actual 
simulation results along with it, which we agreed later (after the model 
had been added to the document) would be a good info document to get out 
of the design team when finished.

Other Changes:

* Added the following two new requirements:

<t hangText="REQ 22:"> It must be possible to disable the reporting of
load information towards upstream targets based on the identity of
those targets. This allows a domain administrator who considers the
load of their elements to be sensitive information, to restrict access
to that information. Of course, in such cases, there is no expectation
that the overload mechanism itself will help prevent overload from
that upstream target.
</t>

<t hangText="REQ 23:"> It must be possible for the overload
mechanism to work in cases where there is a load balancer in front
of a farm of proxies.
</t>

* clarified that overload is related to goodput, and described the way
   in which external resources (DNS, databases) impact the system

* discussed the implications of TCP vs. UDP and clarified that the
   retransmit problems are specific to UDP

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

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