Re: [Fecframe] IETF 67

[Marshall Eubanks <[e-mail]>]

Dear Mark;

On Oct 20, 2006, at 3:04 PM, Mark Watson wrote:

> 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 ?
>

No, I must have heard something wrong or been confused - my notes  
from our drive to the airport mention the problem statement but the  
above is the clearly the document we were talking about.

> 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.
>

I would agree. Is there anyone else with agenda items ?

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

> ...Mark

Marshall

>
> -----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