From exim@www1.ietf.org Fri Apr 23 15:01:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28745 for ; Fri, 23 Apr 2004 15:01:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5j7-0005IY-KS for rmt-archive@odin.ietf.org; Fri, 23 Apr 2004 14:48:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3NImfmh020361 for rmt-archive@odin.ietf.org; Fri, 23 Apr 2004 14:48:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH5Ge-0000xs-Ta for rmt-web-archive@optimus.ietf.org; Fri, 23 Apr 2004 14:19:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24777 for ; Fri, 23 Apr 2004 14:19:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH5Gc-0005u7-AA for rmt-web-archive@ietf.org; Fri, 23 Apr 2004 14:19:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH5Fn-0005fQ-00 for rmt-web-archive@ietf.org; Fri, 23 Apr 2004 14:18:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BH5Ew-0005Py-00 for rmt-web-archive@ietf.org; Fri, 23 Apr 2004 14:17:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH56i-0006Oj-P8; Fri, 23 Apr 2004 14:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BH4yy-0003wp-UO for rmt@optimus.ietf.org; Fri, 23 Apr 2004 14:01:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23717 for ; Fri, 23 Apr 2004 14:00:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BH4yw-0000ty-HI for rmt@ietf.org; Fri, 23 Apr 2004 14:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BH4xA-0000cc-00 for rmt@ietf.org; Fri, 23 Apr 2004 13:59:09 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BH4w5-00009p-00; Fri, 23 Apr 2004 13:58:01 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i3NHujN06267; Fri, 23 Apr 2004 10:56:45 -0700 (PDT) Message-Id: <200404231756.i3NHujN06267@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, rmt@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 23 Apr 2004 10:56:45 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Subject: [Rmt] RFC 3738 on Wave and Equation Based Rate Control (WEBRC) Building Block Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3738 Title: Wave and Equation Based Rate Control (WEBRC) Building Block Author(s): M. Luby, V. Goyal Status: Experimental Date: April 2004 Mailbox: luby@digitalfountain.com, v.goyal@ieee.org Pages: 32 Characters: 82584 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rmt-bb-webrc-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3738.txt This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. This document is a product of the Reliable Multicast Transport Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040423105341.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3738 --OtherAccess Content-Type: Message/External-body; name="rfc3738.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040423105341.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From exim@www1.ietf.org Wed Apr 28 14:17:23 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05327 for ; Wed, 28 Apr 2004 14:17:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItVM-0008Ly-Po for rmt-archive@odin.ietf.org; Wed, 28 Apr 2004 14:09:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SI9ut4032110 for rmt-archive@odin.ietf.org; Wed, 28 Apr 2004 14:09:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItOF-0006FI-Sc for rmt-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:02:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04278 for ; Wed, 28 Apr 2004 14:02:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItOC-0003m7-9Y for rmt-web-archive@ietf.org; Wed, 28 Apr 2004 14:02:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItNF-0003h4-00 for rmt-web-archive@ietf.org; Wed, 28 Apr 2004 14:01:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BItMy-0003dm-00 for rmt-web-archive@ietf.org; Wed, 28 Apr 2004 14:01:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItAA-0003az-Lj; Wed, 28 Apr 2004 13:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt5l-0002aR-TA for rmt@optimus.ietf.org; Wed, 28 Apr 2004 13:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02532 for ; Wed, 28 Apr 2004 13:43:27 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt5i-0002Sp-80 for rmt@ietf.org; Wed, 28 Apr 2004 13:43:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt4s-0002PG-00 for rmt@ietf.org; Wed, 28 Apr 2004 13:42:35 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIt47-0002Kn-00; Wed, 28 Apr 2004 13:41:47 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SHflG29089; Wed, 28 Apr 2004 20:41:47 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 20:41:38 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3SHfcaK010895; Wed, 28 Apr 2004 20:41:38 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00CeIlaL; Wed, 28 Apr 2004 20:41:37 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SHfaH11037; Wed, 28 Apr 2004 20:41:36 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 20:41:36 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 20:41:36 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 20:41:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Apr 2004 20:41:34 +0300 Message-ID: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-06.txt Thread-Index: AcQiYWWlGJ3m4fX3Rbazk0G2F+ejsQK4ukEQ To: , X-OriginalArrivalTime: 28 Apr 2004 17:41:36.0200 (UTC) FILETIME=[0D954C80:01C42D48] Content-Transfer-Encoding: quoted-printable Subject: [Rmt] Session Description for FLUTE Sessions (aka FLUTE SDP) Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-BeenThere: rmt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Reliable Multicast Transport List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NO_EXPERIENCE,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello World I would like to ask for ideas and opinions on a session description for = FLUTE sessions. (FLUTE is the unidirectional file delivery protocol from = the Reliable Multicast Transport WG - draft-ietf-rmt-flute-07.txt - like = an RTP for files at a small stretch of the imagination). In short, to use FLUTE certain out-of-band information is mandatory and = optional. Although this can be sought by any number of proprietary and = closed methods, it's likely to be a big help to have an open document on = how to describe this in a way also suitable for the general Internet. = Thus, I want to build up some initial expert (and novice) opinions on = the semantics and syntax of what would be needed. FLUTE and ALC provide a starter-kit of data items which can easily be = turned into a semantic description. For syntax, it seems SDP is the = natural choice and SDP already comes with a decent tool kit of = attributes to reuse. (This is not to say SDPng and others would be = inappropriate, just that to start the work now SDP seems to be the only = show in town). Some other relevant context is that 3GPP (MBMS/SA4) has identified the = need for such a FLUTE session description, and the time constraints of = 3GPP release 6 (September freeze) offer a minimal window to do a 2 way = swap of ideas and agreement before a standard is needed. I certainly = have no experience in turning out RFC's in 5 months flat (anyone? :), = but a serious attempt to work on the issue in the next few months would = be an excellent way of ensuring a single interoperable method (and open = standard). In addition, I am expecting ETSI/DVB to make a "call for = technologies" in this area within a few weeks so the benefits of rapid = progress should be pretty obvious (but don't shoot me for suggesting it = :) Who wants to get involved? Cheers, Rod. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt