From mailnull@www1.ietf.org Tue Apr 1 09:56:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15748 for ; Tue, 1 Apr 2003 09:56:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31FJpa26764 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 10:19:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FJpK26761 for ; Tue, 1 Apr 2003 10:19:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15647 for ; Tue, 1 Apr 2003 09:55:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FIFK26643; Tue, 1 Apr 2003 10:18:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31FHWK26360 for ; Tue, 1 Apr 2003 10:17:32 -0500 Received: from pfwssp1.ncr.disa.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15553 for ; Tue, 1 Apr 2003 09:53:15 -0500 (EST) Received: from mtassp3.ncr.disa.mil by pfwssp1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 1 Apr 2003 14:43:27 UT Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 09:53:45 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4DED@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'King, Kimberly S.'" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 09:53:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Kimberly, > >-----Original Message----- >From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com] >Sent: Monday, March 31, 2003 11:57 AM >To: Ieprep (E-mail) >Subject: [Ieprep] access and enterprise networks > > > >At the last meeting, people expressed an interest in addressing access and >enterprise networks. As frustrating as it might seem, if there is to be any >progress, the problem still has to be precisely defined. > I thin we need to define what access and enterprise networks are and what are the chokepoints in these network. We need a diagram that depicts this whole thing. >Let's consider defining the problem and it would be nice to factor in some >practical realities too. > >Here are some assumptions: > >A) ETS locations are known in advance of any emergency. When an emergency >occurs, each will already be connected to a network (unless the emergency >damaged the connection in which case that situation is out of scope). > I don't totally agree with the notion that locations of any emergency can be predicted in advance. An known ETS location belongs to one of many emergency scenarios. We cannot address all scenarios at once; therefore, we can only move in small increments; that is, addressing congestion problem in this specific scenario. > >So, what is it that we want to ensure? Would ieprep like a service that >provided some minimum bandwidth guarantee (like gold service) over the >access link and that's sufficient to make everyone reasonably happy? If >that kind of service just isn't acceptable, then please provide some text >and details about the problem you believe we need to address. > Does "Gold service" mean access traffic needs to be classified so that traffic belongs to this gold service could be taken care of first when congestion occurs? If the answer is yes, I would like to some proposed mechanisms from the WG. If no, what else can be done to solve this problem? >Kimberly > An _______________________________________________ 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 From mailnull@www1.ietf.org Tue Apr 1 10:40:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21137 for ; Tue, 1 Apr 2003 10:40:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31G42j09765 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 11:04:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G42K09762 for ; Tue, 1 Apr 2003 11:04:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21122 for ; Tue, 1 Apr 2003 10:39:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G23K09258; Tue, 1 Apr 2003 11:02:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31G16K09215 for ; Tue, 1 Apr 2003 11:01:06 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20941 for ; Tue, 1 Apr 2003 10:36:47 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 8B78A67105 for ; Tue, 1 Apr 2003 10:59:04 -0500 (EST) Date: Tue, 1 Apr 2003 10:39:12 -0500 Subject: Re: [Ieprep] access and enterprise networks Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D02EF4DED@emshqs1.ncr.disa.mil> Message-Id: <1685AAA4-6458-11D7-863B-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.551) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, Apr 1, 2003, at 09:53 America/Montreal, Nguyen, An wrote: > I thin we need to define what access and enterprise networks are and > what > are the chokepoints in these network. We need a diagram that depicts > this > whole thing. Agree. A starting point is that an "enterprise network" normally has one of 2 flavours: (A) campus or single-building network, most commonly built out of 10/100/1000 Ethernet these days. (B) multi-site enterprise network (e.g. US General Electric Co.) with T1/NxT1/T3 links between/among the various sites and with any given site looking like (A) above. An "access network" typically means the uplink between an enterprise network and its IP service provider. Access networks are most commonly built out of T1/NxT1/T3 links, though for large multi-site enterprises the uplink might sometimes be higher bandwidth (e.g. OC-3 ATM or SONET, OC-12 ATM or SONET). >> So, what is it that we want to ensure? Would ieprep like a service >> that >> provided some minimum bandwidth guarantee (like gold service) over the >> access link and that's sufficient to make everyone reasonably happy? >> If >> that kind of service just isn't acceptable, then please provide some >> text >> and details about the problem you believe we need to address. > > Does "Gold service" mean access traffic needs to be classified so that > traffic belongs to this gold service could be taken care of first when > congestion occurs? If the answer is yes, I would like to some proposed > mechanisms from the WG. If no, what else can be done to solve this > problem? I don't know what form of "Gold service" meaning Kimberly meant, so the following example uses the explanation that An provided: One possible mechanism (applicable ONLY IF there is a single administrative/policy domain, not for an inter-domain scenario): - packet classification based on arrival port, based on IP ToS or Ethernet 802.1p precedence markings, based on source/dest address and/or protocol (e.g. UDP, TCP, SCTP) and port number (e.g. SIP, SMTP, FTP), or based on other selectors. - mark IP ToS/Ethernet 802.1p based on the preceding packet classification. - deploy DiffServ within the enterprise network, with at least 3 queues: - normal traffic (lowest priority) - preferred traffic - network control/routing traffic (highest priority, low bandwidth) - use DiffServ to apply class-based-queuing on access/uplink routers The issue with inter-domain is mitigating risk of DoS/DDoS attacks on the ISP's core or in the destination domain's network. Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 12:37:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02729 for ; Tue, 1 Apr 2003 12:37:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31I17L18838 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 13:01:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31I17K18835 for ; Tue, 1 Apr 2003 13:01:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02654 for ; Tue, 1 Apr 2003 12:36:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HxFK18682; Tue, 1 Apr 2003 12:59:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HwAK16797 for ; Tue, 1 Apr 2003 12:58:10 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02223 for ; Tue, 1 Apr 2003 12:33:48 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 1 Apr 2003 12:34:46 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003040112355810278 ; Tue, 01 Apr 2003 12:35:58 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <2AXFGK2H>; Tue, 1 Apr 2003 12:35:35 -0500 Message-Id: From: "King, Kimberly S." To: "'Nguyen, An'" , "'King, Kimberly S.'" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 12:35:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , An, >I thin we need to define what access and enterprise networks >are and what >are the chokepoints in these network. We need a diagram that >depicts this >whole thing. Yes. >I don't totally agree with the notion that locations of any >emergency can be >predicted in advance. An arbitrary location may connect to the Internet, if it connects, via one or more of about 10,000 ISPs. I just haven't heard any ideas on how you get anything but default treatment in an arbitrary network with whom you have no prior relationship. (Recall from the framework that we don't want to assume mandates but rather SLA-type approach.) So that's the reason for the assumption. > >Does "Gold service" mean access traffic needs to be classified so that >traffic belongs to this gold service could be taken care of first when >congestion occurs? Helping performance in IP networks may take a rethinking of what it takes to be successful. At a minimum, it may require redefining what it means to be "taken care of first" and the definition of when there is "congestion". IP network performance is inherently statistical rather than an ordered deterministic "this call first, then that one". For networks with best effort service (e.g., the overwhelming majority of ISPs), it might make sense to have the provider guarantee some minimum throughput for particular locations. Let's take an example of driving a car in my town. Vehicular traffic in Washington D.C. can be congested. One method to control congestion on a highway is to control the rate traffic enters the highway. One method of gold service says ETS locations get to put more traffic on that highway when the on-ramps are busy. There is also another method for solving particular congestion problems (at least for some cars). One can put in a special lane (say for high occupancy cars) on that highway. This is more a RSVP/DiffServ approach and may be appropriate on certain enterprise networks. I hope this provides some forward direction. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 12:57:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04448 for ; Tue, 1 Apr 2003 12:57:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31ILS726170 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 13:21:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31ILSK26134 for ; Tue, 1 Apr 2003 13:21:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04345 for ; Tue, 1 Apr 2003 12:57:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IK9K24851; Tue, 1 Apr 2003 13:20:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IJxK24788 for ; Tue, 1 Apr 2003 13:19:59 -0500 Received: from bootstrap.agcs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04099 for ; Tue, 1 Apr 2003 12:55:36 -0500 (EST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.52.9]) by bootstrap.agcs.com (8.12.8/8.12.6) with ESMTP id h31HvRxa024228 for ; Tue, 1 Apr 2003 10:57:27 -0700 (MST) Received: from USAZ107115SVR20 ([130.131.166.68]) by pxmail1.agcs.com (Netscape Messaging Server 4.15 pxmail1 Mar 5 2002 15:11:07) with SMTP id HCOF8Q00.HQC for ; Tue, 1 Apr 2003 10:58:02 -0700 Received: FROM GOLDMANS1 BY USAZ107115SVR20 ; Tue Apr 01 10:58:01 2003 -0700 From: "Stuart (Stu) Goldman" To: "King Kimberly S." , "'Nguyen An'" Cc: "Ieprep \(E-mail\)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 10:58:01 -0700 Message-ID: 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kimberly, When you said " There is also another method for solving particular congestion problems (at least for some cars). One can put in a special lane (say for high occupancy cars) on that highway. I was surprised that you did not also address those few selected vehicles with flashing lights and a siren that can get "Platinum Service" on the existing roads without the need for new lanes. -----Original Message----- From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of King, Kimberly S. Sent: Tuesday, April 01, 2003 10:36 AM To: 'Nguyen, An'; 'King, Kimberly S.' Cc: Ieprep (E-mail) Subject: RE: [Ieprep] access and enterprise networks An, >I thin we need to define what access and enterprise networks >are and what >are the chokepoints in these network. We need a diagram that >depicts this >whole thing. Yes. >I don't totally agree with the notion that locations of any >emergency can be >predicted in advance. An arbitrary location may connect to the Internet, if it connects, via one or more of about 10,000 ISPs. I just haven't heard any ideas on how you get anything but default treatment in an arbitrary network with whom you have no prior relationship. (Recall from the framework that we don't want to assume mandates but rather SLA-type approach.) So that's the reason for the assumption. > >Does "Gold service" mean access traffic needs to be classified so that >traffic belongs to this gold service could be taken care of first when >congestion occurs? Helping performance in IP networks may take a rethinking of what it takes to be successful. At a minimum, it may require redefining what it means to be "taken care of first" and the definition of when there is "congestion". IP network performance is inherently statistical rather than an ordered deterministic "this call first, then that one". For networks with best effort service (e.g., the overwhelming majority of ISPs), it might make sense to have the provider guarantee some minimum throughput for particular locations. Let's take an example of driving a car in my town. Vehicular traffic in Washington D.C. can be congested. One method to control congestion on a highway is to control the rate traffic enters the highway. One method of gold service says ETS locations get to put more traffic on that highway when the on-ramps are busy. There is also another method for solving particular congestion problems (at least for some cars). One can put in a special lane (say for high occupancy cars) on that highway. This is more a RSVP/DiffServ approach and may be appropriate on certain enterprise networks. I hope this provides some forward direction. 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 From mailnull@www1.ietf.org Tue Apr 1 13:06:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05248 for ; Tue, 1 Apr 2003 13:06:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31IUNN29888 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 13:30:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IUNK29885 for ; Tue, 1 Apr 2003 13:30:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05190 for ; Tue, 1 Apr 2003 13:06:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IT5K29594; Tue, 1 Apr 2003 13:29:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IRUK29386 for ; Tue, 1 Apr 2003 13:27:30 -0500 Received: from pfwhqs1.ncr.disa.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05072 for ; Tue, 1 Apr 2003 13:03:07 -0500 (EST) Received: from mtahqs3.ncr.disa.mil by pfwhqs1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 1 Apr 2003 17:57:53 UT Received: by mtahqs3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 13:09:11 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4DF1@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'King, Kimberly S.'" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 13:03:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Kim, -----Original Message----- >From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com] >Sent: Tuesday, April 01, 2003 12:36 PM >To: 'Nguyen, An'; 'King, Kimberly S.' >Cc: Ieprep (E-mail) >Subject: RE: [Ieprep] access and enterprise networks >I don't totally agree with the notion that locations of any >emergency can be >Helping performance in IP networks may take a rethinking of what it takes to >be successful. At a minimum, it may require redefining what it means to be >"taken care of first" and the definition of when there is "congestion". IP >network performance is inherently statistical rather than an ordered >deterministic "this call first, then that one". What I meant here is in more or less in high probability of call completion, not a deterministic sense. >For networks with best effort service (e.g., the overwhelming majority of >ISPs), it might make sense to have the provider guarantee some minimum >throughput for particular locations. Let's take an example of driving a >car in my town. Vehicular traffic in Washington D.C. can be congested. >One method to control congestion on a highway is to control the rate traffic >enters the highway. One method of gold service says ETS locations get to >put more traffic on that highway when the on-ramps are busy. Are you suggesting that some sort of call admission control mechanisms to make sure that, for the lack of better words, traffic other than best effort has some sort of treatment? >There is also another method for solving particular congestion problems (at >least for some cars). One can put in a special lane (say for high occupancy >cars) on that highway. This is more a RSVP/DiffServ approach and may be >appropriate on certain enterprise networks. I could not agree more with you on DiffServ.:-) An _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 13:29:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06869 for ; Tue, 1 Apr 2003 13:29:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31IqsE04869 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 13:52:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IqsK04866 for ; Tue, 1 Apr 2003 13:52:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06853 for ; Tue, 1 Apr 2003 13:28:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Ip4K04287; Tue, 1 Apr 2003 13:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31IoQK04222 for ; Tue, 1 Apr 2003 13:50:26 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06681 for ; Tue, 1 Apr 2003 13:26:03 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 1 Apr 2003 13:27:06 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003040113281831794 ; Tue, 01 Apr 2003 13:28:18 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <2AXFGRKA>; Tue, 1 Apr 2003 13:27:55 -0500 Message-Id: From: "King, Kimberly S." To: "'Nguyen, An'" , "'King, Kimberly S.'" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 13:28:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , An, >>For networks with best effort service (e.g., the overwhelming >majority of >>ISPs), it might make sense to have the provider guarantee some minimum >>throughput for particular locations. Let's take an example >of driving a >>car in my town. Vehicular traffic in Washington D.C. can be >congested. >>One method to control congestion on a highway is to control the rate >traffic >>enters the highway. One method of gold service says ETS >locations get to >>put more traffic on that highway when the on-ramps are busy. > >Are you suggesting that some sort of call admission control >mechanisms to >make sure that, for the lack of better words, traffic other >than best effort >has some sort of treatment? Maybe. Depends on how you define "call admission control" and "some sort of treatment". I'm not thinking about calls but rather just packets. Back to my vehicle traffic control analogy. Suppose some highway on-ramp can support 10 cars gaining entry to the highway every 5 minutes. I'm suggesting a minimum of those cars are ETS ones (say 4 out of 10). In network terms, suppose a (bottleneck) link can support a certain rate per second of traffic moving through. Suppose, for example, we guarantee 40% of those packets that get through are ETS. It's a preferential treatment to get on the highway. Once on the highway, all cars drive best effort. Picture time... (use fixed-width font such as Courier). Imagine 3 locations, two "regular" and one ETS share a connection to the network. This link can get congested. Suppose regular locations are moving traffic at about 50% of that link speed while ETS is sending traffic at about 45% of the link speed. Normally, (assuming we can load to 100%), we should see 45% of the traffic drop and it might all be assumed to be roughly distributed among the locations. What I'm suggesting is a way for ETS traffic to have preferential access. If the guaranteed minimum were 40% for ETS, then only 5% of that ETS traffic would be dropped. -- -- Regular 50% link speed --- --- //-- --\\ --- --- / \ ----- -- bottleneck link / \ ----- -- | Network | Regular --- ------------------------+ | 50% link speed| | | --- | | | ---- | \ / --- | dropped \ / -- | \\-- --// ETS 45% | --- \ | / \|/ \ traffic dropped 45%, 40% regular traffic 5% ETS Note, I don't want to write the draft real-time on the list but I'm trying to provide what I think are some valid (and cost effective) ways to use the natural methods of IP networks to achieve the desired result. I hope this provides a good direction for a best-effort network. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 13:51:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07900 for ; Tue, 1 Apr 2003 13:51:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31JFmm09933 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 14:15:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JFlK09930 for ; Tue, 1 Apr 2003 14:15:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07874 for ; Tue, 1 Apr 2003 13:51:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JE9K09823; Tue, 1 Apr 2003 14:14:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JDKK09780 for ; Tue, 1 Apr 2003 14:13:20 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07800 for ; Tue, 1 Apr 2003 13:48:55 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 1 Apr 2003 13:49:52 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003040113510316303 ; Tue, 01 Apr 2003 13:51:03 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <2AXDZGA6>; Tue, 1 Apr 2003 13:53:19 -0500 Message-Id: From: "King, Kimberly S." To: "'Stuart (Stu) Goldman'" , "King Kimberly S." , "'Nguyen An'" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 13:51:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Stu, >There is also another method for solving particular congestion >problems (at >least for some cars). One can put in a special lane (say for >high occupancy >cars) on that highway. > >I was surprised that you did not also address those few >selected vehicles >with flashing lights and a siren that can get "Platinum Service" on the >existing roads without the need for new lanes. Not sure how to answer. I was speaking figuratively to get the ideas across. One idea...if the road in question is a loaded link, then all packets already on that link have to move in order. I can't tell packets to pull over into the curb of a link because there is a packet with a siren and flashing lights behind it. We have no space to pull over. Another idea...if the analogy is the entrance onto the highway, then this "platinum service" is basically what I have described as gold. There is a preference to which cars get entry. This is invariant of whether you use the preference for a particular ingress link connected to an ETS location, whether the packets are labeled using DiffServ, or whether the packets are associated with a particular RSVP reservation. It's all basically scheduling at any one hop. Perhaps this clarifies. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 14:00:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08132 for ; Tue, 1 Apr 2003 14:00:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31JOWc10428 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 14:24:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JOWK10425 for ; Tue, 1 Apr 2003 14:24:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08122 for ; Tue, 1 Apr 2003 14:00:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JM8K10300; Tue, 1 Apr 2003 14:22:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JLAK10252 for ; Tue, 1 Apr 2003 14:21:10 -0500 Received: from pfwssp1.ncr.disa.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08034 for ; Tue, 1 Apr 2003 13:56:47 -0500 (EST) Received: from mtassp3.ncr.disa.mil by pfwssp1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 1 Apr 2003 18:47:00 UT Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 13:57:18 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4DF3@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'King, Kimberly S.'" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 13:57:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Kim, >-----Original Message----- >From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com] >Sent: Tuesday, April 01, 2003 1:28 PM >To: 'Nguyen, An'; 'King, Kimberly S.' >Cc: Ieprep (E-mail) >Subject: RE: [Ieprep] access and enterprise networks >>Are you suggesting that some sort of call admission control >>mechanisms to >>make sure that, for the lack of better words, traffic other >>than best effort >>has some sort of treatment? >Maybe. Depends on how you define "call admission control" and "some sort of >treatment". I'm not thinking about calls but rather just packets. Back to >my vehicle traffic control analogy. Suppose some highway on-ramp can >support 10 cars gaining entry to the highway every 5 minutes. I'm >suggesting a minimum of those cars are ETS ones (say 4 out of 10). In >network terms, suppose a (bottleneck) link can support a certain rate per >second of traffic moving through. Suppose, for example, we guarantee 40% of >those packets that get through are ETS. It's a preferential treatment to get >on the highway. Once on the highway, all cars drive best effort. Interesting idea! Why would I buy 10 cars knowing that I can only use 4 when I need to use them. BTW, if I know the location of the emergency sites, would it be the best idea to go with ONE service provider who is willing to provide end-to-end treatment? It sounds like a VPN in this case. >Imagine 3 locations, two "regular" and one ETS share a connection to the >network. This link can get congested. Suppose regular locations are moving >traffic at about 50% of that link speed while ETS is sending traffic at >about 45% of the link speed. Normally, (assuming we can load to 100%), we >should see 45% of the traffic drop and it might all be assumed to be roughly >distributed among the locations. What I'm suggesting is a way for ETS >traffic to have preferential access. If the guaranteed minimum were 40% for >ETS, then only 5% of that ETS traffic would be dropped. > > > > -- > -- Regular 50% link speed --- > --- //-- --\\ > --- --- / \ > ----- -- bottleneck link / \ > ----- -- | Network | > Regular --- ------------------------+ | > 50% link speed| | | > --- | | | > ---- | \ / > --- | dropped \ / > -- | \\-- --// > ETS 45% | --- > \ | / > \|/ > \ > > traffic dropped 45%, > 40% regular traffic > 5% ETS > > Interesting concept! How would you distinguish ETS and non-ETS traffic from a routing perspective? Cheers, An _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 14:19:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08758 for ; Tue, 1 Apr 2003 14:19:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31JhF412305 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 14:43:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JhFK12302 for ; Tue, 1 Apr 2003 14:43:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08729 for ; Tue, 1 Apr 2003 14:18:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JfSK12157; Tue, 1 Apr 2003 14:41:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JavK11154 for ; Tue, 1 Apr 2003 14:36:57 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08547 for ; Tue, 1 Apr 2003 14:12:33 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 7CC7067103; Tue, 1 Apr 2003 14:34:53 -0500 (EST) Date: Tue, 1 Apr 2003 14:15:00 -0500 Subject: Re: [Ieprep] access and enterprise networks Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Ieprep (E-mail)" To: "Nguyen, An" From: RJ Atkinson In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D02EF4DF3@emshqs1.ncr.disa.mil> Message-Id: <3BCF0ACF-6476-11D7-863B-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, Apr 1, 2003, at 13:57 America/Montreal, Nguyen, An wrote: > BTW, if I know the location of the emergency sites, > would it be the best idea to go with ONE service provider who is > willing to > provide end-to-end treatment? It sounds like a VPN in this case. If one knows the location of the emergency sites, the simplest approach is to build a private/dedicated layer-2 connection between those sites. That layer-2 might (for example) be build using Ethernet over dark fibre, using ATM and/or SONET, using Frame Relay, or using mundane T1, E1, or T3 circuits. This is approximately the strategy of the {N,S}IPRnet, which is built primarily on top of leased L2 capacity and provides private network services to many US DoD sites. I am not aware of any IP VPN provider that offers any end-to-end preferential treatment of IP packets. Maybe one exists someplace, but I'm not aware of any (and I have looked). Ran rja@extremenetworks.com _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 14:24:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09095 for ; Tue, 1 Apr 2003 14:24:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31Jmg112928 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 14:48:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JmgK12925 for ; Tue, 1 Apr 2003 14:48:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09069 for ; Tue, 1 Apr 2003 14:24:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JlGK12618; Tue, 1 Apr 2003 14:47:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JhpK12330 for ; Tue, 1 Apr 2003 14:43:51 -0500 Received: from pfwssp1.ncr.disa.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08780 for ; Tue, 1 Apr 2003 14:19:27 -0500 (EST) Received: from mtassp3.ncr.disa.mil by pfwssp1.ncr.disa.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 1 Apr 2003 19:09:40 UT Received: by mtassp3.ncr.disa.mil with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 14:19:58 -0500 Message-ID: <7F18415E4D63CB45BB9B3A591F68D12D02EF4DF4@emshqs1.ncr.disa.mil> From: "Nguyen, An" To: "'RJ Atkinson'" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 14:19:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Ran, >I am not aware of any IP VPN provider that offers any end-to-end >preferential treatment of IP packets. Maybe one exists someplace, >but I'm not aware of any (and I have looked). Sorry, I did not use the right terminology. I meant it from an DiffServ/MPLS perspective :-). An _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 14:35:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09807 for ; Tue, 1 Apr 2003 14:35:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31Jxa313608 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 14:59:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JxaK13605 for ; Tue, 1 Apr 2003 14:59:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09780 for ; Tue, 1 Apr 2003 14:35:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Jw3K13512; Tue, 1 Apr 2003 14:58:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31JtTK13434 for ; Tue, 1 Apr 2003 14:55:29 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09558 for ; Tue, 1 Apr 2003 14:31:05 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id A8ABD67103; Tue, 1 Apr 2003 14:53:25 -0500 (EST) Date: Tue, 1 Apr 2003 14:33:32 -0500 Subject: Re: [Ieprep] access and enterprise networks Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Ieprep (E-mail)" To: "Nguyen, An" From: RJ Atkinson In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D02EF4DF4@emshqs1.ncr.disa.mil> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, Apr 1, 2003, at 14:19 America/Montreal, Nguyen, An wrote: >> I am not aware of any IP VPN provider that offers any end-to-end >> preferential treatment of IP packets. Maybe one exists someplace, >> but I'm not aware of any (and I have looked). > > Sorry, I did not use the right terminology. > I meant it from an DiffServ/MPLS perspective :-). I think your terminology was just fine. I just don't know any IP or IP VPN operator that actually has enabled DiffServ inside the operator's core for any customer packets (nor do I know of any with any form of real end-to-end DiffServ/ToS deployment). I know of a few that use one codepoint for internal routing/network-mgmt traffic and another codepoint for all customer traffic, but those operators clear all IP ToS bits on inbound customer packets. There are also some (e.g. from IETF/Atlanta presentation by Sprint.net) that will read ToS bits on the inbound access link only (i.e. this is not an end-to-end service). There might be some MPLS Layer-2 VPN providers that provide a layer-2 private-line service that has been provisioned in the style of Frame Relay. I'm not aware of any, but some might exist someplace. However, this again would basically be equivalent to purchasing layer-2 capacity and building a private network for oneself (see previous example). Cheers, Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 14:42:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10231 for ; Tue, 1 Apr 2003 14:42:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31K6bV14045 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 15:06:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31K6bK14042 for ; Tue, 1 Apr 2003 15:06:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10224 for ; Tue, 1 Apr 2003 14:42:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31K54K13965; Tue, 1 Apr 2003 15:05:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31K4EK13892 for ; Tue, 1 Apr 2003 15:04:14 -0500 Received: from mclmx.mail.saic.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10136 for ; Tue, 1 Apr 2003 14:39:50 -0500 (EST) Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for ieprep@ietf.org; Tue, 1 Apr 2003 14:40:49 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003040114420132045 ; Tue, 01 Apr 2003 14:42:01 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id <2AXFG72D>; Tue, 1 Apr 2003 14:41:38 -0500 Message-Id: From: "King, Kimberly S." To: "'Nguyen, An'" , "'King, Kimberly S.'" Cc: "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 14:41:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , An, >Interesting idea! Why would I buy 10 cars knowing that I can >only use 4 when >I need to use them. I don't think we are communicating. If getting 40% of the shared bandwidth from a public serving ISP isn't good enough (or some reasonable percent) then you need to consider a priviate network. As was discussed at the last meeting, it is highly improbable that an ISP will give ETS 100% of the bandwidth, even if they ask. This sharing idea is consistent with Wireless Priority Service. If you can find an ISP willing to offer you 100% bandwidth and they feel their other customers will accept such service during emergencies then fine. Some pointed out that everyday folks made important 911 calls during September 11th. I have no axe to grind, I'm just repeating points made by others at previous ieprep meetings and on the lists. An said: >Interesting concept! How would you distinguish ETS and non-ETS >traffic from >a routing perspective? The type of classification I described can be done many ways. One simple way is to imagine a router who connects to three customers. The router can keep track of what packets came in on what link. This is an easy technical problem and Ran mentioned some techniques earlier. The point shouldn't be the mechanism here, the point should be is this service acceptable and if not then can you provide a concrete alternative? Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 14:46:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10406 for ; Tue, 1 Apr 2003 14:46:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31KA5w15022 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 15:10:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KA5K15019 for ; Tue, 1 Apr 2003 15:10:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10381 for ; Tue, 1 Apr 2003 14:45:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31K83K14933; Tue, 1 Apr 2003 15:08:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31K7rK14894 for ; Tue, 1 Apr 2003 15:07:53 -0500 Received: from seahorse.shentel.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10293 for ; Tue, 1 Apr 2003 14:43:28 -0500 (EST) Received: from Steve (ha96s611.d.shentel.net [204.111.98.99]) by seahorse.shentel.net (8.11.6/8.11.6) with SMTP id h31JjXl07620; Tue, 1 Apr 2003 14:45:33 -0500 From: "Steve Silverman" To: "King, Kimberly S." , "'Stuart \(Stu\) Goldman'" , "'Nguyen An'" Cc: "Ieprep \(E-mail\)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 14:47:52 -0500 Message-ID: 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.2800.1106 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Actually, I think the siren analogy is quite good. When emergency traffic does have to get thru, (most rational) people don't mind making way for that emergency traffic even if they are slightly delayed. One factor is that such emergency traffic (let's not call it e-traffic) is less than 1% of the total. Thus, overall, the impact on normal users is acceptable. Such prioritization is possible at the packet network. The Multi-Level Expedited Forwarding PHB has been built and successfully tested. An I-D was submitted on this subject just before the SF meeting but then the Diffserv WG was closed. This does not address signalling or authorization but I view these as solvable problems. The PHB does demonstrate that multiple levels of priority can work in a packet network. Now the question is: Do we need "Emergency Vehicles" on a global voice network? People with some backgrounds answer "Of course", while others respond negatively. (Perhaps they also refuse to pull over when overtaken by an ambulance.) The analogy shouldn't be pushed too hard but the function is necessary to the DOD and some other possible customers have indicated interest. Steve Silverman Houston Associates > -----Original Message----- > From: ieprep-admin@ietf.org > [mailto:ieprep-admin@ietf.org]On Behalf Of > King, Kimberly S. > Sent: Tuesday, April 01, 2003 1:51 PM > To: 'Stuart (Stu) Goldman'; King Kimberly S.; 'Nguyen An' > Cc: Ieprep (E-mail) > Subject: RE: [Ieprep] access and enterprise networks > > > Stu, > > >There is also another method for solving particular congestion > >problems (at > >least for some cars). One can put in a special lane (say for > >high occupancy > >cars) on that highway. > > > >I was surprised that you did not also address those few > >selected vehicles > >with flashing lights and a siren that can get "Platinum > Service" on the > >existing roads without the need for new lanes. > > Not sure how to answer. I was speaking figuratively to get > the ideas > across. > > One idea...if the road in question is a loaded link, then > all packets > already on that link have to move in order. I can't tell > packets to pull > over into the curb of a link because there is a packet with > a siren and > flashing lights behind it. We have no space to pull over. > > Another idea...if the analogy is the entrance onto the > highway, then this > "platinum service" is basically what I have described as > gold. There is a > preference to which cars get entry. This is invariant of > whether you use > the preference for a particular ingress link connected to > an ETS location, > whether the packets are labeled using DiffServ, or whether > the packets are > associated with a particular RSVP reservation. It's all basically > scheduling at any one hop. > > Perhaps this clarifies. > > 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 From mailnull@www1.ietf.org Tue Apr 1 15:17:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13153 for ; Tue, 1 Apr 2003 15:17:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31KfjV17148 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 15:41:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KfjK17145 for ; Tue, 1 Apr 2003 15:41:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13110 for ; Tue, 1 Apr 2003 15:17:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Ke9K17026; Tue, 1 Apr 2003 15:40:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KdDK16967 for ; Tue, 1 Apr 2003 15:39:13 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12785 for ; Tue, 1 Apr 2003 15:14:47 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 76A5867103; Tue, 1 Apr 2003 15:37:08 -0500 (EST) Date: Tue, 1 Apr 2003 15:17:14 -0500 Subject: Re: [Ieprep] access and enterprise networks Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Ieprep" To: "Steve Silverman" From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, Apr 1, 2003, at 14:47 America/Montreal, Steve Silverman wrote: > Actually, I think the siren analogy is quite good. When emergency > traffic does have to get thru, > (most rational) people don't mind making way for that emergency > traffic even if they are slightly delayed. An issue is that buffering in access/enterprise CPE routers/switches is generally pretty shallow (because folks who buy such products do not want to buy RTT ms of buffer). So in the places likely to have congestion, lack of buffering might be a significant practical issue for the deployed equipment. Which is to say, the choice is not "slightly delayed" versus "not delayed" but instead is "dropped" versus "forwarded" -- to use the increasingly strained traffic analogy. > One factor is that such emergency traffic (let's not call it > e-traffic) is less than 1% of the total. Thus, overall, > the impact on normal users is acceptable. Maybe. The 1% number comes from GETS statistics, right ? Not from any real IP-based service, right ? If someone actually has specific measured IP packet utilisation for an IP-based preference system, that would be interesting to hear about and a lot more relevant to the discussions here. > Such prioritization is possible at the packet network. The > Multi-Level Expedited Forwarding PHB has been built and successfully > tested. A significant problem is detecting forged packets or forged IP ToS bits on packets. Absent such ability to detect bogon packets, deployment of end-to-end DiffServ (with any DiffServ PHB) creates a trivially-exploited DoS/DDoS attack on the infrastructure. Within a single policy domain, ACLs or other filtering *might* be able to reduce that risk to acceptable levels. However, no one has described any mechanism for reducing that risk to acceptable levels in an inter-domain context. > This does not address signalling or authorization but I view these as > solvable problems. It would be interesting to see your specific proposals on those issues (and on authentication, without which authorisation could be subverted). Are there any I-Ds on those ? > The PHB does demonstrate that multiple levels of > priority can work in a packet network. We already knew that from the old (80s) DDN, which deployed the RFC-791 8-level DoD precedence system in the production DDN of that time. > Now the question is: Do we need "Emergency Vehicles" on a global > voice network? I don't think so. I think the first questions are can any such system be deployed in any reasonable way. So far, the answer is that such a system could only reasonably be deployed within a single policy domain. Absent specific credible technical proposals that solve the inter-domain issues, it is greatly premature to raise the question quoted above, IMHO. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 17:13:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18128 for ; Tue, 1 Apr 2003 17:13:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31MbZm26967 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 17:37:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MbZK26964 for ; Tue, 1 Apr 2003 17:37:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18114 for ; Tue, 1 Apr 2003 17:13:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MZ9K26126; Tue, 1 Apr 2003 17:35:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MWMK25899 for ; Tue, 1 Apr 2003 17:32:22 -0500 Received: from seahorse.shentel.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17889 for ; Tue, 1 Apr 2003 17:07:55 -0500 (EST) Received: from Steve (ha96s755.d.shentel.net [204.111.98.243]) by seahorse.shentel.net (8.11.6/8.11.6) with SMTP id h31MAHl08578; Tue, 1 Apr 2003 17:10:17 -0500 From: "Steve Silverman" To: "RJ Atkinson" Cc: "Ieprep" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 1 Apr 2003 17:12:36 -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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Tuesday, April 01, 2003 3:17 PM > To: Steve Silverman > Cc: Ieprep > Subject: Re: [Ieprep] access and enterprise networks > > > > On Tuesday, Apr 1, 2003, at 14:47 America/Montreal, Steve Silverman > wrote: > > Actually, I think the siren analogy is quite good. When emergency > > traffic does have to get thru, > > (most rational) people don't mind making way for that emergency > > traffic even if they are slightly delayed. > > An issue is that buffering in access/enterprise CPE routers/switches > is generally pretty shallow (because folks who buy such products > do not want to buy RTT ms of buffer). > > So in the places likely to have congestion, lack of buffering > might be a significant practical issue for the deployed equipment. > > Which is to say, the choice is not "slightly delayed" versus "not > delayed" > but instead is "dropped" versus "forwarded" -- to use the > increasingly > strained traffic analogy. Yes, some packets will be dropped. Voice packets that are delayed more than a jitter buffer's worth are worthless. But these should be a small percentage of any one user's packets. see below. > > > One factor is that such emergency traffic > > is less than 1% of the total. Thus, overall, > > the impact on normal users is acceptable. > > Maybe. The 1% number comes from GETS statistics, right ? > Not from any real IP-based service, right ? The number of users in each DOD priority class is less than 10% of the class below it. I do not believe that anybody has run tests on this but my guess is that very few users would notice much degradation of voice quality. > > A significant problem is detecting forged packets or forged > IP ToS bits > on packets. Granted. I have been working on DISA to fund work in this area for some time. > > > This does not address signalling or authorization but I > view these as > > solvable problems. > > It would be interesting to see your specific proposals on > those issues > (and on authentication, without which authorisation could > be subverted). > > Are there any I-Ds on those ? They haven't funded me to do this yet. This is a big area. I would expect a number of people/companies to be involved in this once they decide to do it. They can't deploy VoIP without it. > > > Now the question is: Do we need "Emergency Vehicles" on a global > > voice network? > > I don't think so. You are certainly entitled to your opinion but the JCS has stated that MLPP must be supported and VoIP can't be deployed without it. This is only one private net but in the past, it has set a standard for various other nets and the DOD tries to run multi-vendor networks so they prefer standards done in a public forum. That's why this is being discussed here. I think the first questions are can any > such system > be deployed in any reasonable way. So far, the answer is > that such a > system could only reasonably be deployed within a single > policy domain. Actually, the DOD is primarily interested in one policy domain, their private network. But I think that if VoIP is ever to be supported by real carriers as a public net, the architectural model and certain security aspects will change signficantly from the current model. The current SIP architecture is based on "smart terminal, dumb fast network". This is OK if you trust everyone but history has shown that is a poor assumption. I predict that before Verizon or SBC is going to invest $Bs, they are going to demand much better safeguards than are available now. This may ease the problems faced by the DOD since all major carriers have some of the same concerns. Steve Silverman > > Absent specific credible technical proposals that solve the > inter-domain issues, > it is greatly premature to raise the question quoted above, IMHO. I think it is good to have an overview of where you are trying to head. > Ran > > _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 1 20:30:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24358 for ; Tue, 1 Apr 2003 20:30:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h321seu07580 for ieprep-archive@odin.ietf.org; Tue, 1 Apr 2003 20:54:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321seK07577 for ; Tue, 1 Apr 2003 20:54:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24309 for ; Tue, 1 Apr 2003 20:30:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321rBK07462; Tue, 1 Apr 2003 20:53:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321pvK07402 for ; Tue, 1 Apr 2003 20:51:57 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24188 for ; Tue, 1 Apr 2003 20:27:24 -0500 (EST) Received: from extremenetworks.com (unknown [10.0.8.103]) by gnat.inet.org (Postfix) with ESMTP id 40AFA67103; Tue, 1 Apr 2003 20:49:13 -0500 (EST) Date: Tue, 1 Apr 2003 20:28:11 -0500 Subject: Re: [Ieprep] access and enterprise networks Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Ieprep" To: "Steve Silverman" From: RJ Atkinson In-Reply-To: Message-Id: <5E3C2190-64AA-11D7-A137-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, Apr 1, 2003, at 17:12 America/Montreal, Steve Silverman wrote: > Yes, some packets will be dropped. Voice packets that are delayed > more than a jitter buffer's worth are worthless. But these should be > a small percentage of any one user's packets. see below. At least some of us think of IEprep as not being limited to voice applications. Certainly DISA folks (that I talk with about their interest in precedence for IP networks) are saying that voice is not the main application of concern for QoS. Their main concerns seem to be with TCP-based applications, such as mail/web/ftp/C3I stuff. >>> One factor is that such emergency traffic >>> is less than 1% of the total. Thus, overall, >>> the impact on normal users is acceptable. >> >> Maybe. The 1% number comes from GETS statistics, right ? >> Not from any real IP-based service, right ? > > The number of users in each DOD priority class is less than 10% of the > class below it. I do not believe that anybody has run tests on this > but my guess is that very few users would notice much degradation of > voice quality. Are you saying that the statistics are for the AutoVON (DSN) system ? Are you saying that this is what the (some part of US DoD) has as a policy statement for their priority schema ? Or are you saying something else ? And when you say "degradation of voice quality", what is that in reference to ? >> A significant problem is detecting forged packets or forged >> IP ToS bits on packets. > > Granted. I have been working on DISA to fund work in this area > for some time. DARPA might be more likely to fund R&D on that. >>> This does not address signalling or authorization but I >>> view these as solvable problems. >> >> It would be interesting to see your specific proposals on >> those issues (and on authentication, without which authorisation >> could be subverted). >> >> Are there any I-Ds on those ? > > They haven't funded me to do this yet. This is a big area. I would > expect a number of people/companies to be involved in this once > they decide to do it. They can't deploy VoIP without it. I'll just say that it is not clear to me that these issues are practical to solve in an inter-domain context. Colour me sceptical at least until a specific documented proposal appears that can be openly evaluated. :-) >>> Now the question is: Do we need "Emergency Vehicles" on a global >>> voice network? >> >> I don't think so. > You are certainly entitled to your opinion but the JCS has stated > that MLPP must be supported and VoIP can't be deployed without it. You misinterpret my comment. I was saying that "I don't think that is the actual question at hand", rather than trying to answer the question either way. One possible outcome from the JCS policy statement is that DISA/DoD don't deploy VoIP. Resolving the conflicts (if any) between their policy choices and the technology they choose to deploy is their local matter, rather than an IETF standards issue. > This is only one private net but in the past, it has set a standard > for various other nets It hasn't set a standard for non-government networks in at least 10 years. In fact, at the moment, DISA (e.g. in GigBE) is directly trying to change its modus operandi and instead of past practices, DISA is trying to directly emulate "commercial best practices" in evolving its deployed IP networks and services to be more effective than the current {N,S}IPRnet. > and the DOD tries to run multi-vendor networks so they prefer > standards done in a public forum. That's why this is being discussed > here. Lets not rathole, but I think DISA's MLPP problem is *solved* (and am happy to explain why, in person if that's helpful) by DiffServ -- in large part because DoD is a single policy domain, so the inter-domain issues aren't particularly the ones facing DoD or DISA. And I further think this is solved in existing IETF standards and with product available from more than one vendor (though maybe not available from all vendors). > I think the first questions are can any >> such system >> be deployed in any reasonable way. So far, the answer is >> that such a >> system could only reasonably be deployed within a single >> policy domain. > > Actually, the DOD is primarily interested in one policy domain, their > private network. See above. > But I think that if VoIP is ever to be supported by real carriers as a > public net, the architectural model and certain security aspects will > change > signficantly from the current model. A lot depends on what you mean by "real carriers". At least 2 different definitions come to mind: (A) real IP carriers (B) real telephony/voice carriers Now group (A) is focused on moving IP packets around and tries VERY hard not to look at more than the Destination IP address. They have said repeatedly on this list and in IEprep meetings that they do not plan to change this focus anytime soon. Group (B) might (hypothetically) move to a VoIP infrastructure, but appears most likely to do so over an essentially closed, specially engineered, IP network -- rather than over the networks operated by folks in (A) -- at least for the forseeable future. My own experience over the past several months, using the Bill Woodcock phone system, is that his phone system works really well. I share Sally Floyd's concerns that the current technology underlying that phone system lacks adequate congestion avoidance and control -- hence might not be healthy for the global Internet, but that's a separate issue from whether it works or not. > The current SIP architecture is based on "smart terminal, dumb fast > network". This is OK if you trust everyone but history has shown > that is a poor assumption. Au contraire. History for the past ~20 years is that "smart host, dumb fast network" is a VERY GOOD assumption for an IP network or for applications on an IP network. The history of voice telephony networks and of IP networks is necessarily largely disjoint over the same time period. Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Apr 2 10:45:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14514 for ; Wed, 2 Apr 2003 10:45:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32GA1c19483 for ieprep-archive@odin.ietf.org; Wed, 2 Apr 2003 11:10:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32GA1K19474 for ; Wed, 2 Apr 2003 11:10:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14488 for ; Wed, 2 Apr 2003 10:45:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32G8IK19305; Wed, 2 Apr 2003 11:08:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32G7xK19263 for ; Wed, 2 Apr 2003 11:07:59 -0500 Received: from [140.32.132.66] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14412 for ; Wed, 2 Apr 2003 10:43:11 -0500 (EST) Received: from mail.nps.navy.mil by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Wed, 2 Apr 2003 07:41:54 -0800 Received: from ro179-38.ro.nps.navy.mil (ro179-38.ro.nps.navy.mil [131.120.179.38]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id h32FhdTw023450; Wed, 2 Apr 2003 07:43:40 -0800 (PST) Subject: Re: [Ieprep] access and enterprise networks From: Rex Buddenberg To: RJ Atkinson Cc: Steve Silverman , Ieprep In-Reply-To: <5E3C2190-64AA-11D7-A137-00039357A82A@extremenetworks.com> References: <5E3C2190-64AA-11D7-A137-00039357A82A@extremenetworks.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 02 Apr 2003 04:46:36 -0800 Message-Id: <1049287597.1024.324.camel@ziggy> Mime-Version: 1.0 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm a bit unclear on the objective. Sigh ... qos/QoS discussions remind me of the observation about economists: if you lined them all up end to end, they still couldn't reach a conclusion. Is the objective to have internet access for emergency services or is it to have high quality of service (definition unclear) internet access ...(but on links that may not exist)? Reiterate my plowshares-->swords checklist: - availability/survivability - security - qos - reach to mobile platforms in my experience most requirements issues fall in these four bins so makes a good checklist to see if you've got arms around the whole problem. From the thread of the last couple days, it looks like we've got one of the four trees (qos) in the forest. And, IMHO, not the most important ones. Running through the checklist: - IP, by it's nature, is very amenable to high availability solutions by provisioning backup comms so that outages can be routed around. I counsel my students to start here ... you may find yourself putting a lot of the qos worries into the no-nevermind category. - the security component for emergency services that is most critical is authenticity. The technology is such that if you solve the authenticity problem (and integrity is a subset solution), then you have all the pieces necessary for confidentiality as well. - qos. In the emergency services situations I dealt with in a former life, I was generally happy when I had comms. Whether it was 'high quality' comms was never an issue. Personally, I find the arguments about QoS a bit tiresome and I can't shake the opinion that we're chasing after a non-problem to the neglect of the real problems. - reach to mobile platforms is a big issue for emergency services just as it is for the military. This category is also rife with solutions (some of them pretty bad) chasing rather undefined problems. Strikes me that using IEPREP to articulate the problem here would be useful... My observation of the traffic loading is that what used to be voice applications tend to shift to some other flavor of data as they get increasingly automated. If engineered at all intelligently, this almost always results in a more loosely coupled system meaning that there's increasingly less need to fiddle with default qos behavior. An example. The dispatcher needs to know where the fire department's engines are. So she calls up on the radio and the engine driver responds with his position (either by reading a street sign or by reading the numbers off a radionav receiver). Now overhaul the system so the engine reports its position automagically ... without pestering the driver. We make the radionav receiver an end system on the network and it periodically (or on poll, a la SNMP) reports its Lat/Long coordinates which are poured into the dispatcher's database and displayed on the GIS GUI. At this stage of automation, the bursty behavior of the internet is inconsequential. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Apr 2 16:42:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11001 for ; Wed, 2 Apr 2003 16:42:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32M7Hw22985 for ieprep-archive@odin.ietf.org; Wed, 2 Apr 2003 17:07:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32M7HK22974 for ; Wed, 2 Apr 2003 17:07:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10995 for ; Wed, 2 Apr 2003 16:42:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32M5LK22608; Wed, 2 Apr 2003 17:05:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32M47K22506 for ; Wed, 2 Apr 2003 17:04:07 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10855 for ; Wed, 2 Apr 2003 16:39:11 -0500 (EST) Received: from KC-MAIL3.kc.umkc.edu ([134.193.143.110] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 15:41:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ieprep] access and enterprise networks Date: Wed, 2 Apr 2003 15:41:39 -0600 Message-ID: Thread-Topic: [Ieprep] access and enterprise networks Thread-Index: AcL5Lvsl+llEGe5QQPOKaKrIGZ5sTgALmZCA From: "Beard, Cory" To: "Rex Buddenberg" , "RJ Atkinson" Cc: "Steve Silverman" , "Ieprep" X-OriginalArrivalTime: 02 Apr 2003 21:41:39.0961 (UTC) FILETIME=[A4F6CE90:01C2F960] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h32M48K22507 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Is the objective to have internet access for emergency services > or is it > to have high quality of service (definition unclear) internet > access ...(but on links that may not exist)? I very much agree. There is a very real possibility of seeking to provide _unnecessarily good service_ to emergency users. I have not heard it said that emergency users, for example, require better quality audio. There is no reason for an emergency packet to move to the head of the queue when it arrives at a router. It just should not be as likely to be dropped or experience unacceptably high delay. Our belief is that the solution lies with an authentication/marking mechanism coupled with emergency-oriented active queue management that during congestion drops packets in a preferential manner. This would only be done at choke points, not along the whole path. These choke points would likely be at the uplinks to ISP's, regional networks (like the network here in Missouri that connects all the schools in the state together), and in resource-constrained access links (wireless, residential cable networks, etc.) Some of this is discussed in the Framework draft in Section 4.1.3. Any comments about what is written there? Cory Beard _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Apr 2 23:05:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23561 for ; Wed, 2 Apr 2003 23:05:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3347tS21865 for ieprep-archive@odin.ietf.org; Wed, 2 Apr 2003 23:07:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3347tK21862 for ; Wed, 2 Apr 2003 23:07:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23553 for ; Wed, 2 Apr 2003 23:05:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3346FK20957; Wed, 2 Apr 2003 23:06:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3345AK20865 for ; Wed, 2 Apr 2003 23:05:10 -0500 Received: from imo-r03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23475 for ; Wed, 2 Apr 2003 23:02:33 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v34.21.) id i.b8.3d67bf84 (3890); Wed, 2 Apr 2003 23:04:55 -0500 (EST) Message-ID: Date: Wed, 2 Apr 2003 23:04:55 EST Subject: Re: [Ieprep] access and enterprise networks To: budden@nps.navy.mil, rja@extremenetworks.com CC: steves@shentel.net, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_b8.3d67bf84.2bbd0ce7_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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: , --part1_b8.3d67bf84.2bbd0ce7_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/2/2003 10:46:50 AM Eastern Standard Time, budden@nps.navy.mil writes: > - qos. In the emergency services situations I dealt with in a former > life, I was generally happy when I had comms. Whether it was 'high > quality' comms was never an issue. Personally, I find the arguments > about QoS a bit tiresome and I can't shake the opinion that we're > chasing after a non-problem to the neglect of the real problems. > I couldn't agree more. This QoS issue and bickering has been sidetracking the real issue, especially since QoS is generally equated with the few parameters associated with transfer of speech packets (loss, delay, delay variation) and not with the broader call setup "QOS" parameters such as call setup time, probability of call failure, probability of premature disconnect, etc. There has recently been some suggestions that what ETS or Assured Service wants is better QOS than the normal traffic gets during normal times. This is not true. As Rex indicated, emergency users would be satisfied with worse QOS (regarding transmission of speech) as long as the connection is set up. That is, in an emergency situation when normal users have something close to 0% chance of getting a call through, the emergency working must have a significantly higher probability. Mike --part1_b8.3d67bf84.2bbd0ce7_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 4/2/20= 03 10:46:50 AM Eastern Standard Time, budden@nps.navy.mil writes:


 - qos.  In the=20= emergency services situations I dealt with in a former
life, I was generally happy when I had comms.  Whether it was 'high
quality' comms was never an issue.  Personally, I find the argument= s
about QoS a bit tiresome and I can't shake the opinion that we're
chasing after a non-problem to the neglect of the real problems.


I couldn't agree more. This QoS issue and bickering has been sidetrackin= g the real issue, especially since QoS is generally equated with the few par= ameters associated with transfer of speech packets (loss, delay, delay varia= tion) and not with the broader call setup "QOS" parameters such as call setu= p time, probability of call failure, probability of premature disconnect, et= c.

There has recently been some suggestions that what ETS or Assured Servic= e wants is better QOS than the normal traffic gets during normal times. This= is not true. As Rex indicated, emergency users would be satisfied with wors= e QOS (regarding transmission of speech) as long as the connection is set up= . That is, in an emergency situation when normal users have something close=20= to 0% chance of getting a call through, the emergency working must have a si= gnificantly higher probability.

Mike
--part1_b8.3d67bf84.2bbd0ce7_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Wed Apr 2 23:05:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23575 for ; Wed, 2 Apr 2003 23:05:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3347u221881 for ieprep-archive@odin.ietf.org; Wed, 2 Apr 2003 23:07:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3347uK21878 for ; Wed, 2 Apr 2003 23:07:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23557 for ; Wed, 2 Apr 2003 23:05:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3346IK20980; Wed, 2 Apr 2003 23:06:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3345MK20890 for ; Wed, 2 Apr 2003 23:05:22 -0500 Received: from imo-r04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23478 for ; Wed, 2 Apr 2003 23:02:45 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v34.21.) id f.7a.3ca4d34c (3890); Wed, 2 Apr 2003 23:04:56 -0500 (EST) Message-ID: <7a.3ca4d34c.2bbd0ce8@aol.com> Date: Wed, 2 Apr 2003 23:04:56 EST Subject: Re: [Ieprep] access and enterprise networks To: BeardC@umkc.edu, budden@nps.navy.mil, rja@extremenetworks.com CC: steves@shentel.net, ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_7a.3ca4d34c.2bbd0ce8_boundary" X-Mailer: 6.0 for Windows XP sub 10501 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: , --part1_7a.3ca4d34c.2bbd0ce8_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/2/2003 4:44:51 PM Eastern Standard Time, BeardC@umkc.edu writes: > There is a very real possibility of seeking to provide _unnecessarily good > service_ to emergency users. I have not heard it said that emergency > users, for example, require better quality audio. There is no reason for > an emergency packet to move to the head of the queue when it arrives at a > router. It just should not be as likely to be dropped or experience > unacceptably high delay. > This is exactly the point of the MLEF that Steve Silverman referred to and explained in a draft. "Emergency" packets are not queued ahead of others. Thay have lower drop probability. Mike --part1_7a.3ca4d34c.2bbd0ce8_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 4/2/20= 03 4:44:51 PM Eastern Standard Time, BeardC@umkc.edu writes:


There is a very real possib= ility of seeking to provide _unnecessarily good service_ to emergency users.=  I have not heard it said that emergency users, for example, require b= etter quality audio.  There is no reason for an emergency packet to mov= e to the head of the queue when it arrives at a router.  It just should= not be as likely to be dropped or experience unacceptably high delay.


This is exactly the point of the MLEF that Steve Silverman referred to a= nd explained in a draft. "Emergency" packets are not queued ahead of others.= Thay have lower drop probability.

Mike
--part1_7a.3ca4d34c.2bbd0ce8_boundary-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Apr 3 05:09:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12320 for ; Thu, 3 Apr 2003 05:09:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33ABoj29657 for ieprep-archive@odin.ietf.org; Thu, 3 Apr 2003 05:11:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33ABoK29654 for ; Thu, 3 Apr 2003 05:11:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12279 for ; Thu, 3 Apr 2003 05:09:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AA2K29285; Thu, 3 Apr 2003 05:10:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33A4gK28182 for ; Thu, 3 Apr 2003 05:04:42 -0500 Received: from clifden.donelan.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12004 for ; Thu, 3 Apr 2003 05:01:54 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #3) id 1911a3-0002R1-00 for ieprep@ietf.org; Thu, 03 Apr 2003 05:04:23 -0500 Date: Thu, 3 Apr 2003 05:04:23 -0500 (EST) From: Sean Donelan To: ieprep@ietf.org Subject: Re: [Ieprep] access and enterprise networks In-Reply-To: Message-ID: 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: , On Wed, 2 Apr 2003 Mpierce1@aol.com wrote: > There has recently been some suggestions that what ETS or Assured Service > wants is better QOS than the normal traffic gets during normal times. This is > not true. This is not a recent development, many times it has been stated that there needs to be a "better than best effort" level of service for emergency traffic. Since during normal times, providers may offer "best effort" service, during an emergency the definition may be "best available" service. But in neither case will it be better than the best service the provider offers. > As Rex indicated, emergency users would be satisfied with worse QOS > (regarding transmission of speech) as long as the connection is set up. That > is, in an emergency situation when normal users have something close to 0% > chance of getting a call through, the emergency working must have a > significantly higher probability. The connection is set up? What does that mean in a packet switched network? The probability of a packet getting through to "set up" the connection will be similar to the packets getting through during the "call" (instaneously changing depending on network conditions). If there is close to 0% chance of setting up the call on a packet switched network, then even if you do magic to set up the call, there will be probably close to 0% chance of receiving any speech packets on the same packet switched network (modulo the issue with gateways, proxies, and directories using different transmission paths) so emergency works will hear dead air. What I've found interesting using IP telephony is its easier to set up a call than it is to transmit and receive the speech packets. One of the most common trouble shooting problems I have is the phones ring, say connected, but get dead air or unintelligible audio. Because the call set up messages are relatively small and are re-transmitted, even in extremely congested networks the SIP messages seem to get through with little user visible delay. Most of the reports I've seen on whether VOIP is ready for prime time concern the problems with the quality of the speech path, not with getting the call set up packets through the network. So if I was looking at the real problems I'm seeing in the network, call set up doesn't seem to be the problem needing to be solved. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Apr 3 06:19:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13940 for ; Thu, 3 Apr 2003 06:19:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33BLGb02889 for ieprep-archive@odin.ietf.org; Thu, 3 Apr 2003 06:21:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BLFK02886 for ; Thu, 3 Apr 2003 06:21:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13933 for ; Thu, 3 Apr 2003 06:18:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BJJK02689; Thu, 3 Apr 2003 06:19:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BI7K02591 for ; Thu, 3 Apr 2003 06:18:07 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13841 for ; Thu, 3 Apr 2003 06:15:23 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 05:17:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ieprep] access and enterprise networks Date: Thu, 3 Apr 2003 05:17:50 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D06D@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] access and enterprise networks Thread-Index: AcL5ll/iZO1qD6GhTR67Hhk6VUmYBAANlzUQ From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: , , Cc: , X-OriginalArrivalTime: 03 Apr 2003 11:17:51.0074 (UTC) FILETIME=[AA05A420:01C2F9D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33BI7K02592 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > This is exactly the point of the MLEF that Steve Silverman referred to and > explained in a draft. "Emergency" packets are not queued ahead of others. > Thay have lower drop probability. ok. But, my question is more general. who are we to suggest a policy configuration? Depending on the contract, ISP provide a suitable service to an emergency responder (i.e. if you pay more, you get a better service.) I forsee different scenarios: situations where the high-priority class is the "best-available" service or just that ieprep works fine with the best-effort. So, I see no reason in discussing a policy issue (i.e. "emergency" packets are not queued ahead of others) _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Apr 3 06:21:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14001 for ; Thu, 3 Apr 2003 06:21:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33BNeB03022 for ieprep-archive@odin.ietf.org; Thu, 3 Apr 2003 06:23:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BNeK03018 for ; Thu, 3 Apr 2003 06:23:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13990 for ; Thu, 3 Apr 2003 06:20:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BM1K02938; Thu, 3 Apr 2003 06:22:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BLCK02882 for ; Thu, 3 Apr 2003 06:21:12 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13930 for ; Thu, 3 Apr 2003 06:18:28 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 05:20:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ieprep] access and enterprise networks Date: Thu, 3 Apr 2003 05:20:55 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D06C@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] access and enterprise networks Thread-Index: AcL5yS55JLxFDHoiQQyOMRedT/ox9QAAUL6g From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Sean Donelan" , X-OriginalArrivalTime: 03 Apr 2003 11:20:56.0313 (UTC) FILETIME=[186EDE90:01C2F9D3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33BLCK02883 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Since during normal times, providers may offer "best effort" service, > during an emergency the definition may be "best available" service. > But in neither case will it be better than the best service the > provider offers. I like this definition of "best available" service. Ken was searching an alternative for "better than best effort". I guess, "best available" service will be an apt choice. > Most of the reports I've seen on whether VOIP is ready for prime > time concern the problems with the quality of the speech path, not > with getting the call set up packets through the network. > > So if I was looking at the real problems I'm seeing in the > network, call set up doesn't seem to be the problem needing to be > solved. I agree with you that call set up is a non-issue. But, as per the quality of speech, vonage (VoIP product)users might disagree with you.Atlast, quality depends on the selection of codec. I presume, you must be an INOC-DBA user and seems it works fine with its available codec. But, more important is change in codec and congetion-aware transport during emergency situations. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Apr 3 07:48:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18023 for ; Thu, 3 Apr 2003 07:48:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33CoxE10671 for ieprep-archive@odin.ietf.org; Thu, 3 Apr 2003 07:50:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CoxK10668 for ; Thu, 3 Apr 2003 07:50:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17995 for ; Thu, 3 Apr 2003 07:48:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CnEK10520; Thu, 3 Apr 2003 07:49:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CmvK10494 for ; Thu, 3 Apr 2003 07:48:57 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17882 for ; Thu, 3 Apr 2003 07:46:11 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 8AC3667103 for ; Thu, 3 Apr 2003 08:08:50 -0500 (EST) Date: Thu, 3 Apr 2003 07:48:38 -0500 Subject: Re: [Ieprep] access and enterprise networks Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: RJ Atkinson To: ieprep Content-Transfer-Encoding: 7bit In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D06C@KC-MAIL4.kc.umkc.edu> Message-Id: <976083B0-65D2-11D7-A0E4-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.551) 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday, Apr 3, 2003, at 06:20 America/Montreal, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > I agree with you that call set up is a non-issue. But, as per the > quality of speech, vonage (VoIP product)users might disagree with > you.Atlast, quality depends on the selection of codec. I presume, > you must be an INOC-DBA user and seems it works fine with its > available codec. But, more important is change in codec and > congetion-aware transport during emergency situations. I'd prefer using some of the (non-ITU) codecs in iVox if I were really in an emergency situation. Certainly DoD reached that conclusion some years back. They work well in low bandwidth situations that have non-trivial packet loss (e.g. Voice/IP/2.4 Kbps HF radio) -- and in an emergency the key thing is to be able to communicate, rather than somewhat abstract ITU defined "quality" of the sound. http://tonnant.itd.nrl.navy.mil/ipresearch/ivox_info.html Ran _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Apr 3 19:42:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21423 for ; Thu, 3 Apr 2003 19:42:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h340iY916008 for ieprep-archive@odin.ietf.org; Thu, 3 Apr 2003 19:44:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340iYK16005 for ; Thu, 3 Apr 2003 19:44:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21402 for ; Thu, 3 Apr 2003 19:41:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340h7K15934; Thu, 3 Apr 2003 19:43:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340gJK15908 for ; Thu, 3 Apr 2003 19:42:19 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21342 for ; Thu, 3 Apr 2003 19:39:19 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 18:41:47 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Ieprep] access and enterprise networks Date: Thu, 3 Apr 2003 18:41:46 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D06F@KC-MAIL4.kc.umkc.edu> Thread-Topic: [Ieprep] access and enterprise networks Thread-Index: AcL532e1nat30vM7REGP22k6D9Ah7AAYjreQ From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "RJ Atkinson" , "ieprep" X-OriginalArrivalTime: 04 Apr 2003 00:41:47.0450 (UTC) FILETIME=[F92481A0:01C2FA42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h340gJK15909 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > I'd prefer using some of the (non-ITU) codecs in iVox if > I were really in an emergency situation. Just curious, what are the codec's which are used widely? I remember you commenting that INOC-DBA sounds fine even with a lousy codec. > Certainly DoD reached that conclusion > some years back. They work well in low bandwidth situations that > have non-trivial packet loss (e.g. Voice/IP/2.4 Kbps HF radio) -- > and in an emergency the key thing is to be able to communicate, > rather than somewhat abstract ITU defined "quality" of the sound. I accept. I don't know whether people see all these mean opinion scores ( as defined by ITU-T) in practice. we should have better rating schemes. But, I would be interested in knowing about practical rating methods available for quality of speech ( other than MOS)... _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Apr 3 20:02:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21725 for ; Thu, 3 Apr 2003 20:02:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3415Lb16704 for ieprep-archive@odin.ietf.org; Thu, 3 Apr 2003 20:05:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3415LK16701 for ; Thu, 3 Apr 2003 20:05:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21720 for ; Thu, 3 Apr 2003 20:02:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34143K16646; Thu, 3 Apr 2003 20:04:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3413LK16591 for ; Thu, 3 Apr 2003 20:03:21 -0500 Received: from bos-gate2.raytheon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21689; Thu, 3 Apr 2003 20:00:20 -0500 (EST) Received: from ds02e00.directory.ray.com (ds02e00.directory.ray.com [147.25.130.245]) by bos-gate2.raytheon.com (8.12.9/8.12.9) with ESMTP id h3412ljY020283; Thu, 3 Apr 2003 20:02:47 -0500 (EST) Received: from ds02e00.directory.ray.com (localhost [127.0.0.1]) by ds02e00.directory.ray.com (8.12.9/8.12.1) with ESMTP id h3412khe029833; Fri, 4 Apr 2003 01:02:46 GMT Received: from ad2-mta02.and.us.ray.com (ad2-mta02.and.us.ray.com [138.127.59.160]) by ds02e00.directory.ray.com (8.12.9/8.12.1) with ESMTP id h3412hkW029809; Fri, 4 Apr 2003 01:02:45 GMT Subject: RE: [Ieprep] access and enterprise networks To: "Ayyasamy, Senthilkumar (UMKC-Student)" Cc: "ieprep" , ieprep-admin@ietf.org, "RJ Atkinson" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Patrick M Killian" Date: Thu, 3 Apr 2003 19:52:06 -0500 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: , We are doing quite a bit government VoIP private network (pt to pt )wan deployments with G729 - non secure and ADPCM G726 secure over satellite and radio. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Fri Apr 4 09:37:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23388 for ; Fri, 4 Apr 2003 09:37:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Edlo20882 for ieprep-archive@odin.ietf.org; Fri, 4 Apr 2003 09:39:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34EdlK20878 for ; Fri, 4 Apr 2003 09:39:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23375 for ; Fri, 4 Apr 2003 09:36:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Ec9K20772; Fri, 4 Apr 2003 09:38:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34EbCK20313 for ; Fri, 4 Apr 2003 09:37:12 -0500 Received: from mawebmail01.remotepipes.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23212 for ; Fri, 4 Apr 2003 09:33:54 -0500 (EST) Received: from happy (unverified [206.149.197.28]) by mawebmail01.remotepipes.net (Vircom SMTPRS 5.1.202) with ESMTP id for ; Fri, 4 Apr 2003 06:36:22 -0800 From: "Ian Brown" To: "'ieprep'" Subject: RE: [Ieprep] access and enterprise networks Date: Fri, 4 Apr 2003 09:36:16 -0500 Message-ID: <002e01c2fab7$8e289a60$6fc495ce@happy> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D06F@KC-MAIL4.kc.umkc.edu> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I don't know whether people see all these mean > opinion scores ( as defined by ITU-T) in practice. we should > have better rating schemes. But, I would be interested in > knowing about practical rating methods available for quality > of speech ( other than MOS)... Much research on better methods of assessing audio and video quality is at http://www.cs.ucl.ac.uk/research/higherview/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Apr 7 12:19:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25375 for ; Mon, 7 Apr 2003 12:19:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37GOFj24116 for ieprep-archive@odin.ietf.org; Mon, 7 Apr 2003 12:24:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GOF824113 for ; Mon, 7 Apr 2003 12:24:15 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25347 for ; Mon, 7 Apr 2003 12:19:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37G9w823424; Mon, 7 Apr 2003 12:09:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37G6I822205 for ; Mon, 7 Apr 2003 12:06:18 -0400 Received: from web41807.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24552 for ; Mon, 7 Apr 2003 12:01:29 -0400 (EDT) Message-ID: <20030407160402.22774.qmail@web41807.mail.yahoo.com> Received: from [65.213.193.49] by web41807.mail.yahoo.com via HTTP; Mon, 07 Apr 2003 09:04:02 PDT Date: Mon, 7 Apr 2003 09:04:02 -0700 (PDT) From: CAITR Reply-To: info@caitr.org To: ieprep@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-64227165-1049731442=:22380" Subject: [Ieprep] Internetworking 2003: Call for Papers 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: , --0-64227165-1049731442=:22380 Content-Type: text/plain; charset=us-ascii Call for Papers ============== Internetworking 2003, June 22-24, 2003, San Jose, California http://www.caitr.org/internetworking03/index.htm REMINDER: Deadline for submissions is April 11, 2003 The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Vishal Sharma, Metanoia - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets - Ran Canetti, Co-chair, IETF Working Group on Multicast Security --0-64227165-1049731442=:22380 Content-Type: text/html; charset=us-ascii

