Subject: Re: [Ieprep] Comments on draft-carlberg-ieprep-framework

From: Scott Bradner <[email-masked]>
Date: Thu, 14 Mar 2002 09:20:36 -0500 (EST)

Mike sez:
  The reference I made about "It's what the US military does" is a 
  basic requirement for voice service operation.

we are talking past each other

I maintain that N-levels of priority is a solution not a requirement

the question that needs to be answered is what functions are needed to
be supported - not how to do them

specifically - what problem is thought to be solved by N levels of priority?

	is it that there should be a different probibility for
	calls to be completed based on who you are or what you are doing?

	is it that the quality of the call should depends on who you
	are and what you are doing?

	or is it someting else

Scott

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

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 14 Mar 2002 15:12:16 +0000

> specifically - what problem is thought to be solved by N levels of priority?

with a slight change of subject line description, there seems to be a
couple of things to consider.

first, there is the objective of having MLPP be supported via IP 
telephony.  

given the existing 5 levels of service for MLPP defined for the 
telephony world, there would appear to be a requirement to have a 
corresponding set of 5 levels or labels of signaling for SIP.  this 
is so that IP telephony via SIP can convey labels on a one-to-one 
basis with MLPP enabled telco networks.  most of these MLPP telco nets
may be private, but folks like US DoD (and NATO, and I believe the 
Japanese MoD) which use MLPP, would like to have a standard for SIP to 
convey these labels so that they can buy SIP phones from more than one 
vendor.

The proposed DSN NameSpace of James and Henning's draft, together with 
the Resource Header field, would seem to satisfy this requirement for
SIP.

my impression of what remains an open issue that is up for a debate is 
whether there should be a corresponding set of 5 markings for the 
(non-signaling) data flows -- in particular, at the IP layer.  And I 
suspect that what Scott is asking is where is the requirement/problem 
that would prompt this solution.

I just want to make sure we don't mix apples and oranges in the debate.

-ken

ps, i was also under the impression that one or some of the public
    cellular providers were planning on adding MLPP, thus extending
    the problem space beyond just private telco nets

---

From: "capthal" <[email-masked]>
Date: Thu, 14 Mar 2002 15:23:15 +0100

That sounds on track to me.

Hal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Scott Bradner
> Sent: Thursday, March 14, 2002 3:21 PM
> To: [email-masked]
> Subject: Re: [Ieprep] Comments on draft-carlberg-ieprep-framework
> 
> 
> Mike sez:

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Mar 2002 08:33:09 -0800

At 07:12 AM 3/14/2002, Ken Carlberg wrote:
>telephony world

tell me - what are these five levels of precedence? I would expect that 
they are precedence in placing calls, not precedence in dropping packets.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Mar 2002 11:20:08 -0600

>they are precedence in placing calls, not precedence in dropping packets.

As it stands now, (I believe) these 5 levels are not the "precedence in
dropping packets", but in dropping session(s) in order to complete higher
precedence session(s), which adds a new level of fun to this mix (and a subtle
re-wording of Fred's comment) 
*************************************
"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: Fred Baker <[email-masked]>
Date: Thu, 14 Mar 2002 10:11:34 -0800

At 09:20 AM 3/14/2002, James M. Polk wrote:
>precedence session(s),

which says to me that if the argument for some form of policy in SIP is to 
extend MLPP, the policy extension should model that of MLPP, and be in the 
form of call management, not packet management.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Mar 2002 13:08:05 -0600

>       are and what you are doing?

Let's pose a strict set of circumstances to address part of this thread that's
not answered yet explicitly (to my understanding - and others I believe)

Let assume RSVP worked completely everywhere and between every phone in the
Internet. A VoIP call using RSVP would work almost identically to a circuit
switched call in taking up a defined amount of bandwidth through each transit
interface between two phones. Lets say that all VoIP calls push aside all other
(data) traffic always with no hesitation. In a case where each call is 80kbps
traversing a T1 (1.544Mbps), 19 calls are possible at any one time. Even though
there is 56kbps of bandwidth remaining, that 20th call cannot be completed if
it requires an 80kbps Reservation across this link.

This is an example where codecs aren't changeable -- I want a specific analysis
to this scenario

What Mike is suggesting is the potential for dropping < 1kbps from all 19
existing calls to make this 20th one exist (if all 19 calls have the same
precedence level and the new 20th call has a higher precedence level). That
instead of clearing one of the calls (preemption), merely degrading all 19
existing calls by about 1 packet per second (of the 50pps for a normal VoIP
call).

Is this considered unacceptable?

One existing example/analogy:  even though the Cellular industry isn't
packet-based, I believe most calls remain *up* AND loose more than 1% of the
media signal during a call (if not much more). 

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Mar 2002 12:16:14 -0800

At 11:08 AM 3/14/2002, James M. Polk wrote:
>precedence level and the new 20th call has a higher precedence level). 
>That instead of clearing one of the calls (preemption), merely degrading 
>all 19 existing calls by about 1 packet per second (of the 50pps for a 
>normal VoIP call).

that may be what Mike is suggesting, if there are two levels of drop 
precedence. However, he is proposing five levels of drop precedence. So he 
might be suggesting that we drop .5 KBPS from 18 of the calls, and 10 KBPS 
from the 19th.

Or, there is another scenario. But for that, let's not use your proposed 
example, let's use the DOE situation that someone described to me in 
private email:

>there are only 146 trunks in one of our DOE Large PBX's servicing several 
>thousand people.

By "trunk", I assume that they mean "T-1", which translates to 24*146=3504 
DS0s. We have a national 8 KHz national reference clock, so I have to 
assume that these DS0s are all synchronized - every 125 microseconds, we 
are going to see a burst of VoIP packets, and since VoIP packets contain 20 
msec samples, there will be 3504/(8*20)=21 packets in the average burst, 
with a randomized density distribution.

Now, let's assume that the routers are configured to start dropping packets 
when their EF queue fills to 15 packets. Every time a burst is sent, you 
have to assume that the entire burst will arrive and get placed into a 
queue, and then will get fed to the line over the next few milliseconds. 
What we're saying is that the last 6 packets in each burst (which may have 
some randomness or may be very predictable depending on the specific 
structure of that burst - were all the calls in the same T-1 frame, or did 
they come from different trunks served by different DSPs?) will be subject 
to loss, and if there happens to be a beat frequency in the burst arrival 
distribution so that successive large bursts can fill a queue and keep it 
full for several milliseconds, entire bursts can be lost.

When we say that they have differential drop thresholds, we're saying that 
some packets will be lost if they arrive at a queue which is 10 packets 
deep, another set might be lost if they arrive at a queue which is 15 
packets deep, and so on; life could get really interesting and either 
unpredictable or all too predictable.

Has anyone figured out yet why I'm not crazy about this as stated? I don't 
mind applying policy to calls in some way, but with five drop thresholds, 
saying that we can shoe-horn a 20th call into the line by dropping 1 KBPS 
evenly from each of the other 19 is simplistic. It's a *lot* messier than 
that. And even with call policy, embedding a DISA-specific call policy in 
every SIP implementation in the world doesn't make sense.

I'm serious about my offer to review simulations of the behavior. Before 
five levels of diff-serv drop precedence is standardized, someone really 
ought to try it out.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 15 Mar 2002 12:39:40 -0600

>might be suggesting that we drop .5 KBPS from 18 of the calls, and 10 KBPS 

I'd call that cellphone quality -- just like I experience everyday. I believe
nearly everyone receives this .5kbps reduction on most calls as it is (as an
analogy), with some calls losing greater amounts of throughput. 

Another point that I've thought about but not proven mathematically
(simulation-wise) yet, what if adjacent priority levels lose at maximum 15% of
throughput relative to higher priority queues *that have packets queued*; that
if priority level #1's queue and #4's queue are the only queues with packets,
then this same 15% rule/algorithm applies as if they were adjacent.....  This
would reduce the relative loss from your lopsided example above by making a
curve loss fall-off, not linear, and not spiked.

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems

---

From: Fred Baker <[email-masked]>
Date: Fri, 15 Mar 2002 11:22:49 -0800

At 10:39 AM 3/15/2002, James M. Polk wrote:
>I'd call that cellphone quality -- just like I experience everyday. I 
>believe nearly everyone receives this .5kbps reduction on most calls as it 
>is (as an analogy), with some calls losing greater amounts of throughput.

You didn't finish reading what I said. .5 kbps loss probably is cell phone 
quality. 10 kbps loss isn't. And leaving the unlost traffic from those 
calls in the network impacts the calls that aren't losing traffic, by 
introducing jitter. If someone isn't going to be able to hold their 
conversation, just get them out of there.

What I'm telling you is that this is all a very interesting intellectual 
debate. Hard-earned experience with VoIP says that this is not something to 
be mandated because someone woke up with stars in his eyes. This stuff 
takes real analysis.

If you want to emulate MLPP, emulate MLPP. MLPP places or doesn't place 
calls based on some policy. Leave the per packet stuff out; it's a 
different service, and doesn't behave the same. Really. Really and truly.

And be smart. Just because twenty years ago we in our ignorance screwed up 
and put IP Precedence policy into IP (which we have since deprecated) 
doesn't mean we should make the same mistake again in SIP. Put a label in 
SIP that identifies the call, and present your credentials. But leave the 
policy (do we drop calls, or do we have a reserved set, or something else?) 
in the network.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 15 Mar 2002 14:17:10 -0600

At 11:22 AM 3/15/2002 -0800, Fred Baker wrote:
>You didn't finish reading what I said. 

Yes I did

>.5 kbps loss probably is cell phone 
>quality. 10 kbps loss isn't. 

Have you traveled lately? For years I've been in a car with wildly varying
degrees of loss in continuous calls, yet I haven't thrown my cellphone away
because the mobility benefit outway my QoS frustration.

>And leaving the unlost traffic from those 

I agree with this completely and am attempting to find a way of *somehow*
creating session awareness without full nodal statefullness that will have
collateral affects few will want.

>be mandated because someone woke up with stars in his eyes. This stuff 

I agree, numbers and charts are required

>
>If you want to emulate MLPP, emulate MLPP. 

I do, but not within this WG's area of eventual solution set. But MLPP does
give a sometimes useful model or analogy or example to reference for those
familiar with its workings.

>MLPP places or doesn't place 
>calls based on some policy. 

This is the session awareness that's required for both ETS and MLPP-like
services over IP.

>Leave the per packet stuff out; 

It's hard sometimes due to the lack of a session awareness aspect that seems to
be the obvious solution (if attainable).

>it's a 

I know, I know, I know and believe you. You have much more experience at this
than I and I can even see this to be true. It's getting there from here that's
tough sometimes.

>and put IP Precedence policy into IP (which we have since deprecated) 

I wish more today would realize this *is* the case instead of constantly
referring to it as if it (in IP) were still "there" and applicable.

>SIP that identifies the call, and present your credentials. 

I believe the SIP R-P ID does this to your stated expectations. I believe
policy is local in nature, but also believe policy can be grey in philosophy
for one's point of view (which yours is strong on BTW). I further believe there
should be hints for the short term as to general behaviors of labels as a
guidance -- with admittedly potentially better wording in those memos to that
affect.

>But leave the 

... we need to make sure the network has the mechanisms in place to accomplish
each desired behavior in reasonable circumstances.

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems