Subject: [Ieprep] IDs to consider

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 15 Oct 2004 10:15:14 -0400

draft-baker-tsvwg-mlef-concerns-02.txt
	draft-baker-tsvwg-mlpp-that-works-02.txt

The above IDs are not quite in our charter but they are 
relevant to the ieprep mission - we would like people 
on the list to review and comment on them with a view 
to recommending to the IESG that they
be published as informational RFCs

Scott & Kimberly 

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

---

From: "Steve Silverman" <[email-masked]>
Date: Fri, 15 Oct 2004 11:24:34 -0400

I would like to ask why this is being considered in the IEPREP WG when
the drafts were always submitted to
the TSVWG and have been discussed there.  I don't think there was any
notice given to the tsvwg that this topic was being moved here.  (Then
again, when Fred submitted these drafts to that WG on work that had
been submitted here, he never announced on this list that he was
moving the topic to that forum.  Despite the fact that he was
attacking my draft, he never notified me that he was doing so. )

As to the draft itself, it is still attacks MLEF (the title throughout
the document after the first page is "MLEF Considered Harmful") on the
assumption that no CAC is being used.  As has been stated in recent
MLEF drafts, in discussion in TSVWG, and in private conversations with
both Fred Baker and James Polk, 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. If a
100% effective CAC can be implemented and demonstrated, MLEF will be
unnecessary and a tiny amount of code wasted.  But if congestion does
arise, the high priority  call packets will get thru.

The dropping of packets due to congestion is not the fault of MLEF, it
is necessitated by the congestion.  All MLEF is doing is deciding
WHICH packets are to be dropped.  It does not add significant
processing or introduce any delay to the packets.

The DOD can not deploy VoIP without a prioritization mechanism.  MLEF
is such a prioritization mechanism.

Steve Silverman

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of King, Kimberly S.
> Sent: Friday, October 15, 2004 10:15 AM
> To: Ieprep (E-mail)
> Subject: [Ieprep] IDs to consider
>
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 15 Oct 2004 14:39:34 -0700

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?

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

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

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?

---

From: "Steve Silverman" <[email-masked]>
Date: Sat, 16 Oct 2004 10:16:21 -0400

comments below
> or inoperative, and have in the JUICE demos. Can you

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.

> See, this is where I go a little nutty.

Take a few deep breaths.  :-)

> 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

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.

> that DoD has with bandwidth-aware/route-aware CAC in other

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