Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls

From: Janet Gunn <[email-masked]>
Date: Mon, 24 Nov 2003 13:53:39 -0800 (PST)

The "factor of 3" or   "1/3" applies to the mean or average traffic rate.  In order to figure anything out about how often that is going to lead to over 100% utilization on a given link, we need to know something about the DISTRIBUTION, over various time intervals.   We also need this information to figure out how effective the various strategies would be. Does this information exist?

The effect is going to be very different depending on the "size of the pipes".  A link that is equvalent to, say, 5 "full time" connections is going to have much more variability in the total, and is threfore going to go over capacity more often, thatn a link that is equivalent to 100s of "full time" connections.  So stratgies that would be effective on "big pipes" might be inadequate on "little pipes".

Janet

-----Original Message-----
From: Steve Silverman <[email-masked]>
Sent: Nov 20, 2003 1:55 PM
To: "James M. Polk" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> James M. Polk
> Sent: Thursday, November 20, 2003 3:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
> At 02:39 PM 11/20/2003 -0500, Steve Silverman wrote:
> >Responses below.
> >
> >It seems to me that if bandwidth is scarce, silence
> suppression is a major
> >benefit. Typical users only speak for one third of the
> time.  But the CAC
> >simply reserves enough bandwidth in each direction for
> continuous speech
> >-  A factor of 3 in actual utilization.  Does this seem a
> reasonable approach
> >to anyone?
>
> Are you suggesting the choice is no CAC or CAC that might
> waste 2/3rds of
> the BW for that session?

No.  I am saying that if silence suppression is used (and I think it
should be used) the
 deterministic busy signal calculation of the Circuit Switched world
is impossible in a Packet Switched
world.  Consequently, to maximize the utility of limited bandwidth,
some prioritization is required
and mechanisms to work within this environment need to be addressed.

>
> Please read RFCs 2205, 2209, 2210, 2747, 2748, 2749, 2750,
> 2753, 2996, 3175
> and 3181. The first and last of this list are especially
> relevant to your
> environments
>
> >Has anyone
> >done a CAC to handle the DOD forces in the Middle East?
> I would assume
> >we don't have much fiber there.
>
> Connectivity and bandwidth awareness are the issue here,
> not whether there
> is fiber or not

The only reason I mention fiber is that in general, fiber provides an
abundance
of bandwidth but here I am focused on the case where bandwidth is a
scarce resource.

>
> >Can anyone supply the relevant facts or are they classified?
>
> I believe testing and analysis should be done prior to
> proposing solutions
> to incomplete requirements
>

I fully agree.
We had been   analyzing and testing before our funds ran out.
Is anyone looking at these issues and running the
appropriate testing.  I hope that my current impression that
these issues are being ignored is incorrect.

Steve

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

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

---

From: [email-masked]
Date: Tue, 25 Nov 2003 09:34:46 EST

In a message dated 11/24/2003 4:57:59 PM Eastern Standard Time, 
[email-masked] writes:

> The "factor of 3" or   "1/3" applies to the mean or average traffic rate.  
> In order to figure anything out about how often that is going to lead to over 
> 100% utilization on a given link, we need to know something about the 
> DISTRIBUTION, over various time intervals.   We also need this information to 
> figure out how effective the various strategies would be. Does this information 
> exist?
> 
> The effect is going to be very different depending on the "size of the 
> pipes".  A link that is equvalent to, say, 5 "full time" connections is going to 
> have much more variability in the total, and is threfore going to go over 
> capacity more often, thatn a link that is equivalent to 100s of "full time" 
> connections.  So stratgies that would be effective on "big pipes" might be 
> inadequate on "little pipes".
> 

Yes, this is all the stuff that would need to go into determining a limit of 
the number of simultaneous phone calls that can be allowed through a pipe of a 
specific size, in order to meet some performance criteria, The point I was 
trying to make is that this is exactly what has been done (using silence 
suppression to cram more calls into a limited space) for trans-ocean cables for a 
long time. And someone had to do the above calculations, so they should be well 
known.

ITU-T Recommendation E.528, Dimensioning of Digital Circuit Multiplication 
Equiment systems, probably covers this. I'm looking for a copy.

