[Rmt] draft-ietf-rmt-bb-fec-basic-schemes-revised
Mark Watson <mark@digitalfountain.com> Sat, 17 November 2007 03:20 UTC
Return-path: <rmt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItEEZ-0003ZX-Fm; Fri, 16 Nov 2007 22:20:39 -0500
Received: from rmt by megatron.ietf.org with local (Exim 4.43) id 1ItEEY-0003Ww-3K for rmt-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 22:20:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItEEX-0003We-Pb for rmt@ietf.org; Fri, 16 Nov 2007 22:20:37 -0500
Received: from exvs01.ex.dslextreme.net ([66.51.199.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItEEP-0004eJ-Bu for rmt@ietf.org; Fri, 16 Nov 2007 22:20:37 -0500
Received: from 67.101.47.65 ([67.101.47.65]) by EXVS01.ex.dslextreme.net ([192.168.7.220]) via Exchange Front-End Server owa.dslextreme.net ([192.168.7.126]) with Microsoft Exchange Server HTTP-DAV ; Sat, 17 Nov 2007 03:22:02 +0000
User-Agent: Microsoft-Entourage/11.3.6.070618
Date: Fri, 16 Nov 2007 19:20:21 -0800
From: Mark Watson <mark@digitalfountain.com>
To: "rmt@ietf.org" <rmt@ietf.org>
Message-ID: <C3639DF5.20287%mark@digitalfountain.com>
Thread-Topic: draft-ietf-rmt-bb-fec-basic-schemes-revised
Thread-Index: AcfE161t7COFnzDKEdyhzwAX8sJN9gGSSfLDF2n870M=
In-Reply-To: <C2C68B0C.1B0BC%mark@digitalfountain.com>
Mime-version: 1.0
X-Spam-Score: 4.4 (++++)
X-Scan-Signature: a0534e6179a1e260079328e8b03c7901
Subject: [Rmt] draft-ietf-rmt-bb-fec-basic-schemes-revised
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1092373802=="
Errors-To: rmt-bounces@ietf.org
All, I have submitted an update of this draft. As there was no comments on my suggestion below, I have incorporated that. Aside from the reference update for the FEC Building Block -> RFC5052, there are no other changes. We should discuss this change at the Vancouver meeting if there are objections we can take it out. I just included it in order to provide a concrete proposal and because there were no objections on the list. After the meeting I believe this draft will be ready for WGLC. Regards, Mark ------ Forwarded Message From: Mark Watson <mark@digitalfountain.com> Date: Fri, 20 Jul 2007 15:53:48 -0700 To: <rmt@ietf.org> Conversation: draft-ietf-rmt-bb-fec-basic-schemes-revised Subject: [Rmt] FW: draft-ietf-rmt-bb-fec-basic-schemes-revised All, Please see message below. I inadvertantly sent it only to the chairs, but it was meant for public consumption. Regards, Mark ------ Forwarded Message From: Mark Watson <mark@digitalfountain.com> Date: Thu, 12 Jul 2007 15:55:01 -0700 To: "rmt-chairs@tools.ietf.org" <rmt-chairs@tools.ietf.org> Conversation: draft-ietf-rmt-bb-fec-basic-schemes-revised Subject: draft-ietf-rmt-bb-fec-basic-schemes-revised All, I would like to make a suggestion which might improve the utility of the ³general purpose² Underspecified FEC Schemes defined in this draft. Each of these schemes defines the usage of a subset of the ³Common FEC Object Transmission Information Elements², but does not define a complete FEC scheme. The Common FEC OTI elements are things like Encoding Symbol Length, Maximum Source Block Size etc. which although not used by all FEC Scheme are generally useful things for which it makes sense to have some kind of common protocol infrastucture. However, FEC Schemes may also defined Scheme-Specific FEC Object Transmission Information Elements and in the case of underspecified FEC schemes it would be possible to define space for Instance-specific information. I think the possibility for instance-specific information would make these schemes much more useful and increase the chance that they get re-used rather than having people create a new underspecified scheme each time they need one. The FEC Building Block prohibits later introduction of Scheme-specific fields to an FEC scheme. This was because of the possible existence of Content Delivery Protocols that would be confused by additional information being introduced in later versions of an FEC Scheme. I think this is not a problem with respect to the previous experimental versions of these schemes, since there is only one registered Instance Id against one of the schemes (and I know it will not be a problem for the owners of that instance id ;-). It could be a problem in future if we do not provide now for Instance-specific information. So, I propose that to each underspecified FEC scheme we add a field for Instance-specific FEC OTI information. The field could consist of a length field, giving the length in 4-byte words of the Instance-specific OTI field, followed by Instance-specific information. In cases where the CDP separately signals the length of the encoded OTI (i.e. All existing CDPs) it can be optional. ...Mark ------ End of Forwarded Message _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt ------ End of Forwarded Message
_______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt
- [Rmt] FW: draft-ietf-rmt-bb-fec-basic-schemes-rev… Mark Watson
- [Rmt] Update RMT Agenda Posted Brian Adamson
- [Rmt] draft-ietf-rmt-bb-fec-basic-schemes-revised Mark Watson