Re: [FECFRAME-PROTO] A new informational draft on fec grouping issues
"Rajiv Asati (rajiva)" <rajiva@cisco.com> Mon, 10 March 2008 21:01 UTC
Return-Path: <fecframe-proto-bounces@ietf.org>
X-Original-To: ietfarch-fecframe-proto-archive@core3.amsl.com
Delivered-To: ietfarch-fecframe-proto-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2046F28C16D; Mon, 10 Mar 2008 14:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.95
X-Spam-Level:
X-Spam-Status: No, score=-100.95 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 ImFTEQ9YqJzw; Mon, 10 Mar 2008 14:01:17 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A0E28C2D8; Mon, 10 Mar 2008 14:00:42 -0700 (PDT)
X-Original-To: fecframe-proto@core3.amsl.com
Delivered-To: fecframe-proto@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA82928C290 for <fecframe-proto@core3.amsl.com>; Mon, 10 Mar 2008 14:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 4MEuwZsXuBv3 for <fecframe-proto@core3.amsl.com>; Mon, 10 Mar 2008 14:00:39 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8C7E23A6EE8 for <fecframe-proto@ietf.org>; Mon, 10 Mar 2008 14:00:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.25,476,1199682000"; d="scan'208";a="1228271"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Mar 2008 16:57:39 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2AKvb3w015499; Mon, 10 Mar 2008 16:57:37 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2AKvGjx028422; Mon, 10 Mar 2008 20:57:37 GMT
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 16:57:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 10 Mar 2008 16:56:40 -0400
Message-ID: <15B86BC7352F864BB53A47B540C089B6050FF604@xmb-rtp-20b.amer.cisco.com>
In-Reply-To: <C3FAB7DC.25E3B%mark@digitalfountain.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [FECFRAME-PROTO] A new informational draft on fec grouping issues
Thread-Index: Achturhr2vPK5a3xQa6iuOp60OoAJgAAX5EwAABMybAAIffIEAAEU0gAAHsSD+IAAgEh8ACU6WmzAxavw0AA74wQiAAOOYsQ
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Mark Watson <mark@digitalfountain.com>, "Ali Begen (abegen)" <abegen@cisco.com>, fecframe-proto@ietf.org
X-OriginalArrivalTime: 10 Mar 2008 20:57:35.0033 (UTC) FILETIME=[5DABD290:01C882F1]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15830; t=1205182657; x=1206046657; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20(rajiva)=22=20<rajiva@cisco.com > |Subject:=20RE=3A=20[FECFRAME-PROTO]=20A=20new=20informatio nal=20draft=20on=20fec=20grouping=20issues |Sender:=20 |To:=20=22Mark=20Watson=22=20<mark@digitalfountain.com>,=0A =20=20=20=20=20=20=20=20=22Ali=20Begen=20(abegen)=22=20<abeg en@cisco.com>,=20<fecframe-proto@ietf.org>; bh=6Pp+RGrbp9FJRaJxdGV2Nec63Qg3lBep74EI7wH3AFk=; b=oIKeNWrUCYaxcjT84aoqNNyMhmLNrg2JuX2ZlByH5BV/s+JrB4W3fLOuP6 qqkBs1WcMlkxcyDv59BdBe/cnXfqa4Z7OkgZo3Qn3rnhSCbxYsAGPqNhsiPH e/OX0NJUpr;
Authentication-Results: rtp-dkim-1; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Subject: Re: [FECFRAME-PROTO] A new informational draft on fec grouping issues
X-BeenThere: fecframe-proto@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Fecframe protocol design team <fecframe-proto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe-proto>, <mailto:fecframe-proto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/fecframe-proto>
List-Post: <mailto:fecframe-proto@ietf.org>
List-Help: <mailto:fecframe-proto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe-proto>, <mailto:fecframe-proto-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: fecframe-proto-bounces@ietf.org
Errors-To: fecframe-proto-bounces@ietf.org
Hi Mark, > The repair flow packet contents can be whatever the FEC > Scheme defines, but the Framework sees only up to the UDP > layer. Since we want the SDP to be at the "Framework" level, > with all scheme-specifics encapsulated in the FSSI, then I > think that fecframe repair flows should always have udp/fec > as transport. Are you suggesting that the RTP header generation (and associated processing) to be delegated to the FEC scheme? > I'm not sure I understand. The object with FECFRAME is to > provide for protection of arbitrary flows over UDP (or DCCP, > I guess), so I'm not sure how it makes sense for the > Framework to set where you have shown it in the architecture below. At minimum, I think that we agree to show the FEC framework block to directly get the data from the application (MPEGoUDP, for example). Cheers, Rajiv > -----Original Message----- > From: Mark Watson [mailto:mark@digitalfountain.com] > Sent: Monday, March 10, 2008 10:03 AM > To: Rajiv Asati (rajiva); Ali Begen (abegen); fecframe-proto@ietf.org > Subject: Re: [FECFRAME-PROTO] A new informational draft on > fec grouping issues > > Hi Rajiv, > > Some comments below. > > ...Mark > > > On 3/7/08 5:38 AM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote: > > > > > > > To say something is "not forbidden" is different from > saying it is > > "mandated". The RFC simply doesn't give any indication of > > what to do in the scenario we are talking about. > > I agree with Mark. We should just say that the existing > means (RFC4756) just don't solve the FEC framework > requirements. Such text conveys the lack of solution a lot better. > > > No, I mean "m=application 3000 udp/fec" for the repair flow. > > The repair flow is not an audio or video flow. > > Good catch. Must be incorporated in the next version of > the draft. > > > If there is RTP involved, it's in the source flows, not the > > repair flow. So > > it it not correct to say the repair flow is an RTP flow. > > The more I think about it, the more I realize that we > should not mandate a particular transport layer or protocol > for the repair flow, though the preferred option may be > highlighted. We should _not_ deny RTP to be the transport > protocol for the repair flow, independent of what's used for > source flow. This opens up the framework to benefit from the > avantages such as the usage of RTCP for reports, the > sequencing etc. Moreover, the underlying IP network can also > benefit from the RTP usage (to employ flow monitoring using > seq#, for example). > > > > The repair flow packet contents can be whatever the FEC > Scheme defines, but the Framework sees only up to the UDP > layer. Since we want the SDP to be at the "Framework" level, > with all scheme-specifics encapsulated in the FSSI, then I > think that fecframe repair flows should always have udp/fec > as transport. > > > > Also, the FEC framework architecture building block > diagram needs to be updated to show that FEC framework block > can get the media payload directly from the application > (MPEGoUDPoIP, for example). Overall, the architecture > building block should be updated as shown in the attached slide. > > > > I'm not sure I understand. The object with FECFRAME is to > provide for protection of arbitrary flows over UDP (or DCCP, > I guess), so I'm not sure how it makes sense for the > Framework to set where you have shown it in the architecture below. > > ...Mark > > > > > > Cheers, > Rajiv > > > -----Original Message----- > > From: Mark Watson [mailto:mark@digitalfountain.com > <mailto:mark@digitalfountain.com> > <mailto:mark@digitalfountain.com> ] > > Sent: Monday, February 18, 2008 9:24 PM > > To: Ali Begen (abegen); Rajiv Asati (rajiva); > fecframe-proto@ietf.org > > Subject: Re: [FECFRAME-PROTO] A new informational draft on > > fec grouping issues > > > > Ali, > > > > See comments inline... > > > > > > On 2/15/08 8:23 PM, "Ali Begen (abegen)" > <abegen@cisco.com> wrote: > > > > > Hi Mark, > > > > > > Thanks for the review. I submitted it yesterday, > but I will make the > > > changes in the next submission (or mention them in the > > meeting, if we > > > can get a slot). > > > > > > My comments are in between. > > > > > >> Ali, > > >> > > >> Sorry if these comments are a little late. They are > > >> non-essential apart from (7). > > >> > > >> 1) At the end of Section 3.1, you say the group attribute > > >> specification 'mandates us to write a=group:FEC S1 > S2 R1 R1'. > > >> Actually, I think it would be more accurate to > just say that > > >> the grouping specification does not support the case > > described at all. > > >> > > >> Writing 'a=group:FEC S1 S2 R1 R1' clearly doesn't make any > > >> sense in this > > >> case: it would be a defect in the specification if it > > >> 'mandated' something which made no sense, whereas > I think a > > >> better way to look at it is that the specification simply > > >> doesn't address this case. > > > > > > In the context of RFC 4756, the way I understand it is > > permissible to > > > write "a=group:FEC S1 S2 R1 R2." It would not make much > > sense, I agree, > > > but it is not forbidden, either. This line is also a valid > > statement > > > from 3388's perspective. Is not it? > > > > > > > To say something is "not forbidden" is different from > saying it is > > "mandated". The RFC simply doesn't give any indication of > > what to do in the > > scenario we are talking about. You have read into it that > > because the only > > thing close is a=group:FEC S1 S2 R1 R2 then this is that the > > RFC "intended" > > for this case. But the RFC didn't intend anything for this > > case - you're > > reading in more than it says. We might as well say the RFC > > mandates writing > > "a=group:FEC" with just as much justification and making just > > as much sense > > (i.e. None). > > > > > > >> 2) I'm not sure what is meant by the next sentence > 'Note that > > >> source and repair flows are identified by their payload > > >> formats and/or other descriptors > > >> [I-D.begen-fecframe-sdp-elements].' Also, it doesn't seem > > >> relevant in this context where we describe > limitations of the > > >> other specifications. > > > > > > I'll clarify here. > > > > > >> 3) 3.3. - the requirement to obey the prioritisation is a > > >> SHOULD in this context, since it is just an optimisation. > > > > > > If I recall correctly from the design team meeting, > we set this to a > > > MUST. If you think it should be a SHOULD, we should > discuss it. The > > > current SDP draft also says it is a MUST. > > > > > >> 4) 3.3 - 'It might be highly desirable to keep all the > > >> receivers ...' - 'all' should be 'most'. > > > > > > OK. > > > > > >> 5) 3.3 - 'Currently, there is no SDP semantics for > indicating > > >> the priority levels of the individual flows that > are grouped > > >> in an "a=group" line.' - remove from 'that are > grouped ...' > > >> onwards, since we have not decided to use the a=group and > > >> indeed are pointing out where it is deficient > > > > > > OK. > > > > > >> 6) 4 - 'There are two main solution approaches.' - > That's a > > >> broad statement! > > >> Perhaps you mean there are two solution approaches > described > > >> in the draft ? > > > > > > Agree. > > > > > >> Another possibility would be to define an fec-specific > > >> mechanism, where each repair flow simply refers > directly to > > >> the protected source flows (this is done in 3GPP, > for example). > > > > > > So, we should simply say 'group s1 r1', 'group s1 > r2', etc if all of > > > these repair flows are protecting s1? Is this what you > > meant? If that is > > > the case, we will need something additional to > signal the additivity > > > since this approach does not differentiate the flows that > > are additive > > > from the ones that are not additive. > > > > For example, we could have an fec-specific attribute (e.g. > > a=fec-repair) and > > somewhere in that attribute line is the list of protected > > source flows. > > > > > > > >> 7) 4.1 and 4.2 - in the examples, the FEC repair > flows should > > >> be 'application' not 'video' type and the transport > > >> identifier should be 'udp/fec', not 'rtp/avp'. > There should > > >> not be an rtpmap attribute. > > > > > > You mean "m=video 30000 udp application" for the > source flows and > > > "m=video 30000 UDP/FEC application" for the repair flows? > > Or, should the > > > media sub-fields be "application" as well? > > > > No, I mean "m=application 3000 udp/fec" for the repair flow. > > The repair flow is not an audio or video flow. > > > > The source flow syntax is unchanged by the use of FEC. > > > > > > > > BTW, is not using 'RTP/AVP' acceptable? > > > > No. The repair flows are not RTP flows. There is no RTP layer > > defined in the > > repair packet format. > > > > > At the end, we might be > > > protecting the whole RTP packets and the stream > might actually carry > > > video, audio, etc? Or, we can't use examples with RTP/AVP > > for now since > > > no payload format is defined for using RTP with fec > framework? > > > > > > > If there is RTP involved, it's in the source flows, not the > > repair flow. So > > it it not correct to say the repair flow is an RTP flow. > > > > > (BTW, the examples are modified from the ones in SDP draft) > > > > So, then, that is wrong as well. Any chance to update before > > the meeting ? > > > > > > > > Thanks, > > > -acbegen > > > > > >> ...Mark > > >> > > >> > > >> On 2/13/08 7:45 AM, "Ali Begen (abegen)" > <abegen@cisco.com> wrote: > > >> > > >>> Hi Rajiv, > > >>> > > >>> Thanks for reading the draft. For other who have not > > >> started reading, > > >>> pls see the updated version (attached). > > >>> > > >>> I asked someone without any FEC background to > comment on the draft > > >>> (seems that we will have the same issue in MMUSIC). So, I > > >> expanded the > > >>> intro part and make clarifications about what we > meant with > > >>> prioritization, additivity, etc. > > >>> > > >>> Thanks again, > > >>> -acbegen > > >>> > > >>>> -----Original Message----- > > >>>> From: Rajiv Asati (rajiva) > > >>>> Sent: Wednesday, February 13, 2008 5:36 AM > > >>>> To: Ali Begen (abegen); 'fecframe-proto@ietf.org' > > >>>> Subject: RE: [FECFRAME-PROTO] A new > informational draft on fec > > >>>> grouping issues > > >>>> > > >>>> Hi Ali, > > >>>> > > >>>> That's fine. > > >>>> I just got to see the draft. Looks fine to me. > > >>>> > > >>>> Cheers, > > >>>> Rajiv > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Ali Begen (abegen) > > >>>>> Sent: Tuesday, February 12, 2008 4:28 PM > > >>>>> To: Rajiv Asati (rajiva); 'fecframe-proto@ietf.org' > > >>>>> Subject: RE: [FECFRAME-PROTO] A new > informational draft on fec > > >>>>> grouping issues > > >>>>> > > >>>>> This is just for describing the problem and > showing some > > >>>> alternative > > >>>>> solutions. It does not have to become anything. > > >>>>> That's why, it is intended to be informational. > > >>>>> > > >>>>> If MMUSIC agrees to adopt one of the solutions > described > > >>>> here or comes > > >>>>> up with a new one, then of course we should > work on that draft > > >>>>> together, which should be in the cateogry of "proposed > > standard." > > >>>>> > > >>>>> However, note that MMUSIC WG should approve what needs > > to be done > > >>>>> here. And, that's why we need to tell them > about our problems. > > >>>>> > > >>>>> -acbegen > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Rajiv Asati (rajiva) > > >>>>>> Sent: Tuesday, February 12, 2008 1:17 PM > > >>>>>> To: Ali Begen (abegen); fecframe-proto@ietf.org > > >>>>>> Subject: RE: [FECFRAME-PROTO] A new > informational draft on fec > > >>>>>> grouping issues > > >>>>>> > > >>>>>> Hi Ali, > > >>>>>> > > >>>>>> We (the protocol team) should all collaborate > to jointly > > >>>> author the > > >>>>>> new draft, if/when it needs to be produced. > > >>>>>> > > >>>>>> Also, why should it be the informational draft? > > >>>>>> > > >>>>>> Cheers, > > >>>>>> Rajiv > > >>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: fecframe-proto-bounces@ietf.org > > >>>>>>> [mailto:fecframe-proto-bounces@ietf.org > <mailto:fecframe-proto-bounces@ietf.org> > <mailto:fecframe-proto-bounces@ietf.org> ] On Behalf Of > > Ali Begen > > >>>>>>> (abegen) > > >>>>>>> Sent: Tuesday, February 12, 2008 4:04 PM > > >>>>>>> To: fecframe-proto@ietf.org > > >>>>>>> Subject: [FECFRAME-PROTO] A new informational > draft on > > >>>>> fec grouping > > >>>>>>> issues > > >>>>>>> > > >>>>>>> Hi everyone, > > >>>>>>> > > >>>>>>> So far, we could not ignite a discussion in > the MMUSIC WG > > >>>>> regarding > > >>>>>>> the FEC grouping issues. So, it was suggested that I > > >>>>> would write an > > >>>>>>> informational draft, describe the problems > and propose some > > >>>>>>> alternative solutions. So, that is what I did. > > >>>>>>> > > >>>>>>> I am attaching the draft for your review. > Note that this > > >>>>> has to be > > >>>>>>> submitted by Monday. So any comments within this week > > >>>>>> (before Friday) > > >>>>>>> would be appreciated. It is important that we convey > > our issues > > >>>>>>> appropriately. So, please take a few minutes > to review the > > >>>>>> document. > > >>>>>>> It is very short, and should not take much time. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> -acbegen > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> _______________________________________________ > > >>> FECFRAME-PROTO mailing list > > >>> FECFRAME-PROTO@ietf.org > > >>> > http://www.ietf.org/mailman/listinfo/fecframe-proto > <http://www.ietf.org/mailman/listinfo/fecframe-proto> > <http://www.ietf.org/mailman/listinfo/fecframe-proto> > > >> > > >> > > >> > > > > > > > > > > > > > > > _______________________________________________ FECFRAME-PROTO mailing list FECFRAME-PROTO@ietf.org https://www.ietf.org/mailman/listinfo/fecframe-proto
- [FECFRAME-PROTO] A new informational draft on fec… Ali Begen (abegen)
- Re: [FECFRAME-PROTO] A new informational draft on… Rajiv Asati (rajiva)
- Re: [FECFRAME-PROTO] A new informational draft on… Ali Begen (abegen)
- Re: [FECFRAME-PROTO] A new informational draft on… Rajiv Asati (rajiva)
- Re: [FECFRAME-PROTO] A new informational draft on… Ali Begen (abegen)
- Re: [FECFRAME-PROTO] A new informational draft on… Rajiv Asati (rajiva)
- Re: [FECFRAME-PROTO] A new informational draft on… Mark Watson
- Re: [FECFRAME-PROTO] A new informational draft on… Ali Begen (abegen)
- Re: [FECFRAME-PROTO] A new informational draft on… Mark Watson
- Re: [FECFRAME-PROTO] A new informational draft on… Rajiv Asati (rajiva)
- Re: [FECFRAME-PROTO] A new informational draft on… Rajiv Asati (rajiva)