Subject: RE: [Ieprep] Preemption

From: Fred Baker <[email-masked]>
Date: Mon, 25 Mar 2002 22:33:15 -0800

At 10:07 PM 3/25/2002, Beard, Cory wrote:
>Can we assume providers will be using RSVP and EF?  (At least in the short 
>term)

we can mostly assume that providers will swamp the situation with bandwidth 
so that the issue is moot. You may contract the use of same on your own 
access links, though, which tends to be among the congestion points of 
concern. And frankly, what seems to be under discussion with MLPP isn't 
service provider networks, it is private networks like DISA's.

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

---

From: senthil ayyasamy <[email-masked]>
Date: Mon, 25 Mar 2002 23:41:51 -0800 (PST)

> service provider networks, it is private networks
I strongly suggest to include mechanisms for
pre-emption into the existing framework document as an
option and leave the implementation to the discretion
of the local policy.  The James Polk draft on MLPP can
serve as a baseline.
	MLPP has Non-Preemptable Resources options which can
be explored for providing pre-emption as an
option.  This certainly prevents access pre-emption as
per the Polk draft.  But, pre-emption at the time of
congestion (network pre-emption) is as important as
access pre-emption.  So, the question is how to make
network pre-emption as an option?  This will provide
avenues for making pre-emption generic .

But still, MLPP is mandated as having influence with a
single domain based implementation only and there is
no recognized/standardized method or mechanism in the
case of which one of several lower precedence calls
gets disconnected. The working group has to focus on
these standardization issues too.Are there
possibilities for extensions to MLPP to cover more
than one domain?

- Senthil

=====
Ayyasamy Senthilkumar
M.S.(Computer Networking)
UMKC,MO.
-----------------------------
An expert is a man who has made all the mistakes that can be made in a very narrow field.
--Niels Bohr.

__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

---

From: Ken Carlberg <[email-masked]>
Date: Tue, 26 Mar 2002 13:03:53 +0000

> > concern. And frankly, what seems to be under
> > discussion with MLPP isn't=20

I think this thread on viewing non-preemptive action as a default
approach is in danger of mixing apples and oranges.  lets take a step
back and review a couple of things.

in the (IEPS) Framework document, the notion of non-preemptive action 
as a default position is presented early in the draft as simply an
objective -- keeping in mind that an objective is not a solution or
mechanisim.  further, this objective doesn't discuss the mechanisms,
which is what the thread has started to dive into.  later in the draft,
when it does discuss mechanisms, the draft makes clear the use of Policy 
as the means of dictating use and applicability of actions such as 
pre-emption.  i'll refer to my earlier post on this topic as to why
i think its helpful to view non-preemptive action as a deafult position
(keeping in mind that a policy may not exist in the presence of 
signaled information)

having said that, we also shouldn't confuse the draft as one that acts
as a framework for both IEPS (GETS-like service) and MLPP.  nor, in my
opinion, should we try to evolve the draft so that it specifically
address MLPP.  if this were the case, then surely we would need to
remove the objective of being able to function in the presence of
non-ubiquitous support.  in addition, the objective of high
*probability* of call completion would not apply to MLPP.

my feeling is that a framework for MLPP should be a separate document.
one could borrow heavily from the IEPS framework draft, but it would 
seem that a framework for MLPP would have a core of different 
objectives.  a question that would remain is whether a framework for
MLPP is within the charter of IEPREP.  that decision is not my call :-)

-ken

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Tue, 26 Mar 2002 07:02:41 -0700

Ken,

Thanks for reminding us of the difference between policy and protocol.

It seems to me that there are four general cases:

   * If a given network never preempts, then preemption does not occur there
   * If a given network always preempts when needed, then preemption may
     occur there
   * If a given network can do either based on an mandatory indicator, then
     it does whatever the indicator directs
   * If a given network can do either based on an optional indicator, then
     the action taken in the absence of the indicator is the DEFAULT action.
     To be consistent with the policy statement in this case the default
     would seem to be to not preempt.

Is my understanding correct, or did I miss something? I  used the term
indicator since the information may be part of the protocol or could be
delivered to the network by other means. I didn't want to restrict it to
just being in the protocol.

Ken Carlberg wrote:

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 26 Mar 2002 11:56:49 -0600

At 11:41 PM 3/25/2002 -0800, senthil ayyasamy wrote:
>.Are there

The SIP Resource Priority ID provides this domain extension to be addressed
directly through the use of a "namespace" as a domain identifier. The R-P ID
specifies a label that can/should be implemented within a single domain, or any
other domain via an SLA with other domain(s).

The case where domain (namespace) X has several priority values (immediate is
greater than routine for example). If the policy within domain X is to, during
times of congestion at any interface within that domain, determine if there are
lower relative priority existing calls in relation to a new higher priority
call, to preempt a single or more lower priority call in order to have that
higher priority call complete. 

If domain with a namespace of Y also wants to grant namespace X originated
calls the same treatment (either because they're nice folks or a formal SLA),
then all UA's, GW's and Proxies within namespace Y will also treat R-P headers
with namespace X as valid and act accordingly (similarly).

Having multiple namespaces as valid within multiple domains (UA's, GW's and
Proxies) is this extension I believe you are asking about. If not, please let
me know...

>- Senthil 
*************************************
"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: Ken Carlberg <[email-masked]>
Date: Wed, 27 Mar 2002 21:50:19 +0000

Stu,

> just being in the protocol.

the above seems fine.  personally, i might express things differently,
but no need to split hairs....its seems close enough.

-ken