Subject: [sip-overload] SIP overload control draft (was: draft-hilt-sipping-overload)

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jun 2010 14:05:17 -0500

Folks: Now that the SOC WG has been established,
draft-hilt-sipping-overload has been re-named
draft-gurbani-soc-overload-control and submitted to the SOC
archives as an individual submission (please see
http://www.ietf.org/id/draft-gurbani-soc-overload-control-00.txt).

I will serve as the editor of the new draft.

This version of the draft contains the list feedback
that occurred on the list from Timothy Moran [1],
Tolga Asveren [2], Geoff Hunt [3] and R. Parthasarathi [4].
I will individually respond to the messages from Moran et al.
later this week, but in the meantime, please do take a look
at the latest version.

Diffs from draft-hilt-sipping-overload-08 are at:

http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-hilt-sipping-overload-08.txt&url2=http://www.ietf.org/id/draft-gurbani-soc-overload-control-00.txt

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00068.html
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00076.html
[3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00079.html
[4] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00113.html

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Padma Valluri <[email-masked]>
Date: Mon, 14 Jun 2010 18:06:35 -0400

From Section 3.6.  Self-Limiting : The SIP server SHOULD occasionally forward a single request to probe if the downstream neighbor is alive.  Once a SIP server has successfully transmitted a request to the downstream neighbor, it can resume normal transmission of requests.

Since there was a discussion about using Options ping mechanism for checking the neighbor's status, would this be the right place to add something specific to that effect and use the existing mechanism to advantage?

From Section 3.5.  Using the 'oc' Parameter Value : The SIP server SHOULD use the following algorithm to determine if it can forward the request.  The SIP server draws a random number between 1 and 100 for the current request.  If the random number is less than or equal to the 'oc' parameter value, the request is not forwarded.  Otherwise, the request is forwarded.

How is this ensuring that the traffic is reduced by oc% towards that SIP server? Am I reading this wrong?

thanks,

Padma.

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.

[email-masked] wrote: -----

To: [email-masked]
From: "Vijay K. Gurbani" <[email-masked]>
Sent by: [email-masked]
Date: 06/14/2010 03:05PM
cc: Volker Hilt <[email-masked]>, Henning Schulzrinne <[email-masked]>
Subject: [sip-overload] SIP overload control draft (was: draft-hilt-sipping-overload)

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jun 2010 17:47:42 -0500

On 06/14/2010 05:06 PM, Padma Valluri wrote:
> From Section 3.6.  Self-Limiting : The SIP server SHOULD occasionally
> forward a single request to probe if the downstream neighbor is alive.
> Once a SIP server has successfully transmitted a request to the
> downstream neighbor, it can resume normal transmission of requests.
>
> Since there was a discussion about using Options ping mechanism for
> checking the neighbor's status, would this be the right place to add
> something specific to that effect and use the existing mechanism to
> advantage?

Padma: The Options ping mechanism will in all probability not
work in any authoritative fashion.  First of all, if the SIP server
is a proxy, it cannot asynchronously create its own OPTIONS
request to send it downstream.  Second, even if the SIP server is
an endpoint and creates an OPTIONS request, there is no guarantee
that the request will be routed to the same downstream server
that experienced congestion.

I think the best we can do is simply to state that a SIP server
periodically send a request to the downstream server to see if
responds.  Some production SIP servers that I am aware of blacklist
a downstream SIP entity if a transport error occurs.  This black-
list lasts for some time (depends on local policy).  Once the
blacklist time expires, the SIP servers continue to send requests
to the downstream SIP entity.  I think we should stay away from
specifying the time duration for the blacklist period.

>  From Section 3.5. Using the 'oc' Parameter Value : The SIP server
> SHOULD use the following algorithm to determine if it can forward the
> request. The SIP server draws a random number between 1 and 100 for the
> current request. If the random number is less than or equal to the 'oc'
> parameter value, the request is not forwarded. Otherwise, the request is
> forwarded.
>

Are you concerned about the properties of PRNGs?  Or am I missing
something in your query?

Thanks,

- vijay

---

From: Padma Valluri <[email-masked]>
Date: Tue, 15 Jun 2010 10:33:54 -0400

Please see in-line.

thanks, Padma.

-----"Vijay K. Gurbani" <[email-masked]> wrote: -----

To: Padma Valluri/USA/CSC@CSC
From: "Vijay K. Gurbani" <[email-masked]>
Date: 06/14/2010 06:47PM
cc: [email-masked], Volker Hilt <[email-masked]>, Henning Schulzrinne <[email-masked]>
Subject: Re: [sip-overload] SIP overload control draft

[PV] If you are sending the request to that server why wouldn't it be routed?

[PV] This might still send new requests to the overloaded server.

[PV] If a Sip server receives an oc=25 from its congested neighbor, the requests going to that neighbor need to be reduced by that amount according to the draft text. But if the decision is made by a random number generation (random number <= 25, don't forward the request, random number > 25, send the request) will not ensure that the load towards the congested neighbor is infact reduced by 25%, right?

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Jun 2010 15:10:47 -0500

Hello Padma: Thanks for your comments; please see inline.

>     [PV] If you are sending the request to that server why wouldn't it

The request will be routed, to be sure; all I am saying is that it is
not guaranteed that the request will hit the same server.  As to why
this may be the case, the causes are many.  RFC3263 resolution for
the same URI may pick a different server if many are available, or
some proxy may have user-specific scripts that affect routing, or
some providers may have routing policies in place (time of day,
bandwidth sensitive, etc.) that affect routing.

>     [PV] This might still send new requests to the overloaded server.

Sure, but by the time the request hits the server again, it may not be
overloaded.  If it still is overloaded and refuses to respond, it will
continue to be avoided.

>     [PV] If a Sip server receives an oc=25 from its congested neighbor,
>     the requests going to that neighbor need to be reduced by that
>     amount according to the draft text. But if the decision is made by a
>     random number generation (random number <= 25, don't forward the
>     request, random number > 25, send the request) will not ensure that
>     the load towards the congested neighbor is infact reduced by 25%, right?

If you generate random numbers to have a statistically valid sample,
then things should work out.

Assume that you have a call arrival rate of 200 calls per
second, and assume you want to drop 30% of the calls (i.e., 60 cps).
Here is a run of a random number generator using the most simplest
of Linux's rand() function with different seeds and only using the
high order bits; i.e.,

    random_number = 1 + (int) (10.0 * (rand() / (RAND_MAX + 1.0))))

If you generate 200 random numbers in 4 runs and look at the cumulative
value in the histogram, you will note that on the average, 60 calls
will be dropped (in the output below, please see the row with the
Midpt column value of 26, which represents random numbers with
values in the 20-30 bin):

        Midpt    Freq     Cum
Run 1  6.000      23      23
       16.000      11      34
       26.000      22      56
       36.000      22      78
       46.000      20      98
       56.000      16     114
       66.000      22     136
       76.000      23     159
       86.000      19     178
       96.000      22     200

Run 2  6.000      23      23
       16.000      25      48
       26.000      19      67
       36.000      33     100
       46.000      17     117
       56.000      17     134
       66.000      16     150
       76.000      12     162
       86.000      22     184
       96.000      16     200

Run 3  6.000      22      22
       16.000      16      38
       26.000      24      62
       36.000      15      77
       46.000      19      96
       56.000      24     120
       66.000      26     146
       76.000      14     160
       86.000      25     185
       96.000      15     200

Run 4  6.000      20      20
       16.000      15      35
       26.000      30      65
       36.000      23      88
       46.000      17     105
       56.000      21     126
       66.000      19     145
       76.000      24     169
       86.000      16     185
       96.000      15     200

If you generate a 1000 random numbers in each run, you will get closer
to the average.

Thanks,

- vijay

---

From: Padma Valluri <[email-masked]>
Date: Tue, 15 Jun 2010 16:37:28 -0400

Comments in-line.

Thanks.

Date: 06/15/2010 04:10PM

[PV] Sure, but aren't we looking for a better mechanism than the existing ones and be more deterministic?

Midpt    Freq     Cum
Run 1  6.000      23      23
16.000      11      34
26.000      22      56
36.000      22      78
46.000      20      98
56.000      16     114
66.000      22     136
76.000      23     159
86.000      19     178
96.000      22     200

Run 2  6.000      23      23
16.000      25      48
26.000      19      67
36.000      33     100
46.000      17     117
56.000      17     134
66.000      16     150
76.000      12     162
86.000      22     184
96.000      16     200

Run 3  6.000      22      22
16.000      16      38
26.000      24      62
36.000      15      77
46.000      19      96
56.000      24     120
66.000      26     146
76.000      14     160
86.000      25     185
96.000      15     200

Run 4  6.000      20      20
16.000      15      35
26.000      30      65
36.000      23      88
46.000      17     105
56.000      21     126
66.000      19     145
76.000      24     169
86.000      16     185
96.000      15     200

[PV] Not sure if you need to specify how to implement the traffic reduction towards a node in the draft. If the server wants to reduce the load by 25%, it might just drop every 4th request going to the congested neighbor. The oc value might change before you reach the right sample to be close to the average.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Jun 2010 16:05:25 -0500

>     existing ones and be more deterministic?

Let's be sure that we're on the same page here.  The above
discussion is predicated on the text in Section 3.6 that
discusses what to do when the downstream server does not
respond *at all*.  If it does, then yes, we are attempting to
design a more deterministic mechanism.  In other words,
we may be in vehement agreement but still debating a moot
point.

To recap, if the downstream server responds and it supports
overload control, the new mechanism we are designing kicks in.
If it does not respond at all for the lifetime of a transaction,
then the upstream server avoids it (and most production
servers already do so.)

>     [PV] Not sure if you need to specify how to implement the traffic
>     reduction towards a node in the draft. If the server wants to reduce
>     the load by 25%, it might just drop every 4th request going to the
>     congested neighbor. The oc value might change before you reach the
>     right sample to be close to the average.

I think providing some guidance is not a bad idea.  An implementer
can always substitute a better algorithm if he or she wants to.

Thanks,

- vijay

---

From: Padma Valluri <[email-masked]>
Date: Wed, 16 Jun 2010 11:53:55 -0400

Vijay,

Thanks for your response. Comments in-line.

Padma.

Date: 06/15/2010 05:05PM

[PV] Understood. When there is no response from an overloaded server, it will help to have a notify mechanism in place to signal the upstream nodes that its ready for requests when the congestion is abated, not just wait for timeout. This would also reduce retries, retransmissions and rerouting (at application level) in a more persistent congestion scenario.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 16 Jun 2010 17:11:13 -0500

Padma: Thank you for your feedback.  More inline.

On 06/16/2010 10:53 AM, Padma Valluri wrote:
>     [PV] Understood. When there is no response from an overloaded
>     server, it will help to have a notify mechanism in place to signal
>     the upstream nodes that its ready for requests when the congestion
>     is abated, not just wait for timeout. This would also reduce
>     retries, retransmissions and rerouting (at application level) in a
>     more persistent congestion scenario.

Again, it helps to look at the context of what is happening.
Section 3.6 --- upon which the above email exchange is predicated
on --- talks about the corner case where the upstream SIP entity
has sent a request to the downstream server but has not received
any response for the duration of the transaction's lifetime.

Case 1: Downstream server supports oc.
  If it did so, it would just have easily sent a response
  with overload control parameters to throttle the
  upstream entity.  But it did not.  Therefore, if it is
  unable to even send a response to the arriving requests,
  it is equally unlikely to create a brand new NOT request
  to send to the upstream entity.  Thus, I don't see how
  having a notification mechanism will help in this particular
  corner case.

Case 2: Downstream server does not support oc.
  Under this scenario, there is an even less probability
  of getting a NOT request from the downstream server.
  If it does not support oc at all, we cannot expect it
  to send a NOT.

Thank you,

- vijay

---

From: Padma Valluri <[email-masked]>
Date: Thu, 17 Jun 2010 17:19:01 -0400

Please see in-line.

Date: 06/16/2010 06:11PM

[PV] This is the corner case that I'm referring to. The notification will be sent when the SIP server comes out of overload condition. This may be triggered by a local overload control mechansim. Sure it can wait for a new request and piggyback oc information in a response after the black list timeout. If the timeout is too small overload condition gets aggravated, if it is too large requests are being queued/rejected/re-routed unnecessarily. Worst case if the oc was 100% (from the last received response)and there was no traffic going to the congested server, no request will be forwarded to it ever. Though it appears as a corner case I feel what is missing here is that the congestion info is always reported reactively and sometimes the servers may need to report their uncongested status on their own. The ping mechanism can also come in handy to verify the status of the adjacent server to restore the traffic towards that destination.

Thank you,

- vijay

---

From: "Bharrat, Shaun" <[email-masked]>
Date: Fri, 18 Jun 2010 09:20:38 -0400

Vijay:

Some questions on the -00 version of the draft.

3.2

When a SIP server retransmits a response, it MUST use the 'oc'
   parameter value and 'oc-validity' parameter value consistent with the
   overload state at the time the retransmitted response is sent.  This
   implies that the values in the 'oc' and 'oc-validity' parameters may
   be different then the ones used in previous retransmissions of the
   response. 

I understand the desire for this but I would like to point out that
some (many) implementations might balk at this. Is this the first case 
where the retransmission of a response requires that the implementation 
rebuild the SIP message rather than resend the original? Determining the

overload state and retransmission of a response for a transaction might
also be in two very separated layers so even getting the updated
information
might be problematic.

Does anyone else feel this might be a problem and deserving of
discussion?

3.5 

This seems to be covered by this...

  A SIP server compliant to this specification MUST honor 'oc'
   parameter values it receives from downstream neighbors.  The SIP
   server MUST NOT forward more messages to a SIP server than allowed by
   the current 'oc' parameter value from this server.
..
The SIP server SHOULD use the following algorithm to determine if it
   can forward the request.  The SIP server draws a random number
   between 1 and 100 for the current request.  If the random number is
   less than or equal to the 'oc' parameter value, the request is not
   forwarded.  Otherwise, the request is forwarded.  Any other
   algorithms that approximate the random number algorithm may be used
   as well.

Does this constrain the sender to blindly following a pure % drop
scheme?
Suppose the sender is capable of monitoring the rate to an overloaded
server and the attempt rate changes significantly. The goal (I would
think)
is that the sender send no more than oc % of the rate at the time the oc
was issued. Does this text allow the sender to do this (i.e. send less
than
allowed by oc % when attempt rate goes up and more than oc % when
attempt
rate goes down)?

Thanks and cheers,
Shaun

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: Monday, June 14, 2010 3:05 PM
> Cc: Volker Hilt; Henning Schulzrinne
> Subject: [sip-overload] SIP overload control draft 
> (was:draft-hilt-sipping-overload)
> 
> This version of the draft contains the list feedback that 
> occurred on the list from Timothy Moran [1], Tolga Asveren 
> [2], Geoff Hunt [3] and R. Parthasarathi [4].
> http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/dr
> aft-hilt-sipping-overload-08.txt&url2=http://www.ietf.org/id/d
> raft-gurbani-soc-overload-control-00.txt
> 
> [1] 
> http://www.ietf.org/mail-archive/web/sip-overload/current/msg0
> 0068.html
> [2] 
> http://www.ietf.org/mail-archive/web/sip-overload/current/msg0
> 0076.html
> [3] 
> http://www.ietf.org/mail-archive/web/sip-overload/current/msg0
> 0079.html
> [4] 
> http://www.ietf.org/mail-archive/web/sip-overload/current/msg0
> 0113.html
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 21 Jun 2010 23:16:57 +0530

Hi Vijay,

AFAIK, Most of the stack implementation reuse the buffer for retransmitting the message and this happens in the SIP transaction layer. As Shaun mentioned, SIP applications will not have the control as RFC 3261 mentioned that Retransmission is SIP transaction layer functionality. This will be major change in all the existing SIP application & stack.

Also, this proposed functionality will have the major performance impact in the system in case the message has to be re-constructed during each retransmission. 

Thanks

Partha

________________________________

From: [email-masked] on behalf of Bharrat, Shaun
Sent: Fri 6/18/2010 6:50 PM
To: Vijay K. Gurbani; [email-masked]
Cc: Volker Hilt; Henning Schulzrinne
Subject: Re: [sip-overload] SIP overload control draft(was:draft-hilt-sipping-overload)

Vijay:

3.2

3.5

Thanks and cheers,
Shaun

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 21 Jun 2010 23:28:25 -0500

> Some questions on the -00 version of the draft.

Shaun: Thanks for the feedback.  More inline.

> information might be problematic.

That is a valid point.  One way to address it is to simply downgrade
the MUST to a SHOULD.  That way, if the overloaded server chooses
to provide finer-grained information to its upstream peer, the upstream
peer will gladly take it and update its state with respect to the
overload condition of the overloaded downstream peer accordingly.

> allowed by oc % when attempt rate goes up and more than oc % when

I am not sure I follow.  The tact taken by this draft is that the
overloaded server remains the authoritative entity to provide backoff
information to its upstream peers.  Asking the sender --- i.e., the
upstream server sending requests to the overloaded one --- to
monitor the rate of the downstream (overloaded) server has its own
set of problems, no?  Unless, of course, I misunderstood what you
wrote above.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 21 Jun 2010 23:33:36 -0500

On 06/21/2010 12:46 PM, Parthasarathi R (partr) wrote:
> Hi Vijay,
>
> AFAIK, Most of the stack implementation reuse the buffer for
> retransmitting the message and this happens in the SIP transaction
> layer. As Shaun mentioned, SIP applications will not have the control as
> RFC 3261 mentioned that Retransmission is SIP transaction layer
> functionality. This will be major change in all the existing SIP
> application & stack.
>
> Also, this proposed functionality will have the major performance impact
> in the system in case the message has to be re-constructed during each
> retransmission.

Partha: Agreed; it is reasonable to maintain a distinction between
the retransmissions at the transaction layer and monitoring overload
at some other layer in a SIP stack.  While some SIP stacks may be able
to dynamically update overload control status, asking all to do so is
probably not a good implementation approach.

Please see my previous response on downgrading the normative
reference.

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 22 Jun 2010 08:49:57 -0400

> set of problems, no?  Unless, of course, I misunderstood what you

I think the point here is that "throttle by X%" is not always the best 
approach, especially when the arrival rate fluctuates wildly.  Reducing 
by, say, 50% might be way to much, or nothing like enough.  It might be 
more productive to say "reduce your transmission rate to Y SIP messages 
per second".  Does this draft permit the latter approach?

It is worth noting that, in the circuit switched world, network overload 
controls based on "% blocking" have largely been replaced by "call 
capping" (e.g. one message every z time interval).  Not everything from 
the circuit switched world is relevant to SIP, but I think this one is.

Janet

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Jun 2010 09:14:41 -0400

inline

> overload condition of the overloaded downstream peer accordingly.

Reducing the MUST to a SHOULD eliminates the burden on the overloaded 
server. But then what is the impact on the algorithm? Perhaps something 
can be found for the recipient to do that would detect and discount 
values that have been delayed.

I don't actually have anything specific in mind - just brainstorming for 
a solution. Perhaps when a new value is received it could be associated 
with the timestamp from the Date header in the response, and then 
subsequent oc values from responses with earlier Dates could be ignored. 
That of course doesn't take into account that the message may have come 
several hops.

A variant on that would be to add a sequence number on oc values from a 
given server. These would only have to change when the oc *value* 
changes, so a server that is not overloaded would be sending a value of 
0 with an unchanging sequence number.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 22 Jun 2010 19:09:10 +0530

Paul/Vijay,

Retransmission with the overload information will never go well and
overload information has to be passed in real-time. So, the
retransmission has to be avoided by the selecting the appropriate
transport mechanism or other means. One of the approach comes to my mind
is as follows:

In case SUB/NOT mechanism is used for overload information, the
following steps will resolve the retransmission issue:

1) NOTIFY shall be integrated into SIP stack as a separate transaction
user (application) which has Timer F is equivalent to Timer E.  
2) On Timer F for NOTIFY of overload, the new NOTIFY shall be formed and
send it. 

This approach will not have any change in the transaction layer and
other application in the system. The timer expiry provides the control
to the transaction user. Overload control information passed from each
of the NOTIFY is in real-time till the neighbor is responding back. As
overload NOTIFY is a separate application in the system from SIP stack
perspective, there is no change in other applications and follow the
existing behavior. Please let me the group opinion about this approach.

Thanks
Partha

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Paul Kyzivat
(pkyzivat)
Sent: Tuesday, June 22, 2010 6:45 PM
To: Vijay K. Gurbani
Cc: Volker Hilt; Bharrat,Shaun; [email-masked]; Henning
Schulzrinne
Subject: Re: [sip-overload] SIP overload control draft

inline

Vijay K. Gurbani wrote:
>> some (many) implementations might balk at this. Is this the first 
>> case where the retransmission of a response requires that the 
>> implementation rebuild the SIP message rather than resend the 
>> original? Determining the overload state and retransmission of a 
>> response for a transaction might also be in two very separated layers

>> so even getting the updated information might be problematic.
> 
> the MUST to a SHOULD.  That way, if the overloaded server chooses to 
> provide finer-grained information to its upstream peer, the upstream 

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 22 Jun 2010 08:44:26 -0500

> values that have been delayed.

Paul: I will circle back to the simulation results to if they
showed better overload control when retransmissions provided a
more up-to-date "oc" value.  If updating the "oc" value during
retransmissions showed no --- or marginal --- benefit, it seems
appropriate to downgrade the MUST to a SHOULD.

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Tue, 22 Jun 2010 16:06:11 +0200

