Subject: Re: [sip-overload] SIP overload control draft

From: Padma Valluri <[email-masked]>
Date: Mon, 26 Jul 2010 11:21:00 -0400

Vijay,
I started with suggesting options ping message (which has its own issues) 
for the corner case mentioned in open issue 2. I'm not very keen to use 
sub/notify if its more complicated. Also this case is not just for servers 
that are crashed, but also for the servers which send the oc value as 100% 
to avoid the crash. In worst case sending a single request as a polling 
mechanism would wok, but if there is a relatively simpler option like 
sending a ping which might make it more efficient, it should be 
considered. 

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.

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

Please see in-line.

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.

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

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

Padma: Thank you for your feedback.  More inline.

On 06/16/2010 10:53 AM, Padma Valluri wrote:
>     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] 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.
[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.
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
-- 
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