Subject: [Sip] comments on draft-ietf-sip-resource-priority-08 and draft-ietf-s ipping-reason-header-for-preemption-02

From: "GOLDMAN, STUART O (STUART)" <[email-masked]>
Date: Sun, 22 May 2005 14:43:50 -0500

----------------------------------------------------------------------------
The following comments are submitted on draft-ietf-sip-resource-priority-08:

Section 4.2 Rule 1 says "... If there are sufficient resources, treat the request like a regular SIP request and skip the remaining steps.  (This does not cause removal of the header fields.)"   Is authorization to be repeated at each node even within a given network or is it sufficient that the first node in the network perform it? If the first node is following rule 1, how would the subsequent node know if authorization had been performed or if the prior node had sufficient resources and skipped that step?

Section 4.3 says "Following standard SIP behavior, if a SIP request contains the  'Require' header field with the 'resource-priority' option tag, a SIP element MUST respond with a 420 (Bad Extension) if it does not support the SIP extensions described in this document.  It then lists  "resource-priority" in the 'Unsupported' header field included in the response."  If a SIP request contains the 'Require' header field with multiple proxies along the path and one of the proxies is not supported, is the 'resource-priority' header still applied to the remaining proxies?

In section 4.5.2, the process is defined for an RP actor to handle the priority request. Depending on implementations, some real-time services may be in weighted queues rather than priority queues and these CoS also may require multi-level priority handling. Shouldn't a similar process be applicable to weighted queuing also? Shouldn't priority signaling and processing be independent of how the routers handle the session packets in their queuing and scheduling mechanism?"

Section 4.7.1  paragraph 2 says "Upon receiving a 417 (Unknown Resource-Priority) response, the UAC MAY attempt a subsequent request with the same or different resource value.  If available, it SHOULD choose authorized resource values from the set of values returned in the 'Accept-Resource-Priority'." It would be useful to understand the criteria used by the UAC to request a different resource value from the set returned. It is not clear if an interoperability problem might exist in the absence of such criteria.
 
Section 4.7.3 para 3: Why does it say "SHOULD"? Intermediate elements cannot process the RPH unless the RPH is in the "outer" header. Is it correct that the RPH "MUST" be in the "outer" header if RPH is used?

Section 4.7.3 para 5: Perhaps this paragraph could be reworded to more clearly state its purpose. Is it correct that once an element sets or receives a RPH with a given r-value, it MUST NOT send a RPH with a different r-value for the same call?- it shouldn't matter how the proxy is implemented. If it is illegal for the UA to change the value, is the proxy then free to drop the message if it detects the change? Must it check for a change?

Section 12.1  Says that "New priority-values MUST NOT be added to existing namespace registries. The registration MUST describe, in the registration itself, how SIP elements should treat requests from that namespace in 'operation',   e.g., whether preemption or only preferential queuing are allowed. "   This seems to prohibit the later addition of  a new priority value to a namespace. If this is because of potential Interoperability problems, would it be possible to explain them? Is this wise given the possibility of the need for an addition should unforeseen event occur, and that the addition may need to occur rapidly? Is it wise to explicitly specify operations in the IANA registration as these may not be complete and may be modified/expanded in the future?

-----------------------------------------------------------------------------
The following comments are submitted on draft-ietf-sipping-reason-header-for-preemption-02.

Section 5

Perhaps this section could be reworded to better express that network preemption is a generic function that can be accomplished by various technical procedures rather than to presume it is  only  "text="RSVP Preemption"."

Stu Goldman

Bell Labs   -  Lucent Technologies

5531 E. Kelton LN

Scottsdale,AZ 85254

623-582-7136 voicemail  602 493 8438 home office

_______________________________________________
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 17:14:27 -0400

I'm working through the

GOLDMAN, STUART O (STUART) wrote:
>     Section 4.2 Rule 1 says "... If there are sufficient
>     resources, treat the request like a regular SIP request and skip
>     the remaining steps.  (This does not cause removal of the header
>     fields.)"   Is authorization to be repeated at each node even within
>     a given network or is it sufficient that the first node in the
>     network perform it? If the first node is following rule 1, how would
>     the subsequent node know if authorization had been performed or if
>     the prior node had sufficient resources and skipped that step?

This would presumably depend on each deployment and I don't think the 
document is the right place to architect SIP 
authentication/authorization requirements. The document mentions (in the 
Security Considerations) section RFC 3325 as an example, which would 
imply one-time authentication at the "edge" of the trusted network.

> 
>     Section 4.3 says "Following standard SIP behavior, if a SIP request
>     contains the  'Require' header field with the 'resource-priority'
>     option tag, a SIP element MUST respond with a 420 (Bad Extension) if
>     it does not support the SIP extensions described in this document. 
>     It then lists  "resource-priority" in the 'Unsupported' header field
>     included in the response."  If a SIP request contains the 'Require'
>     header field with multiple proxies along the path and one of the
>     proxies is not supported, is the 'resource-priority' header still
>     applied to the remaining proxies?

I'm afraid I don't quite understand this question. In SIP, 'Require' 
only applies to UAs, not proxies. Proxies would use 'Proxy-Require', as 
noted (and not recommended).

I'll swap 'SIP element' with 'SIP UA', for additional clarity.

> 
>     In section 4.5.2, the process is defined for an RP actor to handle
>     the priority request. Depending on implementations, some real-time
>     services may be in weighted queues rather than priority queues and
>     these CoS also may require multi-level priority handling. Shouldn't
>     a similar process be applicable to weighted queuing also? Shouldn't
>     priority signaling and processing be independent of how the routers
>     handle the session packets in their queuing and scheduling mechanism?"

I don't understand your reference to weighted queues. As noted early in 
the document, RPH does not address IP-level routing and switching (or 
queueing) at all, but maybe you're referring to something else? Queues 
only refer to the waiting requests, not anything related to packets.

> 
>     Section 4.7.1  paragraph 2 says "Upon receiving a 417 (Unknown
>     Resource-Priority) response, the UAC MAY attempt a subsequent
>     request with the same or different resource value.  If available, it
>     SHOULD choose authorized resource values from the set of values
>     returned in the 'Accept-Resource-Priority'." It would be useful to
>     understand the criteria used by the UAC to request a different
>     resource value from the set returned. It is not clear if an
>     interoperability problem might exist in the absence of such criteria.

Since all such values returned to the UAC are, by definition, valid, I'm 
not sure what interoperability issue you would anticipate or what 
guidance you would suggest. Presumably, the UAC would pick values that 
it is authorized for and that "make sense", from an operational perspective.

>      
>     Section 4.7.3 para 3: Why does it say "SHOULD"? Intermediate
>     elements cannot process the RPH unless the RPH is in the "outer"
>     header. Is it correct that the RPH "MUST" be in the "outer" header
>     if RPH is used?

No. If you only want a UAS to inspect the RPH, putting it in the "inner" 
layer is just fine.

I rephrased as " MUST also be placed in the "outer" message if the UAC
would like proxy servers to be able to act on the header information."

I hope this makes this more explicit.

> 
>     Section 4.7.3 para 5: Perhaps this paragraph could be reworded to
>     more clearly state its purpose. Is it correct that once an element
>     sets or receives a RPH with a given r-value, it MUST NOT send a RPH
>     with a different r-value for the same call?- it shouldn't matter how
>     the proxy is implemented. If it is illegal for the UA to change the
>     value, is the proxy then free to drop the message if it detects the
>     change? Must it check for a change?

To avoid misunderstandings, paragraph 5 is

"If a stateful proxy has authorized a particular resource ..."

Thus, it only refers to those proxies and responses. It does not say 
anything about changing the r-value mid-call.

I don't see the need to explicitly disallow changes in r-values. 
Clearly, an element that did something beyond just passing it on has to 
do "due diligence" (authenticate, etc.) to make this secure. Currently, 
the document treats initial and subsequent requests within a call the 
same; making changes here may have ripple effects elsewhere.

Clearly, your deployment may choose to disallow changes in priority 
values. I don't think interoperability is affected by whether you make 
this choice and I don't think we can exhaustively specify all such 
policy choices. For all I know, you might disallow certain priority 
values based on the length of the conversation...

> 
>     Section 12.1  Says that "New priority-values MUST NOT be added to
>     existing namespace registries. The registration MUST describe, in
>     the registration itself, how SIP elements should treat requests from
>     that namespace in 'operation',   e.g., whether preemption or only
>     preferential queuing are allowed. "   This seems to prohibit the
>     later addition of  a new priority value to a namespace. If this is
>     because of potential Interoperability problems, would it be possible
>     to explain them? Is this wise given the possibility of the need for

In earlier versions of the draft, we tried to solve this problem, and it 
became a mess, as it added more failure cases. Adding values after the 
fact would then lead to possible rejections of calls somewhere else, if 
not all elements have been upgraded, i.e., unreliable operation. Unless 
there is a strong reason to allow this, this just seems to add complexity.

>     an addition should unforeseen event occur, and that the addition may
>     need to occur rapidly? Is it wise to explicitly specify operations
>     in the IANA registration as these may not be complete and may be
>     modified/expanded in the future?

Is there evidence that such additions have "suddenly" occurred in the past?

Here, compared to more traditional networks, we have the advantage that 
if you want to upgrade your network to something new, you can define a 
namespace, with then well-defined behavior.

If there's a real need to solve the problem, we need to find a solution, 
but given past experience with this draft, I'm somewhat reluctant to add 
complexity unless there's a clearly established need.

To cite another possible interop problem: Say, you build your network to 
rely on proxies for authentication. The UAS adds a new priority level, 
but some proxy hasn't been upgraded yet. It will pass through the 
unrecognized level and bad things happen.

Henning