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

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

"When the voice traffic exceeds the link capacity, the high priority
calls
get thru intelligibly. This has been demonstrated."

What happens to the low priority calls?  That is what I am still not
getting.

I'd also be interested in the range of conditions for which it has been
demonstrated.

Janet

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

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

                      "Steve                                                                                                     
                      Silverman"               To:      "James M. Polk" <[email-masked]>, "Janet Gunn" <[email-masked]>,  
                      <steves                  "Ken Carlberg" <[email-masked]>                                              
                      @shentel.net>            cc:      <[email-masked]>                                                        
                      Sent by:                 Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls               
                      ieprep-admin                                                                                               

                      11/25/2003 08:26                                                                                           
                      PM                                                                                                         

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2003 7:31 PM
> To: Janet Gunn; Ken Carlberg; 'Steve Silverman'
> Cc: [email-masked]
> Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>
.........
>
> 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).

No.  MLEF drops some lower priority packets when there is congestion.
It never delays packets.

>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).
>
> 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...
>
> 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?

When the voice traffic exceeds the link capacity, the high priority
calls
get thru intelligibly. This has been demonstrated.

>
> >Please explain.
> >
>
>
> cheers,
> James
>
>                                 *******************
>                  Truth is not to be argued... it is to be presented
>
>

_______________________________________________
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: "Steve Silverman" <[email-masked]>
Date: Wed, 26 Nov 2003 19:46:26 -0500

> From: Janet P Gunn [mailto:[email-masked]]
> Sent: Wednesday, November 26, 2003 12:24 PM
> To: Steve Silverman
> Cc: Ken Carlberg; [email-masked]; [email-masked];
> Janet Gunn;
> James M. Polk

Enough packets are dropped from the lowest priority traffic that the
congestion is relieved.
Comments below.
> I'd also be interested in the range of conditions for which

We had a test setup with multiple voice files and each file could have
a DSCP
associated with it.  The various calls were significantly more than
the bandwidth on the link.
When all were at the same DSCP, as more calls were turned on, the
"important" call became
unintelligible.  By raising the priority of the "important" call, it
stays intelligible as the
rest of the calls are turned on.

This has been demonstrated at DISA.

The quality of the lower priority calls is definitely impacted.  They
are not MOS 4 although
we never did any serious testing.  The requirement for no impact on
lower priority calls
is new to me and appears to me to be impossible.  Since in the CS
world, lower priority calls are terminated,
it always seemed reasonable to me to drop packets from the lower
priority calls. Since in the most common situations,
the number of drops would be small, there would be an acceptable drop
in quality even for the routine traffic.

We had enough voice demand for 30% more than the link had available.

I agree that a thorough testing of the algorithm and its behavior
under varying conditions would be a good idea but unfortunately, DISA
never funded this work.  When the original funding was exhausted and
DISA failed to fund
additional work in this direction, the project was ended.  I am
extremely skeptical that DISA or the DOD can provide
an MLPP-like function over an IP network without something like MLEF.

Steve