RE: IDs to consider

comments below
>
>
> At 11:24 AM 10/15/04 -0400, Steve Silverman wrote:
> >if the CAC works as advertised, MLEF will have no effect
> but if for any
> >reason the CAC is unable to avoid congestion, MLEF will
> ensure that only
> >lower priority packets are dropped.  Some of us have
> doubts as to how well
> >a CAC can work.
>
> That's fair. I can demonstrate the result of MLEF when CAC
> is misconfigured
> or inoperative, and have in the JUICE demos. Can you
> demonstrate that CAC
> is ineffective?

If I demonstrated an ineffective CAC, you would say I did a poor
implementation.  I think it is up
to the vendors to demonstrate an effective CAC under conditions that
that customer thinks are realistic.


>
> >The DOD can not deploy VoIP without a prioritization
> mechanism.  MLEF is
> >such a prioritization mechanism.
>
> See, this is where I go a little nutty.

Take a few deep breaths.  :-)

>
> In a circuit switched environment, a circuit is a circuit
> is a circuit.
> There is no differentiation between them in any way, and no
> flag on the
> data stream exchanged by the circuit that indicates its
> priority. The only
> control is in the control plane, and the control is
> effective for MLPP.
>
> In an ATM environment, a VC is a VC is a VC. They have
> different scheduling
> algorithms depending on how they were negotiated, but
> telephony uses
> something not very different from EF - CBR. There is no
> differentiation
> between them in any way, and no flag on the data stream
> exchanged by the
> circuit that indicates its priority. The only control is in
> the control
> plane, and the control is effective for MLPP.
>
> In an IP environment, you state that you not certain that a
> bandwidth-aware
> CAC mechanism can possibly work, and state that there is a
> requirement for
> a backup plan that imposes DSCP-stamping indicating the
> priority of the
> call.

There is a requirement for a backup plan so that critical users call
work.  How this
is to be implemented is to be determined.  I haven't figured out a
system I trust without
packet marking since intermediate routers don't "know" about the
connections.


The HAIPE folks have stated concerns with this
> approach on the basis
> that it identifies the data streams of highest importance
> to a motivated
> and capable adversary. But "DOD can not deploy VoIP without a
> prioritization mechanism".

This is a legitimate concern that will have to be balanced against the
need to ensure critical calls
get thru and work.  One solution is link encryption of critical links.

>
> I agree that DoD requires a call prioritization mechanism that is
> bandwidth-aware and route-aware. I don't understand why it
> is required in
> the data plane, or why CAC is suspect given the many years
> of experience
> that DoD has with bandwidth-aware/route-aware CAC in other
> technologies?
>

Previous experience was with TCP-based applications that were
relatively insensitive
to occasional packet losses.  Voice is different.

Have you tested any CAC implementations using silence suppression
(Voice Activity Detection) over a limited bandwidth network?


Steve