Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps

From: Janet P Gunn <[email-masked]>
Date: Sat, 6 Nov 2004 23:24:39 -0500

Yes, it would be better to have the namespace define the behaviors.

However, I accept that there may be some general bounds on the behaviors.

It is linking them together in fixed combinations that I object to.

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.
----------------------------------------------------------------------------------------

                      Dean Willis                                                                                              
                      <dean.willis             To:      Janet P Gunn/FED/CSC@CSC                                               
                      @softarmor.com>          cc:      [email-masked], [email-masked], [email-masked], Darren E              
                                               Pado/FED/CSC@CSC, Saud Negash/FED/CSC@CSC, [email-masked], Richard F           
                      11/06/2004 08:12         Kaczmarek/FED/SC/CSC@CSC, [email-masked], [email-masked],                 
                      PM                       [email-masked], [email-masked], Dennis Q Berg/FED/CSC@CSC            
                                               Subject: Re: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit   
                                               for ets and wps                                                                 

Janet P Gunn wrote:
>
>
>
> One of the changes in the draft-ietf-sip-resource-priority-05 is the
> definition of 3 modes, strict, semi-strict, and loose, and the assignment
> of each defined namespaces to a particular mode.
>
> The definition of the mode involves several distinct behaviors
>

Would it be better to have each namespace definition fully define the
behavior of that namesapce, rather than trying to have some "templates"
that could be re-used by multiple namespaces?

--
Dean

_______________________________________________
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: Janet P Gunn <[email-masked]>
Date: Sun, 7 Nov 2004 17:27:54 -0500

To clarify, NCS "owns" (and it is in quotes on purpose) the GETS and WPS
programs.  As such, it will presumably be the first user of the ets and wps
namespaces.  But, no, it doesn't "own" (either literally or figuratively)
the namespaces.

Janet

                                                                                                                               
                      "Ken Carlberg"                                                                                           
                      <carlberg                To:      Janet P Gunn/FED/CSC@CSC                                               
                      @g11.org.uk>             cc:      <[email-masked]>, Darren E Pado/FED/CSC@CSC, Dennis Q              
                                               Berg/FED/CSC@CSC, <[email-masked]>, <[email-masked]>,                        
                      11/07/2004 09:16         <[email-masked]>, <[email-masked]>, <[email-masked]>, Richard F    
                      AM                       Kaczmarek/FED/SC/CSC@CSC, Saud Negash/FED/CSC@CSC, <[email-masked]>,              
                                               <[email-masked]>                                                               
                                               Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit   
                                               for ets and wps                                                                 

> I would prefer a strict or semi-strict mode because these provide
feedback in
> case: a) a misconfigured UA sends the wrong namespace.priority, and/or b)
> initial selection of a server/proxy that does not support the desired
> namespace.  The former is quite possible given an ability (and possibly,
> necessity) of the user to configure their own device to support the given
> namespace.value combination.
>
> [JG] Before posting this, I checked with Dr. Fonash (head of NCS, which
> "owns" GETS and WPS).  He was very clear about wanting "If the SIP
element
> does not recognize the namespace (wps or ets) it should pass it on
without
> acting on it, rather than rejecting it."

ok.  Dr Fonash now has additional input on the subject given my previous
email;
if there is no feedback, then the sender hopes everything is working fine.
further, it will continue to use an R-P capable proxy with no feedback from
the
INVITE indicating that it does not support that particular namespace/value.

Keep in mind that as it states earlier in the draft, the R-P header is
ignored
(assuming proper implementation) by those proxies (eg, the installed base)
that
do not support the new R-P header.  As a sidenote, our current
implementation
of the R-P header follows the MAY portion of the draft and does not send
back
hints of what are acceptable priorities.

Also, when you say the NCS "owns" GETS and WPS, are you refering to the
systems
or the namespace?  If its both, then I have my doubts about the latter.  I
see
no association of the NCS with WPS or GETS in the draft and it would seem
that
initial "ownership" of those namespaces, as well as the others like ETS,
lies
with the authors of the draft.  (I'll be happy to be corrected on that
assumption).

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 08 Nov 2004 00:13:01 -0600

comments in-line below

At 11:47 PM 11/6/2004 -0500, Janet P Gunn wrote:
>From: "Ken Carlberg"
> > Unfortunately, this  (semi-strict) is NOT the behavior desired for the
>ets
> > and wps namespaces.

Janet - I like your list. It is quite valuable because it gives very good 
points for discussion.  As Ken has stated already, a couple of issues from 
your list (I believe) are already addressed within this current version.

> >
> > The behavior desired for the ets and wps namespaces are
> > 1 RPH is optional (semi-strict and loose)

got it

> > 2 SIP element ignores a namespace it does not recognize (loose)

To this, remember the ID does not say to "fail" the call, just that 
Request. This is one way to inform the calling UAC to know it included a 
namespace or priority value that was not recognizable (meaning not 
ets.0/1/2/3/4 or wps.0/1/2/3/4).

There is no way to inform the UAC of this issue within the SIP Request 
(with the bad namespace.priority-value) without failing the request. 
Meaning, there can be no preferential treatment without the sending element 
being told so. SIP doesn't have a "pass, but this wasn't a good choice" 
provisional response like other protocols.

To the user, they might not notice several SIP Request failures, the person 
is merely waiting for the call to be set up (still under a second).

>I would prefer a strict or semi-strict mode because these provide feedback
>in
>"owns" GETS and WPS).  He was very clear about wanting "If the SIP element
>does not recognize the namespace (wps or ets) it should pass it on without

again - this doesn't mean the call attempt has failed and the user needs to 
dial again  - which is one way to read what you wrote. The text in this doc 
clearly needs to not call for failing the call in the ets/wps use-case 
because of a bad namespace or priority-value.

Ironically this is where the A-R-P header would be handy, if it didn't 
reveal to everyone who purposely or inadvertently included a bad or unknown 
RP header.

> > 3 The content of the error message should not reveal (to the end user)
>the
> > valid values for that namespace (strict)
>
>section 4.5 of the drafts states:
>
>    If the UAS understands the resource value, but refuses to honor the
>    request with elevated priority for this particular user, it returns
>    the 403 (Forbidden) response code.  It MAY include the list of
>    resource values that the user is allowed to use in the
>    'Accept-Resource-Priority' response header field.
>
>The "MAY" is the critical term.

I feel this MAY answers your concern - as Ken points out. You may mandate 
vendor's equipment be able to be configured to *not* send the A-R-P in this 
case. That is a useful marketing requirement.

>My understanding would be that this
>decision
>is a local policy issue.  Outside of that I personally don't see a problem
>with
>providing "hints" of accepted values under the context that they can only
>acted
>upon by authorized users.  Informing the user of the acceptable set of
>priorities does not bypass or circumvent the need for proper authentication
>credentials.
>
>[JG]I am not as concerned about this case (valid namespace.valid value -
>just not authorized).

I would think this is of concern - as anyone (literally) can be in this group.

>I am more concerned about the  error message when
>the namespace, or value are not recognized.  But if ets and wps operate
>with the behavior "SIP element ignores a namespace it does not recognize",
>half of that goes away.
>
>[JG]I am still not entirely sure about the desired behavior for the other
>half- (valid namespace.invalid value).  But I suspect that it would be
>better to
>a) Reject the message
>b) NOT return the list of valid values.

I consider this to be the case every time a message is not accurate, but 
want to discuss it with you to tease out any "ships in the night" scenarios 
we're missing

>[JG] I do not think that the full loose mode as defined (if the SIP element
>gets (valid namespace.invalid value) it processes the message as if it had
>no RPH) is the right approach.

nor do I

>I think these messages should be rejected,
>and get an error message.

I agree

>[JG]But I am open to other approaches.

we have time to talk

> > 4 SIP messages that include the RPH with the ets or wps namespaces should
> > include the authorization header (or equivalent mechanism) (semi-strict)

this should be self evident in public networks....

> > 5 Precedence (queueing) is generally the means of providing priority, but
> > exemption from network management controls, for instance call admission
> > within an IP domain, when a "regular" call would not be admitted, is also
> > needed.  Pre-emption is not used.  (semi-strict "plus more")

I do not understand what you have written above, can you rephrase please?

>the "plus more" would seem to be a product of local policy
>
>[JG] Agree.  While it doesn't explicitly state it, the document leads you
>to believe that queueing is the only behavior permitted in semi-strict
>mode.

This is stated a couple of times in the doc, including in the IANA section 
in the table

> > 6 There is no a priori requirement to use, or not use, the "Require"
> > header field.
>
>isn't this addressed in section 4.3.2 below?  or am I missing something?
>
>    If the request includes a 'Require' header field with the
>    'Resource-Priority' option tag, a UAS MUST follow the strict or
>    semi-strict mode rules, otherwise UAS and proxies MUST operate in
>    loose mode.
>
>
>[JG]I guess I wasn't clear.   I simply meant that there wasn't a concern
>about the "require" header itself, independent of the
>strict/semi-strict/loose mode.  Once that is "right", the approach to the
>"require" header will follow

hmmmm

The "Require" header is to mandate that SIP Responses use the header as is 
(copied from request to response without change). If ever there is a case 
needed in which preferential treatment is within the processing of SIP 
elements (such as Proxies), knowing there will always be more than one SIP 
message necessary to complete a transaction - meaning both Request and 
Response will need to be RP marked for preferential treatment for the 
session/transaction to be given priority over other transactions.

To put this simply, if the INVITE is consistently moved to the head of the 
line in all SIP elements between UAs 1 & 2, and the 200 OK is 
slowed/delayed or lost in the congestion of one or more Proxies, the call 
will not be established. In this case, the INVITE, 200 OK and ACK will need 
the RP indication to gain the preferential treatment of that domain; and 
any other messages within that transaction will require it too (such as 
183, PRACK and UPDATE messages if RFC 3312 Preconditions were to be 
required to set up, say RSVP between endpoints).

>-ken

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 8 Nov 2004 09:13:01 -0500

James said,

>[JG]I am not as concerned about this case (valid namespace.valid value -

I would think this is of concern - as anyone (literally) can be in this
group.

I was thinking that it was of less concern because it is someone who
already knows the valid namespace and value.

But you are right, if it is someone who is randomly or systematically
trying namespace/value combinations, we just told them "you got a hit".
So I take it back about being less concerned.

Janet

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 08 Nov 2004 09:20:17 -0600

>already knows the valid namespace and value.

the RPH document is in the public domain - and we are having a fairly 
public discussion about it (and its ramifications). Curious eyes are 
probably reading this too.

;-)

cheers,
James

                                *******************

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 8 Nov 2004 10:29:32 -0500

OK, to turn it around. If "curious eyes" already can know the valid
namespace/value combinations, simply by navigating the ietf site, why
bother to hide it in the protocol messages? At least for the "published"
namespaces.

                                                                                                                               
                      "James M. Polk"                                                                                          
                      <jmpolk                  To:      Janet P Gunn/FED/CSC@CSC                                               
                      @cisco.com>              cc:      [email-masked], "Ken Carlberg" <[email-masked]>, Darren E     
                                               Pado/FED/CSC@CSC, Dennis Q Berg/FED/CSC@CSC, [email-masked],                   
                      11/08/2004 10:20         [email-masked], [email-masked], [email-masked], Richard F          
                      AM                       Kaczmarek/FED/SC/CSC@CSC, Saud Negash/FED/CSC@CSC, [email-masked],                
                                               [email-masked]                                                                 
                                               Subject: RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a   good fit 
                                               for ets and wps                                                                 

;-)

cheers,
James

                                *******************

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 8 Nov 2004 12:51:10 -0500

James said
---

---
OK, please educate me.

If it "fails" that request, but doesn't "fail" the call, does that mean
that the UAC resends the request without the RPH?

If that is what it means, then, for a call which originates in a SIP/IP
domain, but goes to the PSTN, it would reach the PSTN gateway with no
indication that it was entitled to special treatment in the PSTN.

While that is better than failing the call, it still isn't the desired
behavior.

If there is a way that the SIP element can "fail the request but not the
call", AND make sure that the appropriate RPH namespace and value (and
authentication)  get to the PSTN gateway, then it might be OK.

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 8 Nov 2004 13:37:27 -0500

James said:
---

Agree- my point was that this is part of "semi-strict" that IS desirable,
even if we want the treatment to be "loose" in terms of  treatment of an
unrecognized namespace.

Consider this  policy for a specific namespace
 - If the SIP element doesn't recognize the namespace , it ignores the
header (doesn't give any special treatment here, but passes it on if
appropriate- e.g., to a signalling gateway)
-  If the SIP element recognizes the namespace, but there is an invalid
value, the request (and the call) are rejected
-  If the SIP element recognizes the namespace, and the value, but the
authentication header doesn't pass muster, the request (and the call) are
rejected
-  If the SIP element recognizes the namespace, and the value, AND
authentication header is "good", then the request (and the call) get
special treatment here, and the RPH is passed on if appropriate- e.g., to a
signalling gateway.

Is this policy permitted by the current draft?  My reading is that this
policy is not permitted.

Section 4.3.2 says:
"When handling requests with unknown namespaces or priority values,
   elements can operate in one of three modes, "strict", "semi-strict"
   and "loose"."
and
       "If the request includes a 'Require' header field with the
   'Resource-Priority' option tag, a UAS MUST follow the strict or
   semi-strict mode rules, otherwise UAS and proxies MUST operate in
   loose mode."

Since the policy described above does not fit "strict", "semi-strict" or
"loose", it would seem to be forbidden.

Am I missing something?

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 8 Nov 2004 14:13:43 -0500

James said:
___

___

OK. I'll try again (and I combined two different cases, which didn't help
the clarity).

Section 7 says
      "The ets and wps namespaces operate with preferential treatment but
   without preemption.  These namespaces operate under a policy of
   provide preferential treatment to higher relative priority requests
   instead of processing lower relative priority requests.  Messages
   are not preempted, or deleted, except under extreme loads in which
   all available processing is taken up with higher priority messages.

   An example of this is at a IP/PSTN gateway with all of the PSTN side
   circuits utilized.  In strict mode one of the lower priority
   circuits would be freed using preemption.  In semi-strict mode, the
   SIP request May be granted access to the next available circuit
   based on this header's presence in the authorized message,
   regardless of how many other "regular" requests are received at that
   gateway."

First, is that "May" supposed to be "MAY" or "may"?

But more significantly, the desired behavior at the PSTN gateway is more
complicated than what you describe;

-At an IP/PSTN gateway with all of the PSTN side circuits utilized, not
only would the request with the appropriate RPH be granted "the next
available circuit" but if several requests with the appropriate RPH arrive,
they would be queued for the next several circuits to become available.

- At an IP/PSTN gateway, "restrictive network management controls" may be
active, even if  not all PSTN side circuits are utilized.  (An example of
a "restrictive network management control" is "call gapping" in which only
one call every x seconds is accepted.  "Call gapping" is usually made
active as a response to overall network congestion, a bit like ECN in an IP
network).  If restrictive network management controls are active, a request
with the appropriate RPH would be granted an available circuit, even if
less than x seconds had passed since the last call was admitted.

- At an IP/PSTN gateway, if the request has the appropriate RPH, certain
parameters (CPC and/or Precedence) would be set in the ISUP IAM.

I don't see anything in the RPH ID that prevents this "additional"
functionality, so this comment doesn't necessarily mean anything needs to
change.  It was just that the current text is a little misleading in that
it seems to imply that "access to the next available circuit" is all that
is intended.

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 8 Nov 2004 14:38:27 -0500

James said:
___

hmmmm

OK, I was definitely missing the point here.  I was looking at it simply as
the "require" header being the trigger for "strict, or semi-strict" mode
(as opposed to loose mode).

Now that you have explained that it ALSO triggers "setting RPH in the
response, and other associated messages", I would have to say that I DO
want the require header.

In that case , I am unhappy with
      "'Strict' and 'semi-strict' are identified by the
   presence or absence of a 'Require' header field with the 'Resource-
   Priority' option tag.  'Loose' mode does not contain a Require
   header."

Is there some reason we can't have "Loose" and"Require"?

Janet

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 08 Nov 2004 14:35:58 -0600

comments below

>that the UAC resends the request without the RPH?

yep

>While that is better than failing the call, it still isn't the desired

SIP has no mechanism other than failing the request to indicate something 
was wrong. SIP cannot at this time, allow a message to be processed by a 
SIP element (say a proxy) and have that proxy server send the packet 
towards the UAS *and* send some form of a provisional reply to the UAC 
telling it to correct some aspect of itself in future such messages.

>authentication)  get to the PSTN gateway, then it might be OK.

A proxy can replace the field in a header, in this case to a more 
appropriate namespace.value - but I do not believe you will want this to 
happen without authentication of the user at the UAC (which would be in the 
form of a 4XX failure - which you are objecting to.... hmmmm)

cheers,
James

                                *******************