Re: [FECFRAME-PROTO] A new informational draft on fec grouping issues

"Ali Begen (abegen)" <abegen@cisco.com> Sat, 16 February 2008 04:22 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 91D563A6C09; Fri, 15 Feb 2008 20:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level:
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-2.439, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1]
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 r5bvwAVoEDM1; Fri, 15 Feb 2008 20:22:28 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8767E3A68C2; Fri, 15 Feb 2008 20:22:28 -0800 (PST)
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 BD9F63A6BF6 for <fecframe-proto@core3.amsl.com>; Fri, 15 Feb 2008 20:22:26 -0800 (PST)
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 fdPsDWevfNc1 for <fecframe-proto@core3.amsl.com>; Fri, 15 Feb 2008 20:22:25 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5F0C13A68C2 for <fecframe-proto@ietf.org>; Fri, 15 Feb 2008 20:22:25 -0800 (PST)
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Feb 2008 20:23:45 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1G4Njb4016724; Fri, 15 Feb 2008 20:23:45 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1G4Njw1019879; Sat, 16 Feb 2008 04:23: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); Fri, 15 Feb 2008 20:23:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 15 Feb 2008 20:23:22 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5406895573@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <C3DB890C.240C4%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+IAAgEh8A==
References: <04CAD96D4C5A3D48B1919248A8FE0D540683D31A@xmb-sjc-215.amer.cisco.com> <C3DB890C.240C4%mark@digitalfountain.com>
From: "Ali Begen (abegen)" <abegen@cisco.com>
To: Mark Watson <mark@digitalfountain.com>, "Rajiv Asati (rajiva)" <rajiva@cisco.com>, fecframe-proto@ietf.org
X-OriginalArrivalTime: 16 Feb 2008 04:23:27.0174 (UTC) FILETIME=[AD469660:01C87053]
Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 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: <http://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: <http://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,

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?

> 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.

> 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?

BTW, is not using 'RTP/AVP' acceptable? 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? 

(BTW, the examples are modified from the ones in SDP draft) 

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] 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
> 
> 
> 
_______________________________________________
FECFRAME-PROTO mailing list
FECFRAME-PROTO@ietf.org
http://www.ietf.org/mailman/listinfo/fecframe-proto