RE: [Fecframe] IETF 67

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

Greg, Marshall,

I submitted a first draft proposal for the FEC Framework itself as:

draft-watson-fecframe-framework-00

(http://www.ietf.org/internet-drafts/draft-watson-fecframe-framework-00.
txt)

So, I could make a presentation on this.

This is the document that I spoke to Marshall about, but perhaps there
has been some mis-communication, since he refers below to a "problem
statement" - do we need a more detailed problem statement than the
Charter itself and the requirements document ?

Btw, I submitted the proposal above in part to try and encourage more
comments as well as to progress the work. I agree that the requirements
need a bit more review and we can progress that in parallel with the
solution.

Renaming the working group and giving me total dictatorial power would
be just fine ... but perhaps that is not allowed under IETF rules ?

...Mark

-----Original Message-----
From: Greg Shepherd [mailto:[e-mail]] 
Sent: Friday, October 20, 2006 10:14 AM
To: Marshall Eubanks
Cc: Mark Watson; [e-mail]
Subject: Re: [Fecframe] IETF 67

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