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

From: [email-masked]
Date: Wed, 26 Nov 2003 11:04:28 EST

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 
> 

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

[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: Ian Brown <[email-masked]>
Date: Wed, 26 Nov 2003 16:18:46 -0000

>I am not aware of any codec that adapts to packet loss by increasing 

There is a good overview of several Forward Error Correction schemes
that take such an approach in:

C. S. Perkins, O. Hodson, and V. Hardman, A Survey of Packet-Loss
Recovery Techniques for Streaming Audio, IEEE Network Magazine,
September/October 1998. 
http://csperkins.org/rat/publications/ErrorCorrection.ps

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

---

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

comments below

At 11:04 AM 11/26/2003 -0500, [email-masked] wrote:
>>quickly call again (making the problem sustain itself).
>
>
>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 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, 
>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.

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?

>This can be easily demonstrated.
>
>>
>>requires more bandwidth...
>
>
>
>
>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!)
>
>>
>[MAP] I believe there must be feedback from whatever knows about packet 
>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.
>
>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

cheers,
James

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