The use of this technique for existing systems provides the "proof of 
concept".

If the factor is 1/3 for a large pipe, it might be only 1/2 for a smaller one 
because of probability. No matter what value is used, there will be a few 
periods in which packets must be discarded. That's where MLEF can be applied.

Mike Pierce

---

From: "Eagan, Christopher" <[email-masked]>
Date: Tue, 25 Nov 2003 17:25:09 -0500

Sorry Ken,

I believe Steve and I were both referring to voice bearing packets, not signaling and control control packets (at least that is what I was talking about).  I think preferential treatment for signaling and control can be handled with the existing AF PHB's - since it is not likely to be as detrimental to a call if signaling is delayed a bit.

When I was said 'network nodes' earlier, I was referring to routers between two voice endpoints.

I'll try to be more precise next time.

Chris

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ken Carlberg
> Sent: Tuesday, November 25, 2003 5:16 PM
> To: 'Steve Silverman'
> Cc: [email-masked]
> Again, I am simply asking for more precision in what is said. 
>  If people
> are going to use the term "call", please indicate if you are referring
> to the signaling/control packets  OR  the voice/data packets.
> 
> One does not retransmit interactive voice packets.  And typically,
> concerns arise sharply when end-to-end voice exceeds 600ms delay.  On
> the other hand, I have yet to hear concerns about similar delay for
> signaling packets, and we can retransmit them if they are considered
> lost.  Hence, there are different expectations for the two different
> types of flows.
> 
> I hope we can end this thread on that note and not go down a rat hole.
> 
> -ken
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Steve Silverman
> > Sent: Tuesday, November 25, 2003 4:17 PM
> > Cc: [email-masked]
> > A case where MLEF would be useful:
> > 
> > Consider a ship with several hundred people, serious data 
> transmission
> > requirements,
> > (I won't go into detail on this.)
> > and a relatively limited (256 kb/s or maybe even less) 
> satellite link.
> > 
> > As you might imagine, whatever voice services are available are
> > sometimes heavily subscribed.
> > My guess is that 8 kb/s encoding and silence suppression 
> would be very
> > useful given the bandwidth limitation.
> > 
> > Occasionally, there is an important (high priority) call 
> that must get
> > through (or even several). Even if the existing
> > voice calls suffer or some of them are terminated.
> > 
> > I think the case above is realistic.  Is there an existing CAC can
> > handle this case and maximize the use of the b/w?
> > I would assume a router on each end of the link.
> > 
> > Steve
> > 
> > > Ken Carlberg
> > > Sent: Tuesday, November 25, 2003 3:03 PM
> > > To: 'Eagan, Christopher'
> > > Cc: [email-masked]

---

From: "Janet P Gunn" <[email-masked]>
Date: Wed, 26 Nov 2003 12:08:03 -0500

Mike,

This is the part I am not understanding properly.

"That means that, during the short period of congestion, the packet loss
needs to be concentrated on 90% of the calls (lower ones) rather then
spread across all 100% of them. As the lower priority calls drop, CAC
prevents new low priority calls because it knows that the total number of
calls is already at or above the limit, and the need to discard packets
quickly goes away."

WHY do the lower priority calls drop?  Because they become unintelligible
and the users hang up?  Because they get to the end of the conversation and
hang up normally (attrition)?  Because some third party (CAC mechanism or
whatever) "disconnects" them at the "call" level?

I am also a little confused about why the CAC will prevent replacement of
the low priority calls with new low priority calls.

Your premise is: "I would claim that a reasonable example of what needs to
be supported would be 10% of the calls are high priority with all of them
beginning in a rather short time interval (right after the diaster)."   Is
the total number of calls at that point below, at, or above  "the limit"?

If above "the limit" how did it get that way?  Does the CAC admit high
priority calls even when "the limit" has been reached? In that case
admitting the "excess calls" has resulted in packets needing to be dropped,
and the mechanism chooses which packets get dropped.

But if "at" or "below" the limit the "average" packet flow should be within
the engineered limits.  Do you assume that statistical variation will lead
to some packet dropping when the number of calls is "at the limit"?  If
"statistical" variation takes it to the point where packets need to be
dropped, then you have preferential dropping.  The CAC would have no reason
to reject new calls (of any priority) on the basis of the limit.  If there
is excess demand (at the call level), as each low priority call ends, a new
one will replace it.  If (you didn't say it did, but it seems plausible)
the CAC gives preference (in call admission) to high priority calls, then
the proportion of high level calls will increase, so the "pain" (packet
dropping) will be spread over  fewer (low priority) calls.

Is this limit that the CAC bases its decision on a limit at the source
(regardless of where the calls are going), or per source-destination pair,
or for a single link?

Just trying to understand.

----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

                      Mpierce1                                                                                                   
                      @aol.com                 To:      [email-masked], [email-masked], [email-masked],              
                      Sent by:                 [email-masked]                                                                
                      ieprep-admin             cc:      [email-masked]                                                          
                                               Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls               
                                                                                                                                 
                      11/26/2003 11:04                                                                                           
                      AM                                                                                                         

In a message dated 11/25/2003 7:33:19 PM Eastern Standard Time,
[email-masked] writes:

 To summarize what I am hearing about MLEF, this proposed PHB will delay
 the
 time between packets within the same flow (which codecs don't typically
 like) unless there is some mechanism of dropping the delayed packets
 (which
 codecs don't like either). Creating a PHB with a drop precedence similar
 to
 AF and apply it to a delay sensitive application (like voice) will create
 this dropping capability (which codecs don't like) and allow packets that
 are not delayed to arrive on time but with lost information the codec
 requires to replicate the audible speech patterns of the speaker. MLPP
 users are trained to understand what to do when they hear a preemption
 tone
 or announcement - but if they don't hear this tone (or announcement),
 might
 their behavior be to stay on the call longer than is necessary? Will they
 quickly call again (making the problem sustain itself).

[MAP] We need to remember that EF today says that a router must discard
packets that are in excess of the engineered limits (for the "EF" queue).
This can be done by having a simple size limit on the queue or by using
more complicated random early drop algorithms. The only thing that MLEF
adds is to define a way to decide which packets to drop - nothing more. Way
too much has been made about the efects of MLEF (on QoS, etc.). MLEF
doesn't add bad QoS, it only says which calls feel the effect that is
already there without MLEF.

I would claim that a reasonable example of what needs to be supported would
be 10% of the calls are high priority with all of them beginning in a
rather short time interval (right after the diaster). That means that,
during the short period of congestion, the packet loss needs to be
concentrated on 90% of the calls (lower ones) rather then spread across all
100% of them. As the lower priority calls drop, CAC prevents new low
priority calls because it knows that the total number of calls is already
at or above the limit, and the need to discard packets quickly goes away.
This can be easily demonstrated.

 Further adding to this problem space is the behavior of codecs and their
 own packet loss compensation. Most codecs that have this ability - when
 they understand that there is packet loss, will actually increase the
 amount of bandwidth transmitted (because duplicate voice samples are added

 other RTP packets just in case the packet before or after is lost) -
 making
 the problem worse (nearly exponentially worse) because now each call flow
 requires more bandwidth...

[MAP] I am not aware of any codec that adapts to packet loss by increasing
its transmitted rate. I suppose there could be one. Can you give an
example? They certainly couldn't be used in a possibly congested network,
except maybe for the very high priority calls. This would be contrary to
the operation of TCP which is required to drop back on packet rate when
loss occurs. (Before anyone comments, I'm not saying that TCP is being used
for voice packets. The solution for voice shouldn't take the opposite
approach!)

 So, without the providing the feedback necessary to terminate a call flow
 or series of call flows (and inform the user what has occurred) within the

 same priority level within a domain, how is MLEF a benefit?

[MAP] I believe there must be feedback from whatever knows about packet
flow congestion to whatever limits new calls (CAC), even if we never talked
about Assured Service. This must be possible for normal, non-priority
traffic. In the case of Assured Service, preemption of existing calls can
be added to this feedback. However, any such feedback can not take effect
immediately, so something else needs to deal with the short term packet
congestion. That is MLEF.

Note that, because of the probabilistic nature of packet flows and
congestion, we would not want preemption of any existing call to be caused
by a very short term packet loss or queue overflow. Temporary loss of
packets (and audio) with means to stop the congestion is much better.

Mike

---

From: Janet Gunn <[email-masked]>
Date: Wed, 26 Nov 2003 12:43:00 -0500 (GMT-05:00)

Just responding to one, slightly tangental, question.

"In times of disaster, do the same/normal 3 minutes per average call still 
apply?" 

 The data I have seen for 9/11 actually indicated a slightly SHORTER than "normal" average holding time.

Janet
-----Original Message-----
From: "James M. Polk" <[email-masked]>
Sent: Nov 26, 2003 12:18 PM
To: [email-masked], [email-masked], [email-masked], 
	[email-masked]
Cc: [email-masked]
Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls

comments below

At 11:04 AM 11/26/2003 -0500, [email-masked] wrote:
>>To summarize what I am hearing about MLEF, this proposed PHB will delay the
>>like) unless there is some mechanism of dropping the delayed packets (which
>>codecs don't like either). Creating a PHB with a drop precedence similar to
>>users are trained to understand what to do when they hear a preemption tone
>>or announcement - but if they don't hear this tone (or announcement), might
>adds is to define a way to decide which packets to drop - nothing more. 
>Way too much has been made about the efects of MLEF (on QoS, etc.). MLEF 

I would argue that MLEF is a hack at CAC. In choosing which calls receive 
good services and which don't, that's one function of CAC.

>I would claim that a reasonable example of what needs to be supported 
>would be 10% of the calls are high priority with all of them beginning in 
>a rather short time interval (right after the diaster). That means that, 
>concentrated on 90% of the calls (lower ones) rather then spread across 
>all 100% of them.

Several references provide mathematical analysis that > 5% packet loss 
drops MOS to below 3.1 (considered POOR).

If this is in a tactical environment, this could cost lives because orders 
weren't heard (unless field sergeants were give F or FO precedence level 
access)

>As the lower priority calls drop, CAC prevents new low priority calls 
>because it knows that the total number of calls

MLEF has no concept of "session" - so MLEF isn't CAC, yet it's acting like 
it is. And if it looks like a duck, and walks like a duck.....

>is already at or above the limit, and the need to discard packets quickly 
>goes away.

In times of disaster, do the same/normal 3 minutes per average call still 
apply?

Without the currently available feedback of a preemption tone or 
announcement, does user behavior remain the same?

>>other RTP packets just in case the packet before or after is lost) - making
>its transmitted rate.

Any codec with some form of Packet Loss Correction does this very thing - 
and a lot of ITU codecs do.

>I suppose there could be one. Can you give an example?

Some of these are in their specs,
some are with proprietary extensions

         G.729
         G.711
         G.723
         iLBC
         the list is longer...

>They certainly couldn't be used in a possibly congested network, except 
>maybe for the very high priority calls. This would be contrary to the 
>operation of TCP

huh... when does RTP use TCP?

(not for voice, not here)

>which is required to drop back on packet rate when loss occurs. (Before 
>anyone comments, I'm not saying that TCP is being used for voice packets. 
>The solution for voice shouldn't take the opposite approach!)
>
>>
>flow congestion to whatever limits new calls (CAC),

In MLEF, the router queue mechanism would know - and that's about it. 
Should it open up a TCP socket back to each transmitting device to provide 
this feedback?

>even if we never talked about Assured Service. This must be possible for 
>normal, non-priority traffic. In the case of Assured Service, preemption 
>of existing calls can be added to this feedback. However, any such 
>feedback can not take effect immediately, so something else needs to deal 
>with the short term packet congestion. That is MLEF.
>

cheers,
James

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Nov 2003 12:07:18 -0600

> "normal" average holding time.

What was the feedback mechanism (fast busy)?

What if there were no feedback mechanism that all the users were trained to 
pay attention to/for (like a preemption tone or announcement)?

cheers,
James

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

---

From: "Janet P Gunn" <[email-masked]>
Date: Wed, 26 Nov 2003 14:06:29 -0500

Feedback for what?  This was for the NS/EP calls in the PSTN.

                                                                                                                                 
                      "James M. Polk"                                                                                            
                      <jmpolk                  To:      Janet Gunn <[email-masked]>, [email-masked], [email-masked], 
                      @cisco.com>              [email-masked], [email-masked]                                           
                      Sent by:                 cc:      [email-masked]                                                          
                      ieprep-admin             Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls               

                      11/26/2003 01:07                                                                                           
                      PM                                                                                                         

At 12:43 PM 11/26/2003 -0500, Janet Gunn wrote:
>  The data I have seen for 9/11 actually indicated a slightly SHORTER than

> "normal" average holding time.

cheers,
James

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

---

From: [email-masked]
Date: Wed, 26 Nov 2003 15:24:17 EST

> hang up normally (attrition)?  Because some third party (CAC mechanism or

[MAP] Yes, mainly to the 2nd reason - normal attrition. Yes, if the quality 
got that bad, more might be enticed to release early, but I believe limits can 
be set to make this highly unlikely. As for the third reason, yes there may be 
preemption. I do not consider this a part of CAC. (I will limit my notion of 
CAC to something that prevents new call setups, not something that preempts 
existing ones.)

> I am also a little confused about why the CAC will prevent replacement of

[MAP] There have to be different limits for different precedence levels of 
calls, as I described in Section 3.2 of my pref-treat-examples draft. For 
example, if CAC is set to limit the total number of Routine calls on a resource to 
say 100 to provide MOS=4.0, but allows priority calls to push the total over 
that, say to 105, then every time a priority call is setup and one routine call 
drops, a routine call can not be setup again, since there are then still 100 
calls. (Notice that no change in the CAC limits is required in real-time when a 
priority call occurs.)

> the total number of calls at that point below, at, or above  

[MAP] Yes, it can be any of these.

> admitting the "excess calls" has resulted in packets needing to be dropped,

[MAP] Yes, CAC admits Priority calls to go above the "limit" set for normal 
traffic, which is what causes the temporary need to discard packets.

> the engineered limits.  Do you assume that statistical variation will lead

[MAP] Yes, I believe this can still happen. Say the link can support 100 
packet flows (calls). If the packets arrive completely random and spread out 
perfectly over time, and the queue is served at a regular rate, every packet queued 
is dequeued and sent before or just as the next packet arrives. The queue 
limit could be 50 packets. If all 100 sources sent packets that arrived at the 
same instant, they would all need to go into the queue at the same time and 
would not fit. 50 would be discarded. This is an extreme case, but that's the 
nature of a statistical model. It's so far out that we don't worry about it, but 
it can happen. (Note: We don't want any preemption or change to the CAC to be 
caused by such a far-out case.) If the CAC limt were set so that packet discard 
absolutely never occurred, then I would argue that the CAC limit should be 
higher.

  If  > "statistical" variation takes it to the point where packets need to be

[MAP] Yes, that's the whole point of MLEF. It would have some affect on which 
of the above 50 packets are discarded (although it isn't really intended to 
address this rare statistical case).

 The CAC would have no reason

[MAP] A CAC could take into account some notion of the loading on a link (or 
overflow of the buffer) but I see that as rather complicated and too transient 
to affect a CAC (which must be resident someplace else).

> dropping) will be spread over  

[MAP] It is essential that CAC gives preference to high priority calls in 
order for MLEF to work properly. I presume any network would set a limit on how 
many priority calls could exist. If all started at the exact same moment, then 
there would be significant, temporary "pain" on the existing normal calls. But 
preemption is also a "pain". With appropriate assumptions about the rate at 
which high priority calls will "suddenly" start and limits on how many are 
allowes, I believe the "pain" inflicted on the low priority calls can be bounded. 
It's under control of the network administrator to set the limits.

> (regardless of where the calls are going), or per source-destination pair,

[MAP] To be meaningful for VoIP (even without Assured Service or MLEF) it 
needs to be per single link (since that's where congestion can occur) but the 
decision must affect the source (prevent a source from setting up a new call). 
I'd like to see this issue discussed and solved separately from Assured Service, 
since it is still required without Assured Service.

> Just trying to understand.

[MAP] Thanks for the question. I'm trying to take all these questions and 
work them into a better description for a draft of how MLEF and CAC work together.

Mike