Subject: [Sipping] Comments on draft-hilt-sipping-overload-00.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 30 Oct 2006 22:31:51 +0200

Hi,

a few comments on draft-hilt-sipping-overload-00.txt

The last paragraph os page 3 and the last paragraph of Section 4.1 seem
contradictory. The former paragraph says that gateways MUST NOT use
overload control while the latter seems to indicate that they may.

Section 4.5 talks about topology hiding and about not reporting
information about hidden proxies. However, if we go for the hop-by-hop
approach, it would not make sense to report anything related to hidden
proxies to elements different than the B2BUA, which would be the hidden
proxy's next hop.

Regarding the model to choose, the hybrid (third) model seem to get the
best of the other two models.

Regarding hop-by-hop vs. full path, the hop-by-hop seems simpler to
implement and, thus, preferable.

Regarding how to indicate support for this mechanism and how to identify
adjacent entities (the draft proposes the target parameter), we face the
same issues as we did when specifying signalling compression for SIP,
which works also on a hop-by-hop fashion. There, we used Via and SIP URI
parameters.

One issue to think about is whether a proxy sends overload
information/commands to its peer using only responses, or both requests
and responses. If we want to use both requests and responses, we will
face the same peer identification problem as in the SIP/SigComp. That
is, how to correlate the entity sending a request, which is identified
by its Via entry, with the entity receiving a request in the other
direction because it record-routed. The issue is illustrated in the
following slide, which was presented at the last IETF meeting:

http://www3.ietf.org/proceedings/06jul/slides/sip-3.pdf

Nits:

Expand I/O.

Cheers,

Gonzalo

_______________________________________________
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: "Ruppelt, Christian" <[email-masked]>
Date: Tue, 31 Oct 2006 16:22:43 +0100

Hi,
what about an IMS/FMC like architecture where
application servers (Ax) and e.g. MGCF functionality (C) are hidden behind the IMS cloud (B).

A1---\
A2----B--- C
A3---/   

IF C enters overload it will only inform B to reduce the load send to C by x% 
(although the traffic from Ax is the reason for this).
The traffic from A to B is not affected in case of hop-by-hop approach.
This leads to an increasing call failure rate for traffic from Ax by x% because x% sessions will be rejected by B.
I fully agree that a full path approach would be very complex,
but the load should be reduced were it comes from.

christian      

-----Ursprüngliche Nachricht-----
Von: Gonzalo Camarillo [mailto:[email-masked]] 
Gesendet: Montag, 30. Oktober 2006 21:32
An: sipping
Cc: [email-masked]; Volker Hilt; [email-masked]; [email-masked]
Betreff: [Sipping] Comments on draft-hilt-sipping-overload-00.txt

Hi,

Nits:

Expand I/O.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Oct 2006 18:21:01 +0200

Hi,

yes, the draft should talk about overload state that needs to be 
propagated upstream in cases like the one you describe.

Cheers,

Gonzalo

---

From: Volker Hilt <[email-masked]>
Date: Tue, 31 Oct 2006 11:58:24 -0500

Christian, Gonzalo,
> propagated upstream in cases like the one you describe.
Yes, this case probably needs more attention in the draft.

>> IF C enters overload it will only inform B to reduce the load send to 
>> C by x% (although the traffic from Ax is the reason for this).

Yes. It is up to B to decide what to do. If B knows that it is in a 
controlled environment and C is its *only* downstream neighbor, B can 
use hop-by-hop overload control to indicate overload to its upstream 
neighbors if C is overloaded. Essentially B can consider C as a message 
processing resource in this scenario. If this resource is overloaded B 
signals overload to its upstream neighbor.

If B has other downstream neighbors or is in an open environment where 
it can potentially communicate with many downstream entities, it might 
be better of rejecting the x% of the requests it would normally forward 
to C. It should not indicate overload to its upstream neighbors since 
can still serve other destinations.

>> This leads to an increasing call failure rate for traffic from Ax by 
>> x% because x% sessions will be rejected by B.

Even if B rejects these session, Ax may still have an alternative target 
to which it can route these requests. If Ax does not have such a target, 
then it would have to reject these requests anyway.

The only overhead introduced by hop-by-hop overload control is that some 
requests to C are not directly rejected by Ax and go through the detour 
of B.

>> but the load should be reduced were it comes from.
Yes, I agree. I think one of the key points is to avoid a congestion 
collapse. In addition, it is important to find a good tradeoff between 
complexity and the most optimal solution we can achieve.

Cheers,

Volker

---

From: Volker Hilt <[email-masked]>
Date: Tue, 31 Oct 2006 14:49:07 -0500

Gonzalo,

> overload control while the latter seems to indicate that they may.
Yes, thanks. This slipped through when merging the drafts and needs to 
be fixed.

> proxies to elements different than the B2BUA, which would be the hidden
True. Topology hiding should not be an issue for hop-by-hop overload 
control. By definition, only the edge device would report its load to 
upstream neighbors (i.e. entities in other domains). It can decide when 
to indicate that overload has occurred and how much load information it 
wants to disclose.

> implement and, thus, preferable.
Yes, I would tend to agree.

> which works also on a hop-by-hop fashion. There, we used Via and SIP URI
Thanks for the pointer! This seems indeed very similar to what is needed 
for overload control and should probably be aligned.

Actually, it looks like application/instance identifiers are useful for 
a number of purposes (sigcomp, outbound, overload). Would it make sense 
to build them in an usage-independent fashion (maybe we're already there)?

> and responses. 

Load information is most useful for the upstream neighbor of a SIP 
entity since this is the entity that makes routing decisions for 
requests. I don't think there is much room for rerouting a response - 
thus load information in requests may not be all that helpful.

However, one could argue that requests are typically sent in both 
directions and an entity that is a downstream neighbor for one request 
may be an upstream neighbor for another request in the opposite 
direction. Thus, putting load information in requests would increase the 
frequency with which a neighbor learns about load status (since it is 
now reported not only in responses but also in requests). Overall, I 
don't think there is too much value in inserting load information into 
requests, except, maybe, if it is really simple to do (which does not 
seem to be the case).

Cheers,

Volker

> If we want to use both requests and responses, we will