Internet Engineering Task Force Ken Carlberg INTERNET DRAFT Ian Brown June 20, 2002 UCL Somebody Else? Requirements for Authorized Emergency Communications Using Elastic Service Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract The objective of this draft is to present a set of requirements to address requests by users of authorized emergency communications for better than best effort service for elastic service. We stress the word "request" versus guarantee, and we do NOT advocate broad sweeping changes to elastic applications. This document provides background information on emergency communications and presents suggested do's and don'ts in addressing the issue of requirements for elastic services. Finally, examples of requirements for specific applications are presented. Carlberg & Brown Expires December 20, 2002 [Page 1] Internet Draft Elastic Requirements June 20 2002 1. Introduction Recents events have prompted interest in determining the extent by which communications over the Internet, and TCP/IP in particular, can support emergency-related communications. [2] presents a list of requirements for emergency telecommunications capabilities in the Internet. [3] takes this one step further and presents a framework in which to accomplish the requirements for International Emergency Preparedness Scheme (IEPS) at several levels: from application layer signaling to potentially marking of IP datagrams. However, it is important to note that both of these efforts focus on IP telephony -- a type of non-elastic service whose data load is sent over UDP. We loosely define non-elastic service as one in which the end-to-end transport layer does not respond to packet loss of a flow in the form of the source reducing its offered load to the network. Conversely, elastic service alters its offered load in response to perceived congestion and can be exemplified by those applications that run over TCP and SCTP [12, 13]. The example of GETS, and the framework document of [3], focus on a specific form of emergency communications that is associated with some form of authorization. This distinction is important because it makes a requirement of the system to provide a justification as well as a reference point for potentially providing preferential treat- ment. What entity would provide the preferential treatment, how it can be realized, and where it should not be realized with elastic type applications is subject of this document and the requirements that it presents. 1.1. Background: High Level Communications Requirements Emergency personnel tend to have a variety of communications require- ments. The exact set of requirements are dependent on the equipment and end-user applications at hand, the nature of the emergency, the grade or quality of service that is needed or expected, and poten- tially local laws and regulations. As such, it is difficult at best to list a definitively set of requirements for all emergency person- nel. This subsection presents a background perspective on communica- tions requirements from the wireless community. From this perspec- tive, we note what end-users consider important as well as gain insight in what and how others (notably outside of the IETF) identify types of end-to-end applications that emergency personnel would like to use. We stress that this list is not exhaustive, and thus can be augmented as needed. [4] provides background on the high level requirements associated Carlberg & Brown Expires December 20, 2002 [Page 2] Internet Draft Elastic Requirements June 20 2002 with public safety communications (e.g., firemen, law enforcement, paramedics). The requirements listed in [4] stem from Project 25, a standard for digital trunk radios developed by several standards bodies and organizations. They include: 1) Voice Communications 2) Data Communications 3) Imagery and Video 4) Web Browser Access Voice communications can be represented by push-to-talk mode, which is a form of one-to-many communication to any potential responder or a specific known group of responders. "Priority calling" is cited as a major interest -- see [2, 3] for issues related to this area within the context of IP telephony. Call Monitoring and Caller ID is also considered important for supporting personnel not directly involved in an emergency. (note: questions regarding personel privacy on this matter are out of scope of this draft) Data communications is interestingly cited as a separate class of communications from the perspective of the wireless network commun- ity. Examples given in [4] include: email, automatic vehicle loca- tion, database access, asset location (e.g., fire hydrants). This distinction is probably due to the wireless systems that retain sup- port for legacy circuit switched links for voice and data that have been bundled with digital packet switched links. For IP based net- works, voice and data are the same, with the caveat of the former usually being associated with a minimal grade of service. Imagery (still photos), video, and web browser access are viewed as distinctly important types of data for emergency personnel. An obser- vation can be made that while non-streaming video is a type of non- elastic application, imagery and web access represents two types of elastic applications; the web, which typically involves parallel short transaction flows, and imagery, which generally involves a sin- gle large and long end-to-end transaction. It can be argued that in the end, the atomic characteristics of the above list simply involve data over IP networks. At a more granular perspective, we are able to separate applications in terms of elastic and non-elastic service. This distinction is how we decide the objective and scope of this document. 1.2. Objective of This Document A very high level view of the requirements of emergency workers is that they have a desire to communicate during times of emergencies Carlberg & Brown Expires December 20, 2002 [Page 3] Internet Draft Elastic Requirements June 20 2002 and when the network is experiencing problems -- presumably, from congestion due to increased load generated by the general public. The objective of this document is to provide some guidance (in the form of requirements) for systems designers and potential users or customers that have an interest in satisfying this high level requirement by emergency workers. In cases where preferential treat- ment is requested, we target those emergency personnel that are authorized to make the request. Further, we make a distinction from the authorized *request* in contrast to any guarantee in accomplish- ing preferential treatment. Authors note: any objections in just targeting authorized personnel?? A specific NON-objective of this document is to debate who is viewed as emergency personnel, or why these personnel may be considered pre- ferential to the general public. This document will also not take a position of what type of personnel, nor what type of elastic applica- tion, is more important than another. These issues are primarily policy in nature and are out of scope of this document. Finally, we conclude this subsection by stating very firmly that this document does NOT advocate broad sweeping changes to elastic applica- tions. It is our belief that elastic applications in general are quite resilient in the presence of significant end-to-end packet loss of a flow. We do feel that improvements can be identified for cer- tain elastic applications when certain conditions exist. This is discussed in more detail in section 4. 1.3. Scope The requirements document of [2] ranges from the application layer to the network layer. The majority of this document focuses its atten- tion on the end-to-end exchange of information, as opposed to hop- by-hop forwarding of datagrams. As such, we primarily discuss requirements related to the application layer. The reasoning behind this is that congestion control algorithms of TCP and SCTP allow the network to share network resources in a 'fair' manner during times of congestion. We include a section on network requirements to provide some comments and perspectives on the subject as it relates to elas- tic traffic. 2. Technical Objective of Requirements One of the important objectives discussed in [3] in relation to the architecture of the Internet is that of increasing the *probability* that an end-to-end flow will be established through a stressed or Carlberg & Brown Expires December 20, 2002 [Page 4] Internet Draft Elastic Requirements June 20 2002 congested network. We view this as being desireable because it does not place hard requirements or guarantees on a system trying to sup- port emergency communications. Hence, we adopt this 'probabilistic' approach in this document in defining requirements for elastic appli- cations. Another objective is to focus our efforts on markings or labels that distinguish emergency-related flows from other flows of the same type of application. Policies at an *end-point* make the distinction of what is considered important and receive preferential treatment. In addition, these policies define the form and degree of the prefer- ence. Author's Note - are there other more specific objectives that should be listed in this section? 3. Network Requirements In previous discusions on the IEPREP and IEPS mailing lists [5, 6], a significant amount of debate centered on whether elastic traffic should be treated preferentially (e.g., have additional labels in the form of diff-serv code points). The rough consensus on these lists has been that at the network layer it does not need preferential treatment because of its adaptive resilience to loss. A number of respondents on each list asserted that congestion at access points to content providers, as opposed to congestion between backbone ISPs or within core networks, was the key problem areas during the September 11, 2001 event. It was also contended that the back-off algorithms of TCP worked well in sharing resources at congestion points for those applications that did not have stringent delay or loss require- ments. This is an acute characteristic given that 90-95% of traffic transiting IP networks is TCP-based. We can take this one step further and point out that elastic applica- tions tend to be associated with lower expectations regarding loss and end-to-end delay. For example, one can argue that the reception of Instant Messages in order of seconds, or email in the order tens of seconds, is perfectly reasonable for the user to experience. This is in contrast to more stringent loss and delay bounds associated with voice and video over IP. Hence, we take the position that new network layer labels (e.g., diff-serv code points) defined specifically for emergency related flows is probably a dubious requirement, at best. The competition, and potential starvation of resources, for emergency-related TCP- based flows versus other flows used for exchanging routing informa- tion, or network management, is a dangerous position to take. We Carlberg & Brown Expires December 20, 2002 [Page 5] Internet Draft Elastic Requirements June 20 2002 would suggest that simulation or observed data be used to justify a requirement for preferential treatment of a specific elastic applica- tion at the network layer. It should be noted that while there are doubts about attempting to define new network layer labels, existing Assured Forwarding (AF) code points can provide a higher probability of end-to-end connec- tivity and quality of service for certain types of flows. Hence, if for example Instant Messaging (IM) flows are deemed more important than FTP, then the former could be assigned a code point of AFn1 and the latter AFn2, The AFn1 flows would experience less probability of drop versus AFn2 during times of congestion. Another approach would be the use of queuing mechanisms to segment traffic as well as support and/or trigger congestion avoidance algo- rithms. Weighted Fair Queuing, Random Early Discard, and weighted round robin are some of the more well known mechanisms found in routers. A more detailed discussion on the topic and and emergency services can be found in [14]. The one aspect to keep in mind is that the above mechanisms are not aimed at supporting micro-flows of emergency related traffic. They are expected to be deployed for aggregates of flows and typically based on a tuple classification derived from the actual data packet. This allows the mechanisms to scale to large numbers of flows tran- siting a router, but also is a tradeoff in not segmenting emergency related flows with other flows of the same type of application. Author's Note: IM is actually a very tricky example to address because it tends to have several types of flows within its applica- tion; ranging from small packets of user-text to large packets of images/files. IM also tends to include voice/video services, non- elastic traffic, which further complicates its treatment from the network perspective. 4. End-to-End Requirements This section discusses end-to-end requirements for *some* elastic applications that support emergency-related communications. We start with a list of general requirements that should act as a set of guidelines. This initial set would then be augmented by more specific requirements that pertain to a specific application. It is important for the reader to understand that the following list is NOT exhaustive. It represents initial candidates that have been identified as of the writing of this document. Carlberg & Brown Expires December 20, 2002 [Page 6] Internet Draft Elastic Requirements June 20 2002 4.1. General If labels are to be used to distinguish emergency-related then they should be placed at the application layer. These labels or options should not be added to transport layer protocols like TCP or SCTP. One could argue that an architecturally "cleaner" solution would be the establishment of a sublayer that could be applied to all upper layer applications. However, the inclusion of a new sublayer given the existing installed protocol stack makes this approach a long term solution at best. Thus, we do not consider or rely on its realiza- tion in this document. Labels should be used on an end-to-end basis. They can be used to deal with thresholds related to local resources of an end point. These thresholds could be in the form of maximum buffer space per flow, or the number of simultaneous connections that are serviced. It is also recognized that end-to-end is a relative viewpoint. By default, we view it as the point where a TCP connection is ter- minated, which can be at a server. SMTP is a good example where mul- tiple end-to-end segments can exist in the delivery of information to an end-user. We take the position of labels being bound to end- points, versus the end-user, because of the difficulty of maintaining transitive trust between a series of end-points. If labels for distinguishing emergency-related traffic exist, then some form of application layer authenticated credential for validat- ing the label needs to exist. Providing preferential access to resources (e.g., SMTP servers) creates an obvious opportunity for theft of service. Authorization to receive priority service MUST be verified before it is provided to a communications session. Protocol-specific authorisation mechanisms are described in subsec- tions below. More general information on security is given in [10]. Author's Note: do we make mention of anycast? and if so, do we do this per-application? If we do make mention of it, we should also state something in the Issues section with respect to scaling for global anycast. 4.2. Per Application 4.2.1. E-mail/SMTP Simple Mail Transfer Protocol (SMTP) is used to carry e-mail messages from mail clients to Message Transport Agents (MTAs) and between MTAs [7]. The recipient's mail server adds messages to the users mailbox, Carlberg & Brown Expires December 20, 2002 [Page 7] Internet Draft Elastic Requirements June 20 2002 from where they may be retrieved using simple file access or a mechanism such as the Post Office Protocol [8] or the Internet Mes- sage Access Protocol [9]. Messages are formatted as a set of text headers and one or more bodyparts, according to RFC 2822 and related standards. A 'Priority' message header has been defined for use in X.400 gateways, but is not in general usage [RFC2156]. Many mailers also use a non-standardised allows senders to mark important messages, and the recipient to take action such as displaying such messages immediately or receiving a pager notification. A 'Precedence' header has also been implemented by the widely-used sendmail MTA, but its meaning is not standardised. There are two main ways that MTAs could increase the forwarding rate of an authorised emergency-related message. Such messages could be placed in separate queues that are serviced more frequently than nor- mal priority messages. MTAs could also retry message delivery more frequently after failures. To allow MTAs to provide this service, the following requirements must be met: * A mechanism must exist that allows either specific messages or recipients to be marked as prioritized. This priority may be updated by MTAs as they forward a message. This would address the example in which recipients identified in the "To" field receive better service than those identified in the "CC" or "Bcc fields". Author's note: should the above be split into two requirements, with the "recipients" item being optional? * A set of labels must exist to allow MTAs to determine a given message's priority according to local policy, at a reasonable level of granularity. The extensible namespace mechanism described by Polk [11] may provide model for a suitable scheme within SMTP. * MTAs must be able to verify that the sender of a message is author- ized to use a given priority label. This may be done on an agent- to-agent basis (where the sender is the entity forwarding the mes- sage), or based upon the original message author. In the latter case, the message label must be signed by the message author or an MTA in their home domain, in a way that can be verified by other MTAs forwarding the message. This may require that intermediate MTAs can add their own signed priority labels. Carlberg & Brown Expires December 20, 2002 [Page 8] Internet Draft Elastic Requirements June 20 2002 4.2.2. Web/HTTP Author's Note: add a paragraph or two articulating a mechanism that conveys labels and authentication. The approach needs to be in line with the existing design structure of HTTP. Author's Note: the issue of distributed service (eg, Akamai) has been discussed in the issues section. The current feeling is that this is not a mechanism that needs to be required. It probably better reflects a value added deployment issue for a particular content pro- vider, but that is out of scope of this document. 4.2.3. FTP TBD 4.2.4. Instant Messaging Author's note: Possibly, TBD. This section is difficult because of lack of IETF protocols concerning IM 4.2.5. Others?? 5. Issues In this section we articulate some issues that arise from the above requirements. We also try to point out related information that should be taken into consideration in trying to stipulate require- ments for emergency communications using elastic applications. It is quite difficult to identify the percentage of packet loss that TCP can experience and yet still effectively exchange end-to-end data without loss of the connection. The difficulty is influenced by the combination of the slow start and congestion avoidance algorithms of TCP that exist and operate under different conditions. Added to this are the different types of applications that run over TCP. In the case of FTP, the application runs in conjunction with the elastic service it is provided. For other applications, buffer overflow of data (e.g., BGP route exchanges) may exist if data cannot be transferred in a timely manner, thus causing the application to close the connection. Hence, while elastic service can adapt to changes in network conditions, there can be a limit with respect to packet loss at which TCP connectivity may still continue but some applications cannot operate. Carlberg & Brown Expires December 20, 2002 [Page 9] Internet Draft Elastic Requirements June 20 2002 The subject of additional and authenticated labels to request bypass- ing the thresholds at a destination endpoint has been presented as one type of general requirement for elastic applications. Another direction to consider with the label is treating it as a trigger for some type of non-standard mode of operation. For example, soon after the event of 9/11, some well known public websites removed advertise- ments from their page to stream line webpages and minimize the number of TCP connections requested per client-user. An authenticated label from an authorized user could be used to trigger this (or related) action automatically. Another example would be using labels to automatically trigger the use of a distributed architecture for dis- siminating information. Author's Note: Does one discuss Anycast & policies here? 6. Security This document brings up the issue of security and the need for it in the form of authenticated usage of services. It also refers the reader to [10] to get a more indepth discussion on the subject with respect to security for supporting emergency related communications. 7. Acknowledgements The authors would like to thank Julian Onions for his review on requirements for SMTP. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Folts, H., Beard, C, "Requirements for Emergency Telecommunication Capabilities in the Internet", Internet Draft, Work In Progress, June, 2002. 3 Carlberg, K., Brown, I., "Framework for Supporting IEPS in IP Telephony", Internet draft, Work in Progress, May 14, 2002. 4 Desourdis, R., et. al, "Emerging Public Safety Wireless Communication Systems", Artech House, November 2001. 5 ftp://ftp.ietf.org/ietf-mail-archive/ieprep/ 6 http://www.iepscheme.net/ Carlberg & Brown Expires December 20, 2002 [Page 10] Internet Draft Elastic Requirements June 20 2002 7 Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982. 8 Myers, J., et. al., "Post Office Protocol - Version 3", Standard, RFC 1939, May 1996 9 Myers, J., "Internet Message Access Protocol: Version 3", Proposed Standard, RFC 1731, December 1994. 10 Brown, I., "A Security Framework for Prioritised Emergency Communication", Internet draft, March 2002. 11 Polk, J. and H. Schulzrinne, "SIP Communications Resource Priority Header", Internet Draft, Work in Progress, March 2002 12 Stewart, R., et. al., "Stream Control Transmission Protocol", Informational, RFC 3286, May 2002. 13 Postel, J. "Transmission Control Protocol", Standard, RFC 793, Sept, 1981. 14 Talauliker, S., "Best Current Practices for Internet Emergency Preparedness Services in a Differentiated Services Domain", Work in Progress, Internet-Draft, June, 2002. 9. Author's Addresses Ken Carlberg Ian Brown University College London University College London Department of Computer Science Department of Computer Science Gower Street Gower Street London, WC1E 6BT London, WC1E 6BT United Kingdom United Kingdom Carlberg & Brown Expires December 20, 2002 [Page 11] Internet Draft Elastic Requirements June 20 2002 Table of Contents 1. Introduction .................................................. 2 1.1 Background: High Level Communications Requirements ........... 2 1.2 Objective of This Document ................................... 3 1.3. Scope ....................................................... 4 2. Technical Objective of Requirements ........................... 4 3. Network Requirements .......................................... 5 4. End-to-End Requirements ....................................... 6 4.1 General ...................................................... 7 4.2 Per Application .............................................. 7 4.2.1 E-mail/SMTP ................................................ 7 4.2.2 Web/HTTP ................................................... 9 4.2.3 FTP ........................................................ 9 4.2.4 Instant Messaging .......................................... 9 4.2.5 Others?? .................................................. 9 5. Issues ........................................................ 9 6. Security ...................................................... 10 7. Acknowledgements .............................................. 10 8. References .................................................... 10 9. Author's Addresses ............................................ 11 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided as an Carlberg & Brown Expires December 20, 2002 [Page 12] Internet Draft Elastic Requirements June 20 2002 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE. Carlberg & Brown Expires December 20, 2002 [Page 13]