Call for Papers
==============

Internetworking 2003, June 22-24, 2003, San Jose, California
http://www.caitr.org/internetworking03/index.htm

REMINDER: Deadline for submissions is April 11, 2003

The Internetworking 2003 Technical Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots

Conference Technical Co-chairs:
- Dr. Maurice Gagnaire, ENST, France
- Daniel Awduche

Technical Program Committee of the Internetworking 2003 Conference:
- Roberto Sabella, Erisson
- Dr. Moshe Zukerman, Univ. of Melbourne
- Nada Golmie, NIST
- Dr. Guy Pujolle, LIP6, France
- Dr. Samir Tohme, ENST, France
- Stefano Trumpy, Italian National Research Council
- Dr. Ibrahim Habib, City Univ. of NY
- Dr. Vishal Sharma, Metanoia
- Dr. Parviz Yegani, Cisco Systems
- Dr. G.S. Kuo
- Dr. Abbas Jamalipour, Univ. of Sydney
- Dr. Hussein Mouftah, Univ. of Ottawa
- James Kempf
- Elizabeth Rodriguez, Co-chair, IETF Working Group on IP Storage
- Dr. Ferit Yegenoglu, Isocore
- Dr. Ali Zadeh, George Mason University
- Tony Przygienda, Co-chair, IETF Working Group on IS-IS for IP Internets
- Ran Canetti, Co-chair, IETF Working Group on Multicast Security

