Subject: RE: [NSIS] Questions regarding <draft-baker-tsvwg-mlpp-that-works -01.txt>

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 7 Apr 2004 18:46:05 +0200

hi fred, 

thanks for your response. a quick question to better understand the
sip-based approach:

i thought that the preemption mechanism is also applicable for sip proxies
which handle a large number of calls. now, in emergency cases they might
need to drop certain calls. the 'resource-priority' element(s) could be used
for it. 

since architectures (such as the 3gpp) are also using sip as a qos signaling
protocol (together with some other mechanism) it seems to be reasonable to
compare these two approaches (at least at an abstract level). i might,
however, be totally wrong. 

the sip scenario you describe is somewhat different (and seems to concern
the end hosts -users only). what can we learn from
<draft-baker-tsvwg-mlpp-that-works-01.txt> (in particular with regard to
preemption)? the separation into a namespace and a priority value seems to
be useful. 

ciao
hannes

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2004 6:28 PM
> To: Tschofenig Hannes
> Cc: 'James M. Polk'; [email-masked]
> Subject: Re: [NSIS] Questions regarding
> <draft-baker-tsvwg-mlpp-that-works -01.txt>
> 
> 
> Tschofenig Hannes wrote:
> > i would like to add something to my question with regard to 
> the difference
> > between the sip based preemption approach
> > (draft-ietf-sip-resource-priority-03.txt) and the rsvp 
> preemption approach
> > (rfc2751)
> > 
> > draft-ietf-sip-resource-priority-03.txt defines a scheme based on : 
> > - enumerations of <'namespace' '.' 'priority value'> pairs.
> > 
> > rfc2751 defines a scheme based on: 
> > - a preemption priority 
> > - a defending priority 
> > - and a merging strategy
> > 
> > how do they match to each other? 
> > which approach would you suggest for the qos nlsp (or for 
> nsis in general)?
> 
> 
> I think you're comparing apples and orangutans.
> 
> The preemption question in SIP is between two calls to the 
> same device. 
> If Alice is calling Bob when Bob is talking with Carol, in some 
> circumstances you would like Bob and Carol to hang up and have Bob's 
> phone immediately ring with Alice's call. This is not a bandwidth 
> question, it is a question of the urgency of Alice's call vs the one 
> currently in progress.
> 
> In addition, if Alice is calling Bob and is using an unusual 
> DSCP (DISA 
> wants to use multiple DSCP values instead of a single EF code point), 
> Bob should be using the same DSCP value Alice does. The Resource 
> Priority header, by corelated configuration, tells Bob what 
> DSCP value 
> to use.
> 
> The question being looked at in capacity admission concerns 
> choices in 
> how a finite amount of bandwidth migh be used. If Alice calls 
> Bob at a 
> time that some bottleneck link is using all of the bandwidth it is 
> configured to use for that aggregate of applications (might 
> be voice or 
> video, or potentially other real-time applications), it might be 
> preferable for Carol and Dick's call to be dropped entirely 
> rather than 
> simply lose the equivalent of a call's bandwidth distributed 
> across all 
> of the ambient calls.
> 
> Capacity admission is a network layer question. The other, 
> whatever you 
> choose to call it, is an application layer question.
> 

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

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Fri, 9 Apr 2004 15:19:52 -0400

Hi, Fred:

We are in agreement.

The main points are as follows:

1. Applications level signaling schemes (e.g., NSIS protocols) need to
understand the implications between the call level priority (e.g., SIP)
vs. media (e.g., SDP) level priority.

2. The complexities for comparisons of different priority levels between
the circuit-switched PSTN network vs. Packet-switched IP network along
with the application level call signaling protocols (e.g., ISUP, SIP)
that are used.

In this way, we would help us to rationalize how we should address
different aspects of NSIS protocols.

br,
Radhika

-----Original Message-----
From: Fred Baker [mailto:[email-masked]]
Sent: Friday, April 09, 2004 2:02 PM
To: Roy, Radhika R, ALABS
Cc: Nguyen, An; Tschofenig Hannes; James M. Polk; [email-masked]
Subject: RE: [NSIS] Questions regarding

At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote:
>3. If SDP contains multiple media, how does RSVP will take of media
level 
>differentiation in priority in reservation of resources, if something
else 
>does not help in differentiating priority of each media?

I'm not the list moderator, but I'll say something that I'll bet the
list 
moderator is thinking: If this is an NSIS requirement, the point on
*this* 
list should be to ensure that NSIS (GIMP/NSLP) meets the requirement. I 
understand the working group to not so much be thinking about RSVP as a 
protocol to replace it, hopefully in a manner that is interoperable at
some 
level.

I'd suggest that discussion of the NCS/MLPP near-term operational 
requirements, which have wandered from SIP to SIPPING to IEPREP to
TSVWG, 
not be particularly brought here except to ensure that those needs will
be 
met by NSIS when NSIS is done.

---

From: [email-masked]
Date: Tue, 13 Apr 2004 09:25:49 +0300

Hi Fred & Roy,

Catching up after a long weekend:

> >3. If SDP contains multiple media, how does RSVP will take of media level 
> >differentiation in priority in reservation of resources, if something else 
> I'm not the list moderator, but I'll say something that I'll bet the list 
> moderator is thinking: If this is an NSIS requirement, the point on *this* 
> protocol to replace it, hopefully in a manner that is interoperable at some 
> level.

Agreed - MLPP should be discussed on TSVWG, generally - the point of discussing
it on NSIS is to see what, if anything, needs to be done with NSIS protocols
 
> requirements, which have wandered from SIP to SIPPING to IEPREP to TSVWG, 
> not be particularly brought here except to ensure that those needs will be 

Agreed.

thanks,
John

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Apr 2004 14:38:27 -0500

Sorry for the late reply to this message (real work got in the way  :-(

comments in-line

At 06:46 PM 4/7/2004 +0200, Tschofenig Hannes wrote:
>which handle a large number of calls.

The Resource Priority header is not intended to preempt SIP Requests or 
Responses (although someone could build a proxy to do this), but a Proxy 
could easy (conceptually at least) make processing decisions as to which 
messages to process before others (especially in times where the Proxy is 
approaching its own load capacity maximum).

>now, in emergency cases they might
>need to drop certain calls.

Several responses to this (from different situations):

1) Proxies don't generate the SIP BYE message unless the Proxy is a B2BUA 
(which means it isn't really a Proxy) - so Proxies (as of right now) don't 
have a good way of telling UAs that any call should be preempted/terminated

2) without the Proxy being Dialog Stateful (Via and Record Route headers 
placed into a session set-up message prior to the preemption event needing 
to take place), the Proxy has no way of knowing about the emergency nature 
of the new call(s) to preempt the older non-emergency calls. This is an 
architectural decision of a domain.

Remember, proxies are generally thought of as stateless, meaning they can't 
track down calls to preempt any because they don't remember them.

If the Proxy is only transaction stateful (only the Via headers are used 
during session establishment), then the session set-up can be only 
interrupted prior to the session being established (which I don't classify 
as a preemption event, but more of an error event, because RTP hasn't 
started flowing).

>the 'resource-priority' element(s) could be used
>for it.

given the above constraints and considerations in the Voice architecture of 
that domain, this is true

>hannes

cheers,
James

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Apr 2004 16:34:40 -0500

At 12:07 PM 4/13/2004 -0400, Roy, Radhika R, ALABS wrote:
>Hi, John:
>
>Yes, you are right.
>
>What NSIS protocols need to do is as follows:
>
>1. Differentiation in call level priority
>
>2. Differentiation in priority level for each media of a given call level 
>priority

certainly these aren't the only 2 requirements involving this particular 
effort, but a good high level start

some other aspects that need to be considered are:

- is the initiator authorized to use a particular priority level?
- is the system designed to authorize ranges of priority levels, or just a 
specific level at a time?
- how will NSIS & SIP interact to synchronize the control and application 
layer prioritization?
- what's the treatment/behavior of preemption (where and how can it occur)?
- are endpoints and nodes notified of preemption events?
- if either are, how are endpoints and/or nodes informed of preemption events?
- is there more than one type of preemption?
- if so, how many other types of preemptions can there be (and what 
behavior with there be for each)?

the list above goes on quite a bit

>Best regards,
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, April 13, 2004 2:26 AM
>To: [email-masked]; Roy, Radhika R, ALABS
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]

cheers,
James

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

---

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Tue, 13 Apr 2004 23:05:57 -0400

Good points.

In addition to call-level and media-level priority, I find that your
items 3 and 4 are critical. However, I have provided some indications
how we can proceed for all the items that you have indicated.

Inline [RRR].

-----Original Message-----
From: James M. Polk [mailto:[email-masked]]
Sent: Tuesday, April 13, 2004 5:35 PM
To: Roy, Radhika R, ALABS; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] Questions regarding

[RRR] Right.

1- is the initiator authorized to use a particular priority level?

[RRR} It is taken care of today as can be seen used in RADIUS/DIAMETER
protocol. For example, NSIS/SIP entities can check with the AAA server
to make sure of the authorization.

2- is the system designed to authorize ranges of priority levels, or
just a 
specific level at a time?

[RRR] We can start looking as pointed above.

3- how will NSIS & SIP interact to synchronize the control and
application 
layer prioritization?

[RRR] In response of another email of Fred Baker, I have provided some
hints how we can address this. It may be a good starting point.

4- what's the treatment/behavior of preemption (where and how can it
occur)?

[RRR] A logical answer of this question will be to start at the sources
based on some policies. For example, it can be SIP proxies in the case
of SIP protocol. Similar is the case for the NSIS-aware entities.

5- are endpoints and nodes notified of preemption events?

[RRR] Why not if it is possible?

6- if either are, how are endpoints and/or nodes informed of preemption
events?

[RRR] A kind of pre-emption notification message.

7- is there more than one type of preemption?

[RRR] May be depending types of call pre-emption made.

8- if so, how many other types of preemptions can there be (and what 
behavior with there be for each)?

[RRR] We can start with a reasonable set.

level
list
*this*
TSVWG,

cheers,
James

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