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

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:Gonzalo.Camarillo@ericsson.com] 
Gesendet: Montag, 30. Oktober 2006 21:32
An: sipping
Cc: daryl.malas@level3.com; Volker Hilt; rich.terpstra@level3.com; iwidjaja@lucent.com
Betreff: [Sipping] Comments on draft-hilt-sipping-overload-00.txt

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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP