One document matched: draft-dieder-diffserv-phb-efd-00.txt
Network Working Group J. Diederich
Internet-Draft M. Zitterbart
Expires: April 14, 2000 Technical University Braunschweig
October 15, 1999
An Expedited Forwarding with Dropping PHB
draft-dieder-diffserv-phb-efd-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
This Internet-Draft will expire on April 14, 2000.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document defines a new per-hop behavior (PHB) for
Differentiated Services, the so-called 'Expedited Forwarding with
Dropping' PHB. Packets marked for this PHB are forwarded with the
same low-delay, low-jitter characteristics as packets marked with
the Expedited Forwarding PHB, but may experience a certain
probability of packet loss. This PHB is especially suited to provide
low-delay services in cellular wireless networks.
Note from the authors
This document is in an early stage and may not conform to all
requirements on defining per-hop behaviors as specified in [RFC2474]
and [RFC2475]. Furthermore, it describes the concepts of the PHB
only. A simulative evaluation is under way.
Diederich & Zitterbart Expires April 14, 2000 [Page 1]
Internet-Draft Expedited Forwarding with Dropping October 1999
1. Overview and motivation
In Differentiated Services (DiffServ) [RFC2474] [RFC2475], the
Expedited Forwarding (EF) PHB [RFC2598] can be used to provide a
low-latency, low-jitter, assured bandwidth end-to-end service, the
so-called Premium service [RFC2638]. This service appears to the
endpoints like a 'virtual leased line'. Such a line may not always
be in use to 100 percent so that traffic belonging to other PHBs can
utilize unused resources (cf. section 2.2 in [RFC2638]).
1.1 Problem Description
Currently, Assured Forwarding [RFC2597] traffic or Best Effort
traffic may utilize unused EF resources. In both kinds of traffic,
burstiness is allowed which can lead to large queues under heavy
load situations. Therefore, packets from both may have already
experienced delay in upstream DiffServ nodes or might experience
delay later in downstream nodes. Thus, traffic from these services
can not substantially benefit from the 'low-latency advantage' of
utilizing unused EF resources.
1.2 A new per-hop behavior
This document describes a new per-hop behavior called 'Expedited
Forwarding with Dropping' (EFD). In general, packets marked for this
PHB experience a low delay and a low jitter but can be dropped with
a certain probability. Furthermore, EFD packet utilize unused EF
resources. The EFD PHB can be used together with traffic
conditioning actions at the DiffServ domain's boundary to create a
so-called Best-Effort Low-Delay (BELD) service. It has the same
low-latency, low-jitter characteristics as Premium service but gives
an assured probability of packet loss and, thus, a loose assurance
on the amount of bandwidth granted. This service can be used by
real-time applications which require low-delay packet delivery but
can tolerate packet loss or adapt to bandwidth variations up to a
certain threshold.
1.3 Example: Low delay service for mobile terminals
In a cellular wireless network, two additional issues have to be
considered when providing a low-delay fixed bit-rate service similar
to Premium service: Mobility of the terminals and the special
characteristics of the radio channel, such as a higher bit error
rate (cf. Appendix B for more details).
1. When a mobile terminal moves into a highly loaded area, the
negotiated Premium service peak rate may not be available
anymore. Since the Premium Service peak rate should be available
with a high assurance as soon as the customer demands it, this
case should occur only rarely. One proposal is to reserve a
Diederich & Zitterbart Expires April 14, 2000 [Page 2]
Internet-Draft Expedited Forwarding with Dropping October 1999
fraction of the Premium service bandwidth for handover purposes
only. However, this increases the amount of unused Premium
service resources compared to wired networks.
2. Due to the higher bit error rate on the radio channel, a certain
amount of bandwidth on the radio link is used for error
protection methods such as Forward Error Correction (FEC) or
Automatic Repeat Request (ARQ). To assure the negotiated peak
rate on the radio channel, a fraction of Premium service radio
channel resources must be reserved for error protection methods.
Otherwise, the negotiated peak rate will not be available under
bad radio channel conditions with a high bit error rate.
However, the average amount of bandwidth necessary for error
protection will be below this fraction leading to unused Premium
service resources.
In summary, a higher fraction of Premium service resources may be
unused when introducing EF-based low-delay services into a cellular
wireless network. A further issue is that real-time applications on
mobile hosts should deal with packet loss, anyway, e.g., due to
short disruptions because of radio shadows. Thus, a service with
low-delay and an assured drop rate is especially suited for cellular
wireless networks. Since such a service can neither be provided with
the EF PHB nor with the AF PHB (cf. Appendix B.5), another PHB such
as the EFD PHB is necessary for this purpose.
This document describes the EFD PHB. An otherwise DiffServ-compliant
node is not required to implement this PHB in order to be considered
DiffServ-compliant, but when a DiffServ-compliant node is said to
implement the EFD PHB, it must conform to the specification in this
document.
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 [RFC2119].
2. Description of the EFD per-hop behavior
EFD packets utilize unused EF resources. Therefore, a DiffServ node
implementing the EFD PHB MUST implement the EF PHB according to
[RFC2598].
There are the following requirements on the behavior of an EFD
compatible DiffServ node:
o The maximum delay a single EFD packet experiences in a DiffServ
node MUST NOT be greater than the maximum delay an EF packet may
experience. No such requirement exists for the average delay a
single EFD packet experiences.
o The maximum delay a single EF packet experiences in a DiffServ
node MUST NOT be larger than without any EFD packets. If an EF
Diederich & Zitterbart Expires April 14, 2000 [Page 3]
Internet-Draft Expedited Forwarding with Dropping October 1999
packet arrives and there are not sufficient resources available
for the incoming EF packet, EFD packets MUST release sufficient
EF resources immediately so that the EF packet does not
experience a higher dropping probability as if there would be no
EFD packets.
o EFD packets MUST NOT be preferentially forwarded compared to EF
packets. EF packets MAY be preferentially forwarded compared to
EFD packets as long as the maximum delay requirement is not
violated. In general, both SHOULD experience the same forwarding
behavior except for the higher dropping probability of EFD
packets.
3. Recommended Codepoint
To be assigned.
4. Mutability
Packets marked for the EFD PHB MAY be remarked at a DiffServ
boundary to other codepoints that satisfy the EFD PHB. Packets
marked for the EFD PHB MAY be promoted to the EF PHB by a DiffServ
domain but SHOULD NOT be demoted or promoted to another PHB.
5. Tunneling
When EFD packets are tunneled, the tunneling packets must be marked
as EFD or EF to keep the low-delay characteristic.
6. Interaction with other PHBs
The EFD PHB can only be implemented in connection with the EF PHB.
Thus, both build a so-called PHB group, providing a low-delay
forwarding with two drop precedences: almost no probability of
dropping a packet for the EF PHB and a certain drop probability for
the EFD PHB depending on the traffic conditioning actions belonging
to the service build with the EFD PHB.
6.1 Impact of EFD traffic on EF traffic
Due to the introduction of EFD packets, the utilization of EF buffer
resources will be higher than with EF packets only. Thus, the
average delay of EF packets increases.
However, the maximum delay bound as described in Appendix A is not
influenced. It still can be guaranteed for both, EF packets and EFD
packets since the amount of EF buffering resources is independent
from the EFD PHB implementation. For a single EF packet, there is no
difference with regard to maximum delay if other EF packets or EFD
packets utilize the EF resources as long as the buffer size remains
Diederich & Zitterbart Expires April 14, 2000 [Page 4]
Internet-Draft Expedited Forwarding with Dropping October 1999
the same.
Furthermore, the introduction of large EFD packets compared to small
EF packets may lead to a larger jitter within EF traffic. This
impact depends on the implementation of the scheduling for the EFD
PHB (Section 7.3) and can be smoothened by means of traffic
conditioning Appendix B.5.
6.2 Impact of EFD traffic on AF traffic
Since EFD packets utilized EF resources only, the impact of EFD
packets on AF is the same as if EF packets would use the EF
resources. As the EF's share of the total bandwidth on a link will
be rather low, this impact should be negligible.
7. Example mechanisms to implement the EFD PHB
It is assumed that the queueing mechanisms as described in [RFC2598]
(e.g., strict priority queuing, Weighted Fair queuing) ensure that
EF / EFD packets are treated preferentially compared to packets
belonging to other PHBs. In this section, we only consider
scheduling or queueing issues related to the internal handling of
the EF / EFD buffer.
7.1 EFD packet arrival
An example implementation of the EFD PHB might process EFD packets
as follows:
o If the output link is idle and there are no EF packets to sent,
forward the EFD packet immediately.
o If the output link is not idle, store the incoming EFD in the EF
buffer as long as there is sufficient buffer capacity.
o If there is insufficient space to store the incoming EFD packet
in the EF buffer, it is dropped. Remarking instead of dropping is
not envisioned since it would lead to the possibility of packet
reordering.
7.2 EF packet arrival
If an EF packet arrives, the following new situation has to be
considered. There is insufficient space in the EF buffer to store
the incoming EF packet but there are EFD packets within the buffer.
In this case, EFD packets must be removed from the buffer so that
the EF packet can be stored. Depending on the buffer implementation,
a handling of free buffer space fragmentation must be considered,
for example, if EFD packets are smaller than EF packets.
Diederich & Zitterbart Expires April 14, 2000 [Page 5]
Internet-Draft Expedited Forwarding with Dropping October 1999
7.3 Scheduling strategies
Since the introduction of EFD packets leads to a higher utilization
of EF buffers, the scheduling strategies within the EF buffer have
an influence on the impact of EFD packets on EF packets. For
example, the impact of large EFD packets on small EF packets may be
lessened using separate queues for both with a common bounded size
and Weighted Fair Queueing (WFQ).
8. Security considerations
Since the EFD PHB has no own resources assigned but uses EF
resources instead, the same security considerations have to be made
as for the EF PHB except for one change: Dropping EFD packets is a
fundamental behavior of this PHB. Thus, these drops MAY be noted but
they definitely cannot be used to identify security attacks.
References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. L. Black,
"Definition of the Differentiated Services Field (DS}
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2475] Blake, S., Black, D.L., Carlson, M. A., Davies, E., Wang,
Z. and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2638] Nichols, K., Jacobson, V. and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
RFC 2638, July 1999.
[QBone] Teitelbaum, B., "QBone Architecture (v1.0)", Internet2 QoS
Working Group Draft, August 1999. Work in progress.
Diederich & Zitterbart Expires April 14, 2000 [Page 6]
Internet-Draft Expedited Forwarding with Dropping October 1999
Authors' Addresses
Joerg Diederich
Technical University Braunschweig
Bueltenweg 74/75
D-38106 Braunschweig
Germany
Phone: +49 531 391 3265
Fax: +49 531 391 5936
EMail: dieder@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/~dieder
Martina Zitterbart
Technical University Braunschweig
Bueltenweg 74/75
D-38106 Braunschweig
Germany
Phone: +49 531 391 3288
Fax: +49 531 391 5936
EMail: zitterbart@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/~zit
Appendix A. Buffer size and maximum delay in Expedited Forwarding
In EF, generally only very small queues are necessary as traffic
conditioning has to ensure that the arrival rate of the EF aggregate
is always less than the departure rate. However, the following worst
case scenario has to be considered [QBone].
o The output link is currently busy due to the transmission of a
packet of another PHB.
o MTU-sized EF packets arrive synchronized on all incoming links.
The size of the EF buffer for each output link must accommodate to
this worst case, since it is no traffic conditioning issue.
Therefore, the EF buffer must be able to store one MTU-sized EF
packet per incoming interface. Thus, the minimal EF buffer size for
each outgoing link is the sum of the MTUs of each incoming interface.
The maximum delay an EF packet experiences in a single DiffServ node
results from this buffer size and the bandwidth of the outgoing
link. For example, if a node has 10 incoming interfaces all with the
same MTU of 1500 Bytes and the EF bandwidth of the outgoing link is
15 MBit/s, the maximum delay for an MTU sized EF packet is: (10 *
1500 Bytes) / 15 MBit/s = 8 ms.
Diederich & Zitterbart Expires April 14, 2000 [Page 7]
Internet-Draft Expedited Forwarding with Dropping October 1999
Appendix B. Low-delay services in wireless cellular networks using
DiffServ
Before introducing Differentiated Services in wireless cellular
networks, the special characteristics of wireless and mobile
communication have to be carefully evaluated. This section discusses
some selected issues.
B.1 Characteristics of wireless communication
In wireless communication, there is a higher bit-error rate on the
radio channel (e.g., due to channel interference, fading, etc.). In
most cellular systems, error protection methods on the radio link
try to accommodate to high bit-errors rate. Two groups of methods
are currently in use: Forward Error Correction (FEC) methods and
Automatic Repeat Request (ARQ) methods. Both need additional radio
link capacity (the former for redundancy, the latter for
retransmissions).
B.2 Characteristics of mobile communication
When providing quality of service in cellular networks, special
attention has to be paid to handover between different cells: Routes
to or from mobile hosts within the wireless network may change
during a single communication session. Thus, also the amount of
available resources may change, for example when a mobile host moves
into a heavily loaded cell. In this case, even a blocking of the
communication session (called handover blocking) cannot be
completely avoided.
B.3 Analysis of Premium service
Premium service is a low-delay service currently discussed in the
context of Differentiated Services. It is specified by means of a
peak-rate and this rate is expected to be available as soon as data
from the customer is sent.
When providing a service most similar to Premium service in wireless
networks, one problem arises from mobility: When a mobile hosts
moves into a neighbored cell, there may not be sufficient bandwidth
available to support the same service as in the previous cell (we do
not consider pre-reservations in other cells because we do not think
that a movement can be predicted in general). Since the users within
the cell should not experience unlimited QoS degradation, admission
control may deny the handover request in the worst case.
Furthermore, dimensioning the necessary amount of radio channel
resources to achieve the negotiated user peak rate is rather
difficult. To accommodate to bit errors, error protection methods
Diederich & Zitterbart Expires April 14, 2000 [Page 8]
Internet-Draft Expedited Forwarding with Dropping October 1999
are widely used. The amount of radio channel resources for error
protections depends on the radio channel characteristics. To provide
the peak rate even under high bit error rates, the reserved amount
of radio channel resources must be chosen according to the strongest
necessary error protection. In situations with an average bit error
rate, the error protection can be weaker so that it needs less radio
channel resources. Thus, unused reserved resources can be utilized
by packets belonging to other services.
As connectivity throughout the whole communication session is the
most important QoS parameter, the current low-delay, low-jitter,
assured bandwidth Premium Service can be provided to mobile users
only when a high fraction of Premium service resources are reserved
for handover purposes, or bad channel characteristics etc. Thus,
only few users may be able to get such a service.
B.4 Proposals for mobile low-delay services
We propose three different low-delay services for cellular wireless
networks:
o Premium service
o Mobile Premium service
o Best-Effort low-delay service
Premium service [RFC2638] may be provided to wireless attached hosts
which do not perform handover during an ongoing communication
session (called portable hosts). However, due to a possible higher
bit error rate of the radio channel, the bandwidth assurance may not
be as strict as in wired networks and the delay may be higher
(higher propagation delay due to a lower bit rate as in fixed
networks).
Mobile Premium service is defined as a low-delay, low-jitter service
such as Premium service. However, the assurance on the amount of
bandwidth is bipartite: Without handover, a mobile terminal will
keep its assigned bandwidth as described in the previous paragraph
on Premium service. With handover, the amount of bandwidth, assigned
in the old cell, will be available in the new cell with a certain
probability only which depends on the amount of bandwidth reserved
for handover purposes as well as on other handover activities. Thus,
for the handover blocking rate, only a statistical guarantee can be
issued. In this way, a change in the quality of Mobile Premium
service is always caused by movements of the mobile terminal itself,
but not due to mobility of other mobile hosts: If the mobile
terminal does not move out of the cell, it will keep its assigned
bandwidth. If it moves into another cell, it might experience
handover blocking.
Best-Effort low-delay (BELD) service has the same low-delay,
Diederich & Zitterbart Expires April 14, 2000 [Page 9]
Internet-Draft Expedited Forwarding with Dropping October 1999
low-jitter, assured handover blocking rate characteristic as Mobile
Premium service and additionally a certain probability of packet
drop. Thus, the bandwidth assurance is less tight as for Mobile
Premium service or Premium service. In contrast to Mobile Premium
service, the quality of the BELD service depends on both, the
mobility of the service owner itself and on the mobility of other
Mobile Premium service / BELD service owners: The assigned bandwidth
may change even if the mobile terminal does not move at all.
Real-time Applications using these three services must be prepared
to deal with occasional packet loss or short disruptions due to the
radio channel characteristics. Differences between these services
exist in the statistical drop rate (and thus the assured bandwidth),
which is lowest for Premium service and highest for BELD service.
Example applications may be for Premium service a high-end IP
telephony (no handover support), for Mobile Premium service a
high-end mobile IP telephony, and a low-cost mobile IP telephony for
the BELD service. This last application may use coders, which can
adapt to a varying amount of bandwidth by adapting the speech
quality whereas the users of such an application accept the varying
speech quality due to a lower price compared to the high-end Mobile
Premium service.
B.5 Possible Implementations of the proposed services
Premium service for portable hosts may be implemented with the EF
PHB in internal nodes and a more conservative admission control as
in wired networks. This admission control accommodates to the
varying bit error rates on the radio link by reserving a fraction of
bandwidth for error protection in case that a higher bit error rate
enforces a strong error protection.
Mobile Premium service may be implemented with the EF PHB, as well,
and a much more conservative admission control as for Premium
service: A certain fraction of bandwidth may be reserved for
handover purposes only so that new potential Premium service /
Mobile Premium service users will be blocked early.
The Best-Effort Low Delay (BELD) Service cannot be constructed from
existing PHBs: The AF PHB allows queueing to accommodate to bursty
traffic, leading to a higher delay. The EF PHB states in the
security consideration section that packet loss due to overflow of
the EF queue should never occur and should be noted as possible
attacks or serious misconfiguration. For BELD service, packet loss
is an inherent feature for applications which can tolerate it.
Therefore, the EF PHB can not be used for building a BELD service,
as well.
Thus, BELD service is constructed from the EFD PHB and the following
Diederich & Zitterbart Expires April 14, 2000 [Page 10]
Internet-Draft Expedited Forwarding with Dropping October 1999
traffic conditioning at the DiffServ domain's boundary: The traffic
conditioning must make sure that the given loose bandwidth assurance
is met by restricting the amount of EFD traffic injected into the
DiffServ domain. In this way, packet loss of EFD traffic should be
kept under control. EF resources which are not used by EFD packets,
may be utilized by packets marked for AF or Best-Effort. Traffic
conditioning may also take actions to lessen the impact of large EFD
packets on small EF packets. For example, it can simply deny long
EFD packets or perform packet fragmentation.
B.6 Deployment of DiffServ in mobile environments
To gain experience with the bandwidth assurance, a service provider
can give for a certain DiffServ domain, the amount of EFD traffic
injected into this domain should be increased slowly while watching
the loss rate of the EFD traffic. The loss rate will depend on
several factors like the current traffic pattern of EF traffic, and,
thus, the time of day or the day of the week.
The EFD PHB and the EF PHB can be deployed in three variants: EF
only, EFD only, and both coexisting. The first case describes the
current DiffServ with AF / Best-Effort traffic utilizing unused EF
resources. In the second case, EF traffic is generally not injected
into the DiffServ domain, so that EFD traffic can utilize most of
the common EF resources. This may be the case for wireless networks,
where the network provider does not want to offer Premium Service or
Mobile Premium service. The third case describes a coexistence
between EF traffic and EFD traffic. For the specification of the EFD
PHB, this last case has been given most attention.
Diederich & Zitterbart Expires April 14, 2000 [Page 11]
Internet-Draft Expedited Forwarding with Dropping October 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Diederich & Zitterbart Expires April 14, 2000 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 10:21:11 |