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

From: Janet Gunn <[email-masked]>
Date: Tue, 25 Nov 2003 14:33:51 -0800 (PST)

As I understand it, CAC operates at the "call" level, and thus at the signalling level, when the "call" is being set up.  The CAC mechanism MIGHT have some knowledge about the packet level activity of the voice/data packets, for instance by knowing  the codec to be used.

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"

In principle, changing the PHB will change the QoS behavior, but it won't/can't, by itself "terminate" a call.  Only a call level (typically signalling based) mechanism can terminate a call.

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

---

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

Comments below.

> Janet Gunn
> Sent: Tuesday, November 25, 2003 5:34 PM
> To: Ken Carlberg; 'Steve Silverman'
> Cc: [email-masked]
> As I understand it, CAC operates at the "call" level, and
> thus at the signalling level, when the "call" is being set
> up.  The CAC mechanism MIGHT have some knowledge about the
> packet level activity of the voice/data packets, for
> instance by knowing  the codec to be used.

The CAC operates at the call level. If silence suppression is in use,
the CAC
does not know if one side is transmitting or not.  It can only make
approximations to
actual usage.

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

Yes.

> In principle, changing the PHB will change the QoS
> behavior, but it won't/can't, by itself "terminate" a call.
>  Only a call level (typically signalling based) mechanism
> can terminate a call.

I agaree with everything above.

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

I have suggested the possibility that if a terminal had enough packets
dropped,
it might then delay or terminate the call, in order to lessen the load
on the network.
This would be terminal initiated signaling based on congestion.

Steve

> [mailto:[email-masked]] On Behalf
> Of
> > Steve Silverman