Subject: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority Parameters

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 14 Sep 2005 12:38:59 -0500

Hi All,

Ken Carlberg suggested in
http://www1.ietf.org/mail-archive/web/nsis/current/msg05274.html that
H.460.4/H.323 call priority elements be added as another priority
parameter in the QSPEC draft
(http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-05.txt). 

In response, I suggested a possible mapping in
http://www1.ietf.org/mail-archive/web/nsis/current/msg05284.html.

An Nguyen voiced support in
http://www1.ietf.org/mail-archive/web/nsis/current/msg05290.html. 

To determine consensus regarding adding the H.460.4/H.323 priority
parameters, John suggested to post the pros and cons to the list, and
people can express their opinions on to whether to include these
parameters or not.

On the pro side:

1. Ken Carlberg: 'Microsoft's use of H.323 for its Netmeeting software,
as well as Cisco's support for H.323 (in the form of gatekeeper's and
the like), would seem to give some substantial weight to the protocol --
enough so that its not just a paper-only specification. Over time, SIP
may take over, but I think that kind of speculation would be outside the
scope of this working group.'
2. An Nguyen: 'From an interoperability perspective, we want hooks in
the NSIS signaling architecture so that H.323 can still be supported.
And interoperability is one of our 14 requirements.'

On the con side:

1. H.323 is a legacy technology (several have expressed this concern).
2. Cornelia brought up the issue at the IETF-63 NSIS meeting, where:
a. Henning Schulzrinne expressed the opinion to not include such legacy
parameters: 'do we need the H.460.4/H.323 elements; deployment is going
down rather than up; could they define these later? there is always one
more.'
b. Cornelia related that 'the general mood (at IETF-63) was to not
include even more parameter values in the QSPEC.'

Please express your opinion RE including the H.460.4/H.323 priority
parameters in the QSPEC I-D, so consensus can be determined for or
against.

Thanks,
Regards,
Jerry

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 14 Sep 2005 14:55:06 -0400

Layered architecture does NOT mean that there will NOT be any
inter-layer communications/dependency (although the word "import" is a
strong one).

The actual point is this:

1. SIP is an application/call layer signaling protocol that will express
priority at the application/call level. It can differentiate between
different call types. In turn, it may, but not always, translate the
priority to RTP media of one call versus other ones.

2. The question is this: How can a call layer priority be mapped to that
of the IP layer packets? 

Thanks,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2005 2:38 PM
To: Roy, Radhika (AEAD)
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: Re: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority
Parameters

Frankly, it strikes me as strange at best to import ANY specific  
application-level priority/preemption parameters directly into NSIS.  
What about SAP (business applications) for year-end-closings? or  
flows set up by RTSP? We really want the World-cup finals to not be  
messed up, right?!

What happened to layered architecture?

Cheers, Dave.

On Sep 14, 2005, at 2:28 PM, Roy, Radhika ((AEAD)) wrote:

> Hi, Jerry and all:
>
> Per IETF perspective, let us keep our focus on IETF application like
> SIP. SIP will have different perspective in standardizing the priority
> parameters. Let us wait for completion of the present SIP works on
> priority.
>
> So, we do not need to focus on non-IETF legacy applications to support
> their needs for now. No need to over burden the present spec as  
> Henning
> indicated.
>
> Best regards,
> Radhika
>
> PS: Other drafts can be written for taking care of interoperability
> between IETF and non-IETF applications in using NSIS QOS signaling
> schemes.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of
> Ash, Gerald R (Jerry), ALABS
> Sent: Wednesday, September 14, 2005 1:39 PM
> To: [email-masked]
> Cc: Ash, Gerald R (Jerry), ALABS
> Subject: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority
> Parameters
>
> Hi All,
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 14:12:02 -0500

>2. The question is this: How can a call layer priority be mapped to that

an API

>Radhika

cheers,
James

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Sep 2005 15:35:49 -0500

Radhika

A wondering comment below

At 03:27 PM 9/14/2005 -0400, Roy, Radhika \(AEAD\) wrote:
>API is only the half-baked solution if all entities are located
>physically at the same place.
>
>If the entities are located at different geographical locations, a
>protocol is needed.
>
>In any situation (API or protocol), the original problem remains the
>same as follows as mentioned in the earlier email:
>

Protocols aren't necessary when the communication is solely within the same 
device, as is the case you are describing (layer 7 and layers 3/4 within 
the same, for example, SIP UA). My answer remains, this is an API within 
that UA that has the ability to configure one layer based on what it 
received on another layer.

In your example #1, SIP can set the prioity level of a call at Layer 7 to 
"high". The receiving UA can interpret that Layer 7 priority "high" as an 
NSIS priority level other than normal. This is not done by a new or 
existing protocol, but in an API within the UA.

Now, I grant you, consistency would be nice in this regard, but this is a 
matter of policy of the domain the UA is attached to.

Using Diffserv as an example:

- A "normal" priority SIP INVITE will send RTP from that UA at DSCP 46 (EF)

- A "high" priority SIP INVITE will/could send RTP from that UA at DSCP 47 
(currently unused)

