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

From: "Steve Silverman" <[email-masked]>
Date: Thu, 29 Jan 2004 11:33:56 -0500

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Fred Baker
> Sent: Tuesday, January 27, 2004 9:36 PM
> To: Janet P Gunn
> Cc: [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Jan 2004 12:25:45 -0600

comments below

At 11:33 AM 1/29/2004 -0500, Steve Silverman wrote:
>critical are unaffected.

without active feedback to those lower priority sessions....

>Actual experiment has shown that this does
>work.

yes it does - but without regard to any call quality.

If the surge is 25 or 50 or 75% above maximum load possible, then what 
happens to the lower priority calls? There isn't any feedback to the users 
(other than pure silence). Further, there isn't any feedback (signaling) to 
their devices what's happening or to hang up the call. There's nothing. How 
long is this expected to last for? No one knows.

Further, no one can test the system (because of no feedback).

No one can point to where there might be potential problems with this 
architecture either (is the system behaving correctly?). There is no 
feedback to discover or monitor its performance. Where is it supposed to be 
discovered that a link between any two routers isn't fast enough (because 
there are perhaps frequent silence periods)?

>will limit the reaction time of the system

where's the propagation delay? the surge won't happen without the signaling 
having already occurred through the congestion point; meaning the system 
(read: routers) already know about all the call (flow) attempts - even when 
there is too much offered load for an interface. The router can either say 
"sorry, not enough resources available to complete your call attempt" or 
"sorry, but there was another call with higher priority, and I have to shut 
your call down now". BTW - these are device signals, this isn't a .wav file 
playing to the user or anything.

>and the computation to
>oversee the entire theatre may also be a limiting factor.

see above, computation occurs at the router that is experiencing this 
surge. It is in charge of the packet forwarding. It is aware of all the 
existing flows it has accepted. It is in charge of accepting new flows and 
preempting lesser priority ones if multilevel offered load exceeds the 
maximum load possible.

>This may
>you need something local and fast reacting

In the router itself isn't fast enough...?

>(at the packet level rather
>than the call level)

packet level = Layer 3

Call level = what? Layer 4, 5 or 7?

>to ensure that the high priority packets get
>thru.

I am a believer in high priority calls getting through, and for all calls 
that remain up - having all their packets arrive safely too.

>Steve Silverman

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: "Ken Carlberg" <[email-masked]>
Date: Thu, 29 Jan 2004 16:26:41 -0500

James,

> (other than pure silence). Further, there isn't any feedback
(signaling)
> to
> their devices what's happening or to hang up the call. There's
nothing.
> How long is this expected to last for? No one knows.
> 

I'm sorry if I missed an argument that may be in one of the related
tsvwg drafts, but is there a specific form of the feedback you are
looking for?  We have RTCP reports that can provide a measure of
feedback on an end-to-end basis.  Admittedly, these are generally not
provided to the user and they are not targeted towards a specific
application or underlying network service, but the hooks are there to at
least inform the users of loss versus silence.

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Jan 2004 17:04:23 -0600

Comments below

At 04:26 PM 1/29/2004 -0500, Ken Carlberg wrote:
>looking for?

This thread is based on:

http://www.ietf.org/internet-drafts/draft-silverman-diffserv-mlefphb-02

and the response in both

http://www.ietf.org/internet-drafts/draft-baker-mlef-concerns-00.txt, and
http://www.ietf.org/internet-drafts/draft-baker-mlpp-that-works-00.txt

This isn't a direct ETS topic - but it is near the topic, and because of 
recent conversations on the list and elsewhere that infer MLEF is a 
replacement for CAC.

Both the bottom two contend that in an MLPP service, there must be a 
feedback mechanism informing the endpoints if there has been a preemption 
of resources. The MLEF ID contends that lower priority packets should be 
vulnerable to packet loss in times of contention without regard to the 
impact on voice quality for an entire precedence level of calls through 
that congested interface.

We have demonstrated in lab tests to DISA and various other organizations 
that, a 1%, 5% and higher packet loss has significant impact on Voice 
Quality (VQ) of all codecs, while at the same time - having some 
organizations maintain the requirement that VQ cannot drop below a 4.0 MOS.

>We have RTCP reports that can provide a measure of
>feedback on an end-to-end basis.

Aren't these for after a call, and propagated up to the requesting NM station?

>Admittedly, these are generally not
>provided to the user

One of the primary MLPP Service requirements is to have a tone or 
announcement to all affected users if there is preemption at the endpoint 
or in the network.

>and they are not targeted towards a specific

It is Fred Baker's and my opinion that an In_band soft_state control plane 
would be the very best of all worlds to provide all manners of offered load 
to capacity analysis at the congestion point - and not continue to rely on 
some server architecture to maintain the congestive state of all interfaces 
for 1000s of router interfaces (in rear-time).

cheers,
James

                                *******************

---

From: "Ken Carlberg" <[email-masked]>
Date: Thu, 29 Jan 2004 19:29:54 -0500

Thanks for the recap.

> Aren't these for after a call, and propagated up to the requesting NM

The reports are sent periodically throughout the session between end
points.  Implementors make their own choices if and when to display the
stats.  At UCL, the RAT (VoIP) tool allows the user to see the stats
updated in real time.  For other implementations, your mileage may very.
 
-ken

---

From: "Steve Silverman" <[email-masked]>
Date: Thu, 29 Jan 2004 19:33:02 -0500

> recent conversations on the list and elsewhere that infer MLEF is a

We are not saying MLEF is a replacement for CAC, but a compliment.  I
don't think that a CAC alone can meet the DOD requirements but I think
that
a CAC and MLEF can meet those requirements (or most of them).

> of resources.

I agree with this but doubt that the CAC can do this job in real time.

The MLEF ID contends that lower priority
> packets should be

I believe that in the event of an overload, this is unavoidable even
if only for a short time.

...

> for 1000s of router interfaces (in real-time).

James:  Have you published anything on this idea?

Steve