RE: [Fecframe] IETF 67

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

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.

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