Subject: Re: [Ieprep] RE:MLPPoIP effort?

From: [email-masked]
Date: Wed, 19 Nov 2003 17:47:50 EST

In a message dated 11/19/2003 3:57:45 PM Eastern Standard Time, 
[email-masked] writes:

> This will have poor effect on the lower precendence class of mlef 
> (as your not preempting but just reducing the quality of lower 
> precendence calls to leave way for the higher precendence calls.) 
> Do you have any performance results to show that mlef doesn't 
> aggravate congestion(given this is suggested for voice calls)?
> 

Yes, congestion would have an effect on lower precedence calls by dropping 
packets. This is considered as being better that having an effect on all calls 
(including the high precedence ones). The effect is temporary, until some 
existing calls release and as CAC kicks in and prevents new calls from being 
established.

Take a typical example: At the moment congestion hits and some high 
precedence calls exist, lets say there are 100 calls, 95 low precedence and 5 high. If 
the congestion is such that 1% of the packets are being discarded (EF says you 
must discard something), then every call gets the effect of 1% packet loss 
(without MLEF). With MLEF, the 5 high precedence calls are essentially exempt 
from having their packets discarded. The other 95 get 1.05% packet loss, hardly 
a big difference. With normal holding times of 3 minutes, it will take less 
than 10 seconds for 5 of those 95 low precedence calls to release, ending the 
need to drop any packets.

MLEF can't aggravate congestion, since all it is doing is deciding which 
packets to discard, where such discard is already required by EF. Remember, this 
also requires effective CAC, which is required even without MLEF.

Simple preemption of the lower precedence calls would be preferable, but it 
appears that there is no sure-fire way to do that. I'm hoping that someone can 
describe one.

Mike Pierce

---

From: "Steve Silverman" <[email-masked]>
Date: Wed, 19 Nov 2003 19:53:46 -0500

One possible solution for the lower priority calls would be a terminal
behaviour such that if a certain percentage
(or number) of packets are lost in a certain amount of time,
the terminal issues a congestion notice to the other party and either the
call is suspended
for a short period of time or terminated.
This is essentially a major extrapolation  of  Van Jacobsen (dropped
pkts --> less offered load) for the voice application.

I believe that one reason for the success of
the Internet (adaptability to surges) is the fact that congestion leads
to lowered terminal transmission (VJ, and when surfing becomes slow, some
people quit.)
If  VoIP is to become a significant part of the total Internet traffic, some
sort of feedback needs to be incorporated.

Obviously, the behavior above  would only help if a significant fraction of
the terminals on the network used it.
For the MLPPoIP community (if this exists) this might be practical.

Steve Silverman

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
  Sent: Wednesday, November 19, 2003 5:48 PM
  To: [email-masked]; [email-masked]
  Cc: [email-masked]
  Subject: Re: [Ieprep] RE:MLPPoIP effort?

  Yes, congestion would have an effect on lower precedence calls by dropping
packets. This is considered as being better that having an effect on all
calls (including the high precedence ones). The effect is temporary, until
some existing calls release and as CAC kicks in and prevents new calls from
being established.

  Take a typical example: At the moment congestion hits and some high
precedence calls exist, lets say there are 100 calls, 95 low precedence and
5 high. If the congestion is such that 1% of the packets are being discarded
(EF says you must discard something), then every call gets the effect of 1%
packet loss (without MLEF). With MLEF, the 5 high precedence calls are
essentially exempt from having their packets discarded. The other 95 get
1.05% packet loss, hardly a big difference. With normal holding times of 3
minutes, it will take less than 10 seconds for 5 of those 95 low precedence
calls to release, ending the need to drop any packets.

  MLEF can't aggravate congestion, since all it is doing is deciding which
packets to discard, where such discard is already required by EF. Remember,
this also requires effective CAC, which is required even without MLEF.

  Simple preemption of the lower precedence calls would be preferable, but
it appears that there is no sure-fire way to do that. I'm hoping that
someone can describe one.

  Mike Pierce