From rem-conf Thu Jan 01 15:23:02 1998 From rem-conf-request@es.net Thu Jan 01 15:23:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xntlp-0000wG-00; Thu, 1 Jan 1998 15:11:21 -0800 Date: Thu, 1 Jan 1998 23:11:17 GMT From: ralph20@ibm.net Message-Id: <199801012311.XAA39236@out2.ibm.net> X-Sender: ralph20@pop03.ca.us.ibm.net X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubsribe marchil@wcb.gov.on.ca unsubscribe ralph20@ibm.net From rem-conf Thu Jan 01 17:29:40 1998 From rem-conf-request@es.net Thu Jan 01 17:29:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xnvrj-00022W-00; Thu, 1 Jan 1998 17:25:35 -0800 Message-ID: <34AC4062.4EAA5B6C@KEGO.COM> Date: Thu, 01 Jan 1998 17:18:26 -0800 From: Cameron Elliott Organization: KEGO - Software & Datacommunications X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: G.723.1 RTP payload format? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -- I'm curious is there a RTP payload format specification for G.723.1 inside RTP? Or does G.723.1 not really need a payload format, and just follows the RTP header? (If so, do you just leave the marker bit clear?) Thanks Cameron Elliott -- Cameron Elliott Kego - Software & Datacommuncations Unix, Embedded Software, TCP/IP, H.323 888-FOR-KEGO Cam@Kego.com From rem-conf Fri Jan 02 09:01:25 1998 From rem-conf-request@es.net Fri Jan 02 09:01:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xoAAg-0007Sg-00; Fri, 2 Jan 1998 08:42:06 -0800 Message-ID: <34AD1857.24EDE39C@dnrc.bell-labs.com> Date: Fri, 02 Jan 1998 11:39:51 -0500 From: "Jonathan D. Rosenberg" Reply-To: jdrosen@dnrc.bell-labs.com X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Cameron Elliott CC: rem-conf@es.net Subject: Re: G.723.1 RTP payload format? References: <34AC4062.4EAA5B6C@KEGO.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The next version of RFC 1890 (http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-profile-new-02.txt) specifies how to encapsulate g.723.1. You are correct in that there are no additional header fields required for it. -Jonathan R. Cameron Elliott wrote: > > -- > I'm curious is there a RTP payload format specification > for G.723.1 inside RTP? > > Or does G.723.1 not really need a payload format, and just > follows the RTP header? > (If so, do you just leave the marker bit clear?) > > Thanks > Cameron Elliott > > -- > Cameron Elliott > > Kego - Software & Datacommuncations > Unix, Embedded Software, TCP/IP, H.323 > > 888-FOR-KEGO > Cam@Kego.com -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (908) 949-6418 Rm. 4C-526 FAX: (908) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Jan 05 06:06:25 1998 From rem-conf-request@es.net Mon Jan 05 06:06:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xpCrv-0002W8-00; Mon, 5 Jan 1998 05:47:03 -0800 Date: Mon, 5 Jan 1998 14:34:37 +0100 (MET) X-Sender: goebel@janus.unik.no Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, end2end-interest@ISI.EDU, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase, multicomm@cc.bellcore.com, osimcast@bbn.com, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca, cost237-teleservices@comp.lancs.ac.uk, tcplw@bsdi.com From: goebel@unik.no (Vera Goebel) Subject: CfP - IDMS'98 (reminder) Cc: idms98@unik.no X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please accept our apologies if you receive multiple copies of this announcement. You will be doing us a great favor if you disseminate the this Call for papers among your interested colleagues. Thanks. **************************************************************************** REMINDER: Call for Papers IDMS'98 5th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 8. - 11. September 1998, Oslo, Norway The Fifth International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services follows the successful IDMS workshops held 1997 in Darmstadt and 1996 in Berlin. The purpose of this workshop is to bring together researchers, developers, and practitioners >from academia and industry. The workshop serves as a forum for discussion, presentation, and exploration of technologies and their advances in the broad field of interactive distributed multimedia systems and telecommunication services -- ranging from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. Case studies and papers describing experimental work are especially welcome. Relevant topics include, but are not limited to =B7 High-speed/ATM networks =B7 Mobile multimedia systems =B7 Multimedia over sattelite =B7 Multimedia middelware =B7 Quality of service issues =B7 Media scaling =B7 Resource management =B7 Protocol design and implementation =B7 Distributed multimedia database systems =B7 Development tools for distributed multimedia applications =B7 Multimedia-specific intelligent agents =B7 Computer supported collaborative work =B7 Distributed virtual reality systems =B7 Distance education =B7 Conferencing =B7 Digital libraries =B7 Interactive television =B7 Video-on-demand systems =B7 Compression algorithms IDMS'98 will consist of a three day technical program, a full day of tutorials, and demonstrations during the workshop. In order to keep the flavour of a workshop, the number of participants will be restricted. =46urthermore, we encurage contributions in form of full papers and position papers. Full papers are expected to describe innovative and significant work. The purpose of position papers is to provide a seed for debate and discussion. Position papers enable researchers to present exciting ongoing work in early stages, suggestions for future directions, and concerns about current developments. Both types of papers will be reviewed by the program committee and printed in the workshop proceedings. The proceedings will be published in the Springer LNCS series and will be available during the workshop. It is intended to forward selected papers to a special issue of the "Computer Communications" Journal. Information for authors: Authors are invited to submit full papers and position papers for review. Submitted manuscripts must describe original work (not submitted or published elsewhere). Full papers must not be longer than 20 double spaced pages and position papers must not be longer than 8 double spaced pages. Both types of papers should contain an abstract of approximately 300 words, and include title, authors and affiliations. The submission process of papers will be handled electronically. Detailed description of the electronic submission procedures is available on the IDMS'98 web page: http://www.unik.no/~idms98. Authors without web access may send mail to idms98@unik.no requesting electronic submission information. Authors unable to submit electronically are invited to send 5 copies of their contribution to one of the workshops chairs ATTN: IDMS'98. Important dates: Submission due: February 1, 1998 Notification of acceptance: April 15, 1998 Camera ready version: May 15, 1998 Workshop: September 9 - 11, 1998 Program co-chairs: Vera Goebel and Thomas Plagemann UniK - Center for Technology at Kjeller, University of Oslo, P.O. Box 70, N-2007 Kjeller, Norway Email: {goebel; plageman}@unik.no, Phone: +47/63.81.45.70, Fax: +47/63.81.81.46 Program Committee: =46. A. Aagesen, NTNU, Norway H. Affifi, ENST Bretagne, France E. Biersack, Institut Eur=E9com, France G. Bochmann, U. Montreal, Canada B. Butscher, DeTeBerkom, Germany A. T. Campbell, Columbia U., USA S. Chanson , Hongkong U., HK L. Delgrossi, U. Piacenza, Italy M. Diaz, LAAS-CNRS, France =46. Eliassen, U. Troms=F8, Norway W. Effelsberg, U. Mannheim, Germany D. Ferrari, U. Cattolica Piacenza, Italy J.-P. Hubaux, EPFL, Switzerland D. Hutchison, Lancaster U., UK W. Kalfa, TU Chemnitz, Germany T. D. C. Little, Boston U., USA E. Moeller, GMD FOKUS, Germany K. Nahrstedt, U. Illinois, USA G. Parulkar, Washington U., USA B. Pehrson, KTH Stockholm, Sweden S. Pink, SICS, Sweden B. Plattner, ETH Zurich, Switzerland H. Scholten, U. Twente, Netherlands R. Steinmetz, GMD, Germany H. Tokuda, Keio U., Japan L. Wolf, TH Darmstadt, Germany M. Zitterbart, TU Braunschweig, Germany ACM Multimedia'98 takes place in Bristol (UK) in the week following IDMS'98: http://www.acm.org/sigmm/MM98. ------------------------------------------------------------------------- Dr. Vera Goebel Tel. +47/63.81.45.71.219 (direct) Associate Professor or Tel. +47/63.81.45.70 (swichboard) UNIK Center for Technology at Kjeller University of Oslo Fax. +47/63.81.81.46 PO BOX 70 N-2007 Kjeller email: goebel@unik.no Norway http://www.unik.no/~goebel/ ------------------------------------------------------------------------- From rem-conf Mon Jan 05 07:21:44 1998 From rem-conf-request@es.net Mon Jan 05 07:21:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xpEGc-00049Q-00; Mon, 5 Jan 1998 07:16:38 -0800 Message-Id: <199801051516.KAA15955@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-new-00.txt,.ps Date: Mon, 05 Jan 1998 10:16:23 -0500 Sender: cclark@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP: A Transport Protocol for Real-Time Applications Author(s) : V. Jacobson, S. Casner, R. Frederick, H. Schulzrinne Filename : draft-ietf-avt-rtp-new-00.txt,.ps Pages : 94 Date : 02-Jan-98 This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. The revision process is not yet complete; some changes which have been discussed and tentatively accepted in meetings of the Audio/Video Transport working group have not yet been incorporated into this draft. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real- time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-new-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-new-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-new-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980102151250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980102151250.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jan 05 07:22:09 1998 From rem-conf-request@es.net Mon Jan 05 07:22:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xpEKv-0004BD-00; Mon, 5 Jan 1998 07:21:05 -0800 From: Dilip D Kandlur To: Subject: MMCN'98: Final Program and Registration Information Message-ID: <5010300014029475000002L052*@MHS> Date: Mon, 5 Jan 1998 10:19:12 -0500 MIME-Version: 1.0 Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Advance Program & Call for Participation SPIE/ACM MULTIMEDIA COMPUTING AND NETWORKING 1998 San Jose, California January 26-28 1998 Conference Kevin Jeffay, University of North Carolina at Chapel Hill Chairs Dilip Kandlur, IBMJT.J. Watson Research Center Timothy Roscoe, Persimmon I.T., Inc. Program Peter Beadle, University of Wollongong Committee Ming-Syan Chen, National Taiwan University Wu-Chi Feng, Ohio State University Martin Freeman, Philips Research J.J. Garcia-Luna-Aceves, U.C. Santa Cruz Anoop Gupta, Stanford University Mark Hayter, DEC Systems Research Center Sugih Jamin, University of Michigan at Ann Arbor Paul Jardetzky, Sun Microsystems Chuck Kalmanek, AT&T Research Ian Leslie, University of Cambridge Sape Mullender, University of Twente Klara Nahrstedt U.I. Urbana-Champaign Guru Parulkar, Washington University Lawrence A. Rowe, U.C. Berkeley Debanjan Saha, IBM T.J. Watson Henning Schulzrinne, Columbia University Doug Shepherd, Lancaster University Brian Smith, Cornell University Cormac Sreenan, AT&T Research Ralf Steinmetz, T.U. Darmstadt Harrick Vin, University of Texas at Austin Jonathan Walpole, Oregon Graduate Institute Raj Yavatkar, Intel Corporation Hui Zhang, Carnegie Mellon University Registration & hotel info can be found at URL: http://www.spie.org/web/meetings/programs/pw98/ei98_home.html +------------------------------------+ | | | Register by January 7, 1998 for | | for early registration discount!! | | | +------------------------------------+ MMCN '98 ADVANCE PROGRAM ------------------------ Monday 26 January 8.45 am: Welcome and Opening Remarks 9.00 to 10.30 am: Session 1: Multimedia System Development Tools Middleware support for distributed multimedia and collaborative computing, K. Birman, R. Friedman, M. Hayden, Cornell Univ.; I. Rhee, Emory Univ. Multiplatform simulation of video playout performance, L. Gharai, R. Gerber, Univ. of Maryland/College Park A Software-only video production switcher for the Internet MBone, T.H. Wong, K. D. Mayer-Patel, D. Simpson, L. A. Rowe, Univ. of California/Berkeley 11.00 am to 12.30 pm: Session 2: Operating Systems I Applying statistical process controls to the adaptive rate control problem: a framework for the streaming of hetergeneous streams, N. R. Manobar, M. H. Willebeek-LeMair, IBM Thomas J. Watson Research Ctr.; A. Prakash, Univ. of Michigan/Ann Arbor An integrated input/output system for kernel data streaming, F. W. Miller, S. K. Tripathi, Univ. of Maryland/College Park Measurement-based admission control and resource allocation for multimedia applications, N. Stratford, P. Barham,S. Crosby, F. Toomey, M. Huggard, Univ. of Cambridge (UK) Lunch Break 2.00 to 3.30 pm: Keynote Address: Enhanced Display Environments for Telecollaboration and Personal Computing in the Office of the Future Henry Fuchs, Federico Gil Professor of Computer Science, Univ. of North Carolina/Chapel Hill 4.00 to 5.30 pm: Session 3: Video-on-Demand Supporting interactive scanning operations in VoD systems, G. Apostolopoulos, Univ. of Maryland/College Park; M. Krunz, Univ of Arizona; S. K. Tripathi, Univ. of Maryland/College Park Modelling prerecorded compressed video streams for fast bandwidth smoothing implementations, W. C. Feng, M. Liu, C. C. Lam, The Ohio State Univ. A system for demonstrating dynamic service aggregation in VoD scenarios, P. Basu, A. Narayanan, R. Krishnan, T. D. C. Little, Boston Univ. Tuesday 27 January 8.30 to 9.15 am: Plenary Speaker Multimedia Communications: What's Next? Leonardo Chiariglione, CSELT/Telecom Italia (Italy) 9.30 to 11.00 am: Session 4: Operating Systems II Symphony: an integrated multimedia file system, P. J. Shenoy, P. Goyal, S. S. Rao, H. M. Vin, Univ. of Texas/Austin Adaptive prefetching for device independent file I/O, D. Revel, D. McNamee, D. Steere, J. Walpole, Oregon Graduate Institute of Science and Technology Resource kernels: a resoure-centric approach to real-time and multimedia systems, R. Rajkumar, K. Juvva, A. Molano, S Oikawa, Carnegie Mellon Univ. 11.15 am to 12.45 pm: Session 5: The World Wide Web Characterizing videos on the World Wide Web, S. Acharya, B. C. Smith, Cornell Univ. Static caching of Web servers, Z. Liu, P. Nain, N. Niclausse, INRIA Ctr. Sophia Antipolis (France); D. Towsley, Univ. of Massachusetts/Amherst Resource-based caching for Web servers, R. Tewari, H. M. Vin, Univ. of Texas/Austin; A. Dan, D. Sitaram, IBM Thomas J. Watson Research Ctr. Lunch/Exhibit Break 2.00 to 3.30 pm: Keynote Address: Low Latency Media Delivery in a Consumer Internet Service Michael Schwartz, Director of Server Engineering and Senior Scientist, @Home Network 4.00 to 5.30 pm: Session 6: Multimedia Applications Integrated audio-visual processing for object serialization and tracking, G. S. Pingali, Lucent Technologies/Bell Labs. Accelerating M-JPEG compression with temporal information, H. Boenisch, K. Froitzheim, P. Schulthess, Univ. Ulm (FRG) Cross-model retrieval of scripted speech audio, C. B. Owen, F. Makedon, Dartmouth College Wednesday 28 January 8:30 to 9:15am: Plenary Speaker The Computer Revolution Hasn't Happened Yet Alan Kay, Disney Fellow and Vice President of Research and Development, The Walt Disney Company 9.30 to 11.30 am: Session 7: Flow and congestion control Adaptive source rate control for wireless video conferencing, H. Liu, M. El Zarki, Univ. of Pennsylvania Flow and congestion control for internet streaming applications, S. Cen, C. Pu, J. Walpole, Oregon Graduate Institute of Science and Technology Invited Paper 11.30am to 1.00 pm: Panel Discussion: The Future of Multimedia Research, Or, What Am I Doing And Why? Moderator: Lawrence A. Rowe, University of California/Berkeley From rem-conf Mon Jan 05 09:06:44 1998 From rem-conf-request@es.net Mon Jan 05 09:06:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xpFtm-00063U-00; Mon, 5 Jan 1998 09:01:10 -0800 Message-Id: <199801051700.SAA20544@basil.cdt.luth.se> X-Mailer: exmh version 2.0.1 12/23/97 To: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-new-00.txt,.ps In-reply-to: Your message of "Mon, 05 Jan 1998 10:16:23 EST." <199801051516.KAA15955@ns.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 05 Jan 1998 18:00:54 +0100 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi On page 7 a photo URL SDES is proposed (well not really as it hasn't been discussed yet :-). How about adding an optional personal home-page URL SDES type? I have done this earlier by inventing my own SDES type (and by that breaking the specs, yes :-). The RTP specs should for both these new SDES types (if accepted :-) include text about a random delay for when the page can be retrieved from the time the URL was first known through the RTCP SDES packet. This could hinder the sudden overload of the webserver in question. /P From rem-conf Mon Jan 05 09:46:46 1998 From rem-conf-request@es.net Mon Jan 05 09:46:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xpGYD-0006qG-00; Mon, 5 Jan 1998 09:42:57 -0800 Sender: hgs@cs.columbia.edu Message-ID: <34B11B9D.1A7E1330@cs.columbia.edu> Date: Mon, 05 Jan 1998 12:42:53 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Peter Parnes CC: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-new-00.txt,.ps References: <199801051700.SAA20544@basil.cdt.luth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Peter Parnes wrote: > > Hi > > On page 7 a photo URL SDES is proposed (well not really as it hasn't been > discussed yet :-). How about adding an optional personal home-page URL SDES > type? I have done this earlier by inventing my own SDES type (and by that > breaking the specs, yes :-). > > The RTP specs should for both these new SDES types (if accepted :-) include > text about a random delay for when the page can be retrieved from the time the > URL was first known through the RTCP SDES packet. This could hinder the sudden > overload of the webserver in question. One simple and conservative approach would be to delay automatic retrieval until it is one's turn to send an SDES RR. For a low-bandwidth audio channel, this would limit total web retrieval rates to about two hits/second. For web pages instead of photos, retrievals will likely be triggered by human action, imposing some amount of randomization. Having the ability to periodically transmit a fixed JPEG or GIF image via RTP might be an alternative for the photo transmission, but would tend to use more bandwidth. > > /P From rem-conf Tue Jan 06 09:07:30 1998 From rem-conf-request@es.net Tue Jan 06 09:07:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xpcCh-0001I6-00; Tue, 6 Jan 1998 08:50:11 -0800 Message-Id: <3.0.3.32.19980106114804.032152a4@cactus.pictel.com> X-Sender: webberr@cactus.pictel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 06 Jan 1998 11:48:04 -0500 To: rem-conf@es.net From: Robert Webber Subject: H.263+ without change marks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Draft 20 of the revised H.263 ("H.263+") is available in PDF format without change marks at: http://standard.pictel.com/h263+rtp/draft20ncm.pdf From rem-conf Fri Jan 09 07:16:23 1998 From rem-conf-request@es.net Fri Jan 09 07:16:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xqfeF-0004YX-00; Fri, 9 Jan 1998 06:42:59 -0800 Message-Id: <199801091442.JAA11558@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-info-repair-02.txt Date: Fri, 09 Jan 1998 09:42:37 -0500 Sender: cclark@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Options for Repair of Streaming Media Author(s) : C. Perkins, O. Hodson Filename : draft-ietf-avt-info-repair-02.txt Pages : 9 Date : 08-Jan-98 This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-info-repair-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-info-repair-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-info-repair-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980108121409.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-info-repair-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-info-repair-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980108121409.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jan 09 09:39:05 1998 From rem-conf-request@es.net Fri Jan 09 09:39:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xqiDH-0006TG-00; Fri, 9 Jan 1998 09:27:19 -0800 Message-Id: <199801091726.SAA17383@pensee.eurecom.fr> X-Mailer: exmh version 1.6.9 8/22/96 To: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-new-00.txt,.ps In-reply-to: Internet-Drafts's message of Mon, 05 Jan 1998 10:16:23 -0500 X-Face: +*!YJ>tO{UEuAf!2V7@zr[0U)psHFTZN[i\-O$v7kkuP?Ec!\91`|l:NQZwD6EnE{nMtS*Ha9enYx^BA4PjHT.@"?7r#UaaJRB"IHEhe"O@z#V]tu:ZqyQ:DW{@SCwanC>N0FC`Z:tJ8sA}6=n{#UA4-tPht_(A\jvs+EquH?4`[_Ft,Zc?{,k9&k+WooGf#{`?}4\Ol-[]G<_)c|wMA=Ct7&#l&"[&/@.0G2[6Pr:bvR5LQl[82k9zji*(8\nk\ X-URI: http://www.eurecom.fr/~nonnen Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jan 1998 18:26:25 +0100 From: Jorg Nonnenmacher X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, The current RTCP spec requires every receiver to send a RTCP packet periodically and randomized in an interval corresponding to the number of receivers. For very popular multicasts/broadcasts with a very large number of receivers two things may be of concern: * The period for sendings of a single receiver becomes very large, such that the intended reception information of a single receiver is old (and meaningless?) * Further, for a very large number of receivers the identity of each single receiver might not be of interest. One can give a threshold for the number of receivers that allows to switch RTCP from the current mechanism to a sampling method. Another (lower) threshold can be given to switch back >from the sampling method to the everybody-sends RR RTCP. One solution to outdated reception status is to define (announce by the sender) classes of reception quality. Receivers group themselves in the defined/announced classes. The receivers are sampled by each class separately. For each class an estimate of the number of receivers can be given due to the number of responses. Joerg From rem-conf Fri Jan 09 18:56:58 1998 From rem-conf-request@es.net Fri Jan 09 18:56:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xqqs7-0002kN-00; Fri, 9 Jan 1998 18:42:03 -0800 Message-ID: <34B6DC17.3F6B8D76@dnrc.bell-labs.com> Date: Fri, 09 Jan 1998 21:25:27 -0500 From: Jonathan Rosenberg Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Jorg Nonnenmacher CC: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-new-00.txt,.ps References: <199801091726.SAA17383@pensee.eurecom.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jorg Nonnenmacher wrote: > > One can give a threshold for the number of receivers > that allows to switch RTCP from the current mechanism > to a sampling method. Another (lower) threshold can be given to switch back > from the sampling method to the everybody-sends RR RTCP. There are some problems if some people stop sending RTCP packets, and others continue, based on group size. The decision about whether to send or not will depend on the group size, but the group size is determined by people sending packets. This interrelationship can cause oscillations and other bad things. For example, lets say (in the extreme case) when the group size reaches 100, half of these stop sending RR. These members will eventually time out, and cause the group to drop back to 50. Then, since the group size is smaller, everyone starts sending again, causing a sharp increase in the group size back up to 100, and then back down again, etc. Other similar algorithms all result in these kinds of behaviors because of the ambiguity. > > One solution to outdated reception status is to define (announce by the > sender) classes of reception quality. > Receivers group themselves in the defined/announced classes. > The receivers are sampled by each class separately. > For each class an estimate of the number of receivers can be given due > to the number of responses. I think this may actually cause more oscillatory problems than the above approach. Since users will move from class to class as their reception varies, group sizes will be very dynamic to begin with, which will probably amplify the oscillations. If you want to get updates from receivers more frequently, some kind of polling from a central monitor seems more appropriate. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (908) 949-6418 Rm. 4D-534B FAX: (908) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sat Jan 10 19:38:06 1998 From rem-conf-request@es.net Sat Jan 10 19:38:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrDwh-0000nq-00; Sat, 10 Jan 1998 19:20:19 -0800 Message-ID: <34B83A88.FD9941F2@cs.columbia.edu> Date: Sat, 10 Jan 1998 22:20:40 -0500 From: Henning Schulzrinne Reply-To: hgs@cs.columbia.edu Organization: Columbia University (home) X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP QOS reports for large groups X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As Jorg Nonnenmacher points out, large groups raise a particular problem of stale QOS reports, as it is likely that each receiver will get to send at most one report covering the whole time since it joined the group. Finding out about loss averaged over an hour is only modestly useful for diagnosing problems and doesn't really tell you a whole lot about the user experience (it could have been 10% constant loss or six minutes of no reception; the first might have been hidden by local recovery, the latter wouldn't). Instead of sampling and further complicating the transmission mechanism, we might consider two alternatives that require only modest changes to the current scheme: 1) Make the indication of the RR loss fraction reflect only recent experience. 2) Add an additional RR field for recent loss experience, where recent may be the shorter of last RR transmission and, say, two minutes. A variation on the proposal by Jorg had been made earlier, namely that only those that experience problems would participate in the receiver reports, with reconsideration limiting the avalanche effect of sudden widespread QOS degradation. Getting the names of those might even be useful: "Dear Mr. Subscriber; we gather that your reception of the world boxing championship was not as good as you have a right to expect. Please accept our apologies and a coupon for Wrestlemania pay-per-view." Henning From rem-conf Sat Jan 10 20:35:22 1998 From rem-conf-request@es.net Sat Jan 10 20:35:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrF55-0001RR-00; Sat, 10 Jan 1998 20:33:03 -0800 X-Sender: tdorcey@mail.boxtop.com Message-Id: In-Reply-To: <34B83A88.FD9941F2@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 Jan 1998 21:29:27 -0700 To: hgs@cs.columbia.edu From: Tim Dorcey Subject: Re: RTP QOS reports for large groups Cc: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:20 PM -0500 1/10/98, Henning Schulzrinne wrote: >As Jorg Nonnenmacher points out, large groups raise a particular problem >of stale QOS reports, as it is likely that each receiver will get to >send at most one report covering the whole time since it joined the >group. Finding out about loss averaged over an hour is only modestly When it is a receiver's turn to send, it should send a batch of reports at fixed intervals that are small enough to be useful. So, a typical receiver's reporting times would look like: ----x-x-x-x-------------------x-x-x-x---------------x-x-x-x------------- instead of: ---x------x------x------x------x-----x-----x-----x-----x-----x-----x---- I'm not sure how much can be done with aggregate QOS reports in the first place, but at least this solves the problem of keeping them from getting too widely spaced in time. Tim From rem-conf Sat Jan 10 23:26:26 1998 From rem-conf-request@es.net Sat Jan 10 23:26:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrHkg-0002YZ-00; Sat, 10 Jan 1998 23:24:10 -0800 Date: Sat, 10 Jan 1998 23:24:53 -0800 (PST) From: Stephen Casner To: rem-conf@es.net cc: Henning Schulzrinne Subject: Re: RTP QOS reports for large groups In-Reply-To: <34B83A88.FD9941F2@cs.columbia.edu> Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I support the idea of refining the definition of the "loss fraction" field in RTCP reception reports. When that field was added (at the 1995 San Jose IETF, if memory serves), the purpose was to allow single reception reports to be useful because the interval between reports could become quite long in large groups. Because it is difficult to choose just how long a shorter measurement interval for the loss fraction should be, the consensus of the working group at that time was that the interval should still be the whole inter-report interval. That's what is currently in the spec. Some folks expressed the sentiment then that we should begin with that definition and see what we might learn during the Proposed Standard stage. I have always felt that this topic was worthy of further consideration, and I think it is appropriate to ask now as we prepare for advancement to Draft Standard status whether this aspect of the protocol should be changed. The hard problem is still there: what should be shorter interval be? - Henning Schulzrinne suggested (actually for an additional field, but I think it could also apply to the existing field): "the shorter of last RR transmission and, say, two minutes". - Perhaps the interval should be scaled by the session bandwidth, so the measurement interval is approximately a constant number of bits. - Or perhaps there is some network time constant that would reflect the period over which changes in congestion were likely to occur, suggesting a contant interval rather than constant number of bits. Does anyone have any analytical or experimental results that would suggest the right choice? -- Steve From rem-conf Sun Jan 11 03:52:03 1998 From rem-conf-request@es.net Sun Jan 11 03:52:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrLqn-00046M-00; Sun, 11 Jan 1998 03:46:45 -0800 To: hgs@cs.columbia.edu cc: rem-conf@es.net Subject: Re: RTP QOS reports for large groups In-reply-to: Your message of "Sat, 10 Jan 1998 22:20:40 EST." <34B83A88.FD9941F2@cs.columbia.edu> Date: Sun, 11 Jan 1998 11:46:22 +0000 Message-ID: <1033.884519182@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <34B83A88.FD9941F2@cs.columbia.edu>, Henning Schulzrinne typed: >>As Jorg Nonnenmacher points out, large groups raise a particular problem >>of stale QOS reports, as it is likely that each receiver will get to >>send at most one report covering the whole time since it joined the >>group. Finding out about loss averaged over an hour is only modestly >>useful for diagnosing problems and doesn't really tell you a whole lot >>about the user experience (it could have been 10% constant loss or six >>minutes of no reception; the first might have been hidden by local >>recovery, the latter wouldn't). henning, your message points out part of the problem with RTP reports...you start with talking about both dianosing problems and userexperience one of these needs aggregate (e.g. per router/leaf/branch) loss info, while the other needs per recevier/sender info... i thinone might want to have i) per session selection of strategies ii) dynamic selection of strategies for reporting per receive/send,er and for employing localization and aggregation of reports (e.g. scoped reports and summarizers) default would be as per now, but with your reconsideation of course but one could imagine playing with a system that used a hierarchical set of summarizers (receives would report on behalf of nearby regions of receivers, who would report with some scope limit of some kind) and then maybe switch to global reports in the event of problems... of coure, just as with reliable multicast work, localizaion and robust representative summarizer election are somewhat difficualt, ESPECIALLY with the current IP multicast architecture....a slight change is called for i think by this too! (see the rm list for idea on turning points and so on...) cheers >> >>Instead of sampling and further complicating the transmission mechanism, >>we might consider two alternatives that require only modest changes to >>the current scheme: >> >>1) Make the indication of the RR loss fraction reflect only recent >>experience. >> >>2) Add an additional RR field for recent loss experience, where recent >>may be the shorter of last RR transmission and, say, two minutes. >> >>A variation on the proposal by Jorg had been made earlier, namely that >>only those that experience problems would participate in the receiver >>reports, with reconsideration limiting the avalanche effect of sudden >>widespread QOS degradation. Getting the names of those might even be >>useful: "Dear Mr. Subscriber; we gather that your reception of the world >>boxing championship was not as good as you have a right to expect. >>Please accept our apologies and a coupon for Wrestlemania pay-per-view." >> >>Henning >> cheers jon From rem-conf Sun Jan 11 03:54:04 1998 From rem-conf-request@es.net Sun Jan 11 03:54:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrLvx-00048f-00; Sun, 11 Jan 1998 03:52:05 -0800 From: Toerless Eckert Message-Id: <199801111148.MAA17697@faui45r.informatik.uni-erlangen.de> Subject: Optimized mpeg encoders ? To: mbone@isi.edu, rem-conf@es.net Date: Sun, 11 Jan 1998 12:48:10 +0100 (MET) Cc: tnzoerne@immd4.informatik.uni-erlangen.de (Thorsten Zoerner (CIP Admin)), Carsten.Wiethoff@blns.siemens.de (Carsten Wiethoff) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4ME+ PL35 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi I was wondering if someone on this group knows if there are optimized versions of mpeg layer2 audio encoders out there in source for free. I currently know only of the ISO reference implementation which is especially pessimized in terms of performace so that the patent holders can better sell their commercial stuff (just guessing). There seem to be a couple of other mpeg layer-2 audio encoders out there, but what i've found so far is only binaries for DOS/Windooz/Mac, so i cannot evaluate their performance anyway, apart from not being able to guess if they would be available in source for free. If anybody got hints here for me, please reply. With the layer 2 reference encoder our best outcome is something slightly more than 100% CPU for 128 Kbps stereo encoding of 44.1 Kzh on an UltraSparc/250Mhz, so this definitely isn't going to work with a videoconferencing application. Best regards Toerless P.S.: I am asking for layer-2 encoder software, because the layer-2 reference encoder does contain a useful psychoaccoustic model and thus optimization could have been done purely on the algorithmic implementation to deliver higher throughput. As for layer 3, there doesn't even seem to be a useful psychoaccoustic model published (i.e.: the one in the ISO reference encoder delivers only slighter better quality per bit than layer 2, but far from sufficient to get a better bitrate/cpu-cycles ratio). Everybody who want's to use a good model seems to have to buy licenses from FHG, and this doesn't work for software designated to become freeware. Also, i don't want to support such a monopoly, even though they're next door to us and are funded with my tax-money too (i especially like that part). If i am mistaken in these point's i would be glad to go for layer 3. From rem-conf Mon Jan 12 00:09:04 1998 From rem-conf-request@es.net Mon Jan 12 00:09:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrelc-0003Gc-00; Sun, 11 Jan 1998 23:58:40 -0800 Date: Sun, 11 Jan 1998 23:58:37 -0800 (PST) Message-Id: <199801120758.XAA04994@shanti.eecs.berkeley.edu> From: Matt Podolsky To: rem-conf@es.net CC: Matt Podolsky , Steve McCanne , Cindy Romer Subject: Paper available: Simulation of FEC for Internet Audio X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A copy of our Infocom '98 paper describing simulation work we have done on FEC for Internet audio is now available on-line at the link below. The paper is entitled "Simulation of FEC-Based Error Control for Packet Audio on the Internet" and was written by myself, Cynthia Romer, and Steven McCanne. http://www-wavelet.eecs.berkeley.edu/~podolsky/publications/infocom98.ps The paper focuses on FEC techniques jointly developed by groups at UCL and INRIA, and implemented in such tools as RAT and FreePhone. We refine these novel coding techniques into a formal framework that we call ``signal processing-based FEC'' (SFEC) and use our framework to more rigorously evaluate the relative merits of this approach. Through extensive simulation, we evaluate the ``scalability'' of SFEC for packet audio --- \ie, the ability for a coding algorithm to improve aggregate performance when used by all sources in the network --- and find that optimal signal quality is achieved when sources react to network congestion not by blindly adding FEC, but rather by adding FEC in a controlled fashion that simultaneously constrains the source-coding rate. Matt Podolsky From rem-conf Mon Jan 12 02:15:45 1998 From rem-conf-request@es.net Mon Jan 12 02:15:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrgkd-0004Ol-00; Mon, 12 Jan 1998 02:05:47 -0800 From: Toerless Eckert Message-Id: <199801121004.LAA21225@faui45r.informatik.uni-erlangen.de> Subject: sdr announcement questions To: rem-conf@es.net Date: Mon, 12 Jan 1998 11:04:56 +0100 (MET) Cc: mbone@isi.edu Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4ME+ PL35 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Question a): How do i solve the following problem: I want to make a sdr-announcement that should have a living-time "forever", i.e.: something like a continuous channel, or continually regular channel. Whatever. I currently solved this by guessing which field holds the end-time and then modifying it. Now the problem with this approach to me seems that i cannot allow for any mistakes in this announcement, because the end-time seem also to convey something like the "cache-timeout" for such an announcement. I.e.: My sdr sends out such an announcement and there's a typo in it. I want to correct it, but that doesn't help, because people who've already reveieved the erroneous announcement will still use that from their local cache. There doesn't seem to be something like a sequence number for announcements, or am i mistaken there ? Replacement question: where's the documentation for the exact format and semantics of the .sdr announcement files ? ;-)) Best regards Toerless From rem-conf Mon Jan 12 02:26:56 1998 From rem-conf-request@es.net Mon Jan 12 02:26:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrh0o-0004eR-00; Mon, 12 Jan 1998 02:22:30 -0800 Message-Id: <199801121022.LAA00690@basil.cdt.luth.se> X-Mailer: exmh version 2.0.1 12/23/97 To: Toerless Eckert cc: rem-conf@es.net, mbone@isi.edu Subject: Re: sdr announcement questions In-reply-to: Your message of "Mon, 12 Jan 1998 11:04:56 +0100." <199801121004.LAA21225@faui45r.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 1998 11:22:03 +0100 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list If you want to change a SDR SDP cache file you have to first quit sdr. The edit the correct cache file and change the second field on the line that starts with 'o=' to a higher number. This field is the 'version number' of this announcement. If you want a session that never time out then you have to change the t-field to t=0 0 The format is documented in the SDP specification. NOTE that this is illegal according to the SDP specifications ;-) /P From rem-conf Mon Jan 12 06:24:43 1998 From rem-conf-request@es.net Mon Jan 12 06:24:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xrkcH-0006pP-00; Mon, 12 Jan 1998 06:13:25 -0800 From: Edgar Hellfritsch Subject: Re: sdr announcement questions To: rem-conf@es.net Date: Mon, 12 Jan 1998 15:12:36 +0100 (MET) In-Reply-To: <199801121022.LAA00690@basil.cdt.luth.se> from "Peter Parnes" at Jan 12, 98 11:22:03 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Message-Id: <34ba24e2229e002@max4.rrze.uni-erlangen.de> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > If you want to change a SDR SDP cache file you have to first quit sdr. The > edit the correct cache file and change the second field on the line that > starts with 'o=' to a higher number. This field is the 'version number' of > this announcement. > > If you want a session that never time out then you have to change the t-field > to > t=0 0 > > The format is documented in the SDP specification. > > NOTE that this is illegal according to the SDP specifications ;-) > > /P > what about private session announcements? they don't show up in the cache dir. sdr doesn't seem to receive private session announcements when starting it AFTER the session initialisation has already taken place. if a private session is announced while sdr is listening, the session shows up immediately. looks to me like private sessions are announced once and never again. ist that a known effect? edgar From rem-conf Tue Jan 13 07:21:09 1998 From rem-conf-request@es.net Tue Jan 13 07:21:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xs7iU-00004H-00; Tue, 13 Jan 1998 06:53:22 -0800 From: "Stavros A. Papadakis" Posted-Date: Tue, 13 Jan 1998 16:40:50 +0200 (EET) Date: Tue, 13 Jan 1998 16:39:30 +0200 Message-Id: <9801131439.AA30574@panoramix.csi.forth.gr> Organization: Institute of Computer Science, Foundation for Research and Technology-Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385 GR 711 10 Heraklion, Crete, Greece tel.: +30 (81) 39 16 00, fax: +30 (81) 39 16 01 To: spapad@csi.forth.gr Subject: Announcing the Second European Conference on Research and Advanced Technology for Digital Libraries X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Second European Conference on Research and Advanced Technology for Digital Libraries European European ICS-FORTH University of Union Research Crete Consortium for Informatics and Mathematics 19 - 23 September, 1998 Heraklion, Crete, Greece Web Page http://www.csi.forth.gr/2EuroDL E-mail ecdl@cc.uch.gr ________________________________________________________________________________ - Objectives This conference is the second of a series of European conferences on research and technology for digital libraries funded by the European Commission's TMR Programme. Its objectives are: to bring together researchers from multiple disciplines whose science relates to the development of digital libraries; to provide an opportunity for these scientists to form a research community in Europe specific to digital library development and to enable them to discuss issues and strategies specific to the European context; to assist young researchers in establishing relationships with senior scientists in their areas of interest; to enable review and discussion of research under way in Europe, the US, Japan and other countries on digital libraries; to stimulate researchers, especially young scientists, to explore new areas of interest in digital library development; to establish a forum for discussion of issues specific to Europe such as interoperability, multilinguality, intellectual property policy, and information commerce; to provide an opportunity for researchers in the relevant enabling technologies and information sciences, to discuss issues related to interoperability between world wide distributed digital libraries. >From a technical point of view, the European Conferences series aims to contribute to the definition of those digital library parameters which especially influence issues of access, retrieval, and interaction with information; to identify key problems which must be solved to make digital library services an effective reality; to identify a general structure or framework for integrating research and solutions; and to propose and encourage specific, high priority research directions within such a framework. ________________________________________________________________________________ - Topics The conference organisers solicit papers on topics related to digital libraries, including but not limited to the following list: o Digital Library Models, Frameworks, and System Requirements o Metadata o System Integration and Architecture Issues o Interoperability, Scalability o Networked Information Discovery, Agent Technologies o Information Retrieval, Organisation, Navigation - Tools and Paradigms o Multilinguality o Role of Knowledge Representation Systems in Digital Library Interactions o Collecting, Capturing, Filtering, Cataloging, Indexing, o Preserving o Intellectual Property Rights, Terms and Conditions, Rights Management o Authoring, Electronic Publishing, Electronic Commerce and Information Economies o Economic and Social Implications and Issues o User Interfaces o Handling of Graphics, GIS, Medical Data, Multimedia Information, Experimental Data and o Scientific Models ________________________________________________________________________________ - Conference Programme The conference will be held in Heraklion, Crete, Greece. Tutorials will be organised on the 19th and 20th of September 1998. The opening session will take place at 9.00a.m. on Monday the 21th of September 1998 and the final session will take place on Wednesday afternoon, the 23th of September 1998. Full details on the scientific programme of the Conference will be published on our Web site by the 1st of July 1998. ________________________________________________________________________________ - Important Dates 15 March 1998 Proposals for tutorials, panels and demos due to the Programme Chair 15 April 1998 Notification of tutorial, panel and demo acceptance 15 May 1998 Papers and proposals for posters due to the Programme Chair 25 June 1998 Notification of paper and poster acceptance 1 July 1998 Scientific Programme on the Web 25 July 1998 Final papers due 19,20 September 1998 Tutorials 21-23 September 1998 Conference ________________________________________________________________________________ - Panels Suggestions for the organisation of panel sessions on one of the proposed topics or on related topics are welcomed. Proposals should include a short CV and position paper for each panelist. ________________________________________________________________________________ - Posters During the conference a space will be reserved for poster sessions. Research projects of any scale are invited to illustrate innovative concepts and prototype systems. Poster proposals should include title, names of presenters and outline (max. 500 words). ________________________________________________________________________________ - Tutorials Tutorial days will be held before the Conference, on Saturday the 19th and Sunday the 20th of September 1998. Proposals for tutorials are solicited. Tutorials would be either half day (3 hours) or full day (6 hours). Each proposal should include a title, a summary (intentions, objectives, etc.), duration and a short CV of the instructor(s). ________________________________________________________________________________ - Demos Result demonstrations of on-going projects are strongly encouraged. Those interested should submit a description of the intended Demo to the Programme Chair. ________________________________________________________________________________ - Papers Papers (max 20 pages, double spaced) should be submitted electronically in HTML format, either by e-mail to the Conference Secretariat, ecdl@cc.uch.gr, or to our ftp site, ftp://ftp.ics.forth.gr/2EuroDL. ________________________________________________________________________________ - Proceedings The Proceedings will be published by Springer as a volume in their Lecture Notes in Computer Science series and will be distributed at the Conference. ________________________________________________________________________________ - Fellowship for Young Researchers A limited number of fellowships for the Conference and also for Tutorials are available for young researchers who are citizens of European Union countries or Liechtenstein, Norway and Iceland. The fellowship offers free registration for the participants and, in special cases where necessary and appropriately justified, may pay for or reimburse travel and lodging expenses. ________________________________________________________________________________ - Programme Chair Christos Nikolaou, University of Crete & ICS-FORTH Leoforos Knossou, GR-71110 Heraklion, Crete, Greece Tel: +30 81 393199, Fax: +30 81 210106 E-mail: nikolau@cc.uch.gr ________________________________________________________________________________ - Programme Committee Serge Abiteboul INRIA, France Robert B. Allen Bellcore, USA Thomas Baker Asian Institute of Technology, Thailand William Birmingham University of Michigan, USA Panos Constantopoulos University of Crete & ICS-FORTH, Greece Bruce Croft University of Massachusetts, USA Costis Dallas Hellenic Ministry of Foreign Affairs, Greece Edward A. Fox Virginia Technical University, USA Norbert Fuhr University of Dortmund, Germany Hector Garcia-Molina Stanford University, USA Keith Jeffery RAL-CLRC, UK Martin Kersten CWI, Netherlands Judith Klavans Columbia University, USA Carl Lagoze Cornell University, USA Clifford A. Lynch Coalition for Networked Information, USA Jeff MacKie-Mason University of Michigan, USA A. Desai Narasimhalu National University of Singapore, Singapore Ann Okerson Yale University, USA Olle Olsson SICS, Sweden Andreas Paepcke Stanford University, USA Nicholas Patrikalakis MIT, USA Carol Peters IEI-CNR, Italy Jakka Sairamesh IBM-T.J. Watson Research Center, USA Peter Schauble ETH Zurich, Switzerland Hans Joerg Schek ETH Zurich, Switzerland Eric Simon INRIA, France Ingeborg T. Solvberg University of Science and Technology, Norway Constantine Stephanidis ICS-FORTH, Greece Shigeo Sugimoto University of Library and Information Science,Japan Costantino Thanos IEI-CNR, Italy Ulrich Thiel GMD-IPSI, Germany Stuart Weibel OCLC, USA ________________________________________________________________________________ - Local Organising Committee Sarantos Kapidakis ICS-FORTH, Greece Penelope Constanta ICS-FORTH, Greece Spiros Lalis University of Crete, Greece Gioylh Koraoy University of Crete, Greece Stella Vourou University of Crete & ICS-FORTH, Greece Mixalhs Tzekakhs University of Crete, Greece Maria Stavrakaki University of Crete, Greece Rena Kalaitzaki University of Crete, Greece Maria Prevelianaki ICS-FORTH, Greece Liana Kefalaki ICS-FORTH, Greece Dimitris Papadakis University of Crete, Greece Manolis Marazakis University of Crete, Greece Anastasia Anastasiadi ICS-FORTH, Greece Stavros Papadakis University of Crete, Greece ________________________________________________________________________________ - Contact Info For more information regarding this conference contact the conference secretariat, Rena Kalaitzaki and Maria Stavrakaki University of Crete, Computer Science Department, Tel: +30 81 393504 Fax: +30 81 393501 E-mail: ecdl@cc.uch.gr ________________________________________________________________________________ You can subscribe to the announcement list of the "Second European Conference on Research and Advanced Technology for Digital Libraries" by sending electronic mail to 'majordomo@csi.forth.gr' with body 'subscribe ecdl2-announce ' From rem-conf Tue Jan 13 09:36:47 1998 From rem-conf-request@es.net Tue Jan 13 09:36:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xsA90-0001T1-00; Tue, 13 Jan 1998 09:28:54 -0800 Date: Tue, 13 Jan 1998 18:27:14 +0100 (MET) From: Christian Isnard - CERN/IT/CS/EN To: rem-conf MBONE List , hepnet-l@slacvm.slac.stanford.edu, hrc@frcpn11.in2p3.fr, htasc@listbox.cern.ch, net-teleconferencing LIST Cc: Christian Isnard Subject: MBONE announcement for CERN LHCC meeting Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CERN is pleased to announce the MBONE broadcast of the LARGE HADRON COLLIDER COMMITTEE Session --------------------------------------- on Thursday 15 January 1998 from the CERN Auditorium *** Times are UTC+1 *** Open Session (please note change from preliminary announcement) at 09.00 hrs - Auditorium 09.00-09.10 Status of the LHC project (C.Llewellyn Smith) 09.15-10.00 Status of the LHC machine (L.Evans) 10.15-10.35 COFFEE BREAK 10.35-11.35 CMS Muon Project Technical Design Report (F.Gasparini, G.Mitselmakher, G.Iaselli) 11.45-12.45 CMS Electromagnetic Calorimeter Project Technical Design Report (H.Hofer, J.-L.Faure, P.Denes, C.Seez) The broadcast is announced via sdr as "CERN LHCC". vat and vic applications will be used with a ttl of 127. The sessions will also be recorded using the wrtp application. They can be downloaded from our vod server: http://sunmed2.cern.ch/cgi-bin/nph-MBone-sessions/ In case of questions or problems please contact: multicast@noc.cern.ch From rem-conf Tue Jan 13 17:47:45 1998 From rem-conf-request@es.net Tue Jan 13 17:47:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xsHoR-0006iB-00; Tue, 13 Jan 1998 17:40:11 -0800 Date: Wed, 14 Jan 1998 02:44:26 +0100 From: csmr98@dsi.UNIFI.IT Subject: Conf. Prog.: CSMR98+REF98: Maintenance & Reengineering in Florence To: rem-conf@es.net Message-id: <9801140144.AA28483@aguirre.dsi.UNIFI.IT> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear colleague: Here is the preliminary program of the combined conference that will be help in Florence, Italy, 8-11 March 1998. Please accept our apologies if you receive multiple copies of this ca= ll. Post forward this message to all your interested colleagues. Please visit our www page: http://www.dsi.unifi.it/~nesi/csmr98.html thank you=20 ---------------------------------------------------------------------= ----------- ----> 2nd EUROMICRO CONFERENCE on SOFTWARE MAINTENANCE AND REENGINEE= RING ----> 6th REENGINEERING FORUM Palazzo degli Affari, FIRENZE, Italy, March 8-11, 1998 csmr98@aguirre.ing.unifi.it, csmr98@dsi.unifi.it http://www.dsi.unifi.it/~nesi/csmr98.html, http://www.reenginee= r.org/ref98/ Fax: +39-(0)55-4796363 ----> Sponsored by: EUROMICRO, REENGINEERING FORUM, IEEE Computer Soc= iety IEEE Task Force on Information Technology,=20 IEEE Technical Council on Software Engineering= =20 In Cooperation with CESVIT, Universita' di Firenze. Patroned by: AICA, AIIA, DeQualitate, Dipartimento di Sistemi e= Informatica, Jackson, TABOO, UNINFO. Local Conference Organization: Paolo Nesi, Alessandro Fantechi, Fabrizio Fioravanti Dip. Sistemi e Informatica, Universit=E0 degli Studi di F= irenze=20 Via S. Marta, 3, 50139 Firenze, Italy=20 --------------------------> Conference Program <---------------------= --------- Keynote Speakers:=20 - Continuous Engineering for Industrial Scale Software Systems.=20 H. Weber, ISST, D - Evolving Software Practice for Year 2000 and Beyond.=20 S. Bohner, META Group - Software Engineering Strategies, USA STEVENS LECTURE ON SOFT. DEVELOPMENT METHODS - Presentation of the Wayne Stevens Award and the Stevens Lecture on= =20 Software Development Methods.=20 Session: Tool Architecture - Architecture and Functions of a Commercial Software Reengineering W= orkbench=20 (H. M. Sneed - Software Engineering Service - D) - Control Flow Normalization for COBOL/CICS Legacy System=20 (M. van Brand, A. Sellink, C. Verhoef, - University of Amsterdam - = NL) Session: Data Reengineering - A Generic Approach for Data Reverse Engineering Taking into Account= Application=20 Domain Knoledge (S. A. Ghannouchi, , H. H. B. Ghezola, F. Kamoun, E= NSI, Tun) - A strategy for reducing the effort for database schema maintenance= =20 (D. Castelli - Istituto di Elaborazione dell'Informazione - I) - Data Reverse Engineering Methods in Practice=20 (P. Aiken - Virginia Commonwealth University - USA) - Database Reengineering for Quality (E. Locuratolo - IEI - CNR; M. L= offredo,=20 O. Signore, CNUCE - CNR - I) Session: Business Information Technology - An Organizational Framework for Mass-Customized Business Applicatio= n=20 (P. Ludwig, T. Kaufmann, H. Liessmann - D) - Driving IT Decisions from Architectural Principles=20 (E. Chikofsky - DMR Consulting Group - USA) - Architectural Reflection: Bridging the Gap Between a Running System= and its=20 Architectural Specification (W. Cazzola, A. Savigni, A. Sosio, F. T= isato,=20 University of Milano - I) Session: Year 2000 Problem - Variable Classification Technique for Software Maintenance and Appl= ication to The=20 Year 2000 Problem (K. Kawabe, A. Matsuo, S. Uehara - Fujitsu Labora= tories Ltd. JP=20 A. Ogawa - Fujitsu Ltd. - JP) - From "Y2K" to Data Warehouses [and other beneficial impacts of the = millennium=20 problem] (D. Aebi, C. Schucan, ETH Zurich - SW) Session: Program Understanding - On Constructing a Tool to Verify Programs for Processors Built in M= achines=20 (T. Ohta, N. Matsumara, Y. Itoh, Shizuoka Univ. - JP) - Improving Comprehensibility of Software with Diagramming, Folding, = and=20 Coloring (J. H. Cross II - Auburn University - USA) Session: Reuse and Object Oriented Techniques - A Dependence-Based Representation for Concurrent Object-Oriented So= ftware Maintenance (J. Zhao - Fukouka Institute of Tech. - J. Cheng, K. Ushijima - Kyu= shu Univ.-JP) - OOA Metrics for the Unified Modeling Language=20 (M. Marchesi-Univ. di Cagliari - I) - Protection Reconfiguration for Reusable Software (C. D. Jensen, D. = Hagimont - Universite Joseph Fourier - F) Session: System Assessment=20 - Towards Mature Measurement Program (F. Niessink, H. van Vliet-Univ.= Amsterdam NL) - A Tool for Process and Product Assessment of C++ Applications=20 (F. Fioravanti, P. Nesi, S. Perlini - University of Florence - I) - Software Testability Measurement derived from Data Flow Analysis (P= .-L. Yeh,=20 J.-C. Lin, Tatung Institute of Technology - Taiwan) Session: System Documentation - Documentu: A Flexible Architecture for Documentation Production Bas= ed on a Reverse Engineering Strategy (C. de Oliveira Braga, Arndt von Staa, Julio C= .S.P. Leite,=20 PUC-Rio - Brazil) - Documentation Multi-Targeting Using ASML (C. Owen, F. Makedon, J. F= ord, S. Rebelsky,=20 Grinnell College - USA) Session: Software Architecture - Assessing Architectural Complexity (R. Kazman - Carnege Mellon Univ= ersity - USA -=20 M. Burth - University of Mannheim - D) - Architecture recovery for Software Evolution (J. C. Duenas, W. L. d= e Oliveira,=20 J. A. de la Puente - Universidad Politecnica de Madrid - E) - The Hot-Spots Technique to Scavenge for Architectural Elements=20 (H. Gall, B. Bellay, Technical University of Vienna - Austria) Session: Requirements and Specification Evolution - Requirements Evolution in the Midst of Environmental Change A Manag= ed Approach (W.=20 Lam, M. Loomes - Univ. of Hertfordshire - UK) - A Method for Assessing Legacy Systems for Evolution (J. Ransom, I. = Sommerville,=20 I. Warren - Lancaster University - UK) - System Specification Reengineering Using the SpecView Tool=20 (T. G. Kirner, R. C. Gratao - Federal University of Sao Carlos - BR= ) - A Tool Supporting the Re-Design of Legacy Applications=20 (K. Cremer - RWTH Aachen- D) Session: Maintenance Effort - Modeling Maintenance Effort by means of Dynamic System=20 (F. Calzolari, G. Antoniol, P. Tonella - IRST - I) - Improving Defect Removal Effectiveness for Software Development= =20 (Hareton K. N. Leung The Honk Kong Poly. Univ.) - The Extract-Transform-Rewrite Cycle A Step Towards metaCARE=20 (B. Kullbach, A. Panse - University of Koblenz - D) Session: Logic Programming, Telecommunications - A Metric Suite for Concurrent Logic Programs (J. Zhao - Fukouka Ins= titute of=20 Technology - J. Cheng, K. Ushijima - Kyushu Univ. - JP) - Identifying Fault Prone Modules An Empirical Study in Telecom-munic= ation System=20 (S.-B. Hong, K. Kim - Call Proc.Section, ETRI - KR) Session: Reverse Engineering in Practice - A Process for Reverse Engineering of AXE 10 Software=20 (S. Haglund, Ericsson Software Technology AB - Sweden) - Regenerative Verification and Validation: Moving Forward From Rever= se Engineering=20 (T. Roberts - TASC - B. Farley - Motorola - USA) - A Proposed Reverse Engineering Tech to Redocument High-Level Contro= l Structures of Embedded Systems Software (D. Wilkening -USA) - Current Parsing Techniques in Software Renovation Considered Harmfu= l=20 (M. van den Brand, A. Sellink, C. Verhoef, NL) Papers in CSMR98 OPEN FORUM Sections - DBFW A Simple DataBase FrameWork for the Evaluation and Maintenance= of Automated Theorem Prover Data (P. Jakobi, A. Wolf, D) - Reengineering of Distributed Systems Using Formal Methods=20 (S. Kleuker - University of Oldenburg D) - Metrics-based Evaluation of Object-Oriented Software development Me= thods=20 (R. R. Dumke, E. Foltin - University of Magdeburg - D) - RENAISSANCE, A Method To Migrate From Legacy To Immortal Software S= ystem=20 (M. Battaglia, G. Savoia, J. Favaro - Intecs Sistemi - I) - Visualization of Differences between Versions of Object-Oriented So= fware=20 (J. Seemann, J. W. von Gudenberg - Wurzburg University - D) - Amber Metrics for the Testing & Maintenance of Object-Oriented Desi= gns=20 (J. Doake, I. Duncan - Anglia Polytechnic University - UK) - Tailoring the Process Model for Maintenance and Reengineering=20 (S. Stoecklin, D. Wiliams, P. Stoecklin, USA) - Toward a systematic object-oriented transformation of a Merise anal= ysis=20 (I. Borne, A. Romanczuk, F. Stefani, Ecole de Nantes - F) - Object Evolution by Model Evolution (R. T. Mittermeir, H. Pirker, = Dominik=20 Rauner-Reithmayer - Universit=E4t Klagenfurt - A) - A sound and Pratical Approach to the Re-Engineering of Time Critica= l System=20 (H. Zedan, H. Yang, De Montfort University - UK) - Reengineering a Computerized Numerical Control Towards Object-Orien= ted=20 (F. Butera, B. Fontanella, P.Nesi, M.Perfetti - ELEXA S.r.l. - I) - Software Artifacts Reuse and Maintenance An organizational Framewor= k=20 (C. Toffolon, S. Dakhli - Paris-Dauphine University - F) - The Task Artifact Cycle: Some Experiences from Reengineering Practi= ce=20 (S. Kutscha, sd&m GmbH und Co KG, D) Session: CSMR98 Industrial Track - ESSI Project CARERRAS (David Fox, England) - ESSI Project PROMASYS (Miguel Fernandez Diaz, Spain) Session: Results of the Reverse Engineering Demonstration Project= =20 Companies, research centers, and universities participating in the = Reverse=20 Engineering Demonstration Project will present their results on t= he analysis=20 of a single software system using different tools and techniques.= =20 General Time Frame The conference will run from Sunday 8th to Wednesday 11th. Registrati= on will start on Sunday 8th at the 16:00 and continues till 18:00. Conference will sta= rt at the 18:00 of Sunday 8th with the official opening. The registration desk will be a= lso open in the morning from 8:00 to 9:00 of Monday and Tuesday. The conference will = close its activities Wednesday 11th at the 18:00. Social Program On Tuesday 10th the conference dinner will be organized.=20 Tours could be organized with the Agency by BUS or by feet to visit: = Boboli Garden,=20 the Dome, Giotto Tower, The Old Bridge, Michelangelo Vista Point, Bel= vedere,=20 Cappelle Medicee, S. Croce Church, S. Miniato Church, Fiesole Village= , S. Gimignano=20 Village, The Chianti Vine Area, the Old Market Area, Siena Village, M= useum with the=20 David of Michelangelo, (Accademia Gallery), Uffizi Museum, Medieval = Arms Museum,=20 Archeological Museum, and more than 100 churches along the town. etc. ------------------------------------------------------------------ For travel information, registration form, accommodation form,=20 and all other details please consult the www pages of the=20 conference: http://www.dsi.unifi.it/~nesi/csmr98.html http://www.reengineer.org/ref98/ ---------------------------------------------------------------------= --------------- From rem-conf Wed Jan 14 11:51:15 1998 From rem-conf-request@es.net Wed Jan 14 11:51:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xsYa6-0006NM-00; Wed, 14 Jan 1998 11:34:30 -0800 Date: Wed, 14 Jan 98 11:32:00 PST From: Gim L Deisher Message-ID: To: itu-adv-video@ferrari.iterated.com, rem-conf@es.net, internet-drafts@ietf.org cc: Chad_Zhu@mail.intel.com, Donald_Newell@mail.intel.com, Christian_Maciocco@mail.intel.com, Thomas_R_Gardos@ccm.jf.intel.com, stewe@cs.tu-berlin.de, jo@cs.tu-berlin.de, garys@python.pictel.com, cabo@tzi.org, lscline@ideal.jf.intel.com Subject: New RTP Payload Format for H.263+ X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Text item: Enclosed is a new revision of the H.263+ RTP payload specification which is to replace the 11/97 IETF draft, draft-ietf-avt-rtp-h263-video-00.txt. Since the version presented in December 97 IETF meeting, only minor corrections and clarifications have been made. Comments welcome as usual. Thank you. Text item: h263pplh.txt 1/14/98 8:41A Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT C. Bormann / Univ. Bremen L. Cline / Intel G. Deisher / Intel T. Gardos / Intel C. Maciocco / Intel D. Newell / Intel J. Ott / Univ. Bremen G. Sullivan / PictureTel S. Wenger / TU Berlin C. Zhu / Intel Date Generated: 14 Jan. 1998 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Status of This Memo This document is an Internet-Draft. 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 made obsolete 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. 1. Introduction This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263. The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. The 1998 version is referred to as H.263+ in this document. Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode (ISD), the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [4] for more information on coding options. The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable to use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries. With the independent segment decoding option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Utilizing ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others. The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference frame. The reference picture selection mode can be used with or without a back channel, which provides information to the encoder about the internal status of the decoder. However, no special provision is made herein for carrying back channel information. H.263+ also includes bitstream scalability as an optional coding mode. Three kinds of scalability are defined: temporal, signal-to-noise ratio (SNR), and spatial scalability. Temporal scalability is achieved via the disposable nature of bi-directionally predicted frames, or B-frames. SNR scalability permits refinement of encoded video frames, thereby improving the quality (or SNR). Spatial scalability is similar to SNR scalability except the refinement layer is twice the size of the base layer in the horizontal dimension, vertical dimension, or both. 2. Usage of RTP When transmitting H.263+ video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting from the bitstream including the fixed length codes and variable length codes will be included in the packet, with the only exception being that when the payload of a packet begins with a Picture, GOB, Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of the start code are removed and replaced by setting an indicator bit in the payload header. For H.263+ bitstreams coded with temporal, spatial, or SNR scalability, each layer may be transported to a different network address. More specifically, each layer may use a unique IP address and port number combination. The temporal relations between layers shall be expressed using the RTP timestamp so that they can be synchronized at the receiving ends in multicast or unicast applications. The H.263+ video stream will be carried as payload data within RTP packets. A new H.263+ payload header is defined in section 4. This section defines the usage of the RTP fixed header and H.263+ video packet structure. 2.1 RTP Header Usage Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for H.263+ video streams: Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame, and is 0 otherwise. Payload Type (PT): The Payload Type shall specify the H.263+ video payload format. Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame data contained in the RTP data packet. The RTP timestamp shall be the same on successive packets if a video frame occupies more than one packet. In a multilayer scenario, all pictures corresponding to the same temporal reference should use the same timestamp. If temporal scalability is used (if B-frames are present), the timestamp may not be monotonically increasing in the RTP stream. If B-frames are transmitted on a separate layer and address, they must be synchronized properly with the reference frames. Refer to the 1998 ITU-T Recommendation H.263 [4] for information on required transmission order to a decoder. For an H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, the same as that of the RTP payload for H.261 stream [5]. Since both the H.263+ data and the RTP header contain time information, it is required that those timing information run synchronously. That is, both the RTP timestamp and the temporal reference (TR in the picture header of H.263) should carry the same relative timing information. If necessary, mathematical rounding should be applied to the information of the H.263+ data stream to generate the RTP timestamp (this is especially true for the standard picture clock frequency of 30000/1001 Hz, and may also be true if custom picture clock frequencies are to be used; see [4] for details). 2.2 Video Packet Structure A section of an H.263+ compressed bitstream is carried as a payload within each RTP packet. For each RTP packet, the RTP header is followed by an H.263+ payload header, which is followed by a number of bytes of a standard H.263+ compressed bitstream. The size of the H.263+ payload header is variable depending on the payload involved as detailed in the section 4. The layout of the RTP H.263+ video packet is shown as: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263+ Payload Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263+ Compressed Data Stream ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Any H.263+ start codes can be byte aligned by an encoder by using the stuffing mechanisms of H.263+. As specified in H.263+, picture, slice, and EOSBS start codes shall always be byte aligned, and GOB and EOS start codes may be byte aligned. For packetization purposes, GOB start codes should be byte aligned, although this is not absolutely required herein since it is not required in H.263+. All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin with 16 zero-valued bits. If a start code is byte aligned and it occurs at the beginning of a packet, these two bytes shall be removed from the H.263+ compressed data stream in the packetization process and shall instead be represented by setting a bit (the P bit) in the payload header. 3. Design Considerations The goals of this payload format are to specify an efficient way of encapsulating an H.263+ standard compliant bitstream and to enhance the resiliency towards packet losses. Due to the large number of different possible coding schemes in H.263+, a copy of the picture header with configuration information is inserted into the payload header when appropriate. The use of that copy of the picture header along with the payload data can allow decoding of a received packet even in such cases in which another packet containing the original picture header becomes lost. There are a few assumptions and constraints associated with this H.263+ payload header design. The purpose of this section is to point out various design issues and also to discuss several coding options provided by H.263+ that may impact the performance of network-based H.263+ video. o The optional slice structured mode described in annex K of H.263+ [4] enables more flexibility for packetization. Similar to a picture segment that begins with a GOB header, the motion vector predictors in a slice are restricted to reside within its boundaries. However, slices provide much greater freedom in the selection of the size and shape of the area which is represented as a distinct decodable region. In particular, slices can have a size which is dynamically selected to allow the data for each slice to fit into a chosen packet size. Slices can also be chosen to have a rectangular shape which is conducive for minimizing the impact of errors and packet losses on motion compensated prediction. For these reasons, the use of the slice structured mode is strongly recommended for any applications used in environments where significant packet loss occurs. o In non-rectangular slice structured mode, only complete slices should be included in a packet. In other words, slices should not be fragmented across packet boundaries. The only reasonable need for a slice to be fragmented across packet boundaries is when the encoder which generated the H.263+ data stream could not be influenced by an awareness of the packetization process (such as when sending H.263+ data through a network other than the one to which the encoder is attached, as in network gateway implementations). Optimally, each packet will contain only one slice. o The independent segment decoding (ISD) described in annex R of [4] prevents any data dependency across slice or GOB boundaries in the reference picture. It can be utilized to further improve resiliency in high loss conditions. o If ISD is used in conjunction with the slice structure, the rectangular slice submode shall be enabled and the dimensions and quantity of the slices present in a frame shall remain the same between each two intra-coded frames (I-frames), as required in H.263+. The individual ISD segments may also be entirely intra coded from time to time to realize quick error recovery without adding the latency time associated with sending complete INTRA-pictures. o When the slice structure is not applied, the insertion of a (preferably byte-aligned) GOB header can be used to provide resync boundaries in the bitstream, as the presence of a GOB header eliminates the dependency of motion vector prediction across GOB boundaries. These resync boundaries provide natural locations for packet payload boundaries. o H.263+ allows picture headers to be sent in an abbreviated form in order to prevent repetition of overhead information that does not change from picture to picture. For resiliency, sending a complete picture header for every frame is often advisable. This means, that especially in cases with high packet loss probability in which picture header contents are not expected to be highly predictable, the sender may always set the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. o In a multi-layer scenario, each layer may be transmitted to a different network address. The configuration of each layer such as the enhancement layer number (ELNUM), reference layer number (RLNUM), and scalability type should be determined at the start of the session and should not change during the course of the session. o All start codes can be byte aligned, and picture, slice, and EOSBS start codes are always byte aligned. The boundaries of these syntactical elements provide ideal locations for placing packet boundaries. o We assume that a maximum Picture Header size of 504 bits is sufficient. The syntax of H.263+ does not explicitly prohibit larger picture header sizes, but the use of such extremely large picture headers is not expected. 4. H.263+ Payload Header For H.263+ video streams, each RTP packet carries only one H.263+ video packet. The H.263+ payload header is always present for each H.263+ video packet. The payload header is of variable length. A 16 bit field of the basic payload header may be followed by an 8 bit field for Video Redundancy Coding information, and/or by a variable length picture header as indicated by PLEN. These optional fields appear in the order given above when present. If a picture header is included in the payload header, the length of the picture header in number of bytes is specified by PLEN. The minimum length of the payload header is 16 bits, corresponding to PLEN equal to 0 and no VRC information present. The remainder of this section defines the various components of the RTP payload header. Section five defines the various packet types that are used to carry different types of H.263+ coded data, and section six summarizes how to distinguish between the various packet types. 4.1 General H.263+ payload header The H.263+ payload header is structured as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |P|V| PLEN |PEBIT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RR: 5 bits Reserved bits. Shall be zero. P: 1 bit Indicates the picture start or a picture segment (GOB/Slice) start or a video sequence end (EOS or EOSBS). Two bytes of zero bits then have to be prefixed to the payload of such a packet to compose a complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the omission of the two first bytes of the start codes, thus improving the compression ratio. V: 1 bit Indicates the presence of an 8 bit field containing information for Video Redundancy Coding (VRC), which follows immediately after the initial 16 bits of the payload header if present. For syntax and semantics of that 8 bit VRC field see section 4.2. PLEN: 6 bits Picture header length in number of bytes. If no additional picture header is attached, PLEN is 0. If PLEN>0, the additional picture header is attached immediately following the rest of the payload header. PEBIT: 3 bits Indicates the number of bits that shall be ignored in the last byte of the picture header. If PLEN is zero, then PEBIT shall also be zero. 4.2 Video Redundancy Coding Header Extension Video Redundancy Coding (VRC) is an optional mechanism intended to improve error resilience over packet networks. Implementing VRC in H.263+ will require the Reference Picture Selection option described in Annex N. By having multiple "threads" of independently inter-frame predicted pictures, damage of individual frame will cause distortions only within its own thread but leave the other threads unaffected. From time to time, all threads converge to a so-called sync frame (an INTRA picture or a non-INTRA picture which is redundantly represented within multiple threads); from this sync frame, the independent threads are started again. For a more complete description of VRC see [7]. While a VRC data stream is - like all H.263+ data - totally self- contained, it may be useful for the transport hierarchy implementation to have knowledge about the current damage status of each thread. On the Internet, this status can easily be determined by observing the marker bit, the sequence number of the RTP header, and the thread-id and a circling "packet per thread" number. The latter two numbers are coded in the VRC header extension. The format of the VRC header extension is as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | TID | Trun |S| +-+-+-+-+-+-+-+-+ TID: 3 bits Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC data will use as reference information only sync frames or frames within the same thread. By convention, thread 0 is expected to be the "canonical" thread, which is the thread from which the sync frame should ideally be used. In the case of corruption or loss of the thread 0 representation, a representation of the sync frame with a higher thread number can be used by the decoder. Lower thread numbers are expected to contain equal or better representations of the sync frames than higher thread numbers in the absence of data corruption or loss. See [7] for details. Trun: 4 bits Monotonically increasing (modulo 16) 4 bit number counting the packet number within each thread. S: 1 bit A bit that indicates that the packet content is for a sync frame. An encoder using VRC may send several representations of the same "sync" picture, in order to ensure that regardless of which thread of pictures is corrupted by errors or packet losses, the reception of at least one representation of a particular picture is ensured (within at least one thread). The sync picture can then be used for the prediction of any thread. If packet losses have not occurred, then the sync frame contents of thread 0 can be used and those of other threads can be discarded (and similarly for other threads). Thread 0 is considered the "canonical" thread, the use of which is preferable to all others. The contents of packets having lower thread numbers shall be considered as generally preferred over those with higher thread numbers. 5. Packetization schemes 5.1 Picture Segment Packets and Sequence Ending Packets (P=1) A picture segment packet is defined as a packet that starts at the location of a Picture, GOB, or slice start code in the H.263+ data stream. This corresponds to the definition of the start of a video picture segment as defined in H.263+. For such packets, P=1 always. An extra picture header can sometimes be attached in the payload header of such packets. Whenever an extra picture header is attached as signified by PLEN>0, only the last six bits of its picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte aligned picture start code can be conveniently assembled on the receiving end by prepending the sixteen leading '0' bits. When PLEN>0, the end bit position corresponding to the last byte of the picture header data is indicated by PEBIT. The actual bitstream data shall begin on an 8-bit byte boundary following the payload header. A sequence ending packet is defined as a packet that starts at the location of an EOS or EOSBS code in the H.263+ data stream. This delineates the end of a sequence of H.263+ video data (more H.263+ video data may still follow later, however, as specified in ITU-T Recommendation H.263). For such packets, P=1 and PLEN=0 always. The optional header extension for VRC may or may not be present as indicated by the V bit flag. 5.1.1 Packets that begin with a Picture Start Code Any packet that contains the whole or the start of a coded picture shall start at the location of the picture start code (PSC), and should normally be encapsulated with no extra copy of the picture header. In other words, normally PLEN=0 in such a case. However, if the coded picture contains an incomplete picture header (UFEP = "000"), then a representation of the complete (UFEP = "001") picture header may be attached during packetization in order to provide greater error resilience. Thus, for packets that start at the location of a picture start code, PLEN shall be zero unless both of the following conditions apply: 1) The picture header in the H.263+ bitstream payload is incomplete (PLUSPTYPE present and UFEP="000"), and 2) The additional picture header which is attached is not incomplete (UFEP="001"). A packet which begins at the location of a Picture, GOB, slice, EOS, or EOSBS start code shall omit the first two (all zero) bytes from the H.263+ bitstream, and signify their presence by setting P=1 in the payload header. Here is an example of encapsulating the first packet in a frame (without an attached redundant complete picture header): 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |1|V|0|0|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | bitstream data without the first two 0 bytes of the PSC | +---------------------------------------------------------------+ 5.1.2 Packets that begin with GBSC or SSC For a packet that begins at the location of a GOB or slice start code, PLEN may be zero or may be nonzero, depending on whether a redundant picture header is attached to the packet. In environments with very low packet loss rates, or when picture header contents are very seldom likely to change (except as can be detected from the GFID syntax of H.263+), a redundant copy of the picture header is not required. However, in less ideal circumstances a redundant picture header should be attached for enhanced error resilience, and its presence is indicated by PLEN>0. Assuming a PLEN of 9, below is an example of a packet that begins with a GBSC or a SSC: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |1|V|0 0 1 0 0 1|PEBIT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0| picture header starting with TR, PTYPE, ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | bitstream data begins with GBSC/SCC ... . +-+-+-+-+-+-+-+-+-----------------------------------------------+ Notice that only the last six bits of the picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte aligned picture start code can be conveniently assembled if needed on the receiving end by prepending the sixteen leading '0' bits. 5.1.3 Packets that Begin with an EOS or EOSBS Code For a packet that begins with an EOS or EOSBS code, PLEN shall be zero, and no Picture, GOB, or Slice start codes shall be included within the same packet. As with other packets beginning with start codes, the two all-zero bytes that begin the EOS or EOSBS code at the beginning of the packet shall be omitted, and their presence shall be indicated by setting the P bit to 1 in the payload header. System designers should be aware that some decoders may interpret the loss of a packet containing only EOS or EOSBS information as the loss of essential video data and may thus respond by not displaying some subsequent video information. Since EOS and EOSBS codes do not actually affect the decoding of video pictures, they are somewhat unnecessary to send at all. Because of the danger of misinterpretation of the loss of such a packet, encoders are generally to be discouraged from sending EOS and EOSBS. Below is an example of a packet containing an EOS code: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |1|V|0|0|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|0|0| +-+-+-+-+-+-+-+-+ 5.2 Encapsulating Follow-On Packet (P=0) A Follow-on packet contains a number of bytes of coded H.263+ data which does not start at a synchronization point. That is, a Follow-On packet does not start with a Picture, GOB, Slice, EOS, or EOSBS header, and it may or may not start at a macroblock boundary. Since Follow-on packets do not start at synchronization points, the data at the beginning of a follow-on packet is not independently decodable. For such packets, P=0 always. If the preceding packet of a Follow-on packet got lost, the receiver may discard that Follow-on packet as well as all other following Follow-on packets. Better behavior, of course, would be for the receiver to scan the interior of the packet payload content to determine whether any start codes are found in the interior of the packet which can be used as resync points. The use of an attached copy of a picture header for a follow-on packet is useful only if the interior of the packet or some subsequent follow-on packet contains a resync code such as a GOB or slice start code. PLEN>0 is allowed, since it may allow resync in the interior of the packet. The decoder may also be resynchronized at the next segment or picture packet. Here is an example of a follow-on packet (with PLEN=0): 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |0|V|0|0|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | bitstream data | +---------------------------------------------------------------+ 6. Use of this payload specification There is no syntactical difference between a picture segment packet and a Follow-on packet, other than the indication P=1 for picture segment or sequence ending packets and P=0 for Follow-on packets. See the following for a summary of the entire packet types and ways to distinguish between them. For a more detailed discussion on how to use the payload specification, the reader should refer to [8]. It is possible to distinguish between the different packet types by checking the P bit and the first 6 bits of the payload along with the header information. The following table shows the packet type for permutations of this information (see also the picture/GOB/Slice header descriptions in H.263+ for details): --------------+--------------+----------------------+------------------- First 6 bits | P-Bit | PLEN | Packet | Remarks of Payload |(payload hdr.)| | --------------+--------------+----------------------+------------------- 100000 | 1 | 0 | Picture | Typical Picture 100000 | 1 | > 0 | Picture | Note UFEP 1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs 1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs Xxxxxx | 0 | 0 | Follow-on | Xxxxxx | 0 | > 0 | Follow-on | Interior Resync --------------+--------------+----------------------+------------------- See [4] for details regarding the possible values of the six bits (a "1" bit followed by a five bit GN field explicit or emulated) of GOB, Slice, EOS, and EOSBS codes. As defined in this specification, every start of a coded frame (as indicated by the presence of a PSC) has to be encapsulated as a picture segment packet. If the whole coded picture fits into one packet of reasonable size (which is dependent on the connection characteristics), this is the only type of packet that needs to be observed. Due to the high compression ratio achieved by H.263+ it is often possible to use this mechanism, especially for small spatial picture formats such as QCIF and typical Internet packet sizes around 1500 bytes. If the complete coded frame does not fit into a single packet, two different ways for the packetization may be chosen. In case of very low or zero packet loss probability, one or more Follow-on packets may be used for coding the rest of the picture. Doing so leads to minimal coding and packetization overhead as well as to an optimal use of the maximal packet size, but does not provide any added error resilience. The alternative is to break the picture into reasonably small partitions - called Segments - (by using the Slice or GOB mechanism), that do offer synchronization points. By doing so and using the Picture Segment payload with PLEN>0, decoding of the transmitted packets is possible even in such cases in which the Picture packet containing the picture header was lost (provided any necessary reference picture is available). Picture Segment packets can also be used in conjunction with Follow-on packets for large segment sizes. 7. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [1], and any appropriate RTP profile (for example [3]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression so there is no conflict between the two operations. A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity. As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets >from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [5] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. A security review of this payload format found no additional considerations beyond those in the RTP specification. 8. References [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP : A Transport Protocol for Real-Time Applications", RFC 1889. [2] "Video Codec for Audiovisual Services at px64 kbits/s", ITU-T Recommendation H.261, 1993. [3] "RTP Profile for Audio and Video Conference with Minimal Control", RFC 1890. [4] "Video Coding for Low Bitrate Communication", Draft ITU-T Recommendation H.263, Draft 20, September 1997. [5] T. Turletti, C. Huitema, "RTP Payload Format for H.261 Video Streams", RFC 2032. [6] C. Zhu, "RTP Payload Format for H.263 Video Streams", RFC 2190. [7] S. Wenger, "Video Redundancy Coding in H.263+", Proc. AVSPN97, Aberdeen, U.K.. [8] S. Wenger, G. Knorr, J. Ott: "Error resilience support in H.263 V.2", submitted for publication to IEEE T-CSVT, 1997. From rem-conf Wed Jan 14 12:29:15 1998 From rem-conf-request@es.net Wed Jan 14 12:29:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xsZK1-00076Y-00; Wed, 14 Jan 1998 12:21:57 -0800 To: Toerless Eckert cc: rem-conf@es.net, mbone@isi.edu Subject: Re: sdr announcement questions In-reply-to: Your message of "Mon, 12 Jan 98 02:04:56 PST." <199801121004.LAA21225@faui45r.informatik.uni-erlangen.de> Date: Wed, 14 Jan 1998 12:21:34 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <98Jan14.122142pst.177480@crevenia.parc.xerox.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Toerless Eckert wrote: > There doesn't seem to be something like > a sequence number for announcements, or am i mistaken there ? The third field in the "o=" line is the version number; if you keep the other fields the same then the new announcement is supposed to replace the old one. >Replacement question: where's the documentation for the exact format and >semantics of the .sdr announcement files ? ;-)) sdr stores announcements with one or two header lines (n= and/or k= ) followed by an SDP (draft-ietf-mmusic-sdp-05.{txt,ps}) packet. Bill From rem-conf Wed Jan 14 18:38:51 1998 From rem-conf-request@es.net Wed Jan 14 18:38:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xsf7e-0002UO-00; Wed, 14 Jan 1998 18:33:34 -0800 Sender: "M. Strata Rose" Date: Wed, 14 Jan 98 12:33:28 PST From: strata@virtual.net Reply-To: strata@virtual.net To: rem-conf@es.net Subject: January BayLISA: SSH : Thurs, 1/15/1998 Message-ID: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ----------------------------------------------------------------------------- January BayLISA: SSH -- Introduction through Implementation Mbone broadcast, 01/15/1998 19:30 PST - approx 21:30 PST BayLISA will broadcast the following talk and take live questions from the mbone audience during the q&a period. If you are within the Bay Area, please feel free to drop by in person! We are working on generating session information further in advance of our meetings, so that more people may tune in. We apologize for the last-minute notice this month. Strata Rose, BayLISA Board Member ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- BayLISA General Meeting Thursday, 15 January, 1998 Cisco Building J1, LONDON Room <*** Note temporary room change, building remains the same. London Room is right next to usual room. Traditional ASCII map at end of posting. ----------------------------------------------------------------------------- Thursday, 15 January, 1998 SSH -- Introduction through Implementation, Steve Acheson Starting at 19:30, and continuing until about 21:30 SSH, the Secure Shell program, has matured into a popular and powerful tool for secure system access and securely performing remote functions, such as rdist and rsync. The talk will focus on: SSH features and authentication methods Overview of the different versions (both public and commercial) How to secure X11 connections using SSH How to do secure port forwarding with SSH Softare available for use with SSH (eg, rdist, rsync) ----------------------------------------------------------------------------- General Meetings: Unless otherwise noted, monthly meetings are held on the third Thursday of each month, at Cisco Systems in San Jose. Directions are available at this time, and please let us know if you have any questions. Light refreshments are generally served. BayLISA meetings are also broadcast on the MBONE using volunteer assistance and loaned hardware. MSRI has an MBONE broadcast schedule page as well as information about MBONE tools. Please see the BayLISA web site for more information about future meetings, BayLISA membership, and other neat stuff. http://www.baylisa.org/ Upcoming meetings: February 19th: All the News That Fits... Large Scale Netnews (Panel) Nick Christensen, Earthlink Danheil Baker, Supernews Landon Knoll, SGI ----------------------------------------------------------------------------- [http://www.baylisa.org/events/cisco.html] Getting To The Meeting at Cisco Systems Cisco Systems -- Building J Gateway Conference Facility 236 W. Tasman Drive San Jose, CA 95134 (At Highway 237 and N. First) Take any freeway to highway 237. If your on the Milpitas (east) side of the bay, head west towards Mountain View, if your on the Mountain View (west) side of the bay, head east towards Milpitas. Take highway 237 to N. First Street. Head south on N. First until you get to Tasman Drive. Turn right, following the light rail tracks. Go through the second signal, and Building J will be the middle of three buildings on your right before Vista Montana. You can enter the conference facility through the doors on the north side of the building. Look! An ongoing tradition, a terrible ASCII map! Cisco Main Campus ========================================================= \ Highway 237 \ \ Vista Montana/\ / \ ___________________ / \ Tasman Drive \ / \ \ / \ H / \ \ I \ G \ J \ F \ \ N. First Street \ K \ E \--- \ \ L \ D \ \ C \ \ \ \ B \----------\--------- Tasman Drive / \ A / \ Rio Robles Drive ----------------------------------------------------------------------------- =========================================================================== Strata Rose [KF6NBZ] strata@virtual.net VirtualNet Consulting http://www.virtual.net/ Internet: Installations, Security, Large Site Scaling Issues, E-Commerce =========================================================================== From rem-conf Thu Jan 15 02:46:25 1998 From rem-conf-request@es.net Thu Jan 15 02:46:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xsmdv-00066E-00; Thu, 15 Jan 1998 02:35:23 -0800 From: Edgar Hellfritsch Subject: SDR private announcements To: rem-conf@es.net Date: Thu, 15 Jan 1998 11:35:17 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Message-Id: <34bde6661085002@max4.rrze.uni-erlangen.de> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi In order to keep a public sdp announcement posted forever, you just set the date of expiry to zero in the corresponding cache file. fine. (ok, You're supposed not to do this, but in our case it's a necessity.) How can I do this with an encrypted cache file? Decode/edit/re-encode the cache file? Or do I have to keep re-announcing our regular private sessions every month? Any suggestions? Edgar From rem-conf Thu Jan 15 03:57:55 1998 From rem-conf-request@es.net Thu Jan 15 03:57:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xsnrZ-0006vf-00; Thu, 15 Jan 1998 03:53:33 -0800 To: Edgar Hellfritsch cc: rem-conf@es.net Subject: Re: SDR private announcements In-reply-to: Your message of "Thu, 15 Jan 1998 11:35:17 +0100." <34bde6661085002@max4.rrze.uni-erlangen.de> Date: Thu, 15 Jan 1998 11:53:04 +0000 Message-ID: <530.884865184@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Edgar Hellfritsch writes: >In order to keep a public sdp announcement posted forever, you just set the >date of expiry to zero in the corresponding cache file. fine. (ok, You're >supposed not to do this, but in our case it's a necessity.) > >How can I do this with an encrypted cache file? Decode/edit/re-encode the >cache file? Or do I have to keep re-announcing our regular private sessions >every month? ...or change the SDR UI to allow for non-expiry when creating the session, and SDR will encrypt it for you. Colin From rem-conf Thu Jan 15 08:52:09 1998 From rem-conf-request@es.net Thu Jan 15 08:52:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xssOD-0002DV-00; Thu, 15 Jan 1998 08:43:33 -0800 Message-Id: <199801151643.LAA03200@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-h263-video-01.txt Date: Thu, 15 Jan 1998 11:43:16 -0500 Sender: scoya@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Author(s) : C. Maciocco, J. Ott, C. Bormann, C. Zhu, L. Cline, D. Newell, G. Sullivan, G. Deisher, S. Wenger Filename : draft-ietf-avt-rtp-h263-video-01.txt Pages : 10 Date : 14-Jan-98 This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263 [4]. Because the 1998 version of H.263 is a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263. The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. The 1998 version is referred to as H.263+ in this document. Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode (ISD), the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [4] for more information on coding options. The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable to use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries. With the independent segment decoding option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Utilizing ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others. The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference fra Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-h263-video-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-h263-video-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-h263-video-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980115112135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-h263-video-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-h263-video-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980115112135.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jan 15 10:15:03 1998 From rem-conf-request@es.net Thu Jan 15 10:15:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xstih-0003JM-00; Thu, 15 Jan 1998 10:08:47 -0800 Message-Id: <3.0.5.32.19980115100825.00910bf0@ideal.jf.intel.com> X-Sender: bstrahm@ideal.jf.intel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Jan 1998 10:08:25 -0800 To: Edgar Hellfritsch , rem-conf@es.net From: Bill Strahm Subject: Re: SDR private announcements In-Reply-To: <34bde6661085002@max4.rrze.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:35 AM 1/15/98 +0100, you wrote: >Hi > >In order to keep a public sdp announcement posted forever, you just set the >date of expiry to zero in the corresponding cache file. fine. (ok, You're >supposed not to do this, but in our case it's a necessity.) > Is there any chance you could define an admin scope to announce your private sessions on. Along with the encryption, you get privacy through obscurity, and non-interested people will not have to see your private session and even know it is going on. I am getting more and more concerned about seeing SessionTitle (private) all over the SDP interface, since these announcements have only a small audience (all though it might be global) do they really belong on the public announcement group ? Bill Bill Strahm |Programming today is a race between bstrahm@ |software engineers striving to build ibeam.intel.com|bigger and better idiot-proof programs, (503) 264-4632 |and the Universe trying to produce |bigger and better idiots. So far, the |Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me From rem-conf Fri Jan 16 03:12:08 1998 From rem-conf-request@es.net Fri Jan 16 03:12:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xt9Tm-00033M-00; Fri, 16 Jan 1998 02:58:26 -0800 X-Authentication-Warning: archimedes.informatik.uni-mannheim.de: kuehne owned process doing -bs Date: Fri, 16 Jan 1998 11:58:20 +0100 (MET) From: Gerald Kuehne X-Sender: kuehne@archimedes To: rem-conf@es.net Subject: RTP payload for MPEG4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, are the any information available concerning a RTP payload for (parts of) MPEG4? bye Gerald From rem-conf Fri Jan 16 05:51:50 1998 From rem-conf-request@es.net Fri Jan 16 05:51:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xtC4v-0004MP-00; Fri, 16 Jan 1998 05:44:57 -0800 Date: 16 Jan 1998 08:42 EST Sender: "Vahe Balabanian" To: kuehne@pi4.informatik.uni-mannheim.de Cc: rem-conf@es.net, mpeg4-rtp@valathar.Eng.Sun.COM From: "Vahe Balabanian" Subject: re:RTP payload for MPEG4 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Gerard, a group from IETF AVT and ISO MPEG is presently drafting an RFC. It has not been uploaded yet as a draft RFC. Vahe Balabanian Nortel Advanced Tehnology In message "RTP payload for MPEG4", kuehne@pi4.informatik.uni-mannheim.de writes: > >Hi, > >are the any information available concerning a RTP payload for >(parts of) MPEG4? > >bye >Gerald > > > > > From rem-conf Fri Jan 16 16:15:53 1998 From rem-conf-request@es.net Fri Jan 16 16:15:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xtLpb-00022L-00; Fri, 16 Jan 1998 16:09:47 -0800 From: Ken Wong Reply-To: kenwong@nih.gov To: rem-conf@es.net Subject: NIH Mbone Broadcast Message-ID: Date: Fri, 16 Jan 1998 19:02:53 -0500 (EST) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.2 Build (32) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The NIH will be multicasting live to the Global Mbone the Xenotransplantation Conference. The conference will be held on January 21 and 22 at the NIH in Bethesda, Md from 8am to 6pm EST. This multicast is intended to facilitate the real-time delivery of health information. All comments welcomed. Ken ---------------------- Ken Wong kenwong@nih.gov From rem-conf Fri Jan 16 20:57:24 1998 From rem-conf-request@es.net Fri Jan 16 20:57:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xtQ9A-0003U8-00; Fri, 16 Jan 1998 20:46:16 -0800 Message-Id: <199801170446.UAA05211@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: kenwong@nih.gov cc: rem-conf@es.net Subject: Re: NIH Mbone Broadcast In-reply-to: Your message of "Fri, 16 Jan 1998 19:02:53 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jan 1998 20:46:03 -0800 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Curious what is Xenotransplantation? Tnks, Amancio From rem-conf Mon Jan 19 09:48:42 1998 From rem-conf-request@es.net Mon Jan 19 09:48:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xuKl7-0001aj-00; Mon, 19 Jan 1998 09:13:13 -0800 Date: Mon, 19 Jan 1998 12:11:27 -0500 (EST) From: Christian Huitema Message-Id: <980119121126.ZM2984@seawind.bellcore.com> In-Reply-To: Stephen Casner "Re: RTP QOS reports for large groups" (Jan 10, 11:24pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Stephen Casner , rem-conf@es.net Subject: Re: RTP QOS reports for large groups Cc: Henning Schulzrinne MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > When that field was added (at the > 1995 San Jose IETF, if memory serves), the purpose was to allow single > reception reports to be useful because the interval between reports > could become quite long in large groups. There was actually a debate between two groups based on, essentially the VAT experience and the IVS/MICE experience. Van Jacobson had work hard to develop diagnostic tools that would take the reports from VAT and use them in order to detect network problems, or MBONe problems. To do that, you need indications that are very well defined, so you can easily compare reports issued by different implementations, and relate them to physical variables. In the MICE project, we had started experimenting with rate adaptation as a way to cope with congestion (see the communication by Wakeman, Turletti and Bolot in the 1994 Sigcomm conference). To adapt, you need a signal that reflects the short term experience of users -- the average loss rate over the last 5 minutes is not terribly useful. If you have short term averages coming from a random set of recipient, you can assume that the observers get a statistical sampling of the short term conditions, and you can then adapt the behavior of sources. The loss rate indication was initially added to RTP to enable this kind of adaptation; but the whole purpose was kind of lost in the final definition. I would like to define the loss rate as a running average over some period. Clearly, there is a debate on what the period should be. However, there are only 8 bits allocated to the loss rate, which sort of constrains the design space. What about an exponential average with a half life of 128 packets ? -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ From rem-conf Mon Jan 19 11:30:39 1998 From rem-conf-request@es.net Mon Jan 19 11:30:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xuMlO-0002MZ-00; Mon, 19 Jan 1998 11:21:38 -0800 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Christian Huitema cc: Stephen Casner , rem-conf@es.net, Henning Schulzrinne Subject: Re: RTP QOS reports for large groups In-reply-to: Your message of "Mon, 19 Jan 1998 12:11:27 EST." <980119121126.ZM2984@seawind.bellcore.com> Date: Mon, 19 Jan 1998 14:21:30 -0500 Message-ID: <6540.885237690@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >I would like to define the loss rate as a running average over some >period. Clearly, there is a debate on what the period should be. However, >there are only 8 bits allocated to the loss rate, which sort of constrains >the design space. What about an exponential average with a half life of >128 packets ? Unless you're actually using this is a feedback loop, it's likely that the current definition is more useful for general monitoring purposes. Whilst I agree that the current definition is not terribly useful for any congestion control scheme, I'm unconvinced that we can fix an interval now and get it right. The alternative would seem to be to change the spec to allow any form of filter to be used to process the loss reports prior to sending, and to specify the filter characteristics out of band (such as in SDP). The default could be the current spec, but apps should expect to be able to be told to use an exponential average or a time interval filter with a specified parameter. This would let us experiment with particular values without having to have access to the receivers source code. Different sessions could use different filters if this turns out to be useful. To implement this, we'd probably need a bit from somewhere to indicate that a particular RR is using the specified report filter rather than the default one to prevent old receivers confusing senders. Cheers, Mark From rem-conf Mon Jan 19 22:21:59 1998 From rem-conf-request@es.net Mon Jan 19 22:21:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xuWxx-0005Px-00; Mon, 19 Jan 1998 22:15:17 -0800 Message-Id: <199801200615.WAA22300@mlk.cs.berkeley.edu> To: rem-conf@es.net cc: Brian Smith Subject: ACM Multimedia 98 From: mccanne@eecs.berkeley.edu (Steven McCanne) Date: Mon, 19 Jan 1998 22:15:16 -0800 Sender: mccanne@mlk.cs.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would like to point out to people on this list that the ACM Multimedia paper deadline is approaching. This conference is unique in that it brings together researchers working on content and applications with those (like many on this list) working on protocols and network infrastructure. A number of papers related to RTP and the MBone have been published in past Multimedia proceedings. More info, including the call, is available at http://www.acm.org/sigmm/MM98/ Steve From rem-conf Wed Jan 21 01:36:43 1998 From rem-conf-request@es.net Wed Jan 21 01:36:42 1998 Received: from list by mail2.es.net with local (Exim 1.81 #2) id 0xuwJV-0004Xl-00; Wed, 21 Jan 1998 01:19:13 -0800 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9801210915.AA03041@ece.iisc.ernet.in> Subject: Re: RTP QOS reports for large groups To: hgs@cs.columbia.edu Date: Wed, 21 Jan 98 14:45:17 GMT+5:30 Cc: rem-conf@es.net In-Reply-To: <34B83A88.FD9941F2@cs.columbia.edu>; from "Henning Schulzrinne" at Jan 10, 98 10:20 pm X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Can't we adopt ideas given in the paper "A reliable multicast framework for light-weight sessions and application level framing" by Sally Floyd et al. and bring in some sort of scoping for RR reports in the context of quality reporting ? The same paper mentions "packet loss in multicast traffic is most likely to occur not in the backbone but in the edges of the multicast network" and suggests the use of loss neighborhood to limit the number of loss requests, repairs. Poor audio/video reception can be due to congested links, and the locality of the congestion from the above paragraph is most likely at the edge of the network. So why can't we limit RR reports to "loss neighborhood" for action to be taken instead of to the entire group ? I am not addressing the issue of participants identity conveyed in the reports here. Regards Anand. From rem-conf Wed Jan 21 02:31:37 1998 From rem-conf-request@es.net Wed Jan 21 02:31:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xuxNL-00079y-00; Wed, 21 Jan 1998 02:27:15 -0800 To: anand@ece.iisc.ernet.in (SVR Anand) cc: hgs@cs.columbia.edu, rem-conf@es.net Subject: Re: RTP QOS reports for large groups In-reply-to: Your message of "Wed, 21 Jan 1998 14:45:17 GMT." <9801210915.AA03041@ece.iisc.ernet.in> Date: Wed, 21 Jan 1998 10:22:20 +0000 Message-ID: <2125.885378140@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <9801210915.AA03041@ece.iisc.ernet.in>, SVR Anand typed: >>Can't we adopt ideas given in the paper "A reliable multicast framework for >>light-weight sessions and application level framing" by Sally Floyd et al. >>and bring in some sort of scoping for RR reports in the context of quality >>reporting ? yes - dynamic, continuous autoconfiguring areas and "representatives" (possibly nested) who then scope their reports appropriately and dynamically set their timers as per SRM is a good idea - i think deborah estrin has folks working on this... >>The same paper mentions "packet loss in multicast traffic is most likely >>to occur not in the backbone but in the edges of the multicast network" >>and suggests the use of loss neighborhood to limit the number of loss >>requests, repairs. >>Poor audio/video reception can be due to congested links, and the locality >>of the congestion from the above paragraph is most likely at the edge of >>the network. So why can't we limit RR reports to "loss neighborhood" for >>action to be taken instead of to the entire group ? >> >>I am not addressing the issue of participants identity conveyed in the >>reports here. >> >>Regards >>Anand. >> cheers jon From rem-conf Wed Jan 21 02:31:38 1998 From rem-conf-request@es.net Wed Jan 21 02:31:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xuxK0-000778-00; Wed, 21 Jan 1998 02:23:48 -0800 To: anand@ece.iisc.ernet.in (SVR Anand) cc: hgs@cs.columbia.edu, rem-conf@es.net Subject: Re: RTP QOS reports for large groups In-reply-to: Your message of "Wed, 21 Jan 1998 14:45:17 GMT." <9801210915.AA03041@ece.iisc.ernet.in> Date: Wed, 21 Jan 1998 10:23:09 +0000 Message-ID: <779.885378189@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> SVR Anand writes: >Can't we adopt ideas given in the paper "A reliable multicast framework for >light-weight sessions and application level framing" by Sally Floyd et al. >and bring in some sort of scoping for RR reports in the context of quality >reporting ? >The same paper mentions "packet loss in multicast traffic is most likely >to occur not in the backbone but in the edges of the multicast network" >and suggests the use of loss neighborhood to limit the number of loss >requests, repairs. Well, my experience is that there is a lot of congestion in the backbone links too, both within SuperJANET (the UK research network), and on the international links. Maybe the "packet loss in multicast traffic is most likely to occur not in the backbone but in the edges of the multicast network" comment is true in some places, but certainly not all. >Poor audio/video reception can be due to congested links, and the locality >of the congestion from the above paragraph is most likely at the edge of >the network. So why can't we limit RR reports to "loss neighborhood" for >action to be taken instead of to the entire group ? This limits the scope for session monitoring tools somewhat, which are very useful as the first stage for finding network problems. I'm also not sure it's the right approach for loss repair: in many cases you want the RR to go back to the original sender of a media stream, so that sender can be informed to lower its rate, and add some form of FEC to the stream. -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: (+44) 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf Wed Jan 21 04:00:11 1998 From rem-conf-request@es.net Wed Jan 21 04:00:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xuymu-0000UM-00; Wed, 21 Jan 1998 03:57:44 -0800 Date: Wed, 21 Jan 1998 11:47:55 +0000 (GMT) From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: rem-conf@es.net Subject: vat on Win95 - voice controlled mode? Message-ID: X-antiSpam: Do not send me unsolicited commercial email MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I don't seem to be able to operate vat in a voice controlled mode in Win95. When I'm speaking, the respective line of the vat display "lights up", and when I stop speaking, it goes out, but I don't seem to hear from the other participant(s) until I turn off the "talk" button. First investigations suggested that it might be an issue whether the sound card supports full duplex. Well, according to the documentation, this sound card _does_ support full duplex. Should I expect this to work or not? If so, any suggestions how to go about debugging it further, please? From rem-conf Wed Jan 21 04:00:11 1998 From rem-conf-request@es.net Wed Jan 21 04:00:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xuyk0-0000Sg-00; Wed, 21 Jan 1998 03:54:44 -0800 Message-ID: <34C5E1C1.D1E2A8BE@telematik.informatik.uni-karlsruhe.de> Date: Wed, 21 Jan 1998 12:53:37 +0100 From: Markus Hofmann Reply-To: hofmann@telematik.informatik.uni-karlsruhe.de Organization: University of Karlsruhe X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Jon Crowcroft CC: SVR Anand , rem-conf@es.net Subject: Re: RTP QOS reports for large groups References: <2125.885378140@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jon Crowcroft wrote: > yes - dynamic, continuous > autoconfiguring areas and "representatives" (possibly nested) > who then scope their reports appropriately and dynamically set their > timers as per SRM is a good idea - i think deborah estrin has folks > working on this... Right, but scoping based on TTL is not very precise. Why not to build separate subgroups, each of them having a separate multicast address? There has also been some interesting discussion during the RM meeting in Cannes about a modified multicast service model (see http://www.east.isi.edu/rm/ for presentation material an minutes).) Cheers Markus From rem-conf Wed Jan 21 04:23:33 1998 From rem-conf-request@es.net Wed Jan 21 04:23:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xuz76-0001Fq-00; Wed, 21 Jan 1998 04:18:36 -0800 Message-Id: <199801211218.NAA03651@basil.cdt.luth.se> X-Mailer: exmh version 2.0.1 12/23/97 To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-new-00.txt,.ps In-reply-to: Your message of "Mon, 05 Jan 1998 12:42:53 EST." <34B11B9D.1A7E1330@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jan 1998 13:18:22 +0100 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi This is probably some very old thing but I was wondering why it says on page 45 that "The NAME value is expected to remain constant at least for the duration of a session." regarding the SDES NAME field? If that should remain in there shouldn't all MBone applications enforce this then? Today, as you all know, it is very easy to change the name during a session. /P From rem-conf Wed Jan 21 06:02:10 1998 From rem-conf-request@es.net Wed Jan 21 06:02:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xv0cz-0002H3-00; Wed, 21 Jan 1998 05:55:37 -0800 Sender: hgs@cs.columbia.edu Message-ID: <34C5FE53.E8DAC1FE@cs.columbia.edu> Date: Wed, 21 Jan 1998 08:55:31 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Peter Parnes CC: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-new-00.txt,.ps References: <199801211218.NAA03651@basil.cdt.luth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Peter Parnes wrote: > > Hi > > This is probably some very old thing but I was wondering why it says on page > 45 that > "The NAME value is expected to remain constant at least for the duration of a > session." regarding the SDES NAME field? > > If that should remain in there shouldn't all MBone applications enforce this > then? Today, as you all know, it is very easy to change the name during a > session. This may be partly due to the fact that not all applications support NOTE as the appropriate alternative to putting messages in one's name field. It may be appropriate to add advice to discourage the change of these fields and use NOTE for temporary anouncements. > > /P -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 (@Bell Labs: 732 949 8344) Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf Wed Jan 21 11:25:49 1998 From rem-conf-request@es.net Wed Jan 21 11:25:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xv5f0-0004oB-00; Wed, 21 Jan 1998 11:18:02 -0800 From: Tom Zoerner Message-Id: <199801211917.UAA05180@faui01.informatik.uni-erlangen.de> Subject: Timestamp definition in FEC draft To: rem-conf@es.net Date: Wed, 21 Jan 1998 20:17:56 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi. I'm currently implementing a multicast application with FEC according to draft-ietf-avt-fec-01. However I have some trouble with the way timestamps are supposed to be set. In the draft is says to use the timestamp of the oldest xor'ed packet. I see two problems with this: 1) I cannot add LPC redundancy for the latest packet, since the offsets in redundancy encoded payloads can only be negative. If I do FEC with one or several later packets however, the offset would be zero or positive. I'm not sure yet if it's a good idea to combine LPC redundancy with FEC, but my idea is to recover loss-less from single losses (I'm working with layered codecs so I need that property) and use the usual repair and error concealment techniques for multi-packet losses. 2) jitter/delay calculation: well, I cannot actually generate the FEC packet before I have the data for the latest to-be-coded packet. That means however, that the timestamp on the packet being sent differs wildly from the actual time the packet was generated. Hence I can not easily use FEC packets for jitter calculation. The simple solution seems to be to exclude FEC packets completely from jitter calculation, however the sender may use a scheme where he sends *only* FEC encoded packets, e.g. scheme 2 from Budge's draft. The only reason the draft gives for chosing the oldest timestamp for the whole packet is because it "is a somewhat natural definition". Well, I believe using the latest timestamp would be even more natural, since in addition to the 2 points above the timestamps in the packet stream would still increase monotonically. So I'd like to propose to reconsider the draft in that point. (Is there actually already software in use based on that draft?) -tom From rem-conf Wed Jan 21 15:03:27 1998 From rem-conf-request@es.net Wed Jan 21 15:03:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xv970-0006N4-00; Wed, 21 Jan 1998 14:59:10 -0800 From: "Edward W. Knightly" Message-Id: <980121165906.ZM25471@qos.ece.rice.edu> Date: Wed, 21 Jan 1998 16:59:06 -0600 X-Mailer: Z-Mail (4.0.1 13Jan97) To: rem-conf@es.net Subject: IWQoS Call for Papers MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Below is the final CFP for IWQoS '98. The workshop's URL is http://www-ece.rice.edu/conf/iwqos98/ Best regards, -Ed Knightly (IWQoS '98 co-chair) ________________________________________________ CALL FOR PAPERS Sixth IEEE/IFIP International Workshop on Quality of Service (IWQoS '98) -Napa, California USA - May 18-20, 1998 Sponsored by IEEE Communications Society Technical Committees on Computer Communications, Internet, Multimedia Communications, and Software Technical co-sponsorship by IFIP WG6.1* In co-operation with ACM SIGCOMM Patrons: Hewlett Packard and Nokia Corporation *to be approved ________________________________________________ INVITED PROGRAM --------------- Keynote Address - Roch Guerin, IBM Research Keynote Paper - Domenico Ferrari, Universita' Cattolica Piacenza, Italy Panel Chair - Hui Zhang, Carnegie Mellon University "The Future of Differential and Integrated Services in the Internet" Panel Chair - Vaduvur Bharghavan, University of Illinois at Urbana Champaign "QoS in Wireless Networks: the Transition from Myth to Reality" WORKSHOP SCOPE -------------- This is the sixth in a series of workshops aimed at providing an international forum for the exchange of information on quality of service (QoS) research in distributed and Internet systems. The objective of the Sixth International Workshop on Quality of Service is to bring together researchers, developers, and practitioners working in all facets of QoS research addressing distributed systems, Internet services, multimedia, operating systems, networking, and middleware to discuss recent results and future directions. Contributions are solicited in all areas of QoS research in distributed systems and networking, including, but not limited to: - QoS Specification, Resource Allocation, (Re)negotiation, and Monitoring - QoS and the Internet - QoS Performance Modeling, Analysis and Evaluation - Adaptive Applications and Services - QoS Measurement, Management and Control - QoS Support for Mobility and Wireless Networks - Middleware Solutions for End-to-End QoS - Media Scaling and QoS Filtering Techniques - QoS Support for Information Appliances - Storage Systems/Database Support for QoS - Experimental Studies on QoS, including Human Perception - QoS Programmability, Languages and Formal Method Techniques - QoS Economics and Implications WORKSHOP URL ------------ http://www-ece.rice.edu/conf/iwqos98 IMPORTANT DATES --------------- * Submission of contribution: February 23, 1998 * Notification of acceptance: April 6, 1998 * Camera-ready paper due: April 13, 1998 PAPER SUBMISSION ---------------- Authors are invited to submit full papers and position statements for review. Full papers should not exceed 12 single-spaced pages including figures, tables, and references, using a typeface no smaller than 11 points. Position statements should not exceed 3 single-spaced pages. To expedite the reviewing process, please submit the paper electronically (in postscript format only, through e-mail) to iwqos98@ece.rice.edu. All submissions must include name and affiliation of the authors, a contact address of the main author, an abstract, and keywords. PROGRAM CO-CHAIRS: ------------------ Ed Knightly, Rice University Rich Friedrich, Hewlett Packard Laboratories PROGRAM COMMITTEE: ------------------ Vaduvur Bharghavan, University of Illinois at Urbana Champaign, USA Gordon Blair, University of Lancaster, UK Andrew Campbell, Columbia University, USA Simon Crosby, Cambridge University, UK Jon Crowcroft, UCL, UK Hermann de Meer, University of Hamburg, Germany Jan de Meer, GMD Fokus, Germany Sudhir Dixit, Nokia Research, USA Alexandros Eleftheriadis, Columbia University, USA Domenico Ferrari, Universita' Cattolica Piacenza, Italy Leonard Franken, KPN Research, The Netherlands Michael Fry, University of Technology, Australia Jean-Peirre Hubaux, EPFL, Switzerland Brigitte Kerherve, University of Quebec at Montreal, Canada Glenford Mapp, Olivetti Research Ltd, UK Mahmoud Nagshineh, IBM Thomas J. Watson Research Center, USA Klara Nahrstedt, University of Illinois at Urbana Champaign, USA Max Ott, C&C Research, NEC USA Guru Parulkar, Washington University, USA Steve Pink, Lulea University of Technology, Sweden Jerry Rolia, Carleton University, Canada Douglas Schmidt, Washington University, USA Chris Sluman, OpenIT Ltd, UK Cormac Sreenan, AT&T Research, USA Hideyuki Tokuda, Keio University, Japan James VanLoo, Sun Microsystems, USA Andreas Vogel, DSTC, Australia Lixia Zhang, University of California, Los Angeles, USA Hui Zhang, Carnegie Mellon University, USA From rem-conf Thu Jan 22 01:55:03 1998 From rem-conf-request@es.net Thu Jan 22 01:55:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xvJBT-0001xP-00; Thu, 22 Jan 1998 01:44:27 -0800 Message-ID: <34C71042.AB75BD43@cisco.com> Date: Thu, 22 Jan 1998 01:24:19 -0800 From: Chase Bailey Organization: Cisco Systems X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: 6bone@isi.edu, alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, atmpost@hplabs.hpl.hp.com, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, citmalum@haas.berkeley.edu, citmlst@haas.berkeley.edu, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, "comsoc-gicb@ieee.org" , comsoc.tac@tab.ieee.org, cost237-gen@montefiore.ulg.ac.be, cost237-teleservices@comp.lancs.ac.uk, cost237-transport@comp.lancs.ac.uk, Cost237-WG3@masi.ibp.fr, cswg%sunoco@relay.nswc.navy.mil, dbworld@cs.wisc.edu, end2end-interest@isi.edu, enternet@bbn.com, epr@infotest.com, f-troup@codex.cis.upenn.edu, FORTE94_CFP@admin.unibe.ch, g-troup@ccrc.wustl.edu, globecom@signet.com.sg, golshani@asu.edu, hipparch@sophia.inria.fr, hpcs95-prog@VM1.NODAK.EDU, ICAD@santafe.edu, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, itc@fokus.gmd.de, kia@koko.CS.UNLV.EDU, manet@itd.nrl.navy.mil, mobile-ip@tadpole.com, mospf@gated.cornell.edu, mpls@external.cisco.com, multicomm@cc.bellcore.com, ni@cps.msu.edu, nlanr@nlanr.net, ns-users@mash.cs.berkeley.edu, ns-annouce@mash.cs.berkeley.edu, OSIMCAST@bbn.com, park@cstp.umkc.edu, perform@tay1.dec.com, rdhm@masi.ibp.fr, rem-conf@es.net, reres@laas.fr, rm@mash.cs.berkeley.edu, rsvp@isi.edu, SC6WG4@ntd.comsat.com, sigmedia@bellcore.com, singhal@cis.ohio-state.edu, tccc@cs.umass.edu, tcp-over-satellite@achtung.sp.trw.com, udlr@sophia.inria.fr, wiggles@ca.ibm.com, xtp-relay@cs.concordia.ca Subject: HOT INTERCONNECTS VI - CALL FOR PAPERS X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS HOT INTERCONNECTS VI A Symposium on High Performance Interconnects, >from system buses and interfaces to networks August 13-15, 1998 Stanford University Stanford, California, U.S.A. Sponsored by the IEEE Computer Society Technical Committee on Microprocessors and Microcomputers. Hot Interconnects is an international symposium focusing on the hardware and software architecture and implementation of high-performance interconnects of all scales. The conference is directed particularly at new and exciting product and technology innovations in interconnects from system buses and interfaces to small and large scale networks and network software. Contributions should focus on real products, prototypes, or experimental systems and their performance evaluation. Contributions are solicited in, but not limited to, the following topics: - High speed serial links - High performance buses and interfaces - Multi-Mbps to the home - Processor-memory interconnects - Gigabit per second networking technologies - Cluster interconnects - Terabit per second networking technologies - Network-attached storage devices and interfaces - Performance evaluation of interconnects - Optical Interconnects - Web casting technologies - Video and audio on the Internet - High performance network switches - Wireless and mobile networks - Bus support chip sets - Network security - Networking chip sets - Innovations in distributed computing - Network protocols on a chip - Emerging network appliance technologies - Innovations in distributed computing - Low power devices The deadline for submissions is March 1, 1998. Contributions can be in the form of full papers or in abstracts or position statements for review. Full papers should not exceed 15 single-spaced pages including figures, tables, and references. Abstracts or Position Statements should not exceed 3 pages. To expedite the reviewing process please submit the paper electronically in ASCII, postscript, word or pdf format to hoti@stanford.edu. Hardcopy submissions should be mailed in 10 copies to Nick McKeown, Program Co-chair, Hot Interconnects VI, Computer Systems Lab., Stanford University, Stanford, CA 94305-9030, USA. All submissions must include name and affiliation of the authors, a contact address (phone, fax and email address) of the main author. Web Site: http://www.hoti.org ------------------------------------------------------------------------ Important Dates: - March 1, 1998: Paper submission deadline - May 15, 1998: Notifications of acceptance mailed to authors - June 15, 1998: Final camera-ready manuscripts due. ------------------------------------------------------------------------ General Chair: - Hasan Alkhatib, Santa Clara University halkhatib@scu.edu, 408-554-4485 Program Commitee Co-Chairs: - Nick McKeown, Stanford University nickm@stanford.edu, 650-725-3641 - Chase Bailey, Cisco Systems chase@cisco.com, 408-527-3765 Program Commitee: - Bill Dally, Stanford - Chuck Thacker, Microsoft - Craig Partridge, BBN/GTE - Dan Pitt, Bay Networks - Dave Oran, Cisco Systems - Greg Chesson, Silicon Graphics - James Luciani, Bay Networks - Kathleen Nichols, Bay Networks - Mark Horowitz, Stanford - Martin Izzard, Texas Instruments - Qiang Li, Santa Clara University - Randy Rettberg, Sun Microsystems - Steve Deering, Cisco Systems Publicity Committee: - Kristina Scott, Cisco Systems krscott@cisco.com, 408-527-1504 From rem-conf Thu Jan 22 03:28:31 1998 From rem-conf-request@es.net Thu Jan 22 03:28:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xvKhv-0002a9-00; Thu, 22 Jan 1998 03:22:03 -0800 To: Tom Zoerner cc: rem-conf@es.net Subject: Re: Timestamp definition in FEC draft In-reply-to: Your message of "Wed, 21 Jan 1998 20:17:56 +0100." <199801211917.UAA05180@faui01.informatik.uni-erlangen.de> Date: Thu, 22 Jan 1998 11:21:12 +0000 Message-ID: <721.885468072@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <199801211917.UAA05180@faui01.informatik.uni-erlangen.de>Tom Zoerner writes: > I'm currently implementing a multicast application with FEC according to > draft-ietf-avt-fec-01. However I have some trouble with the way timestamps > are supposed to be set. In the draft is says to use the timestamp of the > oldest xor'ed packet. I see two problems with this: > > 1) I cannot add LPC redundancy for the latest packet, since the offsets > in redundancy encoded payloads can only be negative. If I do FEC with > one or several later packets however, the offset would be zero or positive. > > I'm not sure yet if it's a good idea to combine LPC redundancy with FEC, It looks like a lot of work for an uncertain reward. I am also implementing the parity fec proposed in draft-ietf-avt-fec-01, and have some simulator code for the budge schemes for a prelimary investigation. I ran random and burst loss models against parity fec, interleaving, and redundancy. Two of the parity fec schemes proposed by Budge et al performed considerably better than redundancy upto 20% loss rates before their performance fell sharply. The simulation did not account for redundancy generating larger packets and parity fec more packets, both of which adversely affect router performance. Neither did the simulation allow for bigger time offsets between the media units xor'ed together which makes both redundancy and parity fec deal better with the bursty losses observed. We probably want tools to be smart about the ranges and effects of fec techniques, or perhaps the fec on separate multicast groups. > 2) jitter/delay calculation: well, I cannot actually generate the FEC > packet before I have the data for the latest to-be-coded packet. That > means however, that the timestamp on the packet being sent differs > wildly from the actual time the packet was generated. Hence I can not > easily use FEC packets for jitter calculation. The problem is when you release the packets, if you hold onto all of the packets with the same timestamp and release them consecutively then you reduce some of the wild variation. > The simple solution seems to be to exclude FEC packets completely from > jitter calculation, however the sender may use a scheme where he sends > *only* FEC encoded packets, e.g. scheme 2 from Budge's draft. > > The only reason the draft gives for chosing the oldest timestamp for > the whole packet is because it "is a somewhat natural definition". > Well, I believe using the latest timestamp would be even more natural, > since in addition to the 2 points above the timestamps in the packet > stream would still increase monotonically. But this breaks if the offset between xor'ed units is not 1. i.e xor f(x) f(x,x+10) f(x+1) f(x+1,x+11) ts x x+10 x+1 x+11 -- Orion Orion Hodson [Research Student] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, UK. Tel: (0)171 419 3704. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From rem-conf Thu Jan 22 06:31:45 1998 From rem-conf-request@es.net Thu Jan 22 06:31:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xvNa4-0003nE-00; Thu, 22 Jan 1998 06:26:08 -0800 Message-ID: <34C7489C.E3B9B484@dnrc.bell-labs.com> Date: Thu, 22 Jan 1998 08:24:44 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Zoerner CC: rem-conf@es.net Subject: Re: Timestamp definition in FEC draft References: <199801211917.UAA05180@faui01.informatik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Tom Zoerner wrote: > > 2) jitter/delay calculation: well, I cannot actually generate the FEC > packet before I have the data for the latest to-be-coded packet. That > means however, that the timestamp on the packet being sent differs > wildly from the actual time the packet was generated. Hence I can not > easily use FEC packets for jitter calculation. > > The simple solution seems to be to exclude FEC packets completely from > jitter calculation, however the sender may use a scheme where he sends > *only* FEC encoded packets, e.g. scheme 2 from Budge's draft. An alternative is to use the redundancy payload format to send the FEC packets. Lets say you were using a (5,7) scheme (that is, five data packets, plus two more FEC). The two FEC packets would then be piggybacked as "redundant codecs" with the first two data packets in the next block. This actually accomplishes a number of things: -hides the jitter in FEC packet generation, since the media packet timestamps, not the FEC, are used for jitter computation -reduces header overheads -works well with RTP header compression I should point out to you that I don't think the current FEC scheme supports sending *only* FEC encoded packets. This is because the FEC packets use a bitmask to indicate which media packets the FEC is applied to. The bitmask indicates offsets in sequence number space. Now, if the media packets are never actually sent by themselves, they don't have a sequence number of their own, and therefore cannot be referenced via the mask. Thus, the FEC payload format would only work for what are called "systematic codes" where the FEC always follows the original data (with the current mask definition, you could also send them before). I believe that there are results from coding theory that have shown that this restriction does not affect the performance of the code. I'm not sure whether these results apply here, though. The earlier draft didn't have this restriction. The media packets had their own sequence numbering space. FEC packets had their sequence number computed in the same way as the media - the xor of the sequence numbers of the associated packets. The problem with this was that having screwy, non-contiguous sequence numbering broke RTP compression and made it harder to actually detect lost packets. > > The only reason the draft gives for chosing the oldest timestamp for > the whole packet is because it "is a somewhat natural definition". > Well, I believe using the latest timestamp would be even more natural, > since in addition to the 2 points above the timestamps in the packet > stream would still increase monotonically. The definition of the timestamp, from RFC1889, is "The timestamp reflects the sampling instant of the first octet in the RTP data packet". For FEC, this would be the sampling instant of the oldest packet covered by the FEC. This is what I meant by "natural" - it is based on the current definition. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (732) 949-6418 Rm. 4C-526 FAX: (732) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jan 22 06:54:26 1998 From rem-conf-request@es.net Thu Jan 22 06:54:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xvNxO-00048I-00; Thu, 22 Jan 1998 06:50:14 -0800 X-Lotus-FromDomain: VOCALTEC From: "Ron Kalian" To: rem-conf@es.net cc: "Scott Petrack" Message-ID: <42256594.004F8E70.00@il4.vocaltec.co.il> Date: Thu, 22 Jan 1998 16:49:07 +0200 Subject: Proposal for change to the current RTP/RTCP spec Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, The current RTP/RTCP spec allows for sending RTCP Receiver Report (RR) extensions, should the existing RR parameters not suffice. The spec specifies very little about the RR extensions - allowing anything to be an RR extension so long as it follows the RRs in the RR packet.. A problem with this is that there is no way to uniquely identify extensions. Although it is possible to start the extension with a some "unique" identifier, one party's RR extensions may get misinterpreted by another party as their own! I think there must be a way to uniquely identify one's RR extensions. For this reason I would like to propose the following addition to the RTCP spec: "The RR extension part of the RR packet must begin with a unique 32-bit identifier, that must be registered with IANA." RR extensions are not the only way of passing application specific RTCP data. It is also possible to use an APP packet, in which case a new RTCP packet type may be registered with IANA. But there are cases in which it is preferable to use RR extensions, because: 1. Transmitting the same extension data, RR extensions save 64-bits due to lack of APP packet header, even if a 32-bit identifier is included (in the case of an APP packet - in the 'name' field). 2. Some extension data are closely related to the RR data, in which case it must be transmitted together with the RR as RR extensions. In any case, the readers of RR packets should be able to determine whether or not they can read a given extension. This can only be achieved using unique identifiers for RR extensions. Ron Kalian. _________________________________ Ron Kalian Program Manager VocalTec Communications Ltd. Phone: ++972-9-9525852 Email: ron@vocaltec.com _________________________________ Visit us at CeBIT 98' Hannover Messe March 19 - 25, 1998 From rem-conf Fri Jan 23 15:32:06 1998 From rem-conf-request@es.net Fri Jan 23 15:32:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xvsN1-0000Gq-00; Fri, 23 Jan 1998 15:18:43 -0800 Date: Fri, 23 Jan 1998 15:18:30 -0800 From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199801232318.PAA24126@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu Subject: DC IETF MBone content available X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This e-mail is going out to a few mailing lists, and I cringe to do it, but it is relevant to all... (lists bcc'ed to prevent accidents). *** Announcing Availability of the DC IETF Sessions on the IMJ I'm ready to announce that all the sessions from the 40th IETF in DC that were transmitted on the MBone are now available on the IMJ (http://imj.gatech.edu) for on-demand playback. You can schedule programs via the WWW page and start the MBone sessions via SDR (or the WWW page with a simple plug-in). For additional information about the MBone see http://mbone.com. Now that I've graduated and settled down somewhat in my new position at the University of California, Santa Barbara, I hope to continue research on the IMJ and to make the archival of IETF meetings a regular service. Part of this work includes encoding the sessions in real-time as they are being broadcast. This will significantly cut down on the turn around time between when the content is first broadcast and when it is available for replay. Finally, and as usual, I've included the original IMJ e-mail announcement for those who want additional information about the IMJ. Any suggestions for improvement are welcome. -Kevin **** Announcing the Interactive Multimedia Jukebox At one point on the MBone list there was a discussion of what on-demand servers exist or are being developed. Well, I'd like to announce our version called the Interactive Multimedia Jukebox (IMJ). The IMJ web page is a request and scheduling interface for the playout of content over the MBone. CONTENT IS ENCODED SO THAT IT CAN BE RECEIVED WITH THE LATEST VERSIONS OF VIC AND VAT (ANY PLATFORM). The IMJ page is located at http://imj.gatech.edu. Information about the IMJ including general info, a postscript version of a paper about the IMJ, how-to-use information, and how it was implemented can be found at http://www.cc.gatech.edu/computing/Telecomm/IMJ/. (Recent note: the paper will be appearing in the WWW7 conference in Brisbane, Australia) Some quick additional information about the IMJ is included below: IMJ Audio/Video ----------------- The IMJ uses the WWW to submit requests which are then scheduled for playout on the MBone. Right now we are offering three channels: Channels 1 and 2 are being broadcast at a TTL of 127. Channel 3 is for internal testing and has a a TTL of 15. Each channel provides DVI-2 audio and 128 Kbps H.261 video. The encoding was done using Henning Schulzrinne's rtpplay and rtpdump. Scheduling ---------- Program scheduling uses a set of criteria to decide on which channel to schedule a program. The current set of criteria are listed just below the interactive schedule. We are exploring lots of different options. Content ------- We have been working on the jukebox paradigm with Turner Broadcasting, and as a result of their interest they have agreed to let us broadcast content on the MBone. I am particularly excited about this aspect because of their help and interest in investigating new applications on the Internet. The plan is to add a new set of content about every two weeks. When this happens, the old content will be moved to the secondary request menu for two weeks. The old-old stuff will be removed. Hopefully I'll be able to advertise on the MBone list when the new stuff is available. Development Platform -------------------- As is mentioned in the paper on the IMJ information page we are using the IMJ as a platform for a variety of research issues including providing interactivity, supporting multiple heterogeneous streams, video server organization, tracking usage, program scheduling, and pricing. Acknowledgments ---------------- In addition to Turner Broadcasting, several other groups have made the IMJ possible. The GT Broadband Telecommunications Center sponsored much of the research and some of the equipment, and GT Office of Information Technology offered technical assistance and additional equipment. Please send any feedback or suggestions to almeroth@cs.ucsb.edu or kevin@cc.gatech.edu. -Kevin Almeroth From rem-conf Fri Jan 23 22:43:15 1998 From rem-conf-request@es.net Fri Jan 23 22:43:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xvzG3-00022P-00; Fri, 23 Jan 1998 22:39:59 -0800 Message-Id: <3.0.5.16.19980123223507.2df70976@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Fri, 23 Jan 1998 22:35:07 To: "Kevin C. Almeroth" From: Ross Finlayson Subject: Re: DC IETF MBone content available Cc: IPMULTICAST@STARDUST.COM, rem-conf@es.net In-Reply-To: <199801232322.SAA28563@morticia.cc.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 06:22 PM 1/23/98 -0500, Kevin C. Almeroth wrote: >[...] I hope to continue research >on the IMJ and to make the archival of IETF meetings a regular service. >Part of this work includes encoding the sessions in real-time as they are >being broadcast. This will significantly cut down on the turn around >time between when the content is first broadcast and when it is available >for replay. [...] >Any suggestions for improvement are welcome. Just one: Make it possible to people with 28.8 kbps MBone connections to access these archives. I'm serious. If RealNetworks can do this sort of thing, than so can we. If we want to have IP multicast taken seriously, we have to make it more usable by 'normal people'. Ross Finlayson Live Networks http://www.lvn.com/ From rem-conf Mon Jan 26 08:23:37 1998 From rem-conf-request@es.net Mon Jan 26 08:23:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xwqyw-0004nH-00; Mon, 26 Jan 1998 08:01:54 -0800 X-Lotus-FromDomain: VOCALTEC From: "Scott Petrack" To: rem-conf@es.net Message-ID: <42256598.00554AA1.00@il4.vocaltec.co.il> Date: Mon, 26 Jan 1998 17:57:31 +0200 Subject: Is there a tool for exact recording of received RTP streams? Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is there a tool (public domain or otherwise) which stores a received RTP stream on disk, including the precise time at which each packet was received, in such a way that the receipt of the RTP can be exactly "re-enacted" at a later point in time (inlcuding all the jitter, etc.). I'd like to know what tools are out there. Thanks Scott Petrack VocalTec Communications Ltd. petrack@vocaltec.com From rem-conf Mon Jan 26 09:18:19 1998 From rem-conf-request@es.net Mon Jan 26 09:18:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xws4t-0005s7-00; Mon, 26 Jan 1998 09:12:07 -0800 Sender: hgs@cs.columbia.edu Message-ID: <34CCC3DB.AF7CAFBF@cs.columbia.edu> Date: Mon, 26 Jan 1998 12:11:55 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Scott Petrack CC: rem-conf@es.net Subject: Re: Is there a tool for exact recording of received RTP streams? References: <42256598.00554AA1.00@il4.vocaltec.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scott Petrack wrote: > > Is there a tool (public domain or otherwise) which stores a received RTP > stream on disk, including the precise time at which each packet was > received, in such a way that the receipt of the RTP can be exactly > "re-enacted" at a later point in time (inlcuding all the jitter, etc.). The RTP tools (http://www.cs.columbia.edu/~hgs/rtptools/) do exactly that. > > I'd like to know what tools are out there. > Thanks > Scott Petrack > VocalTec Communications Ltd. > petrack@vocaltec.com -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 (@Bell Labs: 732 949 8344) Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf Mon Jan 26 09:23:59 1998 From rem-conf-request@es.net Mon Jan 26 09:23:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xwsAf-0005wI-00; Mon, 26 Jan 1998 09:18:05 -0800 Message-Id: <199801261717.SAA25840@basil.cdt.luth.se> X-Mailer: exmh version 2.0.1 12/23/97 To: "Scott Petrack" cc: rem-conf@es.net Subject: Re: Is there a tool for exact recording of received RTP streams? In-reply-to: Your message of "Mon, 26 Jan 1998 17:57:31 +0200." <42256598.00554AA1.00@il4.vocaltec.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jan 1998 18:17:52 +0100 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You can use my mMOD system for making an exact copy of the original traffic at a lter point in time. http://www.cdt.luth.se/~peppar/progs/mMOD/ /P From rem-conf Mon Jan 26 09:30:26 1998 From rem-conf-request@es.net Mon Jan 26 09:30:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xwsIP-0006Kz-00; Mon, 26 Jan 1998 09:26:05 -0800 Date: Mon, 26 Jan 1998 18:25:15 +0100 (MET) Message-Id: <199801261725.SAA06670@baby.link.no> To: rem-conf@es.net Subject: Re: Is there a tool for exact recording of received RTP streams? From: Petter Reinholdtsen Reply-to: pere@td.org.uit.no X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Scott Petrack] > Is there a tool (public domain or otherwise) which stores a received > RTP stream on disk, including the precise time at which each packet > was received, in such a way that the receipt of the RTP can be > exactly "re-enacted" at a later point in time (inlcuding all the > jitter, etc.). Might MBone VCR or MBone VCR on Demand be the program you are looking for? Have a look at and . -- ##> Petter Reinholdtsen <## | pere@td.org.uit.no O- http://www.hungry.com/~pere/ | Go Mozilla, go! Go! From rem-conf Mon Jan 26 15:52:09 1998 From rem-conf-request@es.net Mon Jan 26 15:52:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xwyBV-0002JD-00; Mon, 26 Jan 1998 15:43:21 -0800 Date: Mon, 26 Jan 1998 15:41:58 -0800 (Pacific Standard Time) From: Stephen Casner To: rem-conf@es.net Subject: Minutes of AVT meeting in Washington DC Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="11353260-15213-885858118=:-183571" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --11353260-15213-885858118=:-183571 Content-Type: TEXT/PLAIN; charset=US-ASCII Here are the somewhat lengthy minutes of the AVT meeting at the 40th IETF in Washington, DC in December. Any comments or corrections are welcome. -- Steve --11353260-15213-885858118=:-183571 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="avt/minutes.97dec" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Minutes of AVT meeting TWludXRlcyBvZiB0aGUgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IFdvcmtpbmcg R3JvdXANCg0KUmVwb3J0ZWQgYnkgU3RldmUgQ2FzbmVyDQoNCg0KMS4gIElu dHJvZHVjdGlvbiBhbmQgc3RhdHVzDQoNClRoZSBBVlQgd29ya2luZyBncm91 cCBwcm9kdWNlZCB0aGUgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbCwg d2hpY2gNCndhcyBwdWJsaXNoZWQgaW4gSmFudWFyeSAxOTk2IGFzIFByb3Bv c2VkIFN0YW5kYXJkIFJGQzE4ODkgYWxvbmcgd2l0aA0KdGhlIGNvbXBhbmlv biBSVFAgcHJvZmlsZSBmb3IgYXVkaW8vdmlkZW8gY29uZmVyZW5jaW5nIFJG QzE4OTAuICBBVlQNCm1ldCBmb3IgdHdvIGJ1c3kgc2Vzc2lvbnMgYXQgdGhl IDQwdGggSUVURiBtZWV0aW5nIGluIFdhc2hpbmd0b24sIERDDQp0byBkaXNj dXNzIGNvbnRpbnVpbmcgd29yayBvbiBSVFAgYW5kIGF1eGlsaWFyeSBkb2N1 bWVudHMuICBBdCB0aGlzDQptZWV0aW5nLCBhIHByZXNlbnRhdGlvbiB3YXMg Z2l2ZW4gb24gY2hhbmdlcyB0byB0aGUgUlRQIHNwZWNpZmljYXRpb25zDQph cyBkZXRhaWxlZCBpbiBuZXcgSW50ZXJuZXQtRHJhZnRzIHJldmlzaW5nIHRo ZSBzcGVjcyB0b3dhcmRzDQphZHZhbmNlbWVudCB0byBEcmFmdCBTdGFuZGFy ZCBzdGF0dXMuICBUaGVyZSB3YXMgc2lnbmlmaWNhbnQNCmRpc2N1c3Npb24g b2YgYSB0b3BpYyByYWlzZWQgZWFybGllciBvbiB0aGUgbWFpbGluZyBsaXN0 IHRoYXQgaW1wYWN0cw0KdGhlIHByb2ZpbGUgc3BlYzogaG93IHRvIGdldCBw YXlsb2FkIGZvcm1hdHMgZGVmaW5lZCBhbmQgbmFtZWQgZm9yDQpodW5kcmVk cyBvZiBleGlzdGluZyBjb2RlY3MsIHBlcmhhcHMgdXNpbmcgYSBnZW5lcmlj IGZvcm1hdC4NClByZXNlbnRhdGlvbnMgd2VyZSBhbHNvIGdpdmVuIG9uIHRo ZSByZXZpc2lvbnMgdG8gdGhlIFJUUCBNSUIgYW5kIG9uDQpzZXZlcmFsIG5l dyBwYXlsb2FkIGZvcm1hdCBzcGVjaWZpY2F0aW9ucy4gIEl0IGlzIGV4cGVj dGVkIHRoYXQgdGhlDQpSVFAgc3BlY2lmaWNhdGlvbnMgYW5kIGEgbnVtYmVy IG9mIHRoZSBwYXlsb2FkIHNwZWNpZmljYXRpb25zIHdpbGwgYmUNCnJlYWR5 IGZvciBwdWJsaWNhdGlvbiBiZWZvcmUgdGhlIG5leHQgSUVURiBtZWV0aW5n Lg0KDQpTaW5jZSB0aGUgbGFzdCBJRVRGIG1lZXRpbmcsIHR3byBwYXlsb2Fk IGZvcm1hdCBzcGVjaWZpY2F0aW9ucyB3ZXJlDQpwdWJsaXNoZWQgYXMgUHJv cG9zZWQgU3RhbmRhcmRzOiBSRkMyMTkwIGZvciBILjI2MyB2aWRlbywgYW5k IFJGQzIxOTgNCmZvciByZWR1bmRhbnQgYXVkaW8uICBOb3RlIHRoYXQgYSBu ZXdlciBwYXlsb2FkIGZvcm1hdCBmb3IgdGhlIDE5OTgNCnJldmlzaW9uIG9m IEguMjYzIGlzIG5lYXJpbmcgY29tcGxldGlvbiBhcyBkZXNjcmliZWQgYmVs b3cuDQoNCkp1c3QgYWZ0ZXIgdGhlIG1lZXRpbmcsIHRoZSBJRVNHIGFwcHJv dmVkIHB1YmxpY2F0aW9uIG9mIHRoZQ0KSW50ZXJuZXQtRHJhZnQgcmV2aXNp bmcgdGhlIHBheWxvYWQgZm9ybWF0IGZvciBNUEVHLTIgdmlkZW8gaW4NClJG QzIwMzguICBBbHNvIHNpbmNlIHRoZSBtZWV0aW5nLCBhIHJlcXVlc3Qgd2Fz IHNlbnQgdG8gdGhlIElFU0cgdG8NCmlzc3VlIExhc3QgQ2FsbCBvbiBhIHBh Y2thZ2Ugb2YgdGhyZWUgZHJhZnRzIGluY2x1ZGluZyB0aGUgSVAvVURQL1JU UA0KaGVhZGVyIGNvbXByZXNzaW9uIHNwZWNpZmljYXRpb24gZm9sbG93aW5n IHRoZSBQUFBFWFQgd29ya2luZyBncm91cCdzDQphcHByb3ZhbCBhdCB0aGlz IG1lZXRpbmcgb2YgYSBzZXQgb2YgcHJvcG9zZWQgbnVtYmVyIGFzc2lnbm1l bnRzDQpuZWVkZWQgZm9yIHRoZXNlIHNwZWNpZmljYXRpb25zLg0KDQoNCjIu ICBDaGFuZ2VzIHRvIHRoZSBSVFAgU3BlY2lmaWNhdGlvbiBhbmQgQXVkaW8v VmlkZW8gUHJvZmlsZQ0KDQpUaGUgbmV4dCBnb2FsIG9mIHRoZSBBVlQgd29y a2luZyBncm91cCBpcyB0byBhZHZhbmNlIHRoZSBSVFANCnNwZWNpZmljYXRp b24gdG8gRHJhZnQgU3RhbmRhcmQgc3RhdHVzLiAgVG93YXJkIHRoYXQgZW5k LCBTdGV2ZSBDYXNuZXINCnJldmlld2VkIHJldmlzaW9ucyBvZiB0aGUgUlRQ IHNwZWMgYW5kIHByb2ZpbGUgdGhhdCBoYXZlIGJlZW4gcHJlcGFyZWQNCnRv IGluY29ycG9yYXRlIGNsYXJpZmljYXRpb25zIHRvIHRoZSB0ZXh0IGFuZCBj aGFuZ2VzIHRvIGV4cGFuZCB0aGUNCmFwcGxpY2FiaWxpdHkgb2YgUlRQIGJh c2VkIG9uIGV4cGVyaWVuY2UgZHVyaW5nIHRoZSBQcm9wb3NlZCBTdGFuZGFy ZA0Kc3RhZ2UuICBUaGVzZSByZXZpc2lvbnMgaGF2ZSBiZWVuIHBvc3RlZCBh cyBJbnRlcm5ldC1EcmFmdHM6DQoNCglkcmFmdC1pZXRmLWF2dC1ydHAtbmV3 LTAwLnBzLCAudHh0DQoJZHJhZnQtaWV0Zi1hdnQtcHJvZmlsZS1uZXctMDIu cHMsIC50eHQNCg0KUmVhZGVycyBhcmUgZW5jb3VyYWdlZCB0byBzZWUgdGhl IFBvc3RTY3JpcHQgdmVyc2lvbnMgb2YgdGhlc2UgZHJhZnRzDQpiZWNhdXNl IHRoZXkgbWFyayB0aGUgY2hhbmdlcyB3aXRoIGNoYW5nZSBiYXJzLg0KDQpB IHF1ZXN0aW9uIHJhaXNlZCBhdCB0aGlzIG1lZXRpbmcgc3VnZ2VzdHMgdGhl cmUgbWF5IGJlIHNvbWUgY29uZnVzaW9uDQphYm91dCB0aGUgc3RhbmRhcmRp emF0aW9uIHByb2Nlc3MuICBBbiBJRVRGIHN0YW5kYXJkcy10cmFjayBSRkMg bWF5IGJlDQphZHZhbmNlZCB0byB0aGUgbmV4dCBsZXZlbCB3aXRob3V0IHJl cHVibGljYXRpb24gaWYgbm8gY2hhbmdlcyBhcmUNCnJlcXVpcmVkLiAgSG93 ZXZlciwgd2hlbiBjaGFuZ2VzIGFyZSBuZWVkZWQsIHRoZSBtZWNoYW5pc20g aXMgdG8gcG9zdA0KYW4gSW50ZXJuZXQtRHJhZnQgY29udGFpbmluZyB0aGUg cmV2aXNpb25zLiAgVGhhdCBkcmFmdCB3aWxsIHRoZW4gYmUNCnB1Ymxpc2hl ZCBhcyBhIG5ldyBSRkMgd2l0aCBhIG5ldyBudW1iZXIuICBQYXJ0IG9mIHRo ZSBJRVNHIGFwcHJvdmFsDQpwcm9jZXNzIGlzIHRvIGp1ZGdlIHdoZXRoZXIg dGhlIGNoYW5nZXMgYXJlIGFjY2VwdGFibGUgd2hpbGUgYWR2YW5jaW5nDQp0 byB0aGUgbmV4dCBsZXZlbCBvciByZXF1aXJlIGFub3RoZXIgcGFzcyBhdCB0 aGUgc2FtZSBsZXZlbC4NCg0KVGhlIGNoYW5nZXMgdG8gdGhlIFJUUCBzcGVj IHdlcmUgYnJpZWZseSByZXZpZXdlZCBpbiB0aGlzIG1lZXRpbmcgYW5kDQph cmUgbGlzdGVkIGluIHRoZSBpbnRyb2R1Y3Rpb24gc2VjdGlvbiBvZiB0aGUg ZHJhZnQuICBBbHRob3VnaCB0aGUNCmNoYW5nZXMgYXJlIHNldmVyYWwsIHRo ZXkgZG8gbm90IGFmZmVjdCB0aGUgcHJvdG9jb2wgZm9ybWF0IG5vcg0KaW50 cm9kdWNlIGFueSBpbmNvbXBhdGliaWxpdGllcywgc28gYXBwcm92YWwgb2Yg dGhlc2UgY2hhbmdlcyBmb3INCmFkdmFuY2VtZW50IHRvIERyYWZ0IFN0YW5k YXJkIGlzIGV4cGVjdGVkLiAgVGhlIGNoYW5nZXMgYXJlIHByaW1hcmlseQ0K bmV3IHJ1bGVzIGFuZCBlbmhhbmNlbWVudHMgdG8gdGhlIGFsZ29yaXRobXMg Z292ZXJuaW5nIGhvdyBSVFAgaXMNCnVzZWQuICBJbiBwYXJ0aWN1bGFyLCBz ZXZlcmFsIGVuaGFuY2VtZW50cyB3ZXJlIGFkZGVkIGluIHRoZQ0KbWFuYWdl bWVudCBvZiBSVENQIGJhbmR3aWR0aCB0byBhdm9pZCBzY2FsaW5nIHByb2Js ZW1zIGluIHZlcnkgbGFyZ2UNCmdyb3VwcyB3aXRoIG1hbnkgc2ltdWx0YW5l b3VzIGpvaW5zIGFuZCBsZWF2ZXMuICBBbHNvIGFkZGVkIHdhcyBhDQpzYW1w bGluZyBtZXRob2QgdG8gcmVkdWNlIFNTUkMgc3RvcmFnZSByZXF1aXJlbWVu dHMgd2hlbiB0aGUgbnVtYmVyIG9mDQpwYXJ0aWNpcGFudHMgaXMgdmVyeSBs YXJnZS4gIFRoZXNlIGVuaGFuY2VtZW50cyBoYXZlIGJlZW4gZGlzY3Vzc2Vk IGluDQpkZXRhaWwgaW4gdGhlIHBhc3QgdGhyZWUgQVZUIG1lZXRpbmdzLg0K DQpBdCB0aGlzIG1lZXRpbmcsIEpvbmF0aGFuIFJvc2VuYmVyZyBkZXNjcmli ZWQgdGhlIGxhdGVzdCBvZiB0aGVzZQ0KZW5oYW5jZW1lbnRzOiBhICJCWUUg cmVjb25zaWRlcmF0aW9uIiBhbGdvcml0aG0gdG8gYXZvaWQgYSBmbG9vZCBv Zg0KUlRDUCBCWUUgcGFja2V0cyB3aGVuIG1hbnkgcGFydGljaXBhbnRzIGxl YXZlIGEgc2Vzc2lvbiBhdCB0aGUgc2FtZQ0KdGltZS4gIFRoaXMgYWxnb3Jp dGhtIGlzIGluY2x1ZGVkIGluIHRoZSByZXZpc2VkIFJUUCBzcGVjLiAgSW4N CmFkZGl0aW9uLCBhIG1vcmUgZGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhl IGFsZ29yaXRobSBpbmNsdWRpbmcNCnNpbXVsYXRpb24gcmVzdWx0cyBpcyBn aXZlbiBpbiBkcmFmdC1pZXRmLWF2dC1ieWVyZWNvbi0wMC5wcyBhbmQgLnR4 dC4NCg0KVGhpcyBhbGdvcml0aG0gY29tcGxldGVzIHRoZSBwbGFubmVkIHNl dCBvZiBzY2FsaW5nIGVuaGFuY2VtZW50cywNCmV4Y2VwdCBmb3Igc29tZSBz bWFsbCByZWZpbmVtZW50cyBiZWluZyBjb25zaWRlcmVkIGZvciB0aHJlZSBv ZiB0aGUNCmFsZ29yaXRobXMuICBUaGUgYWxnb3JpdGhtcyBoYXZlIGJlZW4g dmFsaWRhdGVkIHRocm91Z2ggc2ltdWxhdGlvbiwNCmJ1dCBpdCBpcyBpbXBv cnRhbnQgdG8gbWFrZSBzdXJlIHRoZXkgd29yayB3ZWxsIGluIHJlYWwNCmlt cGxlbWVudGF0aW9ucyBvbiBhIGxhcmdlIHNjYWxlLiAgQW55b25lIHdobyBj YW4gcGVyZm9ybSBzdWNoIGEgdGVzdA0KaXMgaGlnaGx5IGVuY291cmFnZWQg dG8gZG8gc28gYW5kIHRvIHJlcG9ydCB0aGUgcmVzdWx0cy4NCg0KSW4gYWRk aXRpb24gdG8gdGhlIGNoYW5nZXMgYWxyZWFkeSBpbmNsdWRlZCBpbiB0aGUg UlRQIHNwZWMsIHRoZXJlIGFyZQ0KdHdvIGNoYW5nZXMgdGVudGF0aXZlbHkg YWNjZXB0ZWQgaW4gcHJldmlvdXMgbWVldGluZ3MgYnV0IG5vdCB5ZXQNCmVu dGVyZWQgaW4gdGhlIHNwZWM6IGFsbG93aW5nIHRoZSBSVENQIHNlbmRlciBh bmQgcmVjZWl2ZXIgYmFuZHdpZHRocw0KdG8gYmUgc3BlY2lmaWVkIGV4cGxp Y2l0bHkgcmF0aGVyIHRoYW4gYmVpbmcgZml4ZWQgYXQgNSUsIGFuZCBzY2Fs aW5nDQp0aGUgbWluaW11bSBpbnRlcnZhbCBmb3IgUlRDUCBtZXNzYWdlcyBp bnZlcnNlbHkgcHJvcG9ydGlvbmFsIHRvDQpiYW5kd2lkdGguICBUaGVzZSBj aGFuZ2VzIHdpbGwgYmUgYWRkZWQgaW4gdGhlIG5leHQgZHJhZnQuICBMYXN0 bHksDQp0aGVyZSBhcmUgc2V2ZXJhbCBvdGhlciBwcm9wb3NlZCBzbWFsbCBj aGFuZ2VzIGxpc3RlZCBpbiB0aGUgZHJhZnQNCnRoYXQgcmVjZWl2ZWQgc29t ZSBkaXNjdXNzaW9uIGluIHRoaXMgbWVldGluZyBhbmQgd2lsbCBiZSBkaXNj dXNzZWQNCmZ1cnRoZXIgb24gdGhlIG1haWxpbmcgbGlzdCB0byBkZWNpZGUg aWYgdGhleSBzaG91bGQgYmUgbWFkZS4NCg0KVGhlIHByaW1hcnkgY2hhbmdl IGZvciB0aGUgUlRQIGF1ZGlvL3ZpZGVvIHByb2ZpbGUgZHJhZnQgaXMgYSBt b3JlDQpjb21wbGV0ZSBsaXN0IG9mIGVuY29kaW5ncyAocHJpbWFyaWx5IGF1 ZGlvKSBhbmQgYmV0dGVyIGRlc2NyaXB0aW9ucw0KZm9yIGJvdGggb2xkIGFu ZCBuZXcgb25lcy4gIE9mIGNvdXJzZSwgdGhlIHByb2ZpbGUgY2FuJ3QgaW5j bHVkZSBhbGwNCmVuY29kaW5ncy4gIFRoZXJlZm9yZSwgdGhlIG1haW4gb3Bl biBpc3N1ZSBmb3IgdGhlIHByb2ZpbGUgaXMgdG8NCmJldHRlciBkZWZpbmUg bmFtZXNwYWNlIGZvciBlbmNvZGluZ3MsIHRoZSBwcm9jZWR1cmVzIGZvciBy ZWdpc3RlcmluZw0KYWRkaXRpb25hbCBuYW1lcywgYW5kIGhvdyBkeW5hbWlj IHBheWxvYWQgdHlwZSBtYXBwaW5ncyBzaG91bGQgYmUNCmV4cHJlc3NlZCB1 c2luZyB0aG9zZSBuYW1lcy4gIFRoYXQgaXMgdGhlIHRvcGljIG9mIHRoZSBu ZXh0IHNlY3Rpb24uDQoNClNsaWRlczoJZnRwOi8vaHlkcmEucHJlY2VwdC5j b20vcHViL3J0cC9pZXRmNDAtYXZ0LnBwdA0KCWh0dHA6Ly93d3cuY3MuY29s dW1iaWEuZWR1L35qZHJvc2VuL2lldGZfYnllcmVjb245NS5wcHQNCglodHRw Oi8vd3d3LmNzLmNvbHVtYmlhLmVkdS9+amRyb3Nlbi9pZXRmX2J5ZXJlY29u LnBzDQoJaHR0cDovL3d3dy5jcy5jb2x1bWJpYS5lZHUvfmpkcm9zZW4vaWV0 Zl9ieWVyZWNvbi5wZGYNCg0KDQozLiBHZW5lcmljIHBheWxvYWQgdHlwZSBt YXBwaW5nIGFuZCBmcmFnbWVudGF0aW9uDQoNCkJlZm9yZSB0aGlzIG1lZXRp bmcsIGEgZGlzY3Vzc2lvbiBiZWdhbiBvbiB0aGUgbWFpbGluZyBsaXN0IHJl Z2FyZGluZw0KaG93IHRvIGVuYWJsZSBSVFAgdHJhbnNwb3J0IG9mIHRoZSBo dW5kcmVkcyBvZiBleGlzdGluZyBjb2RlY3MgZm9yDQp3aGljaCBubyBwYXls b2FkIGZvcm1hdHMgaGF2ZSBiZWVuIGRlZmluZWQuICBTdGV2ZSBDYXNuZXIg ZGVzY3JpYmVkDQp0aGUgcGVyY2VpdmVkIHByb2JsZW1zIGFzOg0KDQogIC0g dGhlIGVuY29kaW5nIG5hbWVzcGFjZSBhbmQgcmVnaXN0cmF0aW9uIHByb2Nl ZHVyZXMgYXJlIG5vdA0KICAgIHdlbGwgZGVmaW5lZDsNCiAgLSBub3QgZW5v dWdoIHBlb3BsZSBrbm93IGhvdyB0byBkZXNpZ24gYW5kIHdyaXRlIHBheWxv YWQgZm9ybWF0czsNCiAgLSB0aGUgcHJvY2VzcyBvZiB3cml0aW5nIGFuIFJG QyBmb3IgZWFjaCBlbmNvZGluZyBhbmQgZ2V0dGluZyBpdA0KICAgIGFwcHJv dmVkIHdvdWxkIHRha2UgdG9vIGxvbmc7DQogIC0gRXJpYyBGbGVpc2NobWFu IGFkZGVkIHRoYXQgbWFueSBvZiB0aGUgY29kZWNzIGFyZSBwcm9wcmlldGFy eSBzbw0KICAgIHRoZSBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBkZWZpbmUg YSBwYXlsb2FkIGZvcm1hdCBpcyBub3QNCiAgICBhdmFpbGFibGUuIA0KDQpP bmUgYW5zd2VyIGlzIHRvIGRlZmluZSBhIGdlbmVyaWMgcGF5bG9hZCBmb3Jt YXQgdGhhdCBpbnRyb2R1Y2VzDQphbm90aGVyIGxldmVsIG9mIGluZGlyZWN0 aW9uIGZvciB0aGUgbmFtZXNwYWNlIChwZXJoYXBzIHVzaW5nIGFub3RoZXIN CmV4aXN0aW5nIG5hbWVzcGFjZSkgcmF0aGVyIHRoYW4gdXNpbmcgdGhlIFJU UCBwYXlsb2FkIHR5cGUgZmllbGQuICBUaGUNCmRhdGEgd291bGQgYmUgcGFj a2V0aXplZCB3aXRob3V0IG9wdGltaXphdGlvbiBmb3IgYSBwYXJ0aWN1bGFy DQplbmNvZGluZywgaW4gc29tZSBjYXNlcyB0cmVhdGluZyB0aGUgZGF0YSBh cyBvcGFxdWUuICBUd28gZHJhZnRzDQpwcm9wb3Npbmcgc3VjaCBzY2hlbWVz IGhhdmUgYmVlbiBzdWJtaXR0ZWQsIHRoZSBmaXJzdCBpbiBKdW5lIGZvcg0K UXVpY2tUaW1lIG1lZGlhIHN0cmVhbXMgKGRyYWZ0LWlldGYtYXZ0LXF0LXJ0 cC0wMC50eHQpLCBhbmQgbW9yZQ0KcmVjZW50bHkgYSBzZWNvbmQgZm9yIEFT RiBzdHJlYW1zIChkcmFmdC1rbGVtZXRzLWFzZi1ydHAtMDAudHh0KS4NClNp bmNlIGluIG1hbnkgY2FzZXMgdGhlIHNhbWUgZW5jb2RpbmcgbWlnaHQgYmUg Y2FycmllZCBpbiBlaXRoZXINCnNjaGVtZSBidXQgdGhlIHR3byBzY2hlbWVz IHdvdWxkIG5vdCBpbnRlcm9wZXJhdGUsIG11bHRpcGxlIHBlb3BsZQ0Kbm90 ZWQgb24gdGhlIG1haWxpbmcgbGlzdCB0aGF0IGlmIGEgZ2VuZXJpYyBzY2hl bWUgd2VyZSB0byBiZSBkZWZpbmVkLA0KdGhlcmUgc2hvdWxkIGJlIG9ubHkg b25lLg0KDQpBdCB0aGlzIG1lZXRpbmcsIHR3byBwcmVzZW50YXRpb25zIHdl cmUgbWFkZSB0byBzZXQgdGhlIHN0YWdlIGZvcg0KZGlzY3Vzc2lvbiBvZiB3 aGV0aGVyIGEgZ2VuZXJpYyBwYXlsb2FkIGZvcm1hdCBpcyBuZWVkZWQsIGFu ZCBpZiBzbywNCndoYXQgaXQgc2hvdWxkIGJlLiAgVGhlIGZpcnN0IHdhcyBi eSBBbmRlcnMgS2xlbWV0cyB3aG8gZGVzY3JpYmVkIGENCm1pbmltYWxpc3Qg Z2VuZXJpYyBwYXlsb2FkIGZvcm1hdCBhbmQgdGhlbiBjb21wYXJlZCBpdCB0 byB0aGUgQVNGDQpwYXlsb2FkIGZvcm1hdC4gIEhlIGRlZmluZWQgdGhlIHBy b2JsZW0gYXMgb25lIG9mIGV4dGVuc2liaWxpdHkgZm9yDQpsYXJnZSB2aWRl by1vbi1kZW1hbmQgc2VydmVycy4gIEZpbGVzIGNvbnRhaW5pbmcgbmV3IGVu Y29kaW5ncyBtaWdodA0KYmUgYWRkZWQsIGJ1dCBpdCB3b3VsZCBub3QgYmUg cHJhY3RpY2FsIHRvIHVwZ3JhZGUgdGhlIHNlcnZlciB0byBhZGQgYQ0KbmV3 IHBhY2tldGl6YXRpb24gZnVuY3Rpb24gZm9yIGVhY2guICBHZW5lcmljIHBh eWxvYWQgZm9ybWF0cyBhcmUNCmFscmVhZHkgYmVlbiB1c2VkIGluIHNvbWUg Y29tbWVyY2lhbCBwcm9kdWN0cyBhcyBhIHNvbHV0aW9uIHRvIHRoaXMNCnBy b2JsZW0uICBTaG91bGQgYSBnZW5lcmljIHBheWxvYWQgZm9ybWF0IGJlIHN0 YW5kYXJkaXplZCBieSBBVlQsIG9yDQpzaG91bGQgbWFya2V0IGZvcmNlcyBk ZWNpZGU/DQoNCktsZW1ldHMgZGVzY3JpYmVkIGEgc2ltcGxlIGdlbmVyaWMg cGF5bG9hZCBmb3JtYXQgaW4gd2hpY2ggdGhlDQpzcGVjaWZpY2F0aW9uIG9m IHdoYXQgZW5jb2RpbmcgaXMgYWN0dWFsbHkgY2FycmllZCBpcyBzcGVjaWZp ZWQNCm91dC1vZi1iYW5kLCBlLmcuLCB1c2luZyBkeW5hbWljIHBheWxvYWQg dHlwZSBtYXBwaW5nIGluIFNEUC4gIFRoZQ0KcGF5bG9hZCBmb3JtYXQgaXRz ZWxmIHdvdWxkIGluY2x1ZGUgYSBtaW5pbWFsIHBheWxvYWQgaGVhZGVyIHRv DQpwcmVzZXJ2ZSBmcmFtZSBib3VuZGFyaWVzOyBpdCB3b3VsZCBpbXBsZW1l bnQgZnJhZ21lbnRhdGlvbiBvZiBsYXJnZQ0KZnJhbWVzIGludG8gbXVsdGlw bGUgcGFja2V0cywgYW5kIGdyb3VwaW5nIG9mIG11bHRpcGxlIHNtYWxsIGZy YW1lcw0KaW50byBvbmUgcGFja2V0LiAgSGUgZGVzY3JpYmVkIHRoZSBvYmpl Y3RpdmVzIGZvciB0aGUgQVNGIHBheWxvYWQNCmZvcm1hdCBhcyBsYXJnZWx5 IHRoZSBzYW1lLCBidXQgb3B0aW1pemVkIGZvciBjb250ZW50IHN0b3JlZCBp biBBU0YNCmZpbGVzLiAgSW4gYWRkaXRpb24gdG8gZnJhZ21lbnRhdGlvbiBh bmQgZ3JvdXBpbmcsIHRoZSBBU0YgcGF5bG9hZA0KZm9ybWF0IGluY2x1ZGVz IGEgZnJhbWUgc2VxdWVuY2UgbnVtYmVyLCBhIGtleS1mcmFtZSBmbGFnLCBh bmQgYQ0Kc2VuZC10aW1lc3RhbXAuICBJZiBBVlQgZG9lcyBkZWZpbmUgYSBn ZW5lcmljIHBheWxvYWQgZm9ybWF0LCBzaG91bGQNCnNvbWUgb3IgYWxsIG9m IHRoZSBBU0YgcGF5bG9hZCBmb3JtYXQgZmVhdHVyZXMgYmUgZm9sZGVkIGlu dG8gaXQ/DQoNCkluIHRoZSBzZWNvbmQgcHJlc2VudGF0aW9uLCBIZW5uaW5n IFNjaHVsenJpbm5lIGFpbWVkIHRvIGRpc2VudGFuZ2xlDQp0aGUgbXVsdGlw bGUsIGRpc3RpbmN0IGlzc3VlcyB0aGF0IGhhdmUgc29tZXRpbWVzIGJlZW4g Y29uZnVzZWQgaW4gdGhlDQpkaXNjdXNzaW9uOyBzb21lIGFyZSBlYXN5IHRv IHNvbHZlLCBhbmQgb3RoZXJzIG5lZWQgbmV3IHdvcms6DQoNCiAgLSBNYXBw aW5nIGJldHdlZW4gUlRQIHBheWxvYWQgdHlwZSBudW1iZXJzIGFuZCB2YXJp YWJsZS1sZW5ndGgNCiAgICBlbmNvZGluZyBuYW1lcy4gIFJlZ2lzdHJhdGlv biBvZiBuYW1lcyBkb2Vzbid0IHJlcXVpcmUgYW4gUkZDLA0KICAgIGp1c3Qg YW4gSUFOQSBwcm9jZWR1cmUgKHRoYXQgdGhlIHByb2ZpbGUgbmVlZHMgdG8g c3BlY2lmeSBtb3JlDQogICAgY29tcGxldGVseSkuICBJdCB3b3VsZCBiZSBw b3NzaWJsZSB0byBhbGxvdyBtdWx0aXBsZSBleGlzdGluZw0KICAgIG5hbWVz cGFjZXMgdG8gYmUgaW1wb3J0ZWQgaW50byB0aGUgU0RQICJydHBtYXAiIGF0 dHJpYnV0ZSwgYnV0DQogICAgdGhlbiBpdCB3b3VsZCBiZSBkaWZmaWN1bHQg dG8gYXZvaWQgbXVsdGlwbGUgbmFtZXMgZm9yIHRoZSBzYW1lDQogICAgZW5j b2RpbmcuDQoNCiAgLSBGcmFnbWVudGF0aW9uIG9mIGxvbmcgc3RvcmFnZSB1 bml0cyBpbnRvIE1UVS1zaXplZCBSVFAgcGFja2V0cy4NCiAgICBSVFAgYWxy ZWFkeSBkZWxpbmVhdGVzIHVuaXRzIHVzaW5nIHRoZSBzYW1lIHRpbWVzdGFt cCBhbmQNCiAgICBpbmNyZWFzaW5nIHNlcXVlbmNlIG51bWJlcnMgZm9yIHRo ZSBwYWNrZXRzIG9mIG9uZSB1bml0LCBhbmQgdGhlDQogICAgbWFya2VyIGJp dCB0byBpZGVudGlmeSB0aGUgYmVnaW5uaW5nIG9yIGVuZC4gIEZyYWdtZW50 YXRpb24gbWF5IGJlDQogICAgYmFzZWQgb24gYW4gb3BlbiBzcGVjaWZpY2F0 aW9uIG9mIHNlbWFudGljIGJvdW5kYXJpZXMgYXMgaW4NCiAgICBleGlzdGlu ZyBBVlQgcGF5bG9hZCBmb3JtYXRzOyBoaWRkZW4gd2l0aCBhIGxpYnJhcnkg Y2FsbDsgb3IgKGFzIGENCiAgICBsYXN0IHJlc29ydCkgYmxpbmQgY2hvcHBp bmcgaWYgbm8gaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlLg0KDQogIC0gQWdn cmVnYXRpb24gYW5kIG11bHRpcGxleGluZywgd2hpY2ggbWF5IGFscmVhZHkg YmUgc29sdmVkIGJ5DQogICAgUkZDMjE5OCBpbiB0aGUgY2FzZSBvZiBhdWRp byB3aGVyZSBpdCBpcyBtb3N0IG5lZWRlZCwgYW5kIGluDQogICAgcHJvcG9z YWxzIHRoYXQgSm9uYXRoYW4gUm9zZW5iZXJnIG1hZGUgaW4gU2FuIEpvc2Ug aW4gMTk5Ni4NCg0KICAtIElmIFJUUCtTRFAgaXMgdG8gYmUgY29uc2lkZXJl ZCBhICJtdWx0aW1lZGlhIGZpbGUgdHJhbnNwb3J0IiwgdGhlbg0KICAgIG1l dGEgaW5mb3JtYXRpb24gKGF1dGhvciwgY29weXJpZ2h0KSBjb3VsZCBiZSBz ZW50IGluIFNEUCwgYW5kDQogICAgc3RyZWFtLXJlbGF0ZWQgZGV0YWlscyB3 b3VsZCBuZWVkIHRvIGJlIGNvbnRhaW5lZCBpbiBleHRyYSBoZWFkZXINCiAg ICBmaWVsZHMgKFJUUCBoZWFkZXIgZXh0ZW5zaW9uIG9yIHBheWxvYWQgcHJl Zml4KS4gIEJ1dCBmaWxlDQogICAgdHJhbnNwb3J0IG1pZ2h0IGp1c3QgYmUg cmVsZWdhdGVkIHRvIEZUUC4NCg0KVGhlcmUgd2FzIHN1YnN0YW50aWFsIGdy b3VwIGRpc2N1c3Npb24gb2YgdGhlc2UgaXNzdWVzLiAgU2V2ZXJhbA0KcGVv cGxlIGlkZW50aWZpZWQgdGhlIG5hbWUgc3BhY2UgaXNzdWUgYXMgdGhlIG1v c3QgaW1wb3J0YW50LiAgVGhlcmUNCndhcyBhdCBsZWFzdCByb3VnaCBjb25z ZW5zdXMgdGhhdCB0aGUgcmlnaHQgd2F5IHRvIGhhbmRsZSB0aGUgbXVsdGlw bGUNCmV4aXN0aW5nIG5hbWVzcGFjZXMgd2FzIHRvIG1hcCB0aGVtIGludG8g dGhlIGF1ZGlvIGFuZCB2aWRlbyB0eXBlcyBvZg0KdGhlIE1JTUUgbmFtZXNw YWNlIHJlZ2lzdGVyZWQgd2l0aCBJQU5BLiAgVGhpcyBpbmNsdWRlcyB0aGUg ZW5jb2RpbmcNCm5hbWVzIGluIHRoZSBSVFAgcHJvZmlsZSBSRkMxODkwLCB0 aGUgTWljcm9zb2Z0IFdBViBhbmQgQVZJDQpyZWdpc3RyaWVzLCBhbmQgQXBw bGUgUXVpY2tUaW1lLiAgSGFyYWxkIEFsdmVzdHJhbmQgZW1waGFzaXplZCB0 aGF0DQpldmVuIHRob3VnaCBzb21lIG9mIHRoZSByZWdpc3RyYXRpb25zIGlu IHRoZSBleGlzdGluZyBuYW1lc3BhY2VzIG1heQ0KYmUgb2Jzb2xldGUsIHRo ZXkgc2hvdWxkIGFsbCBiZSBtYXBwZWQgaW50byB0aGUgTUlNRSBuYW1lc3Bh Y2Ugd2hlcmUNCnRoZXkgY291bGQgYmUgbWFya2VkIGFzIG9ic29sZXRlIGlm IGFwcHJvcHJpYXRlLiAgRGF2aWQgU2luZ2VyIHBvaW50ZWQNCm91dCB0aGF0 IG1hcHBpbmcgaW4gdGhlIG5hbWVzIHdvdWxkIGJlIHN0cmFpZ2h0Zm9yd2Fy ZCwgYnV0IHRoZSByZWFsDQp3b3JrIGlzIGluIGRldGVybWluaW5nIHdoaWNo IG5hbWVzIGZyb20gc2VwYXJhdGUgc3BhY2VzIGlkZW50aWZ5IHRoZQ0Kc2Ft ZSBlbmNvZGluZyBhbmQgc2hvdWxkIHRoZXJlZm9yZSBtYXAgdG8gdGhlIHNh bWUgTUlNRSB0eXBlLg0KT3RoZXJ3aXNlLCBub3RoaW5nIGlzIGdhaW5lZCBp biB0aGUgcmUtcmVnaXN0cmF0aW9uLg0KDQpUaGUgc2Vjb25kIHBhcnQgb2Yg dGhlIG1hcHBpbmcgcHJvYmxlbSBpcyB0byBzcGVjaWZ5IGhvdyB0aGUgTUlN RQ0KdHlwZXMgd291bGQgYmUgYXNzb2NpYXRlZCB3aXRoIGR5bmFtaWMgUlRQ IHBheWxvYWQgdHlwZSBudW1iZXJzLCBmb3INCmV4YW1wbGUgaW4gdGhlIFNE UCAicnRwbWFwIiBhdHRyaWJ1dGUuICBQcmV2aW91c2x5LCB0aGUgcGF5bG9h ZCB0eXBlDQp3YXMgbWFwcGVkIHRvIGFuIGVuY29kaW5nIG5hbWUgdGhhdCBp bXBsaWVkIGEgcGFydGljdWxhciBwYWNrZXRpemF0aW9uDQpmb3JtYXQgYXMg d2VsbC4gIElmIHRoYXQgaXMgbm90IHRoZSBjYXNlIGZvciB0aGUgdHJhbnNm ZXJyZWQNCnJlZ2lzdHJhdGlvbnMsIHRoaXMgbWFwcGluZyBtYXkgbmVlZCB0 byBiZSBleHRlbmRlZCB0byBpZGVudGlmeQ0Kc2VwYXJhdGVseSB0aGUgZW5j b2RpbmcgYW5kIHBhY2tldGl6YXRpb24gZm9ybWF0LiAgRXJpYyBGbGVpc2No bWFuDQphbHNvIGV4cHJlc3NlZCBjb25jZXJuIHRoYXQgbWFueSBvZiB0aGUg ZW5jb2RpbmdzIG1heSBoYXZlIHZhcmlvdXMNCnBhcmFtZXRlcnMgdGhhdCBu ZWVkIHRvIGJlIHNwZWNpZmllZCBpbiB0aGUgcGF5bG9hZCB0eXBlIG1hcHBp bmcsDQp3aGVyZWFzIGN1cnJlbnRseSBvbmx5IHNhbXBsZSByYXRlIGFuZCBu dW1iZXIgb2YgY2hhbm5lbHMgYXJlIGRlZmluZWQNCmluIFJGQzE4OTAgYW5k IHJ0cG1hcC4gIFNEUCBkb2VzIGhhdmUgYW5vdGhlciBhdHRyaWJ1dGUgImZt dHAiIHdoaWNoDQptYXkgYmUgYXBwcm9wcmlhdGUgZm9yIGNhcnJ5aW5nIHRo ZXNlIHBhcmFtZXRlcnMuICBTaW5nZXIgbm90ZWQgdGhhdA0Kc29tZXRpbWVz IHRoZSBjb2RlYyBwYXJhbWV0ZXJzIG9yIG90aGVyIG1ldGEgaW5mb3JtYXRp b24gbWlnaHQgYmUgdG9vDQpsYXJnZSB0byBmaXQgY29tZm9ydGFibHkgaW4g U0RQIGFuZCBtaWdodCBub3QgYmUgaHVtYW4gcmVhZGFibGUgYXMgaXMNCnRo ZSBub3JtIGZvciBTRFAuICBDYXNuZXIgb2JzZXJ2ZWQgdGhhdCB0aGUgbGVu Z3RoIGNvbnN0cmFpbnQgaXMNCnByaW1hcmlseSBhIGNvbmNlcm4gd2hlbiBT RFAgaXMgZGVsaXZlcmVkIHZpYSBTQVAsIGJ1dCBpcyBsZXNzIGENCnByb2Js ZW0gd2l0aCBSVFNQLiAgSWYgc29tZSBvZiB0aGUgbWV0YSBpbmZvIGlzIGNv bnN0YW50IGFuZCByZXVzYWJsZSwNCml0IG1pZ2h0IGJlIGRlZmluZWQgZWxz ZXdoZXJlIGFuZCByZWZlcmVuY2VkIGJ5IGEgc2hvcnQgbmFtZSBpbiBTRFAu DQoNCkdpdmVuIHRoZSBkeW5hbWljIHBheWxvYWQgdHlwZSBtYXBwaW5nLCB0 aGVyZSBpcyBubyBuZWVkIGZvciBhDQpwYWNrZXRpemF0aW9uIGZvcm1hdCB0 byBjYXJyeSBzdWJ0eXBlIGluZm9ybWF0aW9uLiAgSG93ZXZlciwgU2luZ2Vy DQpwb2ludGVkIG91dCB0aGF0IGEgZ2VuZXJpYyBwYWNrZXRpemF0aW9uIGlz IHN0aWxsIG5lZWRlZCB0byBkbyBibGluZA0KZnJhZ21lbnRhdGlvbiBmb3Ig aGlzdG9yaWMgY29udGVudCB3aGVuIG5vIGluZm9ybWF0aW9uIGlzIGF2YWls YWJsZSBvbg0KaG93IHRvIHBhY2tldGl6ZS4gIFRoYXQncyBub3QgaWRlYWws IGJ1dCBiZXR0ZXIgdGhhbiBhIGJsYW5rIHNjcmVlbi4NCkRvbiBIb2ZmbWFu IGFzc2VydGVkIHRoYXQgaWYgYSBnZW5lcmljIGZvcm1hdCBpcyB0byBiZSBk ZWZpbmVkLCB0aGVyZQ0Kc2hvdWxkIGJlIG9ubHkgb25lIGFuZCBub3QgbWFu eS4gIFdlIGhhdmUgdGhlIFF1aWNrVGltZSBhbmQgQVNGDQpwcm9wb3NhbHMg bm93LCBhbmQgTVBFRzQgbWF5IHJ1biBpbnRvIHRoZSBzYW1lIHByb2JsZW0u ICBCb2IgV2ViYmVyDQpleHByZXNzZWQgY29uY2VybiBhYm91dCB0aGUgaW5j cmVhc2VkIG92ZXJoZWFkIG9mIGEgZ2VuZXJpYyBwYXlsb2FkDQpmb3JtYXQu ICBDYXNuZXIgc3VnZ2VzdGVkIGEgc21hbGwgZmFtaWx5IG9mIGdlbmVyaWMg Zm9ybWF0cyB0aGF0DQppbXBsZW1lbnQganVzdCB0aGUgZmVhdHVyZXMgdGhh dCBhbiBlbmNvZGluZyBuZWVkcywgcmF0aGVyIHRoYW4gdXNlIGENCmJpdG1h c2sgdG8gaW5kaWNhdGUgd2hpY2ggZmVhdHVyZXMgYXJlIHByZXNlbnQgaW4g ZWFjaCBwYWNrZXQuDQpSZWdhcmRpbmcgdGhlICJzZW5kIiB0aW1lc3RhbXAg aW4gdGhlIEFTRiBwcm9wb3NhbCwgU2luZ2VyIGFzc2VydGVkDQp0aGF0IGlm IGl0IGlzIHVzZWZ1bCwgaXQgYmVsb25ncyBhdCBSVFAgbGV2ZWwgcmF0aGVy IHRoYW4gYXQgdGhlDQpwYWNrZXRpemF0aW9uIGxldmVsLiAgVGhpcyBmdW5j dGlvbiB3YXMgY29uc2lkZXJlZCBhbmQgb21pdHRlZCB3aGVuDQpSVFAgd2Fz IGRlc2lnbmVkOyB3ZSBzaG91bGQgZWl0aGVyIGRlY2lkZSB0aGF0IHdhcyBh IG1pc3Rha2UgYW5kDQpjaGFuZ2UgUlRQLCBvciBsZWF2ZSBpdCBvdXQuICBX ZSBzaG91bGQgbm90IHB1dCBpdCBpbiBmb3Igc29tZSBmb3JtYXRzDQphbmQg bm90IG90aGVycy4NCg0KVGhlIGlzc3VlcyBmb3IgZ2VuZXJpYyBwYWNrZXRp emF0aW9uIGFyZSBsZXNzIGNsZWFyIHRoYW4gZm9yIG5hbWUNCm1hcHBpbmcu ICBNYXJrIEhhbmRsZXkgZXhwbGFpbmVkIHRoYXQgZm9yIG1hbnkgZW5jb2Rp bmdzLCB0aGVyZSBpcyBhDQpiaWcgZ2FpbiBpbiByb2J1c3RuZXNzIHRvIGxv c3MgaWYgb25lIGRlc2lnbnMgYSBwYXlsb2FkIGZvcm1hdA0Kb3B0aW1pemVk IGZvciBlYWNoIGVuY29kaW5nIHRvIGluY2x1ZGUgYSBzbWFsbCBhbW91bnQg b2YgcHJlZGljdG9yDQpzdGF0ZSBpbiB0aGUgcGF5bG9hZCBmb3JtYXQgaGVh ZGVyLiAgWWV0IEZsZWlzY2htYW4gc2F5cyB0aGUgZXhpc3RpbmcNCmZpbGUg Zm9ybWF0cyBoYXZlIG1ldGhvZHMgdG8gZXhwcmVzcyBmcmFnbWVudGF0aW9u IGFuZCByZWFzc2VtYmx5IG9mDQpmcmFtZXMsIGFuZCBoZSB3YW50cyB0byB1 c2UgdGhlIGEgZ2VuZXJpYyBwYWNrZXRpemF0aW9uIG1lY2hhbmlzbSB0aGF0 DQpjYW4gZW5hYmxlIGFsbCB0aGlzIGRhdGEgdGhhdCB3YXMgb3JpZ2luYWxs eSB0YXJnZXRlZCBmb3Igb3RoZXIgbWVhbnMNCm9mIGNvbW11bmljYXRpb24g dG8gYmUgdXNlZCB3aXRoIFJUUC4gIEFudXAgUmFvIGFzc2VydGVkIHRoYXQN CnBhY2tldGl6YXRpb24gYmVsb25ncyB3aGVyZSBpdCBpcyBpbiBSVFAsIG5v dCBpbiB0aGUgZmlsZSBmb3JtYXQuICBBDQpjb2RlYyBwcm92aWRlciBzaG91 bGQgdGVsbCB0aGUgbWVkaWEgc2VydmVyIGhvdyB0byBwdXQgdGhlIGRhdGEg aW50bw0KUlRQLCBlaXRoZXIgdGhyb3VnaCBhIGRvY3VtZW50LCBvciBjb2Rl LCBvciBzZXQgb2YgcnVsZXMgZGVmaW5pbmcgd2hhdA0KdG8gZG8gd2l0aCBv YmplY3RzIGluIHRoZSBmaWxlLiAgVGhlIHRyYWRlb2ZmIG9mIG9wdGltaXpl ZCBwZXJmb3JtYW5jZQ0KdmVyc3VzIHRoZSByZWR1Y2VkIGVmZm9ydCBvZiBh IGdlbmVyaWMgbWVjaGFuaXNtIG1heSBiZSB0aGUgbW9zdA0KY29udGVudGlv dXMgaXNzdWUuICBUaGUgd29ya2luZyBncm91cCBjbGVhcmx5IGhhcyB3b3Jr IHRvIGRvIGJvdGggb24NCm5hbWUgbWFwcGluZyBhbmQgb24gcGFja2V0aXph dGlvbiB3aGljaCBzaG91bGQgYmUgY29udGludWVkIGluDQpkaXNjdXNzaW9u IG9uIHRoZSBtYWlsaW5nIGxpc3QuDQoNClNsaWRlczoJZnRwOi8vaHlkcmEu cHJlY2VwdC5jb20vcHViL3J0cC9pZXRmNDAtYXZ0LnBwdA0KCWh0dHA6Ly93 d3cuY3MuY29sdW1iaWEuZWR1L35oZ3MvcGFwZXJzL1NjaHU5NzEyOlJUUC5w cy5neg0KDQoNCjQuICBSZXZpc2lvbiBvZiBSVFAgTUlCIHNwZWNpZmljYXRp b24NCg0KQSBuZXcgZHJhZnQgb2YgdGhlIFJUUCBNSUIgd2FzIHBvc3RlZCBw cmlvciB0byB0aGlzIG1lZXRpbmcgYXMNCmRyYWZ0LWlldGYtYXZ0LXJ0cC1t aWItMDEudHh0LiAgTWFyayBCYXVnaGVyIGdhdmUgYSBwcmVzZW50YXRpb24g b24NCnRoZSBjaGFuZ2VzIGluIHRoaXMgdmVyc2lvbiBhbmQgdGhlIHN0YXR1 cyBvZiB0aGUgTUlCIGltcGxlbWVudGF0aW9uLg0KVGhlIG1haW4gZGlmZmVy ZW5jZSBmcm9tIHRoZSAtMDAgZHJhZnQgaXMgdGhlIHJlbW92YWwgb2YgUlRQ DQp0cmFuc2xhdG9yIGZ1bmN0aW9ucyBiZWNhdXNlIHRoZXJlIHdlcmUgbm8g aW1tZWRpYXRlIHBsYW5zIGZvciB0aG9zZQ0KZnVuY3Rpb25zIHRvIGJlIGlt cGxlbWVudGVkIGFuZCB0aGVyZWJ5IHZhbGlkYXRlZC4gIEEgZmV3IG90aGVy DQpjaGFuZ2VzIHdlcmUgbWFkZSBhcyBhIHJlc3VsdCBvZiBpbXBsZW1lbnRh dGlvbiBleHBlcmllbmNlLCBwbHVzIHRoZXJlDQp3ZXJlIHNldmVyYWwgY2xh cmlmaWNhdGlvbnMgaW4gcmVzcG9uc2UgdG8gYSByZXZpZXcgb2YgdGhlIE1J QiBieSBGcmVkDQpCYWtlci4gIFNvbWUgZG96ZW4gdmFyaWFibGVzIGhhdmUg YmVlbiBhZGRlZCBhY3Jvc3MgdGhlIHZhcmlvdXMgdGFibGVzDQppbiB0aGUg TUlCLg0KDQpUaGUgTUlCIGNvbnNpc3RzIG9mIHR3byBtb2R1bGVzOiB0aGUg UlRQLVNZU1RFTSBtb2R1bGUgZm9yIGVuZC1zeXN0ZW1zDQpyZXBvcnRzIGN1 cnJlbnQgdmFsdWVzIG9mIHZhcmlhYmxlcyBhc3NvY2lhdGVkIHdpdGggc3Ry ZWFtcyBiZWluZyBzZW50DQpvciByZWNlaXZlZCwgd2hlcmVhcyB0aGUgUlRQ LUlTIG1vZHVsZSBmb3IgUlRQIG1vbml0b3Igc3lzdGVtcyByZWNvcmRzDQpp bmZvcm1hdGlvbiBmcm9tIFJUQ1Agc2VuZGVyIGFuZCByZWNlaXZlciByZXBv cnRzIGZvciBhY2Nlc3MgdmlhDQpuZXR3b3JrIG1hbmFnZW1lbnQgYXBwbGlj YXRpb25zLiAgVGhlIE1JQiBhbGxvd3MgbW9uaXRvcmluZyBvZiBSVFANCnNl c3Npb25zIHRoYXQgYXJlIGluaXRpYXRlZCBieSBzb21lIG1lYW5zLCBidXQg Y2Fubm90IGluaXRpYXRlIG9yDQpjb250cm9sIHNlc3Npb25zIGl0c2VsZi4N Cg0KT25lIHZhcmlhYmxlIG9mIG5vdGUgdGhhdCB3YXMgYWRkZWQgdG8gdGhl IFJUUC1JUyBtb2R1bGUgaXMgdGhlDQpyb3VuZC10cmlwIHRpbWUgKFJUVCku ICBUaGlzIHZhcmlhYmxlIHdpbGwgb25seSBoYXZlIGEgbWVhbmluZ2Z1bA0K dmFsdWUgaWYgdGhlIFJUUCBtb25pdG9yJ3MgY2xvY2sgaXMgc3luY2hyb25p emVkIHdpdGggdGhhdCBvZiB0aGUNCnNlbmRlciBvZiB0aGUgcGFydGljdWxh ciBzdHJlYW07IGhvd2V2ZXIsIHNpbmNlIGl0IGlzIGV4cGVjdGVkIHRoYXQN CnVzdWFsIHByYWN0aWNlIGZvciB0aGUgY29tbW9uICJicm9hZGNhc3QiIHNj ZW5hcmlvIHdpbGwgYmUgdG8gbG9jYXRlDQphbiBSVFAgbW9uaXRvciBvbiB0 aGUgc2VuZGluZyBob3N0LCB0aGUgY2xvY2sgd2lsbCBiZSB0aGUgc2FtZS4N Cg0KVGhlIGV4cGVjdGVkIGFwcGxpY2F0aW9uIGZvciB0aGUgUlRQIE1JQiBp cyBhIGhlbHAtZGVzayBzY2VuYXJpby4NCkludGVsIGhhcyBpbXBsZW1lbnRl ZCB0aGUgTUlCIGZvciB1c2UgaW4gY29uanVuY3Rpb24gd2l0aCBJUCBNdWx0 aWNhc3QNCmFuZCBSU1ZQIE1JQnMgdG8gbW9uaXRvciBvcGVyYXRpb24gb2Yg UlRQIGFwcGxpY2F0aW9ucyBhY3Jvc3MgdGhlaXINCm11bHRpY2FzdCBiYWNr Ym9uZS4gIEludGVncmF0aW9uIGludG8gc3RhbmRhcmQgbmV0d29yayBtYW5h Z2VtZW50DQphcHBsaWNhdGlvbnMgZWFzZXMgdGhlIG1vbml0b3JpbmcgdGFz ayBmb3IgdGhlIElUIGRpdmlzaW9uLiAgVGhlDQpyZW1vdGUgbW9uaXRvcmlu ZyBjYXBhYmlsaXR5IHNpbXBsaWZpZXMgImRyeSBydW4iIHRlc3RpbmcgYmVm b3JlDQpicm9hZGNhc3QgZXZlbnRzIHRvIGFzc3VyZSBxdWFsaXR5LiAgVGhl IEludGVsIGltcGxlbWVudGF0aW9uIHdpbGwNCmFsc28gYmUgZXZhbHVhdGVk IGJ5IEhQLiAgVGhlIG5leHQgc3RlcHMgaW5jbHVkZSBhbiBpbmRlcGVuZGVu dA0KaW1wbGVtZW50YXRpb24gYnkgM0NvbSBhbmQgZml0dGluZyB0aGUgUlRQ IE1JQiBpbnRvIHRoZSBJVFUtVCBILU1lZGlhDQpNSUIgZnJhbWV3b3JrLiAg SXQgaXMgZXhwZWN0ZWQgdGhhdCB0aGVyZSB3aWxsIGJlIG9uZSBtb3JlIHJl dmlzaW9uIG9mDQp0aGUgZHJhZnQsIHRoZW4gYXQgdGhlIGNvbmNsdXNpb24g b2YgdGhlIHRlc3RpbmcgdW5kZXJ3YXkgYXQgSW50ZWwsIGl0DQppcyBwbGFu bmVkIHRoYXQgdGhlIFJUUCBNSUIgd2lsbCBiZSBzdWJtaXR0ZWQgZm9yIHB1 YmxpY2F0aW9uIGFzIGENClByb3Bvc2VkIFN0YW5kYXJkLg0KDQpTbGlkZXM6 CWh0dHA6Ly93d3cucmRyb3AuY29tL3VzZXJzL21iYXVnaGVyL3J0cG1pYnYw MS8NCg0KDQo1LiBOZXcgUlRQIHBheWxvYWQgZm9ybWF0IHByb3Bvc2Fscw0K DQpTZXZlcmFsIG5ldyBwYXlsb2FkIHR5cGVzIGhhdmUgYmVlbiBpbnRyb2R1 Y2VkIGF0IHRoZSBwYXN0IG9uZSBvciB0d28NCkFWVCBtZWV0aW5ncy4gIFNv bWUgb2YgdGhlc2UgYXJlIG5vdyBjb21wbGV0ZWQgYW5kIHJlYWR5IGZvcg0K cHVibGljYXRpb24sIHRob3VnaCBvdGhlcnMgbmVlZCBmdXJ0aGVyIHdvcmsu DQoNCg0KNS4xICBSVFAgdXNlIGluIE1QRUc0IGFuZCB0aGUgcm9sZSBvZiBE TUlGDQoNClZhaGUgQmFsYWJhbmlhbiBjaGFpcnMgdGhlIERlbGl2ZXJ5IE11 bHRpbWVkaWEgSW50ZWdyYXRpb24gRnJhbWV3b3JrDQooRE1JRikgc3ViZ3Jv dXAgd2l0aGluIE1QRUcgYW5kIGdhdmUgYSBwcmVzZW50YXRpb24gdG8gQVZU IHRvIGV4cGxvcmUNCmhvdyBNUEVHLTQgY2FuIG1ha2Ugb3B0aW1hbCB1c2Ug b2YgUlRQIHRocm91Z2ggRE1JRi4gIFRoZSBETUlGDQpzcGVjaWZpY2F0aW9u IElTTy9JRUMgMTQ0OTYtNiBpcyBjb25jZXJuZWQgcHJpbWFyaWx5IHdpdGgg Y29udHJvbA0KcGxhbmUgKHNpZ25hbGluZykgZnVuY3Rpb25zIGluY2x1ZGlu ZyBRb1MsIGJ1dCB3b3JrcyBpbiBjb25qdW5jdGlvbg0Kd2l0aCB0aGUgTVBF Ry00IFN5c3RlbXMgc3BlY2lmaWNhdGlvbiBJU08vSUVDIDE0NDk2LTEgd2hp Y2ggZGVmaW5lcw0KdGhlIGRhdGEgcGxhbmUuDQoNClRoZSBnZW5lcmljIE1Q RUctNCBhcmNoaXRlY3R1cmUgaXMgY29tcG9zZWQgb2YgdGhyZWUgbGF5ZXJz OiBhDQpjb21wcmVzc2lvbiBsYXllciwgYSBzeXN0ZW1zIGxheWVyIHRoYXQg bWFuYWdlcyBzeW5jaHJvbml6YXRpb24gYW5kDQpoaWVyYXJjaHkgYW1vbmcg ZWxlbWVudGFyeSBzdHJlYW1zLCBhbmQgYSBkZWxpdmVyeSBsYXllci4gIFRo ZSBETUlGDQpBcHBsaWNhdGlvbiBJbnRlcmZhY2UgKERBSSkgYmV0d2VlbiB0 aGUgc3lzdGVtcyBhbmQgZGVsaXZlcnkgbGF5ZXJzIGlzDQppbnRlbmRlZCB0 byBhbGxvdyBwbGF5YmFjayBvZiBzdHJlYW1zIHRyYW5zcGFyZW50IHRvIHRo ZSBzb3VyY2UNCmxvY2F0aW9uIGFuZCBkZWxpdmVyeSB0ZWNobm9sb2d5LiAg U3RldmUgQ2FzbmVyIG9ic2VydmVkIHRoYXQgb25lDQpjaGFsbGVuZ2UgaW4g YXR0ZW1wdGluZyB0byBtYXAgTVBFRy00IHRvIFJUUCBpcyB0aGF0IFJUUCBw cm92aWRlcyBzb21lDQpvZiB0aGUgZnVuY3Rpb24gb2YgdGhlIHN5c3RlbSBs YXllciwgc28gdGhlIERBSSBtYXkgbm90IGZpdCBSVFAgd2VsbC4NCltUaGlz IGlzIG9uZSBhc3BlY3Qgb2YgUlRQJ3MgQXBwbGljYXRpb24gTGV2ZWwgRnJh bWluZyBkZXNpZ24NCnBoaWxvc29waHkgaW4gd2hpY2ggcHJvY2Vzc2luZyBp cyBpbnRlZ3JhdGVkIGFjcm9zcyBsYXllcnM7IGF0dGVtcHRpbmcNCnRvIGtl ZXAgdXBwZXIgbGF5ZXJzIHVuYXdhcmUgb2YgbmV0d29ya2luZyBpc3N1ZXMg Y2FuIG1ha2UNCm9wdGltaXphdGlvbiBvZiB0aGUgb3ZlcmFsbCBzeXN0ZW0g bW9yZSBkaWZmaWN1bHQuIC0tRWQuXQ0KDQpJbiBNUEVHLTQsIGltYWdlcyBh cmUgcmVuZGVyZWQgZnJvbSBtdWx0aXBsZSBlbGVtZW50YXJ5IHN0cmVhbXMg b2YNCnByaW1pdGl2ZSBhdWRpbywgdmlkZW8gYW5kIGdyYXBoaWNhbCBvYmpl Y3RzIGFjY29yZGluZyB0byBzY2VuZQ0KZGVzY3JpcHRpb24gaW5mb3JtYXRp b24gdGhhdCB0ZWxscyBob3cgdGhlIHByaW1pdGl2ZSBvYmplY3RzIGFyZSB0 byBiZQ0KY29tcG9zZWQuICBUaGUgc2NlbmUgZGVzY3JpcHRpb24gaXMgaXRz ZWxmIGFub3RoZXIgZWxlbWVudGFyeSBzdHJlYW0uDQoNCkFjcm9zcyB0aGUg KGluZm9ybWF0aXZlKSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgY29tcHJlc3Np b24gbGF5ZXIgYW5kDQp0aGUgc3lzdGVtcyBsYXllciwgZWFjaCBlbGVtZW50 YXJ5IHN0cmVhbSBpcyBkZWxpdmVyZWQgYXMgYSBzZXF1ZW5jZQ0Kb2YgYWNj ZXNzIHVuaXRzIChBVXMpLiAgVGhlIHN5c3RlbXMgbGF5ZXIgaXMgcmVzcG9u c2libGUgZm9yDQpmcmFnbWVudGluZyB0aGUgQVVzIGludG8gcGFja2V0cyAo Y2FsbGVkIEFMLVBEVXMpIHdoaWNoIGFyZSBwYXNzZWQNCmFjcm9zcyB0aGUg KG5vcm1hdGl2ZSkgREFJIHRvIHRoZSBkZWxpdmVyeSBsYXllci4gIFRoZSBo ZWFkZXIgb2YgdGhlDQpmaXJzdCBBTC1QRFUgb2YgYW4gQVUgY29udGFpbnMg dGhlIGZ1bGwgdGltaW5nIGluZm9ybWF0aW9uIHBhc3NlZCB3aXRoDQp0aGUg QVUsIGJ1dCBzdWJzZXF1ZW50IEFMLVBEVXMgb2YgdGhhdCBBVSBoYXZlIGEg c21hbGxlciBoZWFkZXIuDQpNUEVHLTQgU3lzdGVtcyBhbHNvIGRlZmluZXMg YSBzdWJsYXllciBvZiB0aGUgZGVsaXZlcnkgbGF5ZXIgdG8NCm11bHRpcGxl eCBtdWx0aXBsZSBlbGVtZW50YXJ5IHN0cmVhbXMgKGluIEFMLVBEVXMpIHdp dGggZGlmZmVyZW50IFFvUw0KYW5kIHByaW9yaXR5IHJlcXVpcmVtZW50cyBp bnRvIGEgIkZsZXhNdXggc3RyZWFtIiBiZWZvcmUgdHJhbnNtaXNzaW9uDQpv dmVyIGEgbmV0d29yayB0cmFuc3BvcnQgY2hhbm5lbCwgYnV0IHRoZSBGbGV4 TXV4IHN1YmxheWVyIG1heSBiZQ0KYnlwYXNzZWQuICBUaGUgZm9ybWF0IG9m IHRoZSBBTC1QRFVzIHdvdWxkIGJlIHRoZSBzdGFydGluZyBwb2ludCBmb3IN CmdlbmVyYXRpbmcgUlRQIHBhY2tldHMgYXQgdGhlIHRyYW5zbWl0dGVyLiAg Q29udmVyc2VseSwgYXQgdGhlDQpyZWNlaXZlciBBTC1QRFVzIHdvdWxkIGhh dmUgdG8gYmUgcmVnZW5lcmF0ZWQgZnJvbSB0aGUgaW5jb21pbmcgUlRQDQpw YWNrZXRzLg0KDQpCYWxhYmFuaWFuIHByZXNlbnRlZCBhIHN0cmF3bWFuIHBy b3Bvc2FsIGZvciBob3cgUlRQIG1pZ2h0IGJlIHVzZWQgZm9yDQpNUEVHLTQg dG8gZ2V0IHRoZSBBVlQgZ3JvdXAncyBmZWVkYmFjayBiZWZvcmUgdGFraW5n IHRoZSBwcm9wb3NhbCB0bw0KdGhlIE1QRUcgY29tbWl0dGVlLiAgT25lIGdv YWwgb2YgdGhlIGRlc2lnbiBpcyB0byB0cmFuc2Zvcm0gcGFyYW1ldGVycw0K ZnJvbSB0aGUgTVBFRy00IGhlYWRlcnMgaW50byBSVFAgZmllbGRzIChzdWNo IGFzIHNlcXVlbmNlIG51bWJlciBhbmQNCnRpbWVzdGFtcCkgYXMgbXVjaCBh cyBwb3NzaWJsZSBpbiBvcmRlciB0byBtaW5pbWl6ZSBkdXBsaWNhdGUNCmlu Zm9ybWF0aW9uLiAgVGhlIFJUUCBkYXRhIHBhY2tldHMgY291bGQgY29udGFp biBtdWx0aXBsZSBBTC1QRFVzDQp1c2luZyBhIG11bHRpcGxleGluZyBoZWFk ZXIgYm9ycm93ZWQgZnJvbSB0aGUgRmxleE11eCBjb25jZXB0LiAgVGhlcmUN CndlcmUgc2V2ZXJhbCBjb21tZW50cyBvbiB0aGUgcHJvcG9zYWwgdG8gdXNl IHRoZSBFbGVtZW50YXJ5IFN0cmVhbSBJRA0KYXMgdGhlIFNTUkMgSUQuICBU aGVzZSBhcmUgdW5pcXVlIHdpdGhpbiBvbmUgTVBFRy00IHNlc3Npb24sIGJ1 dA0KcGVyaGFwcyBub3QgaW4gYSBtdWx0aS1zZW5kZXIgbXVsdGljYXN0IHNj ZW5hcmlvLiAgVGhlcmUgd2VyZSBhbHNvDQpxdWVzdGlvbnMgYWJvdXQgaG93 IHRoZSBpbmZvcm1hdGlvbiBvdGhlciB0aGFuIGF1ZGlvIGFuZCB2aWRlbyBt aWdodA0KYmUgY2FycmllZDsgc29tZSBtYXkgYmUgc3RhdGljIGZvciB0aGUg c2Vzc2lvbiBhbmQgc3VpdGFibGUgZm9yDQpvdXQtb2YtYmFuZCB0cmFuc21p c3Npb24gaW4gU0RQIG9yIFJUU1AsIHdoaWxlIGZvciB0aGUgZHluYW1pYw0K aW5mb3JtYXRpb24gc3VjaCBhcyBzY2VuZSBkZXNjcmlwdGlvbnMgUlRQL1VE UCBtaWdodCBub3QgYmUgZW5vdWdoLg0KDQpUaGUgc3RyYXdtYW4gYWxzbyBw cm9wb3NlZCB0aGF0IG9ubHkgdGhlIFJUQ1AgU1IgYW5kIFJSIHBhY2tldHMg YmUNCnVzZWQgc2luY2UgZXhpc3RpbmcgTVBFRy00IGRlc2NyaXB0b3JzIGFu ZCBzaWduYWxpbmcgY2FycnkgdGhlIG90aGVyDQpSVENQIGluZm9ybWF0aW9u LiAgSG93ZXZlciwgSm9uYXRoYW4gUm9zZW5iZXJnIGNvbW1lbnRlZCB0aGF0 IHRoZSBTREVTDQpDTkFNRSBpcyB1c2VkIGluIFNTUkMgY29sbGlzaW9uIGRl dGVjdGlvbi4gIERvbiBIb2ZmbWFuIHN1Z2dlc3RlZCB0aGF0DQp0aGUgdXNl IG9mIEJZRSBzaG91bGQgbm90IGJlIHByZWNsdWRlZCBzaW5jZSBNUEVHLTQg bWlnaHQgYWxzbyBiZSB1c2VkDQppbiBsaWdodHdlaWdodCBzZXNzaW9ucyB3 aXRoIG5vIGFkZGl0aW9uYWwgc2lnbmFsaW5nLg0KDQpDYXNuZXIgc3VnZ2Vz dGVkIHRoYXQgdGhlcmUgd2VyZSBtYW55IGRldGFpbHMgaW4gdGhlIHByZXNl bnRhdGlvbiB0aGF0DQp0aGUgZ3JvdXAgcHJvYmFibHkgZGlkbid0IHVuZGVy c3RhbmQgc3VmZmljaWVudGx5IHRvIG1ha2UgY29tbWVudHMgaW4NCnJlYWwg dGltZSwgYW5kIHRoYXQgdGhlIHJpZ2h0IHdheSB0byBwcm9jZWVkIHdvdWxk IGJlIHRvIHdyaXRlIGFuDQpJbnRlcm5ldC1EcmFmdCBkZXNjcmliaW5nIHRo ZSBwcm9wb3NhbC4gIENvbW1lbnRzIHdpbGwgYmUgc29saWNpdGVkIG9uDQp0 aGUgbWFpbGluZyBsaXN0IHdoZW4gdGhhdCBkcmFmdCBpcyBwcmVwYXJlZC4N Cg0KDQo1LjIgIEguMjYzKyB2aWRlbyBwYXlsb2FkIGZvcm1hdA0KDQpBcyBu b3RlZCBpbiB0aGUgaW50cm9kdWN0aW9uLCB0aGUgcGF5bG9hZCBmb3JtYXQg c3BlY2lmaWNhdGlvbiBmb3INCkguMjYzIHZpZGVvIGhhcyBiZWVuIHB1Ymxp c2hlZCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQzIxOTguDQpIb3dldmVy LCBlbmhhbmNlbWVudCBvZiB0aGUgZW5jb2RpbmcgaXRzZWxmIGNvbnRpbnVl cyB1bmRlciB0aGUgbGFiZWwNCkguMjYzKyB0byBpbXByb3ZlIGxvc3MgcmVz aWxpZW5jZSBhbmQgdG8gdXRpbGl6ZSBpbmNyZWFzZWQgcHJvY2Vzc2luZw0K cG93ZXIgdG8gYWNoaWV2ZSBoaWdoZXIgcXVhbGl0eS4gIEFzIGFncmVlZCBp biBwcmV2aW91cyBBVlQgbWVldGluZ3MsDQphIHNlcGFyYXRlIFJUUCBwYXls b2FkIGZvcm1hdCBpcyBiZWluZyBkZXNpZ25lZCB0byBzdXBwb3J0IHRoZQ0K ZW5oYW5jZWQgZW5jb2RpbmcuICBJbiBNdW5pY2gsIFN0ZXBoYW4gV2VuZ2Vy IHByZXNlbnRlZCB0d28gZGlmZmVyZW50DQphcHByb2FjaGVzIHByb3Bvc2Vk IGluIHNlcGFyYXRlIGRyYWZ0cy4gIEFzIHByb21pc2VkIHRoZW4sIHRoZSB0 d28NCmFwcHJvYWNoZXMgaGF2ZSBzaW5jZSBiZWVuIG1lcmdlZCBpbnRvIGEg bmV3IEludGVyZXQtRHJhZnQgbmFtZWQNCmRyYWZ0LWlldGYtYXZ0LXJ0cC1o MjYzLXZpZGVvLTAwLnR4dCB0aGF0IHdhcyBzdWJtaXR0ZWQgaW4gTm92ZW1i ZXIuDQpUaGUgcHJlc2VudGF0aW9uIGF0IHRoaXMgbWVldGluZyB3YXMgYmFz ZWQgdXBvbiB0aGF0IGRyYWZ0IHdpdGggc29tZQ0KbW9kaWZpY2F0aW9ucyBw cm9wb3NlZCBhcyBhIHJlc3VsdCBvZiB0aGUgSVRVIEguMjYzKyBtZWV0aW5n IHRoZSB3ZWVrDQpiZWZvcmUgSUVURi4gIFRob3NlIG1vZGlmaWNhdGlvbnMg YW5kIGZlZWRiYWNrIGZyb20gdGhpcyBtZWV0aW5nIHdlcmUNCmluY29ycG9y YXRlZCBpbnRvIGRyYWZ0LWlldGYtYXZ0LXJ0cC1oMjYzLXZpZGVvLTAxLnR4 dCBwb3N0ZWQgc2luY2UNCnRoZSBtZWV0aW5nLg0KDQpUaGUgSC4yNjMrIGVu aGFuY2VtZW50cyBpbmNsdWRlIHNldmVyYWwgZXJyb3IgcmVzaWxpZW5jZSBt ZWNoYW5pc21zDQpkZXNpZ25lZCB0byBzY2FsZSBvdmVyIGEgcGFja2V0IGxv c3MgcHJvYmFiaWxpdHkgZnJvbSAwIHRvIDIwJS4gIFRoZQ0KbmV3IFJUUCBw YXlsb2FkIGZvcm1hdCBzdXBwb3J0cyBhbGwgb2YgdGhvc2UgbWVjaGFuaXNt cy4gIFRoZSBiYXNpYw0KcGF5bG9hZCBoZWFkZXIgaXMgMTYgYml0cyB3aXRo IHR3byBvcHRpb25hbCBleHRlbnNpb25zOiBhbiA4LWJpdCBWaWRlbw0KUmVk dW5kYW5jeSBDb2RpbmcgaGVhZGVyLCBhbmQgYW4gODAtYml0IGJhY2stY2hh bm5lbCBtZXNzYWdlIGRpc2N1c3NlZA0KYmVsb3cuICBUaGUgYmFzaWMgaGVh ZGVyIHNwZWNpZmllcyB0aGUgYml0IGxlbmd0aCBvZiB0aGUgcmVkdW5kYW50 DQpQaWN0dXJlIEhlYWRlciB0aGF0IG1heSBiZSBpbmNsdWRlZCBpbiBwYWNr ZXRzIGFmdGVyIHRoZSBmaXJzdCBvZiBhDQpwaWN0dXJlLiAgVGhpcyBpcyBv bmUgb2YgdGhlIHByaW1hcnkgZXJyb3IgcmVzaWxpZW5jZSBtZWNoYW5pc21z Lg0KRGV0YWlscyBhcmUgaW4gdGhlIGRyYWZ0Lg0KDQpUd28gdXNhZ2UgZXhh bXBsZXMgd2VyZSBnaXZlbjogSC4yNjMrIGNhbiBhY2hpZXZlICJ2ZXJ5IGdv b2QiIHF1YWxpdHkNCndpdGggMTAgZnJhbWVzIHBlciBzZWNvbmQgaW4gUUNJ RiBzaXplIGF0IDExMmtiL3MuICBUaGF0J3MgYW4gYXZlcmFnZQ0Kb2YgMTQw MCBieXRlcyBwZXIgZnJhbWUsIHdoaWNoIG1lYW5zIG1vc3QgZnJhbWVzIGZp dCBpbiBhIHNpbmdsZQ0KcGFja2V0LiAgVGhlIHNlY29uZCBleGFtcGxlIHdh cyBhIGxheWVyZWQgZW5jb2Rpbmcgc2NoZW1lIHdpdGggYQ0KMjBrYi9zIGJh c2UgbGF5ZXIgcHJvZHVjaW5nIDcuNSBmcmFtZXMvc2VjIFFDSUYsIGEgOTBr Yi9zIGZpcnN0DQplbmhhbmNlbWVudCBsYXllciBpbXByb3ZpbmcgdGhlIGRp c3BsYXkgdG8gMTUgZnJhbWVzL3NlYyBDSUYsIGFuZCBhDQo2MGtiL3Mgc2Vj b25kIGVuaGFuY2VtZW50IGxheWVyIGluY3JlYXNpbmcgdGhlIGZyYW1lIHJh dGUgdG8gMzANCmZyYW1lcy9zZWMgQ0lGLiAgQXQgdGhlIGVuZCBvZiB0aGUg bWVldGluZywgQ2hyaXN0aWFuIE1hY2lvY2NvDQpwcm92aWRlZCBhbiBvbi1z aXRlIGRlbW9uc3RyYXRpb24gb2YgdGhpcyBzZWNvbmQgZXhhbXBsZSBpbXBs ZW1lbnRlZA0KYXQgSW50ZWwuICBJbiBhZGRpdGlvbiwgQVZUIHBhcnRpY2lw YW50cyB3ZXJlIGludml0ZWQgdG8gZG93bmxvYWQgZnJvbQ0KaHR0cDovL2ti cy5jcy50dS1iZXJsaW4uZGUvcGF5bG9hZCBhIHRlc3QgaW1wbGVtZW50YXRp b24gb2YgdGhlIHZpYw0KdG9vbCB3aXRoIGEgcHVibGljIGRvbWFpbiBILjI2 MysgYW5kIHRoZSBuZXcgcGFja2V0aXphdGlvbiBzY2hlbWUNCmFkZGVkLg0K DQpUaGVyZSBhcmUgdHdvIG9wZW4gaXNzdWVzLiAgVGhlIGZpcnN0IGlzc3Vl IGlzIHdoZXRoZXIgZnJhZ21lbnRhdGlvbg0KbWF5IGJlIGFsbG93ZWQgYXQg Ynl0ZSBib3VuZGFyaWVzIHdpdGhpbiBhIG1hY3JvYmxvY2sgc28gdGhhdCBp dCBpcw0Kbm90IG5lY2Vzc2FyeSB0byBhZGQgcGF5bG9hZCBoZWFkZXIgZmll bGRzIHRvIGluZGljYXRlIHVudXNlZCBiaXRzIGF0DQp0aGUgc3RhcnQgYW5k IGVuZCBvZiB0aGUgcGF5bG9hZC4gIFRoZSBjb25jZXJuIGlzIHRoYXQgZGVj b2Rlcg0KcGVyZm9ybWFuY2Ugd2lsbCBiZSByZWR1Y2VkIGJ5IGhhdmluZyB0 byBjaGVjayBmb3IgZW5kLW9mLWJ1ZmZlciBpbg0KdGhlIGlubmVybW9zdCBs b29wLiAgVGhpcyBxdWVzdGlvbiB3aWxsIGJlIGFuc3dlcmVkIGJ5IHNpbXVs YXRpb25zLg0KDQpUaGUgc2Vjb25kIGlzc3VlIHdhcyB0aGUgc3ViamVjdCBv ZiBudW1lcm91cyBjb21tZW50cyBpbiB0aGUgbWVldGluZzoNCnNob3VsZCB0 aGUgYmFjay1jaGFubmVsIG1lc3NhZ2UgYmUgaW5jbHVkZWQsIGFuZCBpZiBz bywgaG93IHNob3VsZCBpdA0KYmUgdXNlZD8gIFRoZSBwdXJwb3NlIG9mIHRo ZSBiYWNrLWNoYW5uZWwgbWVzc2FnZSBpcyB0byB0ZWxsIHRoZQ0KZW5jb2Rl ciBhZnRlciBhbiBlcnJvciBvY2N1cnMgd2hhdCB3YXMgdGhlIG1vc3QgcmVj ZW50IHBpY3R1cmUNCnN1Y2Nlc3NmdWxseSByZWNlaXZlZC4gIEZvciBwb2lu dC10by1wb2ludCBjb21tdW5pY2F0aW9uLCB0aGlzIGlzIHRoZQ0KbW9zdCBl ZmZpY2llbnQgZXJyb3ItcmVzaWxpZW5jZSBtZWNoYW5pc20uICBIb3dldmVy LCBpdCBkb2VzIG5vdCBzY2FsZQ0KdG8gbGFyZ2UgbXVsdGljYXN0IGdyb3Vw cy4gIEZ1cnRoZXJtb3JlLCBzZXZlcmFsIHBhcnRpY2lwYW50cyBzYWlkDQp0 aGF0IGNvbnRyb2wgaW5mb3JtYXRpb24gc3VjaCBhcyB0aGlzIHNob3VsZCBi ZSBjYXJyaWVkIGluIFJUQ1AgcmF0aGVyDQp0aGFuIGFzIGFuIG9wdGlvbmFs IGhlYWRlciBpbiBSVFAgZGF0YSBwYWNrZXRzLiAgSm9uYXRoYW4gUm9zZW5i ZXJnDQpub3RlZCB0aGF0IHRoZSBSVENQIHBhY2tldCByYXRlIGNhbiBiZSBz Y2FsZWQgdG8gYmUgbW9yZSBmcmVxdWVudCBmb3INCnVuaWNhc3QgYXBwbGlj YXRpb25zIHNvIHRoZSBpbnRlcnZhbCBuZWVkIG5vdCBiZSBhIHByb2JsZW0u ICBDYXJzdGVuDQpCb3JtYW5uIHNhaWQgdGhlIGNvbmNlcm4gd2l0aCB1c2lu ZyBSVENQIGlzIHRoZSBhZGRpdGlvbmFsIG92ZXJoZWFkIG9mDQpzZXBhcmF0 ZSBSVENQIHBhY2tldHMgaW4gc2NlbmFyaW9zIHdoZXJlIHRoZXkgYXJlIHNl bnQgZnJlcXVlbnRseSwgaW4NCnBhcnRpY3VsYXIgd2hlbiB0aGUgYmFjay1j aGFubmVsIG1lc3NhZ2UgaXMgdXNlZCBhcyBhbiBBQ0sgcmF0aGVyIHRoYW4N CmEgTkFDSy4gIEhlIGFsc28gcG9pbnRlZCBvdXQgdGhhdCBiYWNrLWNoYW5u ZWwgc2lnbmFsaW5nIGluIFJUUA0KcGFja2V0cyB3b3VsZCBvbmx5IGJlIHVz ZWQgd2hlbiB2aWRlbyB3YXMgYWxyZWFkeSBiZWluZyBzZW50IGluIHRoZQ0K YmFja3dhcmQgZGlyZWN0aW9uIChjb250aW51b3VzIHByZXNlbmNlKS4gIFNj b3R0IFBldHJhY2sgc2FpZCBoZSdkDQpiZWVuIGNvbnNpZGVyaW5nIGEgcHJv cG9zYWwgZm9yIGEgZ2VuZXJpYyBtZWNoYW5pc20gdG8gY29tcHJlc3MgUlRD UA0KcGFja2V0cyBhbmQgcGlnZ3ktYmFjayB0aGVtIG9uIFJUUCBwYWNrZXRz IHRvIHJlZHVjZSBvdmVyaGVhZCBpbiB2ZXJ5DQpsb3cgYmFuZHdpZHRoIHNj ZW5hcmlvcywgYnV0IHRoYXQgdGhlIGlkZWEgbmVlZGVkIGZ1cnRoZXIgd29y ay4NCg0KVGhlcmUgd2FzIGFsc28gYSBkaXNjdXNzaW9uIG9mIHdoZXRoZXIg dGhlcmUgd291bGQgYmUgdG9vIG11Y2ggbGF0ZW5jeQ0KZm9yIHRoZSBiYWNr LWNoYW5uZWwgbWVjaGFuaXNtIHRvIGJlIHVzZWZ1bC4gIEhvd2V2ZXIsIEdh cnkgU3VsbGl2YW4NCnBvaW50ZWQgb3V0IHRoYXQgaW4gZml4ZWQtY2FtZXJh IHNjZW5hcmlvcyBzdWNoIGFzIGEgdGVsZWNvbmZlcmVuY2UsDQpldmVuIGFu IGV4dHJlbWVseSBvbGQgcmVmZXJlbmNlIGZyYW1lIGNhbiBiZSB1c2VmdWwg YmVjYXVzZSBtdWNoIG9mDQp0aGUgYmFja2dyb3VuZCBkb2VzIG5vdCBjaGFu Z2UuDQoNCkJvcm1hbm4gc2FpZCB0aGUgcHJvcG9zYWwgc2hvdWxkIGRlZmlu ZSBhIG1lYW5zIHRvIGNhcnJ5IHRoZQ0KaW5mb3JtYXRpb24gaW4gUlRDUCBh cyB3ZWxsIGFzIFJUUCwgYW5kIHNwZWNpZnkgd2hlbiBlYWNoIG9mIHRoZXNl DQptZWNoYW5pc20gaXMgdG8gYmUgdXNlZC4gIFdlbmdlciBub3RlZCB0aGF0 IHdoZW4gSC4yNjMrIGlzIHVzZWQgaW4gdGhlDQpILjMyMyBmcmFtZXdvcmss IHRoZSBiYWNrY2hhbm5lbCBpbmZvcm1hdGlvbiB3b3VsZCBiZSBjYXJyaWVk IGluIHRoZQ0KSC4yNDUgY29udHJvbCBjb25uZWN0aW9uLCBub3QgaW4gUlRQ IGFueXdheSwgc28gaGUgd291bGQgbm90IGJlIHRvbw0KY29uY2VybmVkIHRv IGxlYXZlIGl0IG91dCBvZiB0aGUgcGF5bG9hZCBmb3JtYXQgcHJvcG9zYWwg ZW50aXJlbHkuDQpTdGV2ZSBDYXNuZXIgZXhwcmVzc2VkIGNvbmNlcm4gYWJv dXQgaGF2aW5nIG11bHRpcGxlIHdheXMgdG8gc2VuZCB0aGUNCmJhY2stY2hh bm5lbCBpbmZvcm1hdGlvbiBsZWFkaW5nIHRvIGluY29tcGF0aWJpbGl0aWVz LiAgSm9lcmcgT3R0DQpzdWdnZXN0ZWQgdGhhdCB0aGUgUlRQIGFuZCBSVENQ IG9wdGlvbnMgc2hvdWxkIGJlIHNpbXVsYXRlZCB0bw0KZGV0ZXJtaW5lIHRo ZSBvcHRpbXVtIG9wZXJhdGlvbiBwb2ludCBmb3IgYm90aCBtZWNoYW5pc21z Lg0KDQpCb2IgV2ViYmVyIGFza2VkIHdoZXRoZXIgdGhpcyBuZXcgSC4yNjMr IHBheWxvYWQgZm9ybWF0IHdvdWxkIG9ic29sZXRlDQp0aGUgSC4yNjMgcGF5 bG9hZCBmb3JtYXQgaW4gUkZDMjE5MCwgc3VjaCB0aGF0IHRoZSBsYXR0ZXIg d291bGQgbm90IGJlDQphZHZhbmNlZCBiZXlvbmQgUHJvcG9zZWQgU3RhbmRh cmQuICBXZW5nZXIgZXhwZWN0cyB0aGF0IHRoZSBpbmR1c3RyeQ0Kd2lsbCBt b3ZlIHF1aWNrbHkgdG8gSC4yNjMrLiAgQ2FzbmVyIHJlcGxpZWQgdGhhdCB0 aGUgZGVjaXNpb24gbm90IHRvDQphZHZhbmNlIFJGQzIxOTAgd291bGQgYmUg YmFzZWQgb24gYSByZXNwb25zZSBmcm9tIHRoZSBjb25zdGl0dWVuY3kgdGhh dA0KaXQgaXMgbm90IG5lZWRlZC4gIFRoZSBwcm9ibGVtIGlzIHRvIGRldGVy bWluZSBob3cgdG8gY29udGFjdCB0aGF0DQpjb25zdGl0dWVuY3kuICBUaGlz IHF1ZXN0aW9uIHdhcyBkZWZlcnJlZCB0byBkaXNjdXNzaW9uIHdpdGggdGhl DQphdXRob3JzIG9mIFJGQzIxOTAuDQoNCkJvcm1hbm4gc2FpZCB0aGF0IHRo ZSBhdXRob3JzIGludGVuZGVkIHRvIHVwZGF0ZSB0aGUgZHJhZnQgc29vbiBh ZnRlcg0KdGhlIG1lZXRpbmcsIGFuZCByZXF1ZXN0ZWQgcHJvbXB0IGZlZWRi YWNrIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgc28NCnRoYXQgdGhlIHBheWxv YWQgZm9ybWF0IGNvdWxkIGJlIHB1dCB1cCBmb3Igd29ya2luZyBncm91cCBs YXN0IGNhbGwgaW4NCkphbnVhcnkuICBUaGlzIGlzIGltcG9ydGFudCBpbiBv cmRlciB0byBtZWV0IHNvbWUgSVRVIGRlYWRsaW5lczsNCm90aGVyd2lzZSwg YSBkcmFmdCB2ZXJzaW9uIG9mIHRoZSBzcGVjIG1pZ2h0IGdldCBpbmNvcnBv cmF0ZWQgaW50byBhbg0KSVRVIGRvY3VtZW50IHN1Y2ggdGhhdCBBVlQgd291 bGQgbm8gbG9uZ2VyIGJlIGFibGUgdG8gY2hhbmdlIGl0Lg0KDQpTbGlkZXM6 CWh0dHA6Ly9rYnMuY3MudHUtYmVybGluLmRlL3BheWxvYWQvc2xpY2VzLw0K DQoNCjUuMyAgQlQtNjU2IHZpZGVvIHBheWxvYWQgZm9ybWF0DQoNCkRlcm1v dCBUeW5hbiBwcmVzZW50ZWQgYSByZXZpc2VkIHByb3Bvc2FsIGZvciBjYXJy eWluZyBJVFUtUiBCVC42NTYtMw0KdW5jb21wcmVzc2VkIHZpZGVvIG92ZXIg UlRQIGluIGRyYWZ0LXR5bmFuLXJ0cC1idDY1Ni0wMS50eHQuICBCVC42NTYg aXMNCnN0dWRpby1xdWFsaXR5IGRpZ2l0YWwgdmlkZW8gc2FtcGxlZCBhY2Nv cmRpbmcgdG8gQlQuNjAxLTUgKGZvcm1lcmx5DQpDQ0lSNjAxKSBhdCAxMy41 IG9yIDE4IE1Iei4gIEF0IHRoZSBub3JtYWwsIGxvd2VyIHJhdGUsIGVhY2gg c2NhbiBsaW5lDQpjb250YWlucyA3MjAgc2FtcGxlcyBvY2N1cHlpbmcgMTQ0 MCBieXRlcyBpbiB0aGUgNDoyOjIgY2hyb21pbmFuY2UNCmVuY29kaW5nLiAg QXQgdGhlICJoaWdoIGRlZmluaXRpb24iIHJhdGUsIGVhY2ggbGluZSBjb250 YWlucyAxMTQ0DQpzYW1wbGVzIGZvciBOVFNDIG9yIDExNTIgc2FtcGxlcyBm b3IgUEFMLiAgVGhlIFJUUCBwYXlsb2FkIGZvcm1hdA0KY29uc2lzdHMgb2Yg YSBmYWlybHkgc2ltcGxlIDMyLWJpdCBoZWFkZXIgZm9sbG93ZWQgYnkgb25l IHNjYW4gbGluZSBvZg0Kc2FtcGxlcyAob3IgYSBmcmFnbWVudCB0aGVyZW9m KS4NCg0KVGhlIGNoYW5nZXMgc2luY2UgdGhlIHByZXZpb3VzIHZlcnNpb24g cHJlc2VudGVkIGluIE11bmljaCBhcmUgdGhhdA0KdGhlIGZsYWdzIHRvIGlu ZGljYXRlIE5UU0MvUEFMIGFuZCAxMy41LzE4IE1IeiBzYW1wbGluZyByYXRl IGhhdmUgYmVlbg0KY29tYmluZWQgaW50byBhIHNpbmdsZSB0eXBlIGZpZWxk IG9mIDQgYml0czsgYW4gZXh0cmEgZmxhZyBoYXMgYmVlbg0KYWRkZWQgdG8g aW5kaWNhdGUgMTAtYml0IHF1YW50aXphdGlvbiB2cy4gdGhlIGRlZmF1bHQg OC1iaXQ7IGFuZCBwZXINCnRoZSByZWNvbW1lbmRhdGlvbiBvZiB0aGUgd29y a2luZyBncm91cCBpbiBNdW5pY2gsIGFuIDExLWJpdCBzY2FuDQpvZmZzZXQg ZmllbGQgaGFzIGJlZW4gYWRkZWQgdG8gc3VwcG9ydCBmcmFnbWVudGF0aW9u IG9mIHNjYW4gbGluZXMNCnRoYXQgYXJlIHRvbyBsb25nIGZvciB0aGUgbmV0 d29yayBNVFUuICBGcmFnbWVudGF0aW9uIG11c3Qgb2NjdXIgb25seQ0Kb24g YSBzYW1wbGUtcGFpciBib3VuZGFyeSAodGhhdCBpcywgYmV0d2VlbiBDYixZ LENyLFkgdW5pdHMpIGFuZCB0aGUNCm9mZnNldCBpcyBleHByZXNzZWQgaW4g dW5pdHMgb2Ygc2FtcGxlLXBhaXJzLiAgRm9yIHRoZSAxMC1iaXQNCnF1YW50 aXphdGlvbiwgc2FtcGxlLXBhaXJzIG9jY3VweSA0MCBiaXRzICg1IG9jdGV0 cykgc28gdGhlDQpmcmFnbWVudGF0aW9uIGRvZXMgb2NjdXIgb24gYW4gb2N0 ZXQgYm91bmRhcnkgYnV0IG5vdCBuZWNlc3NhcmlseSBvbiBhDQozMi1iaXQg Ym91bmRhcnkuDQoNClRoZSBzY2FuIGxpbmUgYW5kIHNjYW4gb2Zmc2V0IGZp ZWxkcyBhcmUgbGFyZ2UgZW5vdWdoIHRvIGFjY29tbW9kYXRlDQpncm93dGgg YmV5b25kIHRoZSBwaWN0dXJlIHNpemVzIGN1cnJlbnRseSBkZWZpbmVkIGlu IEJULjYwMS01LCBidXQNCnR5cGUgZmllbGQgdmFsdWVzIGFyZSBvbmx5IGRl ZmluZWQgZm9yIHRoZSBjdXJyZW50bHkgZGVmaW5lZCBzaXplcy4NCk1pY2hh ZWwgU3BlZXIgYXNrZWQgYWJvdXQgc3VwcG9ydCBmb3IgcHJvZ3Jlc3NpdmUg c2NhbiwgYnV0IHRoYXQncyBub3QNCmNvdmVyZWQgYmVjYXVzZSBpdCdzIG5v dCBkZWZpbmVkIGluIEJULjY1Ni4NCg0KVGhpcyBkcmFmdCBpcyBub3cgcmVh ZHkgZm9yIHdvcmtpbmctZ3JvdXAgbGFzdCBjYWxsIGFuZCB0aGVuIExhc3Qg Q2FsbA0KZm9yIHB1YmxpY2F0aW9uIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQu DQoNClNsaWRlczoJZnRwOi8veGsxMC53ZmEuZGlnaXRhbC5pZS9wdWIvaWV0 Zi9idDY1Ni0yLnBwdA0KDQoNCjUuNCAgUmV2aXNlZCBKUEVHIHZpZGVvIHBh eWxvYWQgZm9ybWF0DQoNClRoZSBwYXlsb2FkIGZvcm1hdCBmb3IgSlBFRyB2 aWRlbyB3YXMgcHVibGlzaGVkIGluIFJGQzIwMzUgaW4gT2N0b2Jlcg0KMTk5 NiBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkLiAgQSBwcm9wb3NhbCB0byByZXZp c2UgdGhlIHBheWxvYWQgZm9ybWF0DQpoYXMgcmVjZW50bHkgYmVlbiBwb3N0 ZWQgYXMgZHJhZnQtaWV0Zi1hdnQtanBlZy1uZXctMDAudHh0IGFuZCAucHMN CmJhc2VkIG9uIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2Ugc2luY2UgdGhl bi4gIEJpbGwgRmVubmVyIHJldmlld2VkDQp0aGUgY2hhbmdlcyB3aGljaCBm YWxsIGludG8gdGhyZWUgYXJlYXM6IGludGVybGFjZSBzdXBwb3J0LCByZXN0 YXJ0DQptYXJrZXJzLCBhbmQgaW4tYmFuZCBxdWFudGl6YXRpb24gdGFibGUg c3VwcG9ydC4NCg0KRWFybHkgZHJhZnRzIG9mIHRoZSBwYXlsb2FkIGZvcm1h dCBiZWZvcmUgUkZDIHB1YmxpY2F0aW9uIGluY2x1ZGVkDQpzdXBwb3J0IGZv ciBpbnRlcmxhY2VkIHZpZGVvLCBidXQgaXQgd2FzIHJlbW92ZWQgYmVjYXVz ZSBvZiBwcm9ibGVtcw0Kd2l0aCBpbnRlcmxhY2VkIGZvcm1hdHMgb24gcHJv Z3Jlc3NpdmUtc2NhbiBkaXNwbGF5cyBtZWFudCB0aGVyZSB3YXMNCm5vdCBj b25zZW5zdXMgb24gaXRzIGluY2x1c2lvbi4gIFRoaXMgcmV2aXNpb24gcmVz dXJyZWN0cyBzdXBwb3J0IGZvcg0KaW50ZXJsYWNlZCBzY2FuIHNpbmNlIGl0 IGlzIG5vdyBzZWVuIHRvIGJlIG5lZWRlZCBmb3Igc3lzdGVtcyB1c2luZw0K aW50ZXJsYWNlZCBkaXNwbGF5cy4gIEluc3RlYWQgb2YgZGVkaWNhdGluZyBi aXRzIGluIHRoZSAidHlwZSIgZmllbGQNCnRvIGluZGljYXRlIGludGVybGFj ZSwgY29kZXMgYXJlIGRlZmluZWQgaW4gdGhlICJ0eXBlLXNwZWNpZmljIGZp ZWxkIg0KZm9yIHR5cGVzIGZvciB3aGljaCBpbnRlcmxhY2UgaXMgdXNlZnVs LiAgQW4gYWRkZWQgZmVhdHVyZSBpcyB0aGUNCmFiaWxpdHkgdG8gaW5kaWNh dGUgYSBzaW5nbGUgZmllbGQgd2hpY2ggc2hvdWxkIGJlIGxpbmUtZG91Ymxl ZCBmb3INCmRpc3BsYXkuDQoNClN1cHBvcnQgZm9yIHJlc3RhcnQgbWFya2Vy cyB3YXMgYSBsYXRlIGFkZGl0aW9uIGJlZm9yZSBwdWJsaWNhdGlvbiBvZg0K UkZDMjAzNSwgYW5kIHRoZSBtZXRob2QgY2hvc2VuIGhhcyBzb21lIGRpc2Fk dmFudGFnZXMuICBJdCBpcyBiZWxpZXZlZA0KdGhhdCBubyBpbXBsZW1lbnRh dGlvbnMgYXJlIHVzaW5nIHR5cGUgY29kZXMgZm9yIHJlc3RhcnQgbWFya2Vy cyBhcw0KY3VycmVudGx5IHNwZWNpZmllZC4gIFRoZSBuZXcgZHJhZnQgZGVk aWNhdGVzIG9uZSBiaXQgb2YgdGhlIHR5cGUNCmZpZWxkIHRvIGluZGljYXRl IHRoZSBwcmVzZW5jZSBvZiByZXN0YXJ0IG1hcmtlcnMgaW4gdGhlIGRhdGEg c2luY2UNCnRoZWlyIHVzZSBpcyBvcnRob2dvbmFsIHRvIHRoZSB0eXBlIHNl bGVjdGlvbi4gIFRoYXQgd291bGQgc2ltcGxpZnkNCnRoZSBhZGRpdGlvbiBv ZiBuZXcgdHlwZXMsIGUuZy4sIGZvciBub24tc3F1YXJlIHBpeGVscy4gIEFs c28sIHRoZQ0KYWRkaXRpb25hbCBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBz dXBwb3J0IHJlc3RhcnRzIGlzIGNhcnJpZWQgaW4gYQ0KNC1ieXRlIG9wdGlv bmFsIGV4dGVuc2lvbiB0byB0aGUgcGF5bG9hZCBmb3JtYXQgaGVhZGVyIHJh dGhlciB0aGFuIGluDQphIDYtYnl0ZSBKUEVHIERSSSBzZWdtZW50IGluIG9y ZGVyIHRvIGtlZXAgdGhlIGRhdGEgMzItYml0IGFsaWduZWQuDQoNClRvIGFs bG93IGR5bmFtaWMgcXVhbnRpemF0aW9uIHRhYmxlcyB0byBiZSBpbmNsdWRl ZCBpbi1iYW5kLA0KcHJldmlvdXNseSB1bnNwZWNpZmllZCB2YWx1ZXMgb2Yg dGhlIFEtZmFjdG9yIGZpZWxkIGluZGljYXRlIHRoYXQgYW4NCm9wdGlvbmFs IHF1YW50aXphdGlvbiB0YWJsZSBoZWFkZXIgZm9sbG93cyB0aGUgcGF5bG9h ZCBmb3JtYXQNCmhlYWRlciAob3IgcmVzdGFydCBtYXJrZXIgaGVhZGVyLCBp ZiBwcmVzZW50KS4NCg0KVGhlc2UgY2hhbmdlcyBhcmUgYmFja3dhcmQgY29t cGF0aWJsZSB3aXRoIHRoZSBzdWJzZXQgb2YgUkZDMjAzNQ0KYmVsaWV2ZWQg dG8gYmUgaW4gdXNlLiAgQW55b25lIHdobyBoYXMgaW5mb3JtYXRpb24gdG8g dGhlIGNvbnRyYXJ5IGlzDQpyZXF1ZXN0ZWQgdG8gY29tbWVudCBvbiB0aGUg bWFpbGluZyBsaXN0LiAgVGhlIG5ldyBmdW5jdGlvbnMgaGF2ZSBiZWVuDQpp bXBsZW1lbnRlZCB0byB0aGUgZXh0ZW50IHRoYXQgYXZhaWxhYmxlIGNvZGVj cyB3aWxsIHN1cHBvcnQgdGhlbS4NClRoaXMgZHJhZnQgc2hvdWxkIGJlIHJl YWR5IGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0KDQo1LjUgIEZv cndhcmQgRXJyb3IgQ29ycmVjdGlvbiBwYXlsb2FkIGZvcm1hdA0KDQpKb25h dGhhbiBSb3NlbmJlcmcgcHJlc2VudGVkIHRoZSBkcmFmdCBwcm9wb3NhbCBm b3IgYW4gRkVDIHBheWxvYWQNCmZvcm1hdCBnaXZlbiBpbiBkcmFmdC1pZXRm LWF2dC1mZWMtMDEudHh0IHRoYXQgd2FzIHJldmlzZWQgZnJvbSB0aGUNCmZp cnN0IHZlcnNpb24gYmFzZWQgb24gZmVlZGJhY2sgZnJvbSB0aGUgcHJlc2Vu dGF0aW9uIGluIE11bmljaC4gIFRoaXMNCmlzIGEgIm1ldGEiIHBheWxvYWQg Zm9ybWF0IHRvIGFwcGx5IGZvcndhcmQgZXJyb3IgY29ycmVjdGlvbiB1c2lu Zw0KcGFyaXR5LWxpa2UgbWVjaGFuaXNtcyBpbmRlcGVuZGVudCBvZiB0aGUg YmFzZSBtZWRpYSB0eXBlIGFuZCBmb3JtYXQuDQoNCkluIHRoaXMgZHJhZnQs IHJhdGhlciB0aGFuIHVzZSBhbiBSVFAgaGVhZGVyIGV4dGVuc2lvbiwgRkVD IHBhY2tldHMNCmFyZSBpZGVudGlmaWVkIGJ5IGFuIEZFQyBwYXlsb2FkIHR5 cGUgd2hpY2ggaW5kaWNhdGVzIHRoYXQgYW4gRkVDDQpwYXlsb2FkIGhlYWRl ciBpcyBpbnNlcnRlZCBiZXR3ZWVuIHRoZSBSVFAgaGVhZGVyIGFuZCBhbnkg YmFzZSBwYXlsb2FkDQpmb3JtYXQgaGVhZGVyLiAgVGhlIG1lZGlhIHBhY2tl dHMgYXJlIHRyYW5zbWl0dGVkIHVubW9kaWZpZWQgd2l0aA0KdGhlaXIgbm9y bWFsIHBheWxvYWQgdHlwZTsgY29uc2VxdWVudGx5LCByZWNlaXZlcnMgdGhh dCBkbyBub3QNCmltcGxlbWVudCB0aGUgRkVDIHBheWxvYWQgZm9ybWF0IGNh biBpZ25vcmUgdGhlIEZFQyBwYWNrZXRzIGFuZCBqdXN0DQpwcm9jZXNzIHRo ZSBtZWRpYSBwYWNrZXRzLiAgVGhlIFJUUCB0aW1lc3RhbXAgb24gYW4gRkVD IHBhY2tldCBpcyBub3cNCnRoZSBtaW5pbXVtIHRpbWVzdGFtcCBvZiB0aGUg bWVkaWEgcGFja2V0cyBjb3ZlcmVkIGJ5IHRoZSBGRUMgcGFja2V0DQpyYXRo ZXIgdGhhbiB0aGUgWE9SIG9mIHRob3NlIHRpbWVzdGFtcHMuICBXaGlsZSB0 aGlzIG1lYW5zIHRoZQ0KdGltZXN0YW1wIGZvciBhIGxvc3QgcGFja2V0IG1h eSBub3QgYmUgcmVjb3ZlcmVkIGV4YWN0bHksIGl0IGF2b2lkcw0Kd2hhdCB3 b3VsZCBiZSBlc3NlbnRpYWxseSByYW5kb20gdGltZXN0YW1wcyB0aGF0IGlt cGFpciBSVFAgaGVhZGVyDQpjb21wcmVzc2lvbiBhbmQgcHJlY2x1ZGUgdGhl IHVzZSBvZiBSRkMyMTk4IHRvIGNvbWJpbmUgRkVDIHBhY2tldHMgaW4NCndp dGggc3Vic2VxdWVudCBkYXRhIHBhY2tldHMgZm9yIHJlZHVjZWQgcGFja2V0 IG92ZXJoZWFkLiAgU2ltaWxhcmx5LA0KdGhlIHNlcXVlbmNlIG51bWJlciBv ZiBGRUMgcGFja2V0cyBub3cgaGFzIHRoZSBzdGFuZGFyZCBtZWFuaW5nIChv bmUNCm1vcmUgdGhhbiB0aGUgcHJldmlvdXMgcGFja2V0KSByYXRoZXIgdGhh biBiZWluZyBhbiBYT1IuICBUaGUgc2VxdWVuY2UNCm51bWJlciBvZiBhIGxv c3QgcGFja2V0IGNhbiBiZSBkZXRlcm1pbmVkIGVhc2lseSBmcm9tIGl0cyBw cmVjdXJzb3Igb3INCnN1Y2Nlc3Nvci4NCg0KSW4gbW9zdCBjYXNlcywgdGhl IEZFQyBwYXlsb2FkIGhlYWRlciBpcyBvbmx5IDMyIGJpdHMsIGJ1dCBpdCBt YXkgYmUNCmV4dGVuZGVkIHRvIDY0IGJpdHMgaWYgdGhlIHBhdHRlcm4gb2Yg cGFja2V0cyBjb3ZlcmVkIGJ5IHRoZSBGRUMgY29kZQ0KaXMgbG9uZ2VyIHRo YW4gOCAoYWxsb3dpbmcgcGF0dGVybnMgdXAgdG8gbGVuZ3RoIDQwKS4gIFRo ZSBoZWFkZXIgYWxzbw0KaW5jbHVkZXMgZmllbGRzIHRvIHJlY292ZXIgdGhl IGxlbmd0aCBhbmQgcGF5bG9hZCB0eXBlIG9mIHRoZSBtaXNzaW5nDQpwYWNr ZXQuDQoNCkltcGxlbWVudGF0aW9uIG9mIHRoaXMgcGF5bG9hZCBmb3JtYXQg aXMgdW5kZXJ3YXksIGFuZCBzaG91bGQgYmUgZG9uZQ0Kd2VsbCBiZWZvcmUg dGhlIG5leHQgSUVURiBtZWV0aW5nLiAgVGhlIG5leHQgc3RlcHMgYXJlIHRv IHRyeSBzb21lDQppbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgYW5kIHRvIHNw ZWNpZnkgYSBnZW5lcmljIHJlY292ZXJ5IGFsZ29yaXRobS4NCg0KU2xpZGVz OglodHRwOi8vd3d3LmNzLmNvbHVtYmlhLmVkdS9+amRyb3Nlbi9pZXRmX2Zl Yzk1LnBwdA0KCWh0dHA6Ly93d3cuY3MuY29sdW1iaWEuZWR1L35qZHJvc2Vu L2lldGZfZmVjLnBzDQoJaHR0cDovL3d3dy5jcy5jb2x1bWJpYS5lZHUvfmpk cm9zZW4vaWV0Zl9mZWMucGRmDQoNCg0KNS42ICBPcHRpb25zIGZvciBSZXBh aXIgb2YgU3RyZWFtaW5nIE1lZGlhDQoNCkluIE11bmljaCwgQ29saW4gUGVy a2lucyBnYXZlIGEgcHJlc2VudGF0aW9uIHJldmlld2luZyB0aGUgc2V2ZXJh bA0KZXJyb3IgcmVjb3ZlcnkgbWVjaGFuaXNtcyB0aGF0IGhhdmUgYmVlbiB1 c2VkIG9yIHByb3Bvc2VkIGZvciBSVFANCm1lZGlhIHN0cmVhbXMuICBUaGUg cmVjZW50bHkgdXBkYXRlZCBkcmFmdC1pZXRmLWF2dC1pbmZvLXJlcGFpci0w MS50eHQNCmluY2x1ZGVzIGFkZGl0aW9uYWwgcmVmZXJlbmNlcyB0byBwYXBl cnMgb24gdGhlc2UgbWVjaGFuaXNtcyBhbmQNCmV4cGFuZGVkIHJlY29tbWVu ZGF0aW9ucyBmb3Igc2NlbmFyaW9zIGluIHdoaWNoIHRoZSBhbGdvcml0aG1z IG1pZ2h0DQpiZSB1c2VkLiAgQXQgdGhpcyBtZWV0aW5nLCBoZSBicmllZmx5 IHJldmlld2VkIHRoZSBvcGVuIGlzc3VlcyBpbiB0aGUNCmRyYWZ0IGFuZCBh c2tlZCBmb3IgY29tbWVudHMuDQoNClRoZSBwcmltYXJ5IGlzc3VlIGlzIGNv bmdlc3Rpb24gY29udHJvbCBhbmQgYWRhcHRpdml0eSB0byB2YXJpYXRpb25z DQppbiBsb3NzIHJhdGVzIGFuZCBhdmFpbGFibGUgYmFuZHdpZHRoLiAgV2hh dCBpcyBhIHNlbnNpYmxlIG9wZXJhdGluZw0KcG9pbnQgZm9yIGxvc3MgbWl0 aWdhdGlvbiBhbGdvcml0aG1zPyAgSXQgaXMgcHJvYmFibHkgbm90IHJlYXNv bmFibGUNCnRvIHRyeSB0byBhcHBseSB0aGVzZSBtZWNoYW5pc21zIHRvIHJl Y292ZXIgZnJvbSA2MCUgcGFja2V0IGxvc3MuICBJcw0KaXQgcmVhc29uYWJs ZSBmb3IgdGhpcyBkcmFmdCB0byBtYWtlIHNwZWNpZmljIHJlY29tbWVuZGF0 aW9ucyBmb3INCmFjY2VwdGFibGUgdGFyZ2V0IGFuZCBtYXhpbXVtIG92ZXJo ZWFkIGxldmVscz8gIEl0IG1heSBiZSBwb3NzaWJsZSB0bw0KZGVmaW5lIHRo ZSBzZW5zaWJsZSAoZmFpcikgb3BlcmF0aW5nIHBvaW50IGJhc2VkIG9uIHRo ZSBUQ1ANCmVxdWl2YWxlbmNlIGZ1bmN0aW9uIHdoaWNoIGdpdmVzIGFuIGFw cHJveGltYXRpb24gb2YgVENQJ3MgdGhyb3VnaHB1dA0KZm9yIGEgZ2l2ZW4g bG9zcyByYXRlLg0KDQpUaGUgZ29hbCBmb3IgdGhpcyBkcmFmdCBpcyBwdWJs aWNhdGlvbiBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQy4NCg0KDQo1LjcgIE5l dyBHU00gZm9ybWF0cw0KDQpTY290dCBQZXRyYWNrIGhhcyByZXF1ZXN0ZWQg dGhlIGluY2x1c2lvbiBvZiB0d28gbmV3IEdTTSBhdWRpbw0KZW5jb2Rpbmdz IGluIHRoZSByZXZpc2VkIGRyYWZ0IG9mIHRoZSBSVFAgQS9WIFByb2ZpbGUu ICBPbmUgZW5jb2RpbmcsDQpHU00gNi4yMCwgY29uc3VtZXMgaGFsZiB0aGUg ZGF0YSByYXRlIG9mIHRoZSBvcmlnaW5hbCBHU00gNi4xMCBmb3JtYXQsDQph bmQgdGhlIG90aGVyLCBHU00gNi42MCwgcHJvdmlkZXMgaW1wcm92ZWQgcXVh bGl0eSBhdCB0aGUgc2FtZSBkYXRhDQpyYXRlLiAgVGhpcyBhZGRpdGlvbiB0 byB0aGUgcHJvZmlsZSBpcyBzdHJhaWdodGZvcndhcmQuDQoNCg0KNi4gUmVj b3JkaW5nIFJUUCBpbiBBU0YNCg0KRXJpYyBGbGVpc2NobWFuIHN1Ym1pdHRl ZCBkcmFmdC1mbGVpc2NobWFuLWFzZi1ydHAtcmVjb3JkLTAwLnR4dCBpbg0K Tm92ZW1iZXIgdG8gZGVzY3JpYmUgaG93IE1Cb25lIHNlc3Npb25zIGNvbmZv cm1pbmcgdG8gUlRQL0FWUA0KKFJGQzE4OTApIG1heSBiZSB0cmFuc3BhcmVu dGx5IHJlY29yZGVkIGludG8gTWljcm9zb2Z0J3MgQWR2YW5jZWQNClN0cmVh bWluZyBGb3JtYXQgKEFTRikgZmlsZXMuICBTdWNoIGEgcmVjb3JkaW5nIGNv dWxkIG9wdGlvbmFsbHkgYmUNCnJlcGxheWVkIGludG8gYSBzZXNzaW9uIHRv IHNpbXVsYXRlIHRoZSBleGFjdCBzZXF1ZW5jZSBvZiB3aGF0DQpoYXBwZW5l ZCwgaW5jbHVkaW5nIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBzcGVha2Vycy4g IFRoaXMgaXMgcGFydCBvZg0KYSBsYXJnZXIgZWZmb3J0IHRvIGRlZmluZSBo b3cgQVNGIHJlY29yZGluZ3MgbWF5IGJlIGRvbmUgZm9yIGEgdmFyaWV0eQ0K b2YgY29udGV4dHMuDQoNClNvIGZhciwgb25seSBtaW5pbWFsIHByaXZhdGUg Y29tbWVudHMgb24gdGhlIGRyYWZ0IGhhdmUgYmVlbiByZWNlaXZlZC4NClRo ZSB3b3JraW5nIGdyb3VwIGlzIHJlcXVlc3RlZCB0byByZWFkIHRoZSBkcmFm dCBhbmQgcHJvdmlkZSBmZWVkYmFjaw0Kb24gYW55IGltcHJvdmVtZW50cyB0 aGF0IG1pZ2h0IGJlIG5lZWRlZC4NCg0KDQo3LiBXcmFwdXANCg0KRXZlbiB0 aG91Z2ggdGhlcmUgd2FzIGEgbG90IG9mIGdvb2QgZGlzY3Vzc2lvbiBhdCB0 aGlzIG1lZXRpbmcsIG1vcmUNCndvdWxkIGhhdmUgYmVlbiB2YWx1YWJsZSBi dXQgd2UgcmFuIG91dCBvZiB0aW1lLiAgU3RldmUgQ2FzbmVyIHdpbGwNCmNv bGxlY3QgdGhlIGFjdGlvbiBpdGVtcyBmcm9tIHRoaXMgbWVldGluZyBhbmQg YnJpbmcgdGhlbSB1cCBvbiB0aGUNCndvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0IHdoZXJlIGl0IGlzIGNyaXRpY2FsIGZvciB0aGlzIGltcG9ydGFudA0K ZGlzY3Vzc2lvbiB0byBjb250aW51ZS4gIFRoZSBnb2FsIGlzIHRvIGhhdmUg bW9zdCBvZiB0aGVzZSBpc3N1ZXMNCnJlc29sdmVkIGJ5IHRoZSBuZXh0IG1l ZXRpbmcgaW4gTWFyY2guDQo= --11353260-15213-885858118=:-183571-- From rem-conf Mon Jan 26 21:21:04 1998 From rem-conf-request@es.net Mon Jan 26 21:21:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xx3O7-00049W-00; Mon, 26 Jan 1998 21:16:43 -0800 Date: Mon, 26 Jan 1998 21:16:12 -0800 (PST) From: "T. Todd Elvins" To: scwpf@sdsc.edu, web-watchers -- K Claffy , rem-conf@es.net, webteam@qualcomm.com, webheads@sio.ucsd.edu, java-ucsd@mib.org, flesner@nosc.mil, talks@ucsd.edu, cse-talks@cs.UCSD.EDU Cc: Greg Johnson Subject: Wednesday night Forum - Reminder - MBONE Broadcast Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Southern California Web Programmers Forum Meeting Agenda Date: January 28, 1998 Time: 7:00PM San Diego Supercomputer Center Invited Speakers Kelly Looney (VP of Marketing) and Mark Gaither (Senior Technical Staff) >from Activerse, Inc. "The Most Interesting Thing on the Internet: People" Realtime network presence is changing the Internet. "The Web's primary focus has been one of people accessing information. Over the next 12 months, look for the first signs of a fundamental shift. Instead of people accessing information, the Web's focus will shift toward people accessing other people in an information-rich environment". -- Paul Saffo, Director of the Institute for the Future Kelly and Mark will present two new software products, Ding! and Ding! Switchboard. Ding! was chosen as one of the "125 best software titles available in the market today" in the Winter '98 issue of Your New PC, a special publication from the editors of PC Magazine. These two products which constitute the first all-Java Internet/intranet instant collaboration system. Speaker #2 T. Todd Elvins (Staff Scientist) >from the San Diego Supercomputer Center SD Bay Project "Using Java to Control VRML" Todd will demonstrate a 3D GIS application constructed using a Java applet to trigger changes in VRML content. Java and VRML were integrated using the Extended Authoring Interface (EAI) to create BAYVIEW, a 3D virtual environmental. ========================================================== For parking and directions see http://www.sdsc.edu/scwpf ----------------------------------------------------------------- T. Todd Elvins, Ph.D. todd@sdsc.edu Science Department, San Diego Supercomputer Center University of California, San Diego (619) 534-5128 P.O. Box 85608 FAX (619) 534-5117 San Diego, CA 92186-9784 http://www.sdsc.edu/~todd/ ----------------------------------------------------------------- From rem-conf Tue Jan 27 00:48:29 1998 From rem-conf-request@es.net Tue Jan 27 00:48:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xx6dt-0005Kz-00; Tue, 27 Jan 1998 00:45:13 -0800 X-Authentication-Warning: listbox2.cern.ch: Host pcitcs04.cern.ch [137.138.33.126] claimed to be cern.ch Message-ID: <34CD9E3C.8D486F5D@cern.ch> Date: Tue, 27 Jan 1998 09:43:40 +0100 From: Miguel CHAMOCHIN GOMEZ Organization: CERN X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Scott Petrack , "rem-conf@es.net" Subject: Re: Is there a tool for exact recording of received RTP streams? References: <42256598.00554AA1.00@il4.vocaltec.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Scott Petrack wrote: > > Is there a tool (public domain or otherwise) which stores a received RTP > stream on disk, including the precise time at which each packet was > received, in such a way that the receipt of the RTP can be exactly > "re-enacted" at a later point in time (inlcuding all the jitter, etc.). See http://csvod1.cern.ch/ "wrtp project". Wrtp application maintain a index file with that information. Best regards. -- Miguel Angel Chamochin Gomez Information Technology Division CERN CH-1211 Geneve 23 SWITZERLAND Phone: +41-22-767-9703 Fax: +41-22-767-7155 e-mail: mangel@mail.cern.ch Miguel.Chamochin@cern.ch --- "Would you tell me, please, which way I ought to go from here?" "That depends a good deal on where you want to get to." - Lewis Carrol, Alice in Wonderland ----- From rem-conf Tue Jan 27 10:23:49 1998 From rem-conf-request@es.net Tue Jan 27 10:23:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxFQY-0000k8-00; Tue, 27 Jan 1998 10:08:02 -0800 Message-ID: <19980127100754.45360@caida.org> Date: Tue, 27 Jan 1998 10:07:54 -0800 From: k claffy To: rem-conf@es.net Cc: jay@sdsc.edu, hutton@sdsc.edu, gjohnson@sdsc.edu, Tracie Monk , don Subject: Stephen Spielberg's Survivors of the Shoah Visual History Foundation" - 1/27/98 Presentation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64e X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (will say 'shoah foundation' in sdr) DIGITAL ASSET MANAGEMENT AT STEPHEN SPIELBERG'S SURVIVORS OF THE SHOAH VISUAL HISTORY FOUNDATION: University of California, San Diego: On Tuesday, January 27, from 4:00 to 6:00 p.m. in the Auditorium of the San Diego Supercomputer Center on the UCSD campus, the National Laboratory for Advanced Network Research (NLANR) will sponsor a presentation on the development of advanced technology to obtain and preserve the testimonies of tens of thousands of survivors of the Holocaust all over the world. The presentation is titled Digital Asset Management at the Survivors of the Shoah Visual History Foundation The speaker will be Sam Gustman, Director of Technology at the Shoah Foundation. He will demonstrate the advanced technology being used for the Foundation's undertaking. "Shoah" is the Hebrew word for the Holocaust. The Survivors of the Shoah Visual History Foundation was founded by Hollywood director Steven Spielberg in 1994. It is a nonprofit organization dedicated to videotaping and archiving interviews of Holocaust survivors all over the world. The purpose of collecting the testimonies is to foster the teaching of racial, ethnic, and cultural tolerance in schools and public organizations around the world. More than 40,000 testimonies have already been collected on videotape in 29 different languages, comprising the collective experience of Jews and non-Jews alike who emerged from Hitler's concentration camps and from hiding places all over Europe at the end of World War II. Gustman and the staff of the Shoah Foundation are putting together the complex system for scheduling, digitizing, cataloguing, and distributing the testimonies. "At present," he says, "we expect the archive to grow to more than 150 terabytes of MPEG-encoded video. We will deliver these testimonies over proprietary and government ATM networks to five Holocaust memorial institutions around the world, which will serve as primary repositories. We are eager to share our plans with the best developers and leaders in advanced digital technology and data archiving, and we are seeking collaborations with them to help make our repository permanently and easily available to people all over the world." Gustman notes that the Foundation works with the world's leading Holocaust museums, educators, archivists, and documentary film makers. The compilation will be the most comprehensive library of survivor testimony ever assembled. "By preserving the eyewitness testimonies of tens of thousands of Holocaust survivors, the Foundation will enable future generations to learn the lessons of this devastating period in human history from those who survived," Gustman says. To access the Shoah Foundation on the web, see http://www.vhf.org. From rem-conf Tue Jan 27 11:18:08 1998 From rem-conf-request@es.net Tue Jan 27 11:18:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxGTs-0001j8-00; Tue, 27 Jan 1998 11:15:32 -0800 Date: Tue, 27 Jan 1998 11:14:13 -0800 (Pacific Standard Time) From: Stephen Casner To: rem-conf@es.net Subject: Re: Minutes of AVT meeting in Washington DC In-Reply-To: Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am not sure why my text/plain attachment of the AVT meeting minutes was encoded BASE64. Since that has caused trouble for some people, here's a URL instead: ftp://hydra.precept.com/pub/rtp/minutes.97dec > Here are the somewhat lengthy minutes of the AVT meeting at the 40th > IETF in Washington, DC in December. Any comments or corrections are > welcome. > -- Steve From rem-conf Wed Jan 28 00:30:43 1998 From rem-conf-request@es.net Wed Jan 28 00:30:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxSo5-0006iu-00; Wed, 28 Jan 1998 00:25:13 -0800 From: wichadak@students.uiuc.edu Message-Id: <3.0.5.32.19980128022544.00849370@students.uiuc.edu> X-Sender: wichadak@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 28 Jan 1998 02:25:44 -0600 To: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Wed Jan 28 08:10:35 1998 From rem-conf-request@es.net Wed Jan 28 08:10:34 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxZuO-0001Hr-00; Wed, 28 Jan 1998 08:00:12 -0800 From: Tom Zoerner Message-Id: <199801281600.RAA25466@faui01.informatik.uni-erlangen.de> Subject: FEC draft and timestamp recovery To: rem-conf@es.net Date: Wed, 28 Jan 1998 17:00:06 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi. I'm still having trouble with the way the FEC draft handles timestamps. Specifically with the fact that FEC masks operate on sequence numbers; when a packet of a certain payload type is missing, I don't know it's sequence number though - in general I only know the timestamp. That however is not directly recoverable by FEC packets. The draft says in chapter 5.3 Recovery Procedures: "The timestamp for xi is computed by any reasonable approximation, at the discretion of the implementor." Is this meant to suggest that this is trivial? Because I really don't think so: Let's assume the last packet I received of my main payload type had sequence number n and timestamp ts. Let's also assume I haven't received any later packets from that payload type, so there's no way to guess the sequence numer of the missing packet. It could be n+1, but also n+2 if there was a FEC or other payload type inbetween (that also got lost). Now let's assume I had received a FEC packet n+3 with mask 0x1010 and timestamp ts. So I know that packet encodes packets n and n+2 - but how do I know if n+2 contained ts+td or ts+2*td? In case of audio it would be quite important to know the timestamp, since it directly determines the position in the playout queue. In the above scenario: at ts+td, do I have to do error concealment for a missing packet (n+1), or do I immediately play out the recovered n+2. Maybe we do need that XOR of all timestamps afterall? Or simply disallow all masks with gaps, i.e. zeroes inbetween ones in the mask (that'd be a serious restriction) -tom From rem-conf Wed Jan 28 10:46:40 1998 From rem-conf-request@es.net Wed Jan 28 10:46:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxcGe-0002s3-00; Wed, 28 Jan 1998 10:31:20 -0800 Message-ID: <34CFA4B4.4CD7@ctr.columbia.edu> Date: Wed, 28 Jan 1998 13:35:48 -0800 From: "Andrew T.Campbell" Reply-To: campbell@ctr.columbia.edu Organization: Center for Telecommunications Research, Columbia University X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: ieeetcpc@ccvm.sunysb.edu, hipparch@sophia.inria.fr, rem-conf@es.net, commsoft@cc.bellcore.com, multicomm@cc.bellcore.com CC: campbell@ctr.columbia.edu Subject: IEEE OPENARCH'98 PROGRAM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list First IEEE Conference on Open Architectures and Network Programming San Francisco, CA, USA, April 3-4, 1998 http://comet.columbia.edu/openarch/ PROGRAM AT A GLANCE: KEYNOTES: Mike Nelson, Federal Communications Commission Bill Edwards, MCI Worldcom INVITED SESSIONS: Research Frontiers in OPEN Architectures -- Speaker: Louis-Francois Pau, Ericsson Utvecklings Research Frontiers in Network Programming -- Speaker: David L. Tennenhouse, DARPA and MIT TECHNICAL SESSIONS: Architectures and Performance -- Chair: Chuck Kalmanek, AT&T Labs - Research Open Signalling -- Chair: Giovanni Pacifici, IBM T.J. Watson Research Center Open Service Management -- Chair: Amit Gupta, Sun Microsystems Protocols -- Chair: Andrew Thomas, HP Labs Work in Progress -- Chair: Tom Laporta, Bell Labs - Lucent Technologies Active Networks -- Chair: Raj Yavatkar, Intel CONFERENCE PANEL: Active Networks and/or Broadband Kernels? -- Chair: Aurel A. Lazar, Columbia University FOR FULL DETAILS OF THE OPENARCH'98 PROGRAM AND REGISTRATION: http://comet.columbia.edu/openarch/ From rem-conf Wed Jan 28 11:06:27 1998 From rem-conf-request@es.net Wed Jan 28 11:06:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxciV-0003IE-00; Wed, 28 Jan 1998 11:00:07 -0800 Message-ID: <34CF7F6E.FE25517D@dnrc.bell-labs.com> Date: Wed, 28 Jan 1998 13:56:46 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Tom Zoerner CC: rem-conf@es.net Subject: Re: FEC draft and timestamp recovery References: <199801281600.RAA25466@faui01.informatik.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Tom Zoerner wrote: > I'm still having trouble with the way the FEC draft handles timestamps. > Specifically with the fact that FEC masks operate on sequence numbers; > when a packet of a certain payload type is missing, I don't know it's > sequence number though - in general I only know the timestamp. That however > is not directly recoverable by FEC packets. The draft says in chapter 5.3 > Recovery Procedures: "The timestamp for xi is computed by any reasonable > approximation, at the discretion of the implementor." Is this meant to > suggest that this is trivial? Because I really don't think so: > > Let's assume the last packet I received of my main payload type had > sequence number n and timestamp ts. Let's also assume I haven't received > any later packets from that payload type, so there's no way to guess the > sequence numer of the missing packet. It could be n+1, but also n+2 if > there was a FEC or other payload type inbetween (that also got lost). > > Now let's assume I had received a FEC packet n+3 with mask 0x1010 and > timestamp ts. So I know that packet encodes packets n and n+2 - but how > do I know if n+2 contained ts+td or ts+2*td? Excellent point. In the original draft, the sequence number space for the media packets was distinct. The FEC packets had a SN which was the minimum of the SN in the media packets it protected. Because of this, you could compute the timestamp for a recovered media packet by interpolating from adjacent packets. The change to using the same sequence space has clearly broken this. > Maybe we do need that XOR of all timestamps afterall? Or simply disallow > all masks with gaps, i.e. zeroes inbetween ones in the mask (that'd be a > serious restriction) It seems there are a number of deficiencies as currently defined with the current SN/TS method: 1. You cannot recover the TS of the packet, as you point out, which is needed for playout. 2. You must send the original media packets (systematic codes only), eliminating some of the schemes in Budge's draft. 3. In multicast, a non-FEC receiver will discard the FEC packets since the PT are unknown. However, it will probably be confused, since it will see gaps in the sequence number space, and think there is a loss of real data. However, if it uses the timestamps to fill-in the required amount of missing data, it will find that there are no gaps. This is a consequence of the media sequence number space being "interrupted" by FEC. 4. There is no clean way to send the FEC on a separate multicast group. This is because its SN space is intermingled with the media. If you send the FEC on a separate group, its probably a good idea for it to have its own SN space. I see several possible fixes: 1. Include an additional 32 bit field in the FEC header for timestamp reconstruction, as you suggest. This fixes (1), but none of the others. 2. Go back to the original proposal. This proposal specified that the SN in the FEC was the minimum of the media packets is was protecting. The TS was the xor of the TS of the packets it was protecting. This fixes (1) and (2), but having packets show up with non-sequential,duplicated SN will cause confusion. It also has problems with header compression. 3. Require the FEC to always be sent as a separate stream. It uses its own sequence number space. The FEC header contains an additional 16 bit SN base field, which indicates the base that the mask is applied to. The SN that the base/mask are referring to are those for the media packets. The media packets are sent completely normally. The TS in the FEC packets is set to the minimum TS of all packets it protects. We can also add a 32 bit TS reconstruction field into the FEC header, which is the xor of the TS in the media packets. This seems to solve all four problems above. It should also work well for RTP compression, since this way the FEC appear as a separate context. You can even still include the FEC data piggybacked onto the media using the redundant codec payload format, if you like. I am tending to lean towards solution (3). -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (732) 949-6418 Rm. 4C-526 FAX: (732) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Wed Jan 28 11:07:02 1998 From rem-conf-request@es.net Wed Jan 28 11:07:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxcm9-0003KQ-00; Wed, 28 Jan 1998 11:03:53 -0800 Date: Wed, 28 Jan 1998 11:02:36 -0800 (Pacific Standard Time) From: Stephen Casner To: rem-conf@es.net Subject: Working group last call on BT.656 and JPEG Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: Two RTP payload format Internet-Drafts were presented at the Washington IETF meeting and were said to be ready to go to working group last call. Therefore, this is a request for last call for comments on: draft-tynan-rtp-bt656-01.txt for BT.656-3 uncompressed video draft-ietf-avt-jpeg-new-00.txt and .ps for motion-JPEG video The first is a new payload format; the second is a revision of RFC2035 which makes functional changes (improvements!), so it will "cycle in grade". Each of these drafts needs a small addition before publication: the BT656 draft needs to have a security considerations section added (can be copied from anoter recent payload format draft), and the JPEG draft needs to have a "changes" section or appendix to summarize the changes (since it is already on the standards track). Since these are simple additions, I think that the working group last call can proceed without them and then any comments can be folded into a revision to go to the IESG. Barring any problems with these drafts, in two weeks I will request IESG Last Call for publication of these drafts as Proposed Standards. -- Steve From rem-conf Wed Jan 28 15:02:00 1998 From rem-conf-request@es.net Wed Jan 28 15:02:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxgPb-0006A9-00; Wed, 28 Jan 1998 14:56:51 -0800 From: keith@comm.toronto.edu (Keith Chow) Message-Id: <199801282256.RAA18042@tesla.comm.toronto.edu> Subject: Question on RTP availability. To: rem-conf@es.net Date: Wed, 28 Jan 1998 17:56:18 -0500 X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Is there any work going on providing RTP as a standard protocol with the OS? Linux? Solaris? Irix? or even Windows? I believe it would be very helpful in developing application. But by doing so, we might need to modify the existing Socket API. Any comment? Keith. ----------------------------------------------- Keith HungKei Chow Network Architecture Lab, Communication Group, Department of Electrical & Computer Engineering University of Toronto Ontario, Canada. ----------------------------------------------- From rem-conf Thu Jan 29 01:23:27 1998 From rem-conf-request@es.net Thu Jan 29 01:23:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxpwb-0001yK-00; Thu, 29 Jan 1998 01:07:33 -0800 To: Jonathan Rosenberg cc: Tom Zoerner , rem-conf@es.net Subject: Re: FEC draft and timestamp recovery In-reply-to: Your message of "Wed, 28 Jan 1998 13:56:46 EST." <34CF7F6E.FE25517D@dnrc.bell-labs.com> Date: Thu, 29 Jan 1998 09:07:18 +0000 Message-ID: <706.886064838@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <34CF7F6E.FE25517D@dnrc.bell-labs.com>Jonathan Rosenberg writes: > Tom Zoerner wrote: > > > I'm still having trouble with the way the FEC draft handles timestamps. > > Specifically with the fact that FEC masks operate on sequence numbers; > > when a packet of a certain payload type is missing, I don't know it's > > sequence number though - in general I only know the timestamp. That however > > is not directly recoverable by FEC packets. The draft says in chapter 5.3 > > Recovery Procedures: "The timestamp for xi is computed by any reasonable > > approximation, at the discretion of the implementor." Is this meant to > > suggest that this is trivial? Because I really don't think so: > > > > Let's assume the last packet I received of my main payload type had > > sequence number n and timestamp ts. Let's also assume I haven't received > > any later packets from that payload type, so there's no way to guess the > > sequence numer of the missing packet. It could be n+1, but also n+2 if > > there was a FEC or other payload type inbetween (that also got lost). > > > > Now let's assume I had received a FEC packet n+3 with mask 0x1010 and > > timestamp ts. So I know that packet encodes packets n and n+2 - but how > > do I know if n+2 contained ts+td or ts+2*td? > > Excellent point. In the original draft, the sequence number space for > the media packets was distinct. The FEC packets had a SN which was the > minimum of the SN in the media packets it protected. Because of this, > you could compute the timestamp for a recovered media packet by > interpolating from adjacent packets. The change to using the same > sequence space has clearly broken this. For simple cases you can get around this problem by observation, if you take an fec coded stream you can reasonably assume that the media data and fec data occurs at predictable intervals. As long as you are not still observing the first cycle of media/fec data then you can predict what n+1 and n+2 should have been. Where this fails is where your fec arises from a joint/source coding, i.e where your fec arises after some classification of your media stream and is no longer predictably placed. > It seems there are a number of deficiencies as currently defined with > the current SN/TS method: > > 1. You cannot recover the TS of the packet, as you point out, which is > needed for playout. > 2. You must send the original media packets (systematic codes only), > eliminating some of the schemes in Budge's draft. > 3. In multicast, a non-FEC receiver will discard the FEC packets since > the PT are unknown. However, it will probably be confused, since it will > see gaps in the sequence number space, and think there is a loss of real > data. However, if it uses the timestamps to fill-in the required amount > of missing data, it will find that there are no gaps. This is a > consequence of the media sequence number space being "interrupted" by > FEC. > 4. There is no clean way to send the FEC on a separate multicast group. > This is because its SN space is intermingled with the media. If you send > the FEC on a separate group, its probably a good idea for it to have its > own SN space. > > I see several possible fixes: > > 1. Include an additional 32 bit field in the FEC header for timestamp > reconstruction, as you suggest. This fixes (1), but none of the others. > 2. Go back to the original proposal. This proposal specified that the SN > in the FEC was the minimum of the media packets is was protecting. The > TS was the xor of the TS of the packets it was protecting. This fixes > (1) and (2), but having packets show up with non-sequential,duplicated > SN will cause confusion. It also has problems with header compression. > 3. Require the FEC to always be sent as a separate stream. It uses its > own sequence number space. The FEC header contains an additional 16 bit > SN base field, which indicates the base that the mask is applied to. The > SN that the base/mask are referring to are those for the media packets. > The media packets are sent completely normally. The TS in the FEC > packets is set to the minimum TS of all packets it protects. We can also > add a 32 bit TS reconstruction field into the FEC header, which is the > xor of the TS in the media packets. This seems to solve all four > problems above. It should also work well for RTP compression, since this > way the FEC appear as a separate context. You can even still include the > FEC data piggybacked onto the media using the redundant codec payload > format, if you like. > > I am tending to lean towards solution (3). I favour (3). - Orion Orion Hodson [Research Student] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, UK. Tel: (0)171 419 3704. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From rem-conf Thu Jan 29 05:26:49 1998 From rem-conf-request@es.net Thu Jan 29 05:26:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxtq3-0003ML-00; Thu, 29 Jan 1998 05:17:03 -0800 X-Authentication-Warning: argo.comet.columbia.edu: mk owned process doing -bs Date: Thu, 29 Jan 1998 08:16:54 -0500 (EST) From: Michael Kounavis To: rem-conf@es.net cc: mnl@comet.columbia.edu Subject: MBone Broadcast announcement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement Title: Scalable bandwidth allocation in the Internet Speaker: Zheng Wang, Bell Labs Lucent Technologies Date: Thursday, Jan. 29, 1997 Time: 11:00 AM - 12:00 AM EST Multicast Address: audio: DVI, RTP, 224.2.177.25/31716 , ttl=127 Contact: Michael Kounavis URL: http://www.comet.columbia.edu/activities/seminars/spring98 Place: Interschool Laboratory Schapiro Research Building Center for Telecommunications Research Columbia University New York City, USA Abstract: In this talk, I present a new differentiated service scheme called "User-Share Differentiation (USD)". The USD scheme is based on the principle of link sharing. The scheme allows ISPs to differentiate traffic flows on a per-user basis, providing virtual leased lines and proportional fair sharing. I first look at the lessons we learnt from the best effor and int-serv models, and the problems with the current proposals, then present the details of the USD scheme. Finally I examine the implementation and standardization issues ----------------------------------------------------------------------- Michael E. Kounavis e-mail : mk@comet.columbia.edu Room 801, CEPSR www : http://www.comet.columbia.edu/~mk/ Columbia University office : (212) 854-6900 New York, NY 10025 lab : (212) 854-5599 ----------------------------------------------------------------------- From rem-conf Thu Jan 29 05:32:35 1998 From rem-conf-request@es.net Thu Jan 29 05:32:35 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxu2d-0003WD-00; Thu, 29 Jan 1998 05:30:03 -0800 Message-ID: <34D0839E.8B170A9D@dnrc.bell-labs.com> Date: Thu, 29 Jan 1998 08:26:54 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Orion Hodson CC: Tom Zoerner , rem-conf@es.net Subject: Re: FEC draft and timestamp recovery References: <706.886064838@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Orion Hodson wrote: > > > > you could compute the timestamp for a recovered media packet by > > interpolating from adjacent packets. The change to using the same > > sequence space has clearly broken this. > > For simple cases you can get around this problem by observation, if > you take an fec coded stream you can reasonably assume that the media > data and fec data occurs at predictable intervals. As long as you are > not still observing the first cycle of media/fec data then you can > predict what n+1 and n+2 should have been. > > Where this fails is where your fec arises from a joint/source coding, > i.e where your fec arises after some classification of your media > stream and is no longer predictably placed. Packet losses may also make this kind of classification hard. The reconstruction mechanisms should be "stateless" I think; stateless here meaning that a single packet contains sufficient information to tell you what to do with it, without requiring other packets to direct behavior. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (732) 949-6418 Rm. 4C-526 FAX: (732) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jan 29 06:32:17 1998 From rem-conf-request@es.net Thu Jan 29 06:32:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxuvT-0004SP-00; Thu, 29 Jan 1998 06:26:43 -0800 Message-Id: <199801291425.GAA26217@iceland.it.earthlink.net> Subject: Fwd: Re: [MC] dog the wag Date: Thu, 29 Jan 98 06:35:48 -0000 x-mailer: Claris Emailer 2.0, March 15, 1997 From: ALICE Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ---------------- Begin Forwarded Message ---------------- Date: 01/29 11:30 AM Received: 01/29 5:38 AM From: Kite-a-holic, revcoal@connix.com To: Francis L. Regan, billywompus@juno.com CC: mindcontrol-l@sonic.net On Wed, 28 Jan 1998, Francis L. Regan wrote: >In the new movie, Wag the Dog, spin doctors create a war to distract >attention from a sex scandal involving their president. People have said >it is interesting how filmmakers could have anticipated a sex scandal and >an impending war and finished a movie before any of it broke in the >news. However, something else might be going on. These guys (I hate >not citing my sources, but i'm in kind of a hurry and can't remember) You CAN'T REMEMBER people who claim to know the President and made substantial campaign contributions????? >know the president and have donated decent amounts of money to his >campaign. What if the president is planning a war with Iraq as the spark >for world war III, and needs a distraction until it can get off the >ground? He could have asked his friends to make a movie suggesting the >opposite. This would also help explain the first lady's lack of flipping >out about this. I was thinking this yesterday, first off in the morning when NBC News was reporting that the U.S. is seriously considering using nuclear weapons against Iraq, and again last night when it was reported that Congress 'just happens' to be voting today (Thursday) on whether to back Clinton in his 'Iraq initiative', and it was stated it WOULD vote to support Clinton by an overwhelming majority... At that point, I became sure that this Lewinsky thing is the smoke and mirrors to divert the public's attention AWAY from the obvious steps being taken to initiate a war... June :-7 /\ \/ / Q / |-+/ / \ --ahjt Go fly a kite ! It's fun! X-NO-ARCHIVE: YES ************************************************************** MINDCONTROL-L Mind Control and Psyops Mailing List To unsubscribe or subscribe: send a message to majordomo@sonic.net with the following text: "unsubscribe MINDCONTROL-L" or "subscribe MINDCONTROL-L". Post to: MINDCONTROL-L@mail.sonic.net. Wes Thomas , list moderator ----------------- End Forwarded Message ----------------- From rem-conf Thu Jan 29 06:34:19 1998 From rem-conf-request@es.net Thu Jan 29 06:34:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxuzZ-0004Y2-00; Thu, 29 Jan 1998 06:30:57 -0800 Message-Id: <199801291429.JAA28158@prima.time.saic.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Jonathan Rosenberg cc: Orion Hodson , Tom Zoerner , rem-conf@es.net Subject: Re: FEC draft and timestamp recovery In-reply-to: Your message of "Thu, 29 Jan 1998 08:26:54 EST." <34D0839E.8B170A9D@dnrc.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Jan 1998 09:29:28 -0500 From: Ken Carlberg X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > 3. Require the FEC to always be sent as a separate stream. perhaps i missed something in the thread, but the above statement makes me think that one produces a domino effect in that a new problem arises in having to ensure that separate streams receive the same service -- e.g., end-to-end delay bounds. feel free to correct me, but an important attribute of FEC packets is that they arrive when the original packets are received. but this problem gets hard(er) when the streams are traversing transit networks that operate under best effort service and yet use a variety of queueing and congestion avoidance strategies (CBQ, W-RED, WFQ, F-RED, etc.). one could provide a counter arguement that integrated, and perhaps differentiated (depending on how it is realized), services can deal with this problem. but that assumes that these services will be populated throughout the internet. from a more extreme perspective, leaf subnets that have (TDMA/FDMA) links would probably still have a hard time 'synchronizing' streams whose packets vary widely in size. please understand, i think that there are some appealing aspects about placing the fec packets in another stream. but i guess what i'm wondering aloud is...are we setting ourselves up for another problem if we use what amounts to an out-of-band means of sending fec packets? just my $0.02, -ken From rem-conf Thu Jan 29 08:02:20 1998 From rem-conf-request@es.net Thu Jan 29 08:02:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxwI3-0005vF-00; Thu, 29 Jan 1998 07:54:07 -0800 Message-ID: <34D0A578.C5EBD97C@dnrc.bell-labs.com> Date: Thu, 29 Jan 1998 10:51:20 -0500 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Ken Carlberg CC: Orion Hodson , Tom Zoerner , rem-conf@es.net Subject: Re: FEC draft and timestamp recovery References: <199801291429.JAA28158@prima.time.saic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ken Carlberg wrote: > > > 3. Require the FEC to always be sent as a separate stream. > > perhaps i missed something in the thread, but the above statement > makes me think that one produces a domino effect in that a new problem > arises in having to ensure that separate streams receive the same > service -- e.g., end-to-end delay bounds. > > feel free to correct me, but an important attribute of FEC packets > is that they arrive when the original packets are received. but > this problem gets hard(er) when the streams are traversing transit > networks that operate under best effort service and yet use a variety > of queueing and congestion avoidance strategies (CBQ, W-RED, WFQ, > F-RED, etc.). > With the current best effort service model, packets may arrive late, early, out of order, or never. Playout buffers and such things are used to deal with these problems. Thus, the current working assumption is that there are no "bounds" on the delay jitter between FEC and data packets anyway. I don't think the service you would get from W-RED, RED, or F-RED would be substantially different. All of those are still FCFS, so the delay jitter and reordering should be the same as FIFO. Loss rates may be different, but for things like F-RED they should be better, not worse. The only problem I see is if you had a WFQ system that isolated traffic based on destination ports. In that case, the delay jitter could be worse. However, I'm not really sure how much worse it would be compared to a congested network with best-effort FIFO service. In any case, the problem you point out will happen when you send audio and video separately anyway. Hosts will have to implement sufficient playout buffering to allow for inter-media synchronization. This buffer should also then be sufficient for the FEC mechanisms. Proposal (3) still allowed you to send the FEC and data in the same packets, however, using the redundant audio codecs. So, if you were really worried about the problem, you could do that. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (732) 949-6418 Rm. 4C-526 FAX: (732) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Jan 29 09:49:30 1998 From rem-conf-request@es.net Thu Jan 29 09:49:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xxxxf-0007ZL-00; Thu, 29 Jan 1998 09:41:11 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Jan 1998 10:36:40 -0700 To: "...." From: James Subject: SUBCRIBE X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please add me to your list..i wish to subscribe to MBone annoucements. james. Oh From rem-conf Thu Jan 29 23:30:27 1998 From rem-conf-request@es.net Thu Jan 29 23:30:27 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0xyAdl-0004UZ-00; Thu, 29 Jan 1998 23:13:29 -0800 Message-Id: <3.0.5.32.19980130171950.00be8a10@pophost.dstc.edu.au> X-Sender: liz@pophost.dstc.edu.au X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Jan 1998 17:19:50 +1000 To: rem-conf@es.net From: Liz Armstrong Subject: WWW7 newsletter Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Please find following the latest WWW7 newsletter. The WWW7 Consortium appreciates your on-going support of the Conference and thanks you for taking the time to distribute our updates to your friends and colleagues. Regards Liz Armstrong for WWW7 Consortium ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WWW7 Electronic Newsletter - January 1998 A regular email newsletter sent out to over 5,000 people around the world who are interested in WWW7. Feel free to forward this newsletter to your associates. To unsubscribe from this mailing, simply forward this entire newsletter to info@www7.conf.au and type Unsubscribe in the subject line of the email. ************************************************************************ A. Developer's Day B. What will be of particular interest to the cultural sector? C. Selection of WWW7 papers, posters, tutorial and workshops now finalised D. Workshops at WWW7 E. Conference Contact Details ************************************************************************ A. Developers' Day Developers' Day will be on Saturday 18 April. The keynote speaker will be James Gosling, Vice President, Sun Microsystems and the father of Java - the most revolutionary programming language in years and the most empowering language for the Web. James will talk on the future of Web development and the role that Java will play. Developers' day will include the following confirmed technology tracks: Style Sheets Markup - XML, HTML, SGML and more Java Internationalisation Resource Description Framework and Metadata Distributed Objects (CORBA) on the Web More tracks are under development including HTTP, Push Technologies and Ecommerce. For more info, visit the WWW7 home page or email B. What will be of particular interest to the cultural sector? This stream will be working alongside the main conference, with a strong focus on the interaction between the emerging technologies and the needs and aspirations of the cultural community. In the special section, a physical collection will be converted to a digital collection using the latest techniques and equipment. Those who make the equipment and use it will be available to talk to you about the good and bad aspects of this process. You will be able to consider photography, VR, textual descriptions, cataloging issues, archival issues and more. All these practical problems for the community will be brought to air in a context where the developers and users can interact. Each day of the main conference there will be three streams from which you can choose: the usual WWW7 technical papers, working sessions for cultural institutional policy and decision-makers, and working sessions for those who develop content for cultural institutions, both derivative and original digital material. On tutorials day (Tuesday, the day before the conference starts), there will be tutorials for you. The first day of the conference, Wednesday, will introduce the issues and links to be made with the technical part of the conference. The second day, Thursday, will be particularly of value to those who work in museums, with the emphasis on visiting cultural institutions - esp. in cyberspace. The third day, Friday, will be of particularly concerned with work in the area of collection description - it will be International Metadata Day, a sequel Metadata Day held at the National Library of Australia following DC4 in Canberra in 1997. Developers' day will extend all this into the development level for those with technical expertise. For more information about the cultural sector activities, please email: www7culture@srl.rmit.edu.au or contact: WWW7 Conference Cultural Sector Activities c/- Sunrise at RMIT GPO Box 2476V Melbourne 3001 VIC Australia Phone +613 9660 3024 Fax +613 9660 2761 C. Selection of WWW7 papers, posters, tutorial and workshops now finalised. The Program Committee were impressed by the number and quality of papers and posters submitted. We received 236 submissions from which we selected 54 papers, 12 posters and 48 short papers. The geographic distribution of papers was also remarkable - we were pleased to receive submissions from 24 countries. Australasia will be well-represented with papers and short papers from Australia, Japan, Singapore, Taiwan and Korea. However we have many good papers and short papers from the rest of the world, with the USA, the UK, Germany, Sweden, Italy, Denmark, the Netherlands, Switzerland, Israel, Greece and Austria all represented in the program. The topic range was also particularly impressive. We received submissions in every one of the topic areas listed in the Call for Papers, with a large number papers on topical areas such as Information retrieval and modeling, search and indexing techniques, browsers and tools, human-computer interaction, applications in education and training, metadata systems and many more. In addition to the refereed papers and short papers, the conference will also devote a track to the activities of the World Wide Web consortium (W3C) motivate much of the research on Web technologies and social issues. Of course, one of the conference keynote speakers is Tim Berners-Lee, co-founder of the Web and Director of the W3C. D. Workshops at WWW7 - Opportunities for Staff Development WWW7 begins with a Workshop and Tutorial Day on April 14, 1998. A slate of 11 workshops afford conference delegates the opportunity to work together to move Web technology and applications forward. The spectrum of areas covered by the conference workshops demonstrates that the WWW7 is truly the gathering place for anyone interested in the World Wide Web. Some workshops focus on advancing the base technology with such topics as HTTP, XSL and XML, and, the emerging area of Web engineering. Other workshops focus on important application areas, such as libraries and on-line training and education. A third set of workshops focus on pressing social issues such as disability access and communication within agricultural communities. Workshops provide a stimulating opportunity for participants to pursue the issues and ideas associated with their particular interest at a gathering of people with similar interests. This is an invaluable opportunity for networking and for establishing on-going collaboration. Indeed, two of the workshops -- The International Flexible Hypertext Workshop and The Hypertext Functionality Workshop -- are part of ongoing series of workshops on these topics. The Web community benefits from the ongoing work accomplished and the new initiatives started during the workshops and the workshops certainly reward those who get involved. The starting point for such involvement is the workshop page of the conference Web site, http://www7.conf.au/workshop.html E. Conference Contact Details WWW7 Conference Secretariat PO Box WWW7 St Lucia South Queensland Australia 4067 Phone +61 7 3870 8831 Fax +61 7 3371 9514 Email :info@www7.conf.au Web: http://www7.conf.au 7th International World Wide Web Conference 14-18 April 1998 Brisbane Convention & Exhibition Centre Brisbane, Australia