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
- [Ieprep] IDs to consider King, Kimberly S.
- RE: [Ieprep] IDs to consider Steve Silverman
- RE: [Ieprep] IDs to consider King, Kimberly S.
- Re: [Ieprep] IDs to consider James M. Polk
- RE: [Ieprep] IDs to consider Fred Baker
- RE: [Ieprep] IDs to consider Steve Silverman
- Re: [Ieprep] IDs to consider Mpierce1
- Re: [Ieprep] IDs to consider Janet P Gunn