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

["DRAGE, Keith (Keith)" <[e-mail]>]

OK

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Volker Hilt
> Sent: 20 April 2011 02:10
> To: [e-mail]
> Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
>
> 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:sip-overload-
> [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
> >>
> >>
> >>
> >
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload