Re: [sip-overload] draft-ietf-soc-overload-design-05

[Volker Hilt <[e-mail]>]

Janet, All,

are you comfortable with the changes for this draft as proposed below? 
The proposal is the add the following sentence at the end of the RPH 
discussion in Sec 12:

     The action taken is determined by the characteristics defined for
     the set of priority values of a Namespace as well as the local
     policies defined for the various Namespaces supported by the server.

Thanks,

Volker



On 4/18/2011 1:27 PM, ken carlberg wrote:
> Volker,
>
> I leave it in your hands as to what to keep, remove, or simply move to another document.
>
> cheers,
>
> -ken
>
>
> On Apr 18, 2011, at 1:22 PM, Volker Hilt wrote:
>
>> Ken,
>>
>> comments inline.
>>> 12. Message Prioritization
>>>
>>> Overload control can require a SIP server to prioritize requests and
>>> select requests to be rejected or redirected. The selection is
>>> largely a matter of local policy of the SIP server, the overall
>>> network, and the services it provides. As a general rule, SIP server
>>> should prioritize requests for ongoing dialogs over requests that set
>>> up a new dialog. Targeting requests for ongoing dialogs may prevent
>>> users from modifying or terminating an ongoing dialog.
>>>
>>> While there are many factors which can affect the prioritization of
>>> SIP requests, the Resource-Priority header field [RFC4412] is a prime
>>> candidate for marking the prioritization of SIP requests. Depending
>>> on the particular network and the services it offers, a particular
>>> namespace and priority value in the RPH it could indicate i) a high
>>> priority request, which should be preserved if possible during
>>> overload, ii) a low priority request, which should be dropped during
>>> overload, or iii) a label, which has no impact on message
>>> prioritization in this network.
>>
>> I've shortened the added text as follows:
>>> <insert text>  The action taken is
>>> determined by the characteristics defined for the set of priority values
>>> of a Namespace as well as the local policies defined for the various
>>> Namespaces supported by the server.
>>>
>>
>> I would suggest to move this text to the Gurbani draft as it defines the specific processing of RPH.
>>> We note that [RFC4412] allows the presence of multiple RPH entries
>>> per SIP request. Local policy would determine which Namespace and
>>> Priority tuple are used to prioritize requests. However, for the sake of
>>> simplicity, a default position should be the use of the first RPH entry to
>>> determine the priority of the SIP request.
>>
>> I'm not sure how much this is related to the design considerations of an overload control mechanism and how much it is related to RPH. I'd suggest to keep this text out of the oc design document.
>>> Another scenario that should be considered is the presence of Back
>>> to Back User Agents (B2BUA) that may strip out the RPH from the
>>> upstream SIP request. Operators or Administrators may choose to
>>> insert their own RPH to support downstream prioritization of the SIP
>>> request. This RPH inserted by the B2BUA may conform to a
>>> Namespace set defined in [RPH4412], or it may reflect a new
>>> Namespace set.
>>> </insert text>
>>>
>> Generally, at this point I'd like to keep the changes to the document to the absolute necessary. It has been discussed for a long time including issues related to RPH.
>>
>> Thanks,
>>
>> Volker
>>
>>> For a number of reasons, responses should not be targeted in order to
>>> reduce SIP server load. Responses cannot be rejected and would have
>>> to be dropped. This triggers the retransmission of the request plus
>>> the response, leading to even more load. In addition, the request
>>> associated with a response has already been processed and dropping
>>> the response will waste the efforts that have been spent on the
>>> request. Most importantly, rejecting a request effectively also
>>> removes the request and the response. If no requests are passed
>>> along there will be no responses coming back in return.
>>>
>>> Overload control does not change the retransmission behavior of SIP.
>>> Retransmissions are triggered using procedures defined in RFC 3261
>>> [RFC3261] and not subject to throttling.
>>>
>> _______________________________________________
>> sip-overload mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sip-overload
>