From ieprep-admin@ietf.org Fri Jan 4 11:34:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07900 for ; Fri, 4 Jan 2002 11:34:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27723 for ; Fri, 4 Jan 2002 11:34:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27708 for ; Fri, 4 Jan 2002 11:34:47 -0500 (EST) Received: from cnri.reston.va.us (cnri.reston.va.us [132.151.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07887 for ; Fri, 4 Jan 2002 11:34:44 -0500 (EST) Received: from hubris.cnri.reston.va.us (cnri-7-74.cnri.reston.va.us [132.151.7.74]) by cnri.reston.va.us (8.11.6/8.11.3) with ESMTP id g04GYjF07800 for ; Fri, 4 Jan 2002 11:34:45 -0500 (EST) Message-Id: <5.0.0.25.2.20020104113229.03793008@mailbox.cnri.reston.va.us> X-Sender: gcunning@mailbox.cnri.reston.va.us X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 04 Jan 2002 11:32:43 -0500 To: ieprep@ietf.org From: Greg Cunningham Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Ieprep] test A Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org TEst A _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 8 16:46:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11399 for ; Tue, 8 Jan 2002 16:46:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24115; Tue, 8 Jan 2002 16:46:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24083 for ; Tue, 8 Jan 2002 16:46:35 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11395 for ; Tue, 8 Jan 2002 16:46:33 -0500 (EST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08LkW320016 for ; Tue, 8 Jan 2002 13:46:32 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 8 Jan 2002 13:46:29 -0800 To: ieprep@ietf.org From: Paul Hoffman / IMC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Ieprep] What is this list? Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Hi. I just got subscribed to this list without asking to be. I am assuming that it is something probably legitimate, but there is no information in the "you have been subscribed" message saying what it is. Can someone impart clue for me and the others who were force-subscribed? --Paul Hoffman, Director --Internet Mail Consortium _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 8 17:12:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11953 for ; Tue, 8 Jan 2002 17:12:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25543; Tue, 8 Jan 2002 17:12:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25508 for ; Tue, 8 Jan 2002 17:12:10 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11948 for ; Tue, 8 Jan 2002 17:12:08 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA01977; Tue, 8 Jan 2002 14:11:34 -0800 (PST) Message-Id: <4.1.20020108155905.011e3ee0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Jan 2002 16:11:16 -0600 To: Paul Hoffman / IMC , ieprep@ietf.org From: "James M. Polk" Subject: Re: [Ieprep] What is this list? In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1910640746==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org --=====================_1910640746==_.ALT Content-Type: text/plain; charset="us-ascii" "International Emergency Preparedness" is the mail list. I didn't subscribe anyone -- so don't kill the messenger. It's from the not-so-old IEPS (add "Scheme" to the above name). http://www.iepscheme.net/ is the current homepage. At 01:46 PM 1/8/2002 -0800, Paul Hoffman / IMC wrote: >Hi. I just got subscribed to this list without asking to be. I am >assuming that it is something probably legitimate, but there is no >information in the "you have been subscribed" message saying what it >is. Can someone impart clue for me and the others who were >force-subscribed? > >--Paul Hoffman, Director >--Internet Mail Consortium > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1910640746==_.ALT Content-Type: text/html; charset="us-ascii"
"International Emergency Preparedness" is the mail list. I didn't subscribe anyone -- so don't kill the messenger. It's from the not-so-old IEPS (add "Scheme" to the above name).

http://www.iepscheme.net/ is the current homepage.

At 01:46 PM 1/8/2002 -0800, Paul Hoffman / IMC wrote:
>Hi. I just got subscribed to this list without asking to be. I am
>assuming that it is something probably legitimate, but there is no
>information in the "you have been subscribed" message saying what it
>is. Can someone impart clue for me and the others who were
>force-subscribed?
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1910640746==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 8 17:42:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12693 for ; Tue, 8 Jan 2002 17:42:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26559; Tue, 8 Jan 2002 17:41:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26530 for ; Tue, 8 Jan 2002 17:41:44 -0500 (EST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12689 for ; Tue, 8 Jan 2002 17:41:41 -0500 (EST) Received: from 208.184.79.252.songbird.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with SMTP id OAA09803; Tue, 8 Jan 2002 14:41:41 -0800 X-Authentication-Warning: joy.songbird.com: 208.184.79.252.songbird.com [208.184.79.252] (may be forged) didn't use HELO protocol Message-Id: <5.1.0.14.2.20020108143926.0312e988@127.0.0.1> X-Sender: dcrocker@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 08 Jan 2002 14:39:50 -0800 To: "James M. Polk" From: Dave Crocker Subject: Re: [Ieprep] What is this list? Cc: ieprep@ietf.org In-Reply-To: <4.1.20020108155905.011e3ee0@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org what was wrong with the old list? d/ At 04:11 PM 1/8/2002 -0600, James M. Polk wrote: >"International Emergency Preparedness" is the mail list. I didn't >subscribe anyone -- so don't kill the messenger. It's from the not-so-old >IEPS (add "Scheme" to the above name). ---------- Dave Crocker Brandenburg InternetWorking tel +1.408.246.8253; fax +1.408.273.6464 _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 8 18:03:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13243 for ; Tue, 8 Jan 2002 18:03:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27309; Tue, 8 Jan 2002 18:02:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27273 for ; Tue, 8 Jan 2002 18:02:50 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13218 for ; Tue, 8 Jan 2002 18:02:47 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g08N2Bj00565; Tue, 8 Jan 2002 18:02:11 -0500 (EST) Date: Tue, 8 Jan 2002 18:02:11 -0500 (EST) From: Scott Bradner Message-Id: <200201082302.g08N2Bj00565@newdev.harvard.edu> To: dcrocker@brandenburg.com Subject: Re: [Ieprep] What is this list? Cc: ieprep@ietf.org Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org I wanted to move the list to the IETF server - which is someting I'm trying to do for new WGs (and this may become a WG) Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 8 18:03:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13254 for ; Tue, 8 Jan 2002 18:03:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27362; Tue, 8 Jan 2002 18:03:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27327 for ; Tue, 8 Jan 2002 18:03:41 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13223 for ; Tue, 8 Jan 2002 18:03:38 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g08N3dP00570 for ieprep@ietf.org; Tue, 8 Jan 2002 18:03:39 -0500 (EST) Date: Tue, 8 Jan 2002 18:03:39 -0500 (EST) From: Scott Bradner Message-Id: <200201082303.g08N3dP00570@newdev.harvard.edu> To: ieprep@ietf.org Subject: [Ieprep] draft ieprep minutes Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org please take a look at these draft ieprep minutes and send in comments (yor name is wrong, you did not say that etc) before friday at 8pm EST) tnx Scott ---- Notes of the IETF 52 Internet Emergency Preparedness BOF The BOF commenced at 09:00 hours on December 13, 2001 with approximately 100 participants. The BOF was co-chaired by Scott Bradner of Harvard University and Hal Folts of the National Communications System (NCS). The featured speaker was Fred Baker from Cisco. Scott opened the BOF by stating that this is not the first time the IETF has done a BOF on emergency services. (The first time was at IETF 48.) The September 11, 2001 incident has crystallized more interest in emergency services. Scott stated that the IETF, through this BOF, is beginning to address the issue of emergency services in the Internet. Scott briefly outlined to the BOF an example of an emergency communications system deployed by Japan. The system, IAA (I Am Alive), was used on September 11 and provides a way for people to communicate to their loved ones that they are OK after a disaster. With respect to Internet/PSTN (Public Switched Telephone Network) interface a few questions surfaced. With respect to Internet connectivity during a disaster, the question arises with respect to: "What happens when a person using the Internet during a disaster situation wants to go to a semi-collapsed PSTN?" How does the person tell the Internet to prioritize a call when going to the PSTN? Scott stated that the Internet worked "just fine" during the September 11 incident. At this point in the BOF Fred Baker gave a presentation covering three acronyms: IEPS, ETS, IEPScheme. All these acronyms represent the same thing with respect to emergency communications. ETS (Emergency Telecommunication Services) has been under development in the ITU for the past few years. People (mostly from the NCS) have been coming to the IETF to ask for help because disasters happen e.g., earthquakes, storms, all of which require Government communications for disaster relief. Fred stated that in the United States there is a PSTN system called GETS (Government Emergency Telecommunications Service) to facilitate government emergency telecommunications during disasters. (In the United Kingdom there is a similar system.) With respect to the Internet, RFC 791 contains a way to prioritize traffic, which has been obsoleted. The MLPP internet drafts (Polk) regarding SIP propose to use exactly the same mechanism - to embed a policy as well as a label into a field, where IMHO a label should be used and let the policy be external. Fred stated that an Internet application that was extensively used on September 11 was Instant Messaging (IM). We have to look at the way the telephone system behaves and how to interconnect to that behavior. Remember the telephone system is not TCP friendly! TCP adapts to congestion. Telephony on Internet e.g., Voice over IP, streaming, mimics tradition. Internet applications: Fred gave some views from a different perspective. Fred stated that Dr. Ohno (of Japan) presented a video on IAA at the previous emergency services BOF. IAA provides a cheap and simple way to get people off the telephone network, but also to convey information among people. FEMA is an example of a government agency which responds to disasters, and has among its bag of tricks an "office in a box", consisting of a satellite-based IP network, a router, and some number of PCs and VoIP telephones. They load the thing into a truck and can deploy it within a short time after delivery. People that really use the Internet in response to emergencies find a way to ensure that it will be available to them at the time they need it. Other Internet application examples include fireman on the ground where Instant Messaging has utility. Fred provided important cases to note and consider: (1) Telephone capabilities in New York City were taken out during the September 11 incident. The loss of these capabilities impacted the entire United States. The Internet, however, worked just fine during the time of these telephone losses. (2) TCP congestion management was added in 1988 because of a congestive collapse of NSFNET. We (the Internet community) learned a lot. In 1996 Fred was part of a panel covering Next Generation Networks (NGNs). The panel recognized that elastic applications behave differently than inelastic applications. It is not clear we (IETF emergency services BOF) have the same problem as inelastic applications. In 1996 Fred was on a panel with Phill Gross in which he stated that earlier in the year Internet MCI had experienced as much as 20% loss rates on some links. In the presence of those loss rates, Internet MCI was not reported as "not working", but as "slow". In addition the Atlantic links, which have had loss rates in excess of 4% for years, and showed some simulations in which TCPs were experiencing as high as 43% loss rates. Each of these was getting its job done, albeit under very adverse conditions. It is important to note that elastic applications (applications which run on TCP or transports with the same congestion avoidance characteristics) do not have the same problems as inelastic applications such as VoIP. Fred discussed Network Access (NA) during an emergency. If you are in a location prone to problems, e.g., earthquakes, you can pre-provision more capabilities, i.e., prepare in advance. To get Internet Service Providers (ISPs) attention, e.g., "Hi I am important." How should the ISPs respond? Fred spoke about GETS priority and restoration priority (lines that are restored first during or after a disaster). Any program which presumes commandeering of existing Internet service in order to support use by emergency personnel presumes that the emergency folks have a way to identify themselves to the ISP agreed on in advance, and presumes that the equipment in use can get the right configuration without the emergency person having to think about it. Prime Issues: (1) We need to talk to a telephone network, especially with respect to signaling. (2) We need to address AAA (Authentication, Authorization, and Accounting) issues. (3) We need to address contract issues. At this point Scott opened the floor to comments asking "What does the IETF need to do to deal with emergencies?" Erin Falk: From an office in a box (a portable, Internet-enabled, set of equipment that can be brought to the site of an emergency) perspective, it is not clear that the IETF has to do something. Fred said that we do not have to address this, except for telephone interconnections. Kev Lauhburn: The network was not under attack on September 11. Special emergency communications should already be operating. Access services were full on September 11. Internet backbone traffic was similar to the traffic of Sept 10. We may have to address access better. Everybody dealing with emergencies should have an Internet phone available at all times. FTS 2000 (a US government telecommunications contract) had contract provisions to address problems. How to run a country in a standalone mode: different ISPs are in different countries, some of these countries we do not like. Summary: Backbone is not a problem. The problem is access. The PSTN core has enormous Bandwidth (BW). Specialized systems are not part of the PSTN Hal Folts: The public network is used by GETS. GETS uses a card for users to get network access. Henning Schulzrinne: Technical: TCP overload, TCP reverts to a non-congestion control mechanism. Even for traditional Internet under severe overload, we still may be able to address emergency services. Contend distribution: It may be something to use to distribute Web content. Data bases, such as IAA and CNN had access problems on September 11. Dr. Ohno: IAA There is a long history on how to manage these data base systems. The systems are operated every day. These systems accept many big things. IAA is addressing access. These systems are important to emergencies. Karen Sollens: The computer systems board of the National Research Council addressed emergency care responses. Does the IETF want to focus on application level responses? It would be nice if a cell phone system can convert to a peer-to-peer system. What happens when a break is on the other side of the network? From an AAA perspective, who has priority when the emergency first happens? Will the ambulance services give up priority to police? How do you get access to deploy fire departments? Should the information on fire deployments be protected? Layers of abstraction need to be addressed. The computer board CSTV reports are online and need to be made available. Rod May: Congestion collapses on access links. People like to talk when they are upset. Right after an emergency you don’t want UDP streaming around the network. There are potentially a lot of things IETF can do e.g., SIP, MEGACO, BW usage and availability. Andy Smuller: Prior to September 11 we did not have any hope that emergency service work would go anywhere. We need to be good citizens of our community. We need to consider interworking more and not focus just on Internet issues Don Choi: MLPP Multi Level Precedence and Preemption (MLPP) is a solution for support of mission critical issues. An Internet draft was submitted to the SIP Working Group (WG). This is more than a SIP issue. Emergency services are beyond just one WG. Issue: We need flexibility and interoperability to support preferential treatment. Scott: We need better access to support preferential treatment. We need adjudication in the access portion to support users who got there first. Dave Crocker: The IETF has experience. IEPS is interesting because there is an incredible range of issues. The way to success in the IETF is to start simple and useful. What are the parameters for local, infrastructure, interworking, new technologies, and those technologies that require change? We will get bogged down if we don’t look at the parameters in a useful sense. Infrastructure Issues: Too much focus on congestion. Recommendations: What simple focus can be done? Special systems for special circumstances typically fail. John Wroclawski: Don’ t do anything special. Play to your strengths. Streaming media is an example that can be incorporated into planning. Two things: (1) Think about doing as little as possible. (2) Think about what is likely to work. Scott: We need to work with someone dealing with E911. We probably need extra equipment. Second, from an MLPP perspective, there is not any way to discriminate application “A” from application “B” during congestion. Henry Cenrick???: There has to be a code point for emergencies and how to get access during emergencies. For example, there can be a DiffServe code point for emergencies. Scott: We need to address authentication for this potential code point. Dave Allen: Three points: (1) Multiple independent loosely coupled systems, when a failure occurs other systems fill the void. (2) Build resilience and technology independence. MLPP confounds protocol design. This is a trap. Application layers on the phone are confounded. (3) Whatever we do on access links is unavoidable. Providers are reluctant to deploy admission control or deny admission. Erin Falk: We need to write an application document to figure out what we need. There are 250 governments in the world but only five levels of priority (in the ITU MLPP Recommendation). We need to figure out what tools we already have. The government has to come in (with money) to the operators and tell what it needs. The government should spread the boxes out. Hal: This emergency services effort is in close partnership with the telecom industry. Scott: It is also in conjunction with ITU work. Fred: The label or priority is put on a call. The operator applies the policy. Don Choi: The ITU Recommendation (an internationally approved Recommendation) on MLPP has five levels. The previous comment on MLPP with respect of the number levels and governments is misleading. Dr. Ohno: We need to introduce control of priority mechanisms. In Japan they are introducing metadata to do this type of control, for example. We have to consider potential control in application layers. E911 is a very localized emergency service. Nobody in Japan understands E911 or the numbers 911 because Japan uses 119. The Transport Layer does not have problems. Let us consider how to internationalize. Ross Callon: Issues: Protection of Internet, and how to make the Internet useful in emergencies. Keep the emergency service simple. We want emergency services and authentication. We worry about valid authentication protection. We need simple authentication mechanisms. One class of service is preferable. Another question for consideration: How to operate an Internet emergency service without DNS? Scott: One class has problems because of different applications. Distributed denial of service attacks present problems that need to be solved. Hal: There are two different services, 911 and 119. There is a general public service to report an emergency. The service we are talking about is an authorized service to recover from a disaster. Steve Bloomingthol: Protection of the infrastructure, is there a group addressing this? There is a concern about very highly coordinated attacks. The independence and random nature of the Internet on September 11 was a real plus, because there is a lot of Internet decentralization. Having GETS Emergency PINs (Personal Identification Numbers) for the Internet is difficult to do. Some ISP assets may not be owned or controlled by the ISPs. Rohn Negan: We should encourage people who come to IETF to go through our process. Hal: We are working with the civil side of NATO. We are also working with ETSI. This European standards organization recently established a body to address emergency telcom. Scott: Are regulations for best practices a good idea? We need folks to come here instead of trying to regulate from a distance. Rohn Negan: It is hard to go to a building and find a wire (network tap). Second, whom do you go to and then ask permission to work on the wire? Andy Smoleth: We do have the right set of protocols. We have to be careful to not exclude other protocols by other groups. MLPP needs other protocols to function in a proper manner. We need a relationship with the people dealing with these to make MLPP work. There are already a lot of basic tools, what do we have to do? Perhaps start with a filtering mechanism similar to SIP. Dave Oran: Two problems (1) Response What to do when someone is out to get you? You need credentials that are hard to forge. Planning is different. Perhaps we need two different WGs. (2) Hacker protection We need a security considerations section. Not just privacy, but how to defend against attacks. Every time we do a protocol we take into account security. Dr. Ohno: In Japan, there is a centralized location for emergency communications. We need interoperability, scalability, and protection from unauthorized users. Bar Hipps: Telephone lessons: We can’t prepare for every emergency. It is a continuous process to conduct after actions to prepare better for the next emergency. In a 1989 California earthquake the entire east wall of a switching center collapsed because one bolt broke in a floor. We subsequently replaced existing bolts with bolts of better quality. Andy Zontes: We need to take on adult responsibilities in the Internet. Peter Lothberg: What can we do to make the network better (i.e., more secure). The problem is infinite. We already have rich connectivity. Sean Donelan: If somebody in a city gives network priority to city police this action will create gridlock. There is an IETF concern about having too many documents. We cannot solve all the world’s problems in one RFC. With respect to access out of the network, the far end is a problem, if you only have network access. Karen Sollens: What ever we do has to be part of everyday life. People cannot be expected to do something different in an emergency. Is there a dichotomy between military and civilian response? Does FEMA and the military assume they have more priority over others? Ran Atkinson: Is anyone on IESG charting a WG on this topic? Scott: With respect to an IETF charter, yes there is consideration for a WG or WGs. Hal has composed a draft WG charter for an IETF WG. Don Choi: The space between military and civilians is another issue. John Wroclawski: Standards are developed to build bridges and use certain bolts. There are two groups in this room. (1) How the Internet can best meet the requirements for emergency services. (2) The other group is an extension of the bolt concept. If this process is brought to the IETF, first look at emergencies from hi level standpoint and ask an important question. Will this defer or impact other important work in the IETF? We don’t need people lecturing us on what to do, especially about what bolts to use. James Polk: This is not 911. Granularity is an issue at times of emergency. With respect to MLPP, Verizon recently put in a wavier to do preemption in their cellular networks. Hal: The government has ordered cellular priority in three cities before the end of 2001. We have come to the IETF to define and work together to find a solution, given the expertise here in IETF. We are not dictating. Dave Crocker: With respect to a former experience with business requirements over E-Mail, it went nowhere! We can first document what the existing system will do. How do we integrate? Will there be any standardization? How does the existing Internet not fulfill emergency requirements? Let us try to find a way to have specific requirements that have immediate solutions. Take existing GETS definitions (capabilities), then consider how can we adapt to these capabilities in the Internet. A starting place, for example, is what is an existing system? What would make sense for us to emulate? John Wroclawski: The IETF does have the capability to convene hi level meetings to discuss issues like this. What we need to do is consider, from the high level perspective, what the Internet can do best and still be useful. Fred: What does it take to place a call using GETS? The circuit switch network places your call ahead of other calls. With respect to the MLPP discussion we need to consider authentication requirements. We need emergency capabilities in a world where circuit switches do not exist. Don Choi: MLPP came up with technology neutral requirements. We are asking the IETF for assistance. Hal: Critical infrastructure is not part of our work here. We are not requesting this. Scott: Is there something for the IETF to do? And if so, what is it? Fred: We have SIP work and an informational RFC. Dave Crocker: There is technical work to do, but we are not sure what it is. Hal walked in the IETF with prioritization. The Internet does not have QoS (Quality of Service) distinctions. Recommendation: Write a document to tell a provider how to best focus on how to interwork with the PSTN. Scott: There is a signaling group called NSIS. It could address some issues. Problem: Denying service to other than emergency service people during an emergency. What is being heard from the BOF? It would be useful to have an impedance matching document to match requirements into what the IETF is doing now. Brian Rosen: SIP is doing 911 and discussing MLPP. Dave Crocker: We have a hammer to deliver specs, but we also have a screwdriver. Suggestion: An IRTF effort to develop a range of goals to deal with things beyond us today. Dr. Ohno: What is the approach? James Polk: Recommend a place to designate a discussion in the IETF. Richard Brennan ETSI TIPHON There is work in the ETSI TIPHON project on a requirements document (for emergency telcom) that would be useful to IETF. Scott: We will continue discussions from this BOF using E-Mail correspondence. The BOF ended at 11:30 hours. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 8 18:43:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14129 for ; Tue, 8 Jan 2002 18:43:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28437; Tue, 8 Jan 2002 18:43:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28406 for ; Tue, 8 Jan 2002 18:43:24 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14114 for ; Tue, 8 Jan 2002 18:43:21 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA10995 for ; Tue, 8 Jan 2002 15:42:53 -0800 (PST) Message-Id: <4.1.20020108174103.01584890@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Jan 2002 17:42:35 -0600 To: ieprep@ietf.org From: "James M. Polk" Subject: Re: [Ieprep] What is this list? In-Reply-To: <200201082302.g08N2Bj00565@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1916120295==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org --=====================_1916120295==_.ALT Content-Type: text/plain; charset="us-ascii" At 06:02 PM 1/8/2002 -0500, Scott Bradner wrote: >I wanted to move the list to the IETF server - which is someting I'm >trying to do for new WGs (and this may become a WG) I think it's a good idea to have this discussion based on an ietf server > >Scott > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1916120295==_.ALT Content-Type: text/html; charset="us-ascii"
At 06:02 PM 1/8/2002 -0500, Scott  Bradner wrote:
>I wanted to move the list to the IETF server - which is someting I'm
>trying to do for new WGs (and this may become a WG)

I think it's a good idea to have this discussion based on an ietf server

>
>Scott
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1916120295==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 8 20:14:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15617 for ; Tue, 8 Jan 2002 20:14:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01086; Tue, 8 Jan 2002 20:13:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01057 for ; Tue, 8 Jan 2002 20:13:43 -0500 (EST) Received: from prserv.net (asmtp2.prserv.net [32.97.166.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15612 for ; Tue, 8 Jan 2002 20:13:41 -0500 (EST) Received: from u4gbb (slip-12-64-186-172.mis.prserv.net[12.64.186.172]) by prserv.net (asmtp2) with SMTP id <2002010901134025204lkcs9e> (Authid: usinet.capthal); Wed, 9 Jan 2002 01:13:40 +0000 From: "Hal Folts" To: "IEPS List" Cc: Subject: RE: [Ieprep] What is this list? Date: Tue, 8 Jan 2002 20:20:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0035_01C19881.F52A0760" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <200201082302.g08N2Bj00565@newdev.harvard.edu> Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C19881.F52A0760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To IEPS List subscribers. We have established a new list ieprep@ietf.org to further facilitate discussions on the emergency communications issues as a result of the BOF in Salt Lake City last month. All those who subscribed to the ieps list have been transfered. However, I still plan to keep the ieps list, but his is how I would see each of the lists used: ieprep@ietf.org for the technical discussions and interactions on the IETF issues in seeking how to deal with the emergency communications issues. This is the first step toward establishing an iepre working group in the IETF. ieps@listserv.gfsc.nasa.gov will remain to provide status reports of the progress made in the work on the Emergency Telecommuncations Service work in all the organizations ITU, T1, ETSI, and IETF. Therefore the first list is the blow by blow action, while the second list is a higher level "follow the progress" list. Initially you are subscribed to both lists, except for about 10 addresses that I could not translate because of the format. If you do not wish to subscribe to either or both, you will need to follow the "unsubscribe" proceedure, or respond directly to me and I will help. Sorry if this has caused some concern or confusion, but I think that I is a major step in progressing the work in the IETF. Many thanks for your understanding. Hal > -----Original Message----- > From: ieprep-admin@ietf.org [mailto:ieprep-admin@ietf.org]On Behalf Of > Scott Bradner > Sent: Tuesday, January 08, 2002 6:02 PM > To: dcrocker@brandenburg.com > Cc: ieprep@ietf.org > Subject: Re: [Ieprep] What is this list? > > > I wanted to move the list to the IETF server - which is someting I'm > trying to do for new WGs (and this may become a WG) > > Scott > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep ------=_NextPart_000_0035_01C19881.F52A0760 Content-Type: text/x-vcard; name="Hal Folts.vcf" Content-Disposition: attachment; filename="Hal Folts.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Folts;Hal FN:Hal Folts ADR:;;400 Holloway Ct. NE;Vienna;VA;22180-3545;USA TEL;WORK:+1 703 607-6186 TEL;HOME:+1 703 281-3245 TEL:+1 703 281-0761 (24 hours) EMAIL:catching@captainhal.com END:VCARD ------=_NextPart_000_0035_01C19881.F52A0760-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 8 21:49:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17516 for ; Tue, 8 Jan 2002 21:49:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03292; Tue, 8 Jan 2002 21:45:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03254 for ; Tue, 8 Jan 2002 21:45:21 -0500 (EST) Received: from web20807.mail.yahoo.com (web20807.mail.yahoo.com [216.136.226.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17447 for ; Tue, 8 Jan 2002 21:45:18 -0500 (EST) Message-ID: <20020109024520.33082.qmail@web20807.mail.yahoo.com> Received: from [134.193.6.56] by web20807.mail.yahoo.com via HTTP; Tue, 08 Jan 2002 18:45:20 PST Date: Tue, 8 Jan 2002 18:45:20 -0800 (PST) From: senthil ayyasamy Subject: Re: [Ieprep] draft ieprep minutes To: Scott Bradner , ieprep@ietf.org In-Reply-To: <200201082303.g08N3dP00570@newdev.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Hi all, consider the problem of network support of prioritized call .The minutes BOF did not address the issue of supporting GETS-like functionality into IP telephony which places certain requirements on support of best-effort service model not excluidng the intergrated and diffserv models. Also,the issue of MPLS and Traffic engineering mechanisms for priority traffic has to be considered. Also see my views inline. > "What happens when a person using the Internet >during a > disaster situation wants > to go to a semi-collapsed PSTN?" How does the > person tell the > Internet to prioritize a call when going to the > PSTN? Is there any draft dealing with the internetworking of PSTN and internet .since,this is very important with respect to IEPS > In 1996 Fred was part of a panel covering Next > Generation Networks (NGNs). Wireless technology is also fast moving towards 3G mobile networks and hence deployment of ETS capabilities have to be addressed as stated in the draft-folts-ieps-white-paper-01.txt . > John Wroclawski: > Don’ t do anything special. Play to your > strengths. Streaming > media is an example that can be incorporated into > planning. Very important is the topic of IEMS but has no mention in the minutes . > We need to write an application document to figure > out what we need. There > are 250 governments in the world but only five > levels of priority (in the > ITU MLPP Recommendation). Since the disaster are always regional,IEPS services should address this aspect also. > It is also in conjunction with ITU work. Is their any co-ordination mechanism defined for mutual exchange between ITU and IETF > With respect to an IETF charter, yes there is > consideration for a WG or > WGs. Hal has composed a draft WG charter for an > IETF WG. Under which area IEPS will appear ??? sub-IP ..Also,what will be its objective at large ???Will it provide input to MPLS,SIP and other like minded WGs or get input from them to work on? > Don Choi: > The space between military and civilians is another > issue. I am really confused about this point as military have their own network. - Senthil ===== SENTHIL KUMAR MS(COMPUTER NETWORKING) UMKC, MO-64112,USA __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jan 9 06:37:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02565 for ; Wed, 9 Jan 2002 06:37:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28004; Wed, 9 Jan 2002 06:37:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27969 for ; Wed, 9 Jan 2002 06:37:48 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02562 for ; Wed, 9 Jan 2002 06:37:45 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 9 Jan 2002 11:37:36 +0000 X-Mailer: exmh version 2.4 05/15/2001 with version: MH 6.8.3 #25[UCI] To: senthil ayyasamy cc: ieprep@ietf.org In-reply-to: Your message of "Tue, 08 Jan 2002 10:23:26 PST." <20020108182326.15552.qmail@web20804.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 09 Jan 2002 11:37:36 +0000 Message-ID: <741.1010576256@cs.ucl.ac.uk> From: Ken Carlberg Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA27970 Subject: [Ieprep] Re: some 9/11 stats Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > >- we don't know where along the path the loss occured > >- the graphs don't show an exact breakdown of how many packets were > >lost over what period of time > >- we don't know the standard deviation of the loss. did some small > >set of nodes unfairly skewer the overall average?, etc. > > what exactly can be inferred from the traffic data if it gives the > above measures (path along the loss,pkt breakdown&SD of the loss) ? it seems to be widely accepted that congestion in the Internet tends to be more prevelant at access points between stub domains and their transit providers, and less so towards the core (ie, inter-ISP links, particularly amongst Tier-1 providers). so if the nodes initiating the pings are in stubs, there is a possibility that the ICMP ping is subject to a higher probably of experiencing a congestion point at the start of the path (stub-to-transit) than along the rest of the ISP-to-ISP path. to me, it would be nice to distinguish loss from ISP-to-ISP, versus stub-to-ISP. for the second point, the site indicates that stats are accumulated every 15 minutes. its hard to gauge from the graph how many periods reported significantly higher than normal loss/response. also, as a general observation, we don't know how many ICMP packets are sent within each period (is it 1, 3, 10, 100?). too many can make the test unfriendly and can trigger congestion for the 'type' of packet (some routers have wfq turned on with a relatively small queue size for ICMP-class packets). for the third point we don't know the distribution of loss experienced amongst the 100+ routers located in North America used for testing. was it +10% of the routers experiencing 100% loss, and then the rest just a slightly higher than normal amount of loss? or was the loss more uniformly widespread? -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jan 10 06:46:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13211 for ; Thu, 10 Jan 2002 06:46:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23119; Thu, 10 Jan 2002 06:45:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23088 for ; Thu, 10 Jan 2002 06:45:53 -0500 (EST) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13204 for ; Thu, 10 Jan 2002 06:45:51 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 16OdeY-0000WF-00; Thu, 10 Jan 2002 06:45:50 -0500 Date: Thu, 10 Jan 2002 06:45:50 -0500 (EST) From: Sean Donelan To: Ken Carlberg cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: some 9/11 stats In-Reply-To: <741.1010576256@cs.ucl.ac.uk> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org On Wed, 9 Jan 2002, Ken Carlberg wrote: > it seems to be widely accepted that congestion in the Internet tends to > be more prevelant at access points between stub domains and their transit > providers, and less so towards the core (ie, inter-ISP links, particularly > amongst Tier-1 providers). so if the nodes initiating the pings are in > stubs, there is a possibility that the ICMP ping is subject to a higher > probably of experiencing a congestion point at the start of the path > (stub-to-transit) than along the rest of the ISP-to-ISP path. to me, > it would be nice to distinguish loss from ISP-to-ISP, versus stub-to-ISP. Congestion in various providers' cores is different than the congestion on inter-ISP links. Inter-ISP links are usually an order of magnitude smaller than their core circuits. Worse, some providers have an internal policy of keeping congestion on Inter-ISP links worse than internal circuits. These tend to be very high-stress points, and probably the least capable of successfully implementing any type of priority queuing without adversly affecting a lot of other stuff. ISPs won't even implement security filters on these links because it kills their equipment. But, under normal conditions, this doesn't cause problems because most high traffic, high visibility users are directly connected to multiple providers. Their bottlenecks are distributed among multiple access links with different providers instead of the inter-ISP links. Therefore most users experience congestion on the access links instead of the inter-ISP links. How does this relate to "emergency" traffic? I don't know because I don't know the traffic patterns of emergency users. Nor do I know a good source for this data. Its important because fixing the wrong bottleneck won't help people stuck in traffic somewhere else. Which brings back my first, and continuing point. Where are emergency users having problems? After we find out where the problems are, we can start working on solutions. We may not be able to predict where the next emergency will happen, but there are substitutes. The next time NASA announces a live feed from Mars, why not put some Voip equipment on either end of the same access links and measure what happens. Or give the IT manager at CNN one of those new Cisco IP phones, and call it during the next breaking news event. Or do something else to figure out what the problems are before fixing them. > for the third point we don't know the distribution of loss experienced > amongst the 100+ routers located in North America used for testing. > was it +10% of the routers experiencing 100% loss, and then the rest > just a slightly higher than normal amount of loss? or was the loss more > uniformly widespread? Or was all the loss due to the first router connected to the test machine because everyone was trying to access the Internet Traffic Report web site to see how the Internet was performing, and congesting the same access link ITR uses to take measurements. Does the graph reflect the performance of the Internet, or the ITR access link? See also data collected by CAIDA, RIPE, Inverse, Keynote, Matrix, and so forth. They each collected data from a different viewpoint, and its not always clear what it all means. For example, low-level data from ITR shows increasing packet loss and latency beginning several hours after the attack, but Keynote web site measurements show the web response was improving several hours after the attack. If you look at any 30-day period of Internet Traffic Report data you'll see periods of high (>25%) packet loss, long (>1000ms) round-trip-times. What is normal for the Internet? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jan 10 12:41:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20026 for ; Thu, 10 Jan 2002 12:41:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07479; Thu, 10 Jan 2002 12:40:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07444 for ; Thu, 10 Jan 2002 12:40:54 -0500 (EST) Received: from web20805.mail.yahoo.com (web20805.mail.yahoo.com [216.136.226.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20018 for ; Thu, 10 Jan 2002 12:40:52 -0500 (EST) Message-ID: <20020110174052.24317.qmail@web20805.mail.yahoo.com> Received: from [134.193.6.56] by web20805.mail.yahoo.com via HTTP; Thu, 10 Jan 2002 09:40:52 PST Date: Thu, 10 Jan 2002 09:40:52 -0800 (PST) From: senthil ayyasamy Subject: Re: [Ieprep] Re: some 9/11 stats To: Sean Donelan , Ken Carlberg Cc: ieprep@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1730621916-1010684452=:23295" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org --0-1730621916-1010684452=:23295 Content-Type: text/plain; charset=us-ascii Hi all, some more queries > Which brings back my first, and continuing point. > Where are emergency > users having problems? After we find out where the > problems are, we > can start working on solutions. As mentioned by scott bradner in the minutes that Internet worked normal during Sept 11 and it was only the telephone lines that were loosy....Then how to identify those problems since we have to rely on PSTN networks > We may not be able to predict where the next > emergency will happen, but > there are substitutes. The next time NASA announces > a live feed from > Mars, why not put some Voip equipment on either end > of the same access > links and measure what happens. Or give the IT > manager at CNN one > of those new Cisco IP phones, and call it during the > next breaking > news event. Or do something else to figure out what > the problems > are before fixing them. cant active measurements be taken by injecting live packets(ping) to CNN at such times and verified ?? > > Does the graph > reflect the performance of the Internet, or the ITR > access link? The method that ITR used for measuring is also necessary .. > What is normal for the Internet? i am very interested in knowing the answer for this question.. -senthil. SENTHIL KUMAR MS(COMPUTER NETWORKING) UMKC, MO-64112,USA --------------------------------- Do You Yahoo!? Send FREE video emails in Yahoo! Mail. --0-1730621916-1010684452=:23295 Content-Type: text/html; charset=us-ascii

Hi all,

some more queries
> Which brings back my first, and continuing point.
> Where are emergency
> users having problems? After we find out where the
> problems are, we
> can start working on solutions.
        As mentioned by scott bradner in the minutes that Internet worked normal during Sept 11 and it was only the telephone lines that were loosy....Then how to identify those problems since we have to rely on PSTN networks

> We may not be able to predict where the next
> emergency will happen, but
> there are substitutes. The next time NASA announces
> a live feed from
> Mars, why not put some Voip equipment on either end
> of the same access
> links and measure what happens. Or give the IT
> manager at CNN one
> of those new Cisco IP phones, and call it during the
> next breaking
> news event. Or do something else to figure out what
> the problems
> are before fixing them.

cant active measurements be taken by injecting live packets(ping) to CNN at such times and verified  ??
>
> Does the graph
> reflect the performance of the Internet, or the ITR
> access link?

The method that ITR used for measuring is also necessary ..

> What is normal for the Internet?

i am very interested in knowing the answer for this question..

-senthil.



SENTHIL KUMAR
MS(COMPUTER NETWORKING)
UMKC,
MO-64112,USA


Do You Yahoo!?
Send FREE video emails in Yahoo! Mail. --0-1730621916-1010684452=:23295-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jan 10 13:41:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21007 for ; Thu, 10 Jan 2002 13:40:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09644; Thu, 10 Jan 2002 13:39:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09609 for ; Thu, 10 Jan 2002 13:39:54 -0500 (EST) Received: from cam-po2.genuity.com (cam-po2.genuity.com [171.78.68.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20987 for ; Thu, 10 Jan 2002 13:39:52 -0500 (EST) Received: from sblumenthal.genuity.com (wob-dhcp178-112.genuity.com [171.78.178.112]) by cam-po2.genuity.com (8.11.3/8.11.2) with ESMTP id g0AIdMm06457; Thu, 10 Jan 2002 13:39:23 -0500 (EST) Message-Id: <5.0.0.25.2.20020110125941.030f5610@po2.genuity.com> X-Sender: blumenth@po2.genuity.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 10 Jan 2002 13:36:25 -0500 To: Sean Donelan , Ken Carlberg From: Steve Blumenthal Subject: Re: [Ieprep] Re: some 9/11 stats Cc: ieprep@ietf.org In-Reply-To: References: <741.1010576256@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Sean, you wrote: >Congestion in various providers' cores is different than the congestion >on inter-ISP links. Inter-ISP links are usually an order of magnitude >smaller than their core circuits. Worse, some providers have an internal >policy of keeping congestion on Inter-ISP links worse than internal >circuits. These tend to be very high-stress points, and probably the >least capable of successfully implementing any type of priority queuing >without adversly affecting a lot of other stuff. ISPs won't even >implement security filters on these links because it kills their >equipment. While, I agree with you that inter-provider peering links are an order of magnitude lower than our backbone links, I disagree that we go out of our way to keep these links congested. We track traffic on all of our peering links on a continuous basis, proactively model traffic growth on these links in the same way as any internal link, and work with our peers to upgrade Inter-ISP links in advance of congestion. Our goal is to have adequate capacity on these links with some headroom for growth or traffic spurts. These circuits don't have to be as fast as our backbone links because with each peer, we have many of these peering inter-connects spread across the country, and we are splitting the traffic on our backbone among many peers. Genuity operates a 10Gb/s backbone (which is not too heavily loaded today) and, in aggregate today, we have over 25Gb/s of exit capacity to our peers. As the speed of these Inter-ISP links have increased, we have encountered delays in getting new links provisioned by the local telco providers and this has led to some links becoming temporarily congested. To get around this, the tier-1 ISPs have gotten together to create IPOPs in carrier neutral facilities. The plan would be for the us to bring dark fiber to the IPOP location and then interconnect to the other large ISPs via optical cross connects in the facility. The plan calls for a number of these facilities around the US with the first ones going into service now. In the long run, I do not think that the Inter-ISP peering circuits will continue to be a bottleneck. We have had some preliminary discussions among the Tier 1 ISPs about inter-provider SLAs, prioritization of traffic, and inter-provider security. We, at Genuity, are looking at the secure BGP work coming out of BBN. I am hoping that this IETF effort may accelerate some of these inter-ISP discussions along with some other activities going on to create an ISP-ISAC. Steve _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 09:00:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20602 for ; Sat, 12 Jan 2002 09:00:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17983; Sat, 12 Jan 2002 08:54:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17953 for ; Sat, 12 Jan 2002 08:54:48 -0500 (EST) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20565 for ; Sat, 12 Jan 2002 08:54:46 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 16POcS-0001sP-00; Sat, 12 Jan 2002 08:54:48 -0500 Date: Sat, 12 Jan 2002 08:54:48 -0500 (EST) From: Sean Donelan To: senthil ayyasamy cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: some 9/11 stats In-Reply-To: <20020110174052.24317.qmail@web20805.mail.yahoo.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org On Thu, 10 Jan 2002, senthil ayyasamy wrote: > cant active measurements be taken by injecting live packets(ping) > to CNN at such times and verified ?? That will tell you how well "ping" performs but not other protocols. As Fred Baker reported at the IETF BOF, some Internet protocols are extremely resiliant to packet loss. They continued to function, for some value of function, with packet loss in excess of 25%. Handling SYN packets was an issue in several failures on September 11. Some firewalls, load balancers, etc collapsed under the flood of SYN packets, which ended up blocking other users. ICMP was processed by a different stack, so you could "ping" the site, but not use it. Although this is an old problem, it is an area which could use some more work. This is a classic example of congestive collapse. In an emergency, do you impose some type of admission control on SYN packets? Is this different than prioritizing SYN packets? Is this different from good network management on any other day? _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 14:12:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23161 for ; Sat, 12 Jan 2002 14:12:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24626; Sat, 12 Jan 2002 14:12:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24593 for ; Sat, 12 Jan 2002 14:12:44 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23158 for ; Sat, 12 Jan 2002 14:12:40 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0CJCC402076 for ; Sat, 12 Jan 2002 11:12:12 -0800 (PST) Message-Id: <4.3.2.7.2.20020112105346.036693b8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 12 Jan 2002 11:05:33 -0800 To: ieprep@ietf.org From: Fred Baker Subject: Re: [Ieprep] Re: some 9/11 stats In-Reply-To: References: <20020110174052.24317.qmail@web20805.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org At 05:54 AM 1/12/2002, Sean Donelan wrote: >In an emergency, do you impose some type of admission control on SYN >packets? Is this different than prioritizing SYN packets? Is this >different from good network management on any other day? I'll argue that you might have to, and since there is not much information in the SYN (even an emergency device might well get its IP address from DHCP, or in an IPv6 world by autoconfiguration), so you can't necessarily even make assumptions about that. I tend to think that the simplest approach under extreme load is to make SYN/SYN-ACK processing be lowest priority - place SYN packets into a queue which uses only bandwidth which has no other user. Net effect you give fair service to those that already got service, and accept new work on a space available basis. And frankly, CNN is a customer of Akamai; the best way for them to unclog load to CNN is some combination of putting up effective mirror sites and offloading to their offload provider. If I worked at CNN, I would be looked *very* hard at how to do a better job of those things. But CNN is not an "emergency services" scenario, IMHO. Nobody who is worried about getting an ambulance to a crash site is checking CNN. They are going to the get-me-an-ambulance service, and presumably anyone who is going to that service needs an ambulance. Prioritization of SYN requests among those-who-get-service and those-who-don't remains to be shown to be a requirement. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 15:10:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23554 for ; Sat, 12 Jan 2002 15:10:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25811; Sat, 12 Jan 2002 15:10:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25776 for ; Sat, 12 Jan 2002 15:10:46 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23551 for ; Sat, 12 Jan 2002 15:10:44 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g0CKAX602667; Sat, 12 Jan 2002 15:10:33 -0500 (EST) Date: Sat, 12 Jan 2002 15:10:33 -0500 (EST) From: Scott Bradner Message-Id: <200201122010.g0CKAX602667@newdev.harvard.edu> To: fred@cisco.com, ieprep@ietf.org Subject: Re: [Ieprep] Re: some 9/11 stats Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org > I tend to think that the simplest approach under extreme load is to make > SYN/SYN-ACK processing be lowest priority you could also RED them - if there is an attack then the attacking SYNs will be more likely to be dropped Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 15:41:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23681 for ; Sat, 12 Jan 2002 15:41:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26512; Sat, 12 Jan 2002 15:41:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26472 for ; Sat, 12 Jan 2002 15:41:00 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23672 for ; Sat, 12 Jan 2002 15:40:57 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0CKeO418915; Sat, 12 Jan 2002 12:40:24 -0800 (PST) Message-Id: <4.3.2.7.2.20020112123528.03646428@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 12 Jan 2002 12:40:02 -0800 To: Scott Bradner From: Fred Baker Subject: Re: [Ieprep] Re: some 9/11 stats Cc: ieprep@ietf.org In-Reply-To: <200201122010.g0CKAX602667@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org At 12:10 PM 1/12/2002, Scott Bradner wrote: > > I tend to think that the simplest approach under extreme load is to make > > SYN/SYN-ACK processing be lowest priority > >you could also RED them - if there is an attack then the attacking SYNs >will be more likely to be dropped RED is an equal opportunity dropper/marker of traffic in a queue. You would use RED on the queue that the SYNs were in, and that would be a good thing. But RED in and of itself won't attack SYNs any harder than anything else unless the SYNs are somehow targeted, such as pulling them out to their own queue. The issue there is that SYNs are small packets (the only information they contain, really, is that some system wants to open a TCP connection to a listening socket), and represent a small fraction of packets - if a typical TCP session is ten packets each way or more, then SYNs represent 10% of traffic each way or less. Simply applying RED will hit data stream packets as well, and frankly you'd like to get them through in order to clear out the sessions. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 15:42:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23696 for ; Sat, 12 Jan 2002 15:42:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26569; Sat, 12 Jan 2002 15:42:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26533 for ; Sat, 12 Jan 2002 15:42:06 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23693 for ; Sat, 12 Jan 2002 15:42:03 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g0CKg4002757; Sat, 12 Jan 2002 15:42:04 -0500 (EST) Date: Sat, 12 Jan 2002 15:42:04 -0500 (EST) From: Scott Bradner Message-Id: <200201122042.g0CKg4002757@newdev.harvard.edu> To: fred@cisco.com, sob@harvard.edu Subject: Re: [Ieprep] Re: some 9/11 stats Cc: ieprep@ietf.org Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org > You would > use RED on the queue that the SYNs were in, and that would be a good thing. yup - that what I was suggesting Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 16:13:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23976 for ; Sat, 12 Jan 2002 16:13:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27150; Sat, 12 Jan 2002 16:13:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27118 for ; Sat, 12 Jan 2002 16:13:09 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23973 for ; Sat, 12 Jan 2002 16:13:06 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0CLCN424608; Sat, 12 Jan 2002 13:12:27 -0800 (PST) Message-Id: <4.3.2.7.2.20020112124019.034045f8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 12 Jan 2002 12:43:21 -0800 To: Scott Bradner From: Fred Baker Subject: Re: [Ieprep] Re: some 9/11 stats Cc: ieprep@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org ECN has some interesting attributes here. SYN and SYN-ACK packets are marked to say "in the event of congestion, drop these", while data packets are set to mark... _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 16:21:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24063 for ; Sat, 12 Jan 2002 16:21:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27243; Sat, 12 Jan 2002 16:21:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27209 for ; Sat, 12 Jan 2002 16:21:03 -0500 (EST) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24059 for ; Sat, 12 Jan 2002 16:21:00 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 16PVaI-0001wV-00; Sat, 12 Jan 2002 16:21:02 -0500 Date: Sat, 12 Jan 2002 16:21:02 -0500 (EST) From: Sean Donelan To: Fred Baker cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: some 9/11 stats In-Reply-To: <4.3.2.7.2.20020112105346.036693b8@mira-sjcm-2.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org On Sat, 12 Jan 2002, Fred Baker wrote: > I tend to think that the simplest approach under extreme load is to make > SYN/SYN-ACK processing be lowest priority - place SYN packets into a queue > which uses only bandwidth which has no other user. Net effect you give fair > service to those that already got service, and accept new work on a space > available basis. I used CAR to rate-limit the SYN packets to a level my servers could manage. Essentially treating the "flash-crowd" as a DDOS. It dropped the SYN packets over a certain rate, essentially limiting SYN's to a few percent of the total bandwidth. Picking a rate was trial-and-error. It stopped collapse, and let me successfully serve more people. But there was no cutting to the front of the line. Is fair service good enough for emergency users as long as they receive service at some point? How long of a delay is tolerable before they want to butt in? > But CNN is not an "emergency services" scenario, IMHO. Nobody who is > worried about getting an ambulance to a crash site is checking CNN. They > are going to the get-me-an-ambulance service, and presumably anyone who > is going to that service needs an ambulance. Prioritization of SYN > requests among those-who-get-service and those-who-don't remains to be > shown to be a requirement. The National Hurricane Center experienced it when a hurricane hit Florida a few years ago. At the time, it was a minor inconvience because NHC emergency users still had non-Internet communications to access the information. Essentially any public Internet TCP service is vulnerable to the same thing. If emergency users move services onto the Internet, those services may experience the same crowd effect. But there are also other solutions, besides a multi-level precedence pre-emption scheme, that already work on today's Internet. The simplest is to give public and emergency users different addresses. This is the Publisher's Clearing House approach. If you have a magazine order, you use the green envelope with one address for priority processing. If you just want to enter the sweepstakes, you use the brown envelope with a different address. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 16:30:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24178 for ; Sat, 12 Jan 2002 16:30:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27468; Sat, 12 Jan 2002 16:30:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27422 for ; Sat, 12 Jan 2002 16:30:17 -0500 (EST) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24152 for ; Sat, 12 Jan 2002 16:30:09 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 16PVj9-0001wg-00; Sat, 12 Jan 2002 16:30:11 -0500 Date: Sat, 12 Jan 2002 16:30:11 -0500 (EST) From: Sean Donelan To: Fred Baker cc: Scott Bradner , Subject: Re: [Ieprep] Re: some 9/11 stats In-Reply-To: <4.3.2.7.2.20020112124019.034045f8@mira-sjcm-2.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org On Sat, 12 Jan 2002, Fred Baker wrote: > ECN has some interesting attributes here. SYN and SYN-ACK packets are > marked to say "in the event of congestion, drop these", while data packets > are set to mark... Usually I want to do admission control away from the point of congestion. No sense in carrying SYN packets across my backbone just to drop them at the last hop. Although this may seem like a DDOS topic, network traffic during a public crisis does resemble a DDOS. The problem with admission control is it blocks the people with the badges too. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sat Jan 12 18:56:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24896 for ; Sat, 12 Jan 2002 18:56:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00233; Sat, 12 Jan 2002 18:55:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00196 for ; Sat, 12 Jan 2002 18:55:43 -0500 (EST) Received: from web20806.mail.yahoo.com (web20806.mail.yahoo.com [216.136.226.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24890 for ; Sat, 12 Jan 2002 18:55:38 -0500 (EST) Message-ID: <20020112235542.47415.qmail@web20806.mail.yahoo.com> Received: from [134.193.6.56] by web20806.mail.yahoo.com via HTTP; Sat, 12 Jan 2002 15:55:42 PST Date: Sat, 12 Jan 2002 15:55:42 -0800 (PST) From: senthil ayyasamy To: Ieprep@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ieprep] TE and IEPS Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Hi all, As for now we were discussing the multi-level precedence preemption and giving different address to emergency user. But what I feel is like have a global view of the network by some traffic visualization tools and in emergency situtaions ..traffic engineer the network either giving priority or allowing the emergency specific traffic to follow some non-congested paths .This have been worked out in some TE packages for solving the problem of congestion in IP networks . Also we in our desester management lab headed by Dr.Beard are researching on mechanisms for providing service to high priority traffic even in a best effort, shortest path routed autonomous system.We will also be working on "how priority treatment can be done in Diff-serv domains ". -senthil. ===== SENTHIL KUMAR MS(COMPUTER NETWORKING) UMKC, MO-64112,USA __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Jan 13 14:18:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14232 for ; Sun, 13 Jan 2002 14:17:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02854; Sun, 13 Jan 2002 14:17:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02822 for ; Sun, 13 Jan 2002 14:17:12 -0500 (EST) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14227 for ; Sun, 13 Jan 2002 14:17:08 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 16Pq7l-0003si-00; Sun, 13 Jan 2002 14:16:57 -0500 Date: Sun, 13 Jan 2002 14:16:57 -0500 (EST) From: Sean Donelan To: Fred Baker cc: ieprep@ietf.org Subject: Call the fire deparment (was Re: [Ieprep] Re: some 9/11 stats) In-Reply-To: <4.3.2.7.2.20020112105346.036693b8@mira-sjcm-2.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org On Sat, 12 Jan 2002, Fred Baker wrote: > But CNN is not an "emergency services" scenario, IMHO. Nobody who is > worried about getting an ambulance to a crash site is checking CNN. They > are going to the get-me-an-ambulance service, and presumably anyone who is > going to that service needs an ambulance. Prioritization of SYN requests > among those-who-get-service and those-who-don't remains to be shown to be a > requirement. The National Fire Protection Association has changed its Fire Alarm Code to include the use of the Internet for fire alarm reporting. Although this isn't a "get me an ambulance" service, its close. Because companies with an existing Internet connection can save up to $50 every month for each location, I expect this will become a popular feature. "October 31, 2001 - Radionics applauds the recent decision of the National Fire Protection Association (NFPA) to allow Data Networks, both the Internet and private Intranets, to be used for the reporting of Fire Alarm and other Life Safety-related signals to central monitoring facilities. The approval of Formal Interpretation 72-99-1 and Tentative Interim Amendment 99-3 opens the door for manufacturer's of alarm systems to use 21st century communications technology for critical fire alarm signaling applications." Currently fire alarm equipment uses RJ31X telephone lines, which allow the alarm to "seize" the telephone line and send the alarm. This effectively gives the fire alarm the highest priority use of the phone line, even interrupting a call in progress. A fire alarm will even preempt a 1-710 call on the line. By default some VoIP products, such as the Cisco IP Phone, prioritize voice packets over all other traffic. I expect this would include the new NFPA fire alarm signal packets, unless the VoIP installer remembers to change it. How will VoIP traffic, fire alarm traffic and "normal" traffic interact on the net? Its an interesting problem. Through the magic of multiplexing the fire alarm packets may get through even if VoIP calls have priority. Do we need to change any Internet Protocols for the NFPA fire alarm packets? I don't know. They are going ahead with IP as it currently exists, and if there are problems I hope they'll let us know. I think that is a good way to proceed. Solving an identified problem is much easier than solving all potential problems. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Sun Jan 13 18:14:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15804 for ; Sun, 13 Jan 2002 18:14:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07696; Sun, 13 Jan 2002 18:13:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07664 for ; Sun, 13 Jan 2002 18:13:45 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15801 for ; Sun, 13 Jan 2002 18:13:40 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 13 Jan 2002 23:13:31 +0000 X-Mailer: exmh version 2.4 05/15/2001 with version: MH 6.8.3 #25[UCI] To: Sean Donelan cc: ieprep@ietf.org Subject: Re: [Ieprep] Re: some 9/11 stats In-reply-to: Your message of "Sat, 12 Jan 2002 16:21:02 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jan 2002 23:13:29 +0000 Message-ID: <1352.1010963609@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org > Is fair service good enough for emergency users as long as they receive > service at some point? How long of a delay is tolerable before they want > to butt in? these are nice questions, but impossible to respond to as a single answer. the answer could depend on the type of application, the qualities of the app that are offered, the expectations of the user of the app, the laws/regulations that are in effect for a given region (groan), the contracts (in the form of SLAs) that have been established, etc. > But there are also other solutions, besides a multi-level precedence > pre-emption scheme, that already work on today's Internet. The simplest > is to give public and emergency users different addresses. the above is possible, but not very desireable because of its lack of portability. also quite undesireable if this were to be propagated via BGP with an ensuing increase in routing tables. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jan 14 11:59:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06748 for ; Mon, 14 Jan 2002 11:59:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13529; Mon, 14 Jan 2002 11:55:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13495 for ; Mon, 14 Jan 2002 11:55:55 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06626 for ; Mon, 14 Jan 2002 11:55:51 -0500 (EST) Received: from FRED-W2K6.cisco.com (ams-clip-vpn-dhcp56.cisco.com [10.50.0.55]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0EGsj426711; Mon, 14 Jan 2002 08:54:46 -0800 (PST) Message-Id: <4.3.2.7.2.20020114170050.03f7bcb0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 17:06:53 +0100 To: Sean Donelan From: Fred Baker Subject: Re: Call the fire deparment (was Re: [Ieprep] Re: some 9/11 stats) Cc: ieprep@ietf.org In-Reply-To: References: <4.3.2.7.2.20020112105346.036693b8@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org At 08:16 PM 1/13/2002, Sean Donelan wrote: >On Sat, 12 Jan 2002, Fred Baker wrote: > > But CNN is not an "emergency services" scenario, IMHO. Nobody who is > > worried about getting an ambulance to a crash site is checking CNN. They > > are going to the get-me-an-ambulance service, and presumably anyone who is > > going to that service needs an ambulance. Prioritization of SYN requests > > among those-who-get-service and those-who-don't remains to be shown to be a > > requirement. > >The National Fire Protection Association has changed its Fire Alarm >Code to include the use of the Internet for fire alarm reporting. >Although this isn't a "get me an ambulance" service, its close. I'm not certain whether you think we agree or we disagree. I'm all for them using the Internet to call the fire department. My point is that when they call the fire department using the Internet, the packets won't go to CNN - they will go to the fire department. And presumably, anyone who is sending packets to the fire department will be wanting someone to come do something heroic about a fire. The congestion we have been discussing is not on the backbone, but on the access link to the site being sent packets. Frankly, during an emergency, if the fire department goes through a congestive collapse scenario as CNN etc may have on 9/11, it's not because there were a zillion people out browsing CNN to find out what was going on. It was because lots of people were calling the fire department. >Do we need to change any Internet Protocols for the NFPA fire alarm >packets? I don't know. They are going ahead with IP as it currently >exists, and if there are problems I hope they'll let us know. I think >that is a good way to proceed. Solving an identified problem is much >easier than solving all potential problems. yes... I could suggest ECN (RFC 3168) deployment, for various reasons not the least of which is the issue we discussed regarding CNN, but (a) I think that's a good idea anyway, and (b) I suspect straight IP deployment will take them 80% of the way there. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jan 14 12:44:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09018 for ; Mon, 14 Jan 2002 12:44:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16267; Mon, 14 Jan 2002 12:41:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16237 for ; Mon, 14 Jan 2002 12:41:18 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08949 for ; Mon, 14 Jan 2002 12:41:16 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g0EHfEE06624; Mon, 14 Jan 2002 12:41:14 -0500 (EST) Date: Mon, 14 Jan 2002 12:41:14 -0500 (EST) From: Scott Bradner Message-Id: <200201141741.g0EHfEE06624@newdev.harvard.edu> To: fred@cisco.com, sean@donelan.com Subject: Re: Call the fire deparment (was Re: [Ieprep] Re: some 9/11 stats) Cc: ieprep@ietf.org Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org > Frankly, during an emergency, if the fire department goes through a > congestive collapse scenario as CNN etc may have on 9/11, it's not because > there were a zillion people out browsing CNN to find out what was going on. > It was because lots of people were calling the fire department. and the usefulness of zillions of people calling the fire department is limited by the number of people the fire department has to answer the phone Scott _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Mon Jan 21 10:52:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13278 for ; Mon, 21 Jan 2002 10:52:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13723; Mon, 21 Jan 2002 10:51:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13691 for ; Mon, 21 Jan 2002 10:51:42 -0500 (EST) Received: from ponyexpress.ee.columbia.edu (IDENT:root@ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13258 for ; Mon, 21 Jan 2002 10:51:39 -0500 (EST) Received: from katja (radsl-65.ocs.columbia.edu [128.59.27.15]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id g0LFpgf01129; Mon, 21 Jan 2002 10:51:42 -0500 From: "Aurel A. Lazar" To: Cc: "Aurel A. Lazar" Date: Mon, 21 Jan 2002 10:51:42 -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.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Ieprep] invitation for contributions to DIREN'02 (Disaster Recovery Networks'02) and CFP Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 7bit I would like to invite you to submit a contribution and to participate in the upcoming DIREN workshop on Disaster Recovery Networks. The workshop will serve as a forum for presentations, discussions and brainstorming on DRNs from an information technology perspective. Aurel A. Lazar http://comet.columbia.edu/~aurel P.S. I would appreciate if you could bring this workshop to the attention of researchers interested in the topic. Thank you! Aurel -------------------------------------------------------- The First IEEE Workshop on Disaster Recovery Networks June 24, 2002, New York, NY Call for Participation The First IEEE Workshop on Disaster Recovery Networks invites your participation in this international forum on innovative network technologies, architectures, and services that can be effectively deployed during disaster recovery. DIREN is sponsored (pending) by the IEEE Communications Society and will be co-located and organized in conjunction with INFOCOM. Please submit by March 15, 2002, a short statement about the topics that you would like to discuss or would like to hear being discussed to aurel@ee.columbia.edu or nick@ee.columbia.edu. The program of the workshop will be posted at http://comet.columbia.edu/diren no later than April 15, 2002. Organizing and Program Committee Victor S. Frost, University of Kansas Aurel A. Lazar, Columbia University Mary Maeda, DARPA Nicholas F. Maxemchuk, Columbia University _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 22 10:35:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26769 for ; Tue, 22 Jan 2002 10:35:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13651; Tue, 22 Jan 2002 10:34:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13621 for ; Tue, 22 Jan 2002 10:34:28 -0500 (EST) Received: from web20807.mail.yahoo.com (web20807.mail.yahoo.com [216.136.226.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26727 for ; Tue, 22 Jan 2002 10:34:24 -0500 (EST) Message-ID: <20020122153426.24308.qmail@web20807.mail.yahoo.com> Received: from [134.193.6.56] by web20807.mail.yahoo.com via HTTP; Tue, 22 Jan 2002 07:34:26 PST Date: Tue, 22 Jan 2002 07:34:26 -0800 (PST) From: senthil ayyasamy To: Ieprep@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ieprep] emergency traffic Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Hi all, I think like the subject of restoration back to normal conditions at times of disaster is as important as prioritizing the traffic. If u have absorbed the CNN at such times ..they went to text only format thinking of their bandwidth.So,i feel we should work out some methodologies and guidelines for restoration of normalcy. I also have a doubt.What essentially constitute a emergency traffic ...the traffic by the (victims or their relatives ) use or traffic by disaster management people like ambulance service etc or the traffic by the people using the internet for acessing disaster inf. Thanks in advance, Senthil. ===== SENTHIL KUMAR MS(COMPUTER NETWORKING) UMKC, MO-64112,USA __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 22 11:26:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28935 for ; Tue, 22 Jan 2002 11:26:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19512; Tue, 22 Jan 2002 11:26:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19480 for ; Tue, 22 Jan 2002 11:26:24 -0500 (EST) Received: from kc-msxalone.kc.umkc.edu (kc-msxalone.kc.umkc.edu [134.193.143.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28929 for ; Tue, 22 Jan 2002 11:26:20 -0500 (EST) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxalone.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.3779); Tue, 22 Jan 2002 10:26:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ieprep] emergency traffic Date: Tue, 22 Jan 2002 10:26:22 -0600 Message-ID: Thread-Topic: [Ieprep] emergency traffic Thread-Index: AcGjWladooMvL7iQT7Kx4b/mMt8AsgABfzNQ From: "Beard, Cory" To: "senthil ayyasamy" , X-OriginalArrivalTime: 22 Jan 2002 16:26:22.0988 (UTC) FILETIME=[87E08CC0:01C1A361] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA19481 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > I also have a doubt.What essentially constitute a > emergency traffic ...the traffic by the (victims or > their relatives ) use or traffic by disaster > management people like ambulance service etc or the > traffic by the people using the internet for acessing > disaster inf. Most of our discussion has centered on prioritization of traffic by disaster management people, not for the general public even if they are victims or relatives. A complete solution would consider everyone who might have a disaster-related communications need, but this is impractical. This is especially true since as soon as the demand for disaster-related communications exceeds capacity, then we start having to make decisions about who is most important within those that already have a disaster-related need. Besides, after a disaster just about everyone would think they had a disaster-related need of some kind. Ideally we would have a framework where everyone could negotiate with the network for the priority they need, but such an approach could only be implemented once simpler approaches have been tested and proven effective. But I have a question: When we say "disaster management people", do we really only mean national-level people? Do local fire and police departments be included? Do they have access to GETS today? Cory Beard _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 22 11:47:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29559 for ; Tue, 22 Jan 2002 11:47:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20710; Tue, 22 Jan 2002 11:46:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20674 for ; Tue, 22 Jan 2002 11:46:54 -0500 (EST) Received: from portal.east.saic.com (portal.east.saic.com [198.151.13.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29549 for ; Tue, 22 Jan 2002 11:46:50 -0500 (EST) Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 22 Jan 2002 16:46:54 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for Ieprep@ietf.org; Tue, 22 Jan 2002 11:46:36 -0500 Received: from MCL-ITS-EXIG01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.15) with SMTP id M2002012211463518284 ; Tue, 22 Jan 2002 11:46:35 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 11:47:05 -0500 Message-Id: From: "King, Kimberly S." To: "'Beard, Cory'" , senthil ayyasamy , Ieprep@ietf.org Subject: RE: [Ieprep] emergency traffic Date: Tue, 22 Jan 2002 11:45:04 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Cory, > Do local fire and police departments be included? Do they have > access to GETS today? They are eligible for GETS and many have access today. Kimberly > -----Original Message----- > From: Beard, Cory [mailto:BeardC@umkc.edu] > Sent: Tuesday, January 22, 2002 11:26 AM > To: senthil ayyasamy; Ieprep@ietf.org > Subject: RE: [Ieprep] emergency traffic > > > > I also have a doubt.What essentially constitute a > > emergency traffic ...the traffic by the (victims or > > their relatives ) use or traffic by disaster > > management people like ambulance service etc or the > > traffic by the people using the internet for acessing > > disaster inf. > > Most of our discussion has centered on prioritization of > traffic by disaster management people, not for the general > public even if they are victims or relatives. > > A complete solution would consider everyone who might have a > disaster-related communications need, but this is > impractical. This is especially true since as soon as the > demand for disaster-related communications exceeds capacity, > then we start having to make decisions about who is most > important within those that already have a disaster-related > need. Besides, after a disaster just about everyone would > think they had a disaster-related need of some kind. > > Ideally we would have a framework where everyone could > negotiate with the network for the priority they need, but > such an approach could only be implemented once simpler > approaches have been tested and proven effective. > > But I have a question: When we say "disaster management > people", do we really only mean national-level people? Do > local fire and police departments be included? Do they have > access to GETS today? > > Cory Beard > > _______________________________________________ > 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 ieprep-admin@ietf.org Tue Jan 22 12:05:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00635 for ; Tue, 22 Jan 2002 12:05:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28655; Tue, 22 Jan 2002 12:05:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28610 for ; Tue, 22 Jan 2002 12:05:40 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00598 for ; Tue, 22 Jan 2002 12:05:36 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0MH58X21829; Tue, 22 Jan 2002 09:05:08 -0800 (PST) Message-Id: <4.3.2.7.2.20020122075740.045bd350@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 08:05:10 -0800 To: senthil ayyasamy From: Fred Baker Subject: Re: [Ieprep] emergency traffic Cc: Ieprep@ietf.org In-Reply-To: <20020122153426.24308.qmail@web20807.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org At 07:34 AM 1/22/2002, senthil ayyasamy wrote: >I also have a doubt.What essentially constitute a emergency traffic ...the >traffic by the (victims or their relatives ) use or traffic by disaster >management people like ambulance service etc or the traffic by the people >using the internet for acessing disaster inf. The discussion at the IETF has rather narrowly defined it as being traffic-by-authorized-people (as demonstrated using some authentication mechanism), as compared with traffic-by-other-people. Personally, I'm not thrilled with the breakdown; folks who were on the ground on 9/11 tell me that those directing emergency traffic in the first moments were "other" people, and that their involvement was pretty important. But I don't have a better suggestion. The premise is that if you are a person who is supposed to be calling the shots, you need to be heard among the din, and you may need assistance from the network in being heard. I think the case has yet to be shown for elastic applications (applications which adapt to ambient congestion, such as the web, instant messaging, or mail, and generally includes applications which run on TCP). But that is the premise. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 22 13:17:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02982 for ; Tue, 22 Jan 2002 13:17:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02505; Tue, 22 Jan 2002 13:16:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02469 for ; Tue, 22 Jan 2002 13:16:48 -0500 (EST) Received: from kc-msxalone.kc.umkc.edu (kc-msxalone.kc.umkc.edu [134.193.143.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02942 for ; Tue, 22 Jan 2002 13:16:45 -0500 (EST) Received: from KC-MAIL1.kc.umkc.edu ([134.193.143.161] RDNS failed) by kc-msxalone.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.3779); Tue, 22 Jan 2002 12:16:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Ieprep] emergency traffic Date: Tue, 22 Jan 2002 12:16:46 -0600 Message-ID: Thread-Topic: [Ieprep] emergency traffic Thread-Index: AcGjZwdi2UIxyoMmTuWrJfUR9xuRjQABTmew From: "Beard, Cory" To: "Fred Baker" , "senthil ayyasamy" Cc: X-OriginalArrivalTime: 22 Jan 2002 18:16:47.0177 (UTC) FILETIME=[F4339390:01C1A370] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA02470 Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Content-Transfer-Encoding: 8bit > The discussion at the IETF has rather narrowly defined it as being > traffic-by-authorized-people (as demonstrated using some > authentication > mechanism), as compared with traffic-by-other-people. > Personally, I'm not > thrilled with the breakdown; folks who were on the ground on > 9/11 tell me > that those directing emergency traffic in the first moments > were "other" > people, and that their involvement was pretty important. But > I don't have a > better suggestion. The only option would be without authorization. There would have to be a mechanism where people could choose their own priority but would know not to use a priority level they knew was inappropriate. Isn't this how MLPP works? Can't someone choose their own priority level, knowing that there will be repercussions for inappropriate use? Or there could be a ticket server that could issue priority tickets and if an unauthorized person made a claim to need priority it could issue a ticket depending on the claim that is made. Then some (smaller) set of resources would have to be available for priority use even without authorization. This is basically how 911 works. Anyone can say they have an emergency and have a response. I talked to a police officer that said that people certainly do misuse 911 for frivolous activities, but he had not heard of a case where someone was prosecuted for abusing 911. Anyone know how well 911 works during disasters? If the phones are down, obviously 911 would not work, but can it be said in general that 911 fails when something major happens? The big problem is educating the public. Supposedly the public knows 911 is for emergencies, but definition of "emergency" can be quite different from person to person. If we introduce another option, like "emergency response coordinator", people would have to know the option exists, but know not to use it. In short, I believe a complete solution would have to address this difficult problem, but it should be discussed at a later time. Cory Beard _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 22 13:40:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04166 for ; Tue, 22 Jan 2002 13:40:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03682; Tue, 22 Jan 2002 13:40:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03646 for ; Tue, 22 Jan 2002 13:40:34 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04159 for ; Tue, 22 Jan 2002 13:40:30 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0MIe1X22010; Tue, 22 Jan 2002 10:40:01 -0800 (PST) Message-Id: <4.3.2.7.2.20020122102632.03162a60@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 10:32:30 -0800 To: "Beard, Cory" From: Fred Baker Subject: RE: [Ieprep] emergency traffic Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org At 10:16 AM 1/22/2002, Beard, Cory wrote: >The only option would be without authorization. There would have to be a >mechanism where people could choose their own priority but would know not >to use a priority level they knew was inappropriate. A better way is to have them tag their traffic with what it is ("this is an emergency-related call" vs "this is an emergency-management call") and let the service provider apply a policy ("oh, well, in that case..."). If it is a priority, one can expect users to set it according to their own perceptions ("but I really AM worried about my sister! She's pregnant and works on the 201st floor!"). Mixing policy and labels is pretty broken, because it limits you to exactly that set of policies. >Isn't this how MLPP works? Can't someone choose their own priority level, >knowing that there will be repercussions for inappropriate use? What repercussions? If I'm not mistaken, you have to have authorization to present the priority, and (as you argue later in the email) the most repercussions you're likely to get is a 911 operator irritated with you. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 22 20:46:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16937 for ; Tue, 22 Jan 2002 20:46:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22331; Tue, 22 Jan 2002 20:46:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22297 for ; Tue, 22 Jan 2002 20:46:39 -0500 (EST) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16934 for ; Tue, 22 Jan 2002 20:46:30 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 16TCU5-0000O0-00; Tue, 22 Jan 2002 20:45:53 -0500 Date: Tue, 22 Jan 2002 20:45:53 -0500 (EST) From: Sean Donelan To: Fred Baker cc: "Beard, Cory" , Subject: RE: [Ieprep] emergency traffic In-Reply-To: <4.3.2.7.2.20020122102632.03162a60@mira-sjcm-2.cisco.com> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org On Tue, 22 Jan 2002, Fred Baker wrote: > A better way is to have them tag their traffic with what it is ("this is an > emergency-related call" vs "this is an emergency-management call") and let > the service provider apply a policy ("oh, well, in that case..."). If it is > a priority, one can expect users to set it according to their own > perceptions ("but I really AM worried about my sister! She's pregnant and > works on the 201st floor!"). Mixing policy and labels is pretty broken, > because it limits you to exactly that set of policies. But before you can apply the policy, you need something the service provider can use to distinguish the different traffic. You can distinguish some traffic based on the source or destination, such as 9-1-1 (or 1-1-9 or 9-9-9) calls are identified by called number. You can also distinguish traffic based on explicit tagging, such as TOS or Diffserv. Or you can distinguish traffic based on transmission path, such as MLPS or a seperate dedicated network. Traffic flows to or from an emergency management agency are the simplest to identify. Dynamically identifying traffic orginating from arbitrary locations and destined for arbitrary locations as deserving special treatment is a more complex problem. Personally, I would like to implement the simple case first. Learn what breaks. After getting the "simple" case to work, move onto the more difficult task of dynamically identifying traffic from arbitrary locations needing special treatment. And if it turns out the "special treatment" wasn't so special after all, we haven't completely broken things. > >Isn't this how MLPP works? Can't someone choose their own priority level, > >knowing that there will be repercussions for inappropriate use? > > What repercussions? If I'm not mistaken, you have to have authorization to > present the priority, and (as you argue later in the email) the most > repercussions you're likely to get is a 911 operator irritated with you. I visited my local government depository library a couple of weeks ago and looked up some reports. Virtually every report on the use of crisis communication systems from world war II until the gulf war (the most recent publically released report was 10 years old) details problems with "precedence abuse." _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Tue Jan 22 22:07:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19190 for ; Tue, 22 Jan 2002 22:07:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25940; Tue, 22 Jan 2002 22:06:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25907 for ; Tue, 22 Jan 2002 22:06:11 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19186 for ; Tue, 22 Jan 2002 22:06:07 -0500 (EST) Received: from FRED-W2K6.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0N357d02445; Tue, 22 Jan 2002 19:05:07 -0800 (PST) Message-Id: <4.3.2.7.2.20020122181432.042f2d98@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 18:18:26 -0800 To: Sean Donelan From: Fred Baker Subject: RE: [Ieprep] emergency traffic Cc: "Beard, Cory" , In-Reply-To: References: <4.3.2.7.2.20020122102632.03162a60@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org At 05:45 PM 1/22/2002, Sean Donelan wrote: >On Tue, 22 Jan 2002, Fred Baker wrote: > > A better way is to have them tag their traffic with what it is ("this is an > > emergency-related call" vs "this is an emergency-management call") and let > > the service provider apply a policy ("oh, well, in that case..."). If it is > > a priority, one can expect users to set it according to their own > > perceptions ("but I really AM worried about my sister! She's pregnant and > > works on the 201st floor!"). Mixing policy and labels is pretty broken, > > because it limits you to exactly that set of policies. > >But before you can apply the policy, you need something the service >provider can use to distinguish the different traffic. fine; if they tag it with something the policy can trigger on, a label that identifies the relevant attributes, that can be used for that purpose. Note that a label is not a policy, though: "this sweater is of the kind you would give your daughter" does not equal "buy this sweater". The first is a label, like "this is traffic related to an emergency". The second is a policy, like "treat this with the highest priority, because it is related to an emergency". My comment on MLPP is that it is an example of a policy encoded in a label, and makes it difficult to provide other policies. You want the label in the message, and the policy in the service provider. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jan 23 06:41:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05717 for ; Wed, 23 Jan 2002 06:41:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22170; Wed, 23 Jan 2002 06:40:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22138 for ; Wed, 23 Jan 2002 06:40:48 -0500 (EST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05709 for ; Wed, 23 Jan 2002 06:40:46 -0500 (EST) Received: from posh.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 23 Jan 2002 11:35:28 +0000 X-Mailer: exmh version 2.4 05/15/2001 with version: MH 6.8.3 #25[UCI] To: "Beard, Cory" cc: Fred Baker , senthil ayyasamy , Ieprep Subject: Re: [Ieprep] emergency traffic In-reply-to: Your message of "Tue, 22 Jan 2002 12:16:46 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jan 2002 11:35:27 +0000 Message-ID: <858.1011785727@cs.ucl.ac.uk> From: Ken Carlberg Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org just some side comments.... >From: "Beard, Cory" > > This is basically how 911 works. Anyone can say they have an emergency > and have a response. I talked to a police officer that said that people > certainly do misuse 911 for frivolous activities, but he had not heard > of a case where someone was prosecuted for abusing 911. i believe in Baltimore, they added a surcharge associated with 911 calls that turned out to be frivolous. if an ambulance was sent to a residence for no reason, he/she was charged $100. it could always be appealed, and probably easily was, but it was one way to discourage non-emergency calls from the public. > From: Fred Baker > Date: Tue, 22 Jan 2002 08:05:10 -0800 (16:05 GMT) > > ...I think the case has yet to be shown for > elastic applications (applications which adapt to ambient congestion, such > as the web, instant messaging, or mail, and generally includes applications > which run on TCP).... i pretty much agree. perhaps a long term thought to keep in mind is *if* the 95%-to-5% (TCP-UDP) mix substantially changes, corresponding to a higher and more sustained level of loss, one might want to revisit this issue. > From: Fred Baker > Date: Tue, 22 Jan 2002 18:18:26 -0800 (Wed 02:18 GMT) > > My comment on MLPP is that it is an example of a policy encoded in a label, > and makes it difficult to provide other policies. You want the label in the > message, and the policy in the service provider. i pretty much agree with the above, but tend to view MLPP as something that contains sub-policies. so I may have a policy that applies to 911 (general emergency from the public), another for GETS/ECS (authorized emergency), and another for MLPP, which would have embedded within it a separate set of sub-policies that articulate a relation to MLPP values. But, the sub-polices have no reference to 911 or GETS/ECS. the sub-policies, as you state, constrains one to a degree, but without it, its not MLPP. -ken _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jan 23 13:48:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20280 for ; Wed, 23 Jan 2002 13:48:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11089; Wed, 23 Jan 2002 13:47:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11052 for ; Wed, 23 Jan 2002 13:47:36 -0500 (EST) Received: from web20810.mail.yahoo.com (web20810.mail.yahoo.com [216.136.226.199]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20268 for ; Wed, 23 Jan 2002 13:47:33 -0500 (EST) Message-ID: <20020123184734.79911.qmail@web20810.mail.yahoo.com> Received: from [134.193.6.56] by web20810.mail.yahoo.com via HTTP; Wed, 23 Jan 2002 10:47:34 PST Date: Wed, 23 Jan 2002 10:47:34 -0800 (PST) From: senthil ayyasamy Subject: Re: [Ieprep] emergency traffic To: Ieprep In-Reply-To: <858.1011785727@cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org Hi all, see my views inline. > i believe in Baltimore, they added a surcharge > associated with 911 calls > that turned out to be frivolous. if an ambulance > was sent to a residence > for no reason, he/she was charged $100. it could > always be appealed, and > probably easily was, but it was one way to > discourage non-emergency calls > from the public. As per NESA, Each household or business pays a small monthly fee for 9-1-1 service on each telephone line that appears on their phone bill. There is no per-call charge for calling 9-1-1. However, EMS/ambulances dispatched through 9-1-1 may charge for taking someone to the hospital; this is a separate ambulance charge, not a 9-1-1 charge. We are aware of both 9-1-1 and E-9-1-1.But,the main issue is about wireless 9-1-1 since the number of wireless users is increasing day-by-day in United States.According to NESA,when 9-1-1 calls are made from wireless phones, the call may not be routed to the closest 9-1-1 center, and the call taker doesn't receive the callback phone number or the location of the caller. This presents life threatening problems due to lost response time, if callers are unable to speak or don't know where they are, or if they don't know their wireless phone callback number and the call is dropped. Hence,this forum should work on some of the requirements for possible implemenations of wireless 9-1-1 by the carriers and local 9-1-1 systems.We should also co-ordinate with NESA on various issues relating with 9-1-1 emergency service. -senthil. ===== SENTHIL KUMAR MS(COMPUTER NETWORKING) UMKC, MO-64112,USA __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jan 23 15:14:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23487 for ; Wed, 23 Jan 2002 15:14:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15097; Wed, 23 Jan 2002 15:11:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15064 for ; Wed, 23 Jan 2002 15:11:22 -0500 (EST) Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23389 for ; Wed, 23 Jan 2002 15:11:19 -0500 (EST) Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 15:11:19 -0500 Message-ID: From: "Folts, Harold" To: "'Beard, Cory'" , Ieprep@ietf.org Subject: RE: [Ieprep] emergency traffic Date: Wed, 23 Jan 2002 15:11:18 -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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org > -----Original Message----- > From: Beard, Cory [mailto:BeardC@umkc.edu] > Sent: Tuesday, January 22, 2002 11:26 AM > > Most of our discussion has centered on prioritization of > traffic by disaster management people, not for the general > public even if they are victims or relatives. This is the primary focus of our work in developing and Emergency Telecommunications Service using an Internet infrastructure > > A complete solution would consider everyone who might have a > disaster-related communications need, but this is > impractical. This is especially true since as soon as the > demand for disaster-related communications exceeds capacity, > then we start having to make decisions about who is most > important within those that already have a disaster-related > need. Besides, after a disaster just about everyone would > think they had a disaster-related need of some kind. Agree. While important, we cannot let these issues impede the first priority of effective communications for disaster recovery operations by authorized users. > > Ideally we would have a framework where everyone could > negotiate with the network for the priority they need, but > such an approach could only be implemented once simpler > approaches have been tested and proven effective. > > But I have a question: When we say "disaster management > people", do we really only mean national-level people? Do > local fire and police departments be included? Do they have > access to GETS today? Yes, this new service, as well as the current GETS, includes authorized users at the local level as well - police, fire, medical, and public utilities - that must immediately deal with saving lives and restoring the community infrastructure. Hal _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jan 23 16:33:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26414 for ; Wed, 23 Jan 2002 16:33:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18950; Wed, 23 Jan 2002 16:32:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18915 for ; Wed, 23 Jan 2002 16:32:30 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26360 for ; Wed, 23 Jan 2002 16:32:28 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA14084; Wed, 23 Jan 2002 13:31:57 -0800 (PST) Message-Id: <4.1.20020123152709.01444008@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 23 Jan 2002 15:31:38 -0600 To: senthil ayyasamy , Ieprep From: "James M. Polk" Subject: Re: [Ieprep] emergency traffic In-Reply-To: <20020123184734.79911.qmail@web20810.mail.yahoo.com> References: <858.1011785727@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1208656766==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org --=====================_1208656766==_.ALT Content-Type: text/plain; charset="us-ascii" At 10:47 AM 1/23/2002 -0800, senthil ayyasamy wrote: >Hi all, >see my views inline. >> i believe in Baltimore, they added a surcharge >> associated with 911 calls >> that turned out to be frivolous. if an ambulance >> was sent to a residence >> for no reason, he/she was charged $100. it could >> always be appealed, and >> probably easily was, but it was one way to >> discourage non-emergency calls >> from the public. > As per NESA, Each household or business pays a >small monthly fee for 9-1-1 service on each telephone >line that appears on their phone bill. There is no >per-call charge for calling 9-1-1. However, >EMS/ambulances dispatched through 9-1-1 may charge for >taking someone to the hospital; this is a separate >ambulance charge, not a 9-1-1 charge. > We are aware of both 9-1-1 and E-9-1-1.But,the >main issue is about wireless 9-1-1 since the number of >wireless users is increasing day-by-day in United >States.According to NESA,when 9-1-1 calls are made >from wireless phones, the call may not be routed to >the closest 9-1-1 center, and the call taker doesn't >receive the callback phone number or the location of >the caller. This presents life threatening problems >due to lost response time, if callers are unable to >speak or don't know where they are, For IP devices making this e911 call, this is indirectly being addressed in the GEOPRIV WG, but was a direct objective in 'Spatial' before that group was not elevated to WG status and went away last year. or if they don't >know their wireless phone callback number and the call >is dropped. > Hence,this forum should work on some of the >requirements for possible implemenations of wireless >9-1-1 by the carriers and local 9-1-1 systems.We >should also co-ordinate with NESA on various issues >relating with 9-1-1 emergency service. >-senthil. > > >===== >SENTHIL KUMAR >MS(COMPUTER NETWORKING) >UMKC, >MO-64112,USA > >__________________________________________________ >Do You Yahoo!? >Send FREE video emails in Yahoo! Mail! >http://promo.yahoo.com/videomail/ > >_______________________________________________ >Ieprep mailing list >Ieprep@ietf.org >https://www1.ietf.org/mailman/listinfo/ieprep ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1208656766==_.ALT Content-Type: text/html; charset="us-ascii"
At 10:47 AM 1/23/2002 -0800, senthil ayyasamy wrote:
>Hi all,
>see my views inline.
>> i believe in Baltimore, they added a surcharge
>> associated with 911 calls
>> that turned out to be frivolous.  if an ambulance
>> was sent to a residence
>> for no reason, he/she was charged $100.  it could
>> always be appealed, and
>> probably easily was, but it was one way to
>> discourage non-emergency calls
>> from the public.
>    As per NESA, Each household or business pays a
>small monthly fee for 9-1-1 service on each telephone
>line that appears on their phone bill. There is no
>per-call charge for calling 9-1-1. However,
>EMS/ambulances dispatched through 9-1-1 may charge for
>taking someone to the hospital; this is a separate
>ambulance charge, not a 9-1-1 charge.
>    We are aware of both 9-1-1 and E-9-1-1.But,the
>main issue is about wireless 9-1-1 since the number of
>wireless users is increasing day-by-day in United
>States.According to NESA,when 9-1-1 calls are made
>from wireless phones, the call may not be routed to
>the closest 9-1-1 center, and the call taker doesn't
>receive the callback phone number or the location of
>the caller.  This presents life threatening problems
>due to lost response time, if callers are unable to
>speak or don't know where they are,

For IP devices making this e911 call, this is indirectly being addressed in the GEOPRIV WG, but was a direct objective in 'Spatial' before that group was not elevated to WG status and went away last year.

or if they don't
>know their wireless phone callback number and the call
>is dropped.
>   Hence,this forum should  work on some of the
>requirements for  possible implemenations of wireless
>9-1-1 by the carriers and local 9-1-1 systems.We
>should also co-ordinate with NESA on various issues
>relating with 9-1-1 emergency service.
>-senthil.
>
>
>=====
>SENTHIL KUMAR
>MS(COMPUTER NETWORKING)
>UMKC,
>MO-64112,USA
>
>__________________________________________________
>Do You Yahoo!?
>Send FREE video emails in Yahoo! Mail!
>
>_______________________________________________
>Ieprep mailing list
>Ieprep@ietf.org

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1208656766==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jan 23 16:56:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27445 for ; Wed, 23 Jan 2002 16:56:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19444; Wed, 23 Jan 2002 16:55:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19411 for ; Wed, 23 Jan 2002 16:55:29 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27436 for ; Wed, 23 Jan 2002 16:55:26 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id NAA09876 for ; Wed, 23 Jan 2002 13:54:57 -0800 (PST) Message-Id: <4.1.20020123153151.01474008@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 23 Jan 2002 15:53:51 -0600 To: From: "James M. Polk" Subject: RE: [Ieprep] emergency traffic In-Reply-To: References: <4.3.2.7.2.20020122102632.03162a60@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1210036089==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org --=====================_1210036089==_.ALT Content-Type: text/plain; charset="us-ascii" At 08:45 PM 1/22/2002 -0500, Sean Donelan wrote: >> >Isn't this how MLPP works? Can't someone choose their own priority level, >> >knowing that there will be repercussions for inappropriate use? >> MLPP enabled networks allow users to choose which Precedence level they wish that next call to be made at, up to the maximum level that phone is allowed to make. MLPP is not directly user assigned, but phone assigned. The physical ISDN port a particular phone is attached to on what is known as an End Office Switch determines the configuration of that phone. In IP, that could be dynamic to the phone upon the user logging into the phone (SmartCard) and then accessing what they individually deem appropriate. I do realize this is a huge problem in non-closed networks like direct ISP-connected facilities. But in Enterprise, Campus and other large finite networks (i.e. DSN) -- I believe this can be accomplished. Plug #1: I have an -01 version of an ID specifying this within the IP domain published last November. It still needs work, but comments are welcome to it Plug #2: Henning Schulzrinne and I have ID in the SIPPING WG for a new SIP Request/Response Header for multiple namespace.level's of Resource Priority to be contained within the INVITE's and 200 OK's for the signaling process of a VoIP Precedence or Emergency or IEPREP type call set-up request. It with some typo's is at the following loc (version -02 is to be published within days from today -- which might change which version is current in the IETF Directory): http://www.ietf.org/internet-drafts/draft-polk-sip-resource-01.txt This ID was discussed openly (no PPT) during the BOF in SLC >> What repercussions? If I'm not mistaken, you have to have authorization to >> present the priority, and (as you argue later in the email) the most >> repercussions you're likely to get is a 911 operator irritated with you. Since it's mostly government-based in implementation, there are repercussions that civilian or normal users don't need to adhere to. And yes, Precedence misuse is prevalent -- so I don't recommend it's use be assigned unchecked by users with no authorization mechanism present as to which levels that user is able to choose from. In this example of user's logging onto the network, a tracking mechanism for each user shouldn't be too hard to report and be justified in usage of by that user. ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1210036089==_.ALT Content-Type: text/html; charset="us-ascii"
At 08:45 PM 1/22/2002 -0500, Sean Donelan wrote:
>> >Isn't this how MLPP works?  Can't someone choose their own priority level,
>> >knowing that there will be repercussions for inappropriate use?
>>

MLPP enabled networks allow users to choose which Precedence level they wish that next call to be made at, up to the maximum level that phone is allowed to make. MLPP is not directly user assigned, but phone assigned. The physical ISDN port a particular phone is attached to on what is known as an End Office Switch determines the configuration of that phone.

In IP, that could be dynamic to the phone upon the user logging into the phone (SmartCard) and then accessing what they individually deem appropriate. I do realize this is a huge problem in non-closed networks like direct ISP-connected facilities. But in Enterprise, Campus and other large finite networks (i.e. DSN) -- I believe this can be accomplished.

Plug #1: I have an -01 version of an ID specifying this within the IP domain published last November. It still needs work, but comments are welcome to it

Plug #2: Henning Schulzrinne and I have ID in the SIPPING WG for a new SIP Request/Response Header for multiple namespace.level's of Resource Priority to be contained within the INVITE's and 200 OK's for the signaling process of a VoIP Precedence or Emergency or IEPREP type call set-up request. It with some typo's is at the following loc (version -02 is to be published within days from today -- which might change which version is current in the IETF Directory):
This ID was discussed openly (no PPT) during the BOF in SLC

>> What repercussions? If I'm not mistaken, you have to have authorization to
>> present the priority, and (as you argue later in the email) the most
>> repercussions you're likely to get is a 911 operator irritated with you.

Since it's mostly government-based in implementation, there are repercussions that civilian or normal users don't need to adhere to.

And yes, Precedence misuse is prevalent -- so I don't recommend it's use be assigned unchecked by users with no authorization mechanism present as to which levels that user is able to choose from.

In this example of user's logging onto the network, a tracking mechanism for each user shouldn't be too hard to report and be justified in usage of by that user.


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1210036089==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jan 23 18:32:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29307 for ; Wed, 23 Jan 2002 18:31:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23352; Wed, 23 Jan 2002 18:31:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23315 for ; Wed, 23 Jan 2002 18:31:46 -0500 (EST) Received: from clifden.donelan.com (clifden.donelan.com [199.34.53.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29302 for ; Wed, 23 Jan 2002 18:31:43 -0500 (EST) Received: from sean (helo=localhost) by clifden.donelan.com with local-esmtp (Exim 3.34 #2) id 16TWro-0000r8-00; Wed, 23 Jan 2002 18:31:44 -0500 Date: Wed, 23 Jan 2002 18:31:44 -0500 (EST) From: Sean Donelan To: "James M. Polk" cc: Ieprep@ietf.org Subject: RE: [Ieprep] emergency traffic In-Reply-To: <4.1.20020123153151.01474008@localhost> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org On Wed, 23 Jan 2002, James M. Polk wrote: > MLPP enabled networks allow users to choose which Precedence level they wish > that next call to be made at, up to the maximum level that phone is allowed to > make. MLPP is not directly user assigned, but phone assigned. The physical ISDN > port a particular phone is attached to on what is known as an End Office Switch > determines the configuration of that phone. My understanding is the NCS wants the precedence to follow the user not the device, so the user has access to the same enhanced priority no matter which working system the user is currently near. This was the sticking point with Verizon giving priority to cell phones instead of users. This requires solving multiple hard problems, and in practice may make the communication system more brittle. Even the limited user authentication used on the Internet today had problems. _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Wed Jan 23 23:20:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05213 for ; Wed, 23 Jan 2002 23:20:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00591; Wed, 23 Jan 2002 23:15:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00559 for ; Wed, 23 Jan 2002 23:15:14 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05118 for ; Wed, 23 Jan 2002 23:15:10 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id UAA02276; Wed, 23 Jan 2002 20:14:09 -0800 (PST) Message-Id: <4.1.20020123215533.01491008@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 23 Jan 2002 22:13:49 -0600 To: Sean Donelan From: "James M. Polk" Subject: RE: [Ieprep] emergency traffic Cc: Ieprep@ietf.org In-Reply-To: References: <4.1.20020123153151.01474008@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1232788375==_.ALT" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org --=====================_1232788375==_.ALT Content-Type: text/plain; charset="us-ascii" At 06:31 PM 1/23/2002 -0500, Sean Donelan wrote: > >On Wed, 23 Jan 2002, James M. Polk wrote: >> MLPP enabled networks allow users to choose which Precedence level they wish >> that next call to be made at, up to the maximum level that phone is >allowed to >> make. MLPP is not directly user assigned, but phone assigned. The physical >ISDN >> port a particular phone is attached to on what is known as an End Office >Switch >> determines the configuration of that phone. > >My understanding is the NCS wants the precedence to follow the user >not the device, they do, and I do for MLPP over IP (MoIP) and IEPREP and IP enabled e911(and the like) >so the user has access to the same enhanced priority >no matter which working system the user is currently near. The only way to do this is with an authentication mechanism making sure the requesting user of a higher than normal precedence call (or whatever) is who they say they are, then an authorization mechanism making sure they access only one of the priority levels they're allowed to.... then there's letting the infrastructure know this in some form or fashion to get the media to behave >This was >the sticking point with Verizon giving priority to cell phones instead >of users. These *special* cell phones are/were to have an authentication chip in them granting the privileges > >This requires solving multiple hard problems, I know.... I've been racking *me little brain* for 2+ years now on this topic. The mobile user is the hardest problem to solve because of the trust model necessary coupled with the response times expected.... :-\ >and in practice may >make the communication system more brittle. Maybe.... I think something such as the SIP Resource header could solve the signaling aspect. Now just getting something in the IP header that classifies this traffic and its intent, across domains no less -- otherwise Diffserv should solve it within a single IP Managed domain that's run well; and maybe MPLS if that domain is big enough to warrant it. Within a single domain the AAA would be much easier to solve, so would the whole trust boundary issue and the cipher(s) and keying. But anywhere to anywhere..... yuk! >Even the limited user >authentication used on the Internet today had problems. agreed > ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1232788375==_.ALT Content-Type: text/html; charset="us-ascii"
At 06:31 PM 1/23/2002 -0500, Sean Donelan wrote:
>
>On Wed, 23 Jan 2002, James M. Polk wrote:
>> MLPP enabled networks allow users to choose which Precedence level they wish
>> that next call to be made at, up to the maximum level that phone is
>allowed to
>> make. MLPP is not directly user assigned, but phone assigned. The physical
>ISDN
>> port a particular phone is attached to on what is known as an End Office
>Switch
>> determines the configuration of that phone.
>
>My understanding is the NCS wants the precedence to follow the user
>not the device,

they do, and I do for MLPP over IP (MoIP) and IEPREP and IP enabled e911(and the like)

>so the user has access to the same enhanced priority
>no matter which working system the user is currently near. 

The only way to do this is with an authentication mechanism making sure the requesting user of a higher than normal precedence call (or whatever) is who they say they are, then an authorization mechanism making sure they access only one of the priority levels they're allowed to.... then there's letting the infrastructure know this in some form or fashion to get the media to behave

>This was
>the sticking point with Verizon giving priority to cell phones instead
>of users.

These *special* cell phones are/were to have an authentication chip in them granting the privileges

>
>This requires solving multiple hard problems,

I know.... I've been racking *me little brain* for 2+ years now on this topic. The mobile user is the hardest problem to solve because of the trust model necessary coupled with the response times expected....

:-\

>and in practice may
>make the communication system more brittle. 

Maybe.... I think something such as the SIP Resource header could solve the signaling aspect. Now just getting something in the IP header that classifies this traffic and its intent, across domains no less -- otherwise Diffserv should solve it within a single IP Managed domain that's run well; and maybe MPLS if that domain is big enough to warrant it. Within a single domain the AAA would be much easier to solve, so would the whole trust boundary issue and the cipher(s) and keying.

But anywhere to anywhere..... yuk!

>Even the limited user
>authentication used on the Internet today had problems.

agreed
>

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1232788375==_.ALT-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep From ieprep-admin@ietf.org Thu Jan 31 16:46:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13552 for ; Thu, 31 Jan 2002 16:46:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26048; Thu, 31 Jan 2002 16:45:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26015 for ; Thu, 31 Jan 2002 16:45:07 -0500 (EST) Received: from bootstrap.agcs.com (bootstrap.agcs.com [130.131.48.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13526 for ; Thu, 31 Jan 2002 16:45:01 -0500 (EST) Received: from pxmail1.agcs.com (pxmail1.agcs.com [130.131.52.9]) by bootstrap.agcs.com (Pro-8.9.3/8.9.3) with ESMTP id OAA26832 for ; Thu, 31 Jan 2002 14:43:29 -0700 (MST) Received: from mknaomi ([130.131.166.58]) by pxmail1.agcs.com (Netscape Messaging Server 3.61) with SMTP id AAA3E92 for ; Thu, 31 Jan 2002 14:45:01 -0700 Received: FROM agcs.com BY mknaomi ; Thu Jan 31 14:44:59 2002 -0700 Message-ID: <3C59B830.13ADBF2E@agcs.com> Date: Thu, 31 Jan 2002 14:33:36 -0700 From: "Stuart (Stu) Goldman" Reply-To: goldmans@agcs.com Organization: AG Communication Systems X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Donelan CC: Fred Baker , ieprep@ietf.org Subject: Re: [Ieprep] Re: some 9/11 stats References: Content-Type: multipart/mixed; boundary="------------21A81C074996D7599CBCAC5F" Sender: ieprep-admin@ietf.org Errors-To: ieprep-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: ieprep@ietf.org This is a multi-part message in MIME format. --------------21A81C074996D7599CBCAC5F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, I believe that Publisher's Clearing house does this on purpose to make people believe they have a better chance if they do buy. ( I believe that the law is that everybody must have the same chance. Also, the chance of hitting it big is very, very small.) The point here is that perception is often more important than reality. Sean Donelan wrote: ...This is the Publisher's Clearing House approach. If you have a magazine order, you use the green envelope with one address for priority processing. If you just want to enter the sweepstakes, you use the brown envelope with a different address. > On Sat, 12 Jan 2002, Fred Baker wrote: > > I tend to think that the simplest approach under extreme load is to make > > SYN/SYN-ACK processing be lowest priority - place SYN packets into a queue > > which uses only bandwidth which has no other user. Net effect you give fair > > service to those that already got service, and accept new work on a space > > available basis. > > I used CAR to rate-limit the SYN packets to a level my servers could > manage. Essentially treating the "flash-crowd" as a DDOS. It dropped > the SYN packets over a certain rate, essentially limiting SYN's to a > few percent of the total bandwidth. Picking a rate was trial-and-error. > It stopped collapse, and let me successfully serve more people. But there > was no cutting to the front of the line. > > Is fair service good enough for emergency users as long as they receive > service at some point? How long of a delay is tolerable before they want > to butt in? > > > But CNN is not an "emergency services" scenario, IMHO. Nobody who is > > worried about getting an ambulance to a crash site is checking CNN. They > > are going to the get-me-an-ambulance service, and presumably anyone who > > is going to that service needs an ambulance. Prioritization of SYN > > requests among those-who-get-service and those-who-don't remains to be > > shown to be a requirement. > > The National Hurricane Center experienced it when a hurricane > hit Florida a few years ago. At the time, it was a minor inconvience > because NHC emergency users still had non-Internet communications to > access the information. > > Essentially any public Internet TCP service is vulnerable to the same > thing. If emergency users move services onto the Internet, those > services may experience the same crowd effect. > > But there are also other solutions, besides a multi-level precedence > pre-emption scheme, that already work on today's Internet. The simplest > is to give public and emergency users different addresses. This is the > Publisher's Clearing House approach. If you have a magazine order, you > use the green envelope with one address for priority processing. If > you just want to enter the sweepstakes, you use the brown envelope > with a different address. > > _______________________________________________ > Ieprep mailing list > Ieprep@ietf.org > https://www1.ietf.org/mailman/listinfo/ieprep --------------21A81C074996D7599CBCAC5F Content-Type: text/x-vcard; charset=us-ascii; name="goldmans.vcf" Content-Description: Card for Stuart (Stu) Goldman Content-Disposition: attachment; filename="goldmans.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Goldman;-Stuart tel;cell:623 582 7136 tel;fax:623 582 7111 tel;home:602 493 8438 tel;work:623 582 7136 x-mozilla-html:TRUE org: adr:;;P.O. Box 52179;Phoenix;AZ;85072-2179;USA version:2.1 email;internet:goldmans@agcs.com x-mozilla-cpt:;23888 fn:Stuart Goldman end:vcard --------------21A81C074996D7599CBCAC5F-- _______________________________________________ Ieprep mailing list Ieprep@ietf.org https://www1.ietf.org/mailman/listinfo/ieprep