From exim@www1.ietf.org Mon Jan 12 16:11:46 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19931 for ; Mon, 12 Jan 2004 16:11:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9LC-0005du-Ef for ieprep-archive@odin.ietf.org; Mon, 12 Jan 2004 16:11:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CLBIY6021686 for ieprep-archive@odin.ietf.org; Mon, 12 Jan 2004 16:11:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9LC-0005dh-Bd for ieprep-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 16:11:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19802 for ; Mon, 12 Jan 2004 16:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9LA-0000Ng-00 for ieprep-web-archive@ietf.org; Mon, 12 Jan 2004 16:11:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9J9-00008K-00 for ieprep-web-archive@ietf.org; Mon, 12 Jan 2004 16:09:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag9HC-0007id-00 for ieprep-web-archive@ietf.org; Mon, 12 Jan 2004 16:07:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9H5-0004xh-0w; Mon, 12 Jan 2004 16:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9H0-0004wC-R8 for ieprep@optimus.ietf.org; Mon, 12 Jan 2004 16:06:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19281; Mon, 12 Jan 2004 16:06:56 -0500 (EST) Message-Id: <200401122106.QAA19281@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 12 Jan 2004 16:06:56 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : ETS Requirements for a Single Administrative Domain Author(s) : K. Carlberg Filename : draft-ietf-ieprep-domain-req-00.txt Pages : 7 Date : 2004-1-12 This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document is an extension of the General Requirements of [2] and focuses on a more specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-domain-req-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ieprep-domain-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-domain-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-12154409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-domain-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-domain-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-12154409.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jan 12 16:11:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19948 for ; Mon, 12 Jan 2004 16:11:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9LD-0005eF-QY for ieprep-archive@odin.ietf.org; Mon, 12 Jan 2004 16:11:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0CLBJkv021704 for ieprep-archive@odin.ietf.org; Mon, 12 Jan 2004 16:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9LD-0005dz-MJ for ieprep-web-archive@optimus.ietf.org; Mon, 12 Jan 2004 16:11:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19807 for ; Mon, 12 Jan 2004 16:11:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9LC-0000Nw-00 for ieprep-web-archive@ietf.org; Mon, 12 Jan 2004 16:11:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9JA-00008S-00 for ieprep-web-archive@ietf.org; Mon, 12 Jan 2004 16:09:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag9HC-0007ig-00 for ieprep-web-archive@ietf.org; Mon, 12 Jan 2004 16:07:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9H4-0004xK-CD; Mon, 12 Jan 2004 16:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9Gv-0004w6-39 for ieprep@optimus.ietf.org; Mon, 12 Jan 2004 16:06:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19263; Mon, 12 Jan 2004 16:06:50 -0500 (EST) Message-Id: <200401122106.QAA19263@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ieprep@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 12 Jan 2004 16:06:50 -0500 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-frame-00.txt Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Emergency Preparedness Working Group of the IETF. Title : A Framework for Supporting ETS Within a Single Administrative Domain Author(s) : K. Carlberg Filename : draft-ietf-ieprep-domain-frame-00.txt Pages : 15 Date : 2004-1-12 This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting ETS within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ieprep-domain-frame-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ieprep-domain-frame-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ieprep-domain-frame-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-1-12154258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-domain-frame-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-domain-frame-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-12154258.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jan 15 09:52:27 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08996 for ; Thu, 15 Jan 2004 09:52:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8pS-0003tt-Kd for ieprep-archive@odin.ietf.org; Thu, 15 Jan 2004 09:50:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FEocL5014987 for ieprep-archive@odin.ietf.org; Thu, 15 Jan 2004 09:50:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8pS-0003te-F9 for ieprep-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 09:50:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08964 for ; Thu, 15 Jan 2004 09:50:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8pQ-00060Z-00 for ieprep-web-archive@ietf.org; Thu, 15 Jan 2004 09:50:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8oS-0005xc-00 for ieprep-web-archive@ietf.org; Thu, 15 Jan 2004 09:49:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah8nw-0005v0-00 for ieprep-web-archive@ietf.org; Thu, 15 Jan 2004 09:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8nt-0003m4-Bl; Thu, 15 Jan 2004 09:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah8nU-0003lV-P3 for ieprep@optimus.ietf.org; Thu, 15 Jan 2004 09:48:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08899 for ; Thu, 15 Jan 2004 09:48:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah8nS-0005u3-00 for ieprep@ietf.org; Thu, 15 Jan 2004 09:48:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah8mZ-0005rf-00 for ieprep@ietf.org; Thu, 15 Jan 2004 09:47:40 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1Ah8lw-0005li-00 for ieprep@ietf.org; Thu, 15 Jan 2004 09:47:00 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 5445FCF3F6; Thu, 15 Jan 2004 09:46:25 -0500 (EST) To: ieprep@ietf.org Message-Id: <20040115144625.5445FCF3F6@newdev.harvard.edu> Date: Thu, 15 Jan 2004 09:46:25 -0500 (EST) From: sob@harvard.edu (Scott Bradner) Subject: [Ieprep] IEPREP in Korea Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 at this point we do not plan to have an ieprep meeting in Korea if feel very strongly that we should please let us know Scott & Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jan 19 10:45:58 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22413 for ; Mon, 19 Jan 2004 10:45:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aibaj-0000a6-Kx for ieprep-archive@odin.ietf.org; Mon, 19 Jan 2004 10:45:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0JFjT91002230 for ieprep-archive@odin.ietf.org; Mon, 19 Jan 2004 10:45:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aibaj-0000Zt-Hd for ieprep-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 10:45:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22316 for ; Mon, 19 Jan 2004 10:45:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aibah-0004jH-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 10:45:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AibZe-0004ZA-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 10:44:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AibXl-0004Jj-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 10:42:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AibXN-0000LE-SB; Mon, 19 Jan 2004 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AibWn-0000I0-Q7 for ieprep@optimus.ietf.org; Mon, 19 Jan 2004 10:41:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21936 for ; Mon, 19 Jan 2004 10:41:21 -0500 (EST) From: saq66@umkc.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AibWg-0004Er-00 for ieprep@ietf.org; Mon, 19 Jan 2004 10:41:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AibSO-0003wD-00 for ieprep@ietf.org; Mon, 19 Jan 2004 10:36:54 -0500 Received: from fw02.rockwellcollins.com ([205.175.225.45] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1AibPL-0003hB-00 for ieprep@ietf.org; Mon, 19 Jan 2004 10:33:43 -0500 Received: by fw02.Rockwellcollins.com; id JAA03353; Mon, 19 Jan 2004 09:33:31 -0600 (CST) Received: from nodnsquery(131.198.169.131) by fw02.collins.rockwell.com via smap (V5.5) id xmann6092; Mon, 19 Jan 04 09:29:00 -0600 Received: from smtpgw01.rockwellcollins.com (localhost [127.0.0.1]) by vs01.rockwellcollins.com (8.11.7+Sun/8.11.7) with ESMTP id i0JFClr22401 for ; Mon, 19 Jan 2004 09:12:48 -0600 (CST) Received: from barn.comsys.rockwell.com (unverified) by smtpgw01.rockwellcollins.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Mon, 19 Jan 2004 09:12:46 -0600 Received: by barn.comsys.rockwell.com; id JAA12533; Mon, 19 Jan 2004 09:12:43 -0600 (CST) Received: from dlprabloom.dallas.rockwellcollins.com(131.199.63.237) by barn.comsys.rockwell.com via smap (V4.2) id xma011938; Mon, 19 Jan 04 09:12:01 -0600 Date: Mon, 19 Jan 2004 09:12:00 -0600 To: ieprep@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------370316505786253" Subject: [Ieprep] Hi Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=FROM_ENDS_IN_NUMS,NO_REAL_NAME autolearn=no version=2.60 ----------370316505786253 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test =) femtsiyrotocbhc -- Test, yep. ----------370316505786253 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on vs01) muatksubuqj.exe is removed from here because it contains a virus. --------------------------------------------------------- ----------370316505786253 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on vs01) Found virus WORM_BAGLE.A in file muatksubuqj.exe The uncleanable file muatksubuqj.exe is moved to /var/log/iscan/virus/virGSDf8aOdX. The Rockwell Collins virus detection network has detected a virus in a message sent to you Detail about the file and it's status are listed above this message If you received the attachment, it was repaired. If you did not receive the attachment, it was quarantined on a Rockwell Collins Server. If you are a Rockwell Collins employee, refer to the following web page for additional information: http://rwebapps.rockwellcollins.com/ebusiness/organization/e-business-operations/it-infrastructure/it-security/viruses.asp The Rockwell Collins Virus Team --------------------------------------------------------- ----------370316505786253-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jan 19 23:18:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28314 for ; Mon, 19 Jan 2004 23:18:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinL1-0000Lm-DV for ieprep-archive@odin.ietf.org; Mon, 19 Jan 2004 23:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0K4I33K001340 for ieprep-archive@odin.ietf.org; Mon, 19 Jan 2004 23:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinL1-0000LV-3e for ieprep-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 23:18:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28292 for ; Mon, 19 Jan 2004 23:18:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AinKz-0002dN-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 23:18:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AinK0-0002aC-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 23:17:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AinJ6-0002Xk-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 23:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinJ5-0008QP-N2; Mon, 19 Jan 2004 23:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinIT-0008Om-VK for ieprep@optimus.ietf.org; Mon, 19 Jan 2004 23:15:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28209 for ; Mon, 19 Jan 2004 23:15:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AinIS-0002VN-00 for ieprep@ietf.org; Mon, 19 Jan 2004 23:15:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AinHY-0002QU-00 for ieprep@ietf.org; Mon, 19 Jan 2004 23:14:29 -0500 Received: from [203.199.83.147] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1AinGo-0002Kd-00 for ieprep@ietf.org; Mon, 19 Jan 2004 23:13:43 -0500 Received: (qmail 8356 invoked by uid 510); 20 Jan 2004 04:13:38 -0000 Date: 20 Jan 2004 04:13:38 -0000 Message-ID: <20040120041338.8355.qmail@webmail25.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 20 jan 2004 04:13:38 -0000 MIME-Version: 1.0 From: "Arun Kumar" Reply-To: "Arun Kumar" To: ieprep@ietf.org Content-type: multipart/alternative; boundary="Next_1074572018---0-203.199.83.147-8349" Subject: [Ieprep] SSL on microcontroller Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_30_40,HTML_IMAGE_ONLY_06,HTML_MESSAGE,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 This is a multipart mime message --Next_1074572018---0-203.199.83.147-8349 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHI,
=0A
=0AI dont know if this a relavent question in this foru= m.
=0ADoes anyone know how to implement SSL on microcontrollers?
=0AO= r
=0AIs there some source code available?
=0A
=0ARegards,
=0AA= run
=0A
=0A
=0A=0A

=0A

=0A=0A --Next_1074572018---0-203.199.83.147-8349 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable HI,=0A=0AI dont know if this a relavent question in this forum.=0ADoes anyo= ne know how to implement SSL on microcontrollers?=0AOr =0AIs there some sou= rce code available?=0A=0ARegards,=0AArun=0A=0A=0A --Next_1074572018---0-203.199.83.147-8349-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Mon Jan 19 23:25:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28649 for ; Mon, 19 Jan 2004 23:25:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinRm-0000ZX-Et for ieprep-archive@odin.ietf.org; Mon, 19 Jan 2004 23:25:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0K4P2eH002190 for ieprep-archive@odin.ietf.org; Mon, 19 Jan 2004 23:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinRk-0000Yv-27 for ieprep-web-archive@optimus.ietf.org; Mon, 19 Jan 2004 23:25:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28578 for ; Mon, 19 Jan 2004 23:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AinRi-00039v-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 23:24:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AinQj-00030d-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 23:23:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AinPo-0002x3-00 for ieprep-web-archive@ietf.org; Mon, 19 Jan 2004 23:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinPp-0000SW-5U; Mon, 19 Jan 2004 23:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AinOu-0000S4-9b for ieprep@optimus.ietf.org; Mon, 19 Jan 2004 23:22:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28508 for ; Mon, 19 Jan 2004 23:22:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AinOs-0002tq-00 for ieprep@ietf.org; Mon, 19 Jan 2004 23:22:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AinO1-0002rm-00 for ieprep@ietf.org; Mon, 19 Jan 2004 23:21:10 -0500 Received: from [203.199.83.148] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1AinN8-0002oX-00 for ieprep@ietf.org; Mon, 19 Jan 2004 23:20:14 -0500 Received: (qmail 10143 invoked by uid 510); 20 Jan 2004 04:20:10 -0000 Date: 20 Jan 2004 04:20:10 -0000 Message-ID: <20040120042010.10141.qmail@webmail26.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 20 jan 2004 04:20:10 -0000 MIME-Version: 1.0 From: "Arun Kumar" Reply-To: "Arun Kumar" To: ieprep@ietf.org Content-type: multipart/alternative; boundary="Next_1074572410---0-203.199.83.148-10136" Subject: [Ieprep] Spit TCP connection Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_IMAGE_ONLY_10,HTML_MESSAGE,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 This is a multipart mime message --Next_1074572410---0-203.199.83.148-10136 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0A
=0AI feel that there should be 2 seperate stacks(TCP/IP= ) for split TCP connection.
=0ABut what is the interfacing between these= two stack and at what layer should the interfacing or interaction take pla= ce. I feel the interaction should take place at a layer at TCP or above it = but below the Session layer.
=0A
=0AIS there any third party open so= urce code available for TCP split connection.?
=0A
=0A
=0ARegards,=
=0AArun
=0A=0A

=0A

=0A=0A --Next_1074572410---0-203.199.83.148-10136 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI feel that there should be 2 seperate stacks(TCP/IP) for split TC= P connection.=0ABut what is the interfacing between these two stack and at = what layer should the interfacing or interaction take place. I feel the int= eraction should take place at a layer at TCP or above it but below the Sess= ion layer. =0A=0AIS there any third party open source code available for TC= P split connection.?=0A=0A=0ARegards,=0AArun=0A --Next_1074572410---0-203.199.83.148-10136-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Tue Jan 27 17:34:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27455 for ; Tue, 27 Jan 2004 17:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbmV-0000Og-OV for ieprep-archive@odin.ietf.org; Tue, 27 Jan 2004 17:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RMY3rE001520 for ieprep-archive@odin.ietf.org; Tue, 27 Jan 2004 17:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbmV-0000OR-Hs for ieprep-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 17:34:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27439 for ; Tue, 27 Jan 2004 17:33:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlbmT-0006Ty-00 for ieprep-web-archive@ietf.org; Tue, 27 Jan 2004 17:34:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlblV-0006RF-00 for ieprep-web-archive@ietf.org; Tue, 27 Jan 2004 17:33:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Albkc-0006OM-00 for ieprep-web-archive@ietf.org; Tue, 27 Jan 2004 17:32:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlbkY-0000IP-3N; Tue, 27 Jan 2004 17:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Albjk-0000Hj-2r for ieprep@optimus.ietf.org; Tue, 27 Jan 2004 17:31:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27343 for ; Tue, 27 Jan 2004 17:31:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Albjh-0006Kz-00 for ieprep@ietf.org; Tue, 27 Jan 2004 17:31:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Albif-0006HT-00 for ieprep@ietf.org; Tue, 27 Jan 2004 17:30:06 -0500 Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx with esmtp (Exim 4.12) id 1Albi2-0006E6-00; Tue, 27 Jan 2004 17:29:27 -0500 Received: from csc.com (va-fch32.csc.com [20.6.39.233]) by amer-mta02.csc.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0RMUK4L007003; Tue, 27 Jan 2004 17:30:20 -0500 (EST) Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: Cc: ieprep@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Janet P Gunn Date: Tue, 27 Jan 2004 17:32:32 -0500 X-MIMETrack: Serialize by Router on VA-FCH32/SRV/CSC(Release 6.0.3|September 26, 2003) at 01/27/2004 05:27:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I think that, under "normal" circumstances, the QoS mechanisms for conventional VoIP will be more than adequate to support ETS, and "special treatment" in Call Admission Control is what will be needed for ETS. But when network congestion and/ or damage are severe, the "conventional" mechanisms may no longer be adequate (especially when network failure initiates the re-routing of Label Switched Paths, and significantly reduces the available capacity). As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call admission is working properly, traffic marking is not needed in normal operations. It is when there are route changes - typically due to network failures - that marking is needed. When there are network failures, the capacity and route assignments on which call admission was based no longer apply, the QoS cannot be guaranteed until the new routes are stabilized, and the call admission process adapts to the new capacity and routes. This may be a very local effect, of quite short duration. But it has a significant impact on the call quality of the calls that are affected. While that paper addresses an IP implementation of MLPP, many of the same concerns apply to ETS. Network failures, and/or massive and sustained statistical anomalies (large, local bursts), and the associated route changes, are the problems we need to focus on. It is in this context that ETS calls must be given a high probability of meeting the QoS criteria, even when network congestion and or damage are severe. The requirements in draft-ietf-ieprep-domain-req-00.txt don't seem to address this, and the framework in draft-ietf-ieprep-domain-frame-00.txt doesn't seem to solve it. In draft-gunn-ieprep-ip-telephony-gap-00.txt we address the need to support ETS SLAs to provide High Probability Toll-Quality Voice - ETS calls must be given adequate resources through the network to ensure a high probability that their packets suffer loss, delay, and jitter consistent with achieving toll-quality voice even when network congestion and / or damage are severe. Of course, one of the conditions for such a service is that the ETS calls are limited in terms of their relative and/or absolute use of resources. And if the damage is so severe that there are no available paths, then obviously they can't be given "adequate resources". But as long as those conditions are met, the ETS calls should get their QoS, even when the "normal" calls lose theirs, even if for a short time. In addition, in order for an ETS service to be viable service (i.e., in order for a provider to be willing to offer it at a "reasonable" cost), there are several additional requirements. The impact on non-ETS calls should be minimized, consistent with providing the ETS service. In particular, the impact on non-ETS calls, when there are no active ETS calls in the network, should be minimal, if any. So any solution that requires a lot of additional work on every packet, and/or at every router, all the time, is not going to be viable. There needs to be some sort of limit on the volume of ETS traffic- if ALL the traffic using a particular resource at a particular moment in time is ETS traffic, it becomes impossible to provide priority treatment. Limiting the volume of ETS traffic also reduces its attractiveness as a vehicle for a DoS attacks (though it might make it more vulnerable to a DoS attack). The impact on network management and administration should be minimized. Approaches which require a lot of additional configuration and administration, just for ETS, during normal network administration, are not going to be viable. Such approaches are also unlikely to be sufficiently reliable, as there is a significant chance that undetected errors will be made in the ETS specific configuration tasks. Approaches which build on existing hardware, software, protocols and procedures are far more likely to be financially viable, and far more likely to be reliable, than approaches that rely on new or untested protocols and techniques. What is the appropriate way to reflect these concerns? ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jan 28 13:12:20 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17866 for ; Wed, 28 Jan 2004 13:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluAM-0004GW-Bj for ieprep-archive@odin.ietf.org; Wed, 28 Jan 2004 13:11:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SIBsaH016390 for ieprep-archive@odin.ietf.org; Wed, 28 Jan 2004 13:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AluAM-0004GH-7f for ieprep-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:11:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17863 for ; Wed, 28 Jan 2004 13:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AluAK-00007L-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:11:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu9M-00000O-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:10:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Alu8b-0007ih-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu8Z-00047P-9z; Wed, 28 Jan 2004 13:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alu8C-00046F-OP for ieprep@optimus.ietf.org; Wed, 28 Jan 2004 13:09:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17703 for ; Wed, 28 Jan 2004 13:09:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alu8A-0007f6-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:09:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alu7C-0007Ub-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:08:39 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Alu6E-0007Fm-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:07:38 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Jan 2004 10:07:10 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0SI74nI017937; Wed, 28 Jan 2004 10:07:07 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (sjc-vpn3-604.cisco.com [10.21.66.92]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APS34422; Wed, 28 Jan 2004 10:06:47 -0800 (PST) Message-Id: <6.0.1.1.2.20040127162316.048affd8@mira-sjc5-b.cisco.com > X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 27 Jan 2004 16:35:49 -1000 To: Janet P Gunn From: Fred Baker Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: ieprep@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="-==-=-=-=======-=----===---=--=--=-=-==-===--=-="; protocol="application/pgp-signature"; micalg=pgp-sha1 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=AWL,DATE_IN_PAST_12_24, FORGED_MUA_EUDORA,INVALID_MSGID autolearn=no version=2.60 ---==-=-=-=======-=----===---=--=--=-=-==-===--=-= Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:32 PM 1/27/2004, Janet P Gunn wrote: >As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call >admission is working properly, traffic marking is not needed in normal >operations. lest I be misunderstood, let me restate that. What I wrote was: One will ask the value of the multiple DSCPs. They are, in fact, of limited to no value in normal operation, as all vice and video traffic should have been admitted, and therefore capacity will have been assigned to them. The behavior of this service will be indistinguishable from the EF PHB regardless of traffic marking. In retrospect, I wonder what the vice traffic would be :^) This is not to be understood as saying "no traffic marking is required"; one still needs RFC 3246. But if bandwidth admission is operating correctly, having N different marks will be operationally indistinguishable from having a single EF mark, as the total number of bytes on the wire will be the same. >It is in this context that ETS calls must be given a high probability of >meeting the QoS criteria, even when network congestion and or damage are >severe. I wonder if we are communicating here. RFC 3246 is designed to operate in a congested network, and to operate in a network in which routing may change. The comment in the mlpp-that-works draft - which if it is giving cause for confusion I will happily remove - is basically me bending over backwards to be intellectually honest and see if I can find a case where CAC may be insufficient. Think about this for a moment: the argument being placed for MLEF is that even in the presence of some loss, voice is intelligible. If that is true, then just after a route change, during the brief interval between the data flow being switched to a new path and the CAC following that and either OKing the flow or deciding to shut down the call, when there may be some loss, voice should be equally intelligible, no? Or does the argument that voice is able to work around a modest level of loss only work when it comes from the proponents of multiple code points? ---==-=-=-=======-=----===---=--=--=-=-==-===--=-= Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP 7.0.1 iQA/AwUBQBcgBG4xHWxyLJtDEQJ5jwCfUYisYdJMVT4qh2Htls40SSgyViEAmgOR IHVbdg1xMdHLZYskAyIHR55n =m2x1 -----END PGP MESSAGE----- ---==-=-=-=======-=----===---=--=--=-=-==-===--=-=-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Wed Jan 28 13:52:24 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19666 for ; Wed, 28 Jan 2004 13:52:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alun6-00078B-IE for ieprep-archive@odin.ietf.org; Wed, 28 Jan 2004 13:51:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0SIpunS027405 for ieprep-archive@odin.ietf.org; Wed, 28 Jan 2004 13:51:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alun6-00077w-DJ for ieprep-web-archive@optimus.ietf.org; Wed, 28 Jan 2004 13:51:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19660 for ; Wed, 28 Jan 2004 13:51:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Alun4-0003pO-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:51:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Alum8-0003jZ-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:50:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlulF-0003dC-00 for ieprep-web-archive@ietf.org; Wed, 28 Jan 2004 13:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlulG-00070h-Ss; Wed, 28 Jan 2004 13:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Alukw-000708-Rn for ieprep@optimus.ietf.org; Wed, 28 Jan 2004 13:49:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19577 for ; Wed, 28 Jan 2004 13:49:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aluku-0003aG-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:49:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aluk0-0003Vm-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:48:45 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1AlujW-0003QI-00 for ieprep@ietf.org; Wed, 28 Jan 2004 13:48:14 -0500 Received: (qmail 16441 invoked from network); 28 Jan 2004 18:41:12 -0000 Received: from pool-151-196-240-182.balt.east.verizon.net (HELO albers) (151.196.240.182) by phobos.simply.net with SMTP; 28 Jan 2004 18:41:12 -0000 From: "Ken Carlberg" To: "'Janet P Gunn'" Cc: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Date: Wed, 28 Jan 2004 13:40:56 -0500 Message-ID: <002101c3e5ce$44a084e0$7301a8c0@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Janet, The following response may be a bit picky on some issues/comments, but I feel it will be helpful to clarify things a bit. > I think that, under "normal" circumstances, the QoS mechanisms for > conventional VoIP will be more than adequate to support ETS, and "special > treatment" in Call Admission Control is what will be needed for ETS. Within the context of what we have written in the past in the IETF, ETS is an umbrella term that is meant to cover a wide variety of applications. Some of these applications (eg, I-Am-Alive) do not support the concept of CAC. So to say that "special treatment" (whatever that is) of CAC is what will be needed for ETS is rather too specific a statement to make. I think we can agree that in those applications used to support ETS and dependent on CAC, an ability to distinguish and perform CAC is of high interest and needs to be supported. > As Fred Baker says in draft-baker-tsvwg-mlpp-that-works.00.txt, if call > admission is working properly, traffic marking is not needed in normal > operations. It is when there are route changes - typically due to network > failures - that marking is needed. Keep in mind that Fred's draft is in respect to MLPP. Arguments from the draft may be applied to other circumstances, but I would refrain from treating it as a blanket statement for all applications and situations. I've worked on systems in the past where "marking" was used to separate traffic into either different physical subnets or different virtuals paths -- neither case where the route changes existed because of network failures. > When there are network failures, the > capacity and route assignments on which call admission was based no longer > apply, the QoS cannot be guaranteed until the new routes are stabilized, > and the call admission process adapts to the new capacity and routes. > This may be a very local effect, of quite short duration. But it has a > significant impact on the call quality of the calls that are affected. > While that paper addresses an IP implementation of MLPP, many of the same > concerns apply to ETS. Ok > Network failures, and/or massive and sustained statistical anomalies > (large, local bursts), and the associated route changes, are the problems > we need to focus on. > > It is in this context that ETS calls must be given a high probability of > meeting the QoS criteria, even when network congestion and or damage are > severe. Ok. > The requirements in draft-ietf-ieprep-domain-req-00.txt don't seem to > address this, and the framework in draft-ietf-ieprep-domain-frame-00.txt > doesn't seem to solve it. Actually, that's fine. The former draft is not aimed at a specific application or system (this is stated in the draft). It is admittedly broad and acts as a foundation for the context of a single domain. The latter draft is not meant to offer solutions, but rather to discuss applicable and related protocols that one *could* encounter within the specific scope of a single domain. I will expand this below where you have a specific question. > In draft-gunn-ieprep-ip-telephony-gap-00.txt we address the need to > support ETS SLAs to provide High Probability Toll-Quality Voice - ETS > calls > must be given adequate resources through the network to ensure a high > probability that their packets suffer loss, delay, and jitter consistent > with achieving toll-quality voice even when network congestion and / or > damage are severe. > What is the appropriate way to reflect these concerns? Through a draft (and I state it with no intention of being obnoxiously obvious). If your question is, how does one deal with the three seemingly related drafts? 1. draft-ietf-ieprep-domain-req-00.txt, 2. draft-ietf-ieprep-domain-frame-00.txt, and 3. draft-gunn-ieprep-ip-telephony-gap-00.txt, then I would follow the position I stated above and have (3) simply be a more specific continuation of what has been stated in (1) and (2) above. In my view it may be more constructive to be very specific and identify specific systems/efforts like GETS or NS/EP or WPS. If the chairs or AD feel differently, I'm sure they'll chime in. Cheers, -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jan 29 12:45:52 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04329 for ; Thu, 29 Jan 2004 12:45:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGEH-0001uJ-1V for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 12:45:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0THjPxw007327 for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 12:45:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGEG-0001u6-Un for ieprep-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 12:45:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04194 for ; Thu, 29 Jan 2004 12:45:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGEF-00074Y-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 12:45:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGCl-0006ki-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 12:43:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmGBO-0006Oa-05 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 12:42:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmFtp-0005WE-Q0; Thu, 29 Jan 2004 12:24:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmF9W-00032a-7e for ieprep@optimus.ietf.org; Thu, 29 Jan 2004 11:36:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00273 for ; Thu, 29 Jan 2004 11:36:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmF9V-0005ri-00 for ieprep@ietf.org; Thu, 29 Jan 2004 11:36:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmF8b-0005mb-00 for ieprep@ietf.org; Thu, 29 Jan 2004 11:35:29 -0500 Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx with esmtp (Exim 4.12) id 1AmF8M-0005gy-00 for ieprep@ietf.org; Thu, 29 Jan 2004 11:35:14 -0500 Received: from Steve (ha96s172.d.shentel.net [204.111.96.172]) by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id i0TGYL430706; Thu, 29 Jan 2004 11:34:21 -0500 From: "Steve Silverman" To: "Fred Baker" , "Janet P Gunn" , Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Date: Thu, 29 Jan 2004 11:33:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <6.0.1.1.2.20040127162316.048affd8@mira-sjc5-b.cisco.com > Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If the offered load exceeds the network capacity, some packets will be dropped. If a line is at 95% of capacity, a 10% surge would cause 5% of the packets to be dropped, degrading most of the conversations. ( I am simplifying here but I think this is clear.) The benefit of multiple DSCPs is that the sessions designated most critical are unaffected. Actual experiment has shown that this does work. In draft-baker-tsvwg-mlpp-that-works.00 it is assumed that the CAC will ensure that voice is not overloaded. Two problems with this are: 1) If silence suppression is used and the bandwidth "oversubscribed" (standard practice) then sometimes, more people on one end will talk and cause congestion. 2) If the area controlled by the CAC is large, propagation delay will limit the reaction time of the system and the computation to oversee the entire theatre may also be a limiting factor. This may cause short congestion incidents (several seconds long) which could be mitigated by MLEF. I'm not saying you don't also need the CAC. I'm saying you need something local and fast reacting (at the packet level rather than the call level) to ensure that the high priority packets get thru. Steve Silverman > -----Original Message----- > From: ieprep-admin@ietf.org > [mailto:ieprep-admin@ietf.org]On Behalf Of > Fred Baker > Sent: Tuesday, January 27, 2004 9:36 PM > To: Janet P Gunn > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt > > > At 12:32 PM 1/27/2004, Janet P Gunn wrote: > >As Fred Baker says in > draft-baker-tsvwg-mlpp-that-works.00.txt, if call > >admission is working properly, traffic marking is not > needed in normal > >operations. > > lest I be misunderstood, let me restate that. What I wrote was: > > One will ask the value of the multiple DSCPs. They are, > in fact, of > limited to no value in normal operation, as all vice and video > traffic should have been admitted, and therefore > capacity will have > been assigned to them. The behavior of this service will be > indistinguishable from the EF PHB regardless of traffic marking. > > In retrospect, I wonder what the vice traffic would be :^) > > This is not to be understood as saying "no traffic marking > is required"; > one still needs RFC 3246. But if bandwidth admission is operating > correctly, having N different marks will be operationally > indistinguishable > from having a single EF mark, as the total number of bytes > on the wire will > be the same. > > >It is in this context that ETS calls must be given a high > probability of > >meeting the QoS criteria, even when network congestion and > or damage are > >severe. > > I wonder if we are communicating here. RFC 3246 is designed > to operate in a > congested network, and to operate in a network in which > routing may change. > The comment in the mlpp-that-works draft - which if it is > giving cause for > confusion I will happily remove - is basically me bending > over backwards to > be intellectually honest and see if I can find a case where > CAC may be > insufficient. > > Think about this for a moment: the argument being placed > for MLEF is that > even in the presence of some loss, voice is intelligible. > If that is true, > then just after a route change, during the brief interval > between the data > flow being switched to a new path and the CAC following > that and either > OKing the flow or deciding to shut down the call, when > there may be some > loss, voice should be equally intelligible, no? > > Or does the argument that voice is able to work around a > modest level of > loss only work when it comes from the proponents of > multiple code points? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jan 29 13:30:03 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06441 for ; Thu, 29 Jan 2004 13:30:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGv3-0003cJ-F4 for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 13:29:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TITb6C013896 for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 13:29:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGv3-0003c3-Bd for ieprep-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 13:29:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06432 for ; Thu, 29 Jan 2004 13:29:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGv1-0004RA-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 13:29:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGu3-0004L3-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 13:28:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmGtW-0004Ez-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 13:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGtU-0003Wh-6e; Thu, 29 Jan 2004 13:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmGt0-0003WB-FO for ieprep@optimus.ietf.org; Thu, 29 Jan 2004 13:27:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06370 for ; Thu, 29 Jan 2004 13:27:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmGsy-0004Dg-00 for ieprep@ietf.org; Thu, 29 Jan 2004 13:27:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmGs1-00048V-00 for ieprep@ietf.org; Thu, 29 Jan 2004 13:26:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AmGri-00043F-00 for ieprep@ietf.org; Thu, 29 Jan 2004 13:26:10 -0500 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0TIPawC007405; Thu, 29 Jan 2004 13:25:36 -0500 (EST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA16635; Thu, 29 Jan 2004 10:25:32 -0800 (PST) Message-Id: <4.3.2.7.2.20040129114303.027b7740@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 12:25:45 -0600 To: "Steve Silverman" , "Fred Baker" , "Janet P Gunn" , From: "James M. Polk" Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt In-Reply-To: References: <6.0.1.1.2.20040127162316.048affd8@mira-sjc5-b.cisco.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 comments below At 11:33 AM 1/29/2004 -0500, Steve Silverman wrote: >If the offered load exceeds the network capacity, some packets will be >dropped. If a line is at >95% of capacity, a 10% surge would cause 5% of the packets to be >dropped, degrading most of the conversations. ( I am simplifying here >but I think this is clear.) > >The benefit of multiple DSCPs is that the sessions designated most >critical are unaffected. without active feedback to those lower priority sessions.... >Actual experiment has shown that this does >work. yes it does - but without regard to any call quality. If the surge is 25 or 50 or 75% above maximum load possible, then what happens to the lower priority calls? There isn't any feedback to the users (other than pure silence). Further, there isn't any feedback (signaling) to their devices what's happening or to hang up the call. There's nothing. How long is this expected to last for? No one knows. Further, no one can test the system (because of no feedback). No one can point to where there might be potential problems with this architecture either (is the system behaving correctly?). There is no feedback to discover or monitor its performance. Where is it supposed to be discovered that a link between any two routers isn't fast enough (because there are perhaps frequent silence periods)? >In draft-baker-tsvwg-mlpp-that-works.00 it is assumed that the CAC >will ensure that voice is not overloaded. >Two problems with this are: > > 1) If silence suppression is used and the bandwidth "oversubscribed" >(standard practice) then sometimes, more people on one end will talk >and cause congestion. > > 2) If the area controlled by the CAC is large, propagation delay >will limit the reaction time of the system where's the propagation delay? the surge won't happen without the signaling having already occurred through the congestion point; meaning the system (read: routers) already know about all the call (flow) attempts - even when there is too much offered load for an interface. The router can either say "sorry, not enough resources available to complete your call attempt" or "sorry, but there was another call with higher priority, and I have to shut your call down now". BTW - these are device signals, this isn't a .wav file playing to the user or anything. >and the computation to >oversee the entire theatre may also be a limiting factor. see above, computation occurs at the router that is experiencing this surge. It is in charge of the packet forwarding. It is aware of all the existing flows it has accepted. It is in charge of accepting new flows and preempting lesser priority ones if multilevel offered load exceeds the maximum load possible. >This may >cause short congestion incidents (several seconds long) which could be >mitigated by MLEF. I'm not saying you don't also need the CAC. I'm >saying >you need something local and fast reacting In the router itself isn't fast enough...? >(at the packet level rather >than the call level) packet level = Layer 3 Call level = what? Layer 4, 5 or 7? >to ensure that the high priority packets get >thru. I am a believer in high priority calls getting through, and for all calls that remain up - having all their packets arrive safely too. >Steve Silverman cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jan 29 16:45:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21236 for ; Thu, 29 Jan 2004 16:45:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJyO-0002In-0w for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 16:45:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TLjFYu008843 for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 16:45:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJyN-0002IX-TI for ieprep-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 16:45:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21095 for ; Thu, 29 Jan 2004 16:45:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmJyL-0007eM-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 16:45:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmJwe-0007AH-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 16:43:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmJue-0006bh-06 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 16:41:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJje-0000T3-G5; Thu, 29 Jan 2004 16:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmJjG-0000Rn-FQ for ieprep@optimus.ietf.org; Thu, 29 Jan 2004 16:29:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19900 for ; Thu, 29 Jan 2004 16:29:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmJjE-0005G7-00 for ieprep@ietf.org; Thu, 29 Jan 2004 16:29:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmJiM-00059r-00 for ieprep@ietf.org; Thu, 29 Jan 2004 16:28:42 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1AmJhk-0004rX-00 for ieprep@ietf.org; Thu, 29 Jan 2004 16:28:04 -0500 Received: (qmail 25691 invoked from network); 29 Jan 2004 21:27:27 -0000 Received: from pool-151-196-240-182.balt.east.verizon.net (HELO albers) (151.196.240.182) by phobos.simply.net with SMTP; 29 Jan 2004 21:27:27 -0000 From: "Ken Carlberg" To: "'James M. Polk'" Cc: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Date: Thu, 29 Jan 2004 16:26:41 -0500 Message-ID: <002f01c3e6ae$97104630$7301a8c0@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <4.3.2.7.2.20040129114303.027b7740@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James, > If the surge is 25 or 50 or 75% above maximum load possible, then what > happens to the lower priority calls? There isn't any feedback to the users > (other than pure silence). Further, there isn't any feedback (signaling) > to > their devices what's happening or to hang up the call. There's nothing. > How long is this expected to last for? No one knows. > > Further, no one can test the system (because of no feedback). I'm sorry if I missed an argument that may be in one of the related tsvwg drafts, but is there a specific form of the feedback you are looking for? We have RTCP reports that can provide a measure of feedback on an end-to-end basis. Admittedly, these are generally not provided to the user and they are not targeted towards a specific application or underlying network service, but the hooks are there to at least inform the users of loss versus silence. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jan 29 18:09:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27145 for ; Thu, 29 Jan 2004 18:09:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLHB-0005YZ-S2 for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 18:08:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0TN8jkn021353 for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 18:08:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLHB-0005YI-Lw for ieprep-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 18:08:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27046 for ; Thu, 29 Jan 2004 18:08:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmLH8-0004cu-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 18:08:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmLGI-0004Tt-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 18:07:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmLFV-0004LL-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 18:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLFV-0004lE-CQ; Thu, 29 Jan 2004 18:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmLFB-0004gn-Re for ieprep@optimus.ietf.org; Thu, 29 Jan 2004 18:06:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26762 for ; Thu, 29 Jan 2004 18:06:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmLF9-0004IB-00 for ieprep@ietf.org; Thu, 29 Jan 2004 18:06:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmLEE-00048u-00 for ieprep@ietf.org; Thu, 29 Jan 2004 18:05:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AmLDJ-0003tu-00 for ieprep@ietf.org; Thu, 29 Jan 2004 18:04:45 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Jan 2004 15:10:00 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i0TN4DTK000066; Thu, 29 Jan 2004 15:04:14 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA01646; Thu, 29 Jan 2004 15:04:11 -0800 (PST) Message-Id: <4.3.2.7.2.20040129163336.02615100@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jan 2004 17:04:23 -0600 To: "Ken Carlberg" From: "James M. Polk" Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Cc: In-Reply-To: <002f01c3e6ae$97104630$7301a8c0@albers> References: <4.3.2.7.2.20040129114303.027b7740@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Comments below At 04:26 PM 1/29/2004 -0500, Ken Carlberg wrote: >James, > > > If the surge is 25 or 50 or 75% above maximum load possible, then what > > happens to the lower priority calls? There isn't any feedback to the >users > > (other than pure silence). Further, there isn't any feedback >(signaling) > > to > > their devices what's happening or to hang up the call. There's >nothing. > > How long is this expected to last for? No one knows. > > > > Further, no one can test the system (because of no feedback). > >I'm sorry if I missed an argument that may be in one of the related >tsvwg drafts, but is there a specific form of the feedback you are >looking for? 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-concerns-00.txt, and http://www.ietf.org/internet-drafts/draft-baker-mlpp-that-works-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. 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. 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. We have demonstrated in lab tests to DISA and various other organizations that, a 1%, 5% and higher packet loss has significant impact on Voice Quality (VQ) of all codecs, while at the same time - having some organizations maintain the requirement that VQ cannot drop below a 4.0 MOS. >We have RTCP reports that can provide a measure of >feedback on an end-to-end basis. Aren't these for after a call, and propagated up to the requesting NM station? >Admittedly, these are generally not >provided to the user One of the primary MLPP Service requirements is to have a tone or announcement to all affected users if there is preemption at the endpoint or in the network. >and they are not targeted towards a specific >application or underlying network service, but the hooks are there to at >least inform the users of loss versus silence. 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 rear-time). >-ken > > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jan 29 19:35:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02977 for ; Thu, 29 Jan 2004 19:35:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMcN-0005ch-Oa for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 19:34:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U0Yhm2021609 for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 19:34:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMcN-0005cS-Jx for ieprep-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 19:34:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02966 for ; Thu, 29 Jan 2004 19:34:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMcL-0002CG-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 19:34:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMbR-00026J-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 19:33:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmMaj-00020j-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 19:33:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMaj-0005T1-4z; Thu, 29 Jan 2004 19:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMaP-0005Sc-Lk for ieprep@optimus.ietf.org; Thu, 29 Jan 2004 19:32:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02942 for ; Thu, 29 Jan 2004 19:32:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMaN-0001yu-00 for ieprep@ietf.org; Thu, 29 Jan 2004 19:32:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMZV-0001tU-00 for ieprep@ietf.org; Thu, 29 Jan 2004 19:31:46 -0500 Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx with smtp (Exim 4.12) id 1AmMZD-0001nQ-00 for ieprep@ietf.org; Thu, 29 Jan 2004 19:31:27 -0500 Received: (qmail 32055 invoked from network); 30 Jan 2004 00:30:43 -0000 Received: from pool-151-196-240-182.balt.east.verizon.net (HELO albers) (151.196.240.182) by phobos.simply.net with SMTP; 30 Jan 2004 00:30:43 -0000 From: "Ken Carlberg" To: "'James M. Polk'" Cc: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Date: Thu, 29 Jan 2004 19:29:54 -0500 Message-ID: <003501c3e6c8$2f41e080$7301a8c0@albers> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <4.3.2.7.2.20040129163336.02615100@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the recap. > >We have RTCP reports that can provide a measure of > >feedback on an end-to-end basis. > > Aren't these for after a call, and propagated up to the requesting NM > station? The reports are sent periodically throughout the session between end points. Implementors make their own choices if and when to display the stats. At UCL, the RAT (VoIP) tool allows the user to see the stats updated in real time. For other implementations, your mileage may very. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From exim@www1.ietf.org Thu Jan 29 19:38:12 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03049 for ; Thu, 29 Jan 2004 19:38:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMfJ-00069A-MR for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 19:37:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0U0bjRe023601 for ieprep-archive@odin.ietf.org; Thu, 29 Jan 2004 19:37:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMfI-00068S-Nk for ieprep-web-archive@optimus.ietf.org; Thu, 29 Jan 2004 19:37:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03029 for ; Thu, 29 Jan 2004 19:37:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMfG-0002W5-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 19:37:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMeI-0002PA-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 19:36:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmMdd-0002JP-00 for ieprep-web-archive@ietf.org; Thu, 29 Jan 2004 19:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMdd-0005ey-QN; Thu, 29 Jan 2004 19:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmMdO-0005eQ-0b for ieprep@optimus.ietf.org; Thu, 29 Jan 2004 19:35:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03010 for ; Thu, 29 Jan 2004 19:35:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmMdM-0002J7-00 for ieprep@ietf.org; Thu, 29 Jan 2004 19:35:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmMcS-0002DM-00 for ieprep@ietf.org; Thu, 29 Jan 2004 19:34:49 -0500 Received: from seahorse.shentel.net ([204.111.11.44]) by ietf-mx with esmtp (Exim 4.12) id 1AmMbr-00020u-00 for ieprep@ietf.org; Thu, 29 Jan 2004 19:34:11 -0500 Received: from Steve (ha96s276.d.shentel.net [204.111.97.20]) by seahorse.shentel.net (8.11.7/8.11.7) with SMTP id i0U0XR425742; Thu, 29 Jan 2004 19:33:28 -0500 From: "Steve Silverman" To: "James M. Polk" , "Ken Carlberg" Cc: Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Date: Thu, 29 Jan 2004 19:33:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-Reply-To: <4.3.2.7.2.20040129163336.02615100@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > 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 From exim@www1.ietf.org Fri Jan 30 10:48:59 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22743 for ; Fri, 30 Jan 2004 10:48:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amash-0006YF-Oc for ieprep-archive@odin.ietf.org; Fri, 30 Jan 2004 10:48:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0UFmVpn025179 for ieprep-archive@odin.ietf.org; Fri, 30 Jan 2004 10:48:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amash-0006Xu-Kt for ieprep-web-archive@optimus.ietf.org; Fri, 30 Jan 2004 10:48:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22735 for ; Fri, 30 Jan 2004 10:48:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amase-0005DO-00 for ieprep-web-archive@ietf.org; Fri, 30 Jan 2004 10:48:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amark-00054i-00 for ieprep-web-archive@ietf.org; Fri, 30 Jan 2004 10:47:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmarK-0004wW-00 for ieprep-web-archive@ietf.org; Fri, 30 Jan 2004 10:47:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmarE-0006R8-J9; Fri, 30 Jan 2004 10:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmaqT-0006Oq-By for ieprep@optimus.ietf.org; Fri, 30 Jan 2004 10:46:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22607 for ; Fri, 30 Jan 2004 10:46:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmaqQ-0004tH-00 for ieprep@ietf.org; Fri, 30 Jan 2004 10:46:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmapV-0004ly-00 for ieprep@ietf.org; Fri, 30 Jan 2004 10:45:14 -0500 Received: from mailgw1a.lmco.com ([192.31.106.7]) by ietf-mx with esmtp (Exim 4.12) id 1Amaoc-0004fg-00 for ieprep@ietf.org; Fri, 30 Jan 2004 10:44:18 -0500 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54]) by mailgw1a.lmco.com (8.12.10/8.12.10) with ESMTP id i0UFiCLf002676; Fri, 30 Jan 2004 08:44:12 -0700 (MST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30884) id <0HSB00L017PNIR@lmco.com>; Fri, 30 Jan 2004 08:44:11 -0700 (MST) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30884) with ESMTP id <0HSB001537PM7E@lmco.com>; Fri, 30 Jan 2004 08:44:10 -0700 (MST) Received: from EMSS09M02.us.lmco.com ([158.183.26.5]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 30 Jan 2004 10:44:10 -0500 Date: Fri, 30 Jan 2004 10:44:09 -0500 From: "Eagan, Christopher" Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt To: "James M. Polk" , Ken Carlberg Cc: ieprep@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: [Ieprep] I-D ACTION:draft-ietf-ieprep-domain-req-00.txt Thread-Index: AcPmvK96J7V8UpiFSouAXmQQEB60OgAiPQRQ content-class: urn:content-classes:message X-OriginalArrivalTime: 30 Jan 2004 15:44:10.0107 (UTC) FILETIME=[E70514B0:01C3E747] Content-Transfer-Encoding: 7BIT Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-BeenThere: ieprep@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Internet Emergency Preparedness Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > We have demonstrated in lab tests to DISA and various other > organizations > that, a 1%, 5% and higher packet loss has significant impact on Voice > Quality (VQ) of all codecs, while at the same time - having some > organizations maintain the requirement that VQ cannot drop > below a 4.0 MOS. I don't think the 4.0 MOS requirement is applicable to all (perhaps most) voip carrying networks that could benefit from MLEF or another packet level marking scheme. This is cited as a requirement for some DoD switched networks and does not necessarily extend to ALL voip carrying networks, or all DoD voip carrying networks, or even all DoD switched voice networks. Actually, providing a 3.0 MOS would be a significant improvement to some current voice networks - especially wireless, mobile, low bandwidth ones. Given this, 30% packet loss is sustainable and acceptable in some situations. Furthermore, MOS is not necessarily the best measure of voice quality for all voice networks. For example, in tactical networks, intelligibility is important while fidelity is not as important. Regardless, I realize if someone said that some arbitrary X quality was required, you could come with the same argument with different packet loss numbers. The point is, each network and even each link may have different requirements. Providing multiple tools (e.g. RSVP based CAC + MLEF) to engineer each network, or in some cases each link, for the specific requirements is needed. Chris _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep