Thanks for the explanations. My comments are inline (starting with
**RV**)
Regards,
Ramakrishna Vedantham.
>-----Original Message-----
>From: ext Michael Luby [mailto:[email protected]]
>Sent: Tuesday, September 20, 2005 5:24 PM
>To: Vedantham Ramakrishna (Nokia-NRC/Dallas);
>[email protected]; [email protected]
>Cc: [email protected]
>Subject: RE: [Rmt] 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).
**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.
>
>
>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
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.