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

From: "James M. Polk" <[email-masked]>
Date: Tue, 25 Nov 2003 18:30:41 -0600

At 02:33 PM 11/25/2003 -0800, Janet Gunn wrote:
>As I understand it, CAC operates at the "call" level, and thus at the 
>signalling level, when the "call" is being set up.

CAC operates at this level, but maybe other levels too

>The CAC mechanism MIGHT have some knowledge about the packet level 
>activity of the voice/data packets,

Depending on the CAC, it might have awareness of packet flows

>for instance by knowing  the codec to be used.

To be precise - it might know the amount of bandwidth required by that flow.

One particular CAC MUST know the bandwidth to set up a reservation - but it 
doesn't care at all what the actual codec is (splitting hairs now, I know)

>Any kind of per hop behavior operates at the packet level, without any 
>explicit knowledge ABOUT the packet, except the label that indicates the 
>PHB.  It doesn't know anything about the associated "call"

correct

>In principle, changing the PHB will change the QoS behavior, but it 
>won't/can't, by itself "terminate" a call.

correct

>Only a call level (typically signalling based) mechanism can terminate a call.

typically

>If there is some kind of  a feedback loop between the "packet level" and 
>the "call level", it is possible that the call level mechanism will detect 
>that the QoS had become unacceptable.  In that case the the call level 
>mechanism might terminate the call.
>
>You seem to be implying that a MLEF PHB can "terminate" a lower priority 
>call.  I don't understand how it can do that.

neither do I....

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

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?

>Please explain.
>
>-----Original Message-----
>From: Ken Carlberg <[email-masked]>
>Sent: Nov 25, 2003 2:15 PM
>To: 'Steve Silverman' <[email-masked]>
>Cc: [email-masked]
>Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
>
>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
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
>Of
> > Steve Silverman
> > Sent: Tuesday, November 25, 2003 4:17 PM
> > Cc: [email-masked]
> > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> >
> > 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
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > Ken Carlberg
> > > Sent: Tuesday, November 25, 2003 3:03 PM
> > > To: 'Eagan, Christopher'
> > > Cc: [email-masked]
> > > Subject: RE: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Ieprep mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ieprep
>
>
>_______________________________________________
>Ieprep mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ieprep
>
>
>
>
>_______________________________________________
>Ieprep mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ieprep

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

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 25 Nov 2003 20:26:20 -0500

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

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

---

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

>get thru intelligibly. This has been demonstrated.

It has also been demonstrated that all calls of lower priority don't 
receive the required feedback necessary to perform correctly. It has been 
demonstrated that all calls of lower priority levels don't receive anything 
intelligibly. The GSCR mandates that all calls *up* are of MOS = 4.0 or higher.

Please refer to the GSCR for mandatory test criteria to this which every 
vendor MUST comply with in order to be certified  by DISA.

MLEF is contradictory to the GSCR - one has to give.

cheers,
James

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