IETFTV BOF J. Jaeggli Internet-Draft University of Oregon Expires: December 11, 2005 June 9, 2005 Next Generation Effort for IETF Multicast/Unicast Delivery draft-jaeggli-ietftv-ng-01 IPR Statement "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79." Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 11, 2005. This document may only be posted in an Internet-Draft. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This memo describes one proposal for continuing and expanding the broadcast and recording effort while reducing the number of volunteers required and the expenses associated with providing the previous service Jaeggli Expires December 10, 2005 [Page 1] Internet-Draft IETFTV-NG June 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Historical Efforts . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Equipment . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Expenses . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Shortcomings . . . . . . . . . . . . . . . . . . . . . . . 5 3. New Effort . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Software Platform . . . . . . . . . . . . . . . . . . . . 6 3.2 Hardware Platform . . . . . . . . . . . . . . . . . . . . 6 3.3 Server Resources . . . . . . . . . . . . . . . . . . . . . 7 3.4 Meeting Room Requirements . . . . . . . . . . . . . . . . 8 3.5 Volunteer Requirements . . . . . . . . . . . . . . . . . . 8 3.6 Post Production . . . . . . . . . . . . . . . . . . . . . 9 3.7 Expenditures . . . . . . . . . . . . . . . . . . . . . . . 9 4. IETF 62 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Equipment Procurement . . . . . . . . . . . . . . . . . . 10 4.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4 Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5 Audience . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. The Future . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 A. Appendix 1 - IETFTV BOF summary . . . . . . . . . . . . . . . 14 B. Appendix 2 - Possible Hardware Configuration . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Jaeggli Expires December 10, 2005 [Page 2] Internet-Draft IETFTV-NG June 2005 1. Introduction With recent changes in the IETF and ways in which interested parties participate, there is a push to overhaul the mechanisms that are provided for remote participation and working group meeting archiving. For the past several years, two sessions have been multicast at two or more bit rates (low and high). These sessions have also been recorded and made available relatively soon after the meeting. More recently, experiments have been conducted in an attempt to add additional rooms with unicast support but only audio. At this point, the IETF is at a cross-roads. Because of perceived changes in remote participant needs and funding availability, the IETF needs to decide what is needed in terms of service to users. Furthermore, an analysis needs to be done on what this service will cost and whether there is budget to support it. This document proposes one possible approach, intended to expand meeting coverage while reducing the volunteers required to support this effort, and devels into the effort to deploy this approach at IETF 62 Jaeggli Expires December 10, 2005 [Page 3] Internet-Draft IETFTV-NG June 2005 2. Historical Efforts Since IETF 49 the University of Oregon Videolab in collaboration with the University of California Santa Barba, various corporate partners the Secretariat and the IETF chair have scheduled and then multicast, the working groups that meet in 2 of the 6 to 8 parallel tracks scheduled every day while the IETF meets. 2.1 Equipment At present the resources required for each track recorded are as follows: o two cameras o a VGA scan converter o video source selector o audio distribution amplifier o 3 cable runs of approximately 15-20M o as many PCs to encode as source formats are required o an ethernet switch attached to a multicast capable network o a kvm switch, monitor keyboard and mouse o 1 Camera operator per track is required, in practice 2 to 3 volunteers per track spell each other over the course of the week o 1 person and an additional host computer are required to monitor the encoder hosts and output for both tracks 2.2 Expenses Typically the University of Oregon has provided 2 to 3 persons and shipped the bulk of the equipment (Cameras reside with the secretariat). Additional volunteers from UCSB and elsewhere have be funded through the IETF chair's ISOC funds or through the meeting local host, if provided by them. Domestically in the United States expenses run about $2000 per person for the duration of the meeting, internationally $3000 and up depending on the meeting location. Shipping equipment has cost anywhere from $5000 domestically to $10,000 internationally. Jaeggli Expires December 10, 2005 [Page 4] Internet-Draft IETFTV-NG June 2005 2.3 Shortcomings The current effort, despite all it successes has several obvious shortcomings: o Multicast deployment is required at end sites in order to receive multicast sources. While one of the University of Oregon's principle goals was and is multicast network deployment evangelism, many people who would like to receive the sources have little or no control over their network transport and are therefore unable to receive the sources. o Poor scaling properties. While multicast delivery had decent scaling properties if audience size increases, covering one additional room under the current model requires a 50% increase in manpower and equipment. covering all 8 tracks would require on the order of a 4 fold increase in manpower and equipment o Equipment is expensive to ship and aging. The cameras (purchased by the IETF chair) are close to 6 years old. The kit of equipment provided by the University of Oregon is the third generation of equipment we have invested in, nevertheless large parts of it are approaching 3 years old. The kit is increasingly hard for The U of O to maintain. Shipping it, (2 large and 1 small flight cases, about 200KG) represents the largest single expense in supporting the IETF multicast o Poor clarity of mission. There are at least three major constituencies who are served by the multicast effort, none particularly well, remote participants and observers are placed at a disadvantage by the multicast requirements, the lack of complete meeting coverage and the subsequent gaps in the archive. IETF attendees have expressed a desire, to be able to monitor the activities of one working group while participating in another, and likewise are not well served by an incomplete record. Consumers of the record only, obviously have the same limitations due to coverageas the previous two groups Jaeggli Expires December 10, 2005 [Page 5] Internet-Draft IETFTV-NG June 2005 3. New Effort The new effort should meet three simple goals. It should be accessible to people with or without multicast connectivity, including availability on the wireless network for those attending the meeting, without adverse performance implications. It should be able to cover as many tracks as are scheduled in parallel. It should be sufficiently inexpensive that it can be funded as part of the ongoing operation of the IETF. The proposal Hinges on delivering a basic, audio-only unicast stream using a purpose-built but off-the-shelf hardware kit, and remote servers, leveraging the reduction in production resources (hardware, camera operators, management) to control costs while expanding to cover the whole IETF meeting schedule. 3.1 Software Platform For IETF 60 and 61 we experimented in a limited basis (4 rooms at 60, 2 rooms at 61) with an application, MUSE <http://muse.dyne.org> that provided a command line, curses, and X11 interface to stream via unicast http an mp3 or ogg audio stream through an Icecast 1 or 2 style server application or interoperable implementation such as Shoutcast or the Apple Darwin streaming server. Client support for this type of unicast delivery appears broad, with most platform's native media players (Quicktime, Real, Winamp, Mplayer, Windows Media Player, etc) being able to handle the stream, allowing us to leverage the current popularity of MP3 streaming used by internet-radio applications. Muse has several desirable properties: o It is open source, and is under active development. o As a command-line application it can be operated and monitored remotely relatively easily. o It is capable of simultaneously streaming and recording the mp3 audio stream. o It can embed a limited amount of meta-data in the recording and the stream about the program being received It is envisioned that a single operator can simultaneously monitor all eight of the streaming boxes from a central location, experience gained during ietf60 suggest that this is feasible. 3.2 Hardware Platform The hardware platform will consist of small headless (no keyboard or Jaeggli Expires December 10, 2005 [Page 6] Internet-Draft IETFTV-NG June 2005 monitor) computers running Linux capable of being centrally managed. For audio-only streaming the principle requirements are a supported full-duplex sound chipset with microphone and line-level inputs, ethernet and a local drive for recording. Additionally form-factor should dictate purchasing, it would be highly desirable if 8 of these units were sufficiently small the be packable as lugguage. One possible configuration might be built around mini-itx platform (17x17cm motherboard) would contain a 1ghz via c3 processor 256MB of ram a 40GB drive and be approximately 170x50x250mm and 2kg. Such units could be sourced for $500 or less each. While that is approximately the cost of an inexpensive laptop, mini-itx computers are about 1/2 the volume and weight of a laptop offering. A Dell Inspiron 1150 for example retails for $699 but is 45x329x275mm and about 3.5kg Miscellaneous additional hardware items needed to support recording are some kind of management workstation, (a laptop could be pressed into service there) cables to mate with the room mixer, various length ethernet jumpers and appropriate luggage for hardware to travel in. In total initial equipment outlay ought to cost less than $5000. Equipment that will have have to be purchased immediatly, to be owned by the IETF: o 8 audio streaming hosts at $500ea o Luggage style flight-case suitable to transport 8 hosts plus appropiate cable $500 o Misc cables to support various audio interconnects $200 Equipment that can provided through volunteer efforts (Joel Jaeggli): o Management workstation o Room Length Ethernet runs o Misc cables to support various audio interconnects 3.3 Server Resources Unlike the multicast services which requires no servers to deliver streams to clients, for the unicast streams sufficient server resources and transit bandwidth must be available to serve client demand. As delivered mp3 audio streams will vary between 32 and 64Kb/s multiplied by the number of clients joined. During the IETF Jaeggli Expires December 10, 2005 [Page 7] Internet-Draft IETFTV-NG June 2005 60 test, peak utilization of ~40 clients never exceeded 2.5Mb/s. While it is possible that servers could be located on the IETF conference network, doing so places an additional, possibly undesirable expectation on the host, According the University of Oregon and ISI's Postel center have offered to host servers. A server is a Linux or UNIX host running the Darwin Streaming Server or shoutcast 2 server, additional servers can be deployed when resources are insufficient on existing servers. At present, the University of Oregon has two such servers available. 3.4 Meeting Room Requirements In some key respects, delivering unicast audio will reduce requirements on the secretariat, hosting entity, working group chairs, participants and multicast volunteers, it adds some requirements as well. o Currently the secretariat schedules multicast rooms, this will no longer be required as all rooms will be covered. o Currently the hosting entity is responsible for providing an ethernet drop in each multicast room on a multicast enabled subnet, instead one drop per meeting room will be required, attached to either the terminal room or general conference network. Meeting room connectivity can leverage the network built to support the wireless in most cases. o A sound system will have to provided in all rooms where recording is desired, presently one is provided in most rooms. Costs of providing sound for additional rooms if necessary are best determined by the secretariat. o Working group chairs and participants will need to enforce microphone discipline, stating their name for the record and using the microphone for meeting participation. 3.5 Volunteer Requirements The volunteer requirements ought to be as low as two person outside of the additional requirements placed on the secretariat and the host. Two volunteers should all one person to monitor all 8 rooms and remote servers while the other is free for trouble-shooting and post production tasks. Additional host requirements (more network drops) ought to be offset by the reduced complexity of the network and the fact that it leverages network assets that have to be deployed anyway Jaeggli Expires December 10, 2005 [Page 8] Internet-Draft IETFTV-NG June 2005 Costs associated with funding volunteers should be similar to current expenses. On a per-person basis, order of $2000 per meeting domestically in the United States (assuming volunteers originate from there). Reimbursable expenses will be submitted through the IETF chair. 3.6 Post Production Currently post production of video captured during the IETF is quite an involved process, and due to the size of the files created, and the overhead of delivering transcoded video for the archive can require several weeks of volunteer effort. The only post production the audio recording should require would be removal of any audio recorded prior to the commencement or after the completion of the meeting and the amending of timestamped filenames to a format that allows the identification of each meeting. It is envisioned that principle post production tasks for audio can be performed during the course of an IETF meeting and the finished product should be available to observers and attendees before the minutes are published, much as the raw unedited video files are now. 3.7 Expenditures This proposal has about $5000 in immediate expenditures related to hardware purchases. Additionally, recurring costs to provide two volunteers to support the, effort are estimated at around $4000 per meeting. This proposal may place finacial expectations on the secretariat if sound systems have to be provided in additional rooms above and beyond what would otherwise be provisioned. Jaeggli Expires December 10, 2005 [Page 9] Internet-Draft IETFTV-NG June 2005 4. IETF 62 4.1 Budget Actual expenditures covered by ISOC for hardware aquisition totaled $3,453.49. The travel and lodging expenses for the one reimbursed volunteer, totaled $1,559.03. 4.2 Equipment Procurement Apart from the fact that substanital cost savings were realized over and above the downwardly resvised estimates, hardware was straightforward and worked as originally envisioned. Lower costs were principally realized through volume discounts on some of the components, and time constraints limiting the purchase of audio and network cabling that ended up being loaned by volunteers or the University of Oregon. In it's entirety, hardware aquisition occupied the span of one month only, with some assembly tasks being completed the day prior to departure for the IETF meeting. Despite time constraints, almost all of the hardware functioned as expected, one of the servers failed due to a bad power supply (since rectified), and was replaced by a server loaned from the University of Oregon. 4.3 Deployment Due to the efforts of the volunteer hosts, ports on a subnet devoted to the streaming were deployed in all of the 8 scheduled meeting rooms. Each host was initially cabled to the ethernet in the room and booted with a laptop acting as serial console attached in order to determine the IP address that the host aquired. IP addresses were subsequently added to the DNS to facilitate remote managment. In the future geting the hosts to update the DNS dynamically or simply recording the mac addresses of the servers would have reduced the number of setup steps considerably. It became apparent in testing of the software proposed for encoding and streaming (muse) in the lab, that some of the desirable functionality of the software was available only from it's gtk gui interface, rather than it's curses text console base interface. The solution adopted was run to run a VNC server on each servers, which functioned as a local xserver, The VNC server could then be attached to a remote management station over ssh to manipulate the applications running locally on each server. In practice, the VNC as local xserver model proved quite successful having survived managment workstation detachments, crashes, and network connectivity Jaeggli Expires December 10, 2005 [Page 10] Internet-Draft IETFTV-NG June 2005 interuptions. 4.4 Operation There are 5 kinds of host involved In delivering audio to an end user. Clients, directed by a link from the IETF meeting webpage are directed to a webpage. They select either to join a particul room a or download a playlist into their media player which includes all of the available rooms. The client then connects to the darwin/ shoutcast streaming server refered to, in the playlist which is recieving an audio stream from the server located in the corresponding IETF meeting room. Operation of the encoders is directed by a manangment workstation, which controls the encoders through remote vnc sessions and is able to monitors the audio output of the darwin shoutcast server as a client. The principal problems with operation at IETF 62 hinge around the operation of the managment workstation. While software makes it possible to monitor all of the servers and audio streams for availability, it's infeasbile for the workstation user to monitor more than one of the audio streams a time. If only one operator is working at a time, traveling from the noc to a room where an issue is present (loss of network connectivity, no audio, poor audio) results in dividing that person's attention. While the managment workstation resided in the noc and sat on the same network with the streaming servers, switching over to the wireless network for debuging was hampered by the tenuous state of the wireless network early in the meeting, and to the extent that things like audio streams would not stay up while roaming between ap's (ie. running from one end of the building to the other with a laptop) continued to remain elusive throughout the meeting. Given some of the shortcomings only a few screwup's resulted in the the loss of recordings, Fewer even than would ordinarily be expected from the video recording, despite a four-fold increase in the amount of recording. Some of this stability increase can likely been attributed to the elimination of Windows NT and 2000 based servers entirely (no crashes other than the manangment workstation), but a greater part was part was probably played by the simplification in the encoding, and a reduction in the number of operators to 2 rather than 6 or 8 required for the multicast delivery and camera operation. 4.5 Audience For the first time, a remote audience received almost complete access to the proceedings of the IETF as they happened. Because delivery of the audio was entirely unicast we have logs that provide a far more accurate picture of the size of the audience. Jaeggli Expires December 10, 2005 [Page 11] Internet-Draft IETFTV-NG June 2005 Over the course of the Week at IETF 62, 552 unique hosts made 4409 requests that resulted in data being streamed. Of those requestes, 702 where made from the conference network. Feedback, from remote users was generally positive, however it points to a few kinks that could stand to be be rectified. Some commentors noted that not all slide decks where available at the time a working group met. Microhpone protocol was not universally observed particulary in small groups although this improved by the end of the week. In the example of the snmp mib working group the 5 particpants in the room included an area director and the working-group chair, another area director followed along remotely... There appears to be substantial interest on the part of local participants at the ietf meeting to monitor sessions in which they are not physicaly participating. If slightly less than a quater of all monitoring occurs from the local network it speaks well to the accessibility of the audio streaming to the group, for which the multicast streaming was not previously accessible. Jaeggli Expires December 10, 2005 [Page 12] Internet-Draft IETFTV-NG June 2005 5. The Future When we planned the transition to audio-only unicast streaming for IETF62, the intention was to field a service that was inexpensive enough that it could be replicated at subsequent IETF meetings. I believe that goal has been achieved. Assuming the same sources are willing to provide funding at similar levels into the future there is no reason to believe that we couldn't replicate the exercise at IETF 63, and beyond. Author's Address Joel Jaeggli University of Oregon 1212 University of Oregon Eugene, Oregon 97405 USA Phone: +1-541-346-1716 Fax: +1-5413464397 Email: joelja@uoregon.edu Jaeggli Expires December 10, 2005 [Page 13] Internet-Draft IETFTV-NG June 2005 Appendix A. Appendix 1 - IETFTV BOF summary From falk@isi.edu Tue Dec 7 13:45:26 2004 Date: Tue, 7 Dec 2004 13:44:53 -0800 From: Aaron Falk falk@isi.edu To: minutes@ietf.org Cc: ietfcast@lists.uoregon.edu Subject: ietfcast: ietf-tv summary for the IETF-61 proceedings Summary of the IETF-TV BoF BoF Chair: Ole Jacobsen Notes taken by: Aaron Falk The purpose of the IETF-TV BoF was to discuss in what way multimedia capture of IETF meetings would best serve the community. Multicast was used by volunteers to provide audio and digital whiteboard tools starting in 1992. Tools and encoding formats evolved over the years until the present day where two rooms at each IETF are covered using MPEG-1 video and H.261/PCM audio four additional rooms with MP3 audio only. The streams are made available using ASM and SSM multicast (some individuals provide unicast reflectors) and the files are post- processed and stored in an online repository for viewing after the meeting. At IETF-60, there were about 20 "viewers" per meeting (ed: IETF or wg meeting?) with a peak of about 70. Feedback from the audio-only sessions was that it was hard to follow the meeting without some visual feedback, preferably the ability to view the slides. There have been 100's to 1000's of downloads of online files. The staffing and travel and equipment expenses have been borne by University of Oregon (UofO) with some assistance from Cisco and the IETF Chair fund. Typical requirements are 6 weeks/year for preparation; staffing and post-processing, 4-6 people (historically students) to operate the equipment during the IETF meeting; $10k for shipping (ed: per meeting? per year?); bandwidth for streaming and download (broadband, real-time bandwidth and server requirements are non-trivial). However, most of the expense is associated with the video capture: camera operators (labor and travel) and specialized equipment are required. The UofO is unwilling to shoulder staffing, and has run out of Cisco-provided funding that allowed their staff to Jaeggli Expires December 10, 2005 [Page 14] Internet-Draft IETFTV-NG June 2005 travel and ship their equipment. The UofO never provided any significant financial support outside of staff. Several questions therefore arise: What problem is being solved by this service? Remote participation? Broadcast to a remote (non-participatory) audience? Creating a public record? It is estimated that a professional staff would cost about ~$50k/ meeting (based on similar hotel events). Various strategies of cost recovery were discussed including increasing meeting fees (~$25), charging online viewers ($100), selling CDs (~$100ea) or finding sponsors (~$25k/yr). There was a general conclusion that some form of service is useful and of interest but there were no clear recommendations identifying a primary audience or of cost recovery. No working group will be created from this BoF. ietfcast resources: _________________________________________________ user interface: http://darkwing.uoregon.edu/~llynch/ietfcast.html web archive: http://darkwing.uoregon.edu/~llynch/ietfcast/index.html Jaeggli Expires December 10, 2005 [Page 15] Internet-Draft IETFTV-NG June 2005 Appendix B. Appendix 2 - Possible Hardware Configuration One of The lessons to be taken away from previous efforts is that shipping and maintenance of the equipment necessary to provide the former service was one of the most expensive and time-consuming parts of the effort. With that mind, and the goal of simplifying the equipement, a more compact, rugged, and inexpensive computer is needed. The actual cpu requirements for audio encoding are signficantly more lightweight than delivering mpeg-4 video, a great assistance in reducing the scale of the equipment necessary to support this effort. One possible configuration that would be appropriate for our application follows (all costs are approximate): o Casetronic c134 aluminum chassis (dimesions 177 x 50 x 254mm) 60w external powesupply $150 o Via epia m1000 mainboard integrated ethernet, sound, video, ieee1394, usb2 1ghz via c3 cpu $160 o 256MB unbuffered pc2100 ddr dimm memory module $50 o 40GB 2.5" laptop harddrive $80 o cable lock $20 o Total: $460 Jaeggli Expires December 10, 2005 [Page 16] Internet-Draft IETFTV-NG June 2005 Full Copyright Statement "Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Jaeggli Expires December 10, 2005 [Page 17] Internet-Draft IETFTV-NG June 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jaeggli Expires December 10, 2005 [Page 18]