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]