Internet Engineering Task Force J. Jaeggli
Internet-Draft Nokia
Intended status: Informational August 2008
Expires: February 2, 2009
IETF Streaming Media, Current Status
draft-jaeggli-ietf-streaming-media-status-00
Status of this Memo
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.
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 February 2, 2009.
Abstract
This document describes the operation of the audio streaming service
provided for the IETF from IETF 62 up to the most recent (IETF 72)
meeting. Efforts associated with meetings prior to IETF 62 back to
IETF 49 as well as a proposal for the current effort were detailed in
the now expired draft draft-jaeggli-ietftv-ng-01.txt. The purpose of
this document is to inform future efforts to deliver streaming media
services for remote or local participants of the level of service and
the technology that was employed.
Jaeggli Expires February 2, 2009 [Page 1]
Internet-Draft IETF Streaming August 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Current Service . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Archival Storage . . . . . . . . . . . . . . . . . . . . . . . 5
5. Shortcomings of the Existing Service . . . . . . . . . . . . . 5
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Jaeggli Expires February 2, 2009 [Page 2]
Internet-Draft IETF Streaming August 2008
1. Introduction
Since IETF 62 there has been an audio stream provided for each of the
8 scheduled meeting rooms. This service has been provided by
volunteers with the financial support variously of the IETF chair ,
the IAD and by the Internet society. This audio streaming service
supplanted a earlier effort which provided video/audio streaming and
recording for two of the 8 parallel rooms.
This draft is intended to document the service as it is currently run
with the hope that this will be useful if future planning and or the
requirements for a production service.
2. History
The situation prior to IETF 62 is described in the now expired draft
draft-jaeggli-ietftv-ng-01.txt. The decision to move away from the
video production and ip multicast streaming model was done on the
basis of a couple of considerations most notably, the cost both
monetary and in human capital of delivering the existing service, the
inability to scale beyond two rooms without a significant larger
effort, and finally the limitations on remote usage that ip multicast
placed on on the audience of potential participants
There are essentially three sets potential consituents for the
streaming/recording of IETF meetings. Participants local to the IETF
monitor the activities of other working groups, remote participants
monitor working groups in which they have an interest, and finally
users of the archive, either for timeshifting purposes or for
purposes of historical couriosity. To the extent that all three
groups were being served poorly by the the pre-62 service, our goals
in providing a new service included increasing the usability for all
three groups.
It was proposed that for a new service that IP multicast transport
would be abandoned in favor of tcp http based mp3 streaming. This
approach has been demostrated to work in number of challenging
enviroments. In contrast to the multicast transport will likely to
work in situations where the participants did not have control over
their own network. Because of the ubitiquity of httpd streamed
internet radio stations, client support for this streaming model is
essentially ubiquitous.
The service moved from mixed video/audio/slides to audio only. While
this may have been a functional step back, it substially reduced the
volunteer staffing requirements to the point that instead of using an
average of 6 volunteers to cover two meeting rooms, a single
Jaeggli Expires February 2, 2009 [Page 3]
Internet-Draft IETF Streaming August 2008
volunteer can under most circumstances manage all 8 parallel
meetings.
3. Current Service
The current service consists of the following components:
o A webserver which hosts the streaming schedule and the playlists
for the 8 channels, plues a unified 8 channel playlist
o One or more servers running the icecast-2 http streaming server.
Client requests on the basis of the playlists are made to these
systems and the audio encoders are connected to them. As
configured presently bandwidth requirements run approximately
64kb/s per client and 8xx64Kb/s for the audio streaming servers
o One encoder/recorder per stream. In the present setup each
encoder is a compact linux system running the muse internet radio
application and displaying to an internaly hosted vnc session
o one or more management workstations. The managment station is
used to remotely control the local vnc sessions on each of the
encoders visually inspect the audio meter and filter settings in
the muse application as well as initiate or halt recordings based
on the schedule or other considerations (meetings run over).
o Line or microphonephone level feed in each of the 8 rooms to be
recorded. This facility is provided by the AV contractor or
faciltiy used for the meeting. In some cases it must be specially
arraigned ahead of time.variouslly this has been provisioned
directly on in-room mixers (most venues) via a centralized audio
distribution system (as in toronoto or seoul) or via a mix as in
chicago. Historically the final responsiblity for securiing this
resource has been in the hand s of the secretariate function as
that is where the contractual relationship with the contractor has
resided.
o Network connectity for the encoders, is required and has been
traditionaly provided as part of the delivery of the IETF network
In total, the live audience for the service has remained relatively
small notwithstanding the considerable improvement in feasibility of
participation. Time shifting considerations, as well as the effort
required to participate in working group activities have in practice
limited maximum concurrency in remote partipants to around 100
simultanious users and generally much lower. That is to say that
local working group participation is approximately an order of
Jaeggli Expires February 2, 2009 [Page 4]
Internet-Draft IETF Streaming August 2008
magnitude higher than remote. exceptions exist for particulary high
interest topics where people who might not otherwise participate in a
working group (journalists for example) choose to tune in for
monitoring purposes.
4. Archival Storage
Archival storage has been provided up to this point first by the
University of Oregon's Wideolab project and more recently by the
Network Startup Resource Center also at the University of Oregon.
This facility provides access to raw recordings during and after the
IETF meeting proper. At the time of this document, recordings back
to IETF 49 (62 for audio only) require approxmiately 350GB of
storage. The secretariat during the Neustar era maintained a backup
(not publicly available) of the archive.
Usage of the the archive is sporadic, but peaks for a month or two
following a given meeting. To some extent the usability of the
current archive is compromised by the lack of post-production (noted
in shortcomings).
5. Shortcomings of the Existing Service
The existing service has a number of notable shortcomings. Some of
these are a product of decisions made in order to minimize the outlay
of effort and capital required to field the service. Others have
become apparent as a product of operational experience. It would be
desirable to be able to alter some of the elements of the service in
order to address some of the more egregious limitations.
o Lack of direct control. Due to the headless nature of the systems
used for recording there is no interface to manage the recording
present in the the working group. working group chairs have little
idea if their session is in fact being recorded, if the remote
participants are recieving reasonable quality audio, if the
speakers are being picked up by the microphones etc. moreover
sessions that meet outside of scheduled hours are at the mercy of
volunteers as to whether recording of their meeting occurs or not.
One way to address this would be to provide web interfaces to the
recording system in order facilitate direct control of the
recorders. The current software platflorm and work flow does not
support this however.
o Limited attention... In order to deliver the service in a cost-
effective fashion the volunteer particpation was scaled back to a
single operator at a time. this results in divided attention and a
Jaeggli Expires February 2, 2009 [Page 5]
Internet-Draft IETF Streaming August 2008
non-zero error rate in terms of issues like failure to initiate
recordings, inability to debug issues with more than one audio
stream in parallel and dividing time between the management
workstation located in the noc and the recorders located in the
meeting rooms.
o Lack of post-production. When video was being recorded, post-
production involved removing the recorded material prior to and
after the break-up of each working group, due the availability of
visual queues and the a fact that week resulted in only about 80
hours of video post-production for a given IETF meeting could be
performed in a couple of days. With the adavent of the recording
of 8 parallel tracks of recording the jump to 320 hours or more
worth of audio recording has made post-productio of the audio
infeasible given the current amount of volunteer time available.
o Audio only, no slides, no back channel. The are considerations
driven by the choice of streaming technology and the complexity of
interoperating with the multiple platforms used to present at the
IETF. Making more material available during the meeting proper
would require more equipement, more rigorous standardization of
process or probably both.
o Equipment aging. The equipment purchased in 2004 has aged fairly
gracefully but is being to suffer from attrition. Moreover, some
of the considerations that drove equipment choices in 2004 have
changed. One of the requirements for the 2004 purchase was that
the choosen servers be checkable as luggage, which due to
increased baggaged restrictions becomes increasing infeasable (the
8 recorders and power-supplies weigh approximately 48lb)s. While
smaller encoder systems are now feasible, the requirements for
such systems should be considered in the context of future plans
for the service
6. Conclusion
As when the transition from mutlicast to the audio streaming service
was made there are both challanges and oportunites in the present
situation. The service as it stands now requires little enough
effort to deliver that it can be handled at the current service level
by one person.Even so it needs an update. It could be expanded to
include new services if there is energy to do so. Some effort should
be made to preserve the legacy that is the present in the recorded
materials from IETF 49 to present.
Jaeggli Expires February 2, 2009 [Page 6]
Internet-Draft IETF Streaming August 2008
7. Acknowledgements
The current IETF streaming effort has been generously support by a
large cast of characters Including the present and previous IETF
chairs, the Internet Society, thesecretariat in several of it's
forms, the University of Oregon, and numerous volunteers who have
expended time energy and capital to keep this service going. .
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
This document does not engender any security considerations.
Author's Address
Joel Jaeggli
Nokia
313 Fairchild Drive
Mountain View, CA 94043
Phone: +1 650 625 2013
Email: joel.jaeggli@nokia.com
Jaeggli Expires February 2, 2009 [Page 7]
Internet-Draft IETF Streaming August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
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 February 2, 2009 [Page 8]