Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt (2)

From: [email-masked]
Date: Tue, 9 Dec 2003 11:16:57 EST

In a message dated 12/8/2003 4:56:54 PM Eastern Standard Time, [email-masked] 
writes:

> My concerns derive fairly directly from mathematics. If a system is 
> designed to carry 20 calls (T-1 line and using G.711 encoding as proposed 
> in current DISA documents), adding a 21st call results in 5% loss roughly 
> uniformly distributed among the calls at any lower precedence than the call 
> added. 5% loss drops the MOS/PESQ score into the danger zone; 10% loss is 
> so bad that the reports don't even attempt to characterize it. If ILBC is 
> used as the codec, per the Miami University report I cited, you get a 
> little better loss performance. That still has a limit, though, and when 
> you go beyond that limit, the result is still horrendous. And, as described 
> in section 2.2, any protection-based codec, ILBC being but one example, has 
> a ballooning effect - when RCP starts reporting loss, the codec sends more 
> traffic. Thus, if a link is capable of carrying 20 calls, adding a 21st 
> call doesn't make it lose the traffic equivalent of a single call. It 
> actually balloons the traffic to 150% of its former size, and as a result 
> drops roughly 1/3 of the traffic - well beyond the limits of even ILBC.
> 
> Mathematics is bedrock. You're building a system to operate in a storm. It 
> can be a house built on bedrock, or it can be the ship that founders on the 
> same bedrock. What you need to show is that the math is wrong, that 21/20 
> of a link does not result in 5% loss, or that 5% loss does not result in a 
> low MOS score, or ...  
> 

[MAP]
Okay, what's the reality of the above situation you suggest.

20 routine calls are in place when the emergency begins.
Let's assume that there is an effective CAC in place that limits new calls so 
that:
  - a new Routine call is allowed only if the current number of Routine calls 
is not > 20
  - a new Priority call is allowed only if the current number of Priority 
calls is not > 1
As the new Priority call is started, it adds to the count that CAC uses for 
this limit.
Let's say the call set up time is 6 seconds. This means it won't need a 
packet flow until 6 seconds after it starts.
The average holding time for the existing Routine calls is 180 seconds. 
Assume that the next call does not release until 9 seconds after the emergency 
(time 0) (the average is really 4.5 seconds after any point in time).
Let's say 1 new Priority call begins at time 1 sec after the emergency.

The simulation results in 5.25% packet loss on the 20 routine calls for 2 
seconds (with MLEF).
The alternative (without MLEF) is that all 21 calls experience 5% packet 
loss, including the first 2 seconds of the Priority call, just as their 
conversation starts.

Yes, the math shows that 21/20 results in 5% loss, but normal call handling 
(call releases and CAC to limit new ones) results in this being a rather short 
duration loss.

Mike Pierce