Subject: [sip-overload] Sending overload control in 100

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 24 Nov 2010 11:13:19 -0600

(Starting a new thread to track the issue better.)

Folks: Rahul [1] and Keith [2] have stated a reasonable position
that we should treat inserting overload control into a 100 with
some trepidation.  Initially, I was of the opinion that it does not
matter [3].  However, after the discussion, it appears reasonable to
revisit the issue outlined in [3],[4].

To recap, the basic issue is that overload-control changes the
semantics of 100 from a simple stopping the retransmission to
carrying additional information (the overload control information.)
Consequently, any additional time in generating or acting on a
received 100 may cause more delay, thus potentially exacerbating the
already overloaded situation by retransmissions.

If anyone else has any other comments, please read [4], [3], [2],
and [1] --- in that order --- and let us know of your thoughts.

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00451.html
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00450.html
[3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00449.html
[4] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00447.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: Volker Hilt <[email-masked]>
Date: Mon, 29 Nov 2010 09:39:19 -0500

Vijay,

I think it is reasonable to say that neither the receiver nor the sender 
should rely on overload control information transmitted in an 100 Trying 
for the reasons that were stated. But I don't think the draft should 
preclude the inclusion of overload information in 100 Trying if it is 
done under the above precondition.

Thanks,

Volker

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 30 Nov 2010 13:28:52 -0600

On 11/29/2010 08:39 AM, Volker Hilt wrote:
> Vijay,
>
> I think it is reasonable to say that neither the receiver nor the
> sender should rely on overload control information transmitted in an
> 100 Trying for the reasons that were stated.

Volker: Let me re-state the above to make it less ambiguous (to me, at
least).

I believe you are saying that IF there is overload control information
in the 100, THEN the upstream client can rely on it.  However, the
upstream SIP client MUST NOT assume that there will always be overload
control in the 100.

Similarly, it is up to the downstream SIP server to put overload
control in the 100.  It is not bound to, and can just as well sent the
overload control in the first non-100 response going upstream.

> But I don't think the draft should preclude the inclusion of
> overload information in 100 Trying if it is done under the above
> precondition.

I fully agree.  I think we ought to point out to implementers the
special nature of 100 just so that they are warned.  However, the
draft should not preclude the inclusion in the 100.

Thanks,

- vijay

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Tue, 30 Nov 2010 21:45:22 +0100

I think allowing overload information in 100 Trying will ask the sender to always check 100 Trying.(to check if overload info is present or not present).
This check will be heavier as it asks SIP applications to take care of 100 Trying.
This flexibility violates the basic design principle of overload mechanism (i.e mechanism itself should not increase the load).
Hence I'll like to see exclusion of 100 Trying for overload purposes.

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: "Vijay K. Gurbani" <[email-masked]>
Date: Tuesday, November 30, 2010 8:27 pm
Subject: Re: [sip-overload] Sending overload control in 100
To: [email-masked]

> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 30 Nov 2010 15:15:47 -0600

On 11/30/2010 02:45 PM, RahulSrivastava 71616 wrote:
> I think allowing overload information in 100 Trying will ask the
> sender to always check 100 Trying.(to check if overload info is
> present or not present).

Again, this would be implementation dependent.

At this point, the draft is rather silent on which responses carry
the overload control information upstream.  We could simply
state that irrespective of whether or not overload control was
sent in a 100, it MUST be sent in the first non-100 response
going upstream.

This way, in the worst case, the receiver will not query the 100
for the overload control information if it does not want to,
and it is guaranteed to receive overload information in the
first non-100 response it receives.

Similarly, senders are not bound to include overload control
in the 100, but they can if the want to.  They will be bound,
however, to include overload control in the first non-100
response going upstream.

Would something to the above effect assuage your concern?

> This check will be heavier as it asks SIP applications to take care
> of 100 Trying. This flexibility violates the basic design principle
> of overload mechanism (i.e mechanism itself should not increase the
> load). Hence I'll like to see exclusion of 100 Trying for overload
> purposes.

I believe that if we are judicious in our wording, then we allow
for implementations to insert or defer insertion of overload
control information in a 100 depending on their particular
architecture and implementation.

Thanks,

- vijay

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Tue, 30 Nov 2010 22:29:10 +0100

If A sends INVITE to B and say B is already overloaded.
How does B informs A beforehand?
 
Assuming event to send first INVITE to A by B happens quite late? 
 
If we add information in INVITE response only, then first X INVITES to B will fail since B was already overloaded? 
It looks like even if sufficient window was avaialble to B it can't inform A since there was no INVITE from A?

If above conclusion is correct then sending overload information "in-band" is the right approach?

Regards,
Rahul