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

[Volker Hilt <[e-mail]>]

Christian, Gonzalo,
> 
> yes, the draft should talk about overload state that needs to be 
> propagated upstream in cases like the one you describe.
> 
Yes, this case probably needs more attention in the draft.

>> 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).

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.

>> 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.

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.

>> I fully agree that a full path approach would be very complex,
>> 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



>> -----Ursprüngliche Nachricht-----
>> Von: Gonzalo Camarillo [mailto:[e-mail]] 
>> Gesendet: Montag, 30. Oktober 2006 21:32
>> An: sipping
>> Cc: [e-mail]; Volker Hilt; [e-mail]; 
>> [e-mail]
>> 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 [e-mail] for questions on current sip
>> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP