Subject: Re: [MEDIACTRL] [sip-overload] WGLC: draft-ietf-soc-overload-design

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 30 Aug 2010 01:36:07 +0530

Volker,
 
I doubt whether the current draft will serve for all SIP servers. I'm taking the example of B2BUA with media (RTP)topology hiding functionality and there is no DSP, DS0 or DISK resource involved. Here, Server experiences an overload of SIP message not just because of incoming SIP messages but also due to the incoming RTP messages and RTP messages flow varies depend upon the dialog (call) hold time whereas there may not any SIP message when the dialog is established. SIP processor mentioned in the system model of this draft may be shared the physical processor with RTP messages or other protocols messages. We have the problem in incorporating the current SIP overload design in media handling SIP devices.
 
I'm including mediactrl to hear their experience with SIP overload design and mediactrl combined SIP implementation.

Thanks
Partha
 
________________________________

From: Volker Hilt [mailto:[email-masked]]
Sent: Sun 8/29/2010 11:43 PM
To: Parthasarathi R (partr)
Cc: Salvatore Loreto; [email-masked]
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-design

Partha,

the design document discusses problems related to the overload of SIP
messages. Any server that processes SIP messages can experience an
overload of SIP messages. Therefore, the discussions in the draft apply
to all servers that are involved in SIP message processing.

SIP servers that also provide media handling services may need
mechanisms to signal that they are out of trunk lines, DSP processors,
storage capacity for voicmails, etc. These mechanisms will often be
needed at times when the servers can still process SIP messages. These
mechanisms are out of scope for the working group as discussed.

Thanks,

Volker

On 8/29/2010 1:21 PM, Parthasarathi R (partr) wrote:
> Sal/Volker,
> The design document is designed for dedicated SIP signaling servers and
> experiments are done based on the dedicated servers. The same design may
> not scale for SIP server with media handling. As per IETF-78 meeting,
> SIP servers with media handling
> (draft-partha-soc-overload-resource-availability-00,
> draft-jones-sip-overload-sce-00) is outside the scope of this working
> group. I think that it is better to indicate the scope of this overload
> design is for "dedicated SIP servers" only and does not include media
> servers with SIP. Please let me know your opinion on the same.
> Thanks
> Partha
> ------------------------------------------------------------------------
> *From:* [email-masked] on behalf of Salvatore Loreto
> *Sent:* Mon 8/23/2010 4:54 AM
> *To:* [email-masked]
> *Cc:* Volker Hilt
> *Subject:* [sip-overload] WGLC: draft-ietf-soc-overload-design
>
> [as chair]
>
> the draft has been update to address all the concerns/suggestions that
> have been raised during
> the F2F meeting in Maastricht:
>
> http://tools.ietf.org/html/draft-ietf-soc-overload-design-01
>
>
> the chairs believe the document has no remaining open issues, and is
> ready for WG last call evaluation.
>
> Today we are starting a two-weeks working group last call.
> This call end on September 5th.
>
> comments and especially full and deep reviews of the draft are really
> appreciate.
>
>
> cheers
> Sal
>
> --
> Salvatore Loreto
> www.sloreto.com
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: Janet P Gunn <[email-masked]>
Date: Sun, 29 Aug 2010 16:34:01 -0400

I guess the points are:
1- If a SIP actor is experiencing overload (regardless of whether the 
overload is due to "too many SIP messages" or something else entirely) it 
needs to reduce the rate at which SIP messages arrive at the SIP actor 
(the focus of this document).
2- If the overload is largely due to something other than SIP messages, 
then ONLY reducing the arrival of SIP messages may not significantly 
reduce the overload, and you may still have congestion collapse. 
3- For devices which are SIP actors, and also  serve other loads (e.g. 
RTP, database lookup, ISUP gateway), it is to be hoped that there is an 
overload control mechanism  for each type of traffic, and that the 
mechanisms are coordinated in a sensible way (so that no one type of 
traffic is starved out by the others).  But, other than a passing comment, 
that is out of scope for a document on SIP Overload Control.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

From:
Volker Hilt <[email-masked]>
To:
"Parthasarathi R (partr)" <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "Paul Jones \(paulej\)" <[email-masked]>
Date:
08/29/2010 04:16 PM
Subject:
Re: [sip-overload] WGLC: draft-ietf-soc-overload-design

Partha,

the CPU load of a SIP server can increase for many reasons, not only the 
processing of RTP packets. For example, the system might start the daily 
backup of a database, apply patches, run a virus scan or launch another 
application.

If any of these events leads to a shortage of CPU cycles in which the 
SIP server may not be able to process all incoming SIP messages, it 
should use overload control to reduce the number of SIP messages.

Thanks,

Volker

On 8/29/2010 4:06 PM, Parthasarathi R (partr) wrote:
> Volker,
> I doubt whether the current draft will serve for all SIP servers. I'm
> taking the example of B2BUA with media (RTP)topology hiding
> functionality and there is no DSP, DS0 or DISK resource involved. Here,
> Server experiences an overload of SIP message not just because of
> incoming SIP messages but also due to the incoming RTP messages and RTP
> messages flow varies depend upon the dialog (call) hold time whereas
> there may not any SIP message when the dialog is established. SIP
> processor mentioned in the system model of this draft may be shared the
> physical processor with RTP messages or other protocols messages. We
> have the problem in incorporating the current SIP overload design in
> media handling SIP devices.
> I'm including mediactrl to hear their experience with SIP overload
> design and mediactrl combined SIP implementation.
>
> Thanks
> Partha
> *From:* Volker Hilt [mailto:[email-masked]]
> *Sent:* Sun 8/29/2010 11:43 PM
> *To:* Parthasarathi R (partr)
> *Cc:* Salvatore Loreto; [email-masked]
> *Subject:* Re: [sip-overload] WGLC: draft-ietf-soc-overload-design
>
> Partha,
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 30 Aug 2010 11:12:42 +0530

My point is same as Janet's. I wish that SIP overload design document
has to explicitly indicate about congestion collapse in SIP server due
to other loads (like RTP message) is outside the scope of the document.
Without this text in the document, the implementers of SIP servers with
other load handling may be mislead.
 
Thanks
Partha

From: Janet P Gunn [mailto:[email-masked]] 
Sent: Monday, August 30, 2010 2:04 AM
To: Volker Hilt
Cc: [email-masked]; Parthasarathi R (partr); Paul Jones (paulej);
[email-masked]; [email-masked]
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-design

I guess the points are: 
1- If a SIP actor is experiencing overload (regardless of whether the
overload is due to "too many SIP messages" or something else entirely)
it needs to reduce the rate at which SIP messages arrive at the SIP
actor (the focus of this document). 
2- If the overload is largely due to something other than SIP messages,
then ONLY reducing the arrival of SIP messages may not significantly
reduce the overload, and you may still have congestion collapse. 
3- For devices which are SIP actors, and also  serve other loads (e.g.
RTP, database lookup, ISUP gateway), it is to be hoped that there is an
overload control mechanism  for each type of traffic, and that the
mechanisms are coordinated in a sensible way (so that no one type of
traffic is starved out by the others).  But, other than a passing
comment, that is out of scope for a document on SIP Overload Control. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of
e-mail for such purpose. 

From: 	Volker Hilt <[email-masked]> 
To: 	"Parthasarathi R (partr)" <[email-masked]> 
Cc: 	"[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>, "Paul Jones \(paulej\)"
<[email-masked]> 
Date: 	08/29/2010 04:16 PM 
Subject: 	Re: [sip-overload] WGLC: draft-ietf-soc-overload-design

Partha,

Thanks,

Volker

> *From:* Volker Hilt [mailto:[email-masked]
<mailto:[email-masked]> ]
>  > http://tools.ietf.org/html/draft-ietf-soc-overload-design-01
<http://tools.ietf.org/html/draft-ietf-soc-overload-design-01> 
>  > comments and especially full and deep reviews of the draft are
really
<https://www.ietf.org/mailman/listinfo/sip-overload> 
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload
<https://www.ietf.org/mailman/listinfo/sip-overload>

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 30 Aug 2010 07:14:25 -0400

Well, there IS already text in the document,  but it could be made 
stronger.

Janet

From:
"Parthasarathi R (partr)" <[email-masked]>
To:
Janet P Gunn/USA/CSC@CSC, "Volker Hilt" <[email-masked]>
Cc:
<[email-masked]>, "Paul Jones (paulej)" <[email-masked]>, 
<[email-masked]>
Date:
08/30/2010 01:42 AM
Subject:
RE: [sip-overload] WGLC: draft-ietf-soc-overload-design

My point is same as Janet's. I wish that SIP overload design document has 
to explicitly indicate about congestion collapse in SIP server due to 
other loads (like RTP message) is outside the scope of the document. 
Without this text in the document, the implementers of SIP servers with 
other load handling may be mislead.
 
Thanks
Partha

I guess the points are: 

Janet

From: 

Partha,

Thanks,

Volker

---

From: Volker Hilt <[email-masked]>
Date: Sun, 29 Aug 2010 16:16:45 -0400

Partha,

Thanks,

Volker

---

From: Volker Hilt <[email-masked]>
Date: Mon, 30 Aug 2010 10:58:27 -0400

Partha,

if other load causes a congestion collapse on the SIP signaling plane of 
a server, it is within the scope of an overload control algorithm. 
Whenever a SIP server runs out of resources to process incoming SIP 
messages, it needs to take action to make sure it is not encountering a 
SIP congestion collapse.

It may use other mechanisms or intelligent design choices to control the 
load generated by other processes on a SIP server. E.g., it may perform 
access control for admitting audio streams for processing, use overload 
control mechanism for other protocols, give less priority to other 
processes (e.g., a virus scanner), etc.

Thanks,

Volker

On 8/30/2010 1:42 AM, Parthasarathi R (partr) wrote:
> *From:* Janet P Gunn [mailto:[email-masked]]
> *Sent:* Monday, August 30, 2010 2:04 AM
> *To:* Volker Hilt
> *Cc:* [email-masked]; Parthasarathi R (partr); Paul Jones (paulej);
> Cc: 	"[email-masked]" <[email-masked]>, "[email-masked]"

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 31 Aug 2010 07:59:37 +0530

Volker,
 
In case you think that SIP overload control algorithm includes the other loads in the signaling plane then the current algorithms mentioned in the design document is not sufficient. In IETF-78 SoC interim meeting, SIP-overload design experiments slides mentioned that media congestion is not part of the experiment. 
 
SIP is the control protocol for RTP traffic. There is no need of separate overload control for RTP in case SIP overload control algorithm is designed for Media load as well. The access control mentioned by you has to be considered as "local overload control" which is not suffice as per the current SIP overload design as well as in the reality. 
 
Even I discussed about different RTP load in IETF-78 SoC as part of draft-partha-soc-overload-resource-availability-00 presentation. I'll explain again here:
 
B2BUA with address hiding service (SBC), memory requirements vary for different types of call as indicated below
 
SIP Audio (RTP) call - 0.2%
SIP Video (RTP) call - 1%
SIP telepresence (RTP) call - 10%
 
The memory of SIP and RTP shall be shared across. RTP load varies depends upon the negotiated codec during the call. The incoming SIP INVITE message acceptance depends upon the dialog(call)-hold time as well as negotiated codec. There is no relationship between the number of SIP messages and the system load in case of SIP media servers. I'm sure that the above problem is not addressed as part of the current design. Please explain me in case the current algorithms solve the above mentioned problem.
 
I could not visualize that media congestion is not part of SIP overload design (document) till I'm attending IETF-78 interim meeting. Please add the explicit text in the SIP overload design document that Congestion collapse in SIP server due to other load is outside scope of the document. The text will surely help other implementers like me.
 
Thanks
Partha 

From: Volker Hilt [mailto:[email-masked]]
Sent: Mon 8/30/2010 8:28 PM
To: Parthasarathi R (partr)
Cc: Janet P Gunn; [email-masked]; Paul Jones (paulej); [email-masked]
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-design

Partha,

Thanks,

Volker

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Tue, 31 Aug 2010 12:08:44 +0500

SIP + RTP is just one usecase and I don't think it can be easily found it what caused overload very easily in the automata.
Only overload can be detected.

Hence I agree whatever be the cause if the overload exists apply the overload. It doesn't matter what was the reason.

Regards,
Rahul

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tuesday, August 31, 2010 7:59 am
Subject: Re: [MEDIACTRL] [sip-overload] WGLC: draft-ietf-soc-overload-design
To: Volker Hilt <[email-masked]>
Cc: "Paul Kyzivat (pkyzivat)" <[email-masked]>, "Paul Jones (paulej)" <[email-masked]>, [email-masked], [email-masked]

