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

[Volker Hilt <[e-mail]>]

Based on the discussion in this thread, I will keep the original text of 
the design draft (i.e., leave the message prioritization section unchanged).

Thanks,

Volker



On 4/19/2011 10:30 AM, ken carlberg wrote:
>
> On Apr 19, 2011, at 9:43 AM, DRAGE, Keith (Keith) wrote:
>
>> With regard to your comment on 1), I believe nothing extra is
>> required. Anyone setting up multiple namespaces has to define at each
>> entity that is required to understand them how they are treated in
>> relationship to each other. That is part of the implementation. That
>> will define which namespaces exist, and which are used at the
>> receiving entity to give any form of priority handling. There is no
>> reason for SIP overload to alter that relationship in any way, shape,
>> or form.
>
> this is somewhat scenario dependent. but I don't think we are gaining
> any traction, so I'll stop here.
>
>> On 2), I do not believe your comment is correct. The fact that a
>> namespace is a pre-emption namespace is not an invitation to pre-empt
>> all other calls until you get your call through, even under situations
>> of no overload. It merely states that calls can be pre-empted when
>> this namespace is used. The same applies for priority. Usually the
>> algorithm for handling these DOES NOT SAY – handle all calls with this
>> namespace until there are none left, and then move onto others. It
>> deals with things like percentage of traffic and so on. So what I am
>> saying is that the RPH is not a guarantee to override all other
>> traffic, whether overload exists or not.
>
> the preemption-capable systems I've worked on in the past *must* preempt
> or tear down state when there are no available resources -- either
> established calls (or flows) or call/session establishment. I guess
> there are various scenarios and variations of implementations that one
> can consider, but I think that continues down an endless series of
> possibilities that never lead to a definitive answer.
>
> I think the subject has been beaten to a pulp. And to a large degree, we
> have gone much further into topics than perhaps was necessary. The
> purpose of the suggested new next was to broaden the picture and bring
> up topics that are attributed to the RPH. The only position that was
> taken in the text was to suggest in the form of a "should" the use of
> the first RPH (which I meant to be the first "recognized/supported"
> RPH). But I conceded that i was fine to remove that position.
>
> I'll stop here and leave it to the co-authors/co-chairs to decide how to
> proceed.
>
> -ken
>
>
>
>> Regards
>> Keith
>> ------------------------------------------------------------------------
>> *From:*ken carlberg [mailto:[e-mail]]
>> *Sent:*19 April 2011 14:23
>> *To:*DRAGE, Keith (Keith)
>> *Cc:*Janet Gunn;[e-mail] <mailto:[e-mail]>
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>> On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:
>>
>>
>> My confirmation was on what Janet wrote, rather than the original text.
>> Two comments.
>> 1) Any statement about some specific RPH being taken as a default are
>> inappropriate. If you are using RPH you must handle them in the way
>> you already know. If you do not know about an RPH value, then you have
>> to ignore it (and possibly delete it in the outgoing INVITE depending
>> on your policy). There are certainly use cases where multiple RPH
>> values can exist, covering different aspects of priority on the same
>> request. It may be the second one that is received that defines the
>> priority in regard to the handling in the SIP server itself (as
>> opposed to priority of giving a media stream or whatever).
>> or it may be the first, or the last. I'll concede the difficulty in
>> stating the first "recognized/supported" RPH is the one to be used.
>> But I think one is deferring the problem that arises with no position
>> taken at all. The primary point that I wanted to make was that the
>> possibility of multiple RPHs may exist. I'm fine with removing the
>> text of choosing a default RPH in that instance.
>>
>>
>> 2) In a case of load shedding, I suspect that the discussion on
>> whether either priority or pre-emption are relevant depend on whether
>> you are using them to represent the request to the original target
>> server that indicated overload, or to some other server. I believe
>> that in the case of representing to the original targetted server it
>> is inappropriate. It is making the assumption that some of the
>> existing traffic directed from this server to that server is somehow
>> responsible for the overload, and that is an entirely invalid assumption.
>> again, the intent of the suggested added text was to point out to the
>> reader that preemption and queuing are *examples* of what has been
>> defined so far with respect to Namespaces. What you have stated above
>> makes a case that another Namespace should be defined, otherwise, you
>> one is overloading new characteristics from what has already been
>> defined.
>> -ken
>>
>>
>> Regards
>> Keith
>> ------------------------------------------------------------------------
>> *From:*ken carlberg [mailto:[e-mail]]
>> *Sent:*19 April 2011 13:39
>> *To:*DRAGE, Keith (Keith)
>> *Cc:*Janet Gunn;[e-mail] <mailto:[e-mail]>
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>> If your comment is about the original text, then we are in some
>> measure of agreement. If you agree with a position that its incorrect
>> to point out the characteristics for currently defined Namespaces as
>> stated in rfc4412, then we are in disagreement.
>> -ken
>> On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:
>>
>>
>>
>> Janet’s statements about RPH align with the way I understand RPH works.
>> Keith
>> ------------------------------------------------------------------------
>> *From:*[e-mail]
>> <mailto:[e-mail]>[mailto:[e-mail]]*On
>> Behalf Of*Janet P Gunn
>> *Sent:*18 April 2011 19:21
>> *To:*ken carlberg
>> *Cc:*[e-mail]
>> <mailto:[e-mail]>;[e-mail]
>> <mailto:[e-mail]>
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>>
>>
>> Ken,
>>
>> First of all, that text is included in quite a few of the soc
>> documents, so if you change it in the design doc, it will need to be
>> changed in the others too.
>>
>> More importantly, I STRONGLY disagree with the statement that "The
>> action taken is determined by the characteristics defined for the set
>> of priority values of a Namespace (e.g., preemption versus queuing)".
>>
>> Neither "preemption" nor "queuing" are appropriate responses to a
>> request for load shedding. Either the request is shed, or it is not.
>> AFAIK, there is no intention to "preempt" another request, nor to
>> change in the order in which the messages respond to load shedding..
>>
>> In particular, in systems already deployed, SIP messages using the
>> ets/wps family of namespaces (which are defined as "queuing based" ,
>> and do queue for MEDIA resources) receive exemption from SIP server
>> overload based shedding. They do NOT have any special queuing based
>> behavior for SIP server resources. Not do they preempt other SIP requests.
>>
>> Furthermore, the behavior associated with a particular namespace is
>> highly dependant on the particular network. dsn.flash-override is not
>> going to elicit any priority behavior in a civilian or public network.
>> It will certainly not preempt anything. Conversely, ets.0, wps.0 is
>> not going to elicit any priority behavior in the DSN network
>>
>> The statement "An example local policy may even include exemptions
>> from network management control." introduces a new term - " network
>> management control" which would need to be defined. I presume that
>> what you really mean in this context is "exemption from load
>> shedding". This is already covered in i) of the existing text.
>>
>> I fail to see the reason for your proposed statement "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. " AFAIK, the
>> order of the headers is not generally relevant to SIP, and I do not
>> see any particular need to introduce it here. Furthermore, a given SIP
>> agent only "understands" certain namespaces. It seems highly
>> counterproductive to suggest that a SIP server, by default, should
>> "use" a namespace it doesn't understand (just because it is "first") ,
>> and ignore the one(s) it does understand (just because not "first").
>>
>> Even if you change the statement to read "the first RPH entry it
>> understands", you would need a "default behavior" to go with the
>> "default namespace."
>>
>> As far as I am concerned, if a particular SIP server does NOT have a
>> local policy for RPH (both which namespaces are relevant/understood,
>> and the appropriate behavior for each namespace or combination of
>> namespaces), then it should simply ignore the RPH namespaces. This
>> seems consistent with generic SIP behavior with regard to namespaces
>> in general.
>>
>> I fail to see the significance of the statement about B2BUAs. ALL SIP
>> servers, (not just B2BUAs) can and will insert, delete, or change the RPH.
>>
>> I also fail to see the need to refer explicitly to Namespaces not
>> defined in RFC4412. There are already a large number of IETF
>> registered RPH namespaces which do not appear in RFC4412 (see RFC 5478
>> for example) and others have been proposed (for instance
>> draft-ietf-ecrit-local-emergency-rph-namespace). If you are suggesting
>> that specific networks may be using purely "private" RPH namespaces
>> that have never been subject to IETF review, that may well be true in
>> practice, but I don't think it should be introduced into IETF
>> documents- especially ones that are not primarily about RPH.
>>
>> 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:
>> 	
>> ken carlberg <[e-mail] <mailto:[e-mail]>>
>> To:
>> 	
>> [e-mail] <mailto:[e-mail]>
>> Date:
>> 	
>> 04/17/2011 03:38 PM
>> Subject:
>> 	
>> [sip-overload] draft-ietf-soc-overload-design-05
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> Hello,
>>
>> in following up on the discussion point I brought up at the
>> Prague-IETF meeting concerning RPH related text, I've added some
>> suggested text to section 12 ofdraft-ietf-soc-overload-design-05. The
>> suggested text is bound by the following tags:
>> <insert text>
>> </insert text>
>>
>> The purpose of the new text is to present a more complete picture and
>> point out aspects that others following this effort should be aware
>> of. I've kept the rest of the original text for that section as is
>> (ie, I did not remove any original text). I've also sent the suggested
>> text to Martin and James for a sanity check before posting to the list.
>>
>> cheers,
>>
>> -ken
>>
>>
>> 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.<insert text>The action taken is
>> determined by the characteristics defined for the set of priority values
>> of a Namespace (e.g., preemption versus queuing) as well as the
>> local policies defined for the various Namespaces supported by the
>> server. An example local policy may even include exemptions from
>> network management control.
>>
>> 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.
>>
>> 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>
>>
>> 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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/sip-overload
>>
>>
>>
>