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

["James M. Polk" <[e-mail]>]

Comments below

At 04:26 PM 1/29/2004 -0500, Ken Carlberg wrote:
>James,
>
> > 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).
>
>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?

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
>application or underlying network service, but the hooks are there to at
>least inform the users of loss versus silence.

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).


>-ken
>
>
>_______________________________________________
>Ieprep mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ieprep


cheers,
James

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


_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep