From mailnull@www1.ietf.org Tue Jun 10 08:02:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22443 for ; Tue, 10 Jun 2003 08:02:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AC1g213459 for rmt-archive@odin.ietf.org; Tue, 10 Jun 2003 08:01:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AC1gB13456 for ; Tue, 10 Jun 2003 08:01:42 -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 IAA22426 for ; Tue, 10 Jun 2003 08:01:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Phmr-00048g-00 for rmt-web-archive@ietf.org; Tue, 10 Jun 2003 07:59:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Phmq-00048c-00 for rmt-web-archive@ietf.org; Tue, 10 Jun 2003 07:59:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AC1FB13435; Tue, 10 Jun 2003 08:01:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABr3B12960 for ; Tue, 10 Jun 2003 07:53:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21786; Tue, 10 Jun 2003 07:53:00 -0400 (EDT) Message-Id: <200306101153.HAA21786@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 10 Jun 2003 07:53:00 -0400 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-bb-norm-06.txt,.ps,.pdf 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : NACK-Oriented Reliable Multicast (NORM) Building Blocks Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker Filename : draft-ietf-rmt-bb-norm-06.txt,.ps,.pdf Pages : 33 Date : 2003-6-9 This document discusses the creation the of negative-acknowledgment This document discusses the creation the of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional 'building blocks' that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-norm-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-rmt-bb-norm-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-bb-norm-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-6-9151202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-norm-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-norm-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9151202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Tue Jun 10 08:04:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22547 for ; Tue, 10 Jun 2003 08:04:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AC3qq13633 for rmt-archive@odin.ietf.org; Tue, 10 Jun 2003 08:03:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AC3qB13630 for ; Tue, 10 Jun 2003 08:03:52 -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 IAA22497 for ; Tue, 10 Jun 2003 08:03:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Phoy-0004AS-00 for rmt-web-archive@ietf.org; Tue, 10 Jun 2003 08:01:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Phox-0004AP-00 for rmt-web-archive@ietf.org; Tue, 10 Jun 2003 08:01:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AC3dB13540; Tue, 10 Jun 2003 08:03:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ABr7B12965 for ; Tue, 10 Jun 2003 07:53:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21802; Tue, 10 Jun 2003 07:53:05 -0400 (EDT) Message-Id: <200306101153.HAA21802@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 10 Jun 2003 07:53:05 -0400 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-pi-norm-07.txt,.ps,.pdf 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : NACK-Oriented Reliable Multicast Protocol (NORM) Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker Filename : draft-ietf-rmt-pi-norm-07.txt,.ps,.pdf Pages : 77 Date : 2003-6-9 This document describes the messages and procedures of the Negative- acknowledgement (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgement mechanism for transport reliability and offers additional protocol mechanisms to conduct reliable multicast sessions with limited 'a priori' coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) from the senders to receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-rmt-pi-norm-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-pi-norm-07.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-6-9151212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-norm-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-norm-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-9151212.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Tue Jun 10 19:04:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22114 for ; Tue, 10 Jun 2003 19:04:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AN40H02096 for rmt-archive@odin.ietf.org; Tue, 10 Jun 2003 19:04:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AN40B02093 for ; Tue, 10 Jun 2003 19:04: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 TAA22072 for ; Tue, 10 Jun 2003 19:03:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ps7j-0002ug-00 for rmt-web-archive@ietf.org; Tue, 10 Jun 2003 19:01:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ps7i-0002ub-00 for rmt-web-archive@ietf.org; Tue, 10 Jun 2003 19:01:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AN3iB02044; Tue, 10 Jun 2003 19:03:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AMtXB01732 for ; Tue, 10 Jun 2003 18:55:33 -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 SAA21922 for ; Tue, 10 Jun 2003 18:55:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PrzY-0002rB-00 for rmt@ietf.org; Tue, 10 Jun 2003 18:53:24 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19PrzX-0002r8-00 for rmt@ietf.org; Tue, 10 Jun 2003 18:53:23 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5AMsrI2024571; Tue, 10 Jun 2003 15:54:54 -0700 (PDT) Received: (from lorenzo@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA03884; Tue, 10 Jun 2003 15:54:45 -0700 (PDT) Date: Tue, 10 Jun 2003 15:54:45 -0700 From: Lorenzo Vicisano To: rmt@ietf.org Cc: Allison Mankin , Roger Kermode , jon.peterson@neustar.biz Message-ID: <20030610155445.D12084@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Subject: [Rmt] WG last-call for NORM BB and PI 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: , Please be advised that RMT Working Group last call is issued for draft-ietf-rmt-bb-norm-06.txt and draft-ietf-rmt-pi-norm-07.txt, starting Today. Please send your comments to this mailing list by Wed June 25th. thank you, the RMT chairs. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From mailnull@www1.ietf.org Fri Jun 13 10:53:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08739 for ; Fri, 13 Jun 2003 10:53:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DErFt17599 for rmt-archive@odin.ietf.org; Fri, 13 Jun 2003 10:53:15 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DErEm17596 for ; Fri, 13 Jun 2003 10:53:14 -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 KAA08702 for ; Fri, 13 Jun 2003 10:53:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QptP-0005yU-00 for rmt-web-archive@ietf.org; Fri, 13 Jun 2003 10:51:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QptO-0005yQ-00 for rmt-web-archive@ietf.org; Fri, 13 Jun 2003 10:51:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBq5a01997; Fri, 13 Jun 2003 07:52:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBpRm01937 for ; Fri, 13 Jun 2003 07:51:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29109; Fri, 13 Jun 2003 07:51:25 -0400 (EDT) Message-Id: <200306131151.HAA29109@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 13 Jun 2003 07:51:25 -0400 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-flute-00.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : FLUTE - File Delivery over Unidirectional Transport Author(s) : T. Paila et al. Filename : draft-ietf-rmt-flute-00.txt Pages : 30 Date : 2003-6-12 This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-rmt-flute-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-flute-00.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-6-12132332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-flute-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-flute-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-12132332.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From exim@www1.ietf.org Wed Jun 25 12:19:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19700 for ; Wed, 25 Jun 2003 12:19:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PGIXX08300 for rmt-archive@odin.ietf.org; Wed, 25 Jun 2003 12:18:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCyf-00029n-RT for rmt-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 12:18:33 -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 MAA19668 for ; Wed, 25 Jun 2003 12:18:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCyQ-00055r-00 for rmt-web-archive@ietf.org; Wed, 25 Jun 2003 12:18:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VCyK-00055f-00 for rmt-web-archive@ietf.org; Wed, 25 Jun 2003 12:18:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCqP-0001kV-RG; Wed, 25 Jun 2003 12:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCpK-0001i1-Ea for rmt@optimus.ietf.org; Wed, 25 Jun 2003 12:09:09 -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 MAA19165 for ; Wed, 25 Jun 2003 12:08:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VCp5-00051U-00 for rmt@ietf.org; Wed, 25 Jun 2003 12:08:39 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx with esmtp (Exim 4.12) id 19VCou-00050b-00 for rmt@ietf.org; Wed, 25 Jun 2003 12:08:28 -0400 Received: from imap-serv.inrialpes.fr (imap-serv.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.12.8/8.12.8) with ESMTP id h5PG62eK021909; Wed, 25 Jun 2003 18:06:02 +0200 (MEST) Received: from inrialpes.fr (iseran.inrialpes.fr [194.199.24.100]) by imap-serv.inrialpes.fr (8.11.6/8.11.3/ImagV2) with ESMTP id h5PG61A07490; Wed, 25 Jun 2003 18:06:02 +0200 (MEST) Message-ID: <3EF9C86D.A94BB531@inrialpes.fr> Date: Wed, 25 Jun 2003 18:06:05 +0200 From: Vincent Roca Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Brian Adamson CC: Lorenzo Vicisano , rmt@ietf.org Subject: Re: [Rmt] WG last-call for NORM BB and PI References: <20030610155445.D12084@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: McAfee uvscan 4241 RBL+ ORBS Found to be clean Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian and al., Please find two comments after a _fast_ reading of the latest NORM PI draft. * session_id semantic, p 17: The NORM use of this session_id is quite different from that of ALC. With NORM, the session_id "uniquely identifies [the sender] current instance of parcipitation in the NormSession". So it does not identify the session (unlike it is suggested by its name) but a sender instance within a session. So at minimum the session_id name should be changed for something more explicit (eg. "sender instance id"). With ALC, the session_id "uniquely identifies a session among all sessions from a particular sender". So the second part of this remark is: how is identified a NORM session? It seems there's no such mechanism (unless I missed something). Two sessions emanating from the same sender are probably distinguished by the session multicast address/UDP port... but is there something else? With ALC, the session (multicast or unicast) address is not used, only the {sender IP addr; TSI} tuple. It means that there is a full independance between the delivery mechanism (eg. the destination address may change while in transit) and the session identifying mechanism. OK, the situation is simpler in ALC since only 1-to-many sessions are considered, which is not the case of NORM... Nevertheless maybe something is missing here, for instance to prevent session collisions. I don't how to do that, though! What is your feeling? * definition of the NORM FEC Object Transmission Information (FTI) Header Extension, p 21: This EXT_FTI definition is quite different from that of FLUTE (draft-ietf-rmt-flute-00.txt). It does not mean that the NORM version is wrong, but it does mean that some harmonization is probably needed between the two documents. (I don't think there is any good reason to have RM dependant FTI formats) To be discussed... Cheers, Vincent ---------------------- http://www.inrialpes.fr/planete/people/roca/ INRIA Rhone-Alpes - projet planete vincent.roca@inrialpes.fr Zirst; 655 av. de l'Europe; Montbonnot phone (+33) 4.76.61.52.16 38334 ST ISMIER cedex - France fax (+33) 4.76.61.52.52 _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From exim@www1.ietf.org Fri Jun 27 22:37:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00587 for ; Fri, 27 Jun 2003 22:37:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S2bM008180 for rmt-archive@odin.ietf.org; Fri, 27 Jun 2003 22:37:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5aZ-00027S-TX for rmt-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 22:37:20 -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 WAA00566 for ; Fri, 27 Jun 2003 22:37:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W5aV-0000dR-00 for rmt-web-archive@ietf.org; Fri, 27 Jun 2003 22:37:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19W5aQ-0000dM-00 for rmt-web-archive@ietf.org; Fri, 27 Jun 2003 22:37:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5aJ-00025P-KR; Fri, 27 Jun 2003 22:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W5Zi-00024w-T6 for rmt@optimus.ietf.org; Fri, 27 Jun 2003 22:36:41 -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 WAA00552 for ; Fri, 27 Jun 2003 22:36:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W5ZP-0000dA-00 for rmt@ietf.org; Fri, 27 Jun 2003 22:36:07 -0400 Received: from mail.oii.net ([207.254.222.70] helo=oii.net) by ietf-mx with esmtp (Exim 4.12) id 19W5ZE-0000d5-00 for rmt@ietf.org; Fri, 27 Jun 2003 22:35:57 -0400 Received: from [24.244.168.162] ([24.244.168.162]) by oii.net (8.11.6/8.9.3) with ESMTP id h5S2TXL30708; Fri, 27 Jun 2003 21:29:34 -0500 Mime-Version: 1.0 X-Sender: adamson@pop.itd.nrl.navy.mil (Unverified) Message-Id: In-Reply-To: <3EF9C86D.A94BB531@inrialpes.fr> References: <20030610155445.D12084@cisco.com> <3EF9C86D.A94BB531@inrialpes.fr> Date: Fri, 27 Jun 2003 22:33:49 -0400 To: Vincent Roca From: Brian Adamson Subject: Re: [Rmt] WG last-call for NORM BB and PI Cc: Lorenzo Vicisano , rmt@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , I'm on vacation this week and won't likely get to update the draft _before_ the cutoff date, but I will see what I can do. I will be back in the office Tuesday. With regards to the sessionId ... that makes sense to me ... i.e. to suggest that senders use a common sessionId for a common session instance, and I agree that how this is accomplished may be TBD ... I went with the "sender instance" usage because this has been an issue in some bulk transfer reliable multicast applications ... when a sender leaves a long-lived session (crashing, terminated, etc) but then rejoins relatively quickly ... our implementation(s) of reliable multicast have used the objectId space to, if not deterministically, randomly to let receivers infer the rejoining sender is a "new" instance and they should "resync" to the sender (i.e. previous object transpor state they have for the sender may be invalid) ... I have always felt this was a little weak, particularly that within NORM we now have a 16-bit objectId space, instead of the 32-bit objectId space used within previous protocols. The "sender instance" usage of a sessionId field allows for a more robust solution to this issue ... However, I understand the usefulness of a sessionId usage which allows the reliable multicast session to transcend mere multicast address/port number assignment ... this is probably more consistent with emerging concepts for transport protocols with more dynamic lower layers due to mobility, security, etc. I think I understand that this is your "session collision" concern? Perhaps the exact usage of the NORM sessionId field may become more well-defined as mechanisms to provide for signalling/agreement to sessionId values within a multicast session? Meanwhile, the NORM spec (as an experimental RFC) could discuss these possible different usages of the field? In the end, a receiver's response to a detected change in "sessionId" from a given "senderId" is the same ... With regards to the "flute" FTI definition, I will look into that. However, I would like to retain a mechanism within NORM that allows for very loosely organized reliable multicast sessions, i.e. where receivers can begin interpreting sender transmitted content quickly without need for out-of-band information (albeit at the cost of some header overhead) ... the FTI extension defined within NORM is currently for "fec_id" == 129 ... other header extensions could be defined for use with NORM ... to possibly include the "flute" definition ... And I will look at the flute draft ... perhaps that will remove the need for the fec_id=129 FTI extension defined in the current NORM draft ?? At 6:06 PM +0200 6/25/03, Vincent Roca wrote: >Brian and al., > >Please find two comments after a _fast_ reading of the latest NORM PI >draft. > >* session_id semantic, p 17: > > The NORM use of this session_id is quite different from that of ALC. > With NORM, the session_id "uniquely identifies [the sender] > current instance of parcipitation in the NormSession". So it does > not identify the session (unlike it is suggested by its name) > but a sender instance within a session. So at minimum the session_id > name should be changed for something more explicit (eg. "sender > instance id"). > > With ALC, the session_id "uniquely identifies a session among all > sessions from a particular sender". > So the second part of this remark is: how is identified a NORM > session? > It seems there's no such mechanism (unless I missed something). > Two sessions emanating from the same sender are probably > distinguished by the session multicast address/UDP port... but is > there something else? > With ALC, the session (multicast or unicast) address is not used, > only the {sender IP addr; TSI} tuple. It means that there is a full > independance between the delivery mechanism (eg. the destination > address may change while in transit) and the session identifying > mechanism. OK, the situation is simpler in ALC since only 1-to-many > sessions are considered, which is not the case of NORM... > Nevertheless maybe something is missing here, for instance to > prevent session collisions. I don't how to do that, though! What > is your feeling? > > >* definition of the NORM FEC Object Transmission Information (FTI) > Header Extension, p 21: > > This EXT_FTI definition is quite different from that of FLUTE > (draft-ietf-rmt-flute-00.txt). It does not mean that the NORM version > is wrong, but it does mean that some harmonization is probably needed > between the two documents. > (I don't think there is any good reason to have RM dependant FTI > formats) > To be discussed... > > >Cheers, > > Vincent > >---------------------- http://www.inrialpes.fr/planete/people/roca/ > INRIA Rhone-Alpes - projet planete vincent.roca@inrialpes.fr > Zirst; 655 av. de l'Europe; Montbonnot phone (+33) 4.76.61.52.16 > 38334 ST ISMIER cedex - France fax (+33) 4.76.61.52.52 -- Brian __________________________________ Brian Adamson _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From exim@www1.ietf.org Mon Jun 30 14:42:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10300 for ; Mon, 30 Jun 2003 14:42:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UIgEY04255 for rmt-archive@odin.ietf.org; Mon, 30 Jun 2003 14:42:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3bR-00016Y-Sc for rmt-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 14:42:13 -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 OAA10289 for ; Mon, 30 Jun 2003 14:42:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X3bO-0003R9-00 for rmt-web-archive@ietf.org; Mon, 30 Jun 2003 14:42:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19X3bI-0003R3-00 for rmt-web-archive@ietf.org; Mon, 30 Jun 2003 14:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3bF-00015b-1f; Mon, 30 Jun 2003 14:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3aZ-00014s-DQ for rmt@optimus.ietf.org; Mon, 30 Jun 2003 14:41:19 -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 OAA10274 for ; Mon, 30 Jun 2003 14:41:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X3aW-0003Qm-00 for rmt@ietf.org; Mon, 30 Jun 2003 14:41:16 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19X3aK-0003QO-00 for rmt@ietf.org; Mon, 30 Jun 2003 14:41:04 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5UIe9O0028488 for ; Mon, 30 Jun 2003 11:40:10 -0700 (PDT) Received: (from lorenzo@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA09582 for rmt@ietf.org; Mon, 30 Jun 2003 11:40:09 -0700 (PDT) Date: Mon, 30 Jun 2003 11:40:09 -0700 From: Lorenzo Vicisano To: rmt@ietf.org Message-ID: <20030630114009.B28053@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Subject: [Rmt] call for agenda items 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: , For the Vienna meeting (Monday, July 14, 1500-1530). Please reply to this email with your request. Please remember the usual guidelines. thank you, the chairs. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt