A Generic Traffic Conditioning Model for Differentiated Services, httpcc.gatech.edu tjiangg

A Generic Traf?c Conditioning Model for

Differentiated Services

Longsong Lin Tianji Jiang Jeffrey Lo

MMC Networks,Inc College of Computing C&C Research Lab.,NEC USA 1134E.Arques Ave.Georgia Institute of Technology System Architecture Department Sunnyvale,CA94086Atlanta,GA30332110Rio Robles.San Jose,CA95134 llin@https://www.wendangku.net/doc/2f9631610.html, tjiang@https://www.wendangku.net/doc/2f9631610.html, jlo@https://www.wendangku.net/doc/2f9631610.html,

Abstract—

Differentiated service(Diffserv)is a set of technologies used to enable the provisioning of class-based,differentiated quality of service.One of the essential building blocks to realize Diffserv is the use of traf?c conditioning mechanisms to support the required forwarding behavior.In this paper, a generic model for traf?c conditioning is proposed.The generic traf?c conditioner(GTC)can be used to provide the traf?c control functional-ity required in support of various de?ned per-hop forwarding behaviors. To demonstrate this capability,a con?guration of GTC for an expedited forwarding that guarantees low packet loss,delay and jitter bounds is pre-sented.Analysis of per-hop delay and jitter due to conditioning traf?c is presented and buffer requirements for GTC and interface are also derived. The GTC is currently implemented in Linux platform.Experimental results have shown that the GTC can achieve minimal packet loss with bounded jitter and delay.

Keywords—Quality-of-Service Network,Differentiated services,Traf?c Conditioning

I.I NTRODUCTION

Motivated by rapid change of requirements in network appli-cations,the Internet has been evolving towards providing wide variety of services to meet the qualities of information delivery demanded by the applications.For the past few years,there have been two major efforts focused on augmenting the single-class, best effort Internet to include different levels of guarantee in ser-vice quality-Integrated service(Intserv)[1]and Differentiated service(Diffserv)[2][3].

The most salient difference between these two approaches lies in the treatment of the packet streams.Inteserv tends to emulate circuit-switch networks,focusing on guaranteeing QoS on individual packet?ows between communication end-points. To ensure the level of guarantee on a per-?ow basis,it requires explicit signaling to reserve corresponding resources along the path between these end-points.One protocol called Resource Reservation Protocol(RSVP)[4]serves for this purpose to setup the states at each node along a path.One of the major dilemmas faced by this approach is that in the core of the Internet where several millions of?ows are usual per se,it may not be feasible to maintain and control the forwarding states ef?ciently.These scalability and management problems are addressed lately by Diffserv approach.Instead of on per-?ow basis,Diffserv aims at treatments on an aggregate of?ows,a set of micro-?ows with similar service requirements.By limiting the number of classes of services,it is anticipated that this approach scales This work was done when Tianji Jiang worked as a summer intern in the NEC C&C Research Labs,San Jose,CA in summer1999.At that time,Dr.Longsong Lin was also with the NEC C&C Research Labs,San Jose,CA well in backbone nodes and requires no setup signaling and state maintenance.Nevertheless,the loss of per-?ow states and granularity due to aggregation may results in more diverse and coarse level of assurance on quality.

Despite of the discrepancy in the facet of service deployment, both approaches employ a common set of mechanisms to realize the services.First,a classi?er is used to categorize packets into a micro-?ow(Intserv)or an aggregate class(Diffserv).This classi?er implements an ordered set of?lters that are used to distribute an incoming packet into one of the classes.Packets pertaining to a class are buffered at a speci?c queue to be sched-uled for transmission.In general,an egress interface could be equipped with several such queues that share the bandwidth of the link.A queue discipline is used to undertake the role of apportioning the link bandwidth according to the requirement of each class.

The crux of Diffserv model lies in differentiation of micro-?ows at boundary of a DS-domain and aggregation of micro-?ows of the same service class at core of the DS-domain.At each ingress interface of a boundary node in a DS domain,the traf?c is passed to a Multi-Field Classi?er(MFC)which may classi?es the packet based on5-tuples of the IP header,MAC addresses,VLAN identi?ers,link-layer traf?c classes or other higher layer protocol addresses.After the class of a?ow is identi?ed,each packet belonging to the same class will be con-ditioned by a traf?c conditioning(TC)block according to the TCS and TP.Leaving the boundary node,each packet is marked with a Diffserv codepoint(DSCP).Thereafter,a Behavior Ag-gregate Classi?er(BAC)in each interior node of a DS domain will classify the packets based only on the DSCP.At each egress interface of a DS node,a scheduling discipline that enforces the PHB for the behavior aggregate dispatches the packets among a set of inter-dependent queues.In the sense,PHB is a means by which a node allocates resources to behavior aggregates,and it is on top of this basic hop-by-hop resource allocation mechanism that useful differentiated services may be constructed.PHBs are implemented in nodes by means of some buffer management and packet scheduling mechanisms and the parameters associ-ated with the mechanisms are closely related to those of traf?c conditioning.

A general architecture of a Diffserv node is depicted in Fig-ure1showing that packet classi?cation and traf?c conditioning are performed at the ingress interface before the forwarding en-gine while queuing discipline and possibly classi?cation and

traf?c conditioning are performed at egress interface after route lookups.The picture enumerates different classi?ers,which in-clude,to support multiple customers per interface,a combination of a MFC and a BAC to distinguish traf?c based on customer as well as service level.For a DS interior node,there might not need conditioning before the forwarding process and packets with DS bytes set are passed to the BA classi?er of a outgoing interface directly.

Fig.1.A general architecture of a Diffserv node

Diffserv to date has offered three groups of PHB:Class Selec-tor(CS),Expedited Forwarding(EF)and Assured Forwarding (AF)[5][6][7].Without per-?ow states in the backbone nodes and with optional signaling protocol for admission control,EF PHB promises to deliver a"virtual lease line(VLL)"-like end-to-end service with a low loss,low latency,low jitter,assured bandwidth through DS domains.AF PHB group provides assur-ance of quality according to the relative ordering between classes, rather than absolute service level for each class.Class Selctor PHBs subsumes the Precedence bits of the IP packet header to codepoints in order to preserve the backward compatibility with most of the deployed forwarding treatments selected by the IP Precedence?eld.For different PHBs,there are different con-straints and requirements that must be ful?lled;hence,it often requires the supports of certain traf?c conditioning functions. For example,to realize EF PHB,it is desirable to con?gure the PHB mechanisms to guarantee a speci?ed rate for an aggregate and condition the aggregate so that its arrival rate at any node is always less than that node’s con?gured minimum departure rate. The main theme of this paper is to investigate the traf?c con-ditioning components and then propose a generic type of traf?c conditioning block called generic traf?c conditioner(GTC)to support the standard PHBs..There have been many traf?c me-ters proposed for speci?c standard PHB[8][9][10].Our goal is to propose a single traf?c conditioning architecture that can be con?gured to support the various PHBs.To show this ca-pability of the GTC,we will show how to con?gure the traf?c conditioning components to serve different PHBs.In particu-lar,we shall demonstrate,through analysis and evaluation,how the GTC can support the PHB to guarantee low delay,jitter and loss as de?ned in EF PHB.An example of application of such a PHB is on the type of applications in which packet delay and jitter are critical while loss can be amortized by certain encoding techniques.Such applications could use services provided by EF PHB or AF PHB group with the support of traf?c shaping and packet re-marking.In such case,we could target at mini-mizing the packet loss,given delay and jitter constraints.We will present the GTC algorithm,proofs of theoretical bounds for jitter and delay,and buffer requirement at interface.We will show the implementation of our design in Linux platforms and collect experimental data to validate our analytical results.

II.G ENERAL M ODEL FOR T RAFFIC C ONDITIONING

In general,a traf?c conditioner block may contain different combinations of meter,marker(re-marker),shaper,dropper,and policer.The proposed traf?c conditioner is generic in the sense that the components of its architecture can be enabled and con-?gured to support currently de?ned PHB groups.

The essence of the GTC architecture is that it embodies shap-ing and policing mechanisms that can be con?gured to meet the requirement of any PHB.As meter and marker are two common denominators for all the PHBs,they play passive role in a traf-?c conditioning block.A meter only gauge the characteristic of the traf?c,it should not change any nature of the traf?c.If there is any change made to the traf?c,it must be caused by the shaper.The marker in the GTC marks packet in accordance with the outcome of meter and policy components.Of course, the GTC can be con?gured to bypass the marking process if it is not necessary,which could occur when the packet is pre-marked by and submitted from a trusted party.In contrast,a shaper ac-tively recti?es the pattern of the traf?c,attempting to?t it to the committed traf?c pro?le.Hence,an out-of-pro?le packet can be re-shaped as in-pro?le packet only through a shaper,rather than meter or elsewhere.

A common practice of meter consists of a token bucket pa-rameterized by an average token generating rate and bucket size. Packets are stored in the buffer of an ingress interface before be-ing measured by the token bucket.The buffer in front of the token bucket actually acts as a shaping buffer as incoming packets will pass if the bucket has enough tokens,or queued otherwise,or dropped if the buffer is full.Hence the buffer and token bucket are tied together closely to function as meter and shaper.An ex-ample of such implementation can be found in[2]where a queue is enlisted in front of the meter and packets are buffered there before submitting them for measurement.However,the shaper could be a separate component from the meter and its realiza-tion is very much implementation dependent.In principle,the shaper processes only out-of-pro?le packets and outputs them in certain sequence by a sequencer for measurement later.Such a generalization is re?ected in the GTC architecture,as shown in

Figure2where a generic shaper outputs out-of-pro?le packets to meter for measurement depending on the policy.The interface queue buffers packets for measurement and packets over?owing the queue size will be dropped.The GTC also drops packets over?owing shaping buffer.In GTC,dropping could be a result of either policing or buffer over?ow.As a comparison,a simple FIFO queue in front of meter may drop over?owing packets and queues non-conformant packets,but can not support dropping due to shaping or policing.

Furthermore,the GTC contains a policing component in which various service policy can be realized.The policer determines the packet treatment depending on the service policy.It could possibly change the forwarding behavior of an out-of-pro?le packet by re-marking or just dropping the packet.For example, a policer can dispose an out-of-pro?le EF packet to AF PHB by re-marking the packet to one of the AF classes.It could also enforce,for example,a low-loss service policy by submit-ting the packet to a shaper,where the packet waiting for being re-measured as in-pro?le.The policing component is general enough to embrace different complexity of service policy.It is the most distinguishing building block that differs Diffserv from Intsev.Although both can enforce service policy in multi-?eld classi?er,Intserv could not enforce the policy to change the existing forwarding behavior of a packet.These two intrinsic features are manifested in Figure2.

(a)

(b)

Fig.2.A comparison of FIFO shaper and general shaper

It should be emphasized that a shaper usually delays the pack-ets in sync with the parameters set at the meter in order to regulate the packets to be in-pro?le.The delay along with shaping could be harmful to the overall performance of the traf?c.For exam-ple,for applications that requires particular bounds on low jitter, delay but tolerable low loss,a shaper should be designed with-out causing any violation of the bounds while trying to maintain low packet loss.Also,since shaping a packet will impede the newly incoming packets from being measured immediately,the buffer at ingress interface may get over?ow quickly.Further-more,when performing shaping,care should be taken as not to cause re-ordering of the original packet stream.This requires prioritizing the measurement order of the packets from shaping buffer over the newly incoming packets.The architecture of the generic traf?c conditioning block is depicted in Figure3.

Fig.3.The architecture of the generic traf?c conditioner.

A.The GTC Algorithm

Given a traf?c pro?le,GTC starts to operate as packets arrive at the meter and outputs marked packets from the maker.The meter picks up packets to measure?rst from the shaper and then from the input queue to GTC.The meter measures the packets and recognizes each of them as IN-pro?le(IN)or Out-of-Pro?le(OUT).The GTC uses a token bucket to measure packets.Tokens are generated in an average rate TR up to the bucket size TBS.An arrival of a packet triggers the measurement based on the current token bucket occupancy and the size of the arrival packet.Consequently,packet that is in-pro?le will be marked with corresponding DSCP in the marker.For out-of-pro?le packets,the policy determines whether they should be shaped,re-marked,or dropped depending on the service policy. If shaping is required,these packets are re-queued in a shaping buffer waiting for meter’s tokens.The shaping buffer can store up to SBS packets and packets over?owing the buffer occupancy will be discarded.The shaper is a simple FIFO queue that delays the out-of-pro?le packets for a certain time before submitting them to the meter.Although the shaper used in GTC is a simple FIFO,it does not preclude the use of other shaping mechanisms that schedule the sequence of submitting packets to the meter. It is also possible to enforce some drop preference in shaping buffer in case that the shaper needs to selectively drop packets to maintain the quality of packet in terms of delay and jitter.In that case,the drop preference could be assigned in the policer. If the policer decides to change the PHB of the packet,it noti?es the marker to re-mark the packet into other codepoint. Changing the PHB of a packet means either downgrading or upgrading the service class of the packet.However,changing codepoint does not necessarily mean to change a PHB.For EF PHB,packets may be re-marked at a DS boundary to only other codepoints that satisfy the EF PHB.This often occurs at the boundary between DS domains where different DSCPs have an equivalent PHB implementation.A DS boundary node may use a MF classi?er to identify a micro-?ow and con?gures a GTC with

a meter,policer,and shaper to regulate the packets of the?ow to be in-pro?le and mark them with a corresponding codepoint.A DS interior node may use a BA classi?er to identify an behavior aggregate.Then,the node can con?gure a GTC with a meter to measure its rate and a marker to re-mark the EF codepoint of the behavior aggregate to an PHB-equivalent codepoint.

Fig.4.Algorithm of the traf?c conditioner

The token bucket is initially(at time0)full,i.e.,the token bucket occupancy0,while the shaping buffer is initially empty,i.e.,the shaping buffer occupancy00. The is increased by bytes per unit time.Hence the total available token for the data stream at time is

,for0.

1,for0.

If,then.

The packets to be measured()by token bucket come from two sources:one from the input arrival at the traf?c condi-tioner()and the other from the feedback from the output of shaping buffer(),i.e.,

1.

If,then the total number of bytes in the packets that are in-pro?le()will be, and the total number of bytes in the packets that are out-of-pro?le()should satisfy

.Else,if,then all the packets are in-pro?le,i.e.and0.

The policer operates on each of the packets in turn.It decides how each packet is treated depending on the present oc-cupancy of the shaping buffer as well as service policy.Shaping can only be applied if not violating the speci?ed per-hop behav-ior.Otherwise,packets should be dropped.In the current imple-mentation of policy,a packet whose addition will over?ow the shaping buffer size should be dropped.If not dropped,the packet will be en-queued in the shaping buffer for later re-measurement or directly re-marked to a code-point corresponding to other classes of service,resulting in demoting or promoting to other PHBs.In this regard,re-marking as a result of policing may change the forwarding behavior of the packet.This may cause out of order delivery of the packet to the destination,if even only demoting is allowed when the codepoint changes.However,if packets are re-marked only to the codepoints of the same class as they were,e.g.,AF1x,and then forwarded to the PHB queue with respect to that class,then re-ordering will not occur.In the regard,re-marking changes the forwarding behavior by differ-entiating the preferences of packet treatment,for example,drop probability,in the PHB queue.Speci?cally,for a out-of-pro?le packet with length,

If,then

drop the packet,,

Else

shape the packet,,or

re-mark the packet,.

At any time instance,the token bucket is updated by

.Similarly,the shaping buffer is updated by1,where

is the result of subtracting the packet being re-marked and dropped from the packets in the time instance.That is,.In case that

,then discard the over?ow packets(OF)and

.Figure5shows a minimum con?guration for a policer in which the criterion for dropping a packet is when adding of the packet over?ows shaping buffer. The shaping buffer is managed under a minimum con?guration that the buffer should not be over?owed.It is possible to exer-cise more sophisticated methods of buffer management,such as RIO or RED to selectively drop packets.In that case,the policer should enforce the stamping of drop preference for each packet passing by.

III.D ELAY AND J ITTER A NALYSIS

In this section,we shall analyze the per-hop delay and jitterbe-havior due to the traf?c conditioning.Our goal is to appropriate parameters for each component in order to achieve the speci?ed PHB requirements.Then,we focus our discussion on provision-ing the EF PHB by allocating bandwidth in a DS-domain.We shall derive a necessary condition of bandwidth allocation for EF PHB.

A.Traf?c Conditioning Delay

A shaper that regulates non-conformant packets into confor-mant is the major factor causing delay and jitter of a packet.A meter ideally should not cause any delay of a packet;however, its size affects burst and delay jitter of a packet.In fact,the larger the size of a meter buffer,the greater the burst and jitter a packet may experience.For example,if the token bucket is set to the size of the largest possible IP packet(MTU)in a stream,

Fig.5.A minimum con?guration of policing and shaping components. the largest jitter a packet can expect is the size of shaping buffer

in packets times MTU.The situation could occur when a packet comes to the meter that has an empty bucket and the shaper is

full of packets of size MTU,including this out-of-pro?le packet. Double the bucket size will double the jitter.In words,the size of shaping buffer affects delay and jitter while the size of meter

bucket affects the burst and jitter.Hence,it is important to con-?gure the SBS and TBS according to the requirement of delay

and jitter for each node.

Assume that a packet of length()arrives to an interface device at time and at that time,the packet sees the

token bucket occupancy of in meter.Moreover,also assume the packet is fully received in the queue of an ingress

interface at time.If the line rate of the physical device is ,then the complete packet should be received in the interface buffer at time.If the number of tokens is less than at time,then by the time

If is not the time the packet can be measured,then up to the time

(1) which is at most

(2) where is the size of th packet and is the token bucket occupancy when the th packet is about to be measured by the meter.In the worst case where all the packets are of size equal to min(,)and token bucket occupancy is always empty,the maximum delay incurred by a packet due to traf?c conditioning is

min1

min

C.Determining Shaping Buffer Size(SBS)

Generally,according to the speci?cation of a traf?c aggregate, the average per-hop delay of a packet can be derived and it should be maintained within a certain bound.Suppose the bound is, then from Eq.(5),it should have

min1

and then we obtain the worst-case number of packets

that the shaper may contain without violating the delay bound requirement of any packet

min

min

min

We will deploy this SBS measure in the implementation dis-cussed later.

D.Per-hop Delay-Jitter and Token Bucket Size

In general,jitter,or variance of delay,that a packet can expe-rience in a node is constrained by the maximum delay the packet may encounter.Speci?cally per-hop jitter is de?ned as the dif-ference of per-hop delays between two consecutive packets of a stream.While end-to-end delay of a packet can be derived straightly from per-hop delay,end-to-end jitter of a packet is not just a summation of all per-hop jitters.In fact,the jitter of a packet at one node could be amortized at another node,resulting in a net jitter to be bounded.

For boundary node merging EF classes,the delay-jitter the node experience could be

(7)

where the allocation of bandwidth to the micro-?ow.The ?rst term accounts for the jitter incurred due to conditioning while the second term due to scheduling.From the equation, the jitter of a node increases as its share of bandwidth allocation decreases or the number of merging classes increases.

min

1min

(8)

The goal of conditioning traf?c to low jitter is to con?gure the token bucket size in such a way that packets output from

the traf?c conditioner are spaced uniformly in token bucket rate .Hence,by shaping,an aggregate in boundary node shall be shaped so as to minimize its jitter,but the jitters for individual

micro-?ows could be intensi?ed.Hence,each micro?ow may need be to further classi?ed and conditioned at the egress bound-ary node.For interior nodes,jitters can be reduced by increasing the line rate.

From the above equations,per-hop jitter of a packet is largely affected by the size of token bucket.In theory,larger token bucket size results in greater variance of delay.This is because of its allowance for multiple packets to go out of the meter as these packets arrive and see a full bucket.For example,one bucket with two-token bucket size()can output two packets at a time,while another with one-can output only one packet.The latter will space the incoming packet uniformly only if the token bucket is implemented in packet basis.Otherwise,if the bucket is implemented in bytes, which is the most often seen in practice,then it is possible that the outgoing traf?c pattern is the same as the incoming traf?c pattern.For instance,if a burst of four packets with one-quarter each arrives at the meter and sees a full bucket,these packets will go out in the same pattern as their input’s.After a certain amount of time,another burst of four packets of the same size comes and again these packets leave the meter in the same fashion.In this case,the jitter can not be well controlled in intermediate nodes of a DS domain.

E.Minimum Interface Queue Size

While minimum shaping buffer size is constrained by the delay requirement,the minimum ingress interface buffer size is determined by the line rate and meter parameters.Since a packet in the head of the shaping buffer need wait at most

bytes of packet.This is the minimum requirement of the interface buffer for storing packets ready for measurement.As soon as there is one whole packet in the interface buffer,the meter is triggered to measure that packet.If the packet is determined to be non-conformant,then it is up to policer to decide whether the packet should be shaped or dropped.If shaped,the packet is enqueued into the shaping buffer,if there is enough capacity to accommodate it.Otherwise,the packet is dropped.

IV.I MPLEMENTA TION AND E V ALUA TION

In this section,an implementation of the GTC is presented, followed by the experiments to evaluate the performance of the implementation,in terms of delay,jitter,and loss.The imple-mentation is based on Linux platform.

A.Linux Network Implementation

Recent Linux kernels offer a wide variety of traf?c control functions.ICA[11]implemented traf?c control in the kernel and provided a set of interfaces between kernel traf?c control element and user space programs.KIDS[12]used the con-cept of device to implement the DS functions in the kernel and implemented driver to control the DS functions.The IP net-work implementation in Linux is shown in Figure6.There is only one central queue backlog that contains packets re-ceived from all interfaces.The net

buff structure to the beginning of the protocol packet,af-ter the Ethernet header.Hence the ip

forwarding()for header analysis which decide the in-terface the packet will be sent through.If a route is found, Ip xmit()is invoked to establishes the?nal IP pro-tocol head and passes the packet to the dev xmit(). This function will actually extracts the packet’s payload from the sk

according to the Equation 6as 373.Hence,we set the SBS equal to 3,and set a CBR with constant rate 100Kbps and a background UDP data traf?c with average rate 100Kbps,both using EF PHB.From the Figure 8,we can ?nd the delay of almost all packets is bounded below 015seconds (i.e.,the given delay bound).Also,the delay-jitter is found within 005seconds.

00.05

0.1

0.15

0.2

1000

200030004000

5000

D e l a y (S e c o n d )

Packet Index

SBS=3

Fig.8.Edge node produces bounded delay for CBR traf?c with

variable packet size

-0.1

-0.075-0.05-0.02500.025

0.050.075

0.10

1000

200030004000

5000

D e l a y J i t t e r (S e c o n d )

Packet Index

SBS=3

Fig.9.Edge node produces bounded jitter for CBR traf?c with

variable packet size

To measure the jitter and delay due to the size of meter buffer,we con?gure EF PHB with token bucket rate 200Kbps with variable TBS and a ?xed shaping buffer size of 3.The traf?c model combines a V oIP traf?c with a bursty UDP data traf?c.The V oIP traf?c sends at 40Kbps and packet length 100bytes (one 72-byte UDP data sent in every 20ms)whereas the bursty UDP data traf?c sends at average rate 151Kbps with packet length 540bytes (seven 512-byte UDP data sent in every 200ms).Then,we vary the TBS from 600Kbytes to 1500Kbytes to observe the effect of on jitter and delay.We measure the jitter and delay for aggregate as well as for micro?ow.In Figures 10and 11,the jitter incurred due to the TC for both the V oIP ?ow and the aggregate with UDP data ?ow are presented.The ?gures are plotted with one point presenting the average of 20measurement results.Because the token bucket meter for EF actually multiplexes two micro?ows into one aggregate,the individualmicro?ow will experience substantial jitterintroduced by the shaping.After shaping,the aggregate leaves the node in average at token bucket rate con?gured for the EF PHB so that the interior node needs to shape the aggregate again.Apparently,the jitter in the aggregate is smaller than that in the V oIP micro?ow.Also,from Figure 11,we see when the token bucket size change from the V oIP MTU to the UDP data MTU,the jitter become

larger.The delay due to traf?c conditioning is presented in Figure 12.It shows that the per-hop delay for V oIP traf?c when merging with other bursty UDP traf?c,is still bounded under 40ms with average 20ms,independent of other traf?cs on the same EF PHB,and the size of token bucket is almost irrelevant to the per-hop delay.

-60

-40

-20020406080

100120

0246

8101214161820

D e l a y J i t t e r (m s )

Packet Index

TBS= 600 Bytes TBS= 800 Bytes TBS= 1K Bytes TBS= 1200 Bytes TBS= 1500 Bytes

Fig.10.Jitter of aggregate in boundary node for V oIP and UDP

-60

-40-20020406080

1001200

2

4

6

8101214161820

D e l a y J i t t e r (m s )

Packet Index

TBS= 600 Bytes TBS= 800 Bytes TBS= 1K Bytes TBS= 1200 Bytes TBS= 1500 Bytes

Fig.11.Jitter of micro?ow in boundary node for V oIP and UDP

0102030405060

70800

2

4

6

8101214

16

18

20

D e l a y (m s )

Packet Index

TBS= 600 Bytes TBS= 800 Bytes TBS= 1K Bytes TBS= 1200 Bytes TBS= 1500 Bytes

Fig.12.Delay of micro?ow in boundary node for V oIP and UDP

V .C ONCLUDING R EMARKS

We have proposed a generic traf?c conditioning architecture and implemented it in a Linux kernel.The GTC is con?gurable to support various forwarding PHBs.In particular,we have shown how to con?gure the GTC to serve for EF PHB that provides guaranteed delay and jitter bounds and low packet loss.The two important features of the GTC,shaping and policing,enable the boundary router of a DS domain to control the jitter and delay within the required bound while trying to minimize the loss of packet.We have derived mathematical expressions for per-hop delay and jitter bounds.To verify these theoretical results,

we have conducted experiments on the Linux implemented with GTC by injecting different traf?c models,including HTTP,CBR, V oIP,and UDP,and observed the performance impact due to the traf?c conditioning.We have shown that the GTC,when used for EF PHB,have achieved bounded delay and jitter as well as minimal packet loss.

R EFERENCES

[1]S.Shenker,C.Partridge,and R.Guerin,“Speci?cation of Guaranteed

Quality of Service,”RFC2212,September1996.

[2]M.Carson,W.Weiss,and et al.,“An Architecture for Differentiated Ser-

vices,”RFC2475,December1999.

[3] E.Davies,S.Keshav,and et al.,“A Framework for Differenti-

ated Services,”Internet Draft,https://www.wendangku.net/doc/2f9631610.html,/internet-drafts/draft-ietf-diffserv-framework-02.txt,February1999.

[4]P.White,“RSVP and Integrated Services in the Internet:A Tutorial,”IEEE

Communications Magazine,May1997.

[5]K.Nichols,S.Blake,and et al.,“Integrated Services Operation over Diff-

serv Networks,”RFC2474,December1998.

[6]V.Jacobson,K.Nichols,and K.Poduri,“An Expedited Forwarding PHB,”

RFC2598,June,1999.

[7]J.Heinanen,F.Baker,and et al.,“Assured Forwarding PHB Group,”RFC

2597,June,1999.

[8]J.Heinanen and R.Guerin,“A Single Rate Three Color Marker,”

Internet Draft,https://www.wendangku.net/doc/2f9631610.html,/internet-drafts/draft-heinanen-diffserv-srtcm-01.txt,May,1999.

[9]J.Heinanen and R.Guerin,“A Two Rate Three Color Marker,”In-

ternet Draft,https://www.wendangku.net/doc/2f9631610.html,/internet-drafts/heinanen-diffserv-trtcm-

01.txt,May,1999.

[10]L.Lin,J.Lo,and F.Ou,“A Generic Traf?c Conditioner,”Internet

Draft,https://www.wendangku.net/doc/2f9631610.html,/internet-drafts/draft-lin-diffserv-gtc-01.txt,Au-gust,1999.

[11]R.Bless and K.Wehrle,“Evaluation of Differentiated Services using an

Implementation underLinux,”http://www.icawww1.ep?.ch/linux-diffserv/.

[12]W.Almesberger and A.Kuznetsov,“Differentiated Services on Linux,”

https://www.wendangku.net/doc/2f9631610.html,rmatik.uni-

karlsruhe.de/forschung/diffserv/KIDS,March,1999.