RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt

If the offered load exceeds the network capacity, some packets will be
dropped.  If a line is at
95% of capacity, a 10% surge would cause 5% of the packets to be
dropped, degrading most of the conversations.  ( I am simplifying here
but I think this is clear.)

The benefit of multiple DSCPs is that the sessions designated most
critical are unaffected. Actual experiment has shown that this does
work.

In draft-baker-tsvwg-mlpp-that-works.00 it is assumed that the CAC
will ensure that voice is not overloaded.
Two problems with this are:

	1)  If silence suppression is used and the bandwidth "oversubscribed"
(standard practice) then sometimes, more people on one end will talk
and cause congestion.

	2)  If the area controlled by the CAC is large, propagation delay
will limit the reaction time of the system and the computation to
oversee the entire theatre may also be a limiting factor.  This may
cause short congestion incidents (several seconds long) which could be
mitigated by MLEF.  I'm not saying you don't also need the CAC.  I'm
saying
you need something local and fast reacting (at the packet level rather
than the call level) to ensure that the high priority packets get
thru.

Steve Silverman

> -----Original Message-----
> From: ieprep-admin@ietf.org
> [mailto:ieprep-admin@ietf.org]On Behalf Of
> Fred Baker
> Sent: Tuesday, January 27, 2004 9:36 PM
> To: Janet P Gunn
> Cc: ieprep@ietf.org
> Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt
>
>
> At 12:32 PM 1/27/2004, Janet P Gunn wrote:
> >As Fred Baker says in
> draft-baker-tsvwg-mlpp-that-works.00.txt, if call
> >admission is working properly, traffic marking is not
> needed in normal
> >operations.
>
> lest I be misunderstood, let me restate that. What I wrote was:
>
>     One will ask the value of the multiple DSCPs. They are,
> in fact, of
>     limited to no value in normal operation, as all vice and video
>     traffic should have been admitted, and therefore
> capacity will have
>     been assigned to them. The behavior of this service will be
>     indistinguishable from the EF PHB regardless of traffic marking.
>
> In retrospect, I wonder what the vice traffic would be :^)
>
> This is not to be understood as saying "no traffic marking
> is required";
> one still needs RFC 3246. But if bandwidth admission is operating
> correctly, having N different marks will be operationally
> indistinguishable
> from having a single EF mark, as the total number of bytes
> on the wire will
> be the same.
>
> >It is in this context that ETS calls must be given a high
> probability of
> >meeting the QoS criteria, even when network congestion and
> or damage are
> >severe.
>
> I wonder if we are communicating here. RFC 3246 is designed
> to operate in a
> congested network, and to operate in a network in which
> routing may change.
> The comment in the mlpp-that-works draft - which if it is
> giving cause for
> confusion I will happily remove - is basically me bending
> over backwards to
> be intellectually honest and see if I can find a case where
> CAC may be
> insufficient.
>
> Think about this for a moment: the argument being placed
> for MLEF is that
> even in the presence of some loss, voice is intelligible.
> If that is true,
> then just after a route change, during the brief interval
> between the data
> flow being switched to a new path and the CAC following
> that and either
> OKing the flow or deciding to shut down the call, when
> there may be some
> loss, voice should be equally intelligible, no?
>
> Or does the argument that voice is able to work around a
> modest level of
> loss only work when it comes from the proponents of
> multiple code points?

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep