Subject: Re: [Sip] Comments on Resource Priority Header

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Mar 2002 20:28:04 -0500

> An implementation would already need to have a procedure to follow if it got
> a priority it did not understand, like defaulting to the lowest it knows. So

Indeed.

> if a new value were defined and an old implemenation received that new value,
> that is what it would do. It just seems too restrictive to say that a
> "domain" or network could never in the future add a new priority value.

> Granted, the proper use of that new value would require upgrading any
> equipment that might use the value in its processing, but then I suspect the
> same will be true for many other improvements/extensions to the protocol in
> the future. Isn't it true that the current situation is that a device must
> ignore any thing it doesn't understand, just like http?

Somebody (you?) argued that ignoring the value should not be the same as
having the lowest priority value. 

> 
> I guess the use of "SHOULD NOT" in the draft in fact indicates that it could
> be done, but it is not recommended, so I suppose this wording is acceptable.

I added wording that the UA MUST ignore Resource-Priority headers with
unknown values or name spaces. That seems to be common protocol behavior
in other cases. The only real difference is that one could imagine that
there are scenarios where certain Resource-Priority values are actually
*below* normal treatment, kind of like the scavenger QoS mechanism. I
don't know if any of the existing schemes have this behavior.

Frankly, I don't see this as a problem in practice. Almost all of these
namespaces will be inherited from some existing scheme, so the
likelihood that somebody suddenly adds a value is pretty low.

> Mike

_______________________________________________
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: [email-masked]
Date: Thu, 7 Mar 2002 08:38:07 EST

In a message dated 3/4/02 8:23:30 PM Eastern Standard Time, 
[email-masked] writes:

> > We don't have a lot of choice. It has to state what will happen to a call
>  > attempt if the priority value is not understood. A statement that it is
>  > treated as the lowest known value is about all that could be done. I 
don't
>  > see the value in defining a "default" other than the lowest.
>  
>  There are two choices:
>  
>  (1) If there's an unknown value, simply ignore the Resource-Priority
>  header. (Any unknown namespace will have to cause the RP header to be
>  ignored.)

I point I think I was trying to make before is there can't be an "igonre" 
case. Since the point of the information is to tell equipment how to treat a 
call setup, in an environment/network that uses this capability, every call 
attempt must have a designated treatment, whether explicitly signaled, or a 
"default" when not present. An unknown value is equivalent to no value, which 
must default to something (unless the call attempt is rejected).

Unknown namespace is another issue: I would expect the call to be rejected, 
since it is obviously someplace where it shouldn't be.
>  
>  (2) Treat unknown values as the lowest priority.
>  
>  The two are the same if and only if "no RP header = well-defined RP
>  value". I tend to think that that's a good general choice. I
>  intentionally say "well-defined", since it may not be the lowest value.
>  One could imagine a system where you can define a priority lower than a
>  normal, unadorned call. As a contrived example, imagine a gas meter
>  reader call, like the one my house gets around 10 pm each night, that
>  would label itself as "left-over". (As I mentioned, there is something
>  like that for IP QoS called scavenger service, or
>  worse-than-best-effort, which scrounges up the bandwidth crumbs left
>  over by BE traffic. Used for huge file transfers in Internet2.)
>  
>  From what I can tell, no such systems exist today, so this may be
>  academic.

No, I don't think it is academic. It is worth considering. The result is that 
an added item would be needed in resource-priority to designate which level 
is the default for each namespace and to include the action it says above. I 
don't know that this would be a "well-defined" value. It would be different 
in each domain (namespace). For the dsn namespace, it would be "Routine"; for 
the q735 namespace, it would be "4".

Mike