Internet DRAFT - draft-carlberg-ieprep-elastic-requirements
draft-carlberg-ieprep-elastic-requirements
Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT Ian Brown
June 20, 2002 UCL
Somebody Else?
Requirements for Authorized Emergency Communications
Using Elastic Service
<draft-carlberg-ieprep-elastic-requirements-00.txt>
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]
