From fecframe-bounces@ietf.org Tue Sep 12 07:37:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN6Zn-0005d1-LY; Tue, 12 Sep 2006 07:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN6Zm-0005b5-RL for fecframe@ietf.org; Tue, 12 Sep 2006 07:37:14 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN6Zk-00084i-KU for fecframe@ietf.org; Tue, 12 Sep 2006 07:37:14 -0400 Received: by wr-out-0506.google.com with SMTP id i32so442509wra for ; Tue, 12 Sep 2006 04:37:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fE+MGDd1blE8q2WjoTeckI7fYb6HTVDGQfP5hAFhmJIM3tDjcmUPWTEvRxpqDFLAQQgGJahRXFOMHDlOfmbzriPy0fL9CD/O7WbWA8i+4+GZQ3QNfrvt85GVMHV7mdOrlWn789QXOV0EzFxeM9DaZ8mRdYGzxepJyXbcjNX0xsw= Received: by 10.90.117.15 with SMTP id p15mr2002334agc; Tue, 12 Sep 2006 04:37:12 -0700 (PDT) Received: by 10.90.67.14 with HTTP; Tue, 12 Sep 2006 04:37:12 -0700 (PDT) Message-ID: <38c19b540609120437s72c14082i819b0be5fb0e6781@mail.gmail.com> Date: Tue, 12 Sep 2006 04:37:12 -0700 From: "Greg Shepherd" To: fecframe@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Fecframe] IETF 67 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org 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. Cheers, Greg _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Sep 12 13:11:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNBnL-00030B-TC; Tue, 12 Sep 2006 13:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNBnK-000306-G5 for fecframe@ietf.org; Tue, 12 Sep 2006 13:11:34 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNBnJ-00024Y-4R for fecframe@ietf.org; Tue, 12 Sep 2006 13:11:34 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id DEF38C278 for ; Tue, 12 Sep 2006 13:11:25 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k8CHBPJD007226; Tue, 12 Sep 2006 13:11:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k8CHBOFw001078; Tue, 12 Sep 2006 13:11:24 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 00953-01; Tue, 12 Sep 2006 13:11:23 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id k8CHBLlR001051;Tue, 12 Sep 2006 13:11:21 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 3C5914FCDE; Tue, 12 Sep 2006 13:11:46 -0400 (EDT) Date: Tue, 12 Sep 2006 13:11:46 -0400 From: Wesley Eddy To: Greg Shepherd Subject: Re: [Fecframe] IETF 67 Message-ID: <20060912171146.GD30006@grc.nasa.gov> References: <38c19b540609120437s72c14082i819b0be5fb0e6781@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38c19b540609120437s72c14082i819b0be5fb0e6781@mail.gmail.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.042 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:4 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org 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 Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Sep 12 13:25:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNC0X-0000L0-SL; Tue, 12 Sep 2006 13:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNC0W-0000Kv-FC for fecframe@ietf.org; Tue, 12 Sep 2006 13:25:12 -0400 Received: from exvs01.ex.dslextreme.net ([66.51.199.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNC0V-0003Ke-4t for fecframe@ietf.org; Tue, 12 Sep 2006 13:25:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Fecframe] IETF 67 Date: Tue, 12 Sep 2006 10:24:32 -0700 Message-ID: <277CB7DD1E4B4C4C860484C00389C9C978540C@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] IETF 67 Thread-Index: AcbWjoujld0xrw3kTaykmPOa1LcuygAAHIbQ From: "Mark Watson" To: , "Greg Shepherd" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org Hi Wesley, Good point. This kind of consideration would be a good addition to the draft.=20 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:weddy@grc.nasa.gov]=20 Sent: Tuesday, September 12, 2006 10:12 AM To: Greg Shepherd Cc: fecframe@ietf.org Subject: Re: [Fecframe] IETF 67 On Tue, Sep 12, 2006 at 04:37:12AM -0700, Greg Shepherd wrote: > Hello, >=20 > We're coming up on IETF 67 and our next milestone of approving our > requirements as presented in: >=20 > draft-ietf-fecframe-req-00 >=20 > 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. ;-) >=20 > 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. >=20 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. --=20 Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 25 13:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRuY6-0005A1-B7; Mon, 25 Sep 2006 13:47:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRuY5-00059w-Ku for fecframe@ietf.org; Mon, 25 Sep 2006 13:47:21 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRuY4-00067L-B5 for fecframe@ietf.org; Mon, 25 Sep 2006 13:47:21 -0400 Received: by wr-out-0506.google.com with SMTP id i5so673077wra for ; Mon, 25 Sep 2006 10:47:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qx9LwRg/+U1q2nOQ5vWEVghG0ydW5jd8ITtpITJnqDxp0VVnU829ZUTzKjOgJWvvxdAntYF/79o28oT07LPwGBwvbLDggXKxTMS5E4g9kzuvanM5RZ8DZBqCkvzueFwgvsRlmajSEK0PO5ni+x4DRnrhe45oxHgyx4ABYqHKoMQ= Received: by 10.90.94.2 with SMTP id r2mr1666525agb; Mon, 25 Sep 2006 10:47:19 -0700 (PDT) Received: by 10.90.81.6 with HTTP; Mon, 25 Sep 2006 10:47:19 -0700 (PDT) Message-ID: <38c19b540609251047p68e421b3n93f95ea16e902640@mail.gmail.com> Date: Mon, 25 Sep 2006 10:47:19 -0700 From: "Greg Shepherd" To: "Mark Watson" Subject: Re: [Fecframe] IETF 67 In-Reply-To: <277CB7DD1E4B4C4C860484C00389C9C978540C@EXVS01.ex.dslextreme.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <277CB7DD1E4B4C4C860484C00389C9C978540C@EXVS01.ex.dslextreme.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: fecframe@ietf.org X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fecframe-bounces@ietf.org On 9/12/06, Mark Watson 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:weddy@grc.nasa.gov] > Sent: Tuesday, September 12, 2006 10:12 AM > To: Greg Shepherd > Cc: fecframe@ietf.org > 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 > Fecframe@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe