Subject: RE: [Tsvwg] draft-silverman-tsvwg-mlefphb-01

From: "Eagan, Christopher" <[email-masked]>
Date: Wed, 24 Nov 2004 12:46:02 -0500

In response to the question, "Given all this, I'd like to ask if anyone
here in TSVWG is interested in pursuing the mlefphb draft (for
Experimental) here?"... Yes, MLEF is a needed and helpful mechanism to
manage multiple levels of priority, real-time traffic.

In the reservation based scheme to protect high priority real-time
traffic, MLEF can still provide redundant protection, especially during
route changes.  Reservation schemes may take several seconds to
re-reserve bandwidth on route changes.  MLEF can levy the consequences
of temporary congestion on the lower priority traffic.  In addition, it
may be beneficial to commercial mobile communications providers who want
to sell different levels of service.  For example, the premium service
customers would be less likely to experience temporary cut-out's in
their conversations when moving between cells.

MLEF also provides a mechanism to increase call capacity by allowing the
group of lower priority calls to proceed with a degraded level of
service.  For example, for a 1,500,000 bps rated link, if each call
requires 80,000 bps, the link could carry 18 calls with zero packet loss
(1,500,000 / 80,000 = 18.75).  However, if 5 of the calls were high
priority and required zero packet loss, while you allowed up to 10%
packet loss on low priority calls, you could accommodate 15 low priority
calls in addition to 5 high priority calls for a increase in call
capacity of about 10%.

This can be taken further with a dual-rate codec rule such as, "All
calls will start with a high quality, high b/w codec.  If it is
recognized that there is network congestion (e.g. via RTCP, ECN, etc.)
and the call is low priority, switch to a lower quality, lower bandwidth
codec to relieve the network".  This dual-rate scheme can further
increase the call capacity of a network.  MLEF fits in here to protect
the high priority traffic while the dual-rate mechanisms adjust.
Whether this is fair, good, bad, evil, etc. is a choice that can be made
on a case by case basis by the network owners.

MLEF is strongly being considered by at least US government working
groups for protection of certain defense related traffic.  (Being a
relative IETF neophyte, I am not sure how this point will resonate.)
>From a commercial perspective, this is a market.  From a standards
perspective, having an experimental RFC for MLEF keeps the IETF
community informed of what is being considered for standards in other
circles.

I think the point has been made that MLEF is not necessarily a
stand-alone all-powerful mechanism to handle different priorities of
real-time traffic.  MLEF is a good tool to fine tune voip networks that
have special requirements and circumstances.  

Chris Eagan
Lockheed Martin
(301) 240 - 6328

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