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

>
> 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-concern
> s-00.txt, and
> http://www.ietf.org/internet-drafts/draft-baker-mlpp-that-wo
> rks-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.

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

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

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

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

...

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

James:  Have you published anything on this idea?

Steve

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