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

From: "Folts, Harold" <[email-masked]>
Date: Wed, 13 Mar 2002 04:24:04 -0500

Mike,

Please keep in mind that this work is directed to NS/EP telecommunications
requirements, which are not necessarily the same as DoD in their dedicatated
networks.

Hal

-----Original Message-----
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Sent: 3/12/02 11:08 AM
Subject: Re: [Ieprep] Comments on draft-carlberg-ieprep-framework

In a message dated 3/11/02 7:51:13 PM Eastern Standard Time,
[email-masked] writes: 

At 09:33 AM 3/11/2002, [email-masked] wrote: 
>At this point, it would be good to consider whether the possibility
should 
>be included for multiple levels of "authorized". (Note that the
parallel 
>work in SG16 on H.460.4 is leaning towards including such a
capability.) 

are these "levels of authorization" or "kinds of authorization"? My 
experience with levels is that the discussion is always about winners
and 
losers: "my stuff is more important than his stuff, so I think there
needs 
to be another level."

The idea is that there could be many different
agencies/persons/functions that need emergency access - FEMA, police,
medical, Red Cross, network administrators, etc. It's hard to image that
all would be treated the same. If there is only one possible level to
apply to all, it would be very difficult to decide whether or not a
particular group would get the authorization, e.g., is the Red Cross one
that needs this? Providing a way to distinguish would help. Whoever
administers the authorization to use emergency levels in a network would
decide who gets which level. Within "emergency" there needs to be 3 or 4
levels. (Remember, In MLPP, or "Assured Service", one could think of the
5 levels of precedence as consisting of a "Routine" level, and then four
levels of "emergency".) 

What makes sense to me in SIP is a simple statement: "I assert that this

call is an emergency call". If you are not authorized to make that 
assertion, the correct policy is to ignore the statement. If you are 
authorized, the network will have a policy to apply such as "permit this

call even if we are well into the overload zone" or "drop a random call
in 
order to complete this one." The network should determine the policy,
not 
the standard.

Not sure of your point. The standard should allow a way to designate
sufficient levels of importance, in order for a network to apply
whatever its policy is. I can certainly envision that a desired network
policy is to control access based on the relative level of the emergency
call and the authorization of the person making the attempt. The MLPP
model is that each user is authorized to use up to a certain level, and
may signal any level up to that one in a call setup. The question is:
how many distinct levels are needed? 

>4.1.2 Diff-Serv 
> 
>[snip] In this example, there would need to be the 5 drop precedence 
>levels for EF, as well as for each AF class, since eventually there
should 
>be a need to apply precedence type services to other traffic types
besides 
>voice. Clearly, there are not enough available DSCP code points. 

I think you have a very different understanding of diffserv than I do.
When 
you talk about a drop precedence for EF (which doesn't have a drop 
precedence), what are you talking about - dropping packets, or dropping
calls?

The current draft shows "EF for voice, with signalling of bandwidth".
Therefore it whould need to have multiple levels of drop precedence.
This refers to dropping individual packets, since that is where the
marking is. Actually, I think that EF only for the signaling and one of
the AF classes for the voice packets would make more sense, as I
suggested in Annex A of draft-pierce-sipping-assured-service. 

Recall that in GETS, you don't get differing qualities of circuits. You
get 
differing probabilities of getting a circuit, but once you have a
circuit, 
it is just a circuit and works exactly like any other circuit. In IP 
telephony, you might have varying call preferences, but once you decide
to 
carry voice at all, EF is the service that carries voice. If you're
trying 
to model GETS in IP Telephony, dropping packets makes no sense. Dropping

calls might make sense.

If GETS resulted in different routing, it might mean different circuit
quality (better or worse). Yes, it was "just a circuit", so there were
limited things that could be done to play with quality. IP provides
other options. 

Yes,dropping calls might make sense, but I recognize the dislike for
"preemption" and understand that it isn't allowed some places. The point
I'm making is that some resources can be stolen for the more important
call by causing the less important call to drop more packets, thereby
stealing some of its QoS. The result, when the QoS of the less important
call gets intolerably bad, is for the parties to give up and disconnect,
freeing up more resources. Meanwhile, the establishment of new calls is
being controlled based on precedence (importance), so their reattempt is
blocked. 

So it's not in the least obvious where diff-serv fits here. Please
advise?

Diff-serv AF provides the drop precedence for what I described above,
without any change. Is there anything else that could do this? 

>As described in draft-pierce-assured-service... 

is that draft-pierce-sipping-assured-service-01.txt?

Certainly. My fast typing often gets ahead of by slow brain. 

BTW, in view of RFC 2597 "Assured Forwarding PHB Group", which is often 
called "Assured Service", I'd personally appreciate it if you could find

another name. My head snaps every time I hear the name :^) 

I'm certainly sensitive to using a term for two things. Is the term
"Assured Service" used in specs, or just in everyday speech? We'll
consider other names.

Mike 

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

---

From: Scott Bradner <[email-masked]>
Date: Wed, 13 Mar 2002 21:37:45 -0500 (EST)

> It's what the US military and many others have been using for years and it is 
> the basic requirement we have for them to use Voice over IP.

why

(note the answer that 'they have it now' is not legit)

i.e. - lets talk about requeirements not solutions - multiple priorities 
on packets is a solution not a requirement - what is the problem to be
solved?

Scott

---

From: [email-masked]
Date: Thu, 14 Mar 2002 08:43:48 EST

> on packets is a solution not a requirement - what is the problem to be

I agree. The reference I made about "It's what the US military does" is a 
basic requirement for voice service operation. The end user must be able to 
specify one of 5 levels for voice call setup and it must have certain effects 
on the call setup and retention. (Hopefully, the user really isn't aware of 
whether the call uses IP or circuit switched or a combination.) That's the 
requirement.

On the other hand, marking of packets with drop precedence, or whatever, is a 
possible solution. Right now we see it as proabably needed in order to meet 
the service operation requirement, but realize that this is the main part to 
discuss. Clearly, there is no claim that packet priority levels is what "they 
have now". BTW, I haven't suggested multiple priorities on packets, only 
mulltiple drop precedences. Unfortunately, some of us not familiar with the 
details of AF have gotten the two concepts mixed up at times. I certainly 
have.

The problem being solved is providing some level of preferential treatment to 
the higher priority call without resorting to preemption of lower precedence 
calls. Instead, some packets of the lower precedence call are "preempted" by 
being dropped when the offered load exceeds the capacity. I haven't seen any 
other solution. (We're talking about the case when the offered voice traffic 
exceeds the capacity of a small access link, not one in which there is still 
a whole lot of data and background traffic that can be pushed aside.)

Mike

---

From: "Bob Bell" <[email-masked]>
Date: Thu, 14 Mar 2002 14:28:34 -0600

Fred - 

You bring up an interesting point, but even though the samples are sync'ed by the 8KHz clock at the trunk interface, the samples are serialized at the point where they are sent on the ethernet. Particularly for large trunk interfaces (e.g. 20 T1's per interface for example), this serialization should help limit the bursts of traffic you are describing. Now if all interfaces are single T1s, and you have 146 T1 spans, and thus 146 separate sources, this might be a bigger problem. By the way, usually the term "Trunk" in a telephony sense is used to indicate a single DS0 or equivalent (e.g. an analog voice circuit) not an aggregation of DS0's as in a T1 or a T3 span. This is not universal but in the example you showed, having a 10-1 person to trunk ratio is not uncommon, so I would suspect the term "trunk" does refer to DS0's in this case.

Bob

>From: Fred Baker [mailto:[email-masked]]
>Sent: Thursday, 14 March, 2002 1:16 PM
>To: [email-masked]
>Cc: [email-masked]
>At 11:08 AM 3/14/2002, James M. Polk wrote:
>>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).
>
>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: "Bob Bell" <[email-masked]>
Date: Thu, 14 Mar 2002 15:16:55 -0600

Fred - 

Even Einstein had trouble balancing his checkbook. ;->

Bob

>Sent: Thursday, 14 March, 2002 2:13 PM
>To: [email-masked]
>Subject: RE: [Ieprep] Comments on draft-carlberg-ieprep-framework
>
>
>At 01:09 PM 3/14/2002, Fred Baker wrote:
>>20 T-1s on a single Ethernet implies that it is a 100 MBPS or 1 GHz 
>>Ethernet; it presents ~15 MBPS of traffic in each direction.
>
>duh; get the math right, fred. 20*1.536 = ~30 MBPS in each direction...
>
>

---

From: [email-masked]
Date: Fri, 15 Mar 2002 23:14:39 EST

Fred Baker worte:

> 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, 

I don't know where you get this view of the existing network. When someone says "trunk" you have to assume they mean a facility to carry exactly one telephone call, not a T-1. Incidentally, a T-1 carries exactly 24 DS0's, normally used for 24 "trunks". (I don't know where the mulriplier of 146 above comes from.) I am unaware of any 8khz national standard which keeps DS0 sychronized. Only the bit rate (1.544Mhz is synced). So there is nothing that would cause bursts of packets.

Mike

---

From: [email-masked]
Date: Mon, 18 Mar 2002 08:42:21 EST

In a message dated 3/17/2002 5:32:07 PM Eastern Standard Time, 
[email-masked] writes:

> Bob, I am a little confused about what you have written. I agree that should 
> more and more calls just be "shoehorned" in, then the QoS would continue to 
> go down IF we were just looking at a SNAPSHOT of the network where no calls 
> ever end. However, if we can assume that the vast bulk of the traffic is 
> not emergency calls, can we not also logically assume that as such non- 
> emergency calls individually end, the bandwidth would revert back to the 
> network. The existing admission policy would not allow additional non 
> emergency calls to be established. So, my question is would not the QoS 
> return to normal as soon as an equal number of non emergency calls have 
> completed their sessions? It seems to me that the "overlooking" of the 
> admission policy for emergency calls would at the most only temporarily 
> impact the QoS of the network. The normal QoS would be quickly restored.  I 
> would think that QoS would not be more than momentarily impacted unless and 
> until the emergency traffic has completely displaced all of the multitude 
> of POTS traffic. Am I missing something? 
> 
> 

Staurt,

As always, you have clearly and succinctly described what I meant in previous 
e-mails and in the Annex to draft-pierce-sipping-assured-service-01. The 
added utility to this is that the lower QoS will encourage those 
non-emergency calls to release early, while the admission policy will block 
their immediate reattempts.

Thanks.

Mike Pierce