RE: [Fecframe] IETF 67

["Mark Watson" <[e-mail]>]

Hi Greg,

The main advantage that could be expected from fitting streaming into
the RMT FEC BB would be that FEC Schemes already defined by RMT could be
reused for streaming without modification.

However, I'm not sure that would actually work, for the following
reasons:

Firstly, the FEC Schemes defined in RMT envisage objects with a finite
size. So, to map streaming to this we would need to consider a stream as
a sequence of FEC BB-style objects. We would then need to communicate
the FEC Object Transmission Information for each object with that
object. This could be done, but the problem is that for many FEC Schemes
there would be advantages if certain pieces of FEC Object Transmission
Information could be the same for every block (for example it makes
sense in some cases for the Symbol Size and Block Size to be the same
for every block). It's advantageous to be able to inform the receiver
that these parameters won't change and also more efficient to signal
them once, out-of-band, than with every block.

Without streaming-specific additions to the FEC Scheme you could not
specify how this "stream-level" FEC OTI was communicated to the
receiver. So, you would not achieve the original aim of re-using the FEC
Schemes without modification anyway.

Secondly, FEC Schemes in RMT generally also include recommendations for
parameter settings, which are based on single-object delivery. Although
not essential it would be a good thing for people to provide
recommendations for streaming cases too - which may be different for a
variety of reasons.

Given that we need streaming-specific modifications to FEC Schemes
anyway, it seems better to me to do this cleanly. This does not mean
that we lose the work done in RMT, but that we recognize that re-use of
an RMT FEC Scheme for FECFRAME doesn't come for free - it requires a
little work.

A third reason is the question of how streaming source data is formatted
into data blocks that an 'object-based' FEC Scheme could process. RMT
FEC Schemes expect an object which is just a sequence of bytes. For
streaming we need to build such an object out of a sequence of
potentially variable-length source packets. We then have the problem
that we don't just send the symbols generated by the FEC Scheme, but we
may wish to send the original source packets themselves. The mapping
between the source block that the RMT FEC Scheme understands and the
Source Packets themselves may again be something where specification
material which is both FEC-Scheme-specific and Streaming-specific is
needed. This was a topic of discussion at the last meeting: The 3GPP FEC
streaming framework makes this issue FEC-Scheme-independent (if that can
be claimed of a spec which includes only one FEC Scheme!), whereas I had
proposed last time we allow also for FEC-Scheme-specific approaches. We
did not conclude on this, but I would propose that we allow FEC Schemes
to specify their own approach (and of course, the Raptor FEC Scheme will
use the 3GPP one to align with 3GPP's use of Raptor).

Regards,

Mark Watson

-----Original Message-----
From: Greg Shepherd [mailto:[e-mail]] 
Sent: Monday, October 09, 2006 4:25 PM
To: Mark Watson
Cc: [e-mail]; [e-mail]
Subject: Re: [Fecframe] IETF 67

Wow, no answers... no flames even. Maybe I need to be more offensive
to get some discussions going. ;-)

That said, where are we with agenda items for the IETF 67?

As per our charter we have a milestone after this meeting for a WG
approval of the reqs draft to move it up the tree.

Can someone take the roll of eloquently stating the pros/cons of
making streaming fit into an existing FEC BB (RMT) vs FECFrame BB
defining streaming outside of RMT.

Cheers,
Greg

On 9/25/06, Greg Shepherd <[e-mail]> wrote:
> On 9/12/06, Mark Watson <[e-mail]> wrote:
> > Hi Wesley,
> >
> > Good point. This kind of consideration would be a good addition to
the
> > draft.
> >
> > The RMT FEC Building Block does indeed provide a lot of what we
need.
> > The main differences are in places where the FEC BB makes
assumptions
> > related to the delivered data being a single 'object' rather than a
> > collection of streams/packet flows.
> >
> > Streams/packet flows have some additional properties - such as
somewhat
> > different needs for timely delivery, the fact that packet sizes for
> > source packets are a property of the stream, not something that the
FEC
> > mechanism can determine as with object delivery and the requirement
to
> > protect multiple streams together.
> >
> > Now, one approach would be to define a way to map a collection of
> > streams/packet flows into an 'object' of the kind addressed in the
FEC
> > BB and then concatenate this mapping with what we already have in
the
> > FEC BB.
> >
> > This might be a little contrived though, so I think what we are
aiming
> > at is essentially a 'stream/packet flow' version of the FEC BB -
reusing
> > as much as possible of course.
> >
> > As with the FEC BB, there is an open question about exactly what
> > functionality to specify in the BB and what to delegate to FEC
Schemes.
> > Delegation has the advantage of generality, whereas specification at
the
> > FEC BB has the advantage of introducing greater commonality between
> > different instantiations of the whole system.
>
> So which direction do we take? Should this be an agenda item for the
> upcoming meeting? To stay on track we should have the framework draft
> ready for submission after IETF 67 so getting the discussion going now
> is best.
>
> I agree that stuffing streaming functions into an object to make it
> fit FEC BB is a bit contrived, but can it be done? What functionality
> would be compromised? Would this prevent extensibiliy in streaming
> functions over having an independent (though inheriting) FECFrame
> spec?
>
> Greg
>
> > Regards,
> >
> > Mark
> >
> > -----Original Message-----
> > From: Wesley Eddy [mailto:[e-mail]]
> > Sent: Tuesday, September 12, 2006 10:12 AM
> > To: Greg Shepherd
> > Cc: [e-mail]
> > Subject: Re: [Fecframe] IETF 67
> >
> > On Tue, Sep 12, 2006 at 04:37:12AM -0700, Greg Shepherd wrote:
> > > Hello,
> > >
> > > We're coming up on IETF 67 and our next milestone of approving our
> > > requirements as presented in:
> > >
> > > draft-ietf-fecframe-req-00
> > >
> > > Since IETF 66 there has been little or no discussion on the list
> > > regarding the reqs, or anything else for that matter. Heck, many
other
> > > IETF WG lists find plenty of non-issues to flame about but we
can't
> > > even find the time or interest to discuss real topics. ;-)
> > >
> > > So, please, read the above req draft and send your feedback here
to
> > > the list. Sure, we could move the draft forward with the
assumption
> > > that no feedback is positive feedback but that seems a bit
> > > disingenuous and actually pretty boring to be honest.
> > >
> >
> > I've read the draft.  Since the RMT FEC building block is described
as
> > the basis for FECFRAME, I think there should be a short section on
why
> > the FEC building block alone isn't sufficient for FECFRAME's goals.
> > Looking at the requirements, the FEC building block meets many of
these
> > already, so it would be valuable to discuss exactly which
requirements
> > require additional mechanisms.  Without this kind of "gap-analysis"
of
> > the existing solution, the real goal of the work is unclear.
> >
> > Also, a minor comment, I'd prefer if the requirements were numbered
in
> > units of 1's rather than in 10's, but this really doesn't matter.
There
> > are also two requirements numbered 30 in the 00 version of the
draft.
> >
> > --
> > Wesley M. Eddy
> > Verizon Federal Network Systems
> >
> > _______________________________________________
> > Fecframe mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/fecframe
> >
>

_______________________________________________
Fecframe mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/fecframe