INTERNET DRAFT R Briscoe
Large-scale Multicast Applications Working Group P Bagnall
Expiration: 29 January 1998 BT
29 July 1997
Taxonomy of Communication Requirements
for Large-scale Multicast Applications
draft-ietf-lsma-requirements-00.txt
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 learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
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
standardisation.
1. Introduction
===============
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:
- most simply, it can be used as a checklist to create a requirements
statement for a particular LSMA. Example applications will be classified
[bagnall97] using the taxonomy in order to exercise (and improve) it
- because strictest requirement have been defined for many
parameters, it will be possible to identify worst case scenarios for the
design of protocols
- 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
- a step towards standardisation of the way LSMAs define their
communications requirements. This could lead to standard APIs between
applications and protocol adaptation middleware
- identification of limitations in current Internet technology for
LSMAs to be added to the LSMA limitations draft [limitations]
- 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
==============
The following terms have no agreed definition, so they will be defined
for this document.
Session
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.1. Definitions of Roles
=========================
Below is an attempt to list all the possible roles in an LSMA. In any
particular LSMA, many of these roles will merge and many will not be
necessary. In order to model the information flows in an LSMA (the comms
parameters) it is generally essential to have a model of the roles. This
would require the linkages between the roles to be defined for the
specific application in question. This approach is standardised in the
Open Distributed Processing Reference Model [rmodp] where these are
called the Information Model and the Enterprise Model respectively.
Security policy owner
defines policy within which sessions can be created for a security
domain (e.g. corporate security policy)
Party liable (to some degree) for information accuracy
a role that may be established to oversee the self-regulation of
information providers, e.g. Stock Exchange, IEEE conference,
Compuserve, Internet Watch Foundation
Session owner
has original idea to set up session and sets Terms and Conditions
within constraints of above parties
Session creator
e.g. assistant of session owner, or some session creation service
Session secretary
advertises or negotiates timing etc
Membership rule creator
Rules may be different for different roles (e.g. senders v.
receivers)
List controller(s)
maintain membership list based on membership rule and control and
negotiate inclusion in list
Access manager(s)
trusted by list controller to manage access to session, e.g.
handing out keys
Security session members
potential participants, e.g. those that hold keys
Participants
active senders and receivers
Senders
Receivers
Disallowed participants
actively black-listed as opposed to just not invited
Media distributors
more formal role than just senders in an interactive application
Billable parties
pay for participants, e.g. participant's company
Payment Brokers
banking services - per participant
Clearing system
connects payment brokers
Certification authorities (CAs)
Authenticate parties - per participant
Certification hierarchy
connects CAs
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.
Reliability
packet loss
Transactional
Guaranteed
Tolerable loss
Semantic loss
component reliability
fail-over time
mean time between failures
Ordering
Ordering type
Timeliness
Hard/soft real-time
Synchronicity
Burstiness
Jitter
expiry
latency
optimum bandwidth
tolerable bandwidth
required by time and tolerance
host performance
fair delay
frame size
content size
Session Control
initiation
start time
end time
duration
active time
burstiness
atomic join
late join allowed ?
temporary leave allowed ?
late join with catch-up allowed ?
potential streams per session
active streams per sessions
sessions per super-session
session semantics
session list rule (see Security: membership criteria)
terms and conditions
Session Topology
# of senders
# of receivers
density of senders/host
density of receivers/host
density of senders/router
density of receivers/router
shape
session heterogeneity
heterogeneity (of almost all other params)
bandwidth along path
hops/path
rate of join/leave between sub-sets
rate of join/leave from whole super-session
time-zone dependent?
burstiness of join/leave rate
admin domains/path
admin domains/group
Directory
latency of lookups (see Timeliness: latency)
fail-over timeout (see Reliability: fail-over time)
registration churn
mobility
Security
strength
authentication purpose
tamper-proofing
non-repudiation
strength
type
denial of service
membership admission control
action restriction (privacy)
membership privacy
retransmit detection strength
membership criteria
membership principals
collusion prevention
fairness
action on compromise
security dynamics
mean time between compromises
compromise detection time limit
compromise recovery time limit
Payment & Charging
for what
charge basis
content
services
when
who pays whom
prevention of onward re-sale
costing of communications
see also topology
cost elements
cost epochs
quotations
charging costs
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 Reliability
=================
3.2.1.1 Reliability - Packet loss
=================================
Transactional
-------------
When multiple operations must occur atomically, transactional
communications guarantee that either all occur or none occur and a
failure is flagged.
Type: Boolean - on/off
Strictest requirement - on
Example application: bank credit transfer, debit and credit must be
atomic.
NB: Transactions are potentially much more complex, but it is believed
this is an application layer problem.
Guaranteed
----------
Guarantees communications will succeed in certain cases.
Type: enumerated
Deferrable if communication fails it will be deferred until
a time when it will be successful.
Guaranteed the communication will succeed so long as all
necessary components are working.
No guarantee - failure will not be reported.
Strictest requirement - deferred
Example application: stock quote feed 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: fixed point fraction of data
Strictest requirement: 0%
Example application: video 40%
Semantic loss
-------------
The application specifies how many and which parts of the communication
can be discarded if necessary.
type: identifiers - names disposable app level frames
strictest requirement - no loss allowed
example application: video feed - P frames may be lost, I frames not.
3.2.1.2. Component Reliability
==============================
Fail-over time
--------------
The time before a failure is detected and a replacement component is
invoked. This is not directly an application requirement.
Type: time (milliseconds)
Strictest Requirement: application dependent
Example application: Name lookup - 5 seconds
Mean time between failures
--------------------------
Type: time (days)
Strictest requirement: indefinite
Example application: xxx
3.2.2. Ordering
===============
Ordering type
-------------
Specifies what ordering must be preserved for the application
Type: boolean true=idempotent
false=>
enumeration
timing values:
global
per sender
none
sequenced values:
global
per sender
none
causal values:
global
per sender
none
Strictest requirement - global timed, sequenced & causal
Example application : Game - global causal (to make sure being hit by
bullet occurs after shot is fired!)
3.2.3. Timeliness
=================
There is a meta-requirement 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.
Hard-real time: Boolean - hard/soft
Synchronicity
-------------
To make sure that separate elements of a session are correctly
synchronised with respect to each other
Type: milliseconds - allowable sync error
Strictest requirement 80ms
Example application: TV lip-sync value 80ms
Burstiness
----------
This is a measure of the variance of bandwidth requirements over time.
Type: fixed point - variation in b/w as fraction of b/w for variable b/w
communications
Fixed point - 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.
Jitter
------
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: milliseconds - maximum acceptable time error
Strictest requirement - <1ms
Example application: audio streaming - <1ms
NB: A jitter requirement implies that the communication is a real-time
stream.
Expiry
------
This specifies how long the information being transferred remains valid
for.
Type: date (seconds since...)
Strictest requirement - for ever
Example application: key distribution - 3600 seconds (valid for at least
one hour)
Latency
-------
Time between initiation and occurrence of an action from application
perspective.
Type: time (milliseconds)
Strictest requirement application dependent
Example application - audio conference 20ms
NB: where an action consists of several distinct sequential parts the
latency budget 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 (kb/s)
Strictest requirement - xxx
Example application - I phone 8kb/s
Tolerable Bandwidth
-------------------
Minimum bandwidth that application can tolerate
Type: bandwidth (kb/s)
Strictest requirement - xxx
Example application - I 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: time - preferred complete time
time - essential complete time
Strictest requirement application dependent
Example application: email - 1min & 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.
Type: acceptable unfairness (milliseconds)
Strictest requirement: 10ms
Example application: auction room - <10ms
Frame size
----------
Size of logical data packets from application perspective
Type: data size (bytes)
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 (kB)
Strictest requirement: N/A
Example application: xxx
3.2.4. Session Control
======================
initiation
----------
which initiation mechanism will be used
type: enumeration
values : announcement
invitation
directive
example application: corporate s/w update - directive
start time
----------
time sender start sending!
type: date (milliseconds since ...)
strictest requirement: now
example app: FTP - at 3am
end time
--------
type: date (milliseconds since ...)
strictest requirement: now
example app: FTP - now+30mins
duration
--------
(end time) - (start time) = (duration), therefore only two of three
should be specified.
type: time (milliseconds)
strictest requirement: -> 0ms for discrete, indefinite for streams
example app: audio feed - 60mins
active time
------------
total time session is active, not including breaks
type: time (milliseconds)
example app: spectator sport transmission
burstiness
----------
expected level of burstiness of the session
type: fixed point. variance as fraction of max bandwidth
strictest requirement: =bandwidth
example app: 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 (quorum)
strictest requirement: 1.0 (proportion)
example app: 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 channel
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 app: 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 simultaneously
type: int
strictest requirements: indefinite
example app: football match mcast - 6, one main video, four user
selected, one audio commentary
sessions per super-session
--------------------------
number of sessions that a single super-session consists of
type: int
strictest requirement: indefinite
example app: parallel and serial meetings in a conference
session semantics
-----------------
description of which streams are redundant alternate formats, etc.
type: session hierarchy description object (dependent on session
description packet def)
example app: movie with dubbing in several languages
session list rule (see Security: membership criteria)
-----------------
terms and conditions
--------------------
expiry
agreement records
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
density of senders/host
-----------------------
The total number of senders / total number of hosts 1 hop from the
multicast tree (in the shadow). This may be required by the middleware,
the network should support.
type: fixed point
strictest requirement: < 1
example app: international audio conference - 0.2
density of receivers/host
-------------------------
as above
density of senders/router
-------------------------
A measure of the utilisation of routers in the tree. This may be
required by the middleware. The network should support it.
type: fixed point
example app: TV broadcast - 0.001
density of receivers/router
---------------------------
A measure of the utilisation of routers in the tree. This may be
required by the middleware. The network should support it.
type: fixed point
example app: TV broadcast - 0.6
shape
-----
the shape of the multicast tree. The middleware may need to know this.
The network should support it.
type: enumeration
values: star, ring, mesh, multi-level, hybrid multi-level etc.
example app: xxx
session heterogeneity
---------------------
number of distinct groups of participants where within each group the
requirements of all members are identical.
type: fixed point (# of sub-sets / # of participants)
strictest requirement: none
example app: movie, subset of English-speaking consumers with slow
terminals as against French-speaking with slow terminals etc.
heterogeneity (of almost all other params)
------------------------------------------
See Further Work
bandwidth along path
--------------------
an indication of the rate limiting hop in the path, and it's bandwidth.
Needed by the middleware
hops/path
---------
measure of the distance to the core/sender of a communication
rate of join/leave between sub-sets
--------------------------------
the rate at which participants change from one sub-set to another
type: events per time per user
strictest requirement: xxx
example application: TV sports event - camera switching - 0.2/s
rate of join/leave from whole super-session
-------------------------------------------
a measure of participant churn in the super-session (application).
type: events per time
strictest requirement: 100 per second
example app: internet shop - shoppers entering & leaving shop 0.2/min
NB: 10% per minute may join/leave once application stable. [NSA]
time-zone dependent?
--------------------
Is membership likely to be linked to time-zones (i.e. are members
humans, teenagers or computers?)
type: Boolean
example app: email - relevant
burstiness of join/leave rate
------------------------------
measure of variance of join/leave rate. Needed by middleware, from
application (prediction) and network (measurement).
type: standard deviation of events per second
strictest requirement: xxx
example app: football match - high variance between duration of match
and start and end
chat forum: low variance - people joining and leaving continuously
without a start or end.
admin domains/path
------------------
number of admin domains traversed by traffic along a path in the
multicast group.
type: int
strictest requirement:
example app:
admin domains/group
-------------------
number of admin domains which are carrying the communication.
type: int
strictest requirement:
example app:
3.2.6. Directory
================
latency of lookups (see Timeliness: latency)
------------------
fail-over timeout (see Reliability: fail-over time)
-----------------
registration churn
------------------
rate at which name/value mappings are changed
type: probability/time (%/second)
strictest requirement:
example app:
mobility
--------
defines restrictions on when directory entries may be changed
type: enumeration
values: while entry is in use
while entry in unused
never
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
===============
Strength
--------
The level to which a system or any sub-system is capable of providing
information security. Stated as the cost of mounting a successful
attack. In practice this typically reduces to key length comparisons,
but these continually need updating as processing speeds improve. Key
length measures are also specific to encryption attacks, whereas cost
can be applied to physical attacks for example.
Strength applies to every security-related parameter as well as to whole
systems.
Type: currency at a set date (to inflation-proof), e.g. 1970 US$
Strictest requirement: a) $300M in 1995 (estimated budget of major
intelligence agency)[Blaze95] b) an international use requirement
restricts key length to {TBA} bits
Authentication purpose
----------------------
The purpose of ensuring that a principal is who they claim to be.
Authentication also has a strength, or level of certainty that a
positive result is correct (see strength) and a time span over which
authentication is valid (for legal follow-up).
Type: Boolean: for admission (see action restriction)?
Boolean: data from each sender authenticated?
Strictest requirement: authentication of admission to all types of
session and of all senders within sessions
Example application: inter-governmental conference
Tamper-proofing
---------------
Assurance that various aspects of information including its quality is
not violated during communication
Type: Boolean: data is unchanged and complete?
Boolean: data timeliness is assured (no malicious packet delay)?
Boolean: no replay of transmission is possible?
Strictest requirement: All true
Example application: stock price feed
Non-repudiation strength
------------------------
The probability of being able to prove that various aspects of a
communication must have occurred.
Type: fixed point
Strictest requirement: 1.0 (full audit trail)
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.
Non-repudiation type
--------------------
Prove that various aspects of a communication must have occurred.
Logical time is defined as a value in a sequence of events with no
regard to the actual time between the events (e.g. proving a message was
sent before or after sending or receiving another message).
Type: Boolean: sender proving reception
enumeration: by whom
values: {>1 rcvr, certain rcvrs, random rcvrs, all rcvrs }
Boolean: what
Boolean: when
Boolean: logical time
Boolean: sender proving send (redundant if proves reception)
Boolean: what
Boolean: when
Boolean: logical time
Boolean: delta time (since previous rcv)
Boolean: proving membership
Boolean: when
Boolean: logical time
Boolean: rcvr proving received
Boolean: when
Boolean: logical time
Strictest requirement: All true
Example application: Quality audits, auctions, voting, patent disputes
Denial of service
-----------------
TBA - difficult to say anything about this without a particular system
design or mechanism.
See also sender exclusion under privacy.
Membership admission control
----------------------------
Whether admission to membership of a session is controlled.
Type: binary enumeration (Boolean?)
Strictest requirement
Example application:
Action restriction (privacy)
----------------------------
The different types of activity listed below may be private to different
secure sessions within an application. These could be considered as the
ACTION field of an access control list, but this doesn't imply an ACL is
a good method to use. Indeed, access to nearly all the actions below can
be separately controlled by distributing data related to each action in
a separate secure session.
Type: membership list/rule for each of the actions below that requires a
distinct one from the others:
- sending data
- receiving data
- forwarding on data
- sending metadata (headers)
- receiving metadata (headers)
- forwarding on metadata
- sending keys
- receiving keys
- forwarding on keys
- session announcement (includes identity of key controller)
- listing members (see also membership detection)
- forwarding on list
- admitting members
Strictest requirement: all required, but all different lists.
Excluding senders of unsolicited traffic into a session and deterring
retransmission (see also retransmission detection) are the most
difficult ones.
Example application: banking work-flow where no one person may have
access to sufficient information to allow fraud.
Membership privacy
------------------
How hidden the fact that a particular participant has joined a session
is (see also Privacy; listing members).
Type: enumeration
values: openly identified
anonymously identified (only size of membership is known)
unadvertised (but traffic could be traced)
undetectable
Strictest requirement: undetectable - involves randomising traffic
patterns
Example application: news feed where customers wish their interests to
be private.
Retransmit detection strength
-----------------------------
How strong is the requirement to monitor receivers to detect onward
transmission. This is one case where the real requirement - retransmit
prevention - has not been stated, because it is assumed to be
impossible.(see also Privacy; forwarding on data, list, keys etc.)
all rcvrs
certain rcvrs
random rcvrs
Type:
Strictest requirement
Example application:
Membership Criteria
-------------------
The type of criterion used to limit the scope of membership
Type: enumeration
values: session bounded by topology (e.g. fire-wall, TTL)
session bounded by administrative scope
Internet-wide membership based on a rule
Strictest requirement: Internet-wide membership based on a rule
Example application:
limited by topology: corporate video-conference;
Rule-based: support forum open to all parties with paid-up support
contracts.
Membership rules may be:
- simple lists of all members
- address rule (e.g. a.b.c.*)
- based on knowledge of a secret
(token, username-password, challenge-response, customer id)
- based on payment
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
values: certified individual ids
certified group ids (corporations, organisations)
login accounts
lists (i.e. lists of lists,
such as multicast groups, secure sessions)
addresses
decryption proxies (decrypt and re-multicast for a secondary
group such as everyone in a corporation)
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: Boolean: time race collusion (true if needs preventing)
Boolean: key encryption key (KEK) sharing
Boolean: sharing of differential QoS
(not strictly collusion as across sessions not within one)
Strictest requirement: All true.
Time race collusion is the most difficult one to prevent.
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.
Fairness
--------
see timeliness for tolerance between delay differences
see reliability for tolerance between different reliabilities
Action on compromise
--------------------
The action to take on detection of compromise (until security
reassured).
Not sure this has anything to do with communications, really.
Type: binary enumeration (Boolean?)
values: warn but continue
pause
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).
3.2.7.1. Security Dynamics
--------------------------
Security dynamics are the delays that security operations insert into a
system's operation. The delays under normal operation (e.g. key
processing, certification of authenticity etc.) need to be taken into
account when designing to meet other requirements like latency. This
parameter is therefore concerned with delays in abnormal security
circumstances (e.g. system compromise):
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: hours
Strictest requirement: xxx
Example application: xxx
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: seconds
Strictest requirement: xxx
Example application: xxx
Compromise recovery time limit
------------------------------
The maximum time it must take to re-seal the security after a breach.
Type: hours
Strictest requirement: 1 second [NSA]
Example application: xxx
3.2.8. Payment & Charging
=========================
This whole section is probably too far outside the scope of the LSMA
working group and is unfinished anyway.
charging for what?
------------------
content
services
content distribution service
QoS transmission
security services
directory services
Type:
Strictest requirement
Example application:
Charge basis: content
---------------------
(often different granularity to ownership basis)
ownership of content
own use/consumption
unlimited
limited (e.g. n copies or n "views")
royalty-based (pay per "view")
resale
unlimited
limited (e.g. n copies)
royalty-based (could hit multicast enabled routers hard!)
own use and resale
own use and not resale
resale and not own use
Type:
Strictest requirement
Example application:
Charge basis: services
----------------------
subscription
time expired
in perpetuity
pay per consumption time
pay per "object"
hybrids of all these
Type:
Strictest requirement
Example application:
Payment: When?
---------------
pre-paid deposit
pre-pay (before any of each charge basis listed above)
post-pay (before any of each charge basis listed above)
periodically billed by usage
free for introductory period
credit and debit decoupled within tolerance
time limited
money limited
time/money hybrid (formula, e.g. 30days if <£50)
Type:
Strictest requirement
Example application:
Who pays whom?
--------------
(directly as opposed to one collecting for another - every role player
could charge directly, but these are the more likely ones to do so)
This bit would be easier to read in two dimensions - who charges and who
pays
Media distributor (typically pays media owner (typically pays media
advertiser))
Session owner (typically pays session advertiser (and might well
pay media distributor))
Network providers (may be paid by session owner, but difficult as
diff. receivers use diff.networks)
Terminal owners (e.g. library, kiosk, arcade, pub etc)
Matchmaker (in auctions, session directories etc.)
advertising (to partially allay costs, or cover totally)
sender pays (e.g. propaganda that receivers are paid to read!)
pay to receive, paid to send (e.g. to encourage contribution of
home videos - yuk!)
Type:
Strictest requirement
Example application:
prevention of onward re-sale
----------------------------
Type:
Strictest requirement
Example application:
3.2.8.1. Costing of communications
==================================
See also topology
Elements of cost
----------------
terminal resources & QoS
network resources & QoS
server resources & QoS
Type:
Strictest requirement
Example application:
Cost epochs
-----------
up front investment
fixed running costs independent of use
variable (use-dependent) costs
Type:
Strictest requirement
Example application:
quotations
----------
response time
off-line "well known" pricing
expiry
spot pricing
Type:
Strictest requirement
Example application:
Costs of charging
-----------------
communications
storage
processing
debt recovery
fraud detection
customer service (proving charges are valid)
Type:
Strictest requirement
Example application:
4. Mapping of Requirements to IETF Working Groups
=================================================
TBA
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 session, 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.
References
=============
[Bagnall97] Bagnall Peter, 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-
01.txt
[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-
cate.pl?searchtype=refnumber&KEYWORDS=10746>
[blaze95] Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson and
Wiener, Paper on minimal key lengths for security in secret key ciphers?
late 1995
[NSA] Wallner D, Harder E, Agee R, Key Management for Multicast: Issues
and Architectures, National Security Agency, 1 July '97. Internet Draft
draft-wallner-key-arch-00.txt
8. Authors' Addresses
=====================
Bob Briscoe
B54/74 BT Labs
Martlesham Heath
Ipswich, IP5 3RE
England
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
England
Phone: +44 1473 647372
Fax: +44 1473 640929
EMail: pbagnall@jungle.bt.co.uk
Home page: http://www.labs.bt.com/people/bagnalpm/
Datatracker
draft-ietf-lsma-requirements-00
Internet-Draft
