Subject: RE: [Sipping] updated overload-requirements

From: "Mary Barnes" <[email-masked]>
Date: Wed, 9 Jan 2008 09:35:04 -0600

This email is to announce a two week re-review of the Post-WGLC version
of the Overload Requirements document.  The diff is available at:
http://tools.ietf.org/wg/sipping/draft-ietf-sipping-overload-reqs/draft-
ietf-sipping-overload-reqs-01-from-00.diff.html

The past reviewers (Volker Hilt, Spencer Dawkins, Tolga Asveren) are
especially requested to re-review to ensure that previous comments have
been addressed. 

Please review the changes and post any comments on those changes to the
list on or before January 23rd, 2008.  If you think the doc is "Ready",
please post a comment to the list as well.  

Regards,
Mary.
SIPPING WG co-chair

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, November 17, 2007 12:34 AM
To: IETF Sipping List
Subject: [Sipping] updated overload-requirements

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

_______________________________________________
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

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 9 Jan 2008 19:55:18 -0500

I think that the doc is "Ready".  I look forward to seeing the solution
which satisfies the requirements.

REQ 13 nit: "of of".

REQ 22: Nice goal.  However depending upon how the two devices interact
and are connected, it will likely be easy to deduce which device is
overloaded or temporarily having issues unless able to potentially blame
another device.  Additionally, a 503 is currently the only SIP response
able to trigger target advancing per RFC 3263.  Does REQ 22 preclude
sending a 503 or only preclude sending 503 containing load information
decipherable by non desirable receivers?

> From: Mary Barnes [mailto:[email-masked]] 
> Sent: Wednesday, January 09, 2008 10:35 AM
> To: IETF Sipping List
> Cc: Volker Hilt
> Subject: RE: [Sipping] updated overload-requirements
> 
> This email is to announce a two week re-review of the 
> Post-WGLC version of the Overload Requirements document.  The 
> diff is available at:
> The past reviewers (Volker Hilt, Spencer Dawkins, Tolga 
> Asveren) are especially requested to re-review to ensure that 
> previous comments have been addressed. 
> 
> Please review the changes and post any comments on those 
> changes to the list on or before January 23rd, 2008.  If you 
> think the doc is "Ready", please post a comment to the list as well.  
> 
> Regards,
> Mary.
> SIPPING WG co-chair
>

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 9 Jan 2008 23:29:37 -0500

With the benefit of hindsight from some other work we are doing, I would 
suggest  a minor modification to Req 13.
We are finding that "processing ahead of others" is not always the 
appropriate  way of prioritizing requests with particular values of RPH. 

Such treatments as "not dropping" requests with RPH (when other requests 
are being dropped), or "allowing more retransmissions" for requests  with 
RPH (than for other requests) are  more useful than "processing ahead of 
others" in many situations.

Therefore I would suggest a rewording such as

REQ 13:  The mechanism must not dictate a specific algorithm for
      prioritizing the processing of work within a proxy during times of
      overload.  It must permit a proxy to prioritize requests based on
      any local policy, so that certain ones (such as a call for
      emergency services or a call with a specific value of the
      Resource-Priority header field [RFC4412]) are given preferential
      treatment,such as not being dropped, being given additional 
      retransmission, or being processed ahead of others.

     Thanks,

Janet

---

From: "Moran, Timothy L." <[email-masked]>
Date: Thu, 10 Jan 2008 07:43:56 -0500

Page 10, Sec 4.4., Par 1: This paragraph suggests that unavailability of
server dependant resources (downstream switches in this case) is not a
valid use of a 503 Service Unavailable response. However, a dependant
resource such as a database (cited elsewhere in the draft) is valid.
>From an upstream perspective, does it matter?

Nits/Questions (minor stuff)
Nit: Pg 1, Abstract, Clarify "it" in the following: "... which tells an
upstream element that it is overloaded". Processors/processes get
overloaded but not the protocol itself.

Q: Pg 7, Par2, "... four SIP transactions", Is this: C<->P1, P1<->S1,
P1<->S2, and P1<->S3?
Q: Pg 7, Par2, "one request ... and 2 responses" and also "... 3
requests and 4 responses" Is the extra response the one from P1 to the
client?

BR,
Tim M.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mary Barnes
Sent: Wednesday, January 09, 2008 10:35 AM
To: IETF Sipping List
Cc: Volker Hilt
Subject: RE: [Sipping] updated overload-requirements

Regards,
Mary.
SIPPING WG co-chair

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Saturday, November 17, 2007 12:34 AM
To: IETF Sipping List
Subject: [Sipping] updated overload-requirements

Other Changes:

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Jan 2008 12:41:42 -0500

> which satisfies the requirements.

Indeed, so do I....

> REQ 13 nit: "of of".

fixed.

> decipherable by non desirable receivers?

I think we can decide downstream on this, its really a protocol 
question. THe intent of the requirement is really that, you don't have 
to use this new mechanism if you don't want, and so you won't get the 
benefits of it. I tend to think this really means, don't send load 
information.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Jan 2008 12:45:06 -0500

Your suggested rewording is fine, I have incorporated.

-Jonathan R.

Janet P Gunn wrote:
> are being dropped), or "allowing more retransmissions" for requests 
>  with RPH (than for other requests) are  more useful than "processing 
> ahead of others" in many situations.
> 
> ------------------------------------------------------------------------
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Jan 2008 14:58:09 -0500

>>From an upstream perspective, does it matter?

This paragraph is not meant to suggest that; difficulties accessing 
server dependent resources IS a cause for overload and is actually 
listed earlier on as such. In this particular case, the problem is that 
the error is not in a server dependent resource, but a downstream 
resource. THis downstream resource might not be used at all for the next 
call; the call might be routed differently.

I added the following to this paragraph:

All subsequent requests might succeed if they take
a different route in the PSTN.

fixed.

> Q: Pg 7, Par2, "... four SIP transactions", Is this: C<->P1, P1<->S1,

yes. I added this.

> requests and 4 responses" Is the extra response the one from P1 to the

yes. Its not an extra response, so much as I'm counting the network 
generated traffic. The initial request is genreated by the client, not 
the servers.

I've clarified by listing what the two responses are in the first case.

Thanks,
Jonathan R.