Re: [Fecframe] IETF 67

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

Plea for Agenda Items

So far we have Mark presenting the "final" version of the reqs doc -
which incorporates input from the last WG meeting.

And possibly Mark presenting the problem statement.

A possible 3rd agenda item could be a proposal to change the WB name
to "Mark". ;-)

Anything else?

Thanks,
Greg

On 10/10/06, Marshall Eubanks <[e-mail]> wrote:
> Sorry, don't know how this got out like the below. Here is the
> complete version :
>
> I met with Mark Watson in Broomfield, Colorado, last week. We
> discussed the
> requirements document,
> draft-ietf-fecframe-req-00 , which I think still needs
> a careful review. I volunteered to provide that review.
>
> My feeling is that we are probably ready to move to the next step,
> and Mark volunteered to
> take the lead in writing the problem statement.
> If anyone wants to participate in  this, please contact us or Mark
> directly.
>
> I would like to get consensus on the requirements document by San
> Diego, and hopefully
> we will also have a first look at the problem statement.
>
> We need to set up an agenda for San Diego, so if anyone has
> suggestions for agenda items, please send them to us.
>
> Regards
> Marshall
>
> On Oct 9, 2006, at 4:44 PM, Marshall Eubanks wrote:
>
> > I met with Mark Watson
> > On Oct 9, 2006, at 4:25 PM, Greg Shepherd wrote:
> >
> >> 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
> >
>
>

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