From fecframe-bounces@ietf.org Fri Apr 18 10:09:06 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8639F3A696F; Fri, 18 Apr 2008 10:09:06 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607D03A696F for ; Fri, 18 Apr 2008 10:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.13 X-Spam-Level: X-Spam-Status: No, score=0.13 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S+B5T-cW4E9 for ; Fri, 18 Apr 2008 10:09:04 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by core3.amsl.com (Postfix) with ESMTP id 4AE793A67B3 for ; Fri, 18 Apr 2008 10:09:04 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so525425wxd.31 for ; Fri, 18 Apr 2008 10:09:01 -0700 (PDT) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Q14Ts07UnPvzJp0BMOG5JWldk6RfdABmEHkLbIPExJ0=; b=p74xbfHh1E3ri+AEHEI9zyVdoXkkAkCBeLchM30zVLfbQaYmshuFcj8CHC2/2yjReB2llN2zcSynfJIPFSNDDEnANJI1g7qzq8xZcIulNqU+cfSczJVCkf+RQLJ7jT6wnAx3NDlCBTN6WLzz4WxVzchjANQ3U9/4rkPbMvzNvrY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IRJ3ZTZNdD2QPYtH2uZx8wja0PlrnOhFe8PAHaqSdzo8KFjWIxz0AYpwLCymUT+nqZCTrtTt/D11Ridt68t5RmoL4FZ6EpkVlh0+POs5ogYongm0zZP/+9e6N3jNOf1PM/fh+FEqEuinH6ZcCwFpYCT4GNF4cGgXkYxmN0cuaCI= Received: by 10.100.140.2 with SMTP id n2mr5569530and.95.1208538541366; Fri, 18 Apr 2008 10:09:01 -0700 (PDT) Received: by 10.100.119.4 with HTTP; Fri, 18 Apr 2008 10:09:01 -0700 (PDT) Message-ID: <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> Date: Fri, 18 Apr 2008 10:09:01 -0700 From: "Greg Shepherd" To: "Ali Begen (abegen)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen (abegen) wrote: > Hi everyone, > > Following up with Magnus' email, I would like to get your opinions and > suggestions about how the WG should proceed regarding the feedback > issue. > > Currently, the framework does not provide any guideline for the receiver > end-points about what they should report back to the sender (or another > 3rd party). The first question is of course whether we should generalize > this feedback support and provide the guidelines in the framework draft > OR we should leave these issues to the individual FEC schemes and CDPs. > (E.g., an FEC scheme may use RTCP machinery to benefit from the receiver > reports and RTCP extended reports to provide any level of detailed > feedback about the FEC performance and other metrics listed below.) Using "may" as you describe above should extend the functionality of the framework without fixing a solution onto all schemes and CDPs. Any objections to this? > If you think the framework should generalize the feedback support and > should define the minimal information that will be included in the > feedback reports, please make your recommendations. The protocol team came to consensus that the feedback details would likely be too scheme-specific to be generalized into the framework. If you think this is no longer the case please elaborate. Otherwise do you feel your above "may" statement is enough to open the framework to your requirements? > FYI, this issue came up in the design team meeting in late January. The > design team decided to make the feedback support optional (not a MUST > but RECOMMENDED). The basic feedback information that - we thought- > would be useful was: > > 1) Which FEC schemes and/or repair flows are used by which clients > 2) How useful the repair flows are, what the FEC recovery performance is > 3) FEC performance variation over time (e.g., in the long term for > planning purposes and in the short term for faster adaptation); number > of errors in errored blocks, number of errored blocks, number of > corrected errors per source block, various histograms. > 4) Feedback information can also (if applicable) sent back to the sender > when all the missing symbols in a source block are recovered, and the > sender starts the (early) transmission of the next source block With the level of discussion we had during the WG meeting I'm quite surprised that the email discuss afterwards had died off. We need to finalize these details and move the draft(s) along. Otherwise I suppose we can assume these guidelines are without opposition and move along anyway. PLEASE SPEAK UP. Thanks, Greg > Please share your comments. > > Thanks, > -acbegen > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Apr 18 13:20:03 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FC93A691F; Fri, 18 Apr 2008 13:20:03 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6483A6DBA for ; Fri, 18 Apr 2008 13:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M42IvujLzqpd for ; Fri, 18 Apr 2008 13:20:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 91C583A6C77 for ; Fri, 18 Apr 2008 13:20:00 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 18 Apr 2008 13:20:02 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3IKK2Kv009160; Fri, 18 Apr 2008 13:20:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3IKK2Ih013639; Fri, 18 Apr 2008 20:20:02 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); Fri, 18 Apr 2008 13:20:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Apr 2008 13:20:01 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Feedback support by the FEC Framework Thread-Index: Acihdu1ajgtwMZkSR7ejrwzULuE70AAGE9fA References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> From: "Ali Begen (abegen)" To: "Greg Shepherd" X-OriginalArrivalTime: 18 Apr 2008 20:20:02.0559 (UTC) FILETIME=[9533D0F0:01C8A191] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5006; t=1208550002; x=1209414002; c=relaxed/simple; s=sjdkim2002; 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]=20Feedback=20support=20by=20 the=20FEC=20Framework |Sender:=20; bh=enQIidWugFva9NxMuEFR3S6e6AtSgEIWFI4ozXdubho=; b=c5Zrw+uHLokI7Ty/edQz9Ahayovng0/Udl4sPSP75fIra5lh6pnfZRUnl7 a22WCRSZdGvofLJBn7Hh5Lx9WeFEgGi+xCXhsLTnIwbtPPVfsrE/EEPpAXT7 BGveZAfQyW; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Greg, Regarding the usage of RTCP, I believe RTCP provides a good feedback mechanism to report the performance of any FEC scheme that is willing to use RTP as the transport protocol. RTCP has the built-in receiver reports that are quite general and useful, but it also supports extended reports where a new report type can be proposed to carry scheme-specific feedback. As many media flows will be carried over RTP, using RTCP for this purpose is straightforward. I suggest folks who are not familiar with RTP/RTCP to refer to Ulas' earlier email about a presentation given in the AVT group. http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf For non-RTP flows (source or repair), there is not such a common tool that can be used to provide feedback on the repair performance. I have not seen any proposal on this in the email list. If the framework will support only UDP-based flows, we either need to come up with something similar to RTCP or simply ignore the feedback issue. Regarding your second comment, RTCP receiver reports are general enough to provide some feeback on any FEC flow that is carried over RTP. If detailed, specific feedback is required by an FEC scheme, extended reports are the way to go. If framework supports RTP/RTCP, this issue will be resolved right a way. Magnus wanted us to discuss this on the list, so let's discuss! We need to forward this discussion. -acbegen > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, April 18, 2008 10:09 AM > To: Ali Begen (abegen) > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Feedback support by the FEC Framework > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen (abegen) > wrote: > > Hi everyone, > > > > Following up with Magnus' email, I would like to get your opinions > > and suggestions about how the WG should proceed regarding the > > feedback issue. > > > > Currently, the framework does not provide any guideline for the > > receiver end-points about what they should report back to > the sender > > (or another 3rd party). The first question is of course whether we > > should generalize this feedback support and provide the > guidelines in > > the framework draft OR we should leave these issues to the > individual FEC schemes and CDPs. > > (E.g., an FEC scheme may use RTCP machinery to benefit from the > > receiver reports and RTCP extended reports to provide any level of > > detailed feedback about the FEC performance and other > metrics listed > > below.) > > Using "may" as you describe above should extend the > functionality of the framework without fixing a solution onto > all schemes and CDPs. > Any objections to this? > > > If you think the framework should generalize the feedback > support and > > should define the minimal information that will be included in the > > feedback reports, please make your recommendations. > > The protocol team came to consensus that the feedback details > would likely be too scheme-specific to be generalized into > the framework. If you think this is no longer the case please > elaborate. Otherwise do you feel your above "may" statement > is enough to open the framework to your requirements? > > > FYI, this issue came up in the design team meeting in late > January. > > The design team decided to make the feedback support > optional (not a > > MUST but RECOMMENDED). The basic feedback information that - we > > thought- would be useful was: > > > > 1) Which FEC schemes and/or repair flows are used by which clients > > 2) How useful the repair flows are, what the FEC recovery > performance > > is > > 3) FEC performance variation over time (e.g., in the long > term for > > planning purposes and in the short term for faster > adaptation); number > > of errors in errored blocks, number of errored blocks, number of > > corrected errors per source block, various histograms. > > 4) Feedback information can also (if applicable) sent back to the > > sender when all the missing symbols in a source block are > recovered, > > and the sender starts the (early) transmission of the next source > > block > > With the level of discussion we had during the WG meeting I'm > quite surprised that the email discuss afterwards had died > off. We need to finalize these details and move the draft(s) > along. Otherwise I suppose we can assume these guidelines are > without opposition and move along anyway. > > PLEASE SPEAK UP. > > Thanks, > Greg > > > Please share your comments. > > > > Thanks, > > -acbegen > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Apr 18 19:04:52 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89F728C2B8; Fri, 18 Apr 2008 19:04:52 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0AD328C326 for ; Fri, 18 Apr 2008 19:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZr7wvXSR9gZ for ; Fri, 18 Apr 2008 19:04:50 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id A242E28C25A for ; Fri, 18 Apr 2008 19:04:50 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so414429and.122 for ; Fri, 18 Apr 2008 19:04:52 -0700 (PDT) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RdJO0AjtdpvhfT+RbteMP2si7bAOq6jhsw+AgIOWnJY=; b=sct/YpuwljCpYIfC/KafQNF5vZBcKuyzlmIIoj8DXdptC6HBDbU3RZY16fbxG1Sn0keKPyUbe0a6NaWPy30EiMOtK/uqT/ZsJtc0JeLrjiZex9ORrrHA8bOHF+y2OlTYOtBKd4+fIEfz8o3Cs4aBozUCLY1bCm+hCJw0V7jZWHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=enhIY0gcN6/aGU8LNOTYMYE29XEwgWEJeGvzWqCDbZ8EV35/hTpQmgdrOuRAQvSjNR6la8tOW5aPMzehYqkVdCBjYdGAr52IanrPMwVTTXKs/psJXSLoegOlolccGt3T7hJRet/bVabru15ghUN51hiFMLdS3ObS10PYBF2npb4= Received: by 10.100.212.13 with SMTP id k13mr4199618ang.43.1208570692506; Fri, 18 Apr 2008 19:04:52 -0700 (PDT) Received: by 10.100.119.4 with HTTP; Fri, 18 Apr 2008 19:04:52 -0700 (PDT) Message-ID: <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> Date: Fri, 18 Apr 2008 19:04:52 -0700 From: "Greg Shepherd" To: "Ali Begen (abegen)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org On Fri, Apr 18, 2008 at 1:20 PM, Ali Begen (abegen) wrote: > Hi Greg, > > Regarding the usage of RTCP, I believe RTCP provides a good feedback > mechanism to report the performance of any FEC scheme that is willing to > use RTP as the transport protocol. RTCP has the built-in receiver > reports that are quite general and useful, but it also supports extended > reports where a new report type can be proposed to carry scheme-specific > feedback. > > As many media flows will be carried over RTP, using RTCP for this > purpose is straightforward. I suggest folks who are not familiar with > RTP/RTCP to refer to Ulas' earlier email about a presentation given in > the AVT group. > http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf > > For non-RTP flows (source or repair), there is not such a common tool > that can be used to provide feedback on the repair performance. I have > not seen any proposal on this in the email list. If the framework will > support only UDP-based flows, we either need to come up with something > similar to RTCP or simply ignore the feedback issue. ..or modify the framework to allow either UDP or RTP flows. Is that reasonable? Greg > Regarding your second comment, RTCP receiver reports are general enough > to provide some feeback on any FEC flow that is carried over RTP. If > detailed, specific feedback is required by an FEC scheme, extended > reports are the way to go. If framework supports RTP/RTCP, this issue > will be resolved right a way. > > Magnus wanted us to discuss this on the list, so let's discuss! We need > to forward this discussion. > > -acbegen > > > > > > -----Original Message----- > > From: Greg Shepherd [mailto:gjshep@gmail.com] > > Sent: Friday, April 18, 2008 10:09 AM > > To: Ali Begen (abegen) > > Cc: fecframe@ietf.org > > Subject: Re: [Fecframe] Feedback support by the FEC Framework > > > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen (abegen) > > wrote: > > > Hi everyone, > > > > > > Following up with Magnus' email, I would like to get your opinions > > > and suggestions about how the WG should proceed regarding the > > > feedback issue. > > > > > > Currently, the framework does not provide any guideline for the > > > receiver end-points about what they should report back to > > the sender > > > (or another 3rd party). The first question is of course whether we > > > should generalize this feedback support and provide the > > guidelines in > > > the framework draft OR we should leave these issues to the > > individual FEC schemes and CDPs. > > > (E.g., an FEC scheme may use RTCP machinery to benefit from the > > > receiver reports and RTCP extended reports to provide any level of > > > detailed feedback about the FEC performance and other > > metrics listed > > > below.) > > > > Using "may" as you describe above should extend the > > functionality of the framework without fixing a solution onto > > all schemes and CDPs. > > Any objections to this? > > > > > If you think the framework should generalize the feedback > > support and > > > should define the minimal information that will be included in the > > > feedback reports, please make your recommendations. > > > > The protocol team came to consensus that the feedback details > > would likely be too scheme-specific to be generalized into > > the framework. If you think this is no longer the case please > > elaborate. Otherwise do you feel your above "may" statement > > is enough to open the framework to your requirements? > > > > > FYI, this issue came up in the design team meeting in late > > January. > > > The design team decided to make the feedback support > > optional (not a > > > MUST but RECOMMENDED). The basic feedback information that - we > > > thought- would be useful was: > > > > > > 1) Which FEC schemes and/or repair flows are used by which clients > > > 2) How useful the repair flows are, what the FEC recovery > > performance > > > is > > > 3) FEC performance variation over time (e.g., in the long > > term for > > > planning purposes and in the short term for faster > > adaptation); number > > > of errors in errored blocks, number of errored blocks, number of > > > corrected errors per source block, various histograms. > > > 4) Feedback information can also (if applicable) sent back to the > > > sender when all the missing symbols in a source block are > > recovered, > > > and the sender starts the (early) transmission of the next source > > > block > > > > With the level of discussion we had during the WG meeting I'm > > quite surprised that the email discuss afterwards had died > > off. We need to finalize these details and move the draft(s) > > along. Otherwise I suppose we can assume these guidelines are > > without opposition and move along anyway. > > > > PLEASE SPEAK UP. > > > > Thanks, > > Greg > > > > > Please share your comments. > > > > > > Thanks, > > > -acbegen > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Apr 18 19:16:21 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3C23A6A83; Fri, 18 Apr 2008 19:16:21 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F213A6B89 for ; Fri, 18 Apr 2008 19:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbePI3ROokbv for ; Fri, 18 Apr 2008 19:16:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BBE183A681A for ; Fri, 18 Apr 2008 19:16:18 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2008 19:16:21 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3J2GLfm004777; Fri, 18 Apr 2008 19:16:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3J2GLvN013090; Sat, 19 Apr 2008 02:16:21 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Apr 2008 19:16:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Apr 2008 19:16:23 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> In-Reply-To: <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Feedback support by the FEC Framework Thread-Index: AcihwcN/0mr7a9krS8W0wWkeXt6iMAAARm8w References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> From: "Ali Begen (abegen)" To: "Greg Shepherd" X-OriginalArrivalTime: 19 Apr 2008 02:16:21.0260 (UTC) FILETIME=[5BE6B4C0:01C8A1C3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6506; t=1208571381; x=1209435381; c=relaxed/simple; s=sjdkim2002; 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]=20Feedback=20support=20by=20 the=20FEC=20Framework |Sender:=20; bh=MUoikFyeFfrc+gDmgjzU4iZqpXQlus5V6RrWT2l/4Wg=; b=CdfzhBJwfr2xfyN0gnVmPpyWVo+eCTqyMj35bCv3bDJMHGXCK9WbIIdvEJ HykQg5IQddDg4PLiG4WJ8xSgOcxjDwRkLkeQi36tc9ZsfVvJhp3a7Erbz0MD Sj0mE5pMtD; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Assuming that we modify the framework to allow UDP and RTP, we can use RTCP machinery for providing feedback for the RTP-based flows. But, what about the UDP-based flows? Shall we ignore the feedback support for those or let the individual schemes figure out what to do, which IMHO may lead to some complications? However, I am all ears to hear any ideas. -acbegen > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, April 18, 2008 7:05 PM > To: Ali Begen (abegen) > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Feedback support by the FEC Framework > > On Fri, Apr 18, 2008 at 1:20 PM, Ali Begen (abegen) > wrote: > > Hi Greg, > > > > Regarding the usage of RTCP, I believe RTCP provides a > good feedback > > mechanism to report the performance of any FEC scheme that > is willing > > to use RTP as the transport protocol. RTCP has the > built-in receiver > > reports that are quite general and useful, but it also supports > > extended reports where a new report type can be proposed to carry > > scheme-specific feedback. > > > > As many media flows will be carried over RTP, using RTCP for this > > purpose is straightforward. I suggest folks who are not > familiar with > > RTP/RTCP to refer to Ulas' earlier email about a > presentation given in > > the AVT group. > > http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf > > > > For non-RTP flows (source or repair), there is not such a > common tool > > that can be used to provide feedback on the repair > performance. I have > > not seen any proposal on this in the email list. If the > framework will > > support only UDP-based flows, we either need to come up > with something > > similar to RTCP or simply ignore the feedback issue. > > ..or modify the framework to allow either UDP or RTP flows. > Is that reasonable? > > Greg > > > Regarding your second comment, RTCP receiver reports are general > > enough to provide some feeback on any FEC flow that is > carried over > > RTP. If detailed, specific feedback is required by an FEC scheme, > > extended reports are the way to go. If framework supports > RTP/RTCP, > > this issue will be resolved right a way. > > > > Magnus wanted us to discuss this on the list, so let's discuss! We > > need to forward this discussion. > > > > -acbegen > > > > > > > > > > > -----Original Message----- > > > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, > > April 18, 2008 10:09 AM > To: Ali Begen (abegen) > Cc: > > fecframe@ietf.org > Subject: Re: [Fecframe] Feedback > support by the > > FEC Framework > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen > > (abegen) > wrote: > > > > Hi everyone, > > > > > > > > Following up with Magnus' email, I would like to get your > > opinions > > and suggestions about how the WG should proceed > > regarding the > > feedback issue. > > > > > > > > Currently, the framework does not provide any > guideline for the > > > > receiver end-points about what they should report back > to > the > > sender > > (or another 3rd party). The first question is > of course > > whether we > > should generalize this feedback support > and provide > > the > guidelines in > > the framework draft OR we should leave > > these issues to the > individual FEC schemes and CDPs. > > > > (E.g., an FEC scheme may use RTCP machinery to > benefit from the > > > > receiver reports and RTCP extended reports to provide > any level > > of > > detailed feedback about the FEC performance and other > > > metrics listed > > below.) > > Using "may" as you describe above > > should extend the > functionality of the framework without > fixing a > > solution onto > all schemes and CDPs. > > > Any objections to this? > > > > > > > If you think the framework should generalize the feedback > > > support and > > should define the minimal information that will be > > included in the > > feedback reports, please make your > > recommendations. > > > > > > The protocol team came to consensus that the feedback details > > > would likely be too scheme-specific to be generalized into > the > > framework. If you think this is no longer the case please > > > elaborate. Otherwise do you feel your above "may" statement > is > > enough to open the framework to your requirements? > > > > > > > FYI, this issue came up in the design team meeting in late > > > January. > > > > The design team decided to make the feedback support > > optional > > (not a > > MUST but RECOMMENDED). The basic feedback information > > that - we > > thought- would be useful was: > > > > > > > > 1) Which FEC schemes and/or repair flows are used by which > > clients > > 2) How useful the repair flows are, what the FEC > > recovery > performance > > is > > 3) FEC performance variation > > over time (e.g., in the long > term for > > planning > purposes and in > > the short term for faster > adaptation); number > > of errors in > > errored blocks, number of errored blocks, number of > > corrected > > errors per source block, various histograms. > > > > 4) Feedback information can also (if applicable) sent back to > > the > > sender when all the missing symbols in a source > block are > > > recovered, > > and the sender starts the (early) > transmission of the > > next source > > block > > With the level of discussion we had > > during the WG meeting I'm > quite surprised that the email discuss > > afterwards had died > off. We need to finalize these > details and move > > the draft(s) > along. Otherwise I suppose we can assume these > > guidelines are > without opposition and move along anyway. > > > > > > PLEASE SPEAK UP. > > > > > > Thanks, > > > Greg > > > > > > > Please share your comments. > > > > > > > > Thanks, > > > > -acbegen > > > > _______________________________________________ > > > > Fecframe mailing list > > > > Fecframe@ietf.org > > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > > > > > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Apr 18 20:40:16 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFC528C307; Fri, 18 Apr 2008 20:40:16 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1185B28C2E5 for ; Fri, 18 Apr 2008 20:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTw89pYnCd18 for ; Fri, 18 Apr 2008 20:40:14 -0700 (PDT) Received: from h665227.serverkompetenz.net (stewe.org [85.214.23.117]) by core3.amsl.com (Postfix) with ESMTP id 6353728C2E9 for ; Fri, 18 Apr 2008 20:40:12 -0700 (PDT) Received: (qmail 10737 invoked by uid 60000); 19 Apr 2008 03:00:35 -0000 Received: from 127.0.0.1 by h665227 (envelope-from , uid 60004) with qmail-scanner-1.24st visas (spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 0.816632 secs); 19 Apr 2008 03:00:35 -0000 Received: from localhost (HELO webmail.stewe.org) (127.0.0.1) by localhost with SMTP; 19 Apr 2008 03:00:34 -0000 Received: from 192.100.104.17 (proxying for 10.162.253.163) (SquirrelMail authenticated user stewe@stewe.org) by webmail.stewe.org with HTTP; Sat, 19 Apr 2008 05:00:34 +0200 (CEST) Message-ID: <62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> Date: Sat, 19 Apr 2008 05:00:34 +0200 (CEST) From: stewe@stewe.org To: "Ali Begen (abegen)" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org If you need for your UDP flows a feedback channel with all the characteristics of RTCP, why don't you simply set up one (without having an active RTP flow? Where is it written that the RTP channel has to send any data, ever? Or, you could design an RTP payload format for "Fecframe error control information" (conveyed in RTP). Then you even have the chance to control your control channel :-) Stephan > Assuming that we modify the framework to allow UDP and RTP, we can use > RTCP machinery for providing feedback for the RTP-based flows. But, what > about the UDP-based flows? Shall we ignore the feedback support for > those or let the individual schemes figure out what to do, which IMHO > may lead to some complications? > > However, I am all ears to hear any ideas. > > -acbegen > >> -----Original Message----- >> From: Greg Shepherd [mailto:gjshep@gmail.com] >> Sent: Friday, April 18, 2008 7:05 PM >> To: Ali Begen (abegen) >> Cc: fecframe@ietf.org >> Subject: Re: [Fecframe] Feedback support by the FEC Framework >> >> On Fri, Apr 18, 2008 at 1:20 PM, Ali Begen (abegen) >> wrote: >> > Hi Greg, >> > >> > Regarding the usage of RTCP, I believe RTCP provides a >> good feedback >> > mechanism to report the performance of any FEC scheme that >> is willing >> > to use RTP as the transport protocol. RTCP has the >> built-in receiver >> > reports that are quite general and useful, but it also supports >> > extended reports where a new report type can be proposed to carry >> > scheme-specific feedback. >> > >> > As many media flows will be carried over RTP, using RTCP for this >> > purpose is straightforward. I suggest folks who are not >> familiar with >> > RTP/RTCP to refer to Ulas' earlier email about a >> presentation given in >> > the AVT group. >> > http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf >> > >> > For non-RTP flows (source or repair), there is not such a >> common tool >> > that can be used to provide feedback on the repair >> performance. I have >> > not seen any proposal on this in the email list. If the >> framework will >> > support only UDP-based flows, we either need to come up >> with something >> > similar to RTCP or simply ignore the feedback issue. >> >> ..or modify the framework to allow either UDP or RTP flows. >> Is that reasonable? >> >> Greg >> >> > Regarding your second comment, RTCP receiver reports are general >> > enough to provide some feeback on any FEC flow that is >> carried over >> > RTP. If detailed, specific feedback is required by an FEC scheme, >> > extended reports are the way to go. If framework supports >> RTP/RTCP, >> > this issue will be resolved right a way. >> > >> > Magnus wanted us to discuss this on the list, so let's discuss! We >> > need to forward this discussion. >> > >> > -acbegen >> > >> > >> > >> > >> > > -----Original Message----- >> > > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, >> > April 18, 2008 10:09 AM > To: Ali Begen (abegen) > Cc: >> > fecframe@ietf.org > Subject: Re: [Fecframe] Feedback >> support by the >> > FEC Framework > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen >> > (abegen) > wrote: >> > > > Hi everyone, >> > > > >> > > > Following up with Magnus' email, I would like to get your >> > opinions > > and suggestions about how the WG should proceed >> > regarding the > > feedback issue. >> > > > >> > > > Currently, the framework does not provide any >> guideline for the >> > > > receiver end-points about what they should report back >> to > the >> > sender > > (or another 3rd party). The first question is >> of course >> > whether we > > should generalize this feedback support >> and provide >> > the > guidelines in > > the framework draft OR we should leave >> > these issues to the > individual FEC schemes and CDPs. >> > > > (E.g., an FEC scheme may use RTCP machinery to >> benefit from the >> > > > receiver reports and RTCP extended reports to provide >> any level >> > of > > detailed feedback about the FEC performance and other > >> > metrics listed > > below.) > > Using "may" as you describe above >> > should extend the > functionality of the framework without >> fixing a >> > solution onto > all schemes and CDPs. >> > > Any objections to this? >> > > >> > > > If you think the framework should generalize the feedback > >> > support and > > should define the minimal information that will be >> > included in the > > feedback reports, please make your >> > recommendations. >> > > >> > > The protocol team came to consensus that the feedback details > >> > would likely be too scheme-specific to be generalized into > the >> > framework. If you think this is no longer the case please > >> > elaborate. Otherwise do you feel your above "may" statement > is >> > enough to open the framework to your requirements? >> > > >> > > > FYI, this issue came up in the design team meeting in late > >> > January. >> > > > The design team decided to make the feedback support >> > optional >> > (not a > > MUST but RECOMMENDED). The basic feedback information >> > that - we > > thought- would be useful was: >> > > > >> > > > 1) Which FEC schemes and/or repair flows are used by which >> > clients > > 2) How useful the repair flows are, what the FEC >> > recovery > performance > > is > > 3) FEC performance variation >> > over time (e.g., in the long > term for > > planning >> purposes and in >> > the short term for faster > adaptation); number > > of errors in >> > errored blocks, number of errored blocks, number of > > corrected >> > errors per source block, various histograms. >> > > > 4) Feedback information can also (if applicable) sent back to >> > the > > sender when all the missing symbols in a source >> block are > >> > recovered, > > and the sender starts the (early) >> transmission of the >> > next source > > block > > With the level of discussion we had >> > during the WG meeting I'm > quite surprised that the email discuss >> > afterwards had died > off. We need to finalize these >> details and move >> > the draft(s) > along. Otherwise I suppose we can assume these >> > guidelines are > without opposition and move along anyway. >> > > >> > > PLEASE SPEAK UP. >> > > >> > > Thanks, >> > > Greg >> > > >> > > > Please share your comments. >> > > > >> > > > Thanks, >> > > > -acbegen >> > > > _______________________________________________ >> > > > Fecframe mailing list >> > > > Fecframe@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/fecframe >> > > > >> > > >> > >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sat Apr 19 07:49:18 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65AAD3A688A; Sat, 19 Apr 2008 07:49:18 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C126F3A67EB for ; Sat, 19 Apr 2008 07:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1l0M1huKYXm for ; Sat, 19 Apr 2008 07:49:16 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 80D783A688A for ; Sat, 19 Apr 2008 07:49:16 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 11081057; Sat, 19 Apr 2008 10:49:20 -0400 From: Marshall Eubanks To: stewe@stewe.org In-Reply-To: <62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org> X-Priority: 3 (Normal) References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> <62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org> Message-Id: <16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 19 Apr 2008 10:49:18 -0400 X-Mailer: Apple Mail (2.919.2) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org On Apr 18, 2008, at 11:00 PM, stewe@stewe.org wrote: > If you need for your UDP flows a feedback channel with all the > characteristics of RTCP, why don't you simply set up one (without > having > an active RTP flow? Where is it written that the RTP channel has to > send > any data, ever? The receiver finds sender information from sender reports. Would the source send out a sender report and give itself a SSRC for a UDP only session ? If not, I don't see how this would work. If so, a non-aware RTP receiver would report no data found, which might mess up the statistics (i.e., the SR's and RR's might need a flag to say, this data is for a non-RTP UDP only session). The RTCP bandwidth (rtcp_bw) would need to be set to something suitable, which implies that the session bandwidth is set suitably (i.e., to the UDP flow, not to the non-existent RTP flow). There might also be security issues about this (e.g., what if a malicious user or misconfigured source starts an RTP flow in what is intended to be a null flow ? How do we tell RTP receivers to ignore this ?) Regards Marshall > > > Or, you could design an RTP payload format for "Fecframe error control > information" (conveyed in RTP). Then you even have the chance to > control > your control channel :-) > > Stephan > > >> Assuming that we modify the framework to allow UDP and RTP, we can >> use >> RTCP machinery for providing feedback for the RTP-based flows. But, >> what >> about the UDP-based flows? Shall we ignore the feedback support for >> those or let the individual schemes figure out what to do, which IMHO >> may lead to some complications? >> >> However, I am all ears to hear any ideas. >> >> -acbegen >> >>> -----Original Message----- >>> From: Greg Shepherd [mailto:gjshep@gmail.com] >>> Sent: Friday, April 18, 2008 7:05 PM >>> To: Ali Begen (abegen) >>> Cc: fecframe@ietf.org >>> Subject: Re: [Fecframe] Feedback support by the FEC Framework >>> >>> On Fri, Apr 18, 2008 at 1:20 PM, Ali Begen (abegen) >>> wrote: >>>> Hi Greg, >>>> >>>> Regarding the usage of RTCP, I believe RTCP provides a >>> good feedback >>>> mechanism to report the performance of any FEC scheme that >>> is willing >>>> to use RTP as the transport protocol. RTCP has the >>> built-in receiver >>>> reports that are quite general and useful, but it also supports >>>> extended reports where a new report type can be proposed to carry >>>> scheme-specific feedback. >>>> >>>> As many media flows will be carried over RTP, using RTCP for this >>>> purpose is straightforward. I suggest folks who are not >>> familiar with >>>> RTP/RTCP to refer to Ulas' earlier email about a >>> presentation given in >>>> the AVT group. >>>> http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf >>>> >>>> For non-RTP flows (source or repair), there is not such a >>> common tool >>>> that can be used to provide feedback on the repair >>> performance. I have >>>> not seen any proposal on this in the email list. If the >>> framework will >>>> support only UDP-based flows, we either need to come up >>> with something >>>> similar to RTCP or simply ignore the feedback issue. >>> >>> ..or modify the framework to allow either UDP or RTP flows. >>> Is that reasonable? >>> >>> Greg >>> >>>> Regarding your second comment, RTCP receiver reports are general >>>> enough to provide some feeback on any FEC flow that is >>> carried over >>>> RTP. If detailed, specific feedback is required by an FEC scheme, >>>> extended reports are the way to go. If framework supports >>> RTP/RTCP, >>>> this issue will be resolved right a way. >>>> >>>> Magnus wanted us to discuss this on the list, so let's discuss! We >>>> need to forward this discussion. >>>> >>>> -acbegen >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, >>>> April 18, 2008 10:09 AM > To: Ali Begen (abegen) > Cc: >>>> fecframe@ietf.org > Subject: Re: [Fecframe] Feedback >>> support by the >>>> FEC Framework > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen >>>> (abegen) > wrote: >>>>>> Hi everyone, >>>>>> >>>>>> Following up with Magnus' email, I would like to get your >>>> opinions > > and suggestions about how the WG should proceed >>>> regarding the > > feedback issue. >>>>>> >>>>>> Currently, the framework does not provide any >>> guideline for the >>>>>> receiver end-points about what they should report back >>> to > the >>>> sender > > (or another 3rd party). The first question is >>> of course >>>> whether we > > should generalize this feedback support >>> and provide >>>> the > guidelines in > > the framework draft OR we should leave >>>> these issues to the > individual FEC schemes and CDPs. >>>>>> (E.g., an FEC scheme may use RTCP machinery to >>> benefit from the >>>>>> receiver reports and RTCP extended reports to provide >>> any level >>>> of > > detailed feedback about the FEC performance and other > >>>> metrics listed > > below.) > > Using "may" as you describe above >>>> should extend the > functionality of the framework without >>> fixing a >>>> solution onto > all schemes and CDPs. >>>>> Any objections to this? >>>>> >>>>>> If you think the framework should generalize the feedback > >>>> support and > > should define the minimal information that will be >>>> included in the > > feedback reports, please make your >>>> recommendations. >>>>> >>>>> The protocol team came to consensus that the feedback details > >>>> would likely be too scheme-specific to be generalized into > the >>>> framework. If you think this is no longer the case please > >>>> elaborate. Otherwise do you feel your above "may" statement > is >>>> enough to open the framework to your requirements? >>>>> >>>>>> FYI, this issue came up in the design team meeting in late > >>>> January. >>>>>> The design team decided to make the feedback support >>>> optional >>>> (not a > > MUST but RECOMMENDED). The basic feedback information >>>> that - we > > thought- would be useful was: >>>>>> >>>>>> 1) Which FEC schemes and/or repair flows are used by which >>>> clients > > 2) How useful the repair flows are, what the FEC >>>> recovery > performance > > is > > 3) FEC performance variation >>>> over time (e.g., in the long > term for > > planning >>> purposes and in >>>> the short term for faster > adaptation); number > > of errors in >>>> errored blocks, number of errored blocks, number of > > corrected >>>> errors per source block, various histograms. >>>>>> 4) Feedback information can also (if applicable) sent back to >>>> the > > sender when all the missing symbols in a source >>> block are > >>>> recovered, > > and the sender starts the (early) >>> transmission of the >>>> next source > > block > > With the level of discussion we had >>>> during the WG meeting I'm > quite surprised that the email discuss >>>> afterwards had died > off. We need to finalize these >>> details and move >>>> the draft(s) > along. Otherwise I suppose we can assume these >>>> guidelines are > without opposition and move along anyway. >>>>> >>>>> PLEASE SPEAK UP. >>>>> >>>>> Thanks, >>>>> Greg >>>>> >>>>>> Please share your comments. >>>>>> >>>>>> Thanks, >>>>>> -acbegen >>>>>> _______________________________________________ >>>>>> Fecframe mailing list >>>>>> Fecframe@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun Apr 20 08:34:10 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F295A3A6B4B; Sun, 20 Apr 2008 08:34:09 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1873C3A6AE0 for ; Sun, 20 Apr 2008 08:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j4+R-tx0Etk for ; Sun, 20 Apr 2008 08:34:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 819803A6AB5 for ; Sun, 20 Apr 2008 08:34:06 -0700 (PDT) Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 20 Apr 2008 08:34:11 -0700 Received: from stealth-10-32-245-153.cisco.com ([10.32.245.153]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m3KFHMgD004369; Sun, 20 Apr 2008 08:17:22 -0700 From: David R Oran To: Marshall Eubanks In-Reply-To: <16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com> X-Priority: 3 (Normal) References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> <62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org> <16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 20 Apr 2008 11:34:08 -0400 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9684; t=1208704643; x=1209568643; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Fecframe]=20Feedback=20support=20by=20 the=20FEC=20Framework |Sender:=20 |To:=20Marshall=20Eubanks=20; bh=GSXpm8cpl4mJ4yIC/hewiVLUVdf8EyqWCq1KtQQ74pM=; b=nY2lXmUCTyHHkInFpG1jk0kUjgUDOB4+2KcFGIhKPhr5u22R4pTBCtK1VR kUOMiVtyI+7HytbgO/xsQhT4v5i1NQBHR/15u16o2FKIimv7l27r6UiznxMa fV+l4H2tku; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org On Apr 19, 2008, at 10:49 AM, Marshall Eubanks wrote: > > On Apr 18, 2008, at 11:00 PM, stewe@stewe.org wrote: > >> If you need for your UDP flows a feedback channel with all the >> characteristics of RTCP, why don't you simply set up one (without >> having >> an active RTP flow? Where is it written that the RTP channel has to >> send >> any data, ever? > It doesn't, but the the conventional RTCP instrumentation is fairly closely tied to the underlying data transport being RTP. Things like SSRCs and SDES for describing sources, sequence numbers for correlating the reports to the data packets, etc. I suppose it would be possible to use the RTCP *framework* for reporting on non-RTP flows, but it would seem to still require a new set of RTCP reports, one per FEC scheme. Is that what you had in mind? > The receiver finds sender information from sender reports. Would the > source send out a sender report and give itself a SSRC for a UDP only > session ? If not, I don't see how this would work. That part would likely work, but we're already stretching the semantics even taking about SSRCs for non-RTP flows. > If so, a non-aware > RTP receiver would report no data found, which might mess > up the statistics (i.e., the SR's and RR's might need a flag to say, > this data is for a non-RTP UDP only session). > I think that's the tip of the iceberg... > The RTCP bandwidth (rtcp_bw) would need to be set to something > suitable, which implies that the > session bandwidth is set suitably (i.e., to the UDP flow, not to the > non-existent RTP flow). > Yup, that part doesn't seem the hard piece. > There might also be security issues about this (e.g., what if a > malicious user or misconfigured source starts an RTP flow in what is > intended > to be a null flow ? How do we tell RTP receivers to ignore this ?) > Well, we can protect the RTCP part with SRTCP. I don't see how you can prevent malicious senders from sending anything they way, so from that point of view I'm not sure what the new problem is. If the encapsulation announced in SDP is not the encapsulation sent, the problem exists, right? Another issue may/will be port multiplexing. There's a well-defined port-multiplexing scheme now for RTP/RTCP, but for arbitrary UDP/RTCP that could be quite difficult - you'd need a per-FEC scheme multiplexing specification. > Regards > Marshall > > >> >> >> Or, you could design an RTP payload format for "Fecframe error >> control >> information" (conveyed in RTP). Then you even have the chance to >> control >> your control channel :-) >> >> Stephan >> >> >>> Assuming that we modify the framework to allow UDP and RTP, we can >>> use >>> RTCP machinery for providing feedback for the RTP-based flows. But, >>> what >>> about the UDP-based flows? Shall we ignore the feedback support for >>> those or let the individual schemes figure out what to do, which >>> IMHO >>> may lead to some complications? >>> >>> However, I am all ears to hear any ideas. >>> >>> -acbegen >>> >>>> -----Original Message----- >>>> From: Greg Shepherd [mailto:gjshep@gmail.com] >>>> Sent: Friday, April 18, 2008 7:05 PM >>>> To: Ali Begen (abegen) >>>> Cc: fecframe@ietf.org >>>> Subject: Re: [Fecframe] Feedback support by the FEC Framework >>>> >>>> On Fri, Apr 18, 2008 at 1:20 PM, Ali Begen (abegen) >>>> wrote: >>>>> Hi Greg, >>>>> >>>>> Regarding the usage of RTCP, I believe RTCP provides a >>>> good feedback >>>>> mechanism to report the performance of any FEC scheme that >>>> is willing >>>>> to use RTP as the transport protocol. RTCP has the >>>> built-in receiver >>>>> reports that are quite general and useful, but it also supports >>>>> extended reports where a new report type can be proposed to carry >>>>> scheme-specific feedback. >>>>> >>>>> As many media flows will be carried over RTP, using RTCP for this >>>>> purpose is straightforward. I suggest folks who are not >>>> familiar with >>>>> RTP/RTCP to refer to Ulas' earlier email about a >>>> presentation given in >>>>> the AVT group. >>>>> http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf >>>>> >>>>> For non-RTP flows (source or repair), there is not such a >>>> common tool >>>>> that can be used to provide feedback on the repair >>>> performance. I have >>>>> not seen any proposal on this in the email list. If the >>>> framework will >>>>> support only UDP-based flows, we either need to come up >>>> with something >>>>> similar to RTCP or simply ignore the feedback issue. >>>> >>>> ..or modify the framework to allow either UDP or RTP flows. >>>> Is that reasonable? >>>> >>>> Greg >>>> >>>>> Regarding your second comment, RTCP receiver reports are general >>>>> enough to provide some feeback on any FEC flow that is >>>> carried over >>>>> RTP. If detailed, specific feedback is required by an FEC scheme, >>>>> extended reports are the way to go. If framework supports >>>> RTP/RTCP, >>>>> this issue will be resolved right a way. >>>>> >>>>> Magnus wanted us to discuss this on the list, so let's discuss! We >>>>> need to forward this discussion. >>>>> >>>>> -acbegen >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, >>>>> April 18, 2008 10:09 AM > To: Ali Begen (abegen) > Cc: >>>>> fecframe@ietf.org > Subject: Re: [Fecframe] Feedback >>>> support by the >>>>> FEC Framework > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen >>>>> (abegen) > wrote: >>>>>>> Hi everyone, >>>>>>> >>>>>>> Following up with Magnus' email, I would like to get your >>>>> opinions > > and suggestions about how the WG should proceed >>>>> regarding the > > feedback issue. >>>>>>> >>>>>>> Currently, the framework does not provide any >>>> guideline for the >>>>>>> receiver end-points about what they should report back >>>> to > the >>>>> sender > > (or another 3rd party). The first question is >>>> of course >>>>> whether we > > should generalize this feedback support >>>> and provide >>>>> the > guidelines in > > the framework draft OR we should leave >>>>> these issues to the > individual FEC schemes and CDPs. >>>>>>> (E.g., an FEC scheme may use RTCP machinery to >>>> benefit from the >>>>>>> receiver reports and RTCP extended reports to provide >>>> any level >>>>> of > > detailed feedback about the FEC performance and other > >>>>> metrics listed > > below.) > > Using "may" as you describe >>>>> above >>>>> should extend the > functionality of the framework without >>>> fixing a >>>>> solution onto > all schemes and CDPs. >>>>>> Any objections to this? >>>>>> >>>>>>> If you think the framework should generalize the feedback > >>>>> support and > > should define the minimal information that will >>>>> be >>>>> included in the > > feedback reports, please make your >>>>> recommendations. >>>>>> >>>>>> The protocol team came to consensus that the feedback details > >>>>> would likely be too scheme-specific to be generalized into > the >>>>> framework. If you think this is no longer the case please > >>>>> elaborate. Otherwise do you feel your above "may" statement > is >>>>> enough to open the framework to your requirements? >>>>>> >>>>>>> FYI, this issue came up in the design team meeting in late > >>>>> January. >>>>>>> The design team decided to make the feedback support >>>>> optional >>>>> (not a > > MUST but RECOMMENDED). The basic feedback information >>>>> that - we > > thought- would be useful was: >>>>>>> >>>>>>> 1) Which FEC schemes and/or repair flows are used by which >>>>> clients > > 2) How useful the repair flows are, what the FEC >>>>> recovery > performance > > is > > 3) FEC performance variation >>>>> over time (e.g., in the long > term for > > planning >>>> purposes and in >>>>> the short term for faster > adaptation); number > > of errors in >>>>> errored blocks, number of errored blocks, number of > > corrected >>>>> errors per source block, various histograms. >>>>>>> 4) Feedback information can also (if applicable) sent back to >>>>> the > > sender when all the missing symbols in a source >>>> block are > >>>>> recovered, > > and the sender starts the (early) >>>> transmission of the >>>>> next source > > block > > With the level of discussion we had >>>>> during the WG meeting I'm > quite surprised that the email >>>>> discuss >>>>> afterwards had died > off. We need to finalize these >>>> details and move >>>>> the draft(s) > along. Otherwise I suppose we can assume these >>>>> guidelines are > without opposition and move along anyway. >>>>>> >>>>>> PLEASE SPEAK UP. >>>>>> >>>>>> Thanks, >>>>>> Greg >>>>>> >>>>>>> Please share your comments. >>>>>>> >>>>>>> Thanks, >>>>>>> -acbegen >>>>>>> _______________________________________________ >>>>>>> Fecframe mailing list >>>>>>> Fecframe@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>>>>> >>>>>> >>>>> >>>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>> >> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun Apr 20 08:42:43 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C19728C191; Sun, 20 Apr 2008 08:42:43 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FA53A69CC for ; Sun, 20 Apr 2008 08:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yYqaRdN+ugd for ; Sun, 20 Apr 2008 08:42:40 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 2C1343A6D8F for ; Sun, 20 Apr 2008 08:42:40 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 11090794; Sun, 20 Apr 2008 11:42:46 -0400 From: Marshall Eubanks To: David R Oran In-Reply-To: X-Priority: 3 (Normal) References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> <62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org> <16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 20 Apr 2008 11:42:42 -0400 X-Mailer: Apple Mail (2.919.2) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org On Apr 20, 2008, at 11:34 AM, David R Oran wrote: > > On Apr 19, 2008, at 10:49 AM, Marshall Eubanks wrote: > >> >> On Apr 18, 2008, at 11:00 PM, stewe@stewe.org wrote: >> >>> If you need for your UDP flows a feedback channel with all the >>> characteristics of RTCP, why don't you simply set up one (without >>> having >>> an active RTP flow? Where is it written that the RTP channel has to >>> send >>> any data, ever? >> > It doesn't, but the the conventional RTCP instrumentation is fairly > closely tied to the underlying data transport being RTP. Things like > SSRCs and SDES for describing sources, sequence numbers for > correlating the reports to the data packets, etc. I suppose it would > be possible to use the RTCP *framework* for reporting on non-RTP > flows, but it would seem to still require a new set of RTCP reports, > one per FEC scheme. Is that what you had in mind? > To me, upon reflection, I don't think that FECFRAME should be doing this. If we (or anyone else) really needs to be able to treat UDP flows in RTP with RTCP feedback, this seems like it should be a separate RFC coming out of AVT. There are too many possible worms in this can for us to handle it just as an aside. Regards Marshall >> The receiver finds sender information from sender reports. Would the >> source send out a sender report and give itself a SSRC for a UDP only >> session ? If not, I don't see how this would work. > That part would likely work, but we're already stretching the > semantics even taking about SSRCs for non-RTP flows. > >> If so, a non-aware >> RTP receiver would report no data found, which might mess >> up the statistics (i.e., the SR's and RR's might need a flag to say, >> this data is for a non-RTP UDP only session). >> > I think that's the tip of the iceberg... > >> The RTCP bandwidth (rtcp_bw) would need to be set to something >> suitable, which implies that the >> session bandwidth is set suitably (i.e., to the UDP flow, not to the >> non-existent RTP flow). >> > Yup, that part doesn't seem the hard piece. > >> There might also be security issues about this (e.g., what if a >> malicious user or misconfigured source starts an RTP flow in what is >> intended >> to be a null flow ? How do we tell RTP receivers to ignore this ?) >> > Well, we can protect the RTCP part with SRTCP. I don't see how you > can prevent malicious senders from sending anything they way, so > from that point of view I'm not sure what the new problem is. If the > encapsulation announced in SDP is not the encapsulation sent, the > problem exists, right? > > Another issue may/will be port multiplexing. There's a well-defined > port-multiplexing scheme now for RTP/RTCP, but for arbitrary UDP/ > RTCP that could be quite difficult - you'd need a per-FEC scheme > multiplexing specification. > > >> Regards >> Marshall >> >> >>> >>> >>> Or, you could design an RTP payload format for "Fecframe error >>> control >>> information" (conveyed in RTP). Then you even have the chance to >>> control >>> your control channel :-) >>> >>> Stephan >>> >>> >>>> Assuming that we modify the framework to allow UDP and RTP, we can >>>> use >>>> RTCP machinery for providing feedback for the RTP-based flows. But, >>>> what >>>> about the UDP-based flows? Shall we ignore the feedback support for >>>> those or let the individual schemes figure out what to do, which >>>> IMHO >>>> may lead to some complications? >>>> >>>> However, I am all ears to hear any ideas. >>>> >>>> -acbegen >>>> >>>>> -----Original Message----- >>>>> From: Greg Shepherd [mailto:gjshep@gmail.com] >>>>> Sent: Friday, April 18, 2008 7:05 PM >>>>> To: Ali Begen (abegen) >>>>> Cc: fecframe@ietf.org >>>>> Subject: Re: [Fecframe] Feedback support by the FEC Framework >>>>> >>>>> On Fri, Apr 18, 2008 at 1:20 PM, Ali Begen (abegen) >>>>> wrote: >>>>>> Hi Greg, >>>>>> >>>>>> Regarding the usage of RTCP, I believe RTCP provides a >>>>> good feedback >>>>>> mechanism to report the performance of any FEC scheme that >>>>> is willing >>>>>> to use RTP as the transport protocol. RTCP has the >>>>> built-in receiver >>>>>> reports that are quite general and useful, but it also supports >>>>>> extended reports where a new report type can be proposed to >>>>>> carry >>>>>> scheme-specific feedback. >>>>>> >>>>>> As many media flows will be carried over RTP, using RTCP for this >>>>>> purpose is straightforward. I suggest folks who are not >>>>> familiar with >>>>>> RTP/RTCP to refer to Ulas' earlier email about a >>>>> presentation given in >>>>>> the AVT group. >>>>>> http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf >>>>>> >>>>>> For non-RTP flows (source or repair), there is not such a >>>>> common tool >>>>>> that can be used to provide feedback on the repair >>>>> performance. I have >>>>>> not seen any proposal on this in the email list. If the >>>>> framework will >>>>>> support only UDP-based flows, we either need to come up >>>>> with something >>>>>> similar to RTCP or simply ignore the feedback issue. >>>>> >>>>> ..or modify the framework to allow either UDP or RTP flows. >>>>> Is that reasonable? >>>>> >>>>> Greg >>>>> >>>>>> Regarding your second comment, RTCP receiver reports are general >>>>>> enough to provide some feeback on any FEC flow that is >>>>> carried over >>>>>> RTP. If detailed, specific feedback is required by an FEC >>>>>> scheme, >>>>>> extended reports are the way to go. If framework supports >>>>> RTP/RTCP, >>>>>> this issue will be resolved right a way. >>>>>> >>>>>> Magnus wanted us to discuss this on the list, so let's discuss! >>>>>> We >>>>>> need to forward this discussion. >>>>>> >>>>>> -acbegen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, >>>>>> April 18, 2008 10:09 AM > To: Ali Begen (abegen) > Cc: >>>>>> fecframe@ietf.org > Subject: Re: [Fecframe] Feedback >>>>> support by the >>>>>> FEC Framework > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen >>>>>> (abegen) > wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> Following up with Magnus' email, I would like to get your >>>>>> opinions > > and suggestions about how the WG should proceed >>>>>> regarding the > > feedback issue. >>>>>>>> >>>>>>>> Currently, the framework does not provide any >>>>> guideline for the >>>>>>>> receiver end-points about what they should report back >>>>> to > the >>>>>> sender > > (or another 3rd party). The first question is >>>>> of course >>>>>> whether we > > should generalize this feedback support >>>>> and provide >>>>>> the > guidelines in > > the framework draft OR we should leave >>>>>> these issues to the > individual FEC schemes and CDPs. >>>>>>>> (E.g., an FEC scheme may use RTCP machinery to >>>>> benefit from the >>>>>>>> receiver reports and RTCP extended reports to provide >>>>> any level >>>>>> of > > detailed feedback about the FEC performance and other > >>>>>> metrics listed > > below.) > > Using "may" as you describe >>>>>> above >>>>>> should extend the > functionality of the framework without >>>>> fixing a >>>>>> solution onto > all schemes and CDPs. >>>>>>> Any objections to this? >>>>>>> >>>>>>>> If you think the framework should generalize the feedback > >>>>>> support and > > should define the minimal information that >>>>>> will be >>>>>> included in the > > feedback reports, please make your >>>>>> recommendations. >>>>>>> >>>>>>> The protocol team came to consensus that the feedback details > >>>>>> would likely be too scheme-specific to be generalized into > the >>>>>> framework. If you think this is no longer the case please > >>>>>> elaborate. Otherwise do you feel your above "may" statement > is >>>>>> enough to open the framework to your requirements? >>>>>>> >>>>>>>> FYI, this issue came up in the design team meeting in late > >>>>>> January. >>>>>>>> The design team decided to make the feedback support >>>>>> optional >>>>>> (not a > > MUST but RECOMMENDED). The basic feedback >>>>>> information >>>>>> that - we > > thought- would be useful was: >>>>>>>> >>>>>>>> 1) Which FEC schemes and/or repair flows are used by which >>>>>> clients > > 2) How useful the repair flows are, what the FEC >>>>>> recovery > performance > > is > > 3) FEC performance >>>>>> variation >>>>>> over time (e.g., in the long > term for > > planning >>>>> purposes and in >>>>>> the short term for faster > adaptation); number > > of errors >>>>>> in >>>>>> errored blocks, number of errored blocks, number of > > >>>>>> corrected >>>>>> errors per source block, various histograms. >>>>>>>> 4) Feedback information can also (if applicable) sent back to >>>>>> the > > sender when all the missing symbols in a source >>>>> block are > >>>>>> recovered, > > and the sender starts the (early) >>>>> transmission of the >>>>>> next source > > block > > With the level of discussion we had >>>>>> during the WG meeting I'm > quite surprised that the email >>>>>> discuss >>>>>> afterwards had died > off. We need to finalize these >>>>> details and move >>>>>> the draft(s) > along. Otherwise I suppose we can assume these >>>>>> guidelines are > without opposition and move along anyway. >>>>>>> >>>>>>> PLEASE SPEAK UP. >>>>>>> >>>>>>> Thanks, >>>>>>> Greg >>>>>>> >>>>>>>> Please share your comments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -acbegen >>>>>>>> _______________________________________________ >>>>>>>> Fecframe mailing list >>>>>>>> Fecframe@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>>> >>> >>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun Apr 20 09:09:32 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B6E28C1E6; Sun, 20 Apr 2008 09:09:32 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4EF28C1E8 for ; Sun, 20 Apr 2008 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awqgkLLj6--q for ; Sun, 20 Apr 2008 09:09:28 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 6574728C19E for ; Sun, 20 Apr 2008 09:09:28 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so818238and.122 for ; Sun, 20 Apr 2008 09:09:34 -0700 (PDT) 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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=WF3W+o8OBKqaQ4nLr4aF9KzX8Gv7oA00H/wSZcnVN08=; b=MNem7n8tbjCodHNN9QMGmo15FWT9HcWdk7r1s8dIlRlLub3+irvxWh3dqyI/tgf5v0izhuOd8qojbcqnzKmbXi5R1J0Sf7j7CGTdlsJ1+VcWX5rerrfqYjGRuAF3BI+TFn6RJeQBpLFFgzvHjw7QqDsh2uTRiDNHaXmkSbhd9QQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tb5amuMG3F3BrXXZqLv4ngl35dwDQhMPJzUcq/DIdMnGVCq6U80ubxBpxbSXSnf7scIibzFd6HJWbrUusailiWyWrbdSgJIdWKABp/lxFKl5NwUGl8GZmBe5ePsbWP+U8tKtFm/ENj+eUGSurp2unE86/m+lcHenx6cGnh7FLTo= Received: by 10.101.70.15 with SMTP id x15mr9988656ank.116.1208707774666; Sun, 20 Apr 2008 09:09:34 -0700 (PDT) Received: by 10.100.119.4 with HTTP; Sun, 20 Apr 2008 09:09:34 -0700 (PDT) Message-ID: <38c19b540804200909m43549e10n837e20511c9a00b8@mail.gmail.com> Date: Sun, 20 Apr 2008 09:09:34 -0700 From: "Greg Shepherd" To: "Marshall Eubanks" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> <62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org> <16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com> Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org On Sun, Apr 20, 2008 at 8:42 AM, Marshall Eubanks wrote: > > On Apr 20, 2008, at 11:34 AM, David R Oran wrote: > > > > > On Apr 19, 2008, at 10:49 AM, Marshall Eubanks wrote: > > > >> > >> On Apr 18, 2008, at 11:00 PM, stewe@stewe.org wrote: > >> > >>> If you need for your UDP flows a feedback channel with all the > >>> characteristics of RTCP, why don't you simply set up one (without > >>> having > >>> an active RTP flow? Where is it written that the RTP channel has to > >>> send > >>> any data, ever? > >> > > It doesn't, but the the conventional RTCP instrumentation is fairly > > closely tied to the underlying data transport being RTP. Things like > > SSRCs and SDES for describing sources, sequence numbers for > > correlating the reports to the data packets, etc. I suppose it would > > be possible to use the RTCP *framework* for reporting on non-RTP > > flows, but it would seem to still require a new set of RTCP reports, > > one per FEC scheme. Is that what you had in mind? > > > > To me, upon reflection, I don't think that FECFRAME should be doing > this. If we (or anyone else) really needs to be able to treat UDP > flows in RTP with RTCP > feedback, this seems like it should be a separate RFC coming out of > AVT. There are too many possible worms in this can for us to handle it > just > as an aside. > > Regards > Marshall Which part, Marshall? What is being discussed here are possibilities, not requirements. This last issues is whether we can/should protect non-RTP flows with RTCP - which I feel is a bit off of the original question. The question I posed was whether the framework can support BOTH UDP and RTP as a transport for the repair symbols. And IF so, then it would seem those wanting RTCP feedback should opt for RTP for the transport and NOT UDP. Greg > > > >> The receiver finds sender information from sender reports. Would the > >> source send out a sender report and give itself a SSRC for a UDP only > >> session ? If not, I don't see how this would work. > > That part would likely work, but we're already stretching the > > semantics even taking about SSRCs for non-RTP flows. > > > >> If so, a non-aware > >> RTP receiver would report no data found, which might mess > >> up the statistics (i.e., the SR's and RR's might need a flag to say, > >> this data is for a non-RTP UDP only session). > >> > > I think that's the tip of the iceberg... > > > >> The RTCP bandwidth (rtcp_bw) would need to be set to something > >> suitable, which implies that the > >> session bandwidth is set suitably (i.e., to the UDP flow, not to the > >> non-existent RTP flow). > >> > > Yup, that part doesn't seem the hard piece. > > > >> There might also be security issues about this (e.g., what if a > >> malicious user or misconfigured source starts an RTP flow in what is > >> intended > >> to be a null flow ? How do we tell RTP receivers to ignore this ?) > >> > > Well, we can protect the RTCP part with SRTCP. I don't see how you > > can prevent malicious senders from sending anything they way, so > > from that point of view I'm not sure what the new problem is. If the > > encapsulation announced in SDP is not the encapsulation sent, the > > problem exists, right? > > > > Another issue may/will be port multiplexing. There's a well-defined > > port-multiplexing scheme now for RTP/RTCP, but for arbitrary UDP/ > > RTCP that could be quite difficult - you'd need a per-FEC scheme > > multiplexing specification. > > > > > >> Regards > >> Marshall > >> > >> > >>> > >>> > >>> Or, you could design an RTP payload format for "Fecframe error > >>> control > >>> information" (conveyed in RTP). Then you even have the chance to > >>> control > >>> your control channel :-) > >>> > >>> Stephan > >>> > >>> > >>>> Assuming that we modify the framework to allow UDP and RTP, we can > >>>> use > >>>> RTCP machinery for providing feedback for the RTP-based flows. But, > >>>> what > >>>> about the UDP-based flows? Shall we ignore the feedback support for > >>>> those or let the individual schemes figure out what to do, which > >>>> IMHO > >>>> may lead to some complications? > >>>> > >>>> However, I am all ears to hear any ideas. > >>>> > >>>> -acbegen > >>>> > >>>>> -----Original Message----- > >>>>> From: Greg Shepherd [mailto:gjshep@gmail.com] > >>>>> Sent: Friday, April 18, 2008 7:05 PM > >>>>> To: Ali Begen (abegen) > >>>>> Cc: fecframe@ietf.org > >>>>> Subject: Re: [Fecframe] Feedback support by the FEC Framework > >>>>> > >>>>> On Fri, Apr 18, 2008 at 1:20 PM, Ali Begen (abegen) > >>>>> wrote: > >>>>>> Hi Greg, > >>>>>> > >>>>>> Regarding the usage of RTCP, I believe RTCP provides a > >>>>> good feedback > >>>>>> mechanism to report the performance of any FEC scheme that > >>>>> is willing > >>>>>> to use RTP as the transport protocol. RTCP has the > >>>>> built-in receiver > >>>>>> reports that are quite general and useful, but it also supports > >>>>>> extended reports where a new report type can be proposed to > >>>>>> carry > >>>>>> scheme-specific feedback. > >>>>>> > >>>>>> As many media flows will be carried over RTP, using RTCP for this > >>>>>> purpose is straightforward. I suggest folks who are not > >>>>> familiar with > >>>>>> RTP/RTCP to refer to Ulas' earlier email about a > >>>>> presentation given in > >>>>>> the AVT group. > >>>>>> http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf > >>>>>> > >>>>>> For non-RTP flows (source or repair), there is not such a > >>>>> common tool > >>>>>> that can be used to provide feedback on the repair > >>>>> performance. I have > >>>>>> not seen any proposal on this in the email list. If the > >>>>> framework will > >>>>>> support only UDP-based flows, we either need to come up > >>>>> with something > >>>>>> similar to RTCP or simply ignore the feedback issue. > >>>>> > >>>>> ..or modify the framework to allow either UDP or RTP flows. > >>>>> Is that reasonable? > >>>>> > >>>>> Greg > >>>>> > >>>>>> Regarding your second comment, RTCP receiver reports are general > >>>>>> enough to provide some feeback on any FEC flow that is > >>>>> carried over > >>>>>> RTP. If detailed, specific feedback is required by an FEC > >>>>>> scheme, > >>>>>> extended reports are the way to go. If framework supports > >>>>> RTP/RTCP, > >>>>>> this issue will be resolved right a way. > >>>>>> > >>>>>> Magnus wanted us to discuss this on the list, so let's discuss! > >>>>>> We > >>>>>> need to forward this discussion. > >>>>>> > >>>>>> -acbegen > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, > >>>>>> April 18, 2008 10:09 AM > To: Ali Begen (abegen) > Cc: > >>>>>> fecframe@ietf.org > Subject: Re: [Fecframe] Feedback > >>>>> support by the > >>>>>> FEC Framework > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen > >>>>>> (abegen) > wrote: > >>>>>>>> Hi everyone, > >>>>>>>> > >>>>>>>> Following up with Magnus' email, I would like to get your > >>>>>> opinions > > and suggestions about how the WG should proceed > >>>>>> regarding the > > feedback issue. > >>>>>>>> > >>>>>>>> Currently, the framework does not provide any > >>>>> guideline for the > >>>>>>>> receiver end-points about what they should report back > >>>>> to > the > >>>>>> sender > > (or another 3rd party). The first question is > >>>>> of course > >>>>>> whether we > > should generalize this feedback support > >>>>> and provide > >>>>>> the > guidelines in > > the framework draft OR we should leave > >>>>>> these issues to the > individual FEC schemes and CDPs. > >>>>>>>> (E.g., an FEC scheme may use RTCP machinery to > >>>>> benefit from the > >>>>>>>> receiver reports and RTCP extended reports to provide > >>>>> any level > >>>>>> of > > detailed feedback about the FEC performance and other > > >>>>>> metrics listed > > below.) > > Using "may" as you describe > >>>>>> above > >>>>>> should extend the > functionality of the framework without > >>>>> fixing a > >>>>>> solution onto > all schemes and CDPs. > >>>>>>> Any objections to this? > >>>>>>> > >>>>>>>> If you think the framework should generalize the feedback > > >>>>>> support and > > should define the minimal information that > >>>>>> will be > >>>>>> included in the > > feedback reports, please make your > >>>>>> recommendations. > >>>>>>> > >>>>>>> The protocol team came to consensus that the feedback details > > >>>>>> would likely be too scheme-specific to be generalized into > the > >>>>>> framework. If you think this is no longer the case please > > >>>>>> elaborate. Otherwise do you feel your above "may" statement > is > >>>>>> enough to open the framework to your requirements? > >>>>>>> > >>>>>>>> FYI, this issue came up in the design team meeting in late > > >>>>>> January. > >>>>>>>> The design team decided to make the feedback support > >>>>>> optional > >>>>>> (not a > > MUST but RECOMMENDED). The basic feedback > >>>>>> information > >>>>>> that - we > > thought- would be useful was: > >>>>>>>> > >>>>>>>> 1) Which FEC schemes and/or repair flows are used by which > >>>>>> clients > > 2) How useful the repair flows are, what the FEC > >>>>>> recovery > performance > > is > > 3) FEC performance > >>>>>> variation > >>>>>> over time (e.g., in the long > term for > > planning > >>>>> purposes and in > >>>>>> the short term for faster > adaptation); number > > of errors > >>>>>> in > >>>>>> errored blocks, number of errored blocks, number of > > > >>>>>> corrected > >>>>>> errors per source block, various histograms. > >>>>>>>> 4) Feedback information can also (if applicable) sent back to > >>>>>> the > > sender when all the missing symbols in a source > >>>>> block are > > >>>>>> recovered, > > and the sender starts the (early) > >>>>> transmission of the > >>>>>> next source > > block > > With the level of discussion we had > >>>>>> during the WG meeting I'm > quite surprised that the email > >>>>>> discuss > >>>>>> afterwards had died > off. We need to finalize these > >>>>> details and move > >>>>>> the draft(s) > along. Otherwise I suppose we can assume these > >>>>>> guidelines are > without opposition and move along anyway. > >>>>>>> > >>>>>>> PLEASE SPEAK UP. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Greg > >>>>>>> > >>>>>>>> Please share your comments. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> -acbegen > >>>>>>>> _______________________________________________ > >>>>>>>> Fecframe mailing list > >>>>>>>> Fecframe@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/fecframe > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> _______________________________________________ > >>>> Fecframe mailing list > >>>> Fecframe@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fecframe > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >> > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe > > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun Apr 20 09:26:43 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48813A6A8C; Sun, 20 Apr 2008 09:26:43 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250953A6A8C for ; Sun, 20 Apr 2008 09:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqu2kcs0SUtA for ; Sun, 20 Apr 2008 09:26:41 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 7199B3A69CC for ; Sun, 20 Apr 2008 09:26:22 -0700 (PDT) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 11091123; Sun, 20 Apr 2008 12:26:28 -0400 Message-Id: From: Marshall Eubanks To: "Greg Shepherd" In-Reply-To: <38c19b540804200909m43549e10n837e20511c9a00b8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 20 Apr 2008 12:26:28 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> <62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org> <16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com> <38c19b540804200909m43549e10n837e20511c9a00b8@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org On Apr 20, 2008, at 12:09 PM, Greg Shepherd wrote: > On Sun, Apr 20, 2008 at 8:42 AM, Marshall Eubanks > wrote: >> >> On Apr 20, 2008, at 11:34 AM, David R Oran wrote: >> >>> >>> On Apr 19, 2008, at 10:49 AM, Marshall Eubanks wrote: >>> >>>> >>>> On Apr 18, 2008, at 11:00 PM, stewe@stewe.org wrote: >>>> >>>>> If you need for your UDP flows a feedback channel with all the >>>>> characteristics of RTCP, why don't you simply set up one (without >>>>> having >>>>> an active RTP flow? Where is it written that the RTP channel >>>>> has to >>>>> send >>>>> any data, ever? >>>> >>> It doesn't, but the the conventional RTCP instrumentation is fairly >>> closely tied to the underlying data transport being RTP. Things like >>> SSRCs and SDES for describing sources, sequence numbers for >>> correlating the reports to the data packets, etc. I suppose it would >>> be possible to use the RTCP *framework* for reporting on non-RTP >>> flows, but it would seem to still require a new set of RTCP reports, >>> one per FEC scheme. Is that what you had in mind? >>> >> >> To me, upon reflection, I don't think that FECFRAME should be doing >> this. If we (or anyone else) really needs to be able to treat UDP >> flows in RTP with RTCP >> feedback, this seems like it should be a separate RFC coming out of >> AVT. There are too many possible worms in this can for us to handle >> it >> just >> as an aside. >> >> Regards >> Marshall > > Which part, Marshall? What is being discussed here are possibilities, > not requirements. This last issues is whether we can/should protect > non-RTP flows with RTCP - which I feel is a bit off of the original > question. > I was reacting (without any hat on) specifically to Stephan's idea of using RTCP as a feedback mechanism for UDP only flows. > The question I posed was whether the framework can support BOTH UDP > and RTP as a transport for the repair symbols. And IF so, then it > would seem those wanting RTCP feedback should opt for RTP for the > transport and NOT UDP. Indeed. If you want RTCP feedback, use RTP. Regards Marshall > > > Greg > >> >> >>>> The receiver finds sender information from sender reports. Would >>>> the >>>> source send out a sender report and give itself a SSRC for a UDP >>>> only >>>> session ? If not, I don't see how this would work. >>> That part would likely work, but we're already stretching the >>> semantics even taking about SSRCs for non-RTP flows. >>> >>>> If so, a non-aware >>>> RTP receiver would report no data found, which might mess >>>> up the statistics (i.e., the SR's and RR's might need a flag to >>>> say, >>>> this data is for a non-RTP UDP only session). >>>> >>> I think that's the tip of the iceberg... >>> >>>> The RTCP bandwidth (rtcp_bw) would need to be set to something >>>> suitable, which implies that the >>>> session bandwidth is set suitably (i.e., to the UDP flow, not to >>>> the >>>> non-existent RTP flow). >>>> >>> Yup, that part doesn't seem the hard piece. >>> >>>> There might also be security issues about this (e.g., what if a >>>> malicious user or misconfigured source starts an RTP flow in what >>>> is >>>> intended >>>> to be a null flow ? How do we tell RTP receivers to ignore this ?) >>>> >>> Well, we can protect the RTCP part with SRTCP. I don't see how you >>> can prevent malicious senders from sending anything they way, so >>> from that point of view I'm not sure what the new problem is. If the >>> encapsulation announced in SDP is not the encapsulation sent, the >>> problem exists, right? >>> >>> Another issue may/will be port multiplexing. There's a well-defined >>> port-multiplexing scheme now for RTP/RTCP, but for arbitrary UDP/ >>> RTCP that could be quite difficult - you'd need a per-FEC scheme >>> multiplexing specification. >>> >>> >>>> Regards >>>> Marshall >>>> >>>> >>>>> >>>>> >>>>> Or, you could design an RTP payload format for "Fecframe error >>>>> control >>>>> information" (conveyed in RTP). Then you even have the chance to >>>>> control >>>>> your control channel :-) >>>>> >>>>> Stephan >>>>> >>>>> >>>>>> Assuming that we modify the framework to allow UDP and RTP, we >>>>>> can >>>>>> use >>>>>> RTCP machinery for providing feedback for the RTP-based flows. >>>>>> But, >>>>>> what >>>>>> about the UDP-based flows? Shall we ignore the feedback support >>>>>> for >>>>>> those or let the individual schemes figure out what to do, which >>>>>> IMHO >>>>>> may lead to some complications? >>>>>> >>>>>> However, I am all ears to hear any ideas. >>>>>> >>>>>> -acbegen >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Greg Shepherd [mailto:gjshep@gmail.com] >>>>>>> Sent: Friday, April 18, 2008 7:05 PM >>>>>>> To: Ali Begen (abegen) >>>>>>> Cc: fecframe@ietf.org >>>>>>> Subject: Re: [Fecframe] Feedback support by the FEC Framework >>>>>>> >>>>>>> On Fri, Apr 18, 2008 at 1:20 PM, Ali Begen (abegen) >>>>>>> wrote: >>>>>>>> Hi Greg, >>>>>>>> >>>>>>>> Regarding the usage of RTCP, I believe RTCP provides a >>>>>>> good feedback >>>>>>>> mechanism to report the performance of any FEC scheme that >>>>>>> is willing >>>>>>>> to use RTP as the transport protocol. RTCP has the >>>>>>> built-in receiver >>>>>>>> reports that are quite general and useful, but it also supports >>>>>>>> extended reports where a new report type can be proposed to >>>>>>>> carry >>>>>>>> scheme-specific feedback. >>>>>>>> >>>>>>>> As many media flows will be carried over RTP, using RTCP for >>>>>>>> this >>>>>>>> purpose is straightforward. I suggest folks who are not >>>>>>> familiar with >>>>>>>> RTP/RTCP to refer to Ulas' earlier email about a >>>>>>> presentation given in >>>>>>>> the AVT group. >>>>>>>> http://www.ietf.org/proceedings/08mar/slides/avt-11.pdf >>>>>>>> >>>>>>>> For non-RTP flows (source or repair), there is not such a >>>>>>> common tool >>>>>>>> that can be used to provide feedback on the repair >>>>>>> performance. I have >>>>>>>> not seen any proposal on this in the email list. If the >>>>>>> framework will >>>>>>>> support only UDP-based flows, we either need to come up >>>>>>> with something >>>>>>>> similar to RTCP or simply ignore the feedback issue. >>>>>>> >>>>>>> ..or modify the framework to allow either UDP or RTP flows. >>>>>>> Is that reasonable? >>>>>>> >>>>>>> Greg >>>>>>> >>>>>>>> Regarding your second comment, RTCP receiver reports are >>>>>>>> general >>>>>>>> enough to provide some feeback on any FEC flow that is >>>>>>> carried over >>>>>>>> RTP. If detailed, specific feedback is required by an FEC >>>>>>>> scheme, >>>>>>>> extended reports are the way to go. If framework supports >>>>>>> RTP/RTCP, >>>>>>>> this issue will be resolved right a way. >>>>>>>> >>>>>>>> Magnus wanted us to discuss this on the list, so let's discuss! >>>>>>>> We >>>>>>>> need to forward this discussion. >>>>>>>> >>>>>>>> -acbegen >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Friday, >>>>>>>> April 18, 2008 10:09 AM > To: Ali Begen (abegen) > Cc: >>>>>>>> fecframe@ietf.org > Subject: Re: [Fecframe] Feedback >>>>>>> support by the >>>>>>>> FEC Framework > > On Thu, Mar 13, 2008 at 11:16 AM, Ali Begen >>>>>>>> (abegen) > wrote: >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> Following up with Magnus' email, I would like to get your >>>>>>>> opinions > > and suggestions about how the WG should proceed >>>>>>>> regarding the > > feedback issue. >>>>>>>>>> >>>>>>>>>> Currently, the framework does not provide any >>>>>>> guideline for the >>>>>>>>>> receiver end-points about what they should report back >>>>>>> to > the >>>>>>>> sender > > (or another 3rd party). The first question is >>>>>>> of course >>>>>>>> whether we > > should generalize this feedback support >>>>>>> and provide >>>>>>>> the > guidelines in > > the framework draft OR we should >>>>>>>> leave >>>>>>>> these issues to the > individual FEC schemes and CDPs. >>>>>>>>>> (E.g., an FEC scheme may use RTCP machinery to >>>>>>> benefit from the >>>>>>>>>> receiver reports and RTCP extended reports to provide >>>>>>> any level >>>>>>>> of > > detailed feedback about the FEC performance and >>>>>>>> other > >>>>>>>> metrics listed > > below.) > > Using "may" as you describe >>>>>>>> above >>>>>>>> should extend the > functionality of the framework without >>>>>>> fixing a >>>>>>>> solution onto > all schemes and CDPs. >>>>>>>>> Any objections to this? >>>>>>>>> >>>>>>>>>> If you think the framework should generalize the feedback > >>>>>>>> support and > > should define the minimal information that >>>>>>>> will be >>>>>>>> included in the > > feedback reports, please make your >>>>>>>> recommendations. >>>>>>>>> >>>>>>>>> The protocol team came to consensus that the feedback >>>>>>>>> details > >>>>>>>> would likely be too scheme-specific to be generalized into > >>>>>>>> the >>>>>>>> framework. If you think this is no longer the case please > >>>>>>>> elaborate. Otherwise do you feel your above "may" statement >>>>>>>> > is >>>>>>>> enough to open the framework to your requirements? >>>>>>>>> >>>>>>>>>> FYI, this issue came up in the design team meeting in late > >>>>>>>> January. >>>>>>>>>> The design team decided to make the feedback support >>>>>>>> optional >>>>>>>> (not a > > MUST but RECOMMENDED). The basic feedback >>>>>>>> information >>>>>>>> that - we > > thought- would be useful was: >>>>>>>>>> >>>>>>>>>> 1) Which FEC schemes and/or repair flows are used by which >>>>>>>> clients > > 2) How useful the repair flows are, what the FEC >>>>>>>> recovery > performance > > is > > 3) FEC performance >>>>>>>> variation >>>>>>>> over time (e.g., in the long > term for > > planning >>>>>>> purposes and in >>>>>>>> the short term for faster > adaptation); number > > of errors >>>>>>>> in >>>>>>>> errored blocks, number of errored blocks, number of > > >>>>>>>> corrected >>>>>>>> errors per source block, various histograms. >>>>>>>>>> 4) Feedback information can also (if applicable) sent back to >>>>>>>> the > > sender when all the missing symbols in a source >>>>>>> block are > >>>>>>>> recovered, > > and the sender starts the (early) >>>>>>> transmission of the >>>>>>>> next source > > block > > With the level of discussion we >>>>>>>> had >>>>>>>> during the WG meeting I'm > quite surprised that the email >>>>>>>> discuss >>>>>>>> afterwards had died > off. We need to finalize these >>>>>>> details and move >>>>>>>> the draft(s) > along. Otherwise I suppose we can assume these >>>>>>>> guidelines are > without opposition and move along anyway. >>>>>>>>> >>>>>>>>> PLEASE SPEAK UP. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Greg >>>>>>>>> >>>>>>>>>> Please share your comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> -acbegen >>>>>>>>>> _______________________________________________ >>>>>>>>>> Fecframe mailing list >>>>>>>>>> Fecframe@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Fecframe mailing list >>>>>> Fecframe@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Fecframe mailing list >>>>> Fecframe@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun Apr 20 12:52:07 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4973A6E49; Sun, 20 Apr 2008 12:52:07 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CAC28C328 for ; Sun, 20 Apr 2008 12:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJWPYVHmT5Ld for ; Sun, 20 Apr 2008 12:52:06 -0700 (PDT) Received: from h665227.serverkompetenz.net (stewe.org [85.214.23.117]) by core3.amsl.com (Postfix) with ESMTP id 2AC1D3A6E49 for ; Sun, 20 Apr 2008 12:52:05 -0700 (PDT) Received: (qmail 2211 invoked by uid 60000); 20 Apr 2008 19:12:17 -0000 Received: from 127.0.0.1 by h665227 (envelope-from , uid 60004) with qmail-scanner-1.24st visas (spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 0.7907 secs); 20 Apr 2008 19:12:17 -0000 Received: from localhost (HELO webmail.stewe.org) (127.0.0.1) by localhost with SMTP; 20 Apr 2008 19:12:16 -0000 Received: from 192.100.104.17 (proxying for 10.241.59.225) (SquirrelMail authenticated user stewe@stewe.org) by webmail.stewe.org with HTTP; Sun, 20 Apr 2008 21:12:16 +0200 (CEST) Message-ID: <3198.192.100.104.17.1208718736.squirrel@webmail.stewe.org> In-Reply-To: References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com> <38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com> <38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com> <62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org> <16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com> <38c19b540804200909m43549e10n837e20511c9a00b8@mail.gmail.com> Date: Sun, 20 Apr 2008 21:12:16 +0200 (CEST) From: stewe@stewe.org To: "Marshall Eubanks" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Marshall, > On Apr 20, 2008, at 12:09 PM, Greg Shepherd wrote: > >> On Sun, Apr 20, 2008 at 8:42 AM, Marshall Eubanks > Which part, Marshall? What is being discussed here are possibilities, >> not requirements. This last issues is whether we can/should protect >> non-RTP flows with RTCP - which I feel is a bit off of the original >> question. >> >[...] > I was reacting (without any hat on) > specifically to Stephan's idea of using RTCP as a feedback mechanism > for UDP only flows. > >> The question I posed was whether the framework can support BOTH UDP >> and RTP as a transport for the repair symbols. And IF so, then it >> would seem those wanting RTCP feedback should opt for RTP for the >> transport and NOT UDP. > > Indeed. If you want RTCP feedback, use RTP. > No. (To the logic expressed in the sentence, but perhaps not to the one implied.) I consider it foolish and architecturally unsound to place something that works perfectly well over UDP into RTP, just to be able to use RTCP. RTP has a certain functionality, much of which is not needed to convey the information needed for fecframe. And, RTP has overhead associated with it, that you don't need. Think of some of the applications of fecframe, please. Overhead counts. (And yes, I know there is rohc.) Can someone explain to me, how (for example) payload type, marker bit, timestamp, ssrc, relate to fecframe data? I buy the sequence number :-) If there were a solid justification beyond the use of RTCP, I would probably buy the fecframe-in-RTP argument. Stephan >[...] _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun Apr 20 22:33:30 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8EB3A6C2B; Sun, 20 Apr 2008 22:33:30 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04C628C138 for ; Sun, 20 Apr 2008 22:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toFOErFCHr2V for ; Sun, 20 Apr 2008 22:33:28 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 925743A6C2B for ; Sun, 20 Apr 2008 22:33:28 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 17DA020802; Mon, 21 Apr 2008 07:33:34 +0200 (CEST) X-AuditID: c1b4fb3c-ad89abb00000193b-4f-480c272d1221 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E864D207F9; Mon, 21 Apr 2008 07:33:33 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 07:33:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 07:33:32 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05075B62B1@esealmw109.eemea.ericsson.se> In-Reply-To: <3198.192.100.104.17.1208718736.squirrel@webmail.stewe.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Feedback support by the FEC Framework thread-index: AcijIAj6SFdfCZWeTmmoGDV2j+tocAAUBLPg References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com><38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com><38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com><62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org><16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com><38c19b540804200909m43549e10n837e20511c9a00b8@mail.gmail.com> <3198.192.100.104.17.1208718736.squirrel@webmail.stewe.org> From: "Ingemar Johansson S" To: "Marshall Eubanks" X-OriginalArrivalTime: 21 Apr 2008 05:33:33.0841 (UTC) FILETIME=[3D7EC810:01C8A371] X-Brightmail-Tracker: AAAAAA== Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Haven't followed this topic fully so my response may not be relevant, anyway as I understand the subject you may consider a look at DCCP rather than UDP. Surely DCCP has its issues, but as it contains both timestamp and also support for different congestion control mechanisms there is not need for RTCP like mechanisms AFAIK. Another interesting protocol may be SST (http://pdos.csail.mit.edu/papers/sst:sigcomm07.pdf) but this is more a research level project, still worth a closer look. Regards Ingemar -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of stewe@stewe.org Sent: den 20 april 2008 21:12 To: Marshall Eubanks Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework Hi Marshall, > On Apr 20, 2008, at 12:09 PM, Greg Shepherd wrote: > >> On Sun, Apr 20, 2008 at 8:42 AM, Marshall Eubanks >> > here are possibilities, not requirements. This last issues is whether >> we can/should protect non-RTP flows with RTCP - which I feel is a bit >> off of the original question. >> >[...] > I was reacting (without any hat on) > specifically to Stephan's idea of using RTCP as a feedback mechanism > for UDP only flows. > >> The question I posed was whether the framework can support BOTH UDP >> and RTP as a transport for the repair symbols. And IF so, then it >> would seem those wanting RTCP feedback should opt for RTP for the >> transport and NOT UDP. > > Indeed. If you want RTCP feedback, use RTP. > No. (To the logic expressed in the sentence, but perhaps not to the one implied.) I consider it foolish and architecturally unsound to place something that works perfectly well over UDP into RTP, just to be able to use RTCP. RTP has a certain functionality, much of which is not needed to convey the information needed for fecframe. And, RTP has overhead associated with it, that you don't need. Think of some of the applications of fecframe, please. Overhead counts. (And yes, I know there is rohc.) Can someone explain to me, how (for example) payload type, marker bit, timestamp, ssrc, relate to fecframe data? I buy the sequence number :-) If there were a solid justification beyond the use of RTCP, I would probably buy the fecframe-in-RTP argument. Stephan >[...] _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Tue Apr 22 14:39:41 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDF03A6AEE; Tue, 22 Apr 2008 14:39:41 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2EE3A6AEE for ; Tue, 22 Apr 2008 14:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT9TO3cl4FE9 for ; Tue, 22 Apr 2008 14:39:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E151C3A69B1 for ; Tue, 22 Apr 2008 14:39:38 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Apr 2008 14:39:45 -0700 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 m3MLdi2U014792; Tue, 22 Apr 2008 14:39:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3MLdi1u013248; Tue, 22 Apr 2008 21:39:45 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 14:39:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 14:39:25 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5406F088C9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <3198.192.100.104.17.1208718736.squirrel@webmail.stewe.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Feedback support by the FEC Framework Thread-Index: AcijIBXNq5xHEtYKTpCSQSGuKp+gGABn8wuw References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com><38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com><38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com><62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org><16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com><38c19b540804200909m43549e10n837e20511c9a00b8@mail.gmail.com> <3198.192.100.104.17.1208718736.squirrel@webmail.stewe.org> From: "Ali Begen (abegen)" To: , "Marshall Eubanks" X-OriginalArrivalTime: 22 Apr 2008 21:39:44.0875 (UTC) FILETIME=[615653B0:01C8A4C1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3072; t=1208900385; x=1209764385; 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]=20Feedback=20support=20by=20 the=20FEC=20Framework |Sender:=20; bh=LrPKeY0h+LF+hDwD9iYdH8XxjGGd+zRgwGfeY3aN5Mg=; b=UOIkVX3LAnX6yIGBF7JPD2r8XJvAlLKnn1v4NnwC4TMb2zUazUAXn0cI9W a7Hs2bNnfBreladDcCCESKOQ6YwvjmhiMZovStejgeB4lfOrLfu2LEmULi10 hE/NVj7+mKN3cPC6VMbVXLwRhVnw5nJVxUhPLIwAEBXJa5HFae238=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Stephan, There are certain advantages for using RTP encapsulation for the repair flows. Based on the discussion, I believe the framework will support both UDP and RTP-based repair flows. I think nobody objects that. Anybody? For those who want to use RTP for the repair flows, IMO a 12-byte overhead is reasonably OK for 1500-byte packets. The ability of using RTCP itself may be enough reason for this overhead. The discussion over the last few days is good but I am afraid I did not get the answer I was hoping for. The original question was: What is the right/suitable feedback mechanism for UDP-based repair flows in the framework? Current direction shows that UDP-based repair flows will not be using a common feedback framework. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On Behalf Of stewe@stewe.org > Sent: Sunday, April 20, 2008 12:12 PM > To: Marshall Eubanks > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Feedback support by the FEC Framework > > Hi Marshall, > > > On Apr 20, 2008, at 12:09 PM, Greg Shepherd wrote: > > > >> On Sun, Apr 20, 2008 at 8:42 AM, Marshall Eubanks > >> discussed > >> here are possibilities, not requirements. This last issues > is whether > >> we can/should protect non-RTP flows with RTCP - which I > feel is a bit > >> off of the original question. > >> > > >[...] > > > I was reacting (without any hat on) > > specifically to Stephan's idea of using RTCP as a feedback > mechanism > > for UDP only flows. > > > >> The question I posed was whether the framework can support > BOTH UDP > >> and RTP as a transport for the repair symbols. And IF so, then it > >> would seem those wanting RTCP feedback should opt for RTP for the > >> transport and NOT UDP. > > > > Indeed. If you want RTCP feedback, use RTP. > > > > No. (To the logic expressed in the sentence, but perhaps not > to the one > implied.) > > I consider it foolish and architecturally unsound to place > something that works perfectly well over UDP into RTP, just > to be able to use RTCP. RTP has a certain functionality, > much of which is not needed to convey the information needed > for fecframe. And, RTP has overhead associated with it, that > you don't need. Think of some of the applications of > fecframe, please. Overhead counts. (And yes, I know there is rohc.) > > Can someone explain to me, how (for example) payload type, > marker bit, timestamp, ssrc, relate to fecframe data? I buy > the sequence number :-) > > If there were a solid justification beyond the use of RTCP, I > would probably buy the fecframe-in-RTP argument. > > Stephan > > >[...] > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Thu Apr 24 17:15:12 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D01D3A69E9; Thu, 24 Apr 2008 17:15:12 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E463A6B52 for ; Thu, 24 Apr 2008 17:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r3cmkUXQFz3 for ; Thu, 24 Apr 2008 17:15:08 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 647583A6B35 for ; Thu, 24 Apr 2008 17:15:08 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1687142rvf.49 for ; Thu, 24 Apr 2008 17:15:13 -0700 (PDT) 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:cc:mime-version:content-type; bh=Ra3Knlbpf1ou497YYNw2FDVbQb3G6hyZ3xf22yAeU0o=; b=R2O1t8J4D0A6SipmS0VopF2hVJaLyyxx8A6BIFECIDEVH+8X7rqDB1UTHU5QOvQvTGrRPP9P0I7KOeSLNwXfb32tCchoVDe+juik1O/wgk1Z7Qz+dkuBdI7GsCqxH3aKweox3zjFGisX95Me5o+TnUcsu+IFb73ZpsDkm6DuURA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=lP+QU9fxxEA4IZ3BS+SMsgefWXaFfMFowek91Vuy0QRBtaF0ohaGmbFww/ySpxVTf1zmgvGEKDqRcLwjLcRBzPZF5lonThkVIumD0IiF94KakAw6t1K7B10XG5hVDiw5vDLjuIgUvppnM/YEACl0ypKPI+sg8APQ+yS5FAoZm5E= Received: by 10.141.88.3 with SMTP id q3mr552528rvl.46.1209082513499; Thu, 24 Apr 2008 17:15:13 -0700 (PDT) Received: by 10.140.158.6 with HTTP; Thu, 24 Apr 2008 17:15:13 -0700 (PDT) Message-ID: <241bc2150804241715m76941a23o3aad26ebda431e6e@mail.gmail.com> Date: Thu, 24 Apr 2008 17:15:13 -0700 From: "=?ISO-8859-2?Q?Ula=BA_C._Kozat?=" To: "Greg Shepherd" , "Marshall Eubanks" MIME-Version: 1.0 Cc: fecframe@ietf.org Subject: [Fecframe] draft document for clarifying use cases of framework document X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1554152548==" Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org --===============1554152548== Content-Type: multipart/alternative; boundary="----=_Part_3635_12806072.1209082513501" ------=_Part_3635_12806072.1209082513501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Greg and Marshall, We had a brief meeting with Ali today to discuss various issues some related to the FECFRAME. We think it is a good idea to generate a new document based on the framework document and explain some parts in more detail (e.g., how we utilize different fields specified in the framework as optional and/or required in different scenarios). We want to pay particular attention to the scenarios where multiple source flows are protected together by one or multiple repair flows. I am cc-ing to the fecframe list in case people have suggestions or concerns before we jump into generating such a draft. Ulas ------=_Part_3635_12806072.1209082513501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Greg and Marshall,

We had a brief meeting with Ali today to discuss various issues some related to the FECFRAME. We think it is a good idea to generate a new document based on the framework document and explain some parts in more detail (e.g., how we utilize different fields specified in the framework as optional and/or required in different scenarios). We want to pay particular attention to the scenarios where multiple source flows are protected together by one or multiple repair flows.

I am cc-ing to the fecframe list in case people have suggestions or concerns before we jump into generating such a draft.

Ulas


------=_Part_3635_12806072.1209082513501-- --===============1554152548== 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://www.ietf.org/mailman/listinfo/fecframe --===============1554152548==-- From fecframe-bounces@ietf.org Tue Apr 29 08:35:48 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29EC3A6DE0; Tue, 29 Apr 2008 08:35:47 -0700 (PDT) X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D0228C32B for ; Tue, 29 Apr 2008 08:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbtDRXMv036z for ; Tue, 29 Apr 2008 08:35:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 124163A6DD1 for ; Tue, 29 Apr 2008 08:35:45 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DE75D2046E; Tue, 29 Apr 2008 17:35:46 +0200 (CEST) X-AuditID: c1b4fb3e-ab993bb000004ec0-09-48174052ced8 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BDFF920271; Tue, 29 Apr 2008 17:35:46 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 17:35:46 +0200 Received: from [127.0.0.1] ([147.214.183.174]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 17:35:46 +0200 Message-ID: <48174052.70207@ericsson.com> Date: Tue, 29 Apr 2008 17:35:46 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Ali Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D5406AFFC7D@xmb-sjc-215.amer.cisco.com><38c19b540804181009t3ab3214u8e50b4351acfe4af@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D5406EA43D5@xmb-sjc-215.amer.cisco.com><38c19b540804181904p4ec74c62lc45ec35ede31c3d5@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D5406EA4583@xmb-sjc-215.amer.cisco.com><62790.192.100.104.17.1208574034.squirrel@webmail.stewe.org><16810A60-7E3A-4901-AC99-62B2B426F9B6@multicasttech.com><38c19b540804200909m43549e10n837e20511c9a00b8@mail.gmail.com> <3198.192.100.104.17.1208718736.squirrel@webmail.stewe.org> <04CAD96D4C5A3D48B1919248A8FE0D5406F088C9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5406F088C9@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 29 Apr 2008 15:35:46.0503 (UTC) FILETIME=[B18B7570:01C8AA0E] X-Brightmail-Tracker: AAAAAA== Cc: fecframe@ietf.org Subject: Re: [Fecframe] Feedback support by the FEC Framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Ali Begen (abegen) skrev: > Hi Stephan, > = > There are certain advantages for using RTP encapsulation for the repair > flows. Based on the discussion, I believe the framework will support > both UDP and RTP-based repair flows. I think nobody objects that. > Anybody? > = > For those who want to use RTP for the repair flows, IMO a 12-byte > overhead is reasonably OK for 1500-byte packets. The ability of using > RTCP itself may be enough reason for this overhead. = > = > The discussion over the last few days is good but I am afraid I did not > get the answer I was hoping for. The original question was: > = > What is the right/suitable feedback mechanism for UDP-based > repair flows in the framework? > = > Current direction shows that UDP-based repair flows will not be using a > common feedback framework. > = Hi, (as individual) I think there are some architectural considerations here for the = framework in regards to feedback mechanisms. Especially with a mix of = flows. I personally didn't think about this issue at all at the point of = chartering the WG. I think it would be good to have a generic mechanism. = However, I don't know if there is enough energy in the WG to take this = on currently. To me it seems that some thinking on the architecture for how this can = be implemented as part of the transport for the framework could ensure = that there are sufficient room for future extensions into this area if = enough interest exist. When it comes to RTP and RTCP I am a believer that FEC in the RTP = payload formats (as has so far been done in RTP) has one real short = comming in that it does not cover the RTCP traffic from the sender to = the client. This becomes relevant in any environments where the packet = loss rate is a bit higher due to that simple repetition of RTCP suddenly = aren't enough. So you get perfect or close to perfect media delivery but = lose a significant part of control traffic from the sender. Quite = relevant in RTCP SSM usage or when other interesting extensions are in = use. Sure, this becomes less relevant if ones reason for using FEC is to = move from <0.5% loss to <10E-6 frame losses to ensure quality. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe