Subject: RE: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-0 5

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Nov 2001 17:27:12 -0000

I am unsure here as to whether we are trying to match apples and oranges. 

The MLPP values tend to get compared against each other and highest value
wins in terms of priority. Therefore they do need to be defined as a
sequence rather than a set. A high MLPP value can force a user with a lower
MLPP value to clear down.

That is not necessarily the case of those values that exist in the
rfc2543bis draft Priority header.

I believe we also have a current understanding that the value "Emergency"
represents an emergency call, i.e. 911 in USA speak, and this value has
nothing to do with MLPP usage in existing signalling systems.

By all means use the Priority header, but this may mean that we have to
expect repetitions to cater for different sets of values, and we may have to
have different rules in implementations depending on the set received.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Henning G. Schulzrinne[SMTP:[email-masked]]
> Sent: 	01 November 2001 0:45
> To: 	Rosen, Brian
> Cc: 	[email-masked]'; [email-masked]
> Subject: 	Re: [Sip] Introducing the "new bis" -
> draft-ietf-sip-rfc2543bis-05
> 
> "Rosen, Brian" wrote:
> > 
> > I have been, and am still very interested in being able to implement
> > what is called MultiLevel Priority and Pre-emption in SIP.  As you
> > may recall, Jim Polk has made several proposals on this subject.
> > 
> > The current priority levels are advisory, the values are not defined,
> > and the current definition allows additional tokens to be used. I would
> > like to propose that the next revision, bis-06 deprecate the current
> > token values and substitute the 791 values.  I believe that, as the old
> > ones are indeed advisory, that any existing implementations would not
> break.
> 
> I'm opposed to that. The original values reflect "human communications
> priorities", not network priorities. The RFC 791 priorities are
> 
>           111 - Network Control
>           110 - Internetwork Control
>           101 - CRITIC/ECP
>           100 - Flash Override
>           011 - Flash
>           010 - Immediate
>           001 - Priority
>           000 - Routine
> 
> Unless you work for the military, they are essentially meaningless to
> normal users. Anybody know what ECP is :-)?
> 
> Since we suffer no shortage of header names, I would suggest that we
> have two different sets, one new header for "communications resource
> priority" (based on RFC 791 and/or the ones suggested by Jim Polk) and
> the existing Priority header for "human precedence", using the existing
> naming scheme.
> 
> Usually, the two are closely related, but may not necessarily be. For
> example, most calls, from a network perspective, may be "Routine", but I
> may well consider it "High" priority for the receiving user.
> 
> I've heard that 791-style values are often assigned based on military
> rank, so it could even be that a four-star general makes a "non-urgent"
> call on a "Flash" circuit.
> 
> Changing names is not a good idea in general since existing
> implementations may translate them into local languages (and leave
> unrecognized names alone).
> 
> > 
> > If that is not acceptable, I'd propose that we ADD the RFC 791 tokens
> > to the existing tokens, with language explaining what happened.
> > 
> > Brian
> > 
> 
> > >
> > > Why was the list of priorities taken from RFC 2076 rather
> > > than from RFC 791?
> > > RFC 2076 was informational and copied the list from RFC 1327
> > > (which was
> > > obsoleted by RFC 2156), They addressed mapping between X.400
> > > and RFC 822, but
> > > RFC 822 did not mention any such values. RFC 791 (and
> > > appropriate existing
> > > telephony standards) should form the basis of the priority
> > > definition field
> > > in SIP.
> > >
> 
> 
> > > Also, there needs to be an explicit statement concerning the
> > > order of the
> > > present and the new values. There is no order specified for
> > > the current set.
> > > Different people would come to different conclusions about
> > > the relative order
> > > of "Routine" and "non-urgent". It needs to state that the
> > > current four values
> > > are in the descending order "emergency, urgent, routine, and
> > > non-urgent". The
> 
> Good idea. That clearly is needed for any set.
> 
> > > order of the 5 new values is as defined in RFC 791 and
> > > applicable standards.
> > > Also, there should be no defined relation between the current
> > > set and the new
> > > added set. It is not expected that they would be used
> > > together, but if they
> > > are, it is a local issue on how to handle them.
> > >
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> _______________________________________________
> Sip mailing list  http://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
> 

_______________________________________________
Sip mailing list  http://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 G. Schulzrinne" <[email-masked]>
Date: Tue, 06 Nov 2001 12:32:11 -0500

> nothing to do with MLPP usage in existing signalling systems.

Indeed. This is purely for the receiving end user. For example, a
suitably authenticated "emergency" message might override a
do-not-disturb call handling directive.

> have different rules in implementations depending on the set received.

These are all good arguments for creating a new header for MLPP. Header
names are cheap and it's not a good idea to mix different behaviors. As
I mentioned earlier, I may want something like

MLPP: Routine
Priority: Emergency

or other combinations.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Nov 2001 13:59:54 -0600

Henning

>I mentioned earlier, I may want something like

Do you recommend a new MLPP header, or one that is named something else that
can translate or correlate directly as a reference from another Doc having
broader Architecture scope (about MLPP and *not* in the SIP/SIPPING WG's)?

For instance, I took what you wrote earlier in this thread about a
Communications Resource Priority Header and worked it around in my head (with
all my other MLPP thoughts) and believe an MLPP-over-IP Arch doc could
reference this CRP Header (in a separate doc than bis) that happens to have
equivalent values without SIP or SIPPING limiting the use of this CRP Header
just for MLPP. That if another SIP Priority usage comes along sometime in the
future -- there's a chance that usage will merely utilize this CRP Header
(which is a modified version of RFC791's listing) or the existing Priority
Header.

Comments

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 06 Nov 2001 15:50:52 -0500

"James M. Polk" wrote:

> Do you recommend a new MLPP header, or one that is named something
> else that can translate or correlate directly as a reference from
> another Doc having broader Architecture scope (about MLPP and *not* in
> the SIP/SIPPING WG's)?

Yes, I would recommend a new MLPP header (not necessarily or even
preferably called MLPP, as that sounds more like multi-layer marketing
than describing its functionality...). If you pick up the RFC 791 terms,
"Precedence" seems like an appropriate name.

I'm usually in favor of small, modular documents rather than
monster-documents; I think the experience with the PacketCable/DCS
documents bears this out, in that splitting the documents helped to
focus discussion. Thus, it might make sense to have an overall document
describing how various features fit together to provide MLPP service
(e.g., relationship or lack thereof to precedence at the IP layer), and
a one-page draft describing the header.

> Communications Resource Priority Header and worked it around in my
> head (with all my other MLPP thoughts) and believe an MLPP-over-IP
> Arch doc could reference this CRP Header (in a separate doc than bis)

Yes.

> that happens to have equivalent values without SIP or SIPPING limiting
> the use of this CRP Header just for MLPP. That if another SIP Priority
> usage comes along sometime in the future -- there's a chance that
> usage will merely utilize this CRP Header (which is a modified version
> of RFC791's listing) or the existing Priority Header.

I think both bis and your CRP document-to-be-written should make the
distinction very clear: Priority is for handling by humans (or their
appointed software agents), CRP is for getting priority access to
traditional PSTN circuits. Priority access to IP capacity is another
issue and should be dealt with outside of SIP or SIPPING, as it will
involve resource reservation, diff-serv or other technologies. (For
example, this might be a use case for the new NSIS WG-in-formation.)
This is another reason to keep the issues separate.

Does that make sense?

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Nov 2001 17:08:06 -0600

Henning

Comments throughout

>"Precedence" seems like an appropriate name.

I'd like to *not* call it MLPP due to the baggage that acronym carries already

>a one-page draft describing the header.

Agreed with the larger doc specifying MLPP functionality in IP and a much
smaller doc doing the new header.
>appointed software agents), 

Here's where I'm missing the subtleties you write of: the existing "Priority is
for handling by humans" could mean many things here -- but I'm thinking from
the MLPP side looking into SIP (with this effort). 

With the CRP Header I know I want to designate 5 levels of Precedence that
Humans (users) can signal to the network for *that session* to receive the
perceived preferential treatment. This must be an administratively authorized
access to the higher levels (and not realistically authentication-based --
because that's not how it works today, nor do customers who want/have MLPP want
this additional oversight). I see the Registration process within SIP as
potentially augmenting the administration by enabling the UA to have access to
the levels the Register reply has in it for a given *known* user; and domain
defined for unknown users.

But what I just described above sounds/reads very much like what you stated
(above that) as for the existing Priority Header.

One additional Precedence level I would like to add is the CRITIC/ECP
(Emergency Call Priority -- I cheated and had to ask someone). This is for GETS
and other Governmental Emergency situations. Below is a link to the
Government's push to get preferential service and access (preemption?) in the
time of emergencies on cell networks (is VoIP next?). Scott Bradner mentioned
recently there might be another IEPS BOF (likely as a reaction to 9/11) in
SLC...

http://www.cnn.com/2001/US/11/06/rec.attacks.cellphones.ap/index.html

>CRP is for getting priority access to traditional PSTN circuits. 

For the seamless access in a hybrid IP/TDM network and the habits of these
users, I know CRP will be for access to the non-IP circuits of an MLPP Domain.
But I don't understand its use in IP extends several hops before accessing
those circuits, and the different role the user would play relative to the
existing Priority Header.

>Priority access to IP capacity is another
>involve resource reservation, diff-serv or other technologies. 

I agreed completely here and am writing a separate, much larger doc for this --
but need the ability to integrate the User enabled precedence choice upon
picking up the handset in SIP... hence my efforts to get a new header -- and
you have given me a great opportunity with the CRP header to fit MLPP and GETS
requirements within the SIP scope into a single small doc, while leaving the
main explanation of functionality to another doc.

>(For

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 06 Nov 2001 18:37:34 -0500

"James M. Polk" wrote:

> I'd like to *not* call it MLPP due to the baggage that acronym carries

Good - one less fun & entertaining argument about header names...

> Here's where I'm missing the subtleties you write of: the existing
> "Priority is for handling by humans" could mean many things here --
> but I'm thinking from the MLPP side looking into SIP (with this
> effort).
> 
> With the CRP Header I know I want to designate 5 levels of Precedence
> that Humans (users) can signal to the network for *that session* to
> receive the perceived preferential treatment. This must be an
> administratively authorized access to the higher levels (and not
> realistically authentication-based -- because that's not how it works
> today, nor do customers who want/have MLPP want this additional
> oversight). I see the Registration process within SIP as potentially
> augmenting the administration by enabling the UA to have access to the
> levels the Register reply has in it for a given *known* user; and
> domain defined for unknown users.

This seems like an implementation decision. If one domain wants to
require biometrics to get higher CRP levels and another allows any
private first class to get the highest level, that's their (respective)
problem.

> 
> But what I just described above sounds/reads very much like what you
> stated (above that) as for the existing Priority Header.

Let me try again: There are two related, but different priorities. Both
are inserted by the UAC (or a proxy on the user's behalf, e.g., if the
call originates from a PSTN phone). I suspect that only CRP will
actually be set by a PSTN gateway, but that's unimportant.

The current Priority header designates the priority the receiving human
being should attach to the incoming call. Typically, this information
will be displayed to the user, be it visually, with a different ring
tone (e.g., a siren for an emergency call...) or flashing lights.

It has nothing to do with network resources. In other words, any proxy
along the way shouldn't care one wit about Priority, with one possible
exception. The user might want to have its proxy use the Priority
information to make call routing and rejection decisions, purely based
on the availability of the user for certain kinds of communications.
This is why CPL knows about Priority.

The model is pretty much exactly as it is for email: Email marked with
higher priority doesn't get delivered any faster, but I can sort by that
priority. (That all high priority messages are spam is another issue I
won't get into...)

> (Emergency Call Priority -- I cheated and had to ask someone). This is
> for GETS and other Governmental Emergency situations. Below is a link
> to the Government's push to get preferential service and access
> (preemption?) in the time of emergencies on cell networks (is VoIP
> next?). Scott Bradner mentioned recently there might be another IEPS
> BOF (likely as a reaction to 9/11) in SLC...
> 

Indeed, this is one aspect. Before I get dinged by somebody on this:
Generally, I think network resources should be reserved at the network
layer, not in an application-specific way. But sometimes this isn't as
clear cut, particularly if parts of the path are non-IP or if some
access control at the application layer is involved.

> For the seamless access in a hybrid IP/TDM network and the habits of
> these users, I know CRP will be for access to the non-IP circuits of
> an MLPP Domain. But I don't understand its use in IP extends several
> hops before accessing those circuits, and the different role the user
> would play relative to the existing Priority Header.

Does the above help? Again, in short:

- Priority: human resources
- Precedence: (non-IP and maybe under some circumstances IP) network
resources (including proxy and other signaling resources), including
maybe access to the air interface, if the air interface is service-aware
(i.e., in some 2.5G and early 3G settings)

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Nov 2001 18:45:32 -0600

Henning

At 06:37 PM 11/6/2001 -0500, Henning G. Schulzrinne wrote:
>Does the above help? 
I understand now -- Thank you very much

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems