[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 rfc2729                                        
INTERNET DRAFT                                       P Bagnall
Large-scale Multicast Applications Working Group     R Briscoe
Expiration: 21 May 1998                              A Poppitt
                                                     20 Nov 1998

                 Taxonomy of Communication Requirements
                 for Large-scale Multicast Applications


Status of this Memo
This document is an Internet-Draft. 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.''
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).

NB: an html version of this draft may be found at

The intention of this draft is to define a classification system
for the communication requirements of any large-scale multicast
application (LSMA). It is very unlikely one protocol can achieve
a compromise between the diverse requirements of all the parties
involved in any LSMA. It is therefore necessary to understand the
worst-case scenarios in order to minimise the range of protocols
needed. Dynamic protocol adaptation is likely to be necessary
which will require logic to map particular combinations of
requirements to particular mechanisms. Standardising the way that
applications define their requirements is a necessary step
towards this. Classification is a first step towards

This taxonomy consists of a large number of parameters that are
considered useful for description of communication requirements
of LSMAs. To describe a particular application, each parameter
would be assigned a value. Typical ranges of values are given
wherever possible. Failing this, the type of any possible values
is given. The parameters are collected into ten or so higher
level categories, but this is purely for convenience.
The parameters are pitched at a level considered meaningful to
application programmers. However, they describe communications
not applications - the terms "3D virtual world", or "shared TV"
might imply communications requirements, but they don't
accurately describe them. Assumptions about the likely mechanism
to achieve each requirement are avoided where possible. The
exception to this is that receiver initiated join to multicast
address groups [refmcast] on an open access Internet is assumed.
While the parameters describe communications, it will be noticed
that few requirements concerning routing etc. are apparent. This
is because applications have few direct requirements on these
second order aspects of communications. Requirements in these
areas will have to be inferred from application requirements
(e.g. latency).

The taxonomy is likely to be useful in a number of ways:
1.   most simply, it can be used as a checklist to create a
     requirements statement for a particular LSMA. Example
     applications will be classified [bagnall98] using the taxonomy in
     order to exercise (and improve) it
2.   because strictest requirement have been defined for many
     parameters, it will be possible to identify worst case scenarios
      for the design of protocols
3.   because the scope of each parameter has been defined (per
     session, per receiver etc.), it will be possible to highlight
     where heterogeneity is going to be most marked
4.   a step towards standardisation of the way LSMAs define their
     communications requirements. This could lead to standard APIs
     between applications and protocol adaptation middleware
5.   identification of limitations in current Internet technology
     for LSMAs to be added to the LSMA limitations draft [limitations]
6.   identification of gaps in Internet Engineering Task Force
     (IETF) working group coverage
This approach is intended to complement that used where
application scenarios for Distributed Interactive Simulation
(DIS) are proposed [scenarios] in order to generate network
design metrics (values of communications parameters). Instead of
creating the communications parameters from the applications, we
try to imagine applications that might be enabled by stretching
communications parameters.
The above introduction assumes all the items under the "Further
Work" section (near the end) have been completed. As they
haven't, the reader is advised to read that section next!

2. Definitions

2.1. Definition of Sessions
The following terms have no agreed definition, so they will be
defined for this document.
  a happening or gathering consisting of flows of information
  related by a common description that persists for a non-
  trivial time (more than a few seconds) such that the
  participants (be they humans or applications) are involved and
  interested at intermediate times may be defined recursively as
  a super-set of other sessions
Secure session
  a session with restricted access
A session or secure session may be a sub and/or super set of a
multicast group. A session can simultaneously be both a sub and a
super-set of a multicast group by spanning a number of groups
while time-sharing each group with other sessions.

2.2. Definitions of Roles
Defining all possible roles is not possible. The roles in a
communication are application dependant.

3. Taxonomy

3.1 Summary of Communications Parameters
Before the communications parameters are defined, typed and given
worst-case values, they are simply listed for convenience. Also
for convenience they are collected under classification headings.

3.1.1 Reliability
     Packet loss
       Tolerated loss
       Semantic loss
     Component reliability
       Setup fail-over time
       Mean time between failures
       Fail over time during a stream

3.1.2 Ordering
     Ordering type

3.1.3 Timeliness
     Hard Realtime
     optimum bandwidth
     tolerable bandwidth
     required by time and tolerance
     host performance
     fair delay
     frame size
     content size

3.1.4 Session Control
     start time
     end time
     active time
     session burstiness
     atomic join
     late join allowed ?
     temporary leave allowed ?
     late join with catch-up allowed ?
     potential streams per session
     active streams per sessions

3.1.5 Session Topology
     # of senders
     # of receivers

3.1.6 Directory
     fail-over timeout (see Reliability: fail-over time)

3.1.7 Security
     authentication strengh
     non-repudiation strength
     denial of service
     action restriction
     retransmit prevention strength
     membership criteria
     membership principals
     collusion prevention
     action on compromise

3.1.8 Security dynamics
     mean time between compromises
     compromise detection time limit
     compromise recovery time limit

3.1.9 Payment & Charging
     Total Cost
     Cost per time
     Cost per Mb

3.2 Definitions, types and strictest requirements
The terms used in the above table are now defined for the context
of this document. Under each definition, the type of their value
is given and where possible worst-case values and example
applications that would exhibit this requirement.
There is no mention of whether a communication is a stream or a
discrete interaction. An attempt to use this distinction as a way
of characterising communications proved to be remarkably
unhelpful and was dropped.

3.2.1 Types
Each requirement has a type. The following is a list of all the
types used in the following definintions.
  =B7    Application Benchmark (unknown)
  =B7    Bandwidth (Kb/s)
  =B7    Boolean
  =B7    Abstract Currency (1970 US$)
  =B7    Currency - current local
  =B7    Date (ms since 0/1/1970)
  =B7    Enumeration (int)
  =B7    Fraction (none)
  =B7    Idenfitiers
  =B7    Int (none)
  =B7    Identifiers (none)
  =B7    membership list/rule
  =B7    Duration (ms)

3.2.1 Reliability
----------------- Packet Loss

When multiple operations must occur atomically, transactional
communications guarantee that either all occur or none occur and
a failure is flagged.
Type:                  Boolean
Meaning:               Transactional or Not transaction
Strictest Requirement: Transactional
Example Application:   Bank credit transfer, debit and=20
                        credit must be atomic.
NB:                    Transactions are potentially much more complex,
                       but it is believed this is an application=20
                       layer problem.

Guarantees communications will succeed under certain conditions.
Type:                  Enumerated
Meaning:               Deferrable =96 if communication fails it will be
                        deferred until a time when it will be
                       Guaranteed =96 the communication will succeed so=20
                        long as all necessary components are working.       =
                       No guarantee - failure will not be reported.
Strictest Requirement: Deferrable
Example Application:   Stock quote feed =96 Guaranteed
NB:                    The application will need to set parameters to
                        more fully define Guarantees, which the
                        middleware may translate into, for example,
                        queue lengths.

Tolerated loss
This specifies the proportion of data from a communication that
can be lost before the application becomes completely unusable.
Type:                  Fraction
Strictest Requirement: 0%
Example Application:   Video =96 20%

Semantic loss
The application specifies how many and which parts of the
communication can be discarded if necessary.
Type:                  Identifiers, name disposable application level
Meaning:               List of the identifiers of application frames
                        which may be lost
Strictest Requirement: No loss allowed
Example Application:   Video feed - P frames may be lost, I frames not
 =20 Component Reliability

Setup Fail-over time

The time before a failure is detected and a replacement component
is invoked. From the applications point of view this is the time
it may take in exceptional circumstances for a channel to be set-
up. It is not the "normal" operating delay before a channel is
Type:                   Time
Strictest Requirement:  Application Dependent
Example Application:    Name lookup - 5 seconds

Mean time between failures

The mean time between two consecutive total failures of the
Type:                   Time
Strictest Requirement:  Indefinite
Example Application:    Telephony - 1000 hours

Fail over time during a stream

The time between a stream breaking and a replacement being set
Type:                   Time
Strictest Requirement:  Equal to latency requirement
Example Application:    File Transfer - 10sec

3.2.2. Ordering

Ordering type

Specifies what ordering must be preserved for the application
Type:                   Enumeration    =20
Meaning:                Timing        Global
                                      Per Sender
                        Sequencing    Global
                                      Per Sender
                        Causality     Global
                                      Per Sender
Strictest Requirement   Global timing, sequencing and Causality
Example Application:    Game - global causal (to make sure being
                         hit by bullet occurs after the shot is

3.2.3. Timeliness

Hard-real time
There is a =93meta-requirement=94 on timeliness. If hard real-time is
required then the interpretation of all the other requirements
changes. Failures to achieve the required timeliness must be
reported before the communication is made. By contrast soft real-
time means that there is no guarantee that an event will occur in
time. However statistical measures can be used to indicate the
probability of completion in the required time, and policies such
as making sure the probability is 95% or better could be used.
Type:                   Boolean
Meaning:                Hard or Soft realtime
Strictest Requirement:  Hard
Example Application:    Medical monitor - Hard

To make sure that separate elements of a session are correctly
synchronised with respect to each other
Type:                   Time
Strictest Requirement:  80ms for humans
Example Application:    TV lip-sync value 80ms

This is a measure of the variance of bandwidth requirements over
Type:                  Fraction
Meaning:               either:
                       Variation in b/w as fraction of b/w for
                        variable b/w communications
                       duty cycle (fraction of time at peak b/w)
                        for intermittent b/w communications.
Strictest Requirement: Variation - max b/w
                       Duty cycle ~ 0
Example Application:   Sharing video clips, with chat channel
                         sudden bursts as clips are swapped.
                       Compressed Audio - difference between
                         silence and talking
NB:                    More detailed analysis of communication
                         flow (eg max rate of b/w change or
                         Fourier Transform of the b/w requirement)
                         is possible but as complexity increases
                         usefulness and computability decrease.
ED:                    This may need to becomes two, namely B/W
                         variance and Duty Cycle

Jitter is a measure of variance in the time taken for
communications to traverse from the sender (application) to the
receiver, as seen from the application layer.
Type:                  Time
Strictest Requirement: <1ms
Example Application:   audio streaming - <1ms
NB:                    A jitter requirement implies that the
                        communication is a real-time stream. It
                        makes relatively little sense for a file
                        transfer for example.

This specifies how long the information being transferred remains
valid for.
Type:                  Date
Strictest Requirement: For ever
Example Application:   key distribution - 3600 seconds (valid
                         for at least one hour)

Time between initiation and occurrence of an action from
application perspective.
Type:                   Time
Strictest Requirement:  Near zero for process control apps
Example Application:    Audio conference 20ms
NB:                     Where an action consists of several
                         distinct sequential parts the latency
                         =93budget=94 must be split over those parts.
                         For process control the requirement may
                         take any value.

Optimum Bandwidth
Bandwidth required to complete communication in time
Type:                   Bandwidth
Strictest Requirement:  Indefinate
Example Application:    Internet Phone 8kb/s

Tolerable Bandwidth
Minimum bandwidth that application can tolerate
Type:                   Bandwidth
Strictest Requirement:  Indefinate
Example Application:    Internet phone 4kb/s

Required by time and tolerance
Time communication should complete by and time when failure to
complete renders communication useless (therefore abort).
Type:                   Date - preferred complete time
                        Date - essential complete time
Strictest Requirement:  Application Dependent
Example Application:    Email - Preferred 5 minutes & Essential
                         in 1 day
NB:                     Bandwidth * Duration - Size; only two of
                         these parameters may be specified. An API
                         though could allow application authors to
                         think in terms of any two.

Host performance
Ability of host to create/consume communication
Type:                   Application benchmark
Strictest Requirement:  Full consumption
Example Application:    Video - consume 15 frames a second
NB:                     Host performance is complex since load,
                         media type, media quality, h/w
                         assistance, and encoding scheme all
                         affect the processing load. These are
                         difficult to predict prior to a
                         communication starting. To some extent
                         these will need to be measured and
                         modified as the communication proceeds.

Fair delay
Time between receipt of communication and response by the client
should determine winner of race conditions, not the first
response at the server. The alternative is that the transport
should make sure that delivery is withheld until all reciepients
have the data. The specified requirement determines what delay is
acceptable between the first receiver getting the data and the
last receiver getting the data (assuming no system failures, but
including packet loss). Requirement: the variance in delay
between users that is acceptable
Type:                   Time
Strictest Requirement:  10ms
Example Application:    auction room - <10ms

Frame size
Size of logical data packets from application perspective
Type:                   data size
Strictest Requirement:  6bytes (gaming)
Example Application:    video - data size of single frame update

Content size
The total size of the content (not relevant for continuous media)
Type:                   data size
Strictest Requirement:  N/A
Example Application:    xxx

3.2.4. Session Control

Which initiation mechanism will be used.
Type:                   Enumeration
Meaning:                Announcement
Strictest Requirement:  Directive
Example Application:    Corporate s/w update - Directive

Start Time
Time sender starts sending!
Type:                   Date
Strictest Requirement:  Now
Example Application:    FTP - at 3am

End Time

Type:                   Date
Strictest Requirement:  Now
Example Application:    FTP - Now+30mins

(end time) - (start time) - (duration), therefore only two of
three should be specified.
Type:                   Time
Strictest Requirement:  - 0ms for discrete, indefinite for
Example Application:    audio feed - 60mins

Active Time
Total time session is active, not including breaks
Type:                   Time
Example Application:    Spectator sport transmission

Session Burstiness
expected level of burstiness of the session
Type:                   fixed point. variance as fraction of max
Strictest Requirement:  -bandwidth
Example Application:    commentary & slide show: 90% of max

atomic join
session fails unless a certain proportion of the potential
participants accept an invitation to join. Alternatively, may be
specified as a specific numeric quorum.
Type:                   fixed point (proportion required) or int
Strictest Requirement:  1.0 (proportion)
Example Application:    price list update, committee meeting
Note:                   whether certain participants are
                         essential is application dependent.

late join allowed ?
does joining a session after it starts make sense
Type:                   Boolean & indirection
Strictest Requirement:  allowed
Example Application:    game - not allowed, indirect to spectator

temporary leave allowed ?
does leaving and then coming back make sense for session
Type:                   Boolean
Strictest Requirement:  allowed
Example Application:    FTP - not allowed

late join with catch-up allowed ?
is there a mechanism for a late joiner to see what they've missed
Type:                   Boolean & indirection
Strictest Requirement:  allowed
Example Application:    sports event broadcast, allowed, indirect
                         to highlights channel

potential streams per session
total number of streams that are part of session, whether being
consumed or not
Type:                   Int
Strictest Requirement:  indefinite
example app:            football match mcast - multiple camera's,
                         commentary, 15 streams

active streams per sessions (ie max app can handle)
maximum number of streams that an application can consume
Type:                   int
Strictest Requirements: indefinite
example app:            football match mcast - 6, one main video,
                         four user selected, one audio commentary
3.2.5. Session Topology

Note: topology may be dynamic. One of the challenges in designing
adaptive protocol frameworks is to predict the topology before
the first join.
# of senders
the number of senders is a result the middleware may pass up to
the application
Type:                   int
Strictest Requirement:  indefinite
example app:            network MUD - 100

# of receivers
the number of receivers is a results the middleware may pass up
to the application
Type:                   int
Strictest Requirement:  indefinite
example app:            video mcast - 100,000

3.2.6. Directory

fail-over timeout (see Reliability: fail-over time)

defines restrictions on when directory entries may be changed
Type:                   Enumeration
Meaning:                while entry is in use
                        while entry in unused
Strictest Requirement:  while entry is in use
example app:            voice over mobile phone, while entry is
                         in use (as phone gets new address when
                         changing cell).
3.2.7. Security
The strength of any security arrangement can be stated as the
expected cost of mounting a successful attack. This allows
mechanisms such as physical isolation to be considered alongside
encryption mechanisms. An example type would be 1970 UD$ (to
inflation proof). Security is an othogonal requirement. Many
requirements can have a security requirement on them which
mandates that the cost of causing the system to fail to meet that
requirement is more than the specified ammount. In terms of
impact on other requirements though, security does potentially
have a large impact so when a system is trying to determine which
mechanisms to use and whether the requirements can be met
security will clearly be a major influence.
Authentication Strength
Authentication aims to ensure that a principal is who they claim
to be. For each role in a communication (see 2.1) there is a
strength for the authentication of the principle who has taken on
that role. The principal could be a person, organisation or other
legal entity. It could not be a process since a process has no
legal representation. Requirement: That the cost of hijacking a
role is in excess of the specified amount. Each role is a
different requirement.
Type:                   Abstract Currency
Strictest Requirement:  budget of largest attacker
Example Application:    inter-governmental conference

This allows the application to specify how much security will be
applied to ensuring that a communication is not tampered with.
This is specified as the minimum cost of successfully tampering
with the communication. Each non-security requirement has a
tamper-proofing requirement attached to it. Requirement: The cost
of tampering with the communication is in excess of the specified
Type:                   Abstract Currency: data is unchanged and complete?
                        Abstract Currency: no replay of transmission is=
                        Abstract Currency: data timeliness is assured (no=
 malicious packet delay)?
Strictest Requirement:  Each budget of largest attacker
Example Application:    stock price feed

Non-repudiation strength
The non-repdiation strength defines how much care is taken to
make sure there is a reliable audit trail on all interactions. It
is measured as the cost of faking an audit trail, and therefore
being able to "prove" an untrue event. There are a number of
possible parameters of the event that need to be proved. The
following list is not exclusive but shows the typical set of
  1.   Time
2.   Ordering (when relative to other events)
3.   Whom
4.   What (the event itself)
There are a number of events that need to be provable.
  1.   sender proved sent
2.   receiver proves received
3.   sender proves received.
Type:                   Abstract Currency
Strictest Requirement:  Budget of largest attacker
Example Application:    Full audit trail: billing based on usage logs.
                        Random partial records: to deter users
                         from fraud with the threat of the
                         possibility of being able to detect it.

Denial of service
There may be a requirement for some systems (999,911,112
emergency sevices access for example) that denial of service
attacks cannot be launched. While this is difficult (maybe
impossible) in many systems at the moment it is still a
requirement, just one that can't be met.
Type:                   Abstract Currency
Meaning:                Cost of launching a denial of service
                         attack is greater than specified amount.
Strictest Requirement:  budget of largest attacker
Example Application:    web hosting, to prevent individual
                         hackers stalling system.

Action restriction
For any given comunication there are a two actions, send and
receive. Operations like adding to members to a group are done as
a send to the membership list. Examining the list is a request to
and receive from the list. Other actions can be generalised to
send and receive on some communication, or are application level
not comms level issues.
Type:                   Membership list/rule for each action.
Strictest Requirement:  Send and receive have different policies.
Example Application:    TV broadcast, sender policy defines
                         transmitter, receiver policy is null.
NB:                     Several actions may share the same
                         membership policy.

Privacy defines how well obscured a principals identity is. This
could be for any interaction. A list of participants may be
obscured, a sender may obscure their identity when they send. For
each possible action there is a need to define the privacy
required. There are also different types of privacy. For example
knowing two messages were sent by the same person breaks the
strongest type of privacy even if the identity of that sender is
still unknown. For each "level" of privacy there is a cost
associated with violating it. The requirement is that this cost
is excessive for the attacker.
Type:                   Abstract Currency
Meaning:                Level of privacy, expected cost to
                        violate privacy level for:-
                         =B7 openly identified
                         =B7 anonymously identified (messages
                           from the same sender can be linked)
                         =B7 unadvertised (but tracable) [ed:what
                           does this mean?]
                         =B7 undetectable
Strictest Requirement:  All levels budget of attacker
Example Application:    Secret ballot voting system - anonymously

Retransmit prevention strength
This is extremely hard at the moment. This is not to say it's not
a requirement.
Type:                   Abstract Currency
Meaning:                The cost of retransmitting a secure piece
                         of information should exceed the
                         specified amount.
Strictest Requirement:  Cost of retransmitting value of

Membership Criteria
If a principal attempts to participate in a communication then a
check will be made to see if it is allowed to do so. The
requirement is that certain principals will be allowed, and
others excluded. Given the application is being protected from
network details there are only two types of specification
available, per user, and per organisation (where an organisation
may contain other organisations, and each user may be a member of
multiple organisations). Rules could however be built on
properties of a user, for example does the user own a key? Host
properties could also be used, so users on slow hosts or hosts
running the wrong OS could be excluded.
Type:                   Macros
Meaning:                Include or exclude
                        =B7 users (list)
                        =B7 organisations (list)
                        =B7 hosts (list)
                        =B7 user properties (rule)
                        =B7 org properties (rule)
                        =B7 hosts properties (rule)
Strictest Requirement:  List of individual users
Example Application:    Corporate video-conference - organisation

Membership Principals
Entities that may join a rule-based secure session atomically.
That is, a group of individuals is a principal if they can only
all join or leave together. Principals can be considered as the
SUBJECT field of an access control list, but this is not intended
to imply ACL is a good method to use.
Type:                   Enumeration
Meaning:                values: certified individuals
                         certified group ids (corporations,
                         lists (i.e. lists of lists, such as
                         multicast groups, secure sessions)
                         [ed:get Bob to explain]
Strictest Requirement:  mixture of all types.
Example Application:    N/A

Collusion prevention
Which aspects of collusion it is required to prevent. Collusion
is defined as malicious co-operation between members of a secure
session. Superficially, it would appear that collusion is not a
relevant threat in a multicast, because everyone has the same
information, however, wherever there is differentiation, it can
be exploited.
Type:                   Abstract Currency
Meaning:                time race collusion - cost of colluding
                         key encryption key (KEK) sharing - cost
                         of colluding
                         sharing of differential QoS (not strictly
                         collusion as across sessions not within
                         one) - cost of colluding
Strictest Requirement:  For all threats cost attackers combined
Example Application:    A race where delay of the start signal
                         may be allowed for, but one participant
                         may fake packet delay while receiving the
                         start signal from another participant.
NB:                     Time race collusion is the most difficult
                         one to prevent. Also note that while
                         these may be requirements for some
                         systems this does not mean there are
                         neccessarily solutions. Setting tough
                         requirements may result in the middleware
                         being unable to create a valid channel.

Fairness is orthogonal to many other requirements. Of particular
interest are Reliability and Timeliness requirements. When a
communication is first created the creator may wish to specify a
set of requirements for these parameters. Principals which join
later may wish to set tigher limits. Fairness enforces a policy
that any improvement is requirement by one principal must be
matched by all others, in effect requirements can only be set for
the whole group. This increases the likelyhood that requirements
of this kind will fail to be met. If fairness if not an issue
then some parts of the network can use more friendly methods to
achieve those simpler requirements.
Type:                   delta of the requirement that needs to be
Meaning:                The variance of performance with respect
                         to any other requirement is less than the
                         specified amount.
Example Application:    Networked game, latency to receive
                         positions of players must be within 5ms
                         for all players.

Action on compromise
The action to take on detection of compromise (until security
reassured). Not sure this has anything to do with communications,
Type:                   Boolean
Meaning:                warn but continue
Scope:                  Per communication
Strictest Requirement:  pause
Example Application:    Secure video conference - if intruder
                         alert, everyone is warned, but they can
                         continue while knowing not to discuss
                         sensitive matters (cf. catering staff
                         during a meeting).
                        =20 Security Dynamics
Security dynamics are the temporal properties of the security
mechanisms that are deployed. They may affect other requirements
such as latency or simply be a reflection of the security
limitations of the system. The requirements are often concerned
with abnormal circumstances (eg. system violation).

Mean time between compromises
This is not the same as the strength of a system. A fairly weak
system may have a very long time between compromises because it
is not worth breaking in to, or it is only worth it for very few
people. Mean time between compromises is a combination of
strength, incentive and scale.
Type:                   Time
Scope:                  Per communication
Strictest Requirement:  indefinate
Example Application:    Secure Shell - 1500hrs

Compromise detection time limit
The average time it must take to detect a compromise (one
predicted in the design of the detection system, that is).
Type:                   Time
Scope:                  Per communication
Strictest Requirement:  Round trip time
Example Application:    Secure Shell - 2secs

Compromise recovery time limit
The maximum time it must take to re-seal the security after a
breach. This combined with the compromise detection time limit
defines how long the system must remain inactive to avoid more
security breaches. For example if a compromise is detected in one
minute, and recovery takes five, then one minute of traffic is
now insecure and the members of the communication must remain
silent for four minutes after detection while security is re-
Type:                   Time
Scope:                  Per communication
Strictest Requirement:  1 second
Example Application:    Audio conference - 10 seconds

3.2.8. Payment & Charging

Total Cost
The total cost of communication must be limited to this amount.
This would be useful for tranfer as opposed to stream type
Type:                   Currency
Meaning:                Maximum charge allowed
Scope:                  Per user per communication
Strictest Requirement:  Free
Example Application:    File Transfer: comms cost must be < 1p/Mb

Cost per Time
This is the cost per unit time. Some applications may not be able
to predict the duration of a communication. It may be more
meaningful for those to be able to specifiy price per time
Type:                   Currency
Scope:                  Per user per communication
Strictest&Requirement:  Free
Example Application     Video Conference - 15p / minute

Cost per Mb
This is the cost per unit of data. Some communications may be
charged by the amount of data transfered. Some applications may
prefer to specify requirements in this way.
Type:                   Currency
Scope:                  Per user per communication
Strictest&Requirement:  Free
Example Application     Email advertising - 15p / Mb

4. Mapping of Requirements to IETF Working Groups

5. Further Work
Attempt to simplify! Refine definitions and types. In particular
clarify where enumerations aren't intended to be "one of" types.
Complete specifying worst case values & example apps.
Identification of scope of each parameter (per communication, per
receiver, per sender etc.) to highlight potential heterogeneity
problems Mapping between requirements and IETF Working Groups
Exercising the taxonomy with some scenarios Exercising the
taxonomy with some media-types which represent large sub- sets of
application capabilities so can potentially be "macros" or
shorthand to set values (or ranges) for a large number of
parameters at once.

6. Security Considerations
See comprehensive security section of taxonomy.

7. References
[Bagnall97] Bagnall Peter, Poppitt Alan, Example LSMA classifications [TBA]

[refmcast] IP multicast ref

[limitations] Pullen M, Myjak M, Bouwens C, Limitations of Internet
Protocol Suite for Distributed Simulation in the Large Multicast
Environment, Internet Draft, 26 Mar 1997, draft-ietf-lsma-limitations-

[scenarios] Seidensticker S, Smith W, Myjak W, Scenarios and Appropriate
Protocols for Distributed Interactive Simulation, Internet Draft, 21 Jul
1997, draft-ietf-lsma-scenarios-01.txt

[rmodp] Open Distributed Processing Reference Model (RM-ODP), ISO/IEC
10746-1 to 10746-4 or ITU-T (formerly CCITT) X.901 to X.904. Jan 1995.
Catalogue entries: <URL:http://www.iso.ch/isob/switch-engine-

[blaze95] Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson and
Wiener, Paper on minimal key lengths for security in secret key ciphers?
late 1995

8. Authors' Addresses
Bob Briscoe
B54/74 BT Labs
Martlesham Heath
Ipswich, IP5 3RE
Phone: +44 1473 645196
Fax: +44 1473 640929
EMail: briscorj@boat.bt.com
Home page: http://www.labs.bt.com/people/briscorj/

Peter Bagnall
B54/74 BT Labs
Martlesham Heath
Ipswich, IP5 3RE
Phone: +44 1473 647372
Fax: +44 1473 640929
EMail: pbagnall@jungle.bt.co.uk
Home page: http://www.labs.bt.com/people/bagnalpm/

Alan Poppitt
B54/74 BT Labs
Martlesham Heath
Ipswich, IP5 3RE
Phone: +44 1473 640889
Fax: +44 1473 640929
EMail: apoppitt@jungle.bt.co.uk
Home page: http://www.labs.bt.com/people/poppitag/