It would be nice if the two UAs used the same priority (equivalent) to send 
RTP packets - but this is of local policy, and highly deterministic of 
domain policy for consistency.

RSVP conveyed the preference DSCP in the DCLASS Object document RFC 2996. 
But this is only one UA telling the other which DSCP it prefers is used. In 
this second UA's domain, "high" priority might be DSCP45. Diffserv allows 
remarking at borders too.

>Mapping problems of priority levels between media of different media of
>different call priorities need to be addressed to be more precise.

I disagree a protocol is needed. An Informational or BCP doc for guidance 
wrt NSIS is more appropriate, but this is still an API within the UA. And 
if you really want a protocol, COPS exists in which an PEP can communicate 
with a LPDP internal to the device (router in that case).

>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, September 14, 2005 3:12 PM
>To: Roy, Radhika (AEAD); [email-masked]
>Subject: RE: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority
>Parameters
>

cheers,
James

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

---

From: [email-masked]
Date: Thu, 15 Sep 2005 08:12:03 +0300

Jerry,

>Please express your opinion RE including the H.460.4/H.323 
>priority parameters in the QSPEC I-D, so consensus can be 
>determined for or against.

If priority, in general, is something that the QSPEC should
support, then we should support it.  However, I am less convinced
of the need to carry every application-level protocol bit & byte
for the sake of interoperability.  I think a cleaner design would
be to draft showing how  H.460.4/H.323 could use the QSPEC (with
priority parameters9 and map from the generic QSPEC parameter
to the specific H.460.4/H.323 parameter.

John

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 15 Sep 2005 08:48:53 +0100

jerry,

I think I agree with John, although to be honest I'm not sure
what the big deal is here. So far as I can tell, we are not
actually talking about *changing* the Qspec in any way, we
are just talking about "someone setting up a call with H.460.4
with call priority 'high' *might* like to use QSPEC priority
value 2" (or whatever). That sounds pretty close to an
implementation decision (like other API issues, in fact).

I'd prefer to see these mapping questions dealt with outside
the Qspec. Indeed, it's not just a question of "H460.4 priority in,
QSPEC priority value out": presumably, anyone implementing an
software using H460.4 has *already* made some decisions about
how to map priority expressed via their UI to H460.4 values, and
they may equally want to use those 'external' priorities to
select the value for the Qspec. So pinning down a fixed mapping
in the Qspec doesn't see appropriate; and if the mapping isn't
fixed, it probably doesn't matter too much where it is written.
(That is, we should be prepared to rely on the common sense
of the implementor, IMHO.)

robert h.

ps. all of this is quite independent of whether anyone uses
H460.4 any more. I think the same arguments would apply to 
other mapping questions, although that may be naivety on my part.

> Behalf Of [email-masked]
> Sent: 15 September 2005 06:12
> To: [email-masked]; [email-masked]
> Subject: RE: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 
> Priority Parameters
> 
> 
> Jerry,
>

---

From: [email-masked]
Date: Thu, 15 Sep 2005 10:39:53 +0200

Hello, 

>> support, then we should support it. 

Yes. I believe priority, in general, is something that the QSPEC should
support.

>> However, I am less convinced
>> for the sake of interoperability.  

Agreed.
Like others have argued already, application-level semantics of priority
should be kept out of the IP layer signaling protocol.
I believe this comment applies to H.460.4/H.323 priorities. But I
believe this comment applies equally to dsn priorities, to drsn
priorities, to Q.735 priorities, to ETS priorities, to WPS priorities ,-
which are currently specified as valid values inside the <Reservation
Priority> Parameter.

>> I think a cleaner design would

As a suggestion, perhaps a reasonable approach would to:
	1) identify what are the few fundamental network-related
"priority-capabilities" that are required by all these applications
	2) allow encoding of these fundamental network-related
priority-capabilities in QSPEC
	3) do not try encode anything application specific in the QSPEC
	4) for guidance, define a mapping between each application's
concept of priority and the QSPEC priority-capabilities.

For example, regarding 1), two fundamental network-related
priority-capabilities required by applications have been clearly
identified:
	- the first one is "preemption" whereby a new flow can displace
existing ones if needed. This is all covered by <Preemption Priority> &
<Defending Priority> Parameters. 
	- the second is "Admission Priority" whereby a new special flow
is not allowed to displace existing flows, but is allowed to carve into
some special pool of resources which has been set aside for these
special flows (i.e. cannot be used by non-special flows).
It would be very useful if folks could identify the additional
fundamental network-related priority-capabilities that may be required
by applications beyond the two above.

Assuming for now that "preemption" and "Admission Priority" are the only
two network-related priority-capabilities, a suggestion would be that
the QSPEC:
	- keeps the <Preemption Priority> & <Defending Priority>
Parameters currently defined exactly as they are.
	- keeps the <Admission Priority> Parameter (ID=12)
	- simply drops the <RPH Namespace> Parameter (ID=13) and the
<RPH Priority> Parameter (ID=14)

Then one may:
	- produce a BCP/Informational which describes how the DSN
priorities get mapped (e.g.):
		dsn.Routing--->		preemption=0, Defending=0,
Admission=Low
		...
		dsn.flash-override--->	preemption=100, Defending=100,
Admission=Low

	- produce a BCP/Informational which describes how the
H.460.4/H.323 priorities get mapped (e.g.):
		emergencyAuthorized--->	preemption=0, Defending=0,
Admission=High
		emergencyPublic--->	preemption=0, Defending=0,
Admission=High
		high--->			preemption=0,
Defending=0, Admission=Medium
		normal--->			preemption=0,
Defending=0, Admission=Low

No?

Cheers

Francois

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Thu, 15 Sep 2005 09:35:29 -0400

James:
 
Let me summarize whole discussion as follows:
 
1. Each layer has its own priority levels.
2. Each layer has dependency to convey the information that we call inter-layer communications. For example, SIP call signaling layer triggers RTP media layer, and RTP media layer invokes the TCP-UDP/IP layer packets.
3. During inter-layer communication many things are needed such as source-destination address for routing, QOS, and other including priority level.
 
The whole protocol developments are made in ways as if they are independent. Although it is true, but they are made in a way that completement each one of them. For example, the source and destination addresses expressed in the SIP/call layer are also conveyed to the IP/network/link layer.
 
No one can say that the SIP/call layer's addresses cannot be mapped into the IP/network/link layer for routing purposes.
 
The same arguments are applicable to all other parameters such as QOS, and others including priority levels.
 
However, the key argument is that each layer should express each parameter in a "generalized" way as if each belong to the semantic and syntax of its own layer. For example, SIP URL may be good enough to express the address in the SIP layer, but in IP layer, it needs to be expressed in IP addresses. A mapping is done between the two (e.g., a DNS server help us to do so, and we use a protocol for this, not API per se).
 
Similarly, the priority levels of the NSIS protocol layer are generic enough, as John and Robert explained, without being application-specifics (e.g., H.460.4/H.323 Priority, SIP layer priority), let us have it (again, it is NOT an "import" between the layers). Otherwise, let us make not application-specific priority levels in NSIS (if is application-specific, it would prefer SIP-specific from the IETF point of view).
 
With respect to usefulness of APIs and protocols, we already know. Let us NOT debate this here.
 
Best regards,
Radhika

________________________________

From: James M. Polk [mailto:[email-masked]]
Sent: Wed 9/14/2005 4:35 PM
To: Roy, Radhika (AEAD); [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: RE: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority Parameters

Radhika

cheers,
James

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

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Thu, 15 Sep 2005 09:35:46 -0400

Kindly the see the reply of James' email. You will all the answers.
 
Best regards,
Radhika

From: David R Oran [mailto:[email-masked]]
Sent: Wed 9/14/2005 6:44 PM
To: Roy, Radhika (AEAD)
Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS; [email-masked]
Subject: Re: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority Parameters

> If the entities are located at different geographical locations, a
Right, and we have two, RSVP and NSIS. The idea that we invent 
another one just to carry priority/preemption information is, excuse 
the bluntness, nuts.

> priority to RTP media of one call versus other ones.
No, it ALWAYS has to do this. The semantics of signaling and data 
transport are different. You can't derive one from the other. In 
fact, a call with high priority for audio might not necessarily have 
high priority for video - the video may be a "nice to have". 
Conversely, if I'm doing surveillance the video might be essential 
but the audio could be dropped without fundamental loss of capability.

> 2. The question is this: How can a call layer priority be mapped to 
Yes, and that is application specific, not protocol specific. These 
protocols are used for multiple applications. Building the mapping 
into the protocols or the standards is fundamentally the wrong thing 
to do.

> different call priorities need to be addressed to be more precise.
I disagree. Sorry if I cant' sugar-coat this...

Cheers, Dave.

>> 2. The question is this: How can a call layer priority be mapped to
>>
> that
>
>> of the IP layer packets?
>>
>
> an API
>
>
>
>> Thanks,
>> Radhika
>>
>
>
> cheers,
> James
>
>                                  *******************

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Thu, 15 Sep 2005 10:41:44 -0400

Hi, Francois:
 
I agree with you that you have provided elaborate pointers how the priority levels in the NSIS signaling protocol can be "generalized" (as John and Robert suggested) in view of application and network layer priorities.
 
It is a good start.
 
I would also add to this: To see the different priority levels suggested in the SIP draft (James and Henning can point further). In addition, QOS policy, and other protocols (e.g., RADUIS, DIAMETER) may, I am not sure, also point to priority levels that may directly/indirectly influence the NSIS signaling protocol related to resources.
 
Let us suggest that Jerry and all co-authors will look into those and provide a summary to this list whether or not NSIS priority levels can be "generalized' in its own semantics and syntaxes to meet the needs of the application and the network layer.
 
Best regards,
Radhika

From: [email-masked] on behalf of [email-masked]
Sent: Thu 9/15/2005 4:39 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] QSPEC Issue: Inclusion of H.460.4/H.323 Priority Parameters

Hello,

Agreed.

Then one may:

No?

Cheers

Francois