The Delay Measurement using The RTCP for

Real-time Service in Interworking EnvironmentHyun Jong Kim', Jong Chan Kim', Seong Gon Choi',

Tae Soo Jeong2, Sung Soo Kang2

'School of Electrical & Computer Engineering, Chungbuk National University (CBNU),12 Gaeshin-dong, Heungduk-gu, Cheongju-city, Chungbuk, 361-763, Republic of Korea

2Electronics and Telecommunications Research Institute (ETRI),161 Gajeong-dong, Yuseong-gu, Daejeon, 305-350, Republic of Korea

'{hjkim78, kjclOl1, sgchoi}@chungbuk.ac.kr2{tsjeong, sskang} getri.re.kr

Abstract - The traffic measurement and monitoring arerequired to guarantee a QoS in BcN (Broadband convergenceNetwork) environment. According to the increment of real-timeservice provision, traffic measurement is needed for real-timeservice in internetworking between different network serviceproviders. Especially, it is an important issue that serviceproblem break out in which network if an obstacle to serviceoccurs in using real-time service (e.g. video conference). For this,we propose a method of traffic measurement using RTCP tomeasure network delay for real-time service in each network.Also With this method, we can detect and define which networkhas created a problem.

Keywords - Traffic Measurement, Convergence Network,RTCP, Trouble Section, delay

1. Introduction

The Internet is persistently expanding and evolving into aglobal communications medium, consisting of heterogeneous-ly interconnected systems and carrying an increasing mix oftraffic flows with diverse characteristics and performancerequirements. Which means network operators and serviceproviders are face with the major challenge of being able toprovide a stable service with consistently predictableperformance characteristics, as these can be defined by acombination of metrics and associated thresholds to includelow and invariable latency, highly reliable datagram delivery,and high network availability.Now traffic measurement studies have been going on several

standard organizations (e.g. ITU-T, IETF, ETSI etc) and areformed in convergence type. The studies about QoS andInterworking are carried out with active in convergencenetwork environment. Especially interworking architectureand performance measurement study is being progressed inNGN [1] - [5].When ISPs (Internet Service Providers) provide end-to-end

service, traffic measurement is needed for QoS management ininterworking environment. Also, traffic measurement isimportant to detect trouble serviced area between different

networks when the problem occurs in QoS. Until now, manystudies have been carried out by using active probe andpassive probe method in order to estimate RTT (Round TripTime) of ICMP or TCP. However, active probe method needstime synchronization between end-users, and the existingpassive probe method is not suitable for real-time servicebecause method of filtering ICMP and TCP is insufficient inreal-time due to these protocol characteristic.The most common tools for measuring RTTs between

end-hosts employ the Internet Control Message Protocol(ICMP) using either time exceeded or echo request/replymessages. While tools that use ICMP are useful in networktrouble-shooting, they have well-known limitations for precisedelay measurements including the fact that Internet ServiceProviders often block or rate-limit ICMP traffic, and thatICMP traffic is often given lower priority in routers. Othertools are to use TCP SYN and SYN-ACK connection setuphandshaking mechanism to measure RTT. But this type ofRTT measurement is insufficient to estimate delay ofusing thereal-time service.So we propose the new traffic measurement method using

RTCP interval to measure each network delay in interworkingpoint. The traffic measurement system (TMS) has to filter onlythe RTCP packet using passive probe to calculate an RTCPinterval. Our new traffic measurement method has advantagesthat do not need accurate time synchronization between endusers like active probe method, and it can estimate networkdelay using the RTCP interval in real-time service. Also newTMS is realized easily by software function on interworkingrouter.The rest ofthe paper is organized as follows. In section 2, we

introduce the related work oftraffic measurement and indicateproblems in these methods. In section 3, we show the newtraffic measurement mechanism for real-time service andanalysis process of RTCP data in order to estimate networkdelay. In section 4, we present an arbitrary data analysis andmethod of providing delay information to provider and userwith proposed system. Finally, we present a conclusion of thepaper and future works in section 5.

ISBN 978-89-5519-131-8 93560 - 1153 - Feb. 12-14, 2007 ICACT2007

2. Related Works

Some recent studies describe measurement tools that attemptto infer path characteristics from TRR measurements arebased on the use of internet Control Message Protocol (ICMP)time-to-live (TTL) [6] and ICMP timestamp options. ButInternet Service Providers often block or rate-limit ICMPtraffic and that ICMP traffic is often given lower priority inrouters.The method [7] uses passive estimation of round-trip times

for bulk TCP transfers. The method uses TCP timestamps tolocate segments from a bulk data sender that arrive one RTTapart, while the other detects patterns caused by self-clockingthat repeat every RTT and can be used throughout the lifetimeof a TCP session. However TCP protocol using this method isincongruent for measuring performance to real-time service.So we estimate delay between networks using RTCP.A previous work [8] introduces a performance measurement

method called CoMPACT Monitor, which can estimate userperformance in a scalable and lightweight manner. Thismethod only requires counting of the traffic volume (passivemonitoring) and simple measurement of thus more feasibleand tractable than conventional methods. However activeprobe method needs time synchronization between end usersto estimate delay. It is inaccuracy that time synchronization isprovided by NTP (Network Time Protocol).

3. Proposed TMS for BcN

BcN (Broadband convergence Network) is defined asenvironment that is interworked by many network serviceproviders. In this environment, if a problem occurs in using areal-time service (e.g. a video conference), it is important todetect the section of the problem in where network. For suchreasons, we propose the new TMS that can detect and definethe trouble serviced network.

3.1 Network Configuration in BcN

erwoiinPoin

NtorkAAprdbtt T,

Traffic MeasuremerU* .vg;em

ransport delay.Re;pl nlormat

Newor iB

j : RTP

m : RTCP

I

QoS ManagmentCener

Figure 1. Real-time service traffic flows in BcN model network

The structure of BcN model network is made in IX schemeusing L3 router between different networks. Edge router ofeach NSP is connected with IX router in Interworking point byusing a peering transit method. As figure 1, user 1 and user_2individually connect with Network_A and Network_B in

order to use real-time service (e.g. a video conference). In thiscase, network performance is measured by extraction datafrom RTCP filtering because typically real-time service usesRTP and RTCP for real-time streaming.RTP provides end-to-end network transport functions

suitable for applications transmitting real-time data, such asaudio, video or simulation data, over multicast or unicastnetwork services. RTP does not address resource reservationand does not guarantee QoS (Quality of Service) for real-timeservices. The data transport is augmented by a control protocol(RTCP) to allow monitoring of the data delivery in a mannerscalable to large multicast networks, and to provide minimalcontrol and identification functionality. RTP and RTCP aredesigned to be independent of the underlying transport andnetwork layers [1]. Here, the TMS is placed in interworkingpoint and can be constituted by software function on edgerouter or interworking gateway.The TMS filters RTCP packets from the flow packet that is

sent by each network, and saves RTCP packet data. Thissystem calculates RTCP interval from saved data and expectsthe time (Tn) when next RTCP packet is sent. Each networkdelay is calculated by a gap of next sending RTCP expectationtime and present time received next RTCP.The estimated delay is reported to each network operator to

monitor their network performance or is saved in a QoSManagement Center. When service user' s QoS complaintoccurs, QoS Management Center can provide delayinformation to user.

3.2 Traffic Measurement Mechanism

L Check the packet headerin flow packets

no

RTCPpack

yes

Where from

Network_A Network_B

Computing the RTCP Computing the RTCPtransmission interval (F_A) transmission interval (P_B)

I I-Computing the next RTCP Computing the next RTCP

received time (fn_A) received time CTn_B)

I IDelay_A= (Tn_A) - _A) Delay_B= (TnB) -(T_B)

Report the delay A and delay_B

Figure 2. The computiing a network delay flow chart

RTP is designed to allow an application to scaleautomatically over session sizes ranging from a fewparticipants to thousands. If the reception reports from eachparticipant were sent at a constant rate, the control trafficwould grow linearly with the number of participants.Therefore, the rate must be scaled down by dynamically

ISBN 978-89-5519-131-8 93560 - 1154 - Feb. 12-14, 2007 ICACT2007

calculating the interval between RTCP packet transmissions.The control traffic bandwidth is in addition to the sessionbandwidth for the data traffic. It is recommended that thefraction of the session bandwidth added for RTCP be fixed at500.For these reasons, we collect RTCP packets using passive

probe. Through collected RTCP packets, we know true thatuser_1 connects with network A and can expect next anRTCP packet arrival time computing the RTCP interval.Through the SR and RR reports ofRTCP packet we know theRTCP packet source or user connected network. Using thedistinguished packet we can estimate each network delay.Detail description of estimating network delay will describe inSection 3.3. Figure 2 shows the computing a network delayflow chart.

3.3 Delay Analysis Mechanism with RTCP in TMS

The RTCP transmission interval between packets from asession participant should scale with the group size. Thisinterval is called the calculated interval. The calculatedinterval T is then determined as follows and is based on [1],[2].

1. If the number of senders is less than or equal to 25% ofthe membership (members), the interval depends onwhether the participant is a sender or not (based on thevalue of RTCP reports). If the participant is a sender, theconstant C is set to the average RTCP packet size dividedby 25% of the RTCP bandwidth, and the constant n is setto the number of senders. If the number of senders isgreater than 25%, senders and receivers are treatedtogether.

2. If the participant has not yet sent an RTCP packet, theconstant Tmin is set to 2.5 seconds, else it is set to 5seconds.

3. The deterministic calculated interval Td is set tomax(Tmin, n*C).

4. The calculated interval T is set to a number uniformlydistributed between 0.5 and 1.5 times the deterministiccalculated interval.

5. The resulting value of is divided by e - 3/2 =1.21828 tocompensate for the fact that the timer reconsiderationalgorithm converges to a value of the RTCP bandwidthbelow the intended average.

When an RTP or RTCP packet is received from a participantwhose SSRC is not in the member table, the SSRC is added tothe table. The same processing occurs for each CSRC in avalidated RTP packet.When an RTP packet is received from a participant whose

SSRC is not in the sender table, the SSRC is added to the table,and the value for senders is updated.For each compound RTCP packet received, the value of

average RTCP packet size is updated:

avg_rtcp_size (1/16)*packet size + (15/16)*avg_rtcp size(1)

where packet-size is the size ofthe RTCP packet just received.

When an RTCP BYE is to be transmitted, if the receivedpacket is an RTCP BYE packet, the SSRC is checked againstthe member table. If present, the entry is removed form thetable, and the value for members is updated. The SSRC is thenchecked against the sender table. If present, the entry isremoved from the table, and the value for senders is updated.

* The value for tn (the next scheduled transmission time ofan RTCP packet) according to the following formula:

tn = tc + (memberslpmembers)*(tn - tc) (2)

* The value for tp (the last time an RTCP packet wastransmitted) is updated according the following formula:

tp = tc - (memberslpmembers) *(tc - tp) (3)

* The next RTCP packet is rescheduled for transmission attime tn, which is now earlier.

* The value pmembers is the estimated number of sessionmembers at the time tn was last recomputed.

According to the rule of computing the RTCP transmissioninterval, we can prospect the time that next RTCP packet willarrive at the TMS. The TMS preserves RTCP packet arrivaltime when TMS received RTCP packet. And we candetermine next RTCP packet arrival time by adding thecalculated interval from received RTCP packet to the last timean RTCP packet was received. Through this kind of processesabove, we can obtain two data - expectation time and thepresent time an RTCP packet was received.

Each network delay = present time - expectation time (4)End-to-End delay = Network A delay + Network B delay (5)

If the trouble is arisen, while they are using the real-timeservice, we can detect and define the trouble serviced sectionbased on calculated delay data. And we can obtain total servicedelay from addition of each network delay.

In the existing algorithm of computing the RTCPtransmission interval, the resulting value of interval isdetermined as multiplying calculated RTCP interval byrandom number between 0.5 and 1.5 when the RTCP packetsare transmitted. But we beforehand know that end-user isgenerating random number to expect next time when end-userwill transmit RTCP SR/RR report.So the end-user has to insert 8bytes random number using to

calculate interval in padding part ofRTCP SR/RR packet, andtransmit them. In interworking point, TMS is used the samealgorithm of the computing the RTCP transmission interval,but the next interval is calculated as using random numbertransmitted by RTCP packet instead of generated randomnumber. According to this procedure, TMS in interworkingpoint can expect time when next RTCP packet will betransmitted, and can calculate each network delay.

ISBN 978-89-5519-131-8 93560 - 1155 - Feb. 12-14, 2007 ICACT2007

4. Data Analysis with Proposed System0.3

Y. 1541 recommendation in ITU-T recommends within thepermission range delay and jitter in different service. Thisrecommendation specifies IP performance values to beachieved internationally for each of the performanceparameters defined in ITU-T recommendation Y. 1540. Someof these values depend on which network QoS class theend-users and network providers agree on. Thisrecommendation defines six different network QoS classes.This recommendation applies to international end-to-end IPnetwork paths. The network QoS classes defined here are

intended to be the basis of agreements between end-users andnetwork service providers, and between service providers. Theclasses should continue to be used when static agreements giveway to dynamic request supported by QoS specificationprotocols. Table 1 present Y.1541 Provisional IP QoS classdefinitions and network performance objectives.

Table 1. Y.1541 Provisional IP QoS class definitions and networkperformance objectives

QoS Applications IPTD IPDVClasses (Examples)

Class 0 Real-time, Jitter sensitive, high lOOms50msinteraction(VolP, VTC)

Class Real-time, Jitter sensitive, 400ms 5Omsinteractive (VoIP, VTC)

Class 2 Transaction Data, Highly OOms Unspecifiedinteractive, (Signaling)

Class 3 Transaction Data, Interactive 400ms Unspecified

Class 4 Low loss only (Shot transactions, Is UnspecifiedBulk data, Video streaming)

Class 5Traditional applications of

Unspecified Unspecifieddefault IP networks

IPTD: IP packet transfer delayIPDV: IP packet delay variation

In order to get arbitrary data we use the ping test to theCBNU server, and analyze that data. Ping test method is thattwo computers forward ping data at the same time to theCBNU server, and then estimate delay of each path. And we

survey service class types that each network can provide basedon analysis data and Y. 1541 recommendation. We know thateach network's one-way delay is about 65ms in Figure 3, andthat end-to-end delay is about 13 tIms in Figure 4. In thisnetwork, network service providers (NSP) Provider class 1

and class 3 service type of Y. 1541.Applying proposed new TMS, we can obtain each network

delay and total network delay in figure 3 and 4. In figure 4, weknow that a large scale delay is arisen at time 65. At this time,we have to show the figure 3 to detect where the source oflarge delay is arisen. We find that a delay of network A ispresented largely at around time 65. This analysis can blamecharge of network trouble upon a network A operator whenservice user complains. Also, it is possible to visually monitornetwork using GUI (Graphical User Interface) environment inreal-time.

4-+

*NtvtwrnA; dleay

Ntdwoik B delay

02

ApprxWam I1 y minimal value

0 10 20 30 40 50 60 70 80 90 100 110

Time

Figure 3. Each network dealy graph

Figure 4. End-to-End network dealy graph

And proposed new TMS in this paper has advantages that donot need time synchronization between end users. Proposedsystem uses the passive probe method because the active probemethod need time synchronization between end-users toestimate network delay and handle packets of small numberbecause it uses only RTCP among protocols that real-timeservice uses. Also new TMS is realized easily by softwarefunction on interworking router.The TMS establishes delay range that does not has a bad

effect on QoS using the calculated delay and jitter. The delayrange is set up by sum of delay and jitter, difference of delayand jitter(delay + jitter = upper boundary, delay jitter = downboundary).The TMS calculates a delay by filtering only RTCP packets

and saves time information of delay when calculated delay isescaped in delay range. The delay is analyzed with problem bynetwork delay in interworking environment when estimateddelay escapes upper boundary of delay range, on the otherhand problem by system error when estimated delay is smallerthan down boundary of delay range. Saved information istransported to providers and QoS Management Center ingraph type or text type by periods (e.g. 1 day period).Example of delay and jitter application of Class 0 and

Class_1 in ITU-T Y.1541 recommendation is presented inFigure 5.

ISBN 978-89-5519-131-8 93560

EAch networik dei

'En&t-Eni de0.4 -------------------------------l

Ehd-to-del a11-13i _______------------------------ --------------------

0 - - --- --- - - - - --- ---- - -T--

01 X1L el lxLnnvalue delayunumWtred etwL

0 20 30 40 60 70-so 9 100 1

Tmie

- 1156 - Feb. 12-14, 2007 ICACT2007

xamnple of tdelayonaio

0 J .. .. ... ... I.. - ...I .... - ... ..... .. .- ...... .. .. ;

O. .... .15...

0145@ Ff f

02 .............

q.1~~~~~~.

+ CIassu0a

0 65.. .... ... .. ........ .. ;... .

O 2 3 ;4 6 7 8 010 11 12 14 15 16 l? 18 19 2 21 L 2 24time

Figure 5. Example of Class_0 and Class_1 application graph

5. Conclusion and Further Study

The traffic measurement is needed in BcN (Broadbandconvergence Network) environment and traffic measurementplays an important role in quality of service managementbetween different network service providers. In order to detectwhere network is trouble, we propose the traffic measurementmethod using RTCP interval to measure network delay in eachother network. Through this method, we can detect and definethe trouble serviced network in time when network problemhas been arisen, and easily practice traffic monitoring withgraphically display of estimate result.However this method only analyzes network performance

about real-time service. In NGN (Next Generation Network)environment, various internet services are provided so that it isdifficult to measure performance only using RTCP. Nowinterworking of different network is constituted by oneinterworking router in BcN model network. But hereafter, ifBcN environment is converged by many interworking routers,resource reservation function for RTCP path is neededbecause it is difficult that expect RTCP path in this networkenvironment. Also if BcN is constituted by theinternetworking not L3 router but L2 MPLS, needed functionor system in MPLS will add to interworking point. Theseissues are for further study.

[7] Bryan Veal, Kang Li, David Lowenthal.: New Methods for PassiveEstimation of TCP Round-Trip Times. In: Proceeding ofPAM (2005)

[8] Keisuke Ishibashi, Toshiyuki Kanazawa, Masaki Aida, Hiroshi Ishii.:Active/passive combination-type performance measurement methodusing change-of-measure framework. In: COMCOM (2003)

[9] Jiang, J., Dovrolis, C.: Passive estimation ofTCP round-trip times. ACMComputer Communication Review 32 (2002)

[10] Jain, M., Dovrolis, C.: End-to-End available bandwidth: measurementmethodology, dynamics, and relation with tcp throughput. In:SIGCOMM, ACM (2002)

[11] Jaiswal, S., lannaccone, G., Diot, C., Kurose, J., Towsley, D.: InferringTCP connection characteristics through passive measurements. In:INFOCOM, IEEE (2004)

[12] Masaki Aida, Naoto Miyoshi, Keisuke Ishibashi.: A Scalable andLightweight QoS Monitoring Technique Combining Passive and ActiveApproaches. In: INFOCOM, IEEE (2003)

[13] B.B. Lowekamp.: Combining active and passive network measurementsto build scalable monitoring systems on the grid. In: PerformanceEvaluation Review 30(4) (2003) 19 - 26

[14] T. Lindh.: A new approach to performance monitoring in IP networks -

combining active and passive methods. In: Proceeding ofPAM (2002)[15] Y.Tsang, M. Coates, R. Nowak.: Network delay tomography. In: IEEE

transactions on Signal Processing (2003), Vol. 51, no. 8, 2125 - 2136[16] ITU-T Recommendation Y.1541: Network performance objectives for

IP-based service

Acknowledgments - This work was supported in part by theInstitute of Information Technology Assessment (IITA) Through theMinistry of Information and Communication (MIC).

CorrespondAuthor: Seong Gon Choi (sgchoi 4chungbuk.ac.kr)

REFERENCES

[1]

[2]

[3]

[4]

[5]

[6]

H. Schulzrinne, S. Casner, R.Frederick, V.Jacobson.: RTP: A TransportProtocol for Real-Time Applications. In: IETF RFC 3550 (2003)H. Schulzrinne, S. Casner.: RTP Profile for Audio and Video Conferencewith Minimal Control. In: IETF RFC 3551 (2003)ITU-T. SG 13. Temporary document: Baseline text for Y.mpm,Management of perfor-mance measurement for NGN. In: TD 112Rev.l(WP 4/13) (2006)ITU-T. SG 13. Temporary document: Y.gina-General interworkingarchitecture. In: TD 253 (WP 3/13) (2006)ITU-T. SG 13. Temporary document: Draft Revised RecommendationY.140IRev. In: TD 255(WP 3/13) (2006)K. Lai, M. Baker.: Measuring link bandwidths using a deterministicmodel of packet delay. In: Proc. ACM SIGCOMM (2000)

ISBN 978-89-5519-131-8 93560

I 0, 14'i

l

- 1157 - Feb. 12-14, 2007 ICACT2007