Re: [Fecframe] IETF 67

[Marshall Eubanks <[e-mail]>]

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