--0-64227165-1049731442=:22380-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Apr 14 15:57:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19995 for ; Mon, 14 Apr 2003 15:57:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EK4lr18847 for ieprep-archive@odin.ietf.org; Mon, 14 Apr 2003 16:04:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EK4l818844 for ; Mon, 14 Apr 2003 16:04:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19980 for ; Mon, 14 Apr 2003 15:56:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195A6X-0004sE-00 for ieprep-web-archive@ietf.org; Mon, 14 Apr 2003 15:59:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195A6X-0004sA-00 for ieprep-web-archive@ietf.org; Mon, 14 Apr 2003 15:59:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EK3F818776; Mon, 14 Apr 2003 16:03:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EK2c818749 for ; Mon, 14 Apr 2003 16:02:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19905 for ; Mon, 14 Apr 2003 15:54:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195A4T-0004rB-00 for ieprep@ietf.org; Mon, 14 Apr 2003 15:56:53 -0400 Received: from clifden.donelan.com ([199.34.53.180]) by ietf-mx with esmtp (Exim 4.12) id 195A4S-0004r7-00 for ieprep@ietf.org; Mon, 14 Apr 2003 15:56:52 -0400 Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #3) id 195A4Y-0003EC-00 for ieprep@ietf.org; Mon, 14 Apr 2003 15:56:58 -0400 Date: Mon, 14 Apr 2003 15:56:57 -0400 (EDT) From: Sean Donelan To: "'ieprep'" In-Reply-To: <002e01c2fab7$8e289a60$6fc495ce@happy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Ieprep] FEMA offeres first responders instant messaging service 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: , http://www.govexec.com/dailyfed/0403/040903a1.htm Nearly 5,000 first responders are taking advantage of an instant messaging service to help bridge communications gaps among federal, state and local emergency relief workers, Federal Emergency Management Agency officials said Wednesday. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Thu Apr 17 18:18:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11835 for ; Thu, 17 Apr 2003 18:18:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMRwS14674 for ieprep-archive@odin.ietf.org; Thu, 17 Apr 2003 18:27:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMRw814671 for ; Thu, 17 Apr 2003 18:27:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11824 for ; Thu, 17 Apr 2003 18:18:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HkC-0003D2-00 for ieprep-web-archive@ietf.org; Thu, 17 Apr 2003 18:20:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196HkC-0003Cy-00 for ieprep-web-archive@ietf.org; Thu, 17 Apr 2003 18:20:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMQV814609; Thu, 17 Apr 2003 18:26:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMP9814530 for ; Thu, 17 Apr 2003 18:25:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11644; Thu, 17 Apr 2003 18:15:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HhT-0003CS-00; Thu, 17 Apr 2003 18:17:47 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 196HhS-0003CL-00; Thu, 17 Apr 2003 18:17:47 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3HMHx013593; Thu, 17 Apr 2003 15:17:59 -0700 (PDT) Message-Id: <200304172217.h3HMHx013593@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, ieprep@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 17 Apr 2003 15:17:59 -0700 Subject: [Ieprep] RFC 3523 on Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology 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: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3523 Title: Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology Author(s): J. Polk Status: Informational Date: April 2003 Mailbox: jmpolk@cisco.com Pages: 6 Characters: 10190 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-polk-ieprep-scenarios-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3523.txt This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents. This document is a product of the Internet Emergency Preparedness Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030417151623.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3523 --OtherAccess Content-Type: Message/External-body; name="rfc3523.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030417151623.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Apr 21 07:42:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10295 for ; Mon, 21 Apr 2003 07:42:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3LBrZI23224 for ieprep-archive@odin.ietf.org; Mon, 21 Apr 2003 07:53:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBrZ823221 for ; Mon, 21 Apr 2003 07:53:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10242 for ; Mon, 21 Apr 2003 07:42:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197Zih-0006wS-00 for ieprep-web-archive@ietf.org; Mon, 21 Apr 2003 07:44:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197Zih-0006wO-00 for ieprep-web-archive@ietf.org; Mon, 21 Apr 2003 07:44:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBpU823075; Mon, 21 Apr 2003 07:51:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBh4822776 for ; Mon, 21 Apr 2003 07:43:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09728; Mon, 21 Apr 2003 07:31:31 -0400 (EDT) Message-Id: <200304211131.HAA09728@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, 21 Apr 2003 07:31:30 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-03.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: , --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 : IP Telephony Requirements for Emergency Telecommunication Service Author(s) : K. Carlberg, R. Atkinson Filename : draft-ietf-ieprep-ets-telephony-03.txt Pages : 6 Date : 2003-4-18 This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in [3]. 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-ets-telephony-03.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-ets-telephony-03.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-ets-telephony-03.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: <2003-4-18131738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-ets-telephony-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-ets-telephony-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-18131738.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Apr 28 14:16:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09131 for ; Mon, 28 Apr 2003 14:16:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SIKrM32388 for ieprep-archive@odin.ietf.org; Mon, 28 Apr 2003 14:20:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SIKr832385 for ; Mon, 28 Apr 2003 14:20:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09117 for ; Mon, 28 Apr 2003 14:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ADCO-0004Tq-00 for ieprep-web-archive@ietf.org; Mon, 28 Apr 2003 14:17:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ADCO-0004Tm-00 for ieprep-web-archive@ietf.org; Mon, 28 Apr 2003 14:17:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SIDN832126; Mon, 28 Apr 2003 14:13:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SICE832096 for ; Mon, 28 Apr 2003 14:12:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08846; Mon, 28 Apr 2003 14:06:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AD36-0004QV-00; Mon, 28 Apr 2003 14:08:20 -0400 Received: from chntex01.is.dyncorp.com ([131.131.133.210]) by ietf-mx with esmtp (Exim 4.12) id 19AD35-0004Q7-00; Mon, 28 Apr 2003 14:08:19 -0400 Received: by chntex01.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <2F24GM1L>; Mon, 28 Apr 2003 14:06:23 -0400 Message-ID: From: "Gunn, Janet" To: "'Internet-Drafts@ietf.org'" Cc: ieprep@ietf.org Subject: RE: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-03.txt Date: Mon, 28 Apr 2003 14:04:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Two very minor comments. In section 3, item 5, the first sentence says "best available" but the last sentence says "better than best effort". Is this intended, or is the second one also supposed to be "best available"? In section 5, the first sentence appears to be missing a ")" at the end. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, April 21, 2003 7:32 AM Cc: ieprep@ietf.org Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-03.txt 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 : IP Telephony Requirements for Emergency Telecommunication Service Author(s) : K. Carlberg, R. Atkinson Filename : draft-ietf-ieprep-ets-telephony-03.txt Pages : 6 Date : 2003-4-18 This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in [3]. 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-ets-telephony-03.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-ets-telephony-03.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-ets-telephony-03.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. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Mon Apr 28 14:50:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09988 for ; Mon, 28 Apr 2003 14:50:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SIsra02495 for ieprep-archive@odin.ietf.org; Mon, 28 Apr 2003 14:54:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SIsr802492 for ; Mon, 28 Apr 2003 14:54:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09973 for ; Mon, 28 Apr 2003 14:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ADjH-0004ft-00 for ieprep-web-archive@ietf.org; Mon, 28 Apr 2003 14:51:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ADha-0004fR-00 for ieprep-web-archive@ietf.org; Mon, 28 Apr 2003 14:50:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SIpH802347; Mon, 28 Apr 2003 14:51:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SIoA802294 for ; Mon, 28 Apr 2003 14:50:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09874; Mon, 28 Apr 2003 14:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ADej-0004e9-00; Mon, 28 Apr 2003 14:47:13 -0400 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx with smtp (Exim 4.12) id 19ADei-0004e6-00; Mon, 28 Apr 2003 14:47:12 -0400 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 28 Apr 2003 19:47:05 +0100 To: "Gunn, Janet" cc: ieprep@ietf.org, Internet-Drafts@ietf.org Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-03.txt In-reply-to: Your message of "Mon, 28 Apr 2003 14:04:08 EDT." Date: Mon, 28 Apr 2003 19:47:02 +0100 Message-ID: <29548.1051555622@cs.ucl.ac.uk> From: Ken Carlberg 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: , > In section 3, item 5, the first sentence says "best available" but the last > sentence says "better than best effort". Is this intended, or is the second > one also supposed to be "best available"? yes, the sentence as it is written in version 3 is as intended. > In section 5, the first sentence appears to be missing a ")" at the end. it has been fixed. regards, -ken ps, I've included the I-D editor on this email to close the loop, but I don't believe the address should be included again _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 29 07:46:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13454 for ; Tue, 29 Apr 2003 07:46:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TBpiT32582 for ieprep-archive@odin.ietf.org; Tue, 29 Apr 2003 07:51:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TBpi832579 for ; Tue, 29 Apr 2003 07:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13426 for ; Tue, 29 Apr 2003 07:46:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ATay-0001ug-00 for ieprep-web-archive@ietf.org; Tue, 29 Apr 2003 07:48:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ATay-0001ud-00 for ieprep-web-archive@ietf.org; Tue, 29 Apr 2003 07:48:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TBo9832429; Tue, 29 Apr 2003 07:50:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TBjr832223 for ; Tue, 29 Apr 2003 07:45:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13135; Tue, 29 Apr 2003 07:40:21 -0400 (EDT) Message-Id: <200304291140.HAA13135@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: Tue, 29 Apr 2003 07:40:20 -0400 Subject: [Ieprep] I-D ACTION:draft-ietf-ieprep-ets-telephony-04.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: , --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 : IP Telephony Requirements for Emergency Telecommunication Service Author(s) : K. Carlberg, R. Atkinson Filename : draft-ietf-ieprep-ets-telephony-04.txt Pages : 6 Date : 2003-4-28 This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in [3]. 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-ets-telephony-04.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-ets-telephony-04.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-ets-telephony-04.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: <2003-4-28124037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ieprep-ets-telephony-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ieprep-ets-telephony-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-28124037.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 29 11:36:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27979 for ; Tue, 29 Apr 2003 11:36:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TFfi623886 for ieprep-archive@odin.ietf.org; Tue, 29 Apr 2003 11:41:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TFfi823883 for ; Tue, 29 Apr 2003 11:41:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27957 for ; Tue, 29 Apr 2003 11:36:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AXBU-0005Qy-00 for ieprep-web-archive@ietf.org; Tue, 29 Apr 2003 11:38:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AXBT-0005Qv-00 for ieprep-web-archive@ietf.org; Tue, 29 Apr 2003 11:38:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TFdU823705; Tue, 29 Apr 2003 11:39:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TFcL823599 for ; Tue, 29 Apr 2003 11:38:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27855 for ; Tue, 29 Apr 2003 11:32:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AX8C-0005P8-00 for ieprep@ietf.org; Tue, 29 Apr 2003 11:34:56 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 19AX8C-0005OX-00 for ieprep@ietf.org; Tue, 29 Apr 2003 11:34:56 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h3TFZRvV002037 for ; Tue, 29 Apr 2003 11:35:27 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h3TFZRnH002036 for ieprep@ietf.org; Tue, 29 Apr 2003 11:35:27 -0400 (EDT) Date: Tue, 29 Apr 2003 11:35:27 -0400 (EDT) From: Scott Bradner Message-Id: <200304291535.h3TFZRnH002036@newdev.harvard.edu> To: ieprep@ietf.org Subject: [Ieprep] may be of interest to this WG 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: , http://www.projectmesa.org/ftp/SSG_SA/Drafts/MESA_70.001_v3.1.1a_SoR(FINAL_draft).doc Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From mailnull@www1.ietf.org Tue Apr 29 15:52:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08397 for ; Tue, 29 Apr 2003 15:52:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TJvE317446 for ieprep-archive@odin.ietf.org; Tue, 29 Apr 2003 15:57:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJvE817443 for ; Tue, 29 Apr 2003 15:57:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08387 for ; Tue, 29 Apr 2003 15:51:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AbAe-0007SV-00 for ieprep-web-archive@ietf.org; Tue, 29 Apr 2003 15:53:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AbAe-0007SR-00 for ieprep-web-archive@ietf.org; Tue, 29 Apr 2003 15:53:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJtT817330; Tue, 29 Apr 2003 15:55:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TJsf817286 for ; Tue, 29 Apr 2003 15:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08259 for ; Tue, 29 Apr 2003 15:48:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ab8B-0007Qr-00 for ieprep@ietf.org; Tue, 29 Apr 2003 15:51:11 -0400 Received: from chntex01.is.dyncorp.com ([131.131.133.210]) by ietf-mx with esmtp (Exim 4.12) id 19Ab8A-0007Qb-00 for ieprep@ietf.org; Tue, 29 Apr 2003 15:51:11 -0400 Received: by chntex01.is.dyncorp.com with Internet Mail Service (5.5.2653.19) id <2F24GQCT>; Tue, 29 Apr 2003 15:49:08 -0400 Message-ID: From: "Gunn, Janet" To: "'King, Kimberly S.'" , "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Tue, 29 Apr 2003 15:46:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , *Sorry to be so late getting in on this. *Comments in line -----Original Message----- From: King, Kimberly S. [mailto:KIMBERLY.S.KING@saic.com] Sent: Monday, March 31, 2003 11:57 AM To: Ieprep (E-mail) Subject: [Ieprep] access and enterprise networks At the last meeting, people expressed an interest in addressing access and enterprise networks. As frustrating as it might seem, if there is to be any progress, the problem still has to be precisely defined. Let's consider defining the problem and it would be nice to factor in some practical realities too. Here are some assumptions: A) ETS locations are known in advance of any emergency. When an emergency occurs, each will already be connected to a network (unless the emergency damaged the connection in which case that situation is out of scope). * There are several variations on this. While some kind of service which is available *everywhere (based on some sort of authentication) would be "nice to have", it is obviously * impractical. So specifying in advance the "ETS location" is an acceptable compromise. * But there are a couple of additional considerations. * First, we don't necessarily want ALL traffic from the ETS location to get "special" * treatment, ALL the time. We want to be able to identify specific * connections/sessions/applications/packets for "special treatment" at a specific time. * This is one of the considerations that keeps the total volume of "special traffic" down. * If the biggest bottleneck is on the connection from "Site A" to its ISP, then giving * "special treatment" to ALL traffic from Site A would be counterproductive. * If EVERYTHING is special, then NOTHING is special. * Second, the predefined set of "source sites" might be quite different from the * (predefined or not-predefined) set of "destination sites", where source-destination makes * sense at some levels (e.g. application) but might not at others (e.g., packet). *Third, it would be nice if the definition of "predefined site" included some provisions *for mobility (dial up, wireless, etc.), within the constraints of a predefined ISP *relationship. B) Generally, we aren't trying to simultaneously solve the problem for every ETS location in the entire world at the same time. Rather, subsets of ETS locations are affiliated with each other and some policy decision (and likely funding scenario) is made for that subset. An example, say all fire stations in particular county want to procure IP connections for their use. Meanwhile, a city's hospitals might be under completely different policy and funding and aren't particularly interested in paying for enhanced communications via some fancy IP network with the fire stations. * If you can completely define the community of interest (e.g., all the fire stations) * then a VPN of some sort is the obvious solution, and within a VPN all sorts of * special treatment is possible. * While restricting it to such a small community of interest makes the solution easier, * it is not as valuable as a solution that involves SOME sort of special treatment * between the communities. For instance, in your example, I can easily see situations * where the fire department would want to get high priority information to a hospital (and the hospital would want to receive that information). So, what is it that we want to ensure? Would ieprep like a service that provided some minimum bandwidth guarantee (like gold service) over the access link and that's sufficient to make everyone reasonably happy? If that kind of service just isn't acceptable, then please provide some text and details about the problem you believe we need to address. * I think a "minimum bandwidth guarantee" is probably sufficient, * but it may no be necessary. * There may be other ways of providing preferential service that are related to the * offered load, and the proportion of the offered load that is "special", rather than * an a priori guarantee. * Janet 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 From mailnull@www1.ietf.org Wed Apr 30 08:08:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29463 for ; Wed, 30 Apr 2003 08:08:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UCDs722971 for ieprep-archive@odin.ietf.org; Wed, 30 Apr 2003 08:13:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UCDs822968 for ; Wed, 30 Apr 2003 08:13:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29443 for ; Wed, 30 Apr 2003 08:07:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AqPT-0006GT-00 for ieprep-web-archive@ietf.org; Wed, 30 Apr 2003 08:10:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AqPT-0006GQ-00 for ieprep-web-archive@ietf.org; Wed, 30 Apr 2003 08:10:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UCCM822894; Wed, 30 Apr 2003 08:12:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UCBP822847 for ; Wed, 30 Apr 2003 08:11:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29414 for ; Wed, 30 Apr 2003 08:05:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AqN5-0006G2-00 for ieprep@ietf.org; Wed, 30 Apr 2003 08:07:35 -0400 Received: from cpmx.mail.saic.com ([139.121.17.160]) by ietf-mx with esmtp (Exim 4.12) id 19AqN4-0006Fz-00 for ieprep@ietf.org; Wed, 30 Apr 2003 08:07:34 -0400 Received: from cp-its-ieg01.mail.saic.com by cpmx.mail.saic.com for ieprep@ietf.org; Wed, 30 Apr 2003 05:07:34 -0700 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by cp-its-ieg01.mail.saic.com (NAVGW 2.5.2.17) with SMTP id M2003043005071031064 ; Wed, 30 Apr 2003 05:07:10 -0700 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 08:10:31 -0400 Message-Id: From: "King, Kimberly S." To: "'Gunn, Janet'" , "'King, Kimberly S.'" , "Ieprep (E-mail)" Subject: RE: [Ieprep] access and enterprise networks Date: Wed, 30 Apr 2003 08:08:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , Janet said: >* If the biggest bottleneck is on the connection from "Site A" >to its ISP, >then giving >* "special treatment" to ALL traffic from Site A would be >counterproductive. > >* If EVERYTHING is special, then NOTHING is special. I understand your idea however I was addressing a different scenario. The idea is that the bottleneck is often an aggregation point from multiple customers into the main ISP network and that Site A (ETS) would have greater throughput at that aggregation point. See http://www1.ietf.org/mail-archive/working-groups/ieprep/current/msg01911.htm l for a picture. Kimberly _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep