As per Relevance of the word guarantee, we have this rfc below:
Network Working Group C.
Request for Comments: 1363
September 1992
A Proposed Flow
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
A flow specification (or "flow spec") is a data structure used
internetwork hosts to request special services of the internetwork
often guarantees about how the internetwork will handle some of
hosts' traffic. In the future, hosts are expected to have to
such services on behalf of distributed applications such
multimedia conferencing
The flow specification defined in this memo is intended
information and possible experimentation (i.e., experimental use
consenting routers and applications only). This RFC is a product
the Internet Research Task Force (IRTF).
The Internet research community is currently studying the problems
supporting a new suite of distributed applications
internetworks. These applications, which include
conferencing, data fusion, visualization, and virtual reality,
the property that they require the distributed system (the
of hosts that support the applications along with the internetwork
which they are attached) be able to provide guarantees about
quality of communication between applications. For example, a
conference may require a certain minimum bandwidth to be sure
the video images are delivered in a timely way to all recipients
One way for the distributed system to provide guarantees is for
to negotiate with the internetwork for rights to use a certain
of the internetwork's resources. (An alternative is to have
internetwork infer the hosts' needs from information embedded in
data traffic each host injects into the network. Currently, it
not clear how to make this scheme work except for a rather
set of traffic classes.)
Partridge [Page 1]
RFC 1363 A Proposed Flow Specification September 1992
There are a number of ways to effect a negotiation. For example
negotiation can be done in-band or out-of-band. It can also be
in advance of sending data (possibly days in advance), as the
part of a connection setup, or concurrently with sending (i.e.,
host starts sending data and starts a negotiation to try to
that it will allowed to continue sending). Insofar as is possible
this memo is agnostic with regard to the variety of negotiation
is to be done
The purpose of this memo is to define a data structure, called a
specification or flow spec, that can be used as part of
negotiation to describe the type of service that the hosts need
the internetwork. This memo defines the format of the fields of
data structure and their interpretation. It also briefly
what purpose the different fields fill, and discusses why this set
fields is thought to be both necessary and sufficient
It is important to note that the goal of this flow spec is to able
describe *any* flow requirement, both for guaranteed flows and
applications that simply want to give hints to the internetwork
their requirements
Format of the Flow
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Maximum Transmission Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Bucket Rate | Token Bucket Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Transmission Rate | Minimum Delay Noticed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Delay Variation | Loss Sensitivity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Burst Loss Sensitivity | Loss Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality of Guarantee |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Discussion of the Flow
The flow spec indicates service requirements for a single direction
Multidirectional flows will need to request services in
directions (using two flow specs).
To characterize a unidirectional flow, the flow spec needs to do
things
Partridge [Page 2]
RFC 1363 A Proposed Flow Specification September 1992
First, it needs to characterize how the flow's traffic will
injected into the internetwork. If the internetwork doesn't
what to expect (is it a gigabit-per-second flow or a three kilobit
per-second flow?) then it is difficult for the internetwork to
guarantees. (Note the word "difficult" rather than "impossible."
may be possible to statistically manage traffic or over-engineer
network so well that the network can accept almost all flows,
setup. But this problem looks far harder than asking the sender
approximate its behavior so the network can plan.) In this
spec, injected traffic is characterized as having a sustainable
(the token bucket rate) a peak rate (the maximum transmission rate),
and an approximate burst size (the token bucket size). A
precise definition of each of these fields is given below.
characterization is based, in part, on the work done in [1].
Second, the flow spec needs to characterize sensitivity to delay
Some applications are more sensitive than others. At the same time
the internetwork will likely have a choice of routes with
delays available from the source to destination. For example,
routes using satellites (which have very long delays) and
using terrestrial lines (which will have shorter delays) may
available. So the sending host needs to indicate the flow'
sensitivity to delay. However, this field is only advisory. It
tells the network when to stop trying to reduce the delay - it
not specify a maximum acceptable delay
There are two problems with allowing applications to specify
maximum acceptable delay
First, observe that an application would probably be happy with
maximum delay of 100 ms between the US and Japan but very
with a delay of 100 ms within the same city. This
suggests that the maximum delay is actually variable, and is
function of the delay that is considered achievable. But
achievable delay is largely determined by the geographic
between the two peers, and this sort of geographical information
usually not available from a network. Worse yet, the advent
mobile hosts makes such information increasingly hard to provide.
there is reason to believe that applications may have
choosing a rational maximum delay
The second problem with maximum delays is that they are an attempt
quantify what performance is acceptable to users, and an
usually does not know what performance will be acceptable its user
For example, a common justification for specifying a
acceptable delay is that human users find it difficult to talk
each other over a link with more than about 100 ms of delay
Certainly such delays can make the conversation less pleasant, but
Partridge [Page 3]
RFC 1363 A Proposed Flow Specification September 1992
is still possible to converse when delays are several seconds long
and given a choice between no connection and a long delay, many
will pick the delay. (The phone call may involve an important
that must be resolved.)
As part of specifying a flow's delay sensitivity, the flow spec
also characterize how sensitive the flow is to the distortion of
data stream
Packets injected into a network according to some pattern will
normally come out of the network still conforming to the pattern
Instead, the pattern will have been distorted by queueing effects
the network. Since there is reason to believe that it may
network design easier to continue to allow the networks
distort traffic patterns, it is expected that those
which are sensitive to distortion will require their hosts to
some amount of buffering to reshape the flow back into its
form. It seems reasonable to assume that buffer space is
infinite and that a receiving system will wish to limit the amount
buffering that a single flow can use
The amount of buffer space required for removing distortion at
receiving system is determined by the variation in end-to-
transmission delays for data sent over the flow. If the
delay is a mean delay, D, plus or minus a variance, V, the
system needs buffer space equivalent to 2 * V * the
rate. To see why this is so, consider two packets, A and B, sent
time units apart which must be delivered to the receiving
T time units apart. In the worst case, A arrives after a delay
D-V time units (the minimum delay) and B arrives after a delay of D+
time units (the maximum delay). The receiver cannot deliver B
it arrives, which is T + 2 * V time units after A. To ensure that
is delivered T time units before B, A must be buffered for 2 * V
units. The delay variance field is the value of 2 * V, and
the receiver to indicate how much buffering it is willing to provide
A third function of the flow spec is to signal sensitivity to loss
data. Some applications are more sensitive to the loss of their
than other applications. Some real-time applications are
sensitive to loss and unable to wait for retransmissions of data
For these particularly sensitive applications, hosts may
forward error correction on a flow to try to absolutely
loss. The loss fields allow hosts to request loss
appropriate for the application's requirements
Finally, it is expected that the internetwork may be able to
a range of service guarantees. At the best, the internetwork may
asked to guarantee (with tight probability bounds) the quality
Partridge [Page 4]
RFC 1363 A Proposed Flow Specification September 1992
service it will provide. Or the internetwork may simply be asked
ensure that packets sent over the flow take a terrestrial path.
quality of guarantee field indicates what type of service
the application desires
Definition of Individual
General Format of
With a few exceptions, fields of the flow spec are expressed using
common 16-bit format. This format has two forms. The first form
shown below
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Exponent | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this format, the first bit is 0, followed by 7 bits of an
(E), and an 8-bit value (V). This format encodes a number, of
form V * (2**E). This representation was chosen to allow
representation of a wide range of values, while avoiding over-
representations
In some case, systems will not wish to request a precise value
rather simply indicate some sensitivity. For example, a
terminal application like Telnet will likely want to indicate that
is sensitive to delay, but it may not be worth expressing
delay values for the network to try to achieve. For these cases
instead of a number, the field in the flow spec will take
following form
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Well-defined Constant |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit of the field is one, and is followed by a 15-
constant. The values of the constants for given fields are
below. Any additional values can be requested from the
Assigned Numbers Authority (IANA).
Version
This field is a 16-bit integer in Internet byte order. It is
version number of the flow specification. The version number
the flow specification defined in this document is 1. The IANA
responsible for assigning future version numbers for any
Partridge [Page 5]
RFC 1363 A Proposed Flow Specification September 1992
revisions of this flow specification
This field does not use the general field format
Maximum Transmission Unit (MTU
A 16-bit integer in Internet byte order which is the
number of bytes in the largest possible packet to be
over this flow
This field does not use the general field format
The field serves two purposes
It is a convenient unit for expressing loss properties. Using
default MTU of the internetwork is inappropriate since
internetwork have very large MTU, such the 64Kbytes of IP,
applications and hosts may be sensitive to losses of far less
an MTU's amount of data -- for example, a voice application
be sensitive to a loss of several consecutive small packets
The MTU also bounds the amount of time that a flow can transmit
uninterrupted, on a shared media
Similarly, the loss rates of links that suffer bit errors
vary dramatically based on the MTU size
Token Bucket
The token bucket rate is one of three fields used to define
traffic will be injected into the internetwork by the
application. (The other two fields are the token bucket size
the maximum transmission rate.)
The token rate is the rate at which tokens (credits) are
into an imaginary token bucket. For each flow, a separate
is maintained. To send a packet over the flow, a host must
a number of credits equal to the size of the packet from the
bucket. If there are not enough credits, the host must wait
enough credits accumulate in the bucket
Note that the fact that the rate is expressed in terms of a
bucket rate does not mean that hosts must implement token buckets
Any traffic management scheme that yields equivalent behavior
permitted
The field is in the general field format and counts the number
byte credits (i.e., right to send a byte) per second which
Partridge [Page 6]
RFC 1363 A Proposed Flow Specification September 1992
deposited into the token bucket. The value must be a number (
a well-known constant).
The value zero is slightly special. It is used to indicate
the application is not making a request for bandwidth guarantees
If this field is zero, then the Token Bucket Size must also
zero, and the type of guarantee requested may be no higher
predicted service
Token Bucket
The token bucket size controls the maximum amount of data that
flow can send at the peak rate. More formally, if the
bucket size is B, and the token bucket rate is R, over
arbitrarily chosen interval T in the life of the flow, the
of data that the flow sends cannot have exceeded B + (R * T
bytes
The token bucket is filled at the token bucket rate. The
size limits how many credits the flow may store. When the
is full, new credits are discarded
The field is in the general field format and indicates the size
the bucket in bytes. The value must be a number
Note that the bucket size must be greater than or equal to the
size
Zero is a legal value for the field and indicates that no
are saved
Maximum Transmission
The maximum transmission rate limits how fast packets may be
back to back from the host. Consider that if the token bucket
full, it is possible for the flow to send a series of back-to-
packets equal to the size of the token bucket. If the
bucket size is large, this back-to-back run may be long enough
significantly inhibit multiplexing
To limit this effect, the maximum transmission rate bounds
fast successive packets may be placed on the network
One can think of the maximum transmission rate control as being
form of a leaky bucket. When a packet is sent, a number
credits equal to the size of the packet is placed into an
bucket, which drains credits at the maximum transmission rate.
more packets may be sent until the bucket has emptied again
Partridge [Page 7]
RFC 1363 A Proposed Flow Specification September 1992
The maximum transmission rate is the rate at which the bucket
emptied. The field is in the general field format and
the size of the bucket in bytes. The value must be a number
must be greater than or equal to the token bucket rate
Note that the MTU size can be used in conjunction with the
transmission rate to bound how long an individual packet
other transmissions. The MTU specifies the maximum time
individual packet may take. The Maximum Transmission Rate,
the frequency with which packets may be placed on the network
Minimum Delay
The minimum delay noticed field tells the internetwork that
host and application are effectively insensitive to
in end-to-end delay below this value. The network is
to drive the delay down to this value but need not try to
the delay further
The field is in the general field format
If expressed as a number it is the number of microseconds of
below which the host and application do not care
improvements. Human users only care about delays in
millisecond range but some applications will be computer
computer and computers now have clock times measured in a
of nanoseconds. For such computers, microseconds are
appreciable time. For this reason, this field measures
microseconds, even though that may seem small
If expressed as a well-known constant (first bit set), two
values are accepted
0 - the application is not sensitive to
1 - the application is moderately delay
e.g., avoid satellite links where possible).
Maximum Delay
If a receiving application requires data to be delivered in
same pattern that the data was transmitted, it may be
for the receiving host to briefly buffer data as it is received
that the receiver can restore the old transmission pattern. (
easy example of this is a case where an application wishes to
and transmit data such as voice samples, which are generated
played at regular intervals. The regular intervals may
distorted by queueing effects in the network and the receiver
Partridge [Page 8]
RFC 1363 A Proposed Flow Specification September 1992
have to restore the regular spacing.)
The amount of buffer space that the receiving host is willing
provide determines the amount of variation in delay permitted
individual packets within a given flow. The maximum
variation field makes it possible to tell the network how
variation is permitted. (Implementors should note that
restrictions on the maximum transmission rate may cause
traffic patterns to be distorted before they are placed on
network, and that this distortion must be accounted for
determining the receiver buffer size.)
The field is in the general field format and must be a number.
is the difference, in microseconds, between the maximum
minimum possible delay that a packet will experience. (There
some question about whether microsecond units are too large. At
terabit per second, one microsecond is a megabit. Presumably if
host is willing to receive data at terabit speeds it is willing
provide megabits of buffer space.)
The value of 0, meaning the receiving host will not buffer
delays, is acceptable but the receiving host must still
enough buffer space to receive a maximum transmission unit
packet from the sending host. Note that it is expected that
value of 0 will make it unlikely that a flow can be established
Loss
This field indicates how sensitive the flow's traffic is
losses. Loss sensitivity can be expressed in one of two ways
either as a number of losses of MTU-sized packets in an interval
or simply as a value indicating a level of sensitivity
The field is in the general field format
If the value is a number, then the value is the number of MTU
sized packets that may be lost out of the number of MTU-
packets listed in the Loss Interval field
If the value is a well-known constant, then one of two values
permitted
0 - the flow is insensitive to
1 - the flow is sensitive to loss (where
choose the path with the lowest loss rate).
Partridge [Page 9]
RFC 1363 A Proposed Flow Specification September 1992
Burst Loss
This field states how sensitive the flow is to losses
consecutive packets. The field enumerates the maximum number
consecutive MTU-sized packets that may be lost
The field is in the general field format
If the value is a number, then the value is the number
consecutive MTU-sized packets that may be lost
If the value is a well-known constant, then the value 0
that the flow is insensitive to burst loss
Note that it is permissible to set the loss sensitivity field
simply indicate sensitivity to loss, and set a numerical limit
the number of consecutive packets that can be lost
Loss
This field determines the period over which the maximum number
losses per interval are measured. In other words, given
arbitrarily chosen interval of this length, the number of
may not exceed the number in the Loss Sensitivity field
The field is in the general field format
If the Loss Sensitivity field is a number, then this field
also be a number and must indicate the number of MTU-sized
which constitutes a loss interval
If the Loss Sensitivity field is not a number (i.e., is a well
known constant) then this field must use the well-known
of 0 (i.e., first bit set, all other bits 0) indicating that
loss interval is defined
Quality of
It is expected that the internetwork will likely have to
more than one type of guarantee
There are two unrelated issues related to guarantees
First, it may not be possible for the internetwork to make a
guarantee. Consider a path through an internetwork in which
last hop is an Ethernet. Experience has shown (e.g., some of
IETF conferencing experiments) that an Ethernet can often
acceptable performance, but clearly the internetwork
Partridge [Page 10]
RFC 1363 A Proposed Flow Specification September 1992
guarantee that the Ethernet will not saturate at some time
a flow's lifetime. Thus it must be possible to
between flows which cannot tolerate the small possibility of
failure (and thus must guaranteed at every hop in the path)
those that can tolerate islands of uncertainty
Second, there is some preliminary work (see [2]) that
that some applications will be able to adapt to modest
in internetwork performance and that network designers can
this flexibility to allow better network utilization. In
model, the internetwork would be allowed to deviate slightly
the promised flow parameters during periods of load. This
of service is called predicted service (to distinguish it
guaranteed service).
The difference between predicted service and service which
be perfectly guaranteed (e.g., the Ethernet example
above) is that the imperfect guarantee makes no
promises about how it might mis-behave. In the worst case,
imperfect guarantee will not work at all, whereas
service will give slightly degraded service. Note too
predicted service assumes that the routers and links in a path
cooperate (to some degree) whereas an imperfect guarantee
that some routers or links will not cooperate
The field is a 16-bit field in Internet byte order. There are
legal values
0 - no guarantee is required (the host is simply
desired performance for the flow
100 (hex) - an imperfect guarantee is requested
200 (hex) - predicted service is requested and if unavailable
then no flow should be established
201 (hex) - predicted service is requested but an
guarantee is acceptable
300 (hex) - guaranteed service is requested and if a
guarantee cannot be given, then no flow should
established
301 (hex) - guaranteed service is request and but an
guarantee is acceptable
It is expected that asking for predicted service or permitting
imperfect guarantee will substantially increase the chance that
Partridge [Page 11]
RFC 1363 A Proposed Flow Specification September 1992
flow request will be accepted
Possible Limitations in the Proposed Flow
There are at least three places where the flow spec is
imperfect, based on what we currently know about flow reservation
In addition, since this is a first attempt at a flow spec,
should expect modifications as we learn more
First, the loss model is not perfect. Simply stating that
application is sensitive to loss and to burst loss is a rather
indication of sensitivity. However, explicitly enumerating
requirements within a cycle is also an imperfect mechanism. The
problem with the explicit values is that not all packets sent over
flow will be a full MTU in size. Expressed another way, the
flow spec expects that an MTU-sized packet will be the unit of
recovery. If flows send packets in a range of sizes, then the
bounds may not be very useful. However, the thought of allowing
flow to request a set of loss models (one per packet size)
sufficiently painful that I've limited the flow to one loss profile
Further study of loss models is clearly needed
Second, the minimum delay sensitivity field limits a flow to
that there is one point on a performance sensitivity curve
which the flow is no longer interested in improved performance.
may be that a single point is insufficient to fully express a flow'
sensitivity. For example, consider a flow for supporting part of
two-way voice conversation. Human users will notice improvements
delay down to a few 10s of milliseconds. However, the key point
sensitivity is the delay at which normal conversation begins
become awkward (about 100 milliseconds). By allowing only
sensitivity point, the flow spec forces the flow designer to
ask for the best possible delay (e.g, a few 10's of ms) to try to
maximum performance from the network, or state a sensitivity of
95 ms, and accept the possibility that the internetwork will not
to improve delay below that value, even if it could (and even
the user would notice the improvement). My expectation is that
simple point is likely to be easier to deal with than attempting
enumerate two (or three or four) points in the sensitivity curve
Third, the models for service guarantees is still evolving and it
by no means clear that the service choices provided are the
set
Partridge [Page 12]
RFC 1363 A Proposed Flow Specification September 1992
How an Internetwork is Expected to Handle a Flow
There are at least two parts to the issue of how an internetwork
expected to handle a flow spec. The first part deals with how
flow spec is interpreted so that the internetwork can find a
which will allow the internetwork to match the flow's requirements
The second part deals with how the network replies to the host'
request
The precise mechanism for setting up a flow, given a flow spec, is
large topic and beyond the scope of this memo. The purpose of
next few paragraphs is simply to sketch an argument that this
spec is sufficient to the requirements of the setup mechanisms
to the author
The key problem in setting up a flow is determining if there
one or more routes from the source to the destination(s) which
be able to support the quality of service requested. Once one has
route (or set of candidate routes) one can take whatever actions
be appropriate to confirm that the route is actually viable and
cause the flow's data to follow that route
There are a number of ways to find a route. One might try to build
route on the fly by establishing the flow hop-by-hop (as ST-II does
or one might consult a route server which provides a set of
source routes derived from a routing database. However,
system is used, some basic information about the flow needs to
provided to the routing system. This information is
* How much bandwidth the flow may require. There's no
in routing a flow that expects to send at over 10 megabits
second via a T1 (1.5 megabit per second) link
* How delay sensitive the application is. One does not
to route a delay-sensitive application over a satellite link
unless the satellite link is the only possible route from
to there
* How much error can be tolerated. Can we send this flow
our microwave channel on a rainy day or is a more reliable
required
* How firm the guarantees need to be. Can we put an
in as one of the hops
* How much delay variation is tolerated. Again, can an
be included in the path? Does the routing system need to
if the addition of this flow will cause a few routers to
Partridge [Page 13]
RFC 1363 A Proposed Flow Specification September 1992
at close to capacity? (A side note: we assume that the
are running with priority queueing systems, so running the
close to capacity doesn't mean that all flows get long
variable delays. Rather, running close to capacity means
high priority flows will be unaffected, and low priority
will get hit with a lot of delay and variation.)
The flow spec provides all of this information. So it
plausible to assume it provides enough information to make
decisions at setup time
The flow spec was designed with the expectation that the
would give a yes or no reply to a request for a guaranteed flow
Some researchers have suggested that the negotiation to set up a
might be an extended negotiation, in which the requesting
initially requests the best possible flow it could desire and
haggles with the network until they agree on a flow with
that the network can actually provide and the application still
useful. This notion bothers me for at least two reasons. First,
means setting up a flow is a potentially long process. Second,
general problem of finding all possible routes with a given set
properties is a version of the traveling salesman problem, and
don't want to embed traveling salesman algorithms into a network'
routing system
The model used in designing this flow spec was that a system
ask for the minimum level of service that was deemed acceptable
the network would try to find a route that met that level of service
If the network is unable to achieve the desired level of service,
refuses the flow, otherwise it accepts the flow
The Flow Spec as a Return
This memo does not specify the data structures that the network
to accept or reject a flow. However, the flow spec has been
so that it can be used to return the type of service
guaranteed
If the request is being accepted, the minimum delay field could
set to the guaranteed or predicted delay, and the quality
guarantee field could be set to no guarantee (0), imperfect
(100 hex), predicted service (200 hex), or guaranteed service (300
hex).
If the request is being rejected, the flow spec could be modified
indicate what type of flow the network believes it could accept e.g.,
the traffic shape or delay characteristics could be adjusted or
Partridge [Page 14]
RFC 1363 A Proposed Flow Specification September 1992
type of guarantee lowered). Note that this returned flow spec
likely be a hint, not a promised offer of service
Why Type of Service is not Good
The flow spec proposed in this memo takes the form of a set
parameters describing the properties and requirements of the flow
An alternative approach which is sometimes mentioned (and which
currently incorporated into IP) is to use a Type of Service (TOS
value
The TOS value is an integer (or bit pattern) whose values have
predefined to represent requested quality of services. Thus, a
of 47 might request service for a flow using up to 1 gigabit
second of bandwidth with a minimum delay sensitivity of 100
milliseconds
TOS schemes work well if the different quality of services that
be requested are both enumerable and reasonably small
Unfortunately, these conditions do not appear to apply to
internetworks. The range of possible bandwidth requests alone
huge. Combine this range with several gradations of
requirements, and widely different sensitivities to errors and
set of TOS values required becomes extremely large. (At least
person has suggested to the author that perhaps a TOS field
with a bandwidth parameter might be appropriate. In other words,
two parameter model. That's a tempting idea but my gut feeling
that it is not quite sufficient so I'm proposing a more
parametric model.)
Another reason to prefer parametric service is optimization issues
A key issue in flow setup is trying to design the the routing
to optimize its management of flows. One can optimize on a number
criteria. A good example of an optimization problem is the
question (expressed by Isidro Castineyra of BBN):
"Given a request to establish a flow, how can the
accept that request in such a way as to maximize the chance
the internetwork will also be able to accept the next
request?"
The optimization goal here is call-completion - maximizing the
that requests to establish flows will succeed. One
alternatively try to maximize revenue (if one is charging for flows).
The internetwork is presumably in a better position to
optimizations if it has more information about the flow's
behavior. For example, if a TOS system says only that a flow
Partridge [Page 15]
RFC 1363 A Proposed Flow Specification September 1992
delay sensitive, the routing system must seek out the most
route for the flow. But if the routing system is told that the
is sensitive only to delays over 100 milliseconds, there may be
number of routes other than the most direct route which can
this delay, thus leaving the most direct route available for a
flow which needs a far lower delay
In fairness, it should be noted that a danger of a parametric
is that it is very easy to have too many parameters. The yearn
optimize can be overdone. The goal of this flow spec is to
just enough parameters that it appears that essential needs can
expressed, and the internetwork has some information it can use
try to manage the flows. Features that would simply be nice
useful to have (but not essential) are left out to keep the
space small
An Implication of the Flow
It is important to observe that the there are fields in the flow
that are based on information from the sender (such as
information) and fields in the flow spec that are based
information from the receiver (such as delay variation). There
also fields that may sender and receiver to negotiate in advance
For example, the acceptable loss rate may depend on whether
sender and receiver both support the same type of forward
correction. The delay sensitivity for a voice connection may depend
in part, on whether both sender and receiver support echo cancelling
The implication is that the internetwork must permit the sender
receiver to communicate in advance of setting up a flow, because
flow spec can only be defined once both sender and receiver have
their say. In other words, a reserved flow should not be the
form of communication. There must be some mechanism to perform
short exchange of messages in preparation for setting up a flow
(Another aside: it has been suggested that perhaps the solution
this problem is to have the sender establish a flow with
incomplete flow spec, and when the receiver gets the flow spec,
the receiver send the completed flow spec back along the flow, so
internetwork can "revise" the flow spec according to the receiver'
desires. I have two problems with this approach. First, it
entirely possible that the receiver's information may lead
internetwork to conclude that the flow established by the sender
no good. For example, the receiver may indicate it has a
tolerance for delay variation than expected and force the flow to
rerouted over a completely different path. Second, if we try
avoid having the receiver's information cause the flow to fail,
we have to over-allocate the flow's during the preliminary setup
Partridge [Page 16]
RFC 1363 A Proposed Flow Specification September 1992
But over allocating the resources requested may lead us to
better quality paths than we need for this flow. In other words,
attempts to optimize use of the network will fail.)
Advance Reservations and Flow
The primary purpose of a flow specification is to provide
to the internetwork so the internetwork can properly manage
proposed flow's traffic in the context of other traffic in
internetwork. One question is whether the flow should give
network information about when the flow is expected to start and
long the flow is expected to last
Announcing when a flow will start is generally of interest
advance reservations. (If the flow is not be reserved
in advance, the presentation of the flow spec to the internetwork
be taken as an implicit request for a flow, now.) It is my view
advance reservation is a distinct problem from the describing
properties of a flow. Advanced reservations will require
mechanism to maintain information in the network about flows
are not currently active but are expected to be activated at
time in the future. I anticipate this will require some sort
distributed database to ensure that information about
reservations is not accidentally lost if parts of the
crash. In other words, advance reservations will
considerable additional supporting baggage that it would probably
better to keep out of the average flow spec
Deciding whether a flow spec should contain information about
long the flow is expected to run is a harder decision to make
Clearly if we anticipate that the internetwork will support
reservations, it will be necessary for elements of the
to predict their traffic load, so they can ensure that
reservations are not compromised by new flow requests. However
there is a school of thought that believes that estimating
load from current behavior of existing flows is more accurate
anything the flows may have declared in their flow specs. For
reason, I've left a duration field out of the flow spec
To illustrate how the flow spec values might be used, this
presents three example flow specs
For the first example, consider using the flow spec to
service for an existing application: Telnet. Telnet is a
Partridge [Page 17]
RFC 1363 A Proposed Flow Specification September 1992
terminal protocol, and one can think of it as stringing a
wire across the network between the user's terminal and a
host
Telnet has proved a very successful application without a need
reserve bandwidth: the amount of data sent over any
connection tends to be quite small. However, Telnet users
often quite sensitive to delay, because delay can affect the
it takes to echo characters. This suggests that a
connection might benefit from asking the internetwork to
long delay paths. It could so so using the following flow
(for both directions):
Version=1
MTU=80 [40 bytes of overhead + 40 bytes user data
Token Bucket Rate=0/0/0 [don't want a guarantee
Token Bucket Size=0/0/0
Maximum Transmission Rate=0/0/0
Maximum Delay Noticed=1/1 [constant = delay sensitive
Maximum Delay Variation=0/0/0 [not a concern
Loss Sensitivity=1/0 [don't worry about loss
Burst Loss Sensitivity=1/0
Loss Interval=1/0
Quality of Guarantee=1/0 [just asking
It is worth noting that Telnet's flow spec is likely to be
same for all instantiations of a Telnet connection. As a result
there may be some optimizations possible (such as just
Telnet packets as being subject to the well-known Telnet
spec).
A Voice
Now consider transmitting voice over the Internet. Currently
good quality voice can be delivered at rates of 32Kbit/s
16Kbit/s. Assuming the rate is 32Kbit/s and voice samples are 16
bit samples packaged into UDP datagrams (for a data rate of
60 Kbyte/s), a flow spec might be
Version=1
MTU=30 [2 byte sample in UDP datagram
Token Bucket Rate=0/10/59 [60.4 Kbytes/s
Token Bucket Size=0/0/30 [save enough to send
after pauses
Maximum Transmission Rate=0/10/59 [peak same as mean
Maximum Delay Noticed=0/10/100 [100 ms
Maximum Delay Variation=0/10/10 [keep variation low
Loss Sensitivity=1/1 [loss sensitive
Partridge [Page 18]
RFC 1363 A Proposed Flow Specification September 1992
Burst Loss Sensitivity=0/0/5 [keep bursts small
Loss Interval=1/0
Quality of Guarantee=1/201 [predicted service and I'll
worse
A Variable Bit-Rate Video
Variable bit-rate video transmissions vary the rate at which
send data according to the amount of the video image that
changed between frames. In this example, we consider a one-
broadcast of a picture. If we assume 30 frames a second and
a full frame is about 1 megabit of data, and that on average
10% of the frame changes, but in the worst case the entire
changes, the flow spec might be
Version=1
MTU=4096 [big so we can put lots of bits in each packet
Token Bucket Rate=0/20/1 [8 Mbits/s
Token Bucket Size=0/17/2 [2 Mbits/s
Maximum Transmission Rate=0/20/30 [30 Mbits/s
Maximum Delay Noticed=1/1 [somewhat delay sensitive
Maximum Delay Variation=0/10/1 [no more than one second
buffering
Loss Sensitivity=0/0/1 [worst case, one loss per frame
Burst Loss Sensitivity=0/0/1 [no burst errors please
Loss Interval=0/0/33 [one frame in MTU sized packets
Quality of Guarantee=1/300 [guaranteed service only
The token bucket is sized to be two frames of data, and the
rate will fill the bucket every 250 ms. The expectation is
full scene changes will be rare and that a fast rate with a
bucket size should accommodate even a series of scene changes
In all cases, these examples are simply to sketch the use of
flow spec. The author makes no claims that the actual values
are the correct ones for a particular application
Security
Security considerations definitely exist. For example, one
assume that users are charged for guaranteed flows. In that case
some mechanism must exist to ensure that a flow request (
flow spec) is authenticated. However I believe that such issues
to be dealt with as part of designing a negotiation protocol, and
not part of designing the flow spec data structure
Partridge [Page 19]
RFC 1363 A Proposed Flow Specification September 1992
I'd like to acknowledge the tremendous assistance of Steve Deering
Scott Shenker and Lixia Zhang of XEROX PARC in writing this RFC
Much of this flow spec was sketched out in two long meetings
them at PARC. Others who have offered notable advice and
include Isidro Castineyra, Deborah Estrin, and members of the End
to-End Research Group chaired by Bob Braden. All ideas that
misbegotten are the sole responsibility of the author. This work
funded under DARPA Contract No. MDA903-91-D-0019. The
expressed in this document are not necessarily those of the
Advanced Research Projects Agency
1. Parekh, A., "A Generalized Processor Sharing
to Flow Control in Integrated Services Networks",
MIT Laboratory for Information and Decision Systems
Report No. LIDS-TH-2089.
2. Clark, D., Shenker, S., and L. Zhang, "Supporting Real-
Applications in an Integrated Services Packet Network
Architecture and Mechanism", Proceedings of ACM SIGCOMM '92,
August 1992.
Author's
Craig
824 Kipling
Palo Alto, CA 94301
Phone: 415-325-4541
EMail: craig@aland.bbn.
Partridge [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