> Volker,
> 
> In case you think that SIP overload control algorithm includes the 
> other loads in the signaling plane then the current algorithms 
> mentioned in the design document is not sufficient. In IETF-78 SoC 
> interim meeting, SIP-overload design experiments slides mentioned 
> that media congestion is not part of the experiment. 
> 
> SIP is the control protocol for RTP traffic. There is no need of 
> separate overload control for RTP in case SIP overload control 
> algorithm is designed for Media load as well. The access control 
> mentioned by you has to be considered as "local overload control" 
> which is not suffice as per the current SIP overload design as 
> well as in the reality. 
> 
> Even I discussed about different RTP load in IETF-78 SoC as part 
> of draft-partha-soc-overload-resource-availability-00 
> presentation. I'll explain again here:
> 
> B2BUA with address hiding service (SBC), memory requirements vary 
> for different types of call as indicated below
> 
> The memory of SIP and RTP shall be shared across. RTP load varies 
> depends upon the negotiated codec during the call. The incoming 
> SIP INVITE message acceptance depends upon the dialog(call)-hold 
> time as well as negotiated codec. There is no relationship between 
> the number of SIP messages and the system load in case of SIP 
> media servers. I'm sure that the above problem is not addressed as 
> part of the current design. Please explain me in case the current 
> algorithms solve the above mentioned problem.
> 
> I could not visualize that media congestion is not part of SIP 
> overload design (document) till I'm attending IETF-78 interim 
> meeting. Please add the explicit text in the SIP overload design 
> document that Congestion collapse in SIP server due to other load 
> is outside scope of the document. The text will surely help other 
> implementers like me.
> 
> Thanks
> Partha 
> Cc: Janet P Gunn; [email-masked]; Paul Jones (paulej); sip-
> [email-masked]: Re: [sip-overload] WGLC: draft-ietf-soc-
> overload-design
> 
> 
> 
> Partha,
> 
> load generated by other processes on a SIP server. E.g., it may 
> performaccess control for admitting audio streams for processing, 
> use overload
> > My point is same as Janet's. I wish that SIP overload design 
> document> has to explicitly indicate about congestion collapse in 
> SIP server due
> > to other loads (like RTP message) is outside the scope of the 
> document.> Without this text in the document, the implementers of 
> SIP servers with
> > *Cc:* [email-masked]; Parthasarathi R (partr); Paul Jones 
> (paulej);> [email-masked]; [email-masked]
> > overload is due to "too many SIP messages" or something else 
> entirely)> it needs to reduce the rate at which SIP messages 
> arrive at the SIP
> > 2- If the overload is largely due to something other than SIP 
> messages,> then ONLY reducing the arrival of SIP messages may not 
> significantly> reduce the overload, and you may still have 
> congestion collapse.
> > 3- For devices which are SIP actors, and also serve other loads 
> (e.g.> RTP, database lookup, ISUP gateway), it is to be hoped that 
> there is an
> > comment, that is out of scope for a document on SIP Overload 
> Control.>
> > Janet
> >
> > Cc:   "[email-masked]" <[email-masked]>, "sip-
> [email-masked]"> <[email-masked]>, "Paul Jones 
> \(paulej\)" <[email-masked]>
> > Subject:      Re: [sip-overload] WGLC: draft-ietf-soc-overload-
> design>
> >
> > backup of a database, apply patches, run a virus scan or launch 
> another> application.
> >
> >  > messages flow varies depend upon the dialog (call) hold time 
> whereas>  > there may not any SIP message when the dialog is 
> established. SIP
> >  > I'm including mediactrl to hear their experience with SIP 
> overload>  > design and mediactrl combined SIP implementation.
> >  >
> >  > Thanks
> >  > Partha
> >  > *Subject:* Re: [sip-overload] WGLC: draft-ietf-soc-overload-
> design>  >
> >  > Partha,
> >  >
> >  > mechanisms to signal that they are out of trunk lines, DSP 
> processors,>  > storage capacity for voicmails, etc. These 
> mechanisms will often be

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 31 Aug 2010 00:04:18 -0400

Personally, I've viewed the work on SOC complementary to what we had also
proposed in the Session Capacity Estimate (SCE) draft.  I agree with Partha
here when he says that the current algorithm is only really focused on the
signaling plane and does not really consider other issues.

The fact is that a device that provides information to a peer suggesting a
reduction in the rate of messages is only looking at the high-level
transaction processing capacity.  One could, in theory, observe resources
and suggest an increase or reduction in the call signaling rate as resources
are reduced.  However, transaction processing capability is one thing, and
available memory, DS0s, DSPs, etc. is something else.

When there is proxy sitting in front of a bank of SBCs, something more is
needed than mere rate control.  The SBC needs to know which SBC likely has
the available resources to handle the call.  One could make this an
elaborate solution wherein the proxy knows tons of information about each
SBC, but the INVITE probably only provides a hint about the needs of the
call and, therefore, is having so much detail will not be very useful.  What
I think it useful, though, is knowing that SBC-1 is telling the proxy that,
given the current load it has, it can likely handle 10 more sessions, and
that SBC-2 is telling the proxy that, given the current load it had, it can
likely handle 100 more sessions.  Combining that SCE approach with a
rate-limiting mechanism provides us with a fairly complete solution.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Parthasarathi R (partr)
Sent: Monday, August 30, 2010 10:30 PM
To: Volker Hilt
Cc: Paul Jones (paulej); [email-masked]; [email-masked]
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-design

Volker,

In case you think that SIP overload control algorithm includes the other
loads in the signaling plane then the current algorithms mentioned in the
design document is not sufficient. In IETF-78 SoC interim meeting,
SIP-overload design experiments slides mentioned that media congestion is
not part of the experiment. 

SIP is the control protocol for RTP traffic. There is no need of separate
overload control for RTP in case SIP overload control algorithm is designed
for Media load as well. The access control mentioned by you has to be
considered as "local overload control" which is not suffice as per the
current SIP overload design as well as in the reality. 

Even I discussed about different RTP load in IETF-78 SoC as part of
draft-partha-soc-overload-resource-availability-00 presentation. I'll
explain again here:

B2BUA with address hiding service (SBC), memory requirements vary for
different types of call as indicated below

The memory of SIP and RTP shall be shared across. RTP load varies depends
upon the negotiated codec during the call. The incoming SIP INVITE message
acceptance depends upon the dialog(call)-hold time as well as negotiated
codec. There is no relationship between the number of SIP messages and the
system load in case of SIP media servers. I'm sure that the above problem is
not addressed as part of the current design. Please explain me in case the
current algorithms solve the above mentioned problem.

I could not visualize that media congestion is not part of SIP overload
design (document) till I'm attending IETF-78 interim meeting. Please add the
explicit text in the SIP overload design document that Congestion collapse
in SIP server due to other load is outside scope of the document. The text
will surely help other implementers like me.

Thanks

Partha 

  _____  

Cc: Janet P Gunn; [email-masked]; Paul Jones (paulej);

Partha,

Thanks,

Volker

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 31 Aug 2010 11:24:54 -0400

Comments on draft-ietf-soc-overload-design-01

Intro, third paragraph says:
“For example, a PSTN gateway that runs
   out of trunk lines but still has plenty of capacity to process SIP
   messages should reject incoming INVITEs using a 488 (Not Acceptable
   Here) response [RFC4412].”

While it is true that 4412 DOES say to use 488 in this case, we have found 
that, in the real world, this can lead to incorrect mapping back to ISUP. 
In at least some contexts, “503 with a Reason header field Q.850 cause 
value of 34 (no circuit available)” may be used instead of 488.  (I 
believe this is covered in a PTSC document.)  So I suggest 

“For example, a PSTN gateway that runs
   out of trunk lines but still has plenty of capacity to process SIP
   messages should reject incoming INVITEs using a response such as 488 
(Not Acceptable
   Here), as described in RFC4412.”

After this paragraph, I would add a new paragraph saying something like:

“There are other failure cases in which a SIP server also serves non-SIP 
traffic (e.g., RTP packets, database queries and updates, event handling) 
which can lead to server overload.  These other loads may, or may not, be 
correlated with the SIP message volume. The server is unable to process 
all SIP requests due to resource constraints, but simply reducing the flow 
of SIP messages may not sufficiently reduce the load to avoid congestion 
collapse.  In this context, it is to be expected that the server has some 
other method of overload control addressing these other sources of load. 
However, the specifics of the overload control for other traffic types, 
and the coordination of the different overload controls, are out of scope 
for this document.” 

This should address Partha’s, and others’ concerns.

Fourth paragraph.

In addition to the other problems with 503 and Retry-After, 503 is used 
for other situations (with or without Retry-After), not just SIP Server 
overload.  A SIP Overload Control process based on 503 would have to 
specify exactly which cause values trigger the Overload Control.

