RE: [Ieprep] IDs to consider

"Steve Silverman" <steves@shentel.net> Fri, 15 October 2004 15:45 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14867 for <ieprep-web-archive@ietf.org>; Fri, 15 Oct 2004 11:45:07 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIURs-0002bi-4U for ieprep-web-archive@ietf.org; Fri, 15 Oct 2004 11:56:57 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUBl-0007AI-8E; Fri, 15 Oct 2004 11:40:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CITwm-0004I7-1V for ieprep@megatron.ietf.org; Fri, 15 Oct 2004 11:24:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12554 for <ieprep@ietf.org>; Fri, 15 Oct 2004 11:24:45 -0400 (EDT)
Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIU8A-0001xg-BP for ieprep@ietf.org; Fri, 15 Oct 2004 11:36:34 -0400
Received: from Steve (ha30s122.d.shentel.net [204.111.23.122]) by seahorse.shentel.net (8.12.11/8.12.11) with SMTP id i9FFODbk006174; Fri, 15 Oct 2004 11:24:13 -0400
From: Steve Silverman <steves@shentel.net>
To: "King, Kimberly S." <KIMBERLY.S.KING@saic.com>, "Ieprep (E-mail)" <ieprep@ietf.org>
Subject: RE: [Ieprep] IDs to consider
Date: Fri, 15 Oct 2004 11:24:34 -0400
Message-ID: <CIEELMKPOOAMCIAKANLBGEHPEEAA.steves@shentel.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <D24D16A6707B0A4B9EF084299CE99B3910ADAF99@mcl-its-exs02.mail.saic.com>
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7bit
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Content-Transfer-Encoding: 7bit

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: ieprep-bounces@ietf.org
> [mailto:ieprep-bounces@ietf.org]On Behalf
> Of King, Kimberly S.
> Sent: Friday, October 15, 2004 10:15 AM
> To: Ieprep (E-mail)
> Subject: [Ieprep] IDs to consider
>
>
>
>
> 	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
> Ieprep@ietf.org
> https://www1.ietf.org/mailman/listinfo/ieprep
>


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