idnits 2.17.00 (12 Aug 2021) /tmp/idnits25870/draft-jaeggli-ietf-streaming-media-status-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 309. 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 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 (August 2008) is 5020 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Jaeggli 3 Internet-Draft Nokia 4 Intended status: Informational August 2008 5 Expires: February 2, 2009 7 IETF Streaming Media, Current Status 8 draft-jaeggli-ietf-streaming-media-status-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 2, 2009. 35 Abstract 37 This document describes the operation of the audio streaming service 38 provided for the IETF from IETF 62 up to the most recent (IETF 72) 39 meeting. Efforts associated with meetings prior to IETF 62 back to 40 IETF 49 as well as a proposal for the current effort were detailed in 41 the now expired draft draft-jaeggli-ietftv-ng-01.txt. The purpose of 42 this document is to inform future efforts to deliver streaming media 43 services for remote or local participants of the level of service and 44 the technology that was employed. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Current Service . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Archival Storage . . . . . . . . . . . . . . . . . . . . . . . 5 52 5. Shortcomings of the Existing Service . . . . . . . . . . . . . 5 53 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 56 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 Intellectual Property and Copyright Statements . . . . . . . . . . 8 60 1. Introduction 62 Since IETF 62 there has been an audio stream provided for each of the 63 8 scheduled meeting rooms. This service has been provided by 64 volunteers with the financial support variously of the IETF chair , 65 the IAD and by the Internet society. This audio streaming service 66 supplanted a earlier effort which provided video/audio streaming and 67 recording for two of the 8 parallel rooms. 69 This draft is intended to document the service as it is currently run 70 with the hope that this will be useful if future planning and or the 71 requirements for a production service. 73 2. History 75 The situation prior to IETF 62 is described in the now expired draft 76 draft-jaeggli-ietftv-ng-01.txt. The decision to move away from the 77 video production and ip multicast streaming model was done on the 78 basis of a couple of considerations most notably, the cost both 79 monetary and in human capital of delivering the existing service, the 80 inability to scale beyond two rooms without a significant larger 81 effort, and finally the limitations on remote usage that ip multicast 82 placed on on the audience of potential participants 84 There are essentially three sets potential consituents for the 85 streaming/recording of IETF meetings. Participants local to the IETF 86 monitor the activities of other working groups, remote participants 87 monitor working groups in which they have an interest, and finally 88 users of the archive, either for timeshifting purposes or for 89 purposes of historical couriosity. To the extent that all three 90 groups were being served poorly by the the pre-62 service, our goals 91 in providing a new service included increasing the usability for all 92 three groups. 94 It was proposed that for a new service that IP multicast transport 95 would be abandoned in favor of tcp http based mp3 streaming. This 96 approach has been demostrated to work in number of challenging 97 enviroments. In contrast to the multicast transport will likely to 98 work in situations where the participants did not have control over 99 their own network. Because of the ubitiquity of httpd streamed 100 internet radio stations, client support for this streaming model is 101 essentially ubiquitous. 103 The service moved from mixed video/audio/slides to audio only. While 104 this may have been a functional step back, it substially reduced the 105 volunteer staffing requirements to the point that instead of using an 106 average of 6 volunteers to cover two meeting rooms, a single 107 volunteer can under most circumstances manage all 8 parallel 108 meetings. 110 3. Current Service 112 The current service consists of the following components: 114 o A webserver which hosts the streaming schedule and the playlists 115 for the 8 channels, plues a unified 8 channel playlist 117 o One or more servers running the icecast-2 http streaming server. 118 Client requests on the basis of the playlists are made to these 119 systems and the audio encoders are connected to them. As 120 configured presently bandwidth requirements run approximately 121 64kb/s per client and 8xx64Kb/s for the audio streaming servers 123 o One encoder/recorder per stream. In the present setup each 124 encoder is a compact linux system running the muse internet radio 125 application and displaying to an internaly hosted vnc session 127 o one or more management workstations. The managment station is 128 used to remotely control the local vnc sessions on each of the 129 encoders visually inspect the audio meter and filter settings in 130 the muse application as well as initiate or halt recordings based 131 on the schedule or other considerations (meetings run over). 133 o Line or microphonephone level feed in each of the 8 rooms to be 134 recorded. This facility is provided by the AV contractor or 135 faciltiy used for the meeting. In some cases it must be specially 136 arraigned ahead of time.variouslly this has been provisioned 137 directly on in-room mixers (most venues) via a centralized audio 138 distribution system (as in toronoto or seoul) or via a mix as in 139 chicago. Historically the final responsiblity for securiing this 140 resource has been in the hand s of the secretariate function as 141 that is where the contractual relationship with the contractor has 142 resided. 144 o Network connectity for the encoders, is required and has been 145 traditionaly provided as part of the delivery of the IETF network 147 In total, the live audience for the service has remained relatively 148 small notwithstanding the considerable improvement in feasibility of 149 participation. Time shifting considerations, as well as the effort 150 required to participate in working group activities have in practice 151 limited maximum concurrency in remote partipants to around 100 152 simultanious users and generally much lower. That is to say that 153 local working group participation is approximately an order of 154 magnitude higher than remote. exceptions exist for particulary high 155 interest topics where people who might not otherwise participate in a 156 working group (journalists for example) choose to tune in for 157 monitoring purposes. 159 4. Archival Storage 161 Archival storage has been provided up to this point first by the 162 University of Oregon's Wideolab project and more recently by the 163 Network Startup Resource Center also at the University of Oregon. 164 This facility provides access to raw recordings during and after the 165 IETF meeting proper. At the time of this document, recordings back 166 to IETF 49 (62 for audio only) require approxmiately 350GB of 167 storage. The secretariat during the Neustar era maintained a backup 168 (not publicly available) of the archive. 170 Usage of the the archive is sporadic, but peaks for a month or two 171 following a given meeting. To some extent the usability of the 172 current archive is compromised by the lack of post-production (noted 173 in shortcomings). 175 5. Shortcomings of the Existing Service 177 The existing service has a number of notable shortcomings. Some of 178 these are a product of decisions made in order to minimize the outlay 179 of effort and capital required to field the service. Others have 180 become apparent as a product of operational experience. It would be 181 desirable to be able to alter some of the elements of the service in 182 order to address some of the more egregious limitations. 184 o Lack of direct control. Due to the headless nature of the systems 185 used for recording there is no interface to manage the recording 186 present in the the working group. working group chairs have little 187 idea if their session is in fact being recorded, if the remote 188 participants are recieving reasonable quality audio, if the 189 speakers are being picked up by the microphones etc. moreover 190 sessions that meet outside of scheduled hours are at the mercy of 191 volunteers as to whether recording of their meeting occurs or not. 192 One way to address this would be to provide web interfaces to the 193 recording system in order facilitate direct control of the 194 recorders. The current software platflorm and work flow does not 195 support this however. 197 o Limited attention... In order to deliver the service in a cost- 198 effective fashion the volunteer particpation was scaled back to a 199 single operator at a time. this results in divided attention and a 200 non-zero error rate in terms of issues like failure to initiate 201 recordings, inability to debug issues with more than one audio 202 stream in parallel and dividing time between the management 203 workstation located in the noc and the recorders located in the 204 meeting rooms. 206 o Lack of post-production. When video was being recorded, post- 207 production involved removing the recorded material prior to and 208 after the break-up of each working group, due the availability of 209 visual queues and the a fact that week resulted in only about 80 210 hours of video post-production for a given IETF meeting could be 211 performed in a couple of days. With the adavent of the recording 212 of 8 parallel tracks of recording the jump to 320 hours or more 213 worth of audio recording has made post-productio of the audio 214 infeasible given the current amount of volunteer time available. 216 o Audio only, no slides, no back channel. The are considerations 217 driven by the choice of streaming technology and the complexity of 218 interoperating with the multiple platforms used to present at the 219 IETF. Making more material available during the meeting proper 220 would require more equipement, more rigorous standardization of 221 process or probably both. 223 o Equipment aging. The equipment purchased in 2004 has aged fairly 224 gracefully but is being to suffer from attrition. Moreover, some 225 of the considerations that drove equipment choices in 2004 have 226 changed. One of the requirements for the 2004 purchase was that 227 the choosen servers be checkable as luggage, which due to 228 increased baggaged restrictions becomes increasing infeasable (the 229 8 recorders and power-supplies weigh approximately 48lb)s. While 230 smaller encoder systems are now feasible, the requirements for 231 such systems should be considered in the context of future plans 232 for the service 234 6. Conclusion 236 As when the transition from mutlicast to the audio streaming service 237 was made there are both challanges and oportunites in the present 238 situation. The service as it stands now requires little enough 239 effort to deliver that it can be handled at the current service level 240 by one person.Even so it needs an update. It could be expanded to 241 include new services if there is energy to do so. Some effort should 242 be made to preserve the legacy that is the present in the recorded 243 materials from IETF 49 to present. 245 7. Acknowledgements 247 The current IETF streaming effort has been generously support by a 248 large cast of characters Including the present and previous IETF 249 chairs, the Internet Society, thesecretariat in several of it's 250 forms, the University of Oregon, and numerous volunteers who have 251 expended time energy and capital to keep this service going. . 253 8. IANA Considerations 255 This memo includes no request to IANA. 257 9. Security Considerations 259 This document does not engender any security considerations. 261 Author's Address 263 Joel Jaeggli 264 Nokia 265 313 Fairchild Drive 266 Mountain View, CA 94043 268 Phone: +1 650 625 2013 269 Email: joel.jaeggli@nokia.com 271 Full Copyright Statement 273 Copyright (C) The IETF Trust (2008). 275 This document is subject to the rights, licenses and restrictions 276 contained in BCP 78, and except as set forth therein, the authors 277 retain all their rights. 279 This document and the information contained herein are provided on an 280 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 281 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 282 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 283 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 284 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 285 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 287 Intellectual Property 289 The IETF takes no position regarding the validity or scope of any 290 Intellectual Property Rights or other rights that might be claimed to 291 pertain to the implementation or use of the technology described in 292 this document or the extent to which any license under such rights 293 might or might not be available; nor does it represent that it has 294 made any independent effort to identify any such rights. Information 295 on the procedures with respect to rights in RFC documents can be 296 found in BCP 78 and BCP 79. 298 Copies of IPR disclosures made to the IETF Secretariat and any 299 assurances of licenses to be made available, or the result of an 300 attempt made to obtain a general license or permission for the use of 301 such proprietary rights by implementers or users of this 302 specification can be obtained from the IETF on-line IPR repository at 303 http://www.ietf.org/ipr. 305 The IETF invites any interested party to bring to its attention any 306 copyrights, patents or patent applications, or other proprietary 307 rights that may cover technology that may be required to implement 308 this standard. Please address the information to the IETF at 309 ietf-ipr@ietf.org.