[Rmt] FW: draft-ietf-rmt-bb-fec-basic-schemes-revised

Mark Watson <mark@digitalfountain.com> Fri, 20 July 2007 22:53 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 1IC1MF-0003hX-Bb; Fri, 20 Jul 2007 18:53:59 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC1ME-0003hR-30 for rmt@ietf.org; Fri, 20 Jul 2007 18:53:58 -0400
Received: from exbe04.ex.dslextreme.net ([66.51.199.86] helo=EXVS01.ex.dslextreme.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC1MD-00042s-OS for rmt@ietf.org; Fri, 20 Jul 2007 18:53:58 -0400
Received: from 65.122.15.162 ([65.122.15.162]) 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 ; Fri, 20 Jul 2007 22:54:45 +0000
User-Agent: Microsoft-Entourage/11.3.6.070618
Date: Fri, 20 Jul 2007 15:53:48 -0700
From: Mark Watson <mark@digitalfountain.com>
To: "rmt@ietf.org" <rmt@ietf.org>
Message-ID: <C2C68B0C.1B0BC%mark@digitalfountain.com>
Thread-Topic: draft-ietf-rmt-bb-fec-basic-schemes-revised
Thread-Index: AcfE161t7COFnzDKEdyhzwAX8sJN9gGSSfLD
In-Reply-To: <C2BBFF55.19FCE%mark@digitalfountain.com>
Mime-version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Subject: [Rmt] FW: 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="===============1149921574=="
Errors-To: rmt-bounces@ietf.org

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