Subject: [Tsvwg] Slides on MLEF/MLPP

From: Fred Baker <[email-masked]>
Date: Mon, 01 Mar 2004 16:31:35 +0900

The slides I used in the tsvwg meeting today are at
     ftp://ftpeng.cisco.com/fred/mlpp/MLEF+MLPP.pdf
     ftp://ftpeng.cisco.com/fred/mlpp/MLEF+MLPP.ppt

The internet drafts I mentioned are:
     http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlef-concerns-01.txt
     http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-01.txt

HTML versions of those same documents (which I personally find easier to 
read) are at:
     ftp://ftpeng.cisco.com/fred/mlpp/mlef-harmful.html
     ftp://ftpeng.cisco.com/fred/mlpp/mlpp-that-works.html

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Eagan, Christopher" <[email-masked]>
Date: Mon, 01 Mar 2004 08:24:28 -0500

It would be helpful if the MLEF draft included recommendations on how it
should be used and how it should not be used.  I think we will find
agreement in where it should not be used without CAC.  Specifically, in
draft-baker-tsvwg-mlef-concerns drafts you rely on the congestive
collapse situation for your main argument against MLEF - briefly, this
is where so many calls occupy a link that all or most low priority calls
drop so many packets that they become unusable.  I think everyone agrees
this is bad and anyone implementing MLEF should be made aware of how to
avoid it.

For example, I think everyone can agree that deploying MLEF to police a
link without Capacity Admission Control (CAC) is not a good idea if the
expected offered load greatly exceeds the capacity.  For example, if you
have a 128 Kbps link, and there is a chance that greater than 20, 6 Kbps
calls will traverse it, CAC should be used in addition to MLEF.

It is unhelpful to completely dismiss MLEF because there are clearly
cases where it can be useful.  For example, if one has a requirement to
maintain at least 5 high priority calls at a quality level of "good" and
to provide as many as possible low priority calls at a level of "fair",
MLEF can be used to increase the aggregate amount of calls versus the
situation where all calls have to meet the higher requirements of the
high priority calls.  This is trading quality for quantity in some cases
and whether this is good or bad will depend on the requirements of a
given situation.  Yes, more bandwidth would solve all this, but there
are some places (ad hoc wireless networks are one example) where you
just don't have more bandwidth and you have to be creative with what you
have.

Completely eliminating MLEF is not a good idea because
1. It is currently useful
2. The arguments against it are limited to a specific case of deployment
3. The arguments against it dismiss future advances in codecs and
policies

Some argue MLEF is a hack.  In the same sense one could argue DiffServ
as a whole is a hack.  However, because of the semi-random nature of
packet arrival times, assigning different drop precedence to packets
actually does work for AF traffic.  Our simulations* show that it also
works for voice traffic when using robust codecs**.

* We are still working on these but initial results show we can increase
the aggregate number of calls on a slow link by as much as 30% in some
cases.

** There has been discussions of codec robustness and bursty vs. random
packet loss and the effects on call quality.  I don't believe bursty
packet loss (defined here as 5 or more consecutive lost packets, or a
about 500ms worth when using 30ms frames and VAD) can be well handled by
any PLC mechanisms.  Bursty packet loss means a short duration where the
call content is not conveyed and may have to be retransmitted.  This
happens today in cell phones and other wireless communication systems
with or without MLEF, and regardless of what codec you are using.

Sincerely,

Chris Eagan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Fred Baker
> Sent: Monday, March 01, 2004 2:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Tsvwg] Slides on MLEF/MLPP
> 
> 
 
http://www.ietf.org/internet-drafts/draft-baker-tsvwg-mlpp-that-works-01
.txt

read) are at: