From fecframe-bounces@ietf.org Mon Dec 03 17:20:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJdz-0008Po-GA; Mon, 03 Dec 2007 17:20:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJdy-0008PT-5i; Mon, 03 Dec 2007 17:20:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJdx-0007wG-Qh; Mon, 03 Dec 2007 17:20:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 96148327BC; Mon, 3 Dec 2007 22:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzJdx-0001D7-Ge; Mon, 03 Dec 2007 17:20:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 03 Dec 2007 17:20:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-req-02.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : FECFRAME requirements Author(s) : M. Watson Filename : draft-ietf-fecframe-req-02.txt Pages : 14 Date : 2007-12-03 This document defines requirements for a "FEC Framework" to be defined by the IETF FECFRAME working group. The object of this group is primarily to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-req-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fecframe-req-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-fecframe-req-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-03171717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fecframe-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fecframe-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-03171717.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe --NextPart-- From fecframe-bounces@ietf.org Mon Dec 03 17:55:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKCL-0004NX-0m; Mon, 03 Dec 2007 17:55:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKCJ-0004IQ-QK for fecframe@ietf.org; Mon, 03 Dec 2007 17:55:31 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzKCJ-0005Xl-97 for fecframe@ietf.org; Mon, 03 Dec 2007 17:55:31 -0500 X-IronPort-AV: E=Sophos;i="4.23,245,1194217200"; d="scan'208";a="19944157" Received: from vpnloria5.inrialpes.fr (HELO [194.199.16.133]) ([194.199.16.133]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2007 23:55:28 +0100 Message-ID: <47548961.8030403@inrialpes.fr> Date: Mon, 03 Dec 2007 23:55:29 +0100 From: Vincent Roca User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Fecframe] a few comments on draft-begen-fecframe-sdp-elements-00 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 Dear Ali, I've read you I-D and have a few comments. Some of them are probably a little bit naive, sorry in advance. They may also reflect the fact that the document is not selft-sufficient... Cheers, Vincent 1/ What are the relationships between this document and the RFC5052 (FEC Building Block)? This document is not mentionned at all in the references while there are implicit references. More specifically: - how does the concept of "scheme ID" relate to the "fully specified FEC scheme" or "undert-specified FEC scheme"? Is it an {FEC Enc. ID/ FEC Inst. ID} equivalent (or FEC Enc. ID in case of fully-specified scheme)? Clarification needed e.g., for section 3.3/bullet 3. This clarification is also needed since the document says that "Scheme ID needs to be registered with IANA" (section 4.5). - is the FSSI the same as the "Scheme Specific Elements" of RFC5052? 2/ section 3.3, bullet 4: - This paragraph is a little bit obscure. Instead of: "However, in the case that the Explicit Source FEC Payload ID is used" I think the author should say: "A value is greater than zero indicates that an explicit Source FEC Payload ID is used. However, in that case, only one FEC scheme..." - This paragraph does not indicate nor give any reference to the concept of "generic tag". The terms "tag" and "Source FEC Payload ID" seem to refer to the same thing, but it's not clearly stated. - It is suggested that multiple FEC schemes can be used when there is no explicit Source FEC Payload ID. Is that true and why? 3/ section 3.3, list of FEC Framework Config Info: Is this list exhaustive? For instance: - repair flows (bullet 1) are "identified", but not "defined" (unlike source flows, bullet 2.). - Is the identifier used for repair flows similar to the one used for source flows? - Is the FSSI sufficient to carry all FEC related parameters (see the question 1/ above on the relationship with RFC5052)? - the length of the FEC Payload ID is mentioned here, but not its content/format. Is it implied by the FEC Scheme (in a way similar to RFC5052)? This should be clarified. 4/ section 4.1 Transport protocol identifiers The differences between "fec/udp" and "udp/fec" are not clear. Latter on, in section 7 "IANA considerations", only two /FEC (in upper case this time) are defined. 5/ section 4.2: example in fig. 1 The example shows a complex source/repair mapping. Is this example realistic or is it a "view of the mind" meant to illustrate the flexibility of the underlying FEC framework? 6/ General question: Parameters carried within a Session Announcement are by nature applicable to the whole session. Is that sufficient or do we lack some flexibility to reflect a dynamic change in the session (e.g. when new source flows are added to the "group", or some source flows diseapper from the "group")? _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Dec 04 14:50:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdmZ-0005aw-Aj; Tue, 04 Dec 2007 14:50:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdmX-0005aj-Me for fecframe@ietf.org; Tue, 04 Dec 2007 14:50:13 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdmV-0005zu-HS for fecframe@ietf.org; Tue, 04 Dec 2007 14:50:13 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Dec 2007 11:50:08 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB4JoAY1006669; Tue, 4 Dec 2007 11:50:10 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB4Jo41n005597; Tue, 4 Dec 2007 19:50:08 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 11:50:03 -0800 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] a few comments on draft-begen-fecframe-sdp-elements-00 Date: Tue, 4 Dec 2007 11:50:02 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540620E27B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <47548961.8030403@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] a few comments on draft-begen-fecframe-sdp-elements-00 thread-index: Acg1/6CehTrla3HLRmayw8o6k8NQgQAqxHiw References: <47548961.8030403@inrialpes.fr> From: "Ali Begen (abegen)" To: "Vincent Roca" , X-OriginalArrivalTime: 04 Dec 2007 19:50:03.0452 (UTC) FILETIME=[DCABDFC0:01C836AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5312; t=1196797811; x=1197661811; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20a=20few=20comments=20on=20draft-begen-fe cframe-sdp-elements-00 |Sender:=20; bh=VxX3UrYWEPhmqeQmAqNUc1jxsFE+mhFmnX2asr1MhyI=; b=t7wU/22jS4SC86CYggmHvKN8L0nUJzks20tSIIilyOe1uifP4adfQRwStUkfjDMfVjgR8NbT /JZH6sfoVtMc+2Copsx/TVilezElhDYQOmwhlPEToV4pYfhrNJI20T013S3dQmg4Mx7Y3BrAuk fCct6SlPLw3+A+6DivL3gKjlY=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: 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 Vincent.=20 Thanks for the questions. Pls see inline.=20 > 1/ What are the relationships between this document and the=20 > RFC5052 (FEC Building Block)? This document is not mentionned=20 > at all in the references while there are implicit references. There are many similarities between the RMT and FECFrame WGs. If necessary, I will include appropriate references in the next submission. > More specifically: > - how does the concept of "scheme ID" relate to the "fully specified > FEC scheme" or "undert-specified FEC scheme"? Is it an {FEC Enc. ID/ > FEC Inst. ID} equivalent (or FEC Enc. ID in case of fully-specified > scheme)? Clarification needed e.g., for section 3.3/bullet 3. > This clarification is also needed since the document says=20 > that "Scheme > ID needs to be registered with IANA" (section 4.5). > - is the FSSI the same as the "Scheme Specific Elements" of RFC5052? Scheme IDs have to be registered with IANA. See the framework draft Section 6.6. It has all the details regarding the FEC Scheme requirements. I believe the SDP draft should just mention about these requirements in a summarized form.=20 Regarding the FSSI field, it is everything that the FEC scheme requires specifically for a proper operation. The details of what will be included in that field depends on the FEC scheme. So, it is pretty much the same thing the RFC 5052 refers to as "Scheme-Specific FEC Object Transmission Information Element." > 2/ section 3.3, bullet 4: > - This paragraph is a little bit obscure. > Instead of: > "However, in the case that the Explicit Source FEC=20 > Payload ID is used" > I think the author should say: > "A value is greater than zero indicates that an explicit Source > FEC Payload ID is used. However, in that case, only one=20 > FEC scheme..." > - This paragraph does not indicate nor give any reference to=20 > the concept > of "generic tag". The terms "tag" and "Source FEC Payload=20 > ID" seem to > refer to the same thing, but it's not clearly stated. I will make this more clear in the next submission. Generic tag, I believe, should be defined in the framework draft, not in here. Good point. > - It is suggested that multiple FEC schemes can be used when there > is no explicit Source FEC Payload ID. Is that true and why? Yes, if none of those FEC schemes modify the source packets, you can use any number of different repair flows to protect the source flow.=20 > 3/ section 3.3, list of FEC Framework Config Info: > Is this list exhaustive? For instance: > - repair flows (bullet 1) are "identified", but not "defined" > (unlike source flows, bullet 2.). Repair flows are already defined by their protocol identifiers. But for the source flow, we need a common way within the framework instance to define them. Once we know how to define them, we assign identifiers to them as we do the same for the repair flows.=20 > - Is the identifier used for repair flows similar to the one used > for source flows? Yes, internally we will simply use integer identifiers for both repair and source flows. > - Is the FSSI sufficient to carry all FEC related parameters (see > the question 1/ above on the relationship with RFC5052)? It should be. If some information about the scheme cannot be put somewhere in the common fields of the SDP, it will go to the FSSI field. > - the length of the FEC Payload ID is mentioned here, but not its > content/format. Is it implied by the FEC Scheme (in a way similar > to RFC5052)? This should be clarified. Are you suggesting I should define the "Source FEC Payload ID" here? And, yes, the FEC scheme determines the length of this field.=20 >=20 >=20 > 4/ section 4.1 Transport protocol identifiers The differences=20 > between "fec/udp" and "udp/fec" are not clear. 'fec/udp' is for the source flows. And 'udp/fec' is for the repair flows.=20 > Latter on, in section 7 "IANA considerations", only two=20 > /FEC (in upper case this time) are defined. I'll fix this. >=20 >=20 > 5/ section 4.2: example in fig. 1 > The example shows a complex source/repair mapping. Is this=20 > example realistic or is it a "view of the mind" meant to=20 > illustrate the flexibility of the underlying FEC framework? The goal is to illustrate that we support complex combination of source/repair flows. It is not necessarily the best or the only to do what you want to do. >=20 >=20 > 6/ General question: > Parameters carried within a Session Announcement are by=20 > nature applicable to the whole session. Is that sufficient or=20 > do we lack some flexibility to reflect a dynamic change in=20 > the session (e.g. when new source flows are added to the=20 > "group", or some source flows diseapper from the "group")? This is a valid question. In case there is a change in the offerings, a new SDP should be sent to the receiver(s), I believe. We are not doing in-band signaling. So, sending a new SDP is probably the easiest solution.=20 Let me know if I skipped something. -acbegen > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www1.ietf.org/mailman/listinfo/fecframe >=20 _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun Dec 30 05:55:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8vpH-0006Le-3S; Sun, 30 Dec 2007 05:55:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8vpG-0006LY-D1 for fecframe@ietf.org; Sun, 30 Dec 2007 05:55:26 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8vpF-0000S4-KL for fecframe@ietf.org; Sun, 30 Dec 2007 05:55:26 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2949651rvb.49 for ; Sun, 30 Dec 2007 02:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=VOF3bDSe6lSqRi21vHYHn03+DC0CdWiqYi6GlGzyWBM=; b=o6Op6narqBrWFcVNOdkOkF3pM1oT6fYtg6V0C1G9/0BWWVpO8eLfNlGS1l9CtJxy72gqSj+X52ZonrZppnxtSlCu+vktTkID1Mpcolb3Wi8kESv8GoVCajVwooM46ivy5go8ZGtUC/vMx8ITCG8tjyRUFTU3PO3IyYIeqd9qc5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=O/B9cQ0qvo8pkKwK77pIJvA4ehPQieOZYY/bmAHzitvm2MfjASopwropk3TrY5N7EBavXsMjt+nbhQmH8ol2+bPZr2y1OfGrto/HwX/t8eOHULS3qmksrBmj3QZlx8ltC/SieJdCBKt8OsINWTvzvdDJPfUv/WGlro5YaVVAVjg= Received: by 10.142.226.2 with SMTP id y2mr3447319wfg.64.1199012124494; Sun, 30 Dec 2007 02:55:24 -0800 (PST) Received: by 10.142.179.21 with HTTP; Sun, 30 Dec 2007 02:55:24 -0800 (PST) Message-ID: <38c19b540712300255o46b126cbq96613d552f734947@mail.gmail.com> Date: Sun, 30 Dec 2007 02:55:24 -0800 From: "Greg Shepherd" To: fecframe@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Subject: [Fecframe] Draft Minutes 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 Please read and send me any comments/corrections Thanks, Greg -------- Marshall - Summarized the design protocol team's work. Magnus - Pointed out an error on the slide that SDP is not a protocol Mark - Presented the update on -01 version of framework. Greg - Asked the AD about freezing the draft? Magnus - Clarified that he could resurrect the draft !!! Magnus - Requested to compress the ASCII diagram Dave - Mark - Should it be WGLC independent of SDP draft? Marshal - Has been done before. Ask the group! Magnus - Perhaps, worth waiting due to ISEG processes. Move the req and framework docs together. Marshal - let's move both of them together forward for LC Rajiv - I agree. Magnus - Systematic vs non-systematic!! Marshall - Clarified the fairness due to congestion. Magnus - Network feedback should be utilized Lorenzo - Congestion control is not quite problem in this context. backward compatible?? Mark - Yes. Compatible. Rajiv - No strong opinion. Let's not hardcode the framework to systematic code. While the preference is for the systematic code, Mark - We should also include some verbiage Ali - Magnus - Different FEC codes may be selected due to different bitrates and IPR issues. Let's not lock-in to just systematic code. Mark - IPR has not been discussed yet. May already exist. Ali - Makes more sense to prefer systematic code. Greg - No technical reason to not include non-systematic code. Ali - presents his SDP draft. Dave - Something subtle here, both sender and receiver must get the necessary CDP information in order to configure themselves. How it gets conveyed is independent. A 3rd party could provide this info to sender and receiver. Mark - I agree. This comment has small impact to the framework. No longer a blackbox. Needs to update the framework doc. Rajiv - Wrt to previous comment, the CDP should take care of this (as well). Greg - How is this priority decided? Mark - Draft doesn't seem to address how is this decided. Perhaps, by the FEC scheme or CDP. The purpose of this draft - Dave - Discuss this with MMUSIC whether there is an existing syntax for priority/use of layering, and whether we can piggyback? Magnus - ? Ali - Layers don't depend on each other. Magnus - reusing Marshal - Let's relook into this again. Magnus - It is still an I-D. Greg - I-D name?? Dave - Is this scheme-id encoded within the packet? Mark - Yes. Dave - It is good. Magnus - Just Mark - Just need an IANA registry for the FEC scheme id. Identifying the FEC scheme id in the SDP. Magnus - Give some guidance on the space of FEC scheme id !! Marshal - Misuse of the space is possible. Dave - Is min-buff-size related to the source block size? Ali - Yes. Dave - Is there a level of abstraction problem here? Magnus - Mark - In some sense, this may not only be receiver, but also source related. Mark - The milisec as a unit is not appropriate. Perhaps, # of blocks!! Gerg - Is this what you referring to as well, Dave? Dave - Time and Space relationship!! What's the right unit to express receiver requirement!! Transmitter can utilize calculate accordingly. No need for transmitter and/receiver to be configured separately. Both transmitter and receiver must utilize the same value. Mark - that's right. Buff-size is not appropriate name. Also need to change the unit to block size etc. As far as FEC is converned, the first block and last block. Dave - I don't follow. Let's assume total source block+FEC = m+k packet. Why couldn't I send m+k-1 packets now, and send the last packet 10 days later. Not optimal to specify the "time" as a unit for the min-buff-size. It will create an issue. Mark - I agree. This is application specific. Shouldn't be mandatory. Application may not need to wait for all the repair packets for its functionality. Marshall- could ms be too long for high data rate stream?? Dave - Good point. Magnus - A smaller unit than ms should be advised. Magnus - Expand the usage of rfc Ali - Explains Mcast consideration and unicast consideration. Dave - My comment is not about this doc. What we really like to have is a metric reporting as part of that framework. In terms of how successful receivers are able to utilize the FEC scheme for recovery. Perhaps, receiver uses RTCP to report back the efficacy of each FEC scheme. The WG should undertake this work. Magnus - Makes sense. Magnus - For unicast, Offer/answer model can get complicated. Should CDP cover this requirement to simplify? Mark - This is a good commnt on the fecframe requirment doc. Mark - About measurement/metric reporting, how much do we need to include this? Marshall - A speculation for # of packets is possible. Mark - Magnus - Operations ! Marshall - Do we need a MIB? Magnus - No. How do we configure and measure performance of a particular scheme? This needs to be included in the framework. Greg - Chair to AD Q - Where does this fit in? framework doc? Requirement doc? Magnus - It belongs to the framework doc. Mark - May be. It depends on how far you wanna go. It is upto CDP what needs to be measured. Or we can advise this to be independent of CDP or FEC scheme. Measurement is an add-on. Greg - it hsould be in the doc. Mark - What measurements do we need to take when FEC doesn't exist. This will help to quantify whether FEC really helps or not. Rajiv - Agreed. Vincent - Sent few comments to this draft. One Q - Is session consiered to be dynamically change? Does the draft include provision for accommodating this dynamism? Magnus - You are right. SDP is not the right choice for such dynamism. SDP is suitable for the stable flow i.e. flows not changing dynamically. Mark - Just to add - We are not requiring CDP to use SDP. If an application wants to add/remove flows, then it is a bigger problem, not job of SDP. Perhaps, job of CDP. People can use other than SDP. Magnus - it is ok to leave UDP as the transport protocol in the draft. Greg - Should we adapt this as the WG doc? Magnus - Yes. _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www1.ietf.org/mailman/listinfo/fecframe