Re: [Fecframe] IETF 67

["Greg Shepherd" <[e-mail]>]

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