Re: [FECFRAME-PROTO] New SDP draft

"Greg Shepherd" <gjshep@gmail.com> Tue, 05 February 2008 23:52 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 ADCE83A67A6; Tue, 5 Feb 2008 15:52:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM+AL-pjVKsp; Tue, 5 Feb 2008 15:52:13 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17173A6780; Tue, 5 Feb 2008 15:52:13 -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 1645F3A67A6 for <fecframe-proto@core3.amsl.com>; Tue, 5 Feb 2008 15:52:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWVGbaroUTB2 for <fecframe-proto@core3.amsl.com>; Tue, 5 Feb 2008 15:52:11 -0800 (PST)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id EEF243A6780 for <fecframe-proto@ietf.org>; Tue, 5 Feb 2008 15:52:10 -0800 (PST)
Received: by an-out-0708.google.com with SMTP id d11so706291and.122 for <fecframe-proto@ietf.org>; Tue, 05 Feb 2008 15:53:43 -0800 (PST)
Received: by 10.100.205.9 with SMTP id c9mr2192269ang.23.1202255623088; Tue, 05 Feb 2008 15:53:43 -0800 (PST)
Received: by 10.100.125.10 with HTTP; Tue, 5 Feb 2008 15:53:43 -0800 (PST)
Message-ID: <38c19b540802051553sd9dd6f5v9eb74e79dfa40e31@mail.gmail.com>
Date: Tue, 05 Feb 2008 15:53:43 -0800
From: Greg Shepherd <gjshep@gmail.com>
To: "Ali Begen (abegen)" <abegen@cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540675610C@xmb-sjc-215.amer.cisco.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <04CAD96D4C5A3D48B1919248A8FE0D5406755D80@xmb-sjc-215.amer.cisco.com> <241bc2150802041404o7ec999a9wb5e0f8336ca0b99d@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540675610C@xmb-sjc-215.amer.cisco.com>
Cc: fecframe-proto@ietf.org
Subject: Re: [FECFRAME-PROTO] New SDP draft
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

Did we ever come to conclusion with mmusic wrt grouping? The
conversation seemed to spin off track discussing uses/application of
groups but away from our original question.

Ali, can you summarize and restate to the mmusic list? ..or did I miss
something?

Thanks,
Greg

On Feb 4, 2008 2:26 PM, Ali Begen (abegen) <abegen@cisco.com> wrote:
>
>
> Hi Ulas.
>
> Thanks for the comments.
>
> 1- We define the priority field in the repair flow descriptor. However, I
> did not want to use it in the examples (not yet) since assigning priority
> means we can use multiple repair flows in an additive manner. And as you
> know, that issue is still at hand. I believe at least for now we should not
> give examples involving additivity and prioritization.
>
> However, different repair sizes are already used in the last example.
>
> 2- Good question. I am not sure whether that should be a part of the FSSI
> (receiver side) or we should specify a new separate element, which is part
> of the configuration information (hence, common to all FEC schemes)? \
>
> I am inclined towards including in the RS-FSSI? But, either is fine with me.
> We decided to make it optional. So, the configuration information may ignore
> or skip it.
>
> Any comments?
>
> -acbegen
>
>
>  ________________________________
>  From: Ulas Kozat [mailto:ulas.kozat@gmail.com]
> Sent: Monday, February 04, 2008 2:05 PM
> To: Ali Begen (abegen)
> Cc: fecframe-proto@ietf.org
> Subject: Re: [FECFRAME-PROTO] New SDP draft
>
>
>
> Ali,
>
> The document looks okay with the notes, etc. I have a few comments:
> 1. Maybe we can add one more example for single source flow and 2 repair
> flows with priority. Also, in such a scenario, should we be able to define 2
> different time windows for each repair flow?
> 2. Are we going to specify a feedback description other than the FEC-scheme
> specific one as part of SDP elements? E.g., is the sender capable of
> receiving any FEC performance feedback or whether the receiver capable of
> sending any feedback?
>
> Ulas
>
>
> On Feb 3, 2008 3:41 AM, Ali Begen (abegen) <abegen@cisco.com> wrote:
>
> > Hi everyone,
> >
> > I made the changes we discussed last week in the SDP draft. I am
> > attaching the txt and xml files.
> >
> > I would like to hear your feedback before I submit it as a WG document.
> > Could you at least go over the new sections and SDP examples?
> >
> > The changes include:
> > - Divided the FEC-scheme-specific-information (FSSI) container into two.
> > Now, we have one container (Sender-side FSSI) which includes the
> > information required only by the sender. The rest of the FSSI info goes
> > to the other container (Receiver-side FSSI). The FEC scheme decides what
> > goes to where.
> >
> > - Media stream grouping: I updated the text based on our last
> > discussion. The discussion is still going on in the MMUSIC and FECFRAME
> > WGs. We need to come up with something that allows us to associate the
> > repair and source flows in a flexible manner. RFC 3388 is severely
> > limiting us.
> >
> > I also added the cases where we would want to use multiple framework
> > instances in Section 4.2.
> >
> > - Repair flow descriptors: I updated this section (4.5) as we now have
> > two containers for FSSI. I also changed the "Scheme ID" to "Encoding ID"
> > to be consistent with the framework draft.
> >
> > - Repair Window: Section 4.6 is re-written. Now, we support both ms and
> > us.
> >
> > - Section 5 is re-written. I added three SDP examples. Please go over
> > the examples and let me know if something is missing or incorrect.
> >
> > 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
>
>
_______________________________________________
FECFRAME-PROTO mailing list
FECFRAME-PROTO@ietf.org
http://www.ietf.org/mailman/listinfo/fecframe-proto