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

From: "Eagan, Christopher" <[email-masked]>
Date: Tue, 25 Nov 2003 11:02:55 -0500

I understand the potential problems cited in regards to an mlef-only solution, but mlef and cac are not necessarily mutually exclusive.  I think mlef has its place in assuring priority communications in places where cac may not work, or may work too slowly.

Examples of where mlef is useful:  When an intervening network node that is routing many calls fails, all the calls must be rerouted - having mlef assures the packets from the priority calls get the best possible treatment while cac mechanisms have time to recover.  Another example is in mobile ad hoc environments, where there are concerns about how fast rsvp can re-reserve resources.

Are there problems with this?  I don't see mlef breaking any existing QoS mechanisms.

Chris

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Fred Baker
> Sent: Thursday, November 20, 2003 11:27 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Ieprep] RE:MLPPoIP - Preemption of low priority calls
> 
> 
> At 06:29 AM 11/20/2003, [email-masked] wrote:
> >Yes, I believe this has been suggested. The obvious problem 
> is trying to 
> >define an algorithm that would allow a terminal to 
> distinguish between 
> >packet loss from congestion that isn't going to go away, and 
> packet loss 
> >that is going to go away rather quickly anyway (as in my 
> example), and 
> >packet loss due to something other than congestion. I tend 
> to think that 
> >this is not possible.
> 
> actually, the obvious problem is that if we are dropping 
> traffic from a 
> precedence class, we are dropping roughly equal amounts from 
> all calls 
> within that class. If it is bad enough that some calls would 
> give up, one 
> must presume that all relevant sessions will at minimum ask 
> the question. 
> Why does one believe that they will not all, or some 
> significant subset, 
> drop? if this is done at a time when a number of sessions are being 
> established, this becomes a rolling pattern - if we have 
> enough calls for 
> 110% of the bandwidth, and are therefore dropping 10% of 
> traffic in the 
> precedence class, one would expect calls to drop and 
> re-establish randomly 
> in a rolling pattern.
> 
> The policy and predictability of the system is pretty 
> suspect, I think. 
> 
> 
> _______________________________________________
> 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: "Ken Carlberg" <[email-masked]>
Date: Tue, 25 Nov 2003 15:02:56 -0500

> Examples of where mlef is useful:  When an intervening network node
that
> is routing many calls fails, all the calls must be rerouted - having
mlef
> assures the packets from the priority calls get the best possible
> treatment while cac mechanisms have time to recover. 

This example is probably not as precise as it should be.  What type of
"network node" were your thinking about?  If the "network node" is a
router between two signaling or media gateways, then existing IP routing
will do the re-routing of IP flows -- transparently from the end-point
gateways.  

Also, what is the form of the call you are referring to?  Is this the
signaling traffic or the voice/data traffic?  I can see some value in an
MLEF-like capability for the latter, but not really the former. This is
because we generally don't associate the same delay & loss expectation
of VoIP signaling versus data.

> Another example is
> in mobile ad hoc environments, where there are concerns about how fast
> rsvp can re-reserve resources.

If you are referring to MANET, versus layer-2, then I would just point
out that IP level ad-hoc routing environments are still quite
experimental. Adding other capabilities like rsvp are in my view a fun
problem to consider, but also not ready for prime time.  A recent paper
in LNCS (URL below) gives some interesting results and expresses
concerns about protocols like TORA, DSV, and AODV. 

-ken

http://www.springerlink.com/app/home/contribution.asp?wasp=9ampwgwqlkrd3
67rvvtk&referrer=parent&backto=issue,56,79;journal,97,1358;linkingpublic
ationresults,id:105633,1

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 25 Nov 2003 16:17:15 -0500

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

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

---

From: "Ken Carlberg" <[email-masked]>
Date: Tue, 25 Nov 2003 17:15:33 -0500

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Steve Silverman
> Sent: Tuesday, November 25, 2003 4:17 PM
> Cc: [email-masked]

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 25 Nov 2003 19:46:32 -0500

Ken,

Sorry for any confusion.
I was using the term call in the requirements sense of both the
signaling packets and the voice packets.
>From a user's point of view, both are necessary for a phone call.

MLEF only acts on the voice/data packets.  It is a way to get critical
data packets thru a congested link.

Steve

> From: Ken Carlberg [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2003 5:16 PM
> To: 'Steve Silverman'
> Cc: [email-masked]
[mailto:[email-masked]] On Behalf
Of