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