Section 2

Even when SIP messages are not dropped, significant delay can cause 
time-outs which lead to retransmission.  I would change the second 
sentence to 
“When SIP is running over the UDP protocol, it will retransmit messages 
that were dropped or excessively delayed by a SIP server due to overload 
and thereby increase the offered load for the already overloaded server.”

At the end of section 2 you say
  “Another challenge for SIP overload control is that the rate of the
   true traffic source usually cannot be controlled.  Overload is often
   caused by a large number of UAs each of which creates only a single
   message.  These UAs cannot be rate controlled as they only send one
   message.  However, the sum of their traffic can overload a SIP
   server.”

In fact, the various wireless technologies DO have method for controlling 
the load “caused by a large number of UAs each of which creates only a 
single message.”  Some of these are of the form “pick a random number and 
see if it exceeds the threshold you have been given”.

Examples include Access Class Barring, and Access Persistence Mechanism. 
It would be possible to do something similar at the SIP level, though it 
would probably be redundant.

My suggested rewording would be:

“Another challenge for SIP overload control is controlling the rate of the 
true traffic source.  Overload is often caused by a large number of UAs 
each of which creates only a single message.  However, the sum of their 
traffic can overload a SIP server. The overload mechanisms suitable for 
controlling a SIP server (e.g., rate control) may not be effective for 
individual UAs.  In some cases, there are other non-SIP mechanisms for 
limiting the load from the UAs.  These may operate independently from, or 
in conjunction with, the SIP overload mechanisms described here.  In 
either case, they are out of scope for this document.”

Section 4

Your model is built on the premise of a “sending entity” and a “receiving 
entity”.  In the real world, not only is Server A sending SIP messages to 
Server B, but Server B is also sending SIP messages to Server A.

I don’t think you should clutter up your model by trying to address both 
directions at once, but you should state somewhere in the text that you 
have made that simplification/abstraction for ease of comprehension, and 
that any mechanism must work in the context of “SIP messages going both 
ways”.

My suggestion would be to add another sentence after 
“The model in Figure 1 shows a scenario with one sending and one
   receiving entity.  In a more realistic scenario a receiving entity
   will receive traffic from multiple sending entities and vice versa
   (see Section 6).”

My suggestion would be:
“In addition, in a more realistic scenario, SIP messages will be going 
both directions, from B to A as well as A to B.  However, the overload 
control mechanisms in each direction can be considered independently.”

Then, in section 5.1, change 
“Each control loop between two servers is
   completely independent of the control loop between other servers
   further up- or downstream.” 
To
“Each control loop between two servers is
   completely independent of the control loop between other servers
   further up- or downstream, and of the control loop between the two 
servers in the other direction.” 

Section 8, 
second paragraph
After “An
   overload control mechanism should ensure that the delay encountered
   by a SIP message is not increased significantly during periods of
   overload.”
Add
“Significantly increased delay can lead to time-outs, and retransmission 
of SIP messages, making the overload worse.”

“Reactiveness” doesn’t seem the right word to me.  “Responsiveness” sounds 
better to me.

End of section 8
Another important metric is the (cpu) load used by the overload “monitor” 
and “actuator”.

End of section 9
Suggest changing 
“Explicit overload control
   mechanisms can be differentiated based on the type of information
   conveyed in the overload control feedback and whether the control
   function is in the receiving or sending entity (receiver- vs. sender-
   based overload control).” 
To
“Explicit overload control
   mechanisms can be differentiated based on the type of information
   conveyed in the overload control feedback and whether the control
   function is in the receiving or sending entity (receiver- vs. sender-
   based overload control), or both.” 

In 9.2, I think 
“A loss percentage enables a SIP server to ask an upstream neighbor to
   reduce the number of requests it would normally forward to this
   server by a percentage X. For example, a SIP server can ask an
   upstream neighbor to reduce the number of requests this neighbor
   would normally send by 10%.  The upstream neighbor then redirects or
   rejects X percent of the traffic that is destined for this server.”
Should be
“A loss percentage enables a SIP server to ask an upstream neighbor to
   reduce the number of requests it would normally forward to this
   server by a X%. For example, a SIP server can ask an
   upstream neighbor to reduce the number of requests this neighbor
   would normally send by 10%.  The upstream neighbor then redirects or
   rejects 10% of the traffic that is destined for this server.”

