INTERNET-DRAFT C. W. Ng
Document: draft-ng-opes-irmlqos-00.txt P. Y. Tan
Expires: January 2002 H. Cheng
Panasonic Singapore Labs
July 2001
Quality of Service Extension to IRML
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Intermediary Rule Markup Language (IRML) [2] is an XML-based
language that can be used to describe service-specific execution
rules for network edge intermediaries under the Open Pluggable Edge
Services (OPES) framework, as described in [3] and [4]. This memo
illustrates examples of employing the IRML for Quality of Service
(QoS) policing and control, and suggests extensions to IRML for
better QoS support.
Ng, Tan, Cheng Expires January 2002 [Page 1]
INTERNET-DRAFT QoS Extension to IRML July 2001
Table of Contents
1. Introduction....................................................2
1.1. Terms Used....................................................2
2. Example Services for QoS Policing in OPES Services..............2
2.1. Adaptation of HTML Contents...................................2
2.2. Dynamic Adaptation of Streaming Contents......................3
2.3. QoS Policy Control............................................4
2.4. Load-Balancing................................................4
3. Requirements for QoS Extension..................................4
4. Proposal to IRML Extensions.....................................5
4.1. QoS Policy Properties.........................................5
4.2. Network Status Properties.....................................5
4.3. Intermediary Load Properties..................................7
5. Examples........................................................7
6. References......................................................9
7. AuthorÆs Address................................................9
1. Introduction
The Intermediary Rule Markup Language (IRML) [2] is an XML-based
language that can be used to describe service-specific execution
rules for network edge intermediaries under the Open Pluggable Edge
Services (OPES) framework, as described in [3] and [4]. This memo
illustrates examples of employing the IRML for Quality of Service
(QoS) policing and control, and suggests extensions to IRML for
better QoS support.
This memo begins in Section 2 by illustrating a few scenarios where
QoS policing and control can be incorporated into the OPES
intermediary. From there, a set of preliminary requirements for QoS
extension to the IRML is drafted in Section 3. Section 4 proposed a
set of QoS extension to the "property" element defined in the IRML,
and Section 5 presents some examples illustrating possible use of
these extensions.
1.1. Terms Used
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [5].
2. Example Services for QoS Policing in OPES Services
2.1. Adaptation of HTML Contents
By far, Hyper Text Markup Language (HTML) pages are the most common
content transported by the Hyper Text Transfer Protocol (HTTP).
These HTML contents are usually static, making them ideal candidate
Ng, Tan, Cheng Expires January 2002 [Page 2]
INTERNET-DRAFT QoS Extension to IRML July 2001
to be cached at the network edge. However, with increasing number
of "thin" clients, it is virtually impossible to have a HTML page
that is suitable to be viewed for all the possible browsers.
Adaptation of HTML pages to suit the clientÆs browser is widely
employed (through means of server-side includes or client-side
JavaScripts). One excellent example would be the adaptation of HTML
to WML (Wireless Markup Language) pages.
Adaptation of HTML pages can also be employed to suit the user or
access-provider QoS requirements. For example, it might be
necessary to remove redundant information when translating HTML
pages to WML for a mobile phone client with a very limited bandwidth
(and limited screen size). It will also be helpful to replace the
![]()
tags in the original HTML page to their ALT text equivalence.
For another client who is using a Personal Digital Assistant (PDA)
with a Wideband-CDMA connection, the translated WML may include more
of the original HTML contents and some pictures.
Bandwidth is not the only consideration. For the example of the PDA
client quoted above, when the channel condition is poor, it might be
desirable to reduce the amount of text in the translated WML to
ensure a more speedy delivery.
Such HTML adaptation is not only limited to the wireless scenario.
For a client with a wired connection to the Internet, it is
sometimes necessary to sub-sample the embedded images in a HTML
pages to reduce their size so as to meet the maximum delay
requirements imposed by the user or access-provider. This can occur
when the allocated bandwidth is small, or when the connection is
congested (e.g. the user is downloading a couple of files
simultaneously).
2.2. Dynamic Adaptation of Streaming Contents
Streaming of audio-visual (AV) contents over the Internet has become
increasing popular over the years. AV streaming poses different
technical challenges as compared to HTML delivery, with stricter QoS
requirements, such as maximum delay and constant/variable bit-rate.
When the transport technologies employed within the network core are
best-effort delivery in nature, it is very difficult to guaranteed
the required quality of service. Thus, to maintain the perceived QoS
by the user, it is often necessary to dynamically adapt the AV
stream to the fluctuating network connection conditions [6].
Ideally such adaptation services should be placed near the end-user,
so as to reduce the errors in estimating the network conditions at
the network edge. This also allows for intermediary to cache the AV
contents, and directing the contents to the adaptation service
depending on the QoS requirements and channel conditions.
Ng, Tan, Cheng Expires January 2002 [Page 3]
INTERNET-DRAFT QoS Extension to IRML July 2001
The use of OPES intermediaries to adapt the AV contents requires
that the QoS parameters, such as allocated/requested bandwidth and
channel conditions, be made available to the rule decision engine.
2.3. QoS Policy Control
Often, the OPES services will reside on an intermediary box that is
provided by the access provider. Thus one major application of the
IRML is to implement policy rules based on the Service Level
Agreement (SLA) between the access provider and the end-user. QoS is
one important aspect of SLA.
To illustrate, consider the following scenario where an end-user has
a service policy of 64kbps bandwidth. Suppose the end-user is in
the middle of watching a movie at 56kbps when a 16kbps voice-over-IP
(VoIP) stream arrives. Instead of simply rejecting the VoIP
connection, with IRML services, the access provider (or even the
end-user) can now specify policy rules to perform any of following
more desirable actions:
(a) adapts the VoIP stream to the remaining bandwidth,
(b) adapts the movie stream to give room for the VoIP stream (e.g.
mute the audio from the movie), or
(c) adapts both the movie and VoIP streams.
2.4. Load-Balancing
The OPES framework in [3] allows for the adaptation services to be
performed remotely on a separate, dedicated server, such as an ICAP
server. This allows for scalability. However, when the number of
connections is small, it might not be desirable to perform remote
callout, as the overhead incurred will add transmission delays. IRML
can be employed to redirect content adaptation to a remote server
when the load on the intermediary is high, and to use a local
proxylet when the load is low. Such decision can only be done if
IRML is extended to environment properties, such as server load.
In addition to serverÆs processing load, such decision may based on
the end-userÆs QoS requirement as well. For instance, when the
server load is moderate, it might process adaptation services for
end-users with stricter QoS requirements, and invoke remote
adaptation services for end-users with lower QoS requirements.
3. Requirements for QoS Extension
In consideration to the example services illustrated in the previous
sections, a preliminary set of requirements for the QoS extension to
the IRML can be outlined as follow:
Ng, Tan, Cheng Expires January 2002 [Page 4]
INTERNET-DRAFT QoS Extension to IRML July 2001
- It SHOULD enable rule modules to match the end-user QoS policy
requirements against pre-defined labels. Such QoS policy
requirements MAY include, but not limited to, the allocated
bandwidth to the end-user, the requested bandwidth for the
current connection, and the required delay bound, if any.
- It SHOULD enable rule modules to match the transmission
statistics of the end-user connection with the intermediary
against pre-defined labels.
- It SHOULD enable rule modules to match the current system load of
the intermediary against pre-defined labels. The system load MAY
be inferred from percentage load, and/or the number of
connections the intermediary is handling.
The above set of requirements is not exhaustive. Further research
work needs to be carried out to evaluate the applicability of these
requirements, and append additional requirements if deem
appropriate.
4. Proposal to IRML Extensions
In order to extend QoS-aware services in the OPES intermediary, it
is proposed that the recognized property names of the "property"
element in IRML be extended to include various QoS-related
properties. These will be described in the following sub-sections.
4.1. QoS Policy Properties
The following are the proposed QoS policy parameters to be extended
to the "property" element. These values are access control
parameters, thus the rule engine can obtain their values via an
interface to an access control module. Specification of such
interface/module is out of scope.
Property Name Value
--------------------------------------------------------------------
"allocated-bandwidth" the allocated bandwidth for the end-user
"requested-bandwidth" the requested bandwidth for this connection
"available-bandwidth" the amount of bandwidth available for the
end-user
"delay-bound" the maximum delay requested
4.2. Network Status Properties
The following are the proposed network status parameters to be
extended to the "property" element. These dynamic values reflect the
current network link status. The rule engine can obtain these values
either via an interface to a traffic monitoring module, or in the
Ng, Tan, Cheng Expires January 2002 [Page 5]
INTERNET-DRAFT QoS Extension to IRML July 2001
case of RTP connections, from the RTCP sender/receiver reports [7].
Specification of such interface/module is out of scope.
Property Name Value
--------------------------------------------------------------------
"r-octets-count" the accumulated number of octets received
by the end-user
"s-octets-count" the accumulated number of octets received
by the intermediary
"r-packets-count" the accumulated number of packets received
by the end-user
"s-packets-count" the accumulated number of packets received
by the intermediary
"r-packets-lost" the total number of packets not received by
the end-user
"s-packets-lost" the total number of packets not received by
the intermediary
"r-fraction-lost" the fraction of packets lost reported by
the end-user since the previous report
"s-fraction-lost" the fraction of packets lost reported by
the intermediary since the previous report
"r-jitter" the inter-arrival jitter reported by the
end-user
"s-jitter" the inter-arrival jitter reported by the
intermediary
Because the rule engine should be stateless, it might be necessary
for the module providing the values of the QoS parameters to provide
additional information about the difference in the parameters values
after a specific interval.
Property Name Value
--------------------------------------------------------------------
"r-octets-diff" the difference in accumulated number of
octets received by the end-user of two most
recent consecutive reports
"s-octets-diff" the difference in the accumulated number of
octets received by the intermediary of two
most recent consecutive reports
"r-packets-diff" the difference in the accumulated number of
packets received by the end-user of two
most recent consecutive reports
"s-packets-diff" the difference in the accumulated number of
packets received by the intermediary of two
most recent consecutive reports
"r-packets-lost-diff" the difference in the total number of
packets not received by the end-user of two
most recent consecutive reports
"s-packets-lost-diff" the difference in the total number of
packets not received by the intermediary of
two most recent consecutive reports
Ng, Tan, Cheng Expires January 2002 [Page 6]
INTERNET-DRAFT QoS Extension to IRML July 2001
4.3. Intermediary Load Properties
The following are the proposed server load parameters to be extended
to the "property" element, in addition to the existing "system-time"
and "system-date" definitions. These values are system environment
parameters, thus the rule engine can obtain their values via an
interface to a system module. Specification of such an interface/
module is out of scope.
Property Name Value
--------------------------------------------------------------------
"system-processing-load" the current processing load in percentage
of the intermediary
"system-connections" the current number of established end-
user connections
5. Examples
The first example below illustrates the case where a HTML page is
adapted to suit the allocated bandwidth of the client. Here, we
assume that there is a sub-system to check the allocated bandwidth
and classify it to a relevant tag of "low", "medium", or "high".
checkBandwidth
proxylet://localhost/html2wml?target=tiny
proxylet://localhost/html2wml?target=small
proxylet://localhost/html2wml?target=large
The second example illustrates the scenario where an adaptation
service is carried out in locally or remotely based on the system
processor load. It also illustrates the adaptations of video stream
based on the connection status. This examples assumes that there is
sub-system to classify the system load and receiver fraction lost
report to an appropriate tag of "low", "mediumö, or "high".
Ng, Tan, Cheng Expires January 2002 [Page 7]
INTERNET-DRAFT QoS Extension to IRML July 2001
checkSystemLoad
checkConnectionStatus
icap://video.adpat.server/video-adpat
proxylet://localhost/video-adpat
The third example shows the adaptation of different content format
for different traffic conditions gathered from the network
monitoring module for a specific network node or a group of network
nodes in delivering Audio-Visual content. Access to the types of
content format is based on the different network conditions supplied
by the network monitoring module. The rule for accessing the type of
content format is being specified based on the type of property
used.
checkBandwidth
proxylet://stillimage.server/jpeg-only
proxylet://content.server/resume
proxlet://videoFEC.correct.server/video-FEC
Ng, Tan, Cheng Expires January 2002 [Page 8]
INTERNET-DRAFT QoS Extension to IRML July 2001
6. References
[1] Bradner, S., "The Internet Standard Process û Revision 3", BCP 9,
RFC 2026, October 1996.
[2] Beck, A., Hoffman, M., "IRML: A Rule Specification Language for
Intermediary Services", Work In Progress, draft-beck-opes-irml-
00.txt, February 2001.
[3] Tomlinson, G., Orman, H., Condry, M., Kempf, J., "Extensible Proxy
Services Framework", Work In Progress, draft-tomlinson-epsfw-
00.txt, 2000.
[4] Beck, A., Hoffman, M., Condry, M., "Example Services for Network
Edge Proxies", Work In Progress, draft-beck-opes-esfnep-01.txt,
November 2000.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Wu., D., Hou, Y. T., Zhang, Y., "Scalable Video Coding and
Transport over Broad-band Wireless Networks", Proc. IEEE, vol. 89,
no. 1, pg 6-20, Jan 2001.
[7] Schulzrine, H., Casner, S., Frederick, R., Jabcobson, V., "RTP: A
Transport Protocol for Real-Time Applications", RFC 1889, January
1996.
7. Author's Address
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Send Ave #04-3530
Tai Seng Industrial Estate
Singapore 534415
Phone: (+65) 381 5420
Email: cwng@psl.com.sg
PekûYew TAN
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Send Ave #04-3530
Tai Seng Industrial Estate
Singapore 534415
Phone: (+65) 381 5470
Email: pytan@psl.com.sg
Hong CHENG
Panasonic Singapore Laboratories Pte Ltd
Ng, Tan, Cheng Expires January 2002 [Page 9]
INTERNET-DRAFT QoS Extension to IRML July 2001
Blk 1022 Tai Send Ave #04-3530
Tai Seng Industrial Estate
Singapore 534415
Phone: (+65) 381 5477
Email: hcheng@psl.com.sg
Ng, Tan, Cheng Expires January 2002 [Page 10]