Subject: [Sipping] Further Information from the sipping "Overload Design Team Status" needed

From: "Moran, Timothy L." <[email-masked]>
Date: Fri, 21 Dec 2007 14:33:38 -0500

Greetings,

I have been out of the IETF loop for a few years - so please bear with
me.

Draft "Requirements for Management of Overload in the Session
Initiation" discusses the need for a SIP overload control mechanism due
to (it would seem) limitations of the 503 "Service Unavailable"
response. Drafts from hilt and chadli are responses to the requirements
draft. However, the presentation "Overload Design Team Status" provides
simulation results of using different overload algorithms to dictate
when a 503 response with the Retry-After is sent.

Questions:
1.	Is there backup text to the Overload Team's presentation?
2.	Is the 503 with Retry-After an option or has it been truly
eliminated? If so, why is the team evaluation algorithms for sending the
503 ???
3.	It would appear (e.g. draft-hilt sections 3.7) that a feedback
mechanism is needed to convey overload from a receiving SIP entity to a
sending SIP entity. Two proposals are a SIP response header and a Notify
(in response to a subscription). How (logically) different are these
mechanisms from a 503? Having asked this, I seem to recall that a  503
response should not be relayed by a proxy for fear of misinterpretation
of which entity is overloaded. Is this a SIP design issue or an
implementation issue? That is, what's so unique about a 503 response vs.
other responses???
4.	Finally, for an RPH labeled request - what assurance is there
that the overloaded server can process enough of the message to read the
RPH field and honor the priority? None???

BR,
Tim M.

_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Fri, 21 Dec 2007 15:15:30 -0600

At 01:33 PM 12/21/2007, Moran, Timothy L. wrote:
>4.     Finally, for an RPH labeled request – 
>what assurance is there that the overloaded 
>server can process enough of the message to read 
>the RPH field and honor the priority? None???

yeah -- this thought has been in the back of my 
mind for some time, knowing I haven't been paying 
any attention to it -- but I don't think I can 
push it off anymore.  Whatever we specify for 
overload ought to account for networks/domains 
that do choose to implement RP (aka RFC 4412) as 
a means of ensuring higher precedence SIP 
signaling messages are processed before lower ones are.

James

---

From: Janet P Gunn <[email-masked]>
Date: Sat, 22 Dec 2007 20:03:35 -0500

There are likely to be multiple levels of overload control.

It is probably inevitable that some levels of overload control will 
discard the messages or packets before  parsing the message sufficiently 
to determine whether or not it contains RPH.

But it is also quite possible that some level of overload control will 
take place after the SIP message has been parsed- e.g. to drop initial 
INVITES in preference to messages associated with calls already in 
process.  At that point in the process, preference can be given to 
messages with particular RPH namespace and priority.

Janet