End of 9.2
WRT:
“Thus, percentage throttling requires an adjustment of the throttling
   percentage in response to the traffic received and may not always be
   able to prevent a server from encountering brief periods of overload
   in extreme cases.”
This is not unique to percentage throttling.  It is possible in rate based 
and window based methods as well.  In all cases, it is heavily dependent 
on the frequency of updates by the control mechanism.  But that needs to 
be balanced against the load generated by the control mechanism.  I am not 
sure whether it makes sense to say something in each method, or put it up 
front as a general comment.

Sec 9.4
Here again, remember that there are many other things that can generate 
503, with or without Retry-After.

Sec 11
Last paragraph add:
“Conversely, the semantics of any proposed approach should permit a 
variety of different algorithms.”

Nits/wordsmithing
Note at end of section 6, change “different than” to “different from”.

Section 12 first para
Change 
“Overload control can require a SIP server to prioritize requests and
   select requests that need to be rejected or redirected.”
To
“Overload control can require a SIP server to prioritize requests and
   select requests to be rejected or redirected.”

Sec 12
Third para
Change 
“Responses should not be targeted when a SIP server is trying to
   reduce load for a number of reasons.”
To
“For a number of reasons, SIP responses should not be dropped in order to
   reduce SIP processing load”

Janet

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 31 Aug 2010 22:36:44 +0530

Janet,
 
Your New paragraph of text about non-SIP traffic handling in SIP server looks good to me.
 
Thanks
Partha

From: [email-masked] on behalf of Janet P Gunn
Sent: Tue 8/31/2010 8:54 PM
To: [email-masked]; [email-masked]
Subject: Re: [sip-overload] [MEDIACTRL] WGLC: draft-ietf-soc-overload-design

Intro, third paragraph says: 
"For example, a PSTN gateway that runs 
   out of trunk lines but still has plenty of capacity to process SIP 
   messages should reject incoming INVITEs using a 488 (Not Acceptable 
   Here) response [RFC4412]." 

While it is true that 4412 DOES say to use 488 in this case, we have found that, in the real world, this can lead to incorrect mapping back to ISUP.  In at least some contexts, "503 with a Reason header field Q.850 cause value of 34 (no circuit available)" may be used instead of 488.  (I believe this is covered in a PTSC document.)  So I suggest 

"For example, a PSTN gateway that runs 
   out of trunk lines but still has plenty of capacity to process SIP 
   messages should reject incoming INVITEs using a response such as 488 (Not Acceptable 
   Here), as described in RFC4412." 

"There are other failure cases in which a SIP server also serves non-SIP traffic (e.g., RTP packets, database queries and updates, event handling) which can lead to server overload.  These other loads may, or may not, be correlated with the SIP message volume. The server is unable to process all SIP requests due to resource constraints, but simply reducing the flow of SIP messages may not sufficiently reduce the load to avoid congestion collapse.  In this context, it is to be expected that the server has some other method of overload control addressing these other sources of load.  However, the specifics of the overload control for other traffic types, and the coordination of the different overload controls, are out of scope for this document."   

This should address Partha's, and others' concerns. 

Fourth paragraph. 

In addition to the other problems with 503 and Retry-After, 503 is used for other situations (with or without Retry-After), not just SIP Server overload.  A SIP Overload Control process based on 503 would have to specify exactly which cause values trigger the Overload Control. 

Section 2 

Even when SIP messages are not dropped, significant delay can cause time-outs which lead to retransmission.  I would change the second sentence to 
"When SIP is running over the UDP protocol, it will retransmit messages that were dropped or excessively delayed by a SIP server due to overload and thereby increase the offered load for the already overloaded server." 

  "Another challenge for SIP overload control is that the rate of the 
   server." 

In fact, the various wireless technologies DO have method for controlling the load "caused by a large number of UAs each of which creates only a single message."  Some of these are of the form "pick a random number and see if it exceeds the threshold you have been given". 

Examples include Access Class Barring, and Access Persistence Mechanism.  It would be possible to do something similar at the SIP level, though it would probably be redundant. 

"Another challenge for SIP overload control is controlling the rate of the true traffic source.  Overload is often caused by a large number of UAs each of which creates only a single message.  However, the sum of their traffic can overload a SIP server. The overload mechanisms suitable for controlling a SIP server (e.g., rate control) may not be effective for individual UAs.  In some cases, there are other non-SIP mechanisms for limiting the load from the UAs.  These may operate independently from, or in conjunction with, the SIP overload mechanisms described here.  In either case, they are out of scope for this document." 

Section 4 

Your model is built on the premise of a "sending entity" and a "receiving entity".  In the real world, not only is Server A sending SIP messages to Server B, but Server B is also sending SIP messages to Server A. 

I don't think you should clutter up your model by trying to address both directions at once, but you should state somewhere in the text that you have made that simplification/abstraction for ease of comprehension, and that any mechanism must work in the context of "SIP messages going both ways". 

My suggestion would be to add another sentence after 
"The model in Figure 1 shows a scenario with one sending and one 
   receiving entity.  In a more realistic scenario a receiving entity 
   will receive traffic from multiple sending entities and vice versa 
   (see Section 6)." 

My suggestion would be: 
"In addition, in a more realistic scenario, SIP messages will be going both directions, from B to A as well as A to B.  However, the overload control mechanisms in each direction can be considered independently." 

Then, in section 5.1, change 
"Each control loop between two servers is 
   completely independent of the control loop between other servers 
   further up- or downstream."   
To 
"Each control loop between two servers is 
   completely independent of the control loop between other servers 
   further up- or downstream, and of the control loop between the two servers in the other direction." 

Section 8, 
second paragraph 
After "An 
   overload control mechanism should ensure that the delay encountered 
   by a SIP message is not increased significantly during periods of 
   overload." 
Add 
"Significantly increased delay can lead to time-outs, and retransmission of SIP messages, making the overload worse." 

"Reactiveness" doesn't seem the right word to me.  "Responsiveness" sounds better to me. 

End of section 8 
Another important metric is the (cpu) load used by the overload "monitor" and "actuator". 

End of section 9 
Suggest changing 
"Explicit overload control 
   mechanisms can be differentiated based on the type of information 
   conveyed in the overload control feedback and whether the control 
   function is in the receiving or sending entity (receiver- vs. sender- 
   based overload control)." 
To 
"Explicit overload control 
   mechanisms can be differentiated based on the type of information 
   conveyed in the overload control feedback and whether the control 
   function is in the receiving or sending entity (receiver- vs. sender- 
   based overload control), or both." 

In 9.2, I think 
"A loss percentage enables a SIP server to ask an upstream neighbor to 
   reduce the number of requests it would normally forward to this 
   server by a percentage X. For example, a SIP server can ask an 
   upstream neighbor to reduce the number of requests this neighbor 
   would normally send by 10%.  The upstream neighbor then redirects or 
   rejects X percent of the traffic that is destined for this server." 
Should be 
"A loss percentage enables a SIP server to ask an upstream neighbor to 
   reduce the number of requests it would normally forward to this 
   server by a X%. For example, a SIP server can ask an 
   upstream neighbor to reduce the number of requests this neighbor 
   would normally send by 10%.  The upstream neighbor then redirects or 
   rejects 10% of the traffic that is destined for this server." 

End of 9.2 
WRT: 
"Thus, percentage throttling requires an adjustment of the throttling 
   percentage in response to the traffic received and may not always be 
   able to prevent a server from encountering brief periods of overload 
   in extreme cases." 
This is not unique to percentage throttling.  It is possible in rate based and window based methods as well.  In all cases, it is heavily dependent on the frequency of updates by the control mechanism.  But that needs to be balanced against the load generated by the control mechanism.  I am not sure whether it makes sense to say something in each method, or put it up front as a general comment. 

Sec 9.4 
Here again, remember that there are many other things that can generate 503, with or without Retry-After. 

Sec 11 
Last paragraph add: 
"Conversely, the semantics of any proposed approach should permit a variety of different algorithms." 

Nits/wordsmithing 
Note at end of section 6, change "different than" to "different from". 

Section 12 first para 
Change 
"Overload control can require a SIP server to prioritize requests and 
   select requests that need to be rejected or redirected." 
To 
"Overload control can require a SIP server to prioritize requests and 
   select requests to be rejected or redirected." 

Sec 12 
Third para 
Change 
"Responses should not be targeted when a SIP server is trying to 
   reduce load for a number of reasons." 
To 
"For a number of reasons, SIP responses should not be dropped in order to 
   reduce SIP processing load" 

Janet