Re: [Sip] Introducing the "new bis" -draft-ietf-sip-rfc2543bis-05

["James M. Polk" <[e-mail]>]

Henning

Comments throughout

At 03:50 PM 11/6/2001 -0500, Henning G. Schulzrinne wrote:
>"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'd like to *not* call it MLPP due to the baggage that acronym carries already

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

Agreed with the larger doc specifying MLPP functionality in IP and a much
smaller doc doing the new header.
>
>> 
>> 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)
>
>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), 

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
>issue and should be dealt with outside of SIP or SIPPING, as it will
>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
>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?
>
>-- 
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

*************************************
"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