Subject: RE: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call

From: [email-masked]
Date: Tue, 20 Sep 2005 17:59:49 -0500

Hi,
Here are some minor editorial corrections to this draft.

Editorial corrections:

Section-1
Old:	1.  CDPs can be designed to operate with a range of different FEC codes/scheme, 
New:	1.  CDPs can be designed to operate with a range of different FEC codes/schemes, 

Section-4
Old:	FEC codes are a valuable basic component of any CDP
New:	FEC code is a valuable basic component of any CDP

Section 6.1
A value for the FEC Encoding ID MUST be reserved and associated with the types, semantics and encoding format of the FEC Payload ID and the the FEC Object Transmission Information.
The party that owns this tuple MUST be able to provide information on how to obtain the the Under-Specified FEC scheme instance

Please remove "the the" repetition in both sentences.

Section-6.2
Old:	1.  A means to reliably communicated the Common FEC Object Transmission Information 
New:	1.  A means to reliably communicate the Common FEC Object Transmission Information  

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-masked]
www.nokia.com/openness
----------------------------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
Lorenzo Vicisano
Sent: Monday, September 12, 2005 1:36 AM
To: [email-masked]
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-masked]
> https://www1.ietf.org/mailman/listinfo/rmt

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

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

---

From: [email-masked]
Date: Mon, 26 Sep 2005 10:51:50 -0500

Thanks for the explanations. My comments are inline (starting with
**RV**) 
Regards,
Ramakrishna Vedantham.

>From: ext Michael Luby [mailto:[email-masked]] 
>Sent: Tuesday, September 20, 2005 5:24 PM
>To: Vedantham Ramakrishna (Nokia-NRC/Dallas); 
>[email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: RE: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call
>
>Comments inline (paragraphs that start with ***).
>
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of [email-masked]
>Sent: Tuesday, September 20, 2005 3:56 PM
>To: [email-masked]; [email-masked]
>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).

**RV** It would be good to make it more explicit because in the original
set of 
RFCs on ALC and LCT,  the term "content delivery" was used mean "file
delivery".
For example see the abstract of the RFC 3451. 
"Layered Coding Transport (LCT) provides transport level support for
reliable content delivery and stream delivery protocols." 

**RV**In addition, the existing RFCs for streaming delivery that use
some kind of FEC e.g. RFC 2733, ULP and UXP drafts may need
modifications or newer versions.
Do we need to care about these issues in the design of FEC BB, OR
specify that it is out of scope of this draft?

>
>--------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.  

**RV** The situation I am referring to is "in the first transmission, I
send source packets in the first case (e.g., using FEC Encoding ID = 0).
In the second transmission, I send a combination of source and repair
packets (e.g., using FEC Encoding ID = 1)."
How does the use of same FEC Encoding ID in both transmissions help in
this situation?

>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).
>

**RV** Why do we need a separate bit to distinguish between a source and
a repair packet? As you stated, it is a higher level protocol issue,
which is already solved.
In download protocols, based on the CodePoint (which signals FEC Encodng
ID) and the other FEC-OTI (which specifies the source block structure),
the receiver knows which FEC Payload ID corresponds to the souce packet
and which FEC Payload ID corresponds to the repair packet.
In streaming protocols, source and rapair streams are sent to different
UDP ports. Any other form of RTP multiplexing may be used to distinguish
between source and repair packets.

>--------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.)

**RV** So your proposal is to use the same FEC Encoding ID but a new FEC
Instance ID for the new under-specified scheme.
When they are fully-specified, they wll get a new FEC Encoding ID (in
the range 0-127).
But if the two under-specified FEC schemes (old and new) are entirely
different (e.g. LDPC vs RS), then shouldn't they use different FEC
Encoding IDs?

>--------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.

**RV** The motivations to use a systematic FEC scheme are very good and
well justified.
But by stating "Where two FEC Payload ID formats are specified, then the
FEC scheme MUST be a systematic FEC code", we are mandating that all FEC
schemes that specify two FEC Payload IDs MUST be systematic. It need not
be the case always. A non-systematic FEC scheme may also specify two
different FEC Payload IDs.
The FEC-BB seems to mandate systematic FEC in this way.

>From: [email-masked] [mailto:[email-masked]]On 
>Behalf Of ext Lorenzo Vicisano
>> 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:
>> 
>> 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
>>

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 26 Sep 2005 12:52:39 -0400

Hi Ramakrishna, 

--Comment w--
You wrote:

I think in this situation, although the second transmission may be the
same 'file', it is a different 'object', with a different Transport
Object Identifier. So then there is no restriction that prevents the
case you describe.

Nevertheless, it would be more efficient to use just FEC Encoding ID 1
and send the appropriate amount of source symbols to account for
receivers which could not make use of repair symbols.

You are right that distinguishing between source and repair packets in
the case where the FEC Scheme defines separate source and repair FEC
Payload ID formats is a content delivery protocol issue. So, your
example for RTP where different ports are used is a good one. It's been
suggested that a similar capability in LCT would be useful - hence the
proposal to allocate the presently reserved bit for this purpose. But at
the moment there are no FEC schemes that would need it.

--Comment 4--

The point here is that FEC Schemes can include whatever they like inside
the FEC Payload ID - they can have optional or conditional fields etc.
so long as the FEC Scheme can parse the contents. So, for the purpose of
the FEC Scheme alone there should not be any need to have "different FEC
Payload ID formats".

However, in the specific case of systematic FEC codes, then there is a
requirement for receivers to be able to partially support the FEC scheme
by supporting only the reception of source data and not supporting the
FEC decoder. So, in this case we provide the possibility to expose the
potentially different formats for the FEC Payload ID in the "source
symbols only" case and the "including repair symbols" case at the layer
above.

...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, September 26, 2005 8:52 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call