idnits 2.17.1 draft-ietf-avt-aggregation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 8) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 227: '... fields in that padding header MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 6, 1998) is 9485 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 section? '1' on line 412 looks like a reference -- Missing reference section? '2' on line 416 looks like a reference -- Missing reference section? '3' on line 420 looks like a reference -- Missing reference section? '4' on line 425 looks like a reference -- Missing reference section? '5' on line 429 looks like a reference -- Missing reference section? '6' on line 433 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT Working Group 2 Internet Draft J.Rosenberg, H.Schulzrinne 3 draft-ietf-avt-aggregation-00.txt Bell Labs/Columbia U. 4 May 6, 1998 5 Expires: November 6, 1998 7 An RTP Payload Format for User Multiplexing 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 ABSTRACT 31 This memo describes an RTP payload format for multiplexing 32 data from multiple users into a single RTP packet. Such 33 multiplexing is especially useful for transporting voice 34 data between Internet telephony gateways. It causes signif- 35 icant reductions in header overheads and improves scalabil- 36 ity. 38 1 Introduction 40 Internet telephone gateways (ITGs) allow a public switched telephony 41 user (PSTN) user to contact another PSTN user, with the long distance 42 portion of the call routed over the Internet. Such a scenario is 43 depicted in Figure 1. 45 ~~~~~~~~ ------- ~~~~~~~~~~ ------- ~~~~~~~~ 46 A --| | | | | | | | | |-- C 47 | PSTN |--| ITG |---| IP NET |---| ITG |--| PSTN | 48 B --| X | | J | | | | K | | Y |-- D 49 ~~~~~~~~ ------- ~~~~~~~~~~ ------- ~~~~~~~~ 51 Figure 1: Internet telephony gateway architecture 53 Subscribers A and B connect to ITG J via their local telephone net- 54 work, X. A wishes to speak with user C, and B wishes to speak with 55 user D, both of which are connected to local phone network Y. To 56 complete the call, ITG J packetizes and transports the voice to and 57 from A and B through the IP network, to remote gateway K. There, ITG 58 K completes the calls to C and D through PSTN Y. This type of 59 arrangement and common destination may be particularly common for 60 connecting the PBXs of corporate branch offices across the Internet. 62 In this scenario, ITGs J and K act as Internet hosts, which are 63 effectively proxies for the telephone users connected to them. Unlike 64 typical Internet telephony, however, their will often be multiple 65 active calls between a pair of gateways, each representing a differ- 66 ent pair of users. Gateways can signal calls using SIP [1], H.323 or 67 proprietary signalling protocols. Media data is transported via a 68 separate RTP [2] session for each user. 70 We observe that using a separate RTP session for each user connected 71 between a pair of gateways is wasteful. The payloads carried in each 72 packet are generally small. For example, the ITU G.729 speech coder 73 [3] generates a rate of 8 kb/s in frames of 10 ms duration. If 74 packed three frames per packet, the resulting RTP payloads are 30 75 bytes long. The IP, UDP and RTP headers add up to 40 bytes, resulting 76 in a packet efficiency of only 43%. 78 On the other hand, suppose the payloads from both users are multi- 79 plexed into the same RTP session and packet. A multiplexing protocol 80 is now required to delineate the packets. The protocol defined here 81 typically adds 16 bits of overhead per multiplexed user. In the two- 82 subscriber example above, this would allow an RTP packet to be con- 83 structed with 60 bytes of useful payload and 41 bytes of header, the 84 efficiency improves to 59%. Since most voice trunks can carry at 85 least 24 calls at a time, we anticipate much better efficiencies in 86 practice, making IP-based interconnection competitive, from an effi- 87 ciency standpoint, with leased lines. 89 A further benefit of multiplexing is a potential reduction in packe- 90 tization delays. Most Internet telephony applications use fairly 91 large packetization delays, mainly for the purpose of raising the 92 size of the payloads to increase efficiency. However, if multiplexing 93 is performed, the packet payload increases. This would allow smaller 94 packetization delays to be used as the number of multiplexed users 95 increases. 97 Yet another benefit is the reduction in interrupt processing at the 98 receiving ITG. Whenever a packet arrives at the gateway, the operat- 99 ing system must perform a context switch into the kernel and process 100 the packet. Without aggregation, the frequency of these interrupts 101 increases linearly with the number of users. However, with aggrega- 102 tion, the packet rate does not increase as more users are added, and 103 thus the interrupt rate stays constant. This improves scalability. 105 The main drawback to multiplexing is the increase in store-and- 106 forward delays. These delays are often most problematic in end sys- 107 tems, which are typically connected via dialup modems. In this appli- 108 cation, ITGs are likely connected to the Internet via higher rate 109 connections, such as a T1. Assuming 24 users are multiplexed into a 110 packet, using the same codec and packetization delays as above, store 111 and forward delays are only 3.7 ms, which are relatively low compared 112 to typical queueing and propagation delays. 114 This draft describes an RTP payload format for supporting multiplex- 115 ing of many users into a single RTP session. It is based on an ear- 116 lier expired Internet Draft [4] 118 2 Payload Format 120 The format of RTP packets with multiplexed users is given in Figure 121 2. 123 Figure 2: Packet format for multiplexing 125 All fields of the RTP header except the timestamp, marker bit and 126 SSRC maintain their current definition. Payload Type: The payload 127 type field designates the RTP packet as a multiplexed payload. The 128 payload type value is chosen dynamically and the binding to this for- 129 mat is conveyed via non-RTP means, such as SDP [1]. Timestamp: This 130 protocol requires that all multiplexed streams in one packet have the 131 same clock rate (i.e., sampling rate for audio) and generate media 132 frames at integer multiples of a common frame duration. It is possi- 133 ble, for example, that a set of users generates a packet every 10 ms, 134 while others generate packets at intervals of 20 and 30 ms, but all 135 frame generation instants must be multiples of this 10 ms interval. 136 (We expect this to be the common case for ITGs. Otherwise, each 137 media frame would require a timestamp offset or an independent 138 0 1 2 3 139 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 | RTP Header | 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | | 146 | mux header | 147 | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | user 1 media data | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | user 2 media data | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | user 3 media data | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 ...... 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | user N media data | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 timestamp, significantly increasing overhead.) This issue is dis- 161 cussed further in Section 3. Marker Bit: This field is not used for 162 multiplexing and always has a value of zero. A marker bit is included 163 for each user in the multiplexing header (see below). SSRC: This 164 field is used to identify groups of users (instead of a single user) 165 whose frames are time synchronized. This is described further in Sec- 166 tion 3. 168 The format of the multiplexing header is shown in Fig. 3. 170 0 1 2 3 171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | user 1 header | user 2 header | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | user 3 header | user 4 header | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 ...... 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | user N-1 header | user N header/padding | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 3: Multiplexing header 184 Each media data frame that is being multiplexed is associated with a 185 header, 16 bits (optionally, 32) in length. These headers indicate, 186 among other things, the length of the media data for user i present 187 in the packet (call this length Li). To determine the number of users 188 present, user headers are read until the sum of the lengths Li 189 encoded in them is equal to the remaining RTP packet length. 191 The format of each user header is shown in Fig. 4: 193 0 1 2 3 194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |M| PT |X| ID | Len | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 4: Format of user header 201 The fields have the following meaning: M: The marker bit has the same 202 definition as in [5], but applies only to the particular media frame. 203 PT: This is the payload type corresponding to the media frame. It is 204 anticipated that this field will also generally be sufficient to 205 determine the length of the data for the user. For example, a PT 206 value of 26 might indicate that the payload is 10 bytes of G.729 com- 207 pressed speech. The method by which the payload types are bound to 208 particular codec types and length values is outside the scope of this 209 document. It is envisioned, however, that signaling protocols such as 210 SIP [6] together with a session description protocol such as SDP or 211 H.323 could be used for this purpose. L: The length flag; if set to 212 one, the 16-bit length field is present. ID: The ID field is a 7-bit 213 key used to identify the user to the remote end system. It associates 214 the media data with the user identifiers contained in signaling pro- 215 tocols. For example, one gateway may set up a call through another, 216 indicating that user 38 is calling PSTN number (800) 555-1212. In 217 order to know which user data corresponds to user 38, the ID value in 218 the header would be set to 38. The value of zero is reserved (see 219 below). Length: In cases where the payload type is not sufficient to 220 determine the length of the user media data, a 16-bit length field 221 can be included. This field contains the length of the user media 222 data, in bytes. It is only present if the L bit has a value of one. 224 The user header fields appear immediately after the RTP header, inde- 225 pendent of their size. If the last user header does not end on a 32- 226 bit boundary, an additional user header with a distinguished user ID 227 of zero is added. The other fields in that padding header MUST be 228 zero. 230 The user media frames follow after the multiplexing header, packed 231 without any padding or headers between. The first user data field 232 contains the data for the user defined by the first user header 233 field, and so on. 235 Note that not every RTP packet has to contain media data frames from 236 all active users. For example, if the packetization interval for a 237 particular user is twice that of another user, only every other 238 packet will contain media frames from both users. 240 3 Multiple Packets 242 In some cases, it may not be possible to multiplex all users together 243 into the same packet. This could be because the timestamps are not 244 all the same, or because the tramsitter wants to restrict the packet 245 size. We define a set of users whose data are placed into the same 246 packet as a user group. Each user group is sent in a separate packet. 248 To distinguish packets from different user groups, the SSRC field is 249 used. The SSRC field is always the same across two packets from the 250 same user group, and always different between two packets in differ- 251 ent user groups. Packets from different user groups have different 252 sequence number spaces as well. Each user group can essentially be 253 considered a different virtual user, and it is for this reason that 254 we use the SSRC field to identify them. 256 Note that the users are only identified by their ID field, not by the 257 SSRC value of their user group. This allows a user to migrate from 258 user group to user group. Such migration may be necessary if the user 259 chooses to change media coder, which would affect its timestamp fre- 260 quency. The size of the ID field imposes a limitation of 127 users in 261 a multiplexed RTP session. Additional RTP sessions would need to be 262 opened if this number is not sufficient. Users may not migrate from 263 session to session, since ID's are only guaranteed unique within a 264 single RTP session. 266 4 Impact on QoS 268 In this section, we discuss the impact of the multiplexing protocol 269 on end to end QoS. 271 4.1 Loss 273 At first glance, it may seem that multiplexing linearly increases the 274 impact of packet loss on per user loss rates (assuming Bernoulli 275 packet losses). However, this is not the case. The fact that there 276 are more users per packet is exactly offset by the decrease in the 277 number of packets transmitted, yielding no difference between multi- 278 plexing and non-multiplexing. Mathematically, one can consider a 279 stream of packets as a Bernoulli process Xi. In the case of multi- 280 plexing, media frames from a particular user are present in each 281 packet Xi, whereas without, media frames are only present in some 282 subset, XNj, j=0..inf. However, the average value of the Bernoulli 283 process and its subsampled version are identical, so the observed 284 loss rate is unchanged. 286 In reality, losses aren't Bernoulli. However, multiplexing is likely 287 to reduce losses on the Internet, for several reasons. First, the 288 improved efficiencies mean the overall bitrate for the stream is 289 less. This has the effect of helping reduce congestion, which causes 290 losses in the first place. Secondly, many routers drop packets not 291 because of link congestion and buffer overflow, but because of pro- 292 cessing overload. A burst of small packets can overwhelm the proces- 293 sors on a typical router, causing loss. Thus, a critical characteris- 294 tic of a router is the number of packets per second it can process. 295 The multiplexing protocol has the advantage of keeping the packet 296 rates low, which can help reduce process-based losses in routers. 297 Finally, many routers use packet based queues, not byte based. Thus, 298 N packets, each of size 1/N, is N times as much buffer resource occu- 299 pancy of 1 packet of size 1. Multiplexing therefore helps improve 300 buffer usage as well. 302 Put together, we expect multiplexing to therefore improve end to end 303 observed loss rates. 305 4.2 Delay 307 One of the costs of multiplexing is delay - not packetization delay 308 (which can be effectively reduced by multiplexing) but store and for- 309 ward delays. These delays are directly proportional to link band- 310 widths. For modem speeds, the increased delays would be unacceptable. 311 However, multiplexed voice is likely to be generated by gateways with 312 much higher link speeds (T1, for example). Assuming all links are T1, 313 the delay for storing and forwarding 20 multiplexed users over 5 hops 314 is 2.2ms (assuming again G.729 with 30 ms packetization delays), 315 which is far less than other delays in the system. 317 Users of the multiplexing protocol with concerns about delays can 318 always opt to use as few users per user group as they feel comfort- 319 able with. 321 4.3 Jitter 322 The amount of jitter introduced by the multiplexing protocol depends 323 entirely on its usage. A system which uses a common payload type and 324 packetization delay among all users in a user group will suffer no 325 additional jitter through multiplexing. 327 However, schemes which involve users changing user groups and payload 328 types, and which involve mixing together different frame sizes per 329 packet, may result in additional jitter. Once again, it is up to the 330 administrator to make the appropriate tradeoff. 332 5 Security Considerations 334 There are no security considerations beyond those addressed in RTP 335 itself. The multiplexing protocol can make use of whatever encryption 336 and authentication schemes are present in RTP, SIP, H.323 or other 337 relevant protocols. 339 6 Open Issues 341 There are a few open issues: 343 1. The multiplexing gain is based entirely on the assumption of 344 synchronized packet generation among some group of users. It 345 is possible to achieve gains without this assumption by intro- 346 ducing timestamp offsets in the user header. The result is an 347 increase in jitter and header overheads, and for this reason 348 we have not taken this route. However, how valid is our 349 assumption of synchronization for gateways? 351 2. Should the length field be made mandatory? 353 3. What support is needed for this in H.323 and SIP? 355 4. How does this relate to the MPEG4 Flexmux encapsulation? 357 7 Conclusion 359 This document has specified an RTP payload format allowing multiple 360 user media frames to reside in an RTP packet. This multiplexing is 361 very useful for ITG-to-ITG communications, where it can reduce packet 362 header overhead and improve gateway scalability. 364 8 Full Copyright Statement 366 Copyright (C) The Internet Society (1998). All Rights Reserved. 368 This document and translations of it may be copied and furnished to 369 others, and derivative works that comment on or otherwise explain it 370 or assist in its implmentation may be prepared, copied, published and 371 distributed, in whole or in part, without restriction of any kind, 372 provided that the above copyright notice and this paragraph are 373 included on all such copies and derivative works. 375 However, this document itself may not be modified in any way, such as 376 by removing the copyright notice or references to the Internet Soci- 377 ety or other Internet organizations, except as needed for the purpose 378 of developing Internet standards in which case the procedures for 379 copyrights defined in the Internet Standards process must be fol- 380 lowed, or as required to translate it into languages other than 381 English. 383 The limited permissions granted above are perpetual and will not be 384 revoked by the Internet Society or its successors or assigns. 386 This document and the information contained herein is provided on an 387 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 388 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 389 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 390 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 391 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 393 9 Authors' Addresses 395 Jonathan Rosenberg 396 Rm. 4C-526 397 Bell Laboratories, Lucent Technologies 398 101 Crawfords Corner Rd. 399 Holmdel, NJ 07733 400 electronic mail: jdrosen@bell-labs.com 402 Henning Schulzrinne 403 Dept. of Computer Science 404 Columbia University 405 1214 Amsterdam Avenue 406 New York, NY 10027 407 USA 408 electronic mail: schulzrinne@cs.columbia.edu 410 10 Bibliography 412 [1] M. Handley and V. Jacobson, SDP: session description protocol, 413 Request for Comments (Proposed Standard) 2327, Internet Engineering 414 Task Force, Apr. 1998. 416 [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a 417 transport protocol for real-time applications, Request for Comments 418 (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 420 [3] International Telecommunication Union, Coding of speech at 8 421 kbit/s using conjugate-structure algebraic-code-excited linear- 422 prediction, Recommendation G.729, Telecommunication Standardization 423 Sector of ITU, Geneva, Switzerland, Mar. 1996. 425 [4] J. Rosenberg and H. Schulzrinne, Issues and options for an aggre- 426 gation service within RTP, Internet Draft, Internet Engineering Task 427 Force, Nov. 1996. Work in progress. 429 [5] H. Schulzrinne, RTP profile for audio and video conferences with 430 minimal control, Request for Comments (Proposed Standard) 1890, 431 Internet Engineering Task Force, Jan. 1996. 433 [6] M. Handley, H. Schulzrinne, and E. Schooler, SIP: Session initia- 434 tion protocol, Internet Draft, Internet Engineering Task Force, Mar. 435 1998. Work in progress.