Subject: RE: [Ieprep] IEPREP SIP REQ-6 to REQ-10

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 10 Oct 2002 16:47:34 -0400

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Monday, September 30, 2002 8:15 PM
To: King, Kimberly S.
Cc: Ieprep (E-mail)
Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10
 New wording suggestion:

"Network terminals configured to use a
priority scheme may occasionally end up making calls in a network that
does not support such a scheme.  In those cases, the protocol must
support a sensible default behavior that treats the call no worse than a
call that did not invoke the priority scheme."

[JPG] That works for me.

>         REQ-10: Address-neutral: The mechanism cannot rely on
>              identifying a set of destination addresses or URI schemes.
>              For example, in GETS-like schemes, the caller can reach any
>              PSTN destination with increased probability of call
>              completion, not just a limited set.
> 
> It appears REQ-10 adds that any address or URI scheme is a valid
> destination.  Let's assume REQ-14 is accepted (we can later debate this
> potential requirement in another thread covering this requirement).  

Indeed. I'll say that explicitly.

[JPG] I would rather say "any address or URI scheme may be a valid
destination".

[JPG] Some schemes will be have an open population of destinations, others
(e.g. MLPP) may have a closed populations of destinations.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 17 Oct 2002 10:22:43 -0400

Addressing just the first part-

In my mind the independence of  indication and policy does not in any way
inhibit me from naming my indications "low, medium, high".  But, at the same
time, it does not PREVENT me from implementing a policy under which (at
least under some circumstances), calls labeled "low" get better performance
than calls labeled "high".  

(An example would be that calls labeled "high" get priority as long as the
volume of "high priority calls" remains below a threshold.  Once the volume
crosses that threshold, they get worse treatment.)

-----Original Message-----
From: Ken Carlberg [mailto:[email-masked]]
Sent: Thursday, October 17, 2002 9:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10

speaking specifically in terms of henning's SIP requirements draft...

> If everyone else understands the meaning of "separation of indication
> and policy" in REQ-7, then perhaps someone can explain it in simple,
> explicit terms. What I am most concerned about is that someone will 
> later say that this requirement, after we have agreed to it, means that
> we can not define priority levels as something like "low, mediium, and
> high". 

simple answer (in my opinion): yes, you can define priority levels as 
"low, mediium, and high", though presumably you'll want to be more 
specific and state "low" in relation to what (e.g., drop precedence).
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 18 Oct 2002 10:40:26 -0400

>Certainly, the treatment provided in any network element is subject to
> local control, but I would find it hard to believe that any customer of a 
>priority service would accept a performance as you've described above, 
>presuming that, by the last phrase, you meant "they get worse 
>treatment than the lower priority calls". I certainly hope that we can 
>figure out how to do better than that. I guess this would prompt me to 
>suggest the following additional requirement if and when we start 
>talking about requirements for treatments or procedures: 
> "If a priority value is intended to get better service, e.g., higher call 
>setup probability, it must not be provided a worse service than 
> lower priority calls no matter what the traffic situation is." 

This is policy.  We don't need to discuss this aspect...just requirements
for indication, labeling, marking or whatever it is currently being called.

---

From: "Gunn, Janet" <[email-masked]>
Date: Fri, 18 Oct 2002 19:48:05 -0400

There are systems (existing or under development) in the Circuit Switched
world which behave as I described.  In some contexts, without such
constraints, carriers are reluctant to offer priority service at all.  I
would oppose the suggested requirement as "shooting ourselves in the foot."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 18, 2002 10:32 AM
To: Gunn, Janet
Cc: [email-masked]
Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10

In a message dated 10/17/2002 4:25:14 PM W. Europe Daylight Time,
[email-masked] writes: 

[MAP] Certainly, the treatment provided in any network element is subject to
local control, but I would find it hard to believe that any customer of a
priority service would accept a performance as you've described above,
presuming that, by the last phrase, you meant "they get worse treatment than
the lower priority calls". I certainly hope that we can figure out how to do
better than that. I guess this would prompt me to suggest the following
additional requirement if and when we start talking about requirements for
treatments or procedures: 

"If a priority value is intended to get better service, e.g., higher call
setup probability, it must not be provided a worse service than lower
priority calls no matter what the traffic situation is." 

Mike Pierce 
Artel

---

From: [email-masked]
Date: Wed, 23 Oct 2002 09:00:59 EDT

> would oppose the suggested requirement as "shooting ourselves in the foot."

[MAP] I'm surprised by the responses to my suggestion that there should be 
requirement that:

If I had suggested that the priority call must always get better service no 
matter what the traffic situation, I could understand the objection, but I 
proposed "not worse", i.e., "the same as" if a network can't do better. An 
architecture or solution which reserves a certain amount of bandwidth (or 
circuits) for the high priority traffic, and doesn't let high priority 
traffic overflow to fairly use the other bandwidth (or circuits) should not 
be acceptable.

I don't know what the situation is with WPS. I suspect the limitations there 
have something to do with the radio interface bandwidth limit and allocation 
method. Even there, I would think that the excess WPS traffic would get equal 
treatment with non-WPS traffic. Why (and how) would any carrier object to 
that?

Mike Pierce
Artel

---

From: "Gunn, Janet" <[email-masked]>
Date: Wed, 23 Oct 2002 11:06:19 -0400

WHY the carriers object- because it puts the carriers which offer the
priority service at a marketing disadvantage (wrt customers not entitled to
the priority service) with carriers not offering the priority service.
(While an approach COULD be devised which met your proposed requirement and
the carriers quantitative concerns, the development cost would have been
much higher, and it still might not have overcome the marketing
"perception.")
 
HOW the carriers object - by simply not submitting a bid to offer the
priority service at all.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 23, 2002 9:01 AM
To: Gunn, Janet
Cc: [email-masked]
Subject: Re: [Ieprep] IEPREP SIP REQ-6 to REQ-10

I don't know what the situation is with WPS. I suspect the limitations there
have something to do with the radio interface bandwidth limit and allocation
method. Even there, I would think that the excess WPS traffic would get
equal treatment with non-WPS traffic. Why (and how) would any carrier object
to that? 

Mike Pierce 
Artel