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

[ken carlberg <[e-mail]>]

On Apr 19, 2011, at 8:23 AM, Janet P Gunn wrote:

> 
> Volker, 
> 
> I would just as soon stick with the original text.   
> 
> I think the new proposed text is misleading. 
> 
> Both Queuing and Preemption are mechanisms that make sense when the "holding time" is several orders of magnitude more that the time to manipulate the queue, or organize the preemption.  This makes them useful mechanisms for dealing with SIP sessions.   
> 
> But when dealing with a SIP server, processing SIP messages, the "holding time" is likely to be the same order of magnitude as the time to manipulate the queue, or organize the preemption.  In this case introducing queue manipulation or preemption is counterproductive, and likely to lead to thrashing.. 

you can't have it both ways.  you cannot say that the Namespaces in rfc4412 are the ones to be used, but that their defined characteristics (either being queuing or preemption) are inappropriate.

I fail to see how pointing out aspects in rfc4412 is misleading.  Note that my suggested text does not advocate nor dismiss existing Namespaces.  The text is general and it simply points out existing aspects, such as the potential for multiple RPH, which is not mentioned in the original text of soc-overload-design.  How that can be construed as misleading is beyond me.

-ken


> We have been through this discussion many times, going back to the development of  Req 13 in 5390, and I see no advantage in re-introducing it to this document. 
> 
> Janet
> 
> This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. 
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. 
> 
> 
> From:	Volker Hilt <[e-mail]>
> To:	Janet P Gunn/USA/CSC@CSC
> Cc:	"[e-mail]" <[e-mail]>
> Date:	04/18/2011 09:23 PM
> Subject:	Re: [sip-overload] draft-ietf-soc-overload-design-05
> 
> 
> 
> 
> 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
> >
> 
> 
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload