idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2013) is 3810 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 435, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-16) exists of draft-ietf-avt-srtp-not-mandatory-13 == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-security-options-04 == Outdated reference: A later version (-02) exists of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XR Block Working Group J. Ott 3 Internet-Draft V. Singh, Ed. 4 Intended status: Standards Track Aalto University 5 Expires: May 16, 2014 I. Curcio 6 Nokia Research Center 7 November 12, 2013 9 RTP Control Protocol (RTCP) Extended Report (XR) for Run Length Encoding 10 (RLE) of Discarded Packets 11 draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09 13 Abstract 15 The RTP Control Protocol (RTCP) is used in conjunction with the Real- 16 time Transport Protocol (RTP) in to provide a variety of short-term 17 and long-term reception statistics. The available reporting may 18 include aggregate information across longer periods of time as well 19 as individual packet reporting. This document specifies a per-packet 20 report metric capturing individual packets discarded from the de- 21 jitter buffer after successful reception. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 16, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. XR Discard RLE Report Block . . . . . . . . . . . . . . . . . 4 60 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 6 62 4.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . 6 63 5. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. XR Report Block Registration . . . . . . . . . . . . . . 7 67 7.2. SDP Parameter Registration . . . . . . . . . . . . . . . 8 68 7.3. Contact information for IANA registrations . . . . . . . 8 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Metrics represented using RFC6390 Template . . . . . 9 74 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10 75 B.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 76 metrics-00 . . . . . . . . . . . . . . . . . . . . . . . 10 77 B.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 78 metrics-01 . . . . . . . . . . . . . . . . . . . . . . . 10 79 B.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 80 metrics-02 . . . . . . . . . . . . . . . . . . . . . . . 10 81 B.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 82 metrics-03 . . . . . . . . . . . . . . . . . . . . . . . 10 83 B.5. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 84 metrics-04 . . . . . . . . . . . . . . . . . . . . . . . 11 85 B.6. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 86 metrics-05 . . . . . . . . . . . . . . . . . . . . . . . 11 87 B.7. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 88 metrics-06 . . . . . . . . . . . . . . . . . . . . . . . 11 89 B.8. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 90 metrics-07 . . . . . . . . . . . . . . . . . . . . . . . 11 91 B.9. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 92 metrics-08 . . . . . . . . . . . . . . . . . . . . . . . 11 93 B.10. changes in draft-ietf-xrblock-rtcp-xr-discard-rle- 94 metrics-09 . . . . . . . . . . . . . . . . . . . . . . . 11 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 97 1. Introduction 99 RTP [RFC3550] provides a transport for real-time media flows such as 100 audio and video together with the RTP control protocol (RTCP) which 101 provides periodic feedback about the media streams received in a 102 specific duration. In addition, RTCP can be used for timely feedback 103 about individual events to report (e.g., packet loss) [RFC4585]. 104 Both long-term and short-term feedback enable a media sender to adapt 105 its media transmission and/or encoding dynamically to the observed 106 path characteristics. 108 RFC3611 [RFC3611] defines RTCP Extended Reports as a detailed 109 reporting framework to provide more than just the coarse Receiver 110 Report (RR) statistics. The detailed reporting may enable a media 111 sender to react more appropriately to the observed networking 112 conditions as these can be characterized better, although at the 113 expense of extra overhead. 115 Among many other report blocks, RFC3611 specifies the Loss Run Length 116 Encoding (RLE) block which reports runs of packets received and lost 117 with the granularity of individual packets. This can help both error 118 recovery and path loss characterization. In addition to lost 119 packets, RFC3611 defines the notion of "discarded" packets: packets 120 that were received but dropped from the de-jitter buffer because they 121 were either too early (for buffering) or too late (for playout). The 122 "discard rate" metric is part of the VoIP metrics report block even 123 though it is not just applicable to audio: it is specified as the 124 fraction of discarded packets since the beginning of the session. 125 See section 4.7.1 of RFC3611 [RFC3611]. The discard metric is 126 believed to be applicable to a large class of RTP applications which 127 use a de-jitter buffer RFC5481 [RFC5481]. 129 Recently proposed extensions to the Extended Reports (XR) reporting 130 suggest enhancing this discard metric: 132 o Reporting the number of discarded packets in a measurement 133 interval, i.e., during either the last reporting interval or since 134 the beginning of the session, as indicated by a flag in the 135 suggested XR report [RFC7002]. If an endpoint needs to report 136 packet discard due to other reasons than early- and late-arrival 137 (for example, discard due to duplication, redundancy, etc.) then 138 it should consider using the Discarded Packets Report Block 139 [RFC7002]. 141 o Reporting gaps and bursts of discarded packets during a 142 measurement interval, i.e., the last reporting interval or the 143 duration of the session [RFC7003]. 145 o Reporting the sum of payload bytes discarded during a measurement 146 interval, i.e., the last reporting interval or the duration of the 147 session [I-D.ietf-xrblock-rtcp-xr-bytes-discarded-metric]. 149 However, none of these metrics allow a receiver to report precisely 150 which packets were discarded. While this information could in theory 151 be derived from high-frequency reporting on the number of discarded 152 packets [RFC7002] or from the gap/burst report [RFC7003], these two 153 mechanisms do not appear feasible: The former would require an unduly 154 high amount of reporting which still might not be sufficient due to 155 the non-deterministic scheduling of RTCP packets. The latter incur 156 significant complexity and reporting overhead and might still not 157 deliver the desired accuracy. 159 This document defines a discard report block following the idea of 160 the run-length encoding applied for lost and received packets in 161 [RFC3611]. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in BCP 14, RFC 2119 168 [RFC2119]. 170 The terminology defined in RTP [RFC3550] and in the extensions for XR 171 reporting [RFC3611] applies. 173 3. XR Discard RLE Report Block 175 The XR Discard RLE report block uses the same format as specified for 176 the loss and duplicate report blocks in [RFC3611]. Figure 1 177 describes the packet format. The fields "BT", "T", "block length", 178 "SSRC of source", "begin_seq", and "end_seq" have the same semantics 179 and representation as defined in [RFC3611], with the addition of the 180 "E" flag to indicate the reason for discard. The "chunks" encoding 181 the run length have the same representation as in RFC3611, but encode 182 discarded packets. A definition of a discarded packet is given in 183 [RFC7002]. 185 0 1 2 3 186 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | BT=DRLE |rsvd |E| T | block length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | SSRC of source | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | begin_seq | end_seq | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | chunk 1 | chunk 2 | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 : ... : 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | chunk n-1 | chunk n | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1: XR Discard RLE Report Block 203 Block Type (BT, 8 bits): A Run-length encoded Discarded Packets 204 Report Block is identified by the constant DRLE. 206 [Note to RFC Editor: please replace DRLE with the IANA provided RTCP 207 XR block type for this block. Please remove this note prior to 208 publication as an RFC.] 210 rsvd (3 bits): This field is reserved for future definition. In the 211 absence of such definition, the bits in this field MUST be set to 212 zero and MUST be ignored by the receiver. 214 The 'E' bit is introduced to distinguish between packets discarded 215 due to early arrival and those discarded due to late arrival. The 216 'E' bit is set to '1' if the chunks represent packets discarded due 217 to too early arrival and is set to '0' otherwise. 219 In case both early and late discarded packets shall be reported, two 220 Discard RLE report blocks MUST be included; their sequence number 221 range MAY overlap, but individual packets MUST only be reported as 222 either early or late and not appear marked in both. If packets 223 appear in both report blocks, the conflicting packets are ignored. 224 Packets reported in neither are considered to be properly received 225 and not discarded. 227 Discard RLE Report Blocks SHOULD be sent in conjunction with an RTCP 228 RR as a compound RTCP packet. 230 4. Protocol Operation 232 This section describes the behavior of the reporting node (= media 233 receiver) and the media sender. 235 4.1. Reporting Node (Receiver) 237 Transmission of RTCP XR Discard RLE Reports is up to the discretion 238 of the media receiver, as is the reporting granularity. However, it 239 is RECOMMENDED that the media receiver signals all discarded packets 240 using the method defined in this document. If all packets over a 241 reporting period were discarded, the media receiver MAY use the 242 Discard Report Block [RFC7002] instead. In case of limited available 243 reporting bandwidth, it is up to the receiver whether or not to 244 include RTCP XR Discard RLE reports. 246 The media receiver MAY send the Discard RLE Reports as part of the 247 regularly scheduled RTCP packets as per RFC3550. It MAY also include 248 Discard RLE Reports in immediate or early feedback packets as per 249 RFC4585. 251 4.2. Media Sender 253 The media sender MUST be prepared to operate without receiving any 254 Discard RLE reports. If Discard RLE reports are generated by the 255 media receiver, the media sender cannot rely on all these reports 256 being received, nor can the media sender rely on a regular generation 257 pattern from the media receiver. 259 However, if the media sender receives any RTCP reports but no Discard 260 RLE report blocks and is aware that the media receiver supports 261 Discard RLE report blocks, it MAY assume that no packets were 262 discarded at the media receiver. 264 5. SDP signaling 266 A participant of a media session MAY use SDP to signal its support 267 for the report block specified in this document or use them without 268 any prior signaling (see section 5 of [RFC3611]). 270 For signaling in SDP, the RTCP XR attribute as defined in [RFC3611] 271 MUST be used. The SDP [RFC4566] attribute 'xr-format' defined in 272 RFC3611 is augmented as described in the following to indicate the 273 the discard RLE metric. 275 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] 276 CRLF ; defined in [RFC3611] 278 xr-format =/ xr-discard-rle 280 xr-discard-rle = "discard-rle" 282 The parameter 'discard-rle' is used to indicate support for the 283 Discard RLE Report Block defined in Section 3. 285 When SDP is used in Offer/Answer context, the mechanism defined in 286 [RFC3611] for unilateral "rtcp-xr" attribute parameters applies (see 287 section 5.2 of [RFC3611]). 289 6. Security Considerations 291 The Discard RLE block provides per-packet statistics so the risk to 292 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 293 applies. In some situations, returning very detailed error 294 information (e.g., over-range measurement or measurement unavailable) 295 using this report block can provide an attacker with insight into the 296 security processing. Implementers should consider the guidance in 297 [I-D.ietf-avt-srtp-not-mandatory] for using appropriate security 298 mechanisms, i.e., where security is a concern, the implementation 299 should apply encryption and authentication to the report block. For 300 example this can be achieved by using the AVPF profile together with 301 the Secure RTP profile as defined in [RFC3711]; an appropriate 302 combination of the two profiles (an "SAVPF") is specified in 303 [RFC5124]. However, other mechanisms also exist (documented in 304 [I-D.ietf-avtcore-rtp-security-options]) and might be more suitable. 306 Additionally, The security considerations of [RFC3550], [RFC3611], 307 and [RFC4585] apply. 309 7. IANA Considerations 311 New block types for RTCP XR are subject to IANA registration. For 312 general guidelines on IANA considerations for RTCP XR, refer to 313 [RFC3611]. 315 7.1. XR Report Block Registration 317 This document extends the IANA "RTP Control Protocol Extended Reports 318 (RTCP XR) Block Type Registry" by a new value: DRLE (Discard RLE 319 Report). 321 [Note to RFC Editor: please replace DRLE with the IANA provided RTCP 322 XR block type for this block here and in the diagrams above. Please 323 remove this note prior to publication as an RFC.] 325 7.2. SDP Parameter Registration 327 This document registers a new parameters for the Session Description 328 Protocol (SDP), "discard-rle" in the "RTP Control Protocol Extended 329 Reports (RTCP XR) Session Description Protocol (SDP) Parameters 330 Registry". 332 7.3. Contact information for IANA registrations 334 Joerg Ott (jo@comnet.tkk.fi) 336 Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland. 338 8. Acknowledgments 340 The authors would like to thank Alan Clark, Roni Even, Sam Hartman, 341 Colin Perkins, Dan Romascanu, Dan Wing, and Qin Wu for providing 342 valuable feedback on earlier versions of this draft. 344 9. References 346 9.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 352 Jacobson, "RTP: A Transport Protocol for Real-Time 353 Applications", STD 64, RFC 3550, July 2003. 355 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 356 Protocol Extended Reports (RTCP XR)", RFC 3611, November 357 2003. 359 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 360 "Extended RTP Profile for Real-time Transport Control 361 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 362 2006. 364 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 365 Description Protocol", RFC 4566, July 2006. 367 [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol 368 (RTCP) Extended Report (XR) Block for Discard Count Metric 369 Reporting", RFC 7002, September 2013. 371 9.2. Informative References 373 [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol 374 (RTCP) Extended Report (XR) Block for Burst/Gap Discard 375 Metric Reporting", RFC 7003, September 2013. 377 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 378 Applicability Statement", RFC 5481, March 2009. 380 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 381 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 382 RFC 3711, March 2004. 384 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 385 Real-time Transport Control Protocol (RTCP)-Based Feedback 386 (RTP/SAVPF)", RFC 5124, February 2008. 388 [I-D.ietf-avt-srtp-not-mandatory] 389 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 390 Framework: Why RTP Does Not Mandate a Single Media 391 Security Solution", draft-ietf-avt-srtp-not-mandatory-13 392 (work in progress), May 2013. 394 [I-D.ietf-avtcore-rtp-security-options] 395 Westerlund, M. and C. Perkins, "Options for Securing RTP 396 Sessions", draft-ietf-avtcore-rtp-security-options-04 397 (work in progress), July 2013. 399 [I-D.ietf-xrblock-rtcp-xr-bytes-discarded-metric] 400 Singh, V., Ott, J., and I. Curcio, "RTP Control Protocol 401 (RTCP) Extended Report (XR) for Bytes Discarded Metric", 402 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-00 (work 403 in progress), October 2013. 405 Appendix A. Metrics represented using RFC6390 Template 407 RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC 408 number, when assigned. 410 a. Run-length encoding of Discarded RTP Packets Metric 412 * Metric Name: Run-length encoding of Discarded RTP Packets 413 Metric. 415 * Metric Description: Instances of RTP packets discarded over 416 the period covered by this report. 418 * Method of Measurement or Calculation: See section 3, for the 419 definition of Discard run-length encoding [RFCXXXX] and 420 section 4.1 of RFC3611 for Run-length encoding. 422 * Units of Measurement: Every RTP packet in the interval is 423 reported as discarded or not. See section 3 for the 424 definition of [RFCXXXX]. 426 * Measurement Point(s) with Potential Measurement Domain: The 427 measurement of these metrics is made at the receiving end of 428 the RTP stream. 430 * Measurement Timing: Each RTP packet between a beginning 431 sequence number (begin_seq) and ending sequence number 432 (end_seq) are reported as discarded or not. See section 3 for 433 the definition of Discard run-length encoding [RFCXXXX]. 435 * Use and applications: See section 1, paragraph 1 of [RFCXXXX]. 437 * Reporting model: See RFC3611. 439 Appendix B. Change Log 441 Note to the RFC-Editor: please remove this section prior to 442 publication as an RFC. 444 B.1. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-00 446 o Changed the interval flag from 1 to 2 bits in the discarded bytes 447 report. Also added the measurement identification tag to the 448 block. 450 o Added this section. 452 B.2. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-01 454 o Removed the measurement identification tag in the bytes discarded 455 block. 457 B.3. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-02 459 o Removed the extra Tag bits from the Discarded bytes XR block. 461 o Clarified use of measurement identity block in Section 4 and 5.2 463 B.4. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 465 o Added explanation for block length in bytes discarded block. 467 o Added an acknowledgement section. 469 B.5. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 471 o Added Block Type definition to each XRBlock. 473 o Made changes requested in WGLC. 475 B.6. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 477 o Made changes requested by SDP directorate. 479 B.7. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 481 o Editorial fixes based on review from Gen-art and IESG review. 483 B.8. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-07 485 o Editorial fixes based on review from IESG. 487 o Editorial fixes based on Security and PM directorate. 489 o Split bytes discarded from this draft to another. 491 o Updated Security Considerations Section. 493 o This draft now normatively cites the definition of discards in 494 'packets discarded' draft. 496 B.9. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-08 498 o Editorial fixes: Updated references from drafts to RFCs. 500 o Updated RFC6390 template with RTP keyword. 502 B.10. changes in draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09 504 o Removed (RLE) from RFC6390 template. 506 Authors' Addresses 508 Joerg Ott 509 Aalto University 510 School of Electrical Engineering 511 Otakaari 5 A 512 Espoo, FIN 02150 513 Finland 515 Email: jo@comnet.tkk.fi 516 Varun Singh (editor) 517 Aalto University 518 School of Electrical Engineering 519 Otakaari 5 A 520 Espoo, FIN 02150 521 Finland 523 Email: varun@comnet.tkk.fi 524 URI: http://www.netlab.tkk.fi/~varun/ 526 Igor D.D. Curcio 527 Nokia Research Center 528 P.O. Box 1000 (Visiokatu 3) 529 Tampere, FIN 33721 530 Finland 532 Email: igor.curcio@nokia.com