Subject: Re: [Tsvwg] Re: comments on draft-baker-mlef-concerns-00.txt

From: [email-masked]
Date: Mon, 8 Dec 2003 20:17:53 EST

In a message dated 12/8/2003 4:56:54 PM Eastern Standard Time, [email-masked] 
writes:

>[Chris Eagen wrote] 
2.  This draft implicitly assumes MLEF being implemented without other 
>mechanisms also being implemented (e.g. without call admission 
>control).  Merits of other mechanisms aside, what is the basis for this 
>assumption?  Does an implementation of MLEF exclude other QoS mechanisms 
>or vice versa?  Not that I have seen.  Maybe if you added interoperability 
>concerns between MLEF and other existing mechanisms this would bolster 
>your argument.

[FB answered] The MLEF PHB states that packet loss is the means of call 
admission 
control. The simulations that Mike Pierce has sent me use packet loss to 
perform call admission control at the source - if a source is seeing a 
certain level of loss, it asks itself some policy-related questions and 
then potentially drops the call. Steve Silverman says the same thing:

[MAP] No, I have never suggested the use of packet loss to perform call 
admission control. I have always assumed, and I hope I have made clear, that CAC 
and MLEF are two separate mechanisms, and that both are required. The MLEF PHB 
draft does not say it uses packet loss to affect admission control. It does not 
mention call admission.

The simulation I sent is not based on using packet loss to affect call 
admission. It is based on fixed call admission limits. I know it needs more 
explanation which I'll try in a follow-up e-mail.

Call admission control (without or without MLEF and with or without multiple 
precedence levels) must be done based on knowledge of how many packet flows a 
facility (link) can support and still provide the desired QoS. This is 
relatively easy to estimate with constant bit rate codecs like G.711. As Fred wrote 
in his draft, it is more complicated and uncertain with variable rates (such as 
with silence suppression).

MLEF (for multiple precedence levels) is what takes care of the (hopefully) 
short periods in which the expectations of CAC are not quite met that must 
result in periods during which the buffer overflows and packets are discarded (as 
required by EF). This is especially a problem when using variable rate codecs 
as Fred described. These make a mechanism such as MLEF all the more important.

The idea of causing packet flows to be stopped by the source based on 
detection of excess packet loss (and reporting back in the other direction) was also 
raised as a method of dealing with congestion, but it is not a part of MLEF. I 
don't consider it part of CAC either, but that a question of definition.

MIke Pierce

---

From: [email-masked]
Date: Mon, 8 Dec 2003 20:22:50 EST

MIke Pierce