> per second". Does this draft permit the latter approach?
Yes, it can. However, I do think it would be useful to agree on one or 
the other though and not have rate- and loss-based feedback as two 
options. Therefore, I think it would be very useful to have a discussion 
on whether loss- or rate-based feedback is better.

Thanks,

Volker

---

From: Volker Hilt <[email-masked]>
Date: Tue, 22 Jun 2010 16:24:12 +0200

> overload condition of the overloaded downstream peer accordingly.
Indeed. It might be useful to add a timestamp to an oc value that 
indicates when the oc value was created on a server. The receiver of an 
oc value can then compare the timestamp of the oc value with the most 
recent one it has received. That way, it can discard older values that 
may be contained in a retransmission from a device that does not update 
oc values.

>> allowed by oc % when attempt rate goes up and more than oc % when
The draft is written in a way that the oc % fixes the percentage of 
traffic that is dropped. If the traffic increases, that will increase 
the rate that is forwarded as the forwarded rate is a fixed fraction of 
the offered rate. If that is too high, the server needs to increase the 
% in its feedback.

I think the bigger question is whether a fixed rate or a fixed loss 
percentage is preferable as feedback.

There is some discussion on this topic in section 9 of 
https://datatracker.ietf.org/doc/draft-hilt-soc-overload-design/

Comments are highly appreciated!

Thanks,

Volker

---

From: Volker Hilt <[email-masked]>
Date: Tue, 22 Jun 2010 16:30:30 +0200

> 0 with an unchanging sequence number.
Yes, good point!

Volker

---

From: "Bharrat, Shaun" <[email-masked]>
Date: Tue, 22 Jun 2010 10:55:53 -0400

> >> is that the sender send no more than oc % of the rate at 
> the time the 
> >> oc was issued. Does this text allow the sender to do this 
> (i.e. send 
> >> less than allowed by oc % when attempt rate goes up and 
> more than oc 
> >> % when attempt rate goes down)?
> >
> The draft is written in a way that the oc % fixes the 
> percentage of traffic that is dropped. If the traffic 
> increases, that will increase the rate that is forwarded as 
> the forwarded rate is a fixed fraction of the offered rate. 
> If that is too high, the server needs to increase the % in 
> its feedback.
> 
> I think the bigger question is whether a fixed rate or a 
> fixed loss percentage is preferable as feedback.
> 

It was my question that sent us down this rathole so I wanted to expand
a bit on the my original question. I understand the tradeoffs between
sending a rate versus a loss percentage. I don't question the logic or
reasoning that led to the choice of a loss percentage. I am sure the
rate
choice has its own rat's nest of issues (how to appoportion the rate for
example). 

So, assuming a loss percentage, my question was whether an 
sender would be allowed (but not required) to behave more sensibly
without 
violating the letter (or spirit) of the draft. Specifically, if the 
sender *knows* its rate towards the overloaded peer, it can in theory 
adjust its rate to (100-oc%) of the rate that resulted in the overload 
indication. In abstract, this would seem to behave better if the load 
towards the overloaded peer is changing. But the concern is that this 
might affect the stability of the overall algorithm if some senders 
behave this way.

So, is the draft prescribing the sender MUST send (100-oc%) of its load
regardless of the variability of the load (because of stability
concerns), 
or is it a must send NO MORE than 100-oc% thereby allowing the sender to

use a higher drop percentage depending on its understanding of the load?

Cheers,
Shaun

> From: Volker Hilt [mailto:[email-masked]] 
> Sent: Tuesday, June 22, 2010 10:24 AM
> To: Vijay K. Gurbani
> Cc: Bharrat, Shaun; [email-masked]; Henning Schulzrinne
> Indeed. It might be useful to add a timestamp to an oc value 
> that indicates when the oc value was created on a server. The 
> receiver of an oc value can then compare the timestamp of the 
> oc value with the most recent one it has received. That way, 
> it can discard older values that may be contained in a 
> retransmission from a device that does not update oc values.
> 
> 
> >> 3.5
> >>
> >> is that the sender send no more than oc % of the rate at 
> the time the 
> >> oc was issued. Does this text allow the sender to do this 
> (i.e. send 
> >> less than allowed by oc % when attempt rate goes up and 
> more than oc 
> >> % when attempt rate goes down)?
> >
> The draft is written in a way that the oc % fixes the 
> percentage of traffic that is dropped. If the traffic 
> increases, that will increase the rate that is forwarded as 
> the forwarded rate is a fixed fraction of the offered rate. 
> If that is too high, the server needs to increase the % in 
> its feedback.
> 
> I think the bigger question is whether a fixed rate or a 
> fixed loss percentage is preferable as feedback.
> 
> > upstream server sending requests to the overloaded one --- 
> to monitor 
> > the rate of the downstream (overloaded) server has its own set of 
> > problems, no?  Unless, of course, I misunderstood what you wrote 
> > above.
> >
> > Thanks,
> >
> > - vijay
>

---

From: Volker Hilt <[email-masked]>
Date: Tue, 22 Jun 2010 17:17:52 +0200

> following steps will resolve the retransmission issue:
The NOTIFY messages that contain overload information can require a 
retransmission (e.g., if they get dropped). The bodies of the 
retransmitted NOTIFY messages would have to be updated.

> 2) On Timer F for NOTIFY of overload, the new NOTIFY shall be formed and
How would the exponential backoff for overload NOTIFY retransmissions 
work in this case? It seems that with this change, overload NOTIFYs 
would be retransmitted at a constant rate of 500ms until they are 
eventually confirmed.

Thanks,

Volker

> other application in the system.The timer expiry provides the control

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 23 Jun 2010 12:05:27 +0530

Volker,

Please read inline.

Thanks
Partha 

-----Original Message-----
From: Volker Hilt [mailto:[email-masked]] 
Sent: Tuesday, June 22, 2010 8:48 PM
To: Parthasarathi R (partr)
Cc: Paul Kyzivat (pkyzivat); Gurbani, Vijay K (Vijay); Bharrat,Shaun;
[email-masked]; Henning Schulzrinne
Subject: Re: [sip-overload] SIP overload control draft

On 6/22/2010 3:39 PM, Parthasarathi R (partr) wrote:
> transport mechanism or other means. One of the approach comes to my 
> mind is as follows:
>

<Partha> It is the indent to avoid re-transmission. </Partha>

> 2) On Timer F for NOTIFY of overload, the new NOTIFY shall be formed 
> and send it.
>

<Partha> This works well in the case of intermediate non-SIP hops causes
the issue or subscriber reloads. But in case of the change in subscriber
without termination will call for retry counter in Notifier application
to solve this issue (Solving issue in app). I agree that it is not good
idea as it has some assumption behind. </Partha>

Thanks,

Volker

>>>      parameter value and 'oc-validity' parameter value consistent 
>>> with
> the
>>>      implies that the values in the 'oc' and 'oc-validity' 
>>> parameters
> may
> server. But then what is the impact on the algorithm? Perhaps 
> something can be found for the recipient to do that would detect and 
> discount values that have been delayed.
>
> I don't actually have anything specific in mind - just brainstorming 
> for a solution. Perhaps when a new value is received it could be 
> associated with the timestamp from the Date header in the response, 
> and then subsequent oc values from responses with earlier Dates could
be ignored.
>
> That of course doesn't take into account that the message may have 
> come several hops.
>
> A variant on that would be to add a sequence number on oc values from 
> a given server. These would only have to change when the oc *value* 
> changes, so a server that is not overloaded would be sending a value 
> of 0 with an unchanging sequence number.
>
> 	Thanks,
> 	Paul

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 23 Jun 2010 11:25:46 -0400

My apologies for the typo.  That should have been "call Gapping", not 
"call Capping".

Janet

[email-masked] wrote on 06/22/2010 08:49:57 AM:

> Janet P Gunn/USA/CSC@CSC 
> 06/22/2010 08:49 AM
> To
> "Vijay K. Gurbani" <[email-masked]>
> 
> cc
> 
> [email-masked], Volker Hilt <volker.hilt@alcatel-
> lucent.com>, "Bharrat, Shaun" <[email-masked]>, sip-
> [email-masked], Henning Schulzrinne <[email-masked]>
> 
> Subject
> 
> Re: [sip-overload] SIP overload control draft
> 
> 
> 
> > > 3.5
> > >
> I think the point here is that "throttle by X%" is not always the 
> best approach, especially when the arrival rate fluctuates wildly. 
> Reducing by, say, 50% might be way to much, or nothing like enough. 
> It might be more productive to say "reduce your transmission rate to
> Y SIP messages per second".  Does this draft permit the latter approach? 

> 
> It is worth noting that, in the circuit switched world, network 
> overload controls based on "% blocking" have largely been replaced 
> by "call capping" (e.g. one message every z time interval).  Not 
> everything from the circuit switched world is relevant to SIP, but I
> think this one is. 
> 
> Janet