Subject: Re: [Sip] Comments on draft-ietf-sip-resource-priority-08 (normal calls)

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:57:46 -0400

Dale,

thanks for your comments below and my apologies for addressing them 
late. Please see inline for responses.

Dale Worley wrote:

> - Requests without the Resource-Priority: header are intended to be
> processed at a lower priority than requests with a Resource-Priority:
> header.  But I don't recall this being stated explicitly anywhere, and
> certainly not up-front in the document.  And there seems to be no
> fixed terminology for such requests.  The phrase "normal,
> non-prioritized" seems to be used a lot, despite its cumbersomeness,
> and the fact that it is objectively incorrect.  (Any PR actor
> prioritizes *all* requests; requests without Resource-Priority: are
> given the lowest priority.)
> 

Nothing prevents somebody to define a "scavenger" service for the R-P 
header, i.e., a service that has priority *below* the normal priority 
level. Unlikely, but possible. For example, the gas meter could 
prioritize its meter reading calls as

Resource-Priority: gas.unimportant

I grep'ed for the terms you mentioned, but only found one such 
reference. Maybe you can identify (in private email) conflicting wording.

> - Given the age of this I-D, there are likely to be implementations of
> this mechanism in the field.  It would enhance the reader's interest
> of these were briefly mentioned.

I don't think this is customary and I'm not sure what we should say here.

More to come.

Henning

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 19:02:07 -0400

Dale Worley wrote:

> - There seems to be some ambiguity as to whether a request is
> queued/delayed waiting for the resources needed to process the request
> *itself*, or waiting for resources (like UA facilities, or bandwidth)
> needed for the *dialog* containing the request.  This is probably not
> important, as the prioritization for both sorts of resources is the
> same, but it gets a bit confusing as the draft refers randomly to one
> situation and then the other.  It might help to state up-front that
> there can be queuing for various sorts of resources, and (absent
> specific policy rules in the IANA registration) they are handled the
> same way.

The document assumes that only sessions are preempted. See Section 4.5:

"Preemption applies only to sessions created by SIP requests, while both 
sessions and request handling can be subject to priority queueing."

I don't think preemption makes sense for processing SIP requests 
themselves (parsing, authenticating, etc.), as this has all kinds of bad 
consequences.

If you find other references where the distinction is not made clear, 
please let me know.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 19:53:24 -0400

> - There are many places where the text notes that the generic
> prioritization behavior can be modified by the specific policies in
> the IANA registration for the namespace.  This seems to be redundant,
> and perhaps could be replaced by a single up-front statement.  This
> could be augmented by a statement that the operation of a PR actor can
> also be modified by local administrative policy.

Can you help me by identifying these places?

I searched for 'IANA' and didn't find undue duplication.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 19:57:11 -0400

Dale Worley wrote:

> - Section 3.2, "Accept-Resource-Priority" is unclear as to the
> semantics of the header.  Usually, "Accept" headers describe
> "configuration" information about the device which changes very
> slowly.  Within that concept, I would expect that
> "Accept-Resource-Priority" would list the namespaces that the RP actor
> understands.  But since the definition of the header says that it
> lists priority values, it must be to indicate the priorities that the
> actor currently has the resources to handle.  If so, this should be
> made explicit.  In this case, it seems like there needs to be an
> extension of the definition to allow it to specify that
> "non-prioritized" requests will be accepted.

This is indeed simply a syntactic understanding. Accept-R-P does not 
indicate which resource priority value would yield a successful call. 
(Among other reaons, such information would be of limited use, given the 
possibly rapid change in load.)

I changed "willing to accept" to "willing to process". Let me know if 
there are any other places that could be read as implying that this is 
dynamic, load-dependent state.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 20:03:52 -0400

Dale Worley wrote:

> - In section 4.6.4, "Insufficient authorization" seems to presuppose
> that the RP actor can determine whether the requester is authorized to
> use any particular priority.  But this seems like it is not always
> true.  A better phrasing might be "... but it can determine that the
> originator is not authorized ...".

I don't see how an RP actor can *not* know whether somebody is 
authorized, since it needs to decide whether to honor the request.

> 
> - Section 4.6.5 contains the sentence fragment "If an RP actor
> receives an authorized request, has insufficient resources and the
> request neither preempts another request nor is queued."

Fixed.

> 
> - In section 4.7.2.1, it might be an improvement to say "MUST
> terminate or interrupt (as appropriate) a session established".  It
> seems that the range of resources that might be needed to establish a
> dialog is quite broad (we've already identified signaling processing
> capacity, media bandwidth, and UA facilities, and there are likely to
> be more), and so we need to allow a broad range of strategies for RP
> actors to free resources, with only the overriding constraint that the
> higher-priority request must not be blocked from being processed by
> resources consumed by a request of sufficiently lower priority.  (See
> section 4.9 describe how request priorities might be grouped and
> handled together.)

I'm not sure I understand. Are you suggesting a new behavior where the 
gateway puts the lower-priority call on hold and then later resumes it? 
(I don't know what you mean by "interrupt".)

> 
> - In section 4.7.2.2, the last sentence might read better as "However,
> the requirements in [RFC3261] regarding the frequency of provisional
> messages still apply, in order to keep each session set-up active
> until successful or rejected."

This is indeed an odd sentence; fixed.

Again, thanks for your comments.

Henning