Re: [Fecframe] IETF 67

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

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