Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

From: [email-masked]
Date: Tue, 20 Sep 2005 18:08:01 -0500

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--------
Do the CDPs mentioned in the drafts include only file delivery protocols like FLUTE or do they include stuff like "MBMS streaming framework"?
Is the draft "Raptor FEC Scheme" meant for only file delivery protocols?

For example, section 3.1 defines a single FEC Payload ID format (SBN,ESI) for both source and repair packets, whereas the MBMS streaming framework defines different FEC payload ID formats for source and repair packets i.e., for Source packets FEC Payload ID = (SBN,ESI) and for repair packets it is (SBN,ESI,SBL).

A possible fix for this problem would be to state in section 3.1 that (SBN,ESI) pair is the minimal set of parameters in the FEC payload ID defined in any CDP that uses Raptor FEC. Do you propose any alternative fixes?

--------Comment-2--------
For file download protocols, the "scheme-specific FEC-OTI" is given by (Z, N, Al).
For MBMS streaming framework, what is the corresponding value of "scheme-specific FEC-OTI"? 
My guess is (Z=1, N=1, Al). And in MBMS streaming framework, this is signaled in the "oti-extension" field of the SDP.
Can you confirm this?

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: Tuesday, September 13, 2005 6:54 PM
To: Michael Luby
Cc: Walsh Rod (Nokia-NRC/Tampere); [email-masked]
Subject: Re: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

Mike,

the two WGLCs are overlapped: both drafts are in
right now and feedback is welcome for both of them,
we jsut moved the deadline for Raptor by one week.

Considering the normal IETF times, this is unlikely to have
an impact in the date of publication of the RFC.

> wglc back by a week, and there are some good reasons why it would be good to
> have the FEC bb and the Raptor wglcs finished by the end of the week of
> September 26.  I've never seen another IETF wg that tried to keep the wglcs

please state the reasons.

Note that this is a fairly informal process: if needed we can
delay asking the IESG to review the FEC BB.. in case something
comes up to require another WGLC. Also note that other FEC IDs
are behind and still have to enter WGLC.

	thanks,
	Lorenzo

On Tue, Sep 13, 2005 at 04:24:27PM -0700, Michael Luby wrote:
> All,
> I don't understand this.  Rod admittedly is going to do his wglc review at
> the last minute on the last day, and for this the Raptor wglc is pushed back
> a week?  I don't understand why this is a reasonable argument to push the
> non-overlapped, and if I remember correctly the first time around the FEC
> bb, the LCT bb and the ALC pi were all in wglc at exactly the same time and
> all finished wglc at exactly the same time within the RMT wg.
> Mike
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Lorenzo Vicisano
> > Sent: Tuesday, September 13, 2005 11:31 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call
> >
> >
> > Rod,
> >
> > this is reasonable: let's make October 3rd the feedback deadline for
> > draft-ietf-rmt-bb-fec-raptor-object-02.
> >
> > 	thanks,
> > 	Lorenzo
> >
> > On Tue, Sep 13, 2005 at 04:53:04PM +0300, [email-masked] wrote:
> > > Hi Lorenzo et al.
> > >
> > > Is there any chance of shifting the raptor date back one week so we
> > > don't have to do two reviews at the last minute on the same day?
> > >
> > > (Yes I feel ashamed for openly admitting to leaving reviews to the last
> > > minute - I know I'm not the only one though :)
> > >
> > > Cheers, Rod.
> > >
> > >
> > >
> > > >-----Original Message-----
> > > >From: [email-masked] [mailto:[email-masked]] On
> > > >Behalf Of ext Lorenzo Vicisano
> > > >Sent: 12 September, 2005 09:34
> > > >To: [email-masked]
> > > >Subject: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call
> > > >
> > > >Please be advised that this email starts RMT working group
> > > >last-call for draft-ietf-rmt-bb-fec-raptor-object-02.
> > > >
> > > >Please provide your comments by Monday September 26th, if any.
> > > >
> > > >	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

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

---

From: "Michael Luby" <[email-masked]>
Date: Tue, 20 Sep 2005 17:00:35 -0700

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, September 20, 2005 4:08 PM
To: [email-masked]; [email-masked]
Subject: RE: [Rmt] draft-ietf-rmt-bb-fec-raptor-object-02 WG Last Call

Hi,

--------Comment-1--------
Do the CDPs mentioned in the drafts include only file delivery protocols
like FLUTE or do they include stuff like "MBMS streaming framework"?
Is the draft "Raptor FEC Scheme" meant for only file delivery protocols?

*** Good point, this specification is only for file/object delivery (since
there is currently no CDP that supports FEC protection of streaming within
the IETF in the context of the FEC building block, something we are trying
to fix, more on this below), and thus the title should be changed to "Raptor
FEC Scheme for Object Delivery".  The file name for the draft already
includes "object", btw, but the word "object" is not reflected in the title
of the draft and it should be.  This draft is in alignment with the file
download specification of 3GPP MBMS.

For example, section 3.1 defines a single FEC Payload ID format (SBN,ESI)
for both source and repair packets, whereas the MBMS streaming framework
defines different FEC payload ID formats for source and repair packets i.e.,
for Source packets FEC Payload ID = (SBN,ESI) and for repair packets it is
(SBN,ESI,SBL).

*** See the first comment above.  When the FEC streaming framework is
adopted into the IETF, then we will introduce Raptor into the IETF that will
include the details you mention above (and whatever it takes to be in
alignment with 3GPP MBMS streaming, or more accurately whatever is adopted
within the IETF eventually on this subject, which hopefully is in alignment
with what was done for 3GPP MBMS.)

A possible fix for this problem would be to state in section 3.1 that
(SBN,ESI) pair is the minimal set of parameters in the FEC payload ID
defined in any CDP that uses Raptor FEC. Do you propose any alternative
fixes?

--------Comment-2--------
For file download protocols, the "scheme-specific FEC-OTI" is given by (Z,
N, Al).
For MBMS streaming framework, what is the corresponding value of
"scheme-specific FEC-OTI"? 
My guess is (Z=1, N=1, Al). And in MBMS streaming framework, this is
signaled in the "oti-extension" field of the SDP.
Can you confirm this?

*** The FEC-OTI for Raptor within the MBMS streaming framework is as you
say.  This will be defined within the IETF once there is a context in which
to define it.  Hopefully, the FEC streaming framework work that was done
within 3GPP for MBMS will be officially accepted as an IETF wg item
somewhere (or a new wg started in which this work can progress) at the next
IETF.

Thank you,

Ramakrishna Vedantham
Nokia Research Center

-----Original Message-----

Mike,

	thanks,
	Lorenzo