RE: draft-ietf-rmt-fec-bb-revised-01 WG Last-Call

Comments inline (paragraphs that start with ***).

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, September 20, 2005 3:56 PM
To: [email protected]; [email protected]
Subject: RE: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call

Hi,

I have the following comments on the content of this draft.
I also included some suggestions for improvement where appropriate.
Your comments and opinions are requested on these issues.

--------Comment-1-------
Section-1
Do the CDPs mentioned in this draft include only file delivery protocols
like FLUTE or do they also include CDPs like "MBMS streaming framework"?
Please give examples of CDP. e.g., FLUTE, MBMS Streaming framework etc.

*** The idea is that absolutely yes, a CDP encompasses FLUTE, the MBMS
streaming framework, and whatever CDPs people invent in the future.  Should
we make that more explicit?  In particular, if and when the MBMS streaming
framework is accepted into the IETF and there is a CDP framework in which to
define FEC schemes for streams then this revision of the FEC building block
accommodates this (by design).

--------Comment-2-------
Section-6.1
"The value of the FEC Encoding ID MUST be the same for all transmission of
encoding symbols related to a particular object,"

Why did you impose this restriction?
This restriction prevents a sender from using different FEC schemes for
different transmissions of the encoding symbols.
For example, a server may wish to use no FEC in the first transmission, it
may wish to use some FEC in the second transmission.

*** The way we handled this is that an FEC Encoding ID MAY use a different
packet format and FEC Payload ID for source and repair packets (for
systematic codes).  Thus, in the situation you are speaking to the first
transmission would only send source packets, and then in a second
transmission you can either send just repair packets or a combination of
source and repair packets.  The differentiation between source and repair
packets is a higher level protocol issue: in FLUTE/ALC/LCT the
differentiation can be made in the LCT header (we are going to use a
previously reserved bit in the LCT header to optionally indicate whether the
packet is a source or a repair packet, in of course a backwards compatible
way, i.e., you don't have to use this LCT mechanism to distinguish).  Thus,
even though it is the same FEC Encoding ID, there are potentially two
different types of packets, source and repair (also see the last comment
below for a nuanced version of this).

--------Comment-3-------
"An already defined Under-Specified FEC Scheme (i.e.  FEC Encoding ID value)
MUST be reused if the associated FEC Payload ID and FEC Object Transmission
Information have the required fields and encoding formats for a new
Under-Specified FEC scheme instance."

Please give an example. What is the motivation behind this restriction?

*** The motivation is that there is no reason to use a new FEC Encoding ID
and write a whole new RFC if a previously defined FEC Encoding ID is
sufficient to handle a new Under-Specified FEC scheme, as introducing a new
FEC Encoding ID is a bigger deal than just registering another
Under-Specified FEC scheme under an existing FEC Encoding ID.  An example is
the LDPC FEC schemes that are being proposed by Inria, which in their
current state are being proposed as Under-Specified under the same FEC
Encoding ID. (Although there is also a request to have them Fully-Specified,
so who knows where this will end up.)

--------Comment-4-------
Section-7
" 2.  The type, semantics and encoding format of one or two FEC Payload IDs.
Where two FEC Payload ID formats are specified, then the FEC scheme MUST be
a systematic FEC code and one FEC Payload ID format MUST be designated for
use with packets carrying only source symbols and the other FEC Payload ID
format MUST be designated for use with packets carrying at least one repair
symbol."

There can be more than two FEC Payload IDs defined by some FEC schemes.
When two FEC Payload IDs are specified, they may not necessarily strictly
correspond to "source packets" and "repair packets".
So I propose to change the "MUST" to "MAY" in the above sentence. What do
you think?

*** A careful reading of the language envisions the more general case you
probably care about (and if not, it would be good to know what you are
referring to), i.e., it states that there may be different FEC Payload IDs
for "source packets" and "non-source packets", where "non-source packets"
are packets that contain at least one repair symbol (but could for example
carry source symbols as well, depending on the FEC scheme).  The idea is for
example that receivers that do not have the FEC code can receive source
packets and interpret the Source FEC Payload ID and simply discard the
non-source packets (although distinguishing between source and non-source
packets is an issue that needs to be solved at a higher level than the FEC
building block protocol -- and this is stated in this FEC building block
draft).  It also allows for example p2p repair using only source packets for
a sender that does not have the FEC encoder, i.e., the sender can create the
source packets for the FEC Encoding ID without actually having the FEC
encoder.  It is also possible when defining a new FEC Encoding ID that the
actual FEC Payload ID defined has optional parts that can be used within the
context of that FEC Encoding ID to distinguish between different packets on
a different basis than "source" versus "non-source", but this is too
detailed and low level to describe in the general FEC building block.



Thank you,

Ramakrishna Vedantham
Nokia Research Center

----------------------------------------------------------------------
Nokia                 		| Phone +1-972-374-1922
6000 Connection Dr,           | Fax   +1-972-894-5937
Irving, TX 75039, USA		 	| mailto:
[email protected]
www.nokia.com/openness
----------------------------------------------------------------------





-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of ext
Lorenzo Vicisano
Sent: Monday, September 12, 2005 1:36 AM
To: [email protected]
Subject: Re: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call


Correcting my own typo: the deadline is Monday September 26th,
not 27th.

	thank you,
	Lorenzo


On Sun, Sep 11, 2005 at 11:14:36PM -0700, Lorenzo Vicisano wrote:
> Please be advised that this email starts RMT working group
> last-call for draft-ietf-rmt-fec-bb-revised-01.
> 
> Please provide your comments by Monday September 27th, if
> any.
> 
> Additional notes:
> 
> draft-ietf-rmt-fec-bb-revised-01 is a revision of RFC 3452, FEC
> Building Block, intended to obsolete RFC 3452 and to move the FEC BB to
> the Standard Track category. Please note that, although this building
> block specification might not be fully backward compatible with RFC
> 3452, the overall revision process of RMT Experimental RFCs strives to
> produce backward-compatible protocol instantiations.
> 
> 	thank you,
> 	Lorenzo Vicisano
> 
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmt

_______________________________________________
Rmt mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmt

_______________________________________________
Rmt mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmt