Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05

"Luby, Michael" <luby@qualcomm.com> Thu, 22 April 2010 16:44 UTC

Return-Path: <luby@qualcomm.com>
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 141DF3A6BFE for <fecframe@core3.amsl.com>; Thu, 22 Apr 2010 09:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 W5YC03Fc2Iii for <fecframe@core3.amsl.com>; Thu, 22 Apr 2010 09:44:42 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CC49128C185 for <fecframe@ietf.org>; Thu, 22 Apr 2010 09:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1271954652; x=1303490652; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version; z=From:=20"Luby,=20Michael"=20<luby@qualcomm.com>|To:=20"A li=20C.=20Begen=20(abegen)"=20<abegen@cisco.com>,=20Orly =20Peck=0D=0A=09<orlyp@radvision.com>,=20"fecframe@ietf.o rg"=20<fecframe@ietf.org>|Date:=20Thu,=2022=20Apr=202010 =2009:44:08=20-0700|Subject:=20Re:=20[Fecframe]=20WGLC=20 -=20draft-ietf-fecframe-sdp-elements-05|Thread-Topic:=20[ Fecframe]=20WGLC=20-=20draft-ietf-fecframe-sdp-elements-0 5|Thread-Index:=20Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9 nZhAAAG4EDw=3D=3D|Message-ID:=20<C7F5CAE8.D9ED%luby@qualc omm.com>|In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D54 0BEE6633@xmb-sjc-215.amer.cisco.com>|Accept-Language:=20e n-US|Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C7F5CAE8D9EDlubyqualcommcom_"|MIME-Version:=201 .0; bh=+1uinLJGoV4Fv/wlVywLl3HoAvPban6tcNzXMGI08Fc=; b=mTwNKne8cHagEcJZghyIxrz9uEbkV8BaiEUYdYdb7W4ThXOFBHgHMmQj Fk2jd4vMQUbsZhMyDScVn8y8gld/k3K4CvrseaFn/D/7IGdJEz4rAF9rL 4zQOLiL8+C8UMQf3IClfegl6sbYZH2J3AkLTvdHVA/j9gbrI+LRYMQbYI 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,5960"; a="39375804"
Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 22 Apr 2010 09:44:11 -0700
X-IronPort-AV: E=Sophos; i="4.52,257,1270450800"; d="scan'208,217"; a="14618957"
Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 22 Apr 2010 09:44:11 -0700
Received: from nasanexhc07.na.qualcomm.com (172.30.39.6) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 22 Apr 2010 09:44:11 -0700
Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhc07.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.0.689.0; Thu, 22 Apr 2010 09:44:11 -0700
Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 22 Apr 2010 09:44:11 -0700
From: "Luby, Michael" <luby@qualcomm.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Orly Peck <orlyp@radvision.com>, "fecframe@ietf.org" <fecframe@ietf.org>
Date: Thu, 22 Apr 2010 09:44:08 -0700
Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05
Thread-Index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhAAAG4EDw==
Message-ID: <C7F5CAE8.D9ED%luby@qualcomm.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6633@xmb-sjc-215.amer.cisco.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C7F5CAE8D9EDlubyqualcommcom_"
MIME-Version: 1.0
Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2010 16:44:46 -0000

Repair window from the receiver perspective doesn't seem very well defined in this text.  Is it specified somewhere else in the spec what the repair window is from the receiver perspective, i.e., how does the receiver know when the repair window starts and how does the receiver know the duration of the repair window (is it signaled?).


On 4/22/10 9:33 AM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

Is the WG happy with the text below?

-acbegen

An FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration. At the receiver side, the FEC decoder tries to decode all the packets received within the repair window to recover the missing packets, if there are any. Repair window stands for the time that spans the source packets and the corresponding repair packets. It defines the minimum time which the receiver SHOULD wait for the repair packets.

> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Orly Peck
> Sent: Thursday, April 22, 2010 5:57 AM
> To: fecframe@ietf.org
> Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05
>
> Hi,
> Here are my comments to draft-ietf-fecframe-sdp-elements-05:
>
> 1) section 4.6 - Repair Window - " Assuming that there is no issue of delay variation, the FEC decoder
> SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery
> process."
>
> I think that the assumption that there is no issue of delay variation is irrelevant for most cases.
> I think the Repair Window should be defined (as I mentioned at the last IETF meeting) as the MINIMUM
> time that the receiver should wait for the repair packets, as the sender only knows the time that
> spans between the source packets and the generation of the repair packets.
> This comment was accepted also by Mark Watson for draft-ietf-fecframe-framework-05.
>
> 2) same section - typo: mismatchs = mismatches.
>
> Thanks,
> Orly Peck.
>
>
> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd
> Sent: Wednesday, April 14, 2010 8:08 PM
> To: Ali C. Begen (abegen)
> Cc: fecframe@ietf.org
> Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05
>
> Working Group Last Call for draft-ietf-fecframe-sdp-elements-05
>
> PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have
> no corrections to the document please send to the list your approval
> of the document as is.
>
> And let's do this quickly. Please send comments to the list by
> end-of-day Friday, April 23.
>
> Thanks!,
> Greg
>
> On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
> > This revision simply fixed the boilerplate. No other changes. Could we run the 2nd wglc on this
> draft?
> >
> > Thanks,
> > -acbegen
> >
> > -----Original Message-----
> > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> > Sent: Sunday, April 04, 2010 3:29 PM
> > To: Ali C. Begen (abegen)
> > Subject: New Version Notification for draft-ietf-fecframe-sdp-elements-05
> >
> >
> > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has been successfully submitted by Ali
> Begen and posted to the IETF repository.
> >
> > Filename:        draft-ietf-fecframe-sdp-elements
> > Revision:        05
> > Title:           SDP Elements for FEC Framework
> > Creation_date:   2010-04-04
> > WG ID:           fecframe
> > Number_of_pages: 21
> >
> > Abstract:
> > This document specifies the use of Session Description Protocol (SDP)
> > to describe the parameters required to signal the Forward Error
> > Correction (FEC) Framework Configuration Information between the
> > sender(s) and receiver(s).  This document also provides examples that
> > show the semantics for grouping multiple source and repair flows
> > together for the applications that simultaneously use multiple
> > instances of the FEC Framework.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> > _______________________________________________
> > 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