From sunseawq@huawei.com Sun Nov 7 00:11:33 2010 Return-Path: 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 6A5F93A69CE; Sun, 7 Nov 2010 00:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 OFirrkWbGh06; Sun, 7 Nov 2010 00:11:32 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0171C3A6985; Sun, 7 Nov 2010 00:11:32 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBI007RT6NFHU@szxga04-in.huawei.com>; Sun, 07 Nov 2010 15:11:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBI00JYU6NF54@szxga04-in.huawei.com>; Sun, 07 Nov 2010 15:11:39 +0800 (CST) Received: from jys1037603 (dhcp-7617.meeting.ietf.org [130.129.118.23]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBI0086C6N0H4@szxml01-in.huawei.com>; Sun, 07 Nov 2010 15:11:39 +0800 (CST) Date: Sun, 07 Nov 2010 15:11:33 +0800 From: Qin Wu To: avt@ietf.org, fecframe@ietf.org, ietf-http-wg@w3.org, hybi@ietf.org Message-id: <249792B19B4845578D9BDC3F77C12D68@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [Fecframe] Fw: [httpstreaming] Agenda and Slides X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 07:11:33 -0000 FYI. ----- Original Message ----- From: "David A. Bryan" To: "httpstreaming" Sent: Sunday, November 07, 2010 2:37 PM Subject: [httpstreaming] Agenda and Slides >I just uploaded an agenda and the current slides from the > participants. The slides are available as links from the agenda, which > I have uploaded here: > > http://www.p2psip.org/httpstream/79/Agenda.html > > I still don't know which room is the IESG room, but I will find out > and post here shortly. > > Thanks, and see you all on Wed. > > David > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > From sunseawq@huawei.com Sun Nov 7 17:48:56 2010 Return-Path: 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 E2BD028C113; Sun, 7 Nov 2010 17:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 hwRQiR+A8p1O; Sun, 7 Nov 2010 17:48:55 -0800 (PST) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B8E3E28C0E4; Sun, 7 Nov 2010 17:48:55 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBJ0066TM8W05@szxga05-in.huawei.com>; Mon, 08 Nov 2010 09:46:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBJ00BSHM8VI7@szxga05-in.huawei.com>; Mon, 08 Nov 2010 09:46:08 +0800 (CST) Received: from jys1037603 ([125.35.86.138]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBJ00KN2M8THG@szxml01-in.huawei.com>; Mon, 08 Nov 2010 09:46:07 +0800 (CST) Date: Mon, 08 Nov 2010 09:46:15 +0800 From: Qin Wu To: Ben Niven-Jenkins Message-id: <0DF4BC8BAA194FB98C04BAE9424F2129@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <249792B19B4845578D9BDC3F77C12D68@china.huawei.com> <58D167AC-E817-4256-88D0-42E36492C562@niven-jenkins.co.uk> Cc: hybi@ietf.org, avt@ietf.org, fecframe@ietf.org, ietf-http-wg@w3.org Subject: Re: [Fecframe] [AVT] Fw: [httpstreaming] Agenda and Slides X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 01:48:57 -0000 Hi, ----- Original Message ----- From: "Ben Niven-Jenkins" To: "Qin Wu" Cc: ; ; ; Sent: Sunday, November 07, 2010 11:54 PM Subject: Re: [AVT] Fw: [httpstreaming] Agenda and Slides Colleagues, Reading the slides I'd like to make some comments in advance of the bar-bof, we can discuss them more via the mailing list or in the bar-BoF itself. HTTP_Stream_1.ppt Slide 14: " No distinction regular HTTP traffic from HTTP Streaming traffic Disadvantage: Transport streaming media in the same way as web page transport Streaming media has no priority to be delivered/processed first " This is not correct, it is possible to apply different treatment to HTTP Streaming traffic Vs "regular" web page traffic, e.g. by the server setting different TOS/DSCP for streaming Vs "web" traffic. [Qin]: There are two different levels for service differential 1evel 1: How to separate HTTP streaming service from High Speed Internet Service(HSI) Since HTTP streaming service and HSI share the same channel and HTTP Streaming service may require more bandwidth or other resource to support high quality content delivery. If the serve can do some mark in the HTTP header and there is some smart cache with intelligence to understand this mark situated between the server and client, the smart cache can treat HTTP streaming traffic in the different way as web traffic. level2: How to treat different HTTP streaming traffic with different priorities. This is more precise granularity of service differential. If there is way to do this, HD HTTP streaming can be treated in the different way as SD HTTP Streaming. Smart cache is one way to do this. As for these two levels of service differential, I agree there is other ways to deal with it, I just think it is quite interesting issue to me, when I dig this problem out On 7 Nov 2010, at 07:11, Qin Wu wrote: > FYI. > ----- Original Message ----- > From: "David A. Bryan" > To: "httpstreaming" > Sent: Sunday, November 07, 2010 2:37 PM > Subject: [httpstreaming] Agenda and Slides > > >> I just uploaded an agenda and the current slides from the >> participants. The slides are available as links from the agenda, which >> I have uploaded here: >> >> http://www.p2psip.org/httpstream/79/Agenda.html >> >> I still don't know which room is the IESG room, but I will find out >> and post here shortly. >> >> Thanks, and see you all on Wed. >> >> David >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >> > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From gjshep@gmail.com Tue Nov 9 15:26:37 2010 Return-Path: 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 A76D028C0D9 for ; Tue, 9 Nov 2010 15:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 W1C8XRPzKkzE for ; Tue, 9 Nov 2010 15:26:37 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B124128C0D0 for ; Tue, 9 Nov 2010 15:26:36 -0800 (PST) Received: by bwz12 with SMTP id 12so55468bwz.31 for ; Tue, 09 Nov 2010 15:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=BswNI0xi70EjwZay2f7hgaO5ODYSH2suXXcaHd78EbU=; b=AhIIyjKblgTY6qy7491aAiqvKI+hCLgL2jeRLbh2rhXZoQjNaakAkdFTCV0V/cyeu1 eToQw6gAU3kJadk7iZHesqJSgpuXQnJRM2iIQVpeRGXdNA6y8d2LYXZRwqY5+5pHpFpE Kfu6nlAN9vlb8uZoJGbkCd/oYZ3Hn9xOiNfxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=lfO3qktGRChz0foT8SpqF/sXNVDIWWPqQDe/1/vxHkhv4fTSUip3iR7s/V+c49EqpW 7G99znCwsHvhSv6MIX5560p2cy8RLB8LGeNjp8P3vpj4WWxyAbstTiRDUwuDrYVKnD7u 3eKAw2uGKUAAXDjMZp7pMzxrnK0gp5mwxcmI4= MIME-Version: 1.0 Received: by 10.204.97.143 with SMTP id l15mr7171415bkn.127.1289345220482; Tue, 09 Nov 2010 15:27:00 -0800 (PST) Received: by 10.204.112.71 with HTTP; Tue, 9 Nov 2010 15:27:00 -0800 (PST) Date: Tue, 9 Nov 2010 15:27:00 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WG Meeting Materials X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 23:26:37 -0000 Please send your .ppts for the WG meeting to Ali and I ASAP. These should be posted before the meeting and not handed over on a mem stick after the meeting starts, thanks. :) Greg From Internet-Drafts@ietf.org Sun Nov 21 12:00:04 2010 Return-Path: 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 F36F73A69F9; Sun, 21 Nov 2010 12:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, 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 j10kCZXl1DSY; Sun, 21 Nov 2010 12:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883283A69F5; Sun, 21 Nov 2010 12:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101121200001.22973.65725.idtracker@localhost> Date: Sun, 21 Nov 2010 12:00:01 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-framework-11.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2010 20:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Forward Error Correction (FEC) Framework Author(s) : M. Watson, A. Begen Filename : draft-ietf-fecframe-framework-11.txt Pages : 38 Date : 2010-11-21 This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-framework-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-framework-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-21115944.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Nov 22 23:30:03 2010 Return-Path: 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 3835B28C0E6; Mon, 22 Nov 2010 23:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, 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 uU2G+MhlSCZp; Mon, 22 Nov 2010 23:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49AE428C168; Mon, 22 Nov 2010 23:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101123073002.17186.86542.idtracker@localhost> Date: Mon, 22 Nov 2010 23:30:02 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-raptor-03.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 07:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Raptor FEC Schemes for FECFRAME Author(s) : M. Watson, T. Stockhammer Filename : draft-ietf-fecframe-raptor-03.txt Pages : 21 Date : 2010-11-22 This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-raptor-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-22232148.I-D@ietf.org> --NextPart-- From stockhammer@nomor.de Mon Nov 22 23:32:33 2010 Return-Path: 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 ED2BA28C1AC for ; Mon, 22 Nov 2010 23:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 pkTLnsX0I1bb for ; Mon, 22 Nov 2010 23:32:31 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id CE33B28C1A4 for ; Mon, 22 Nov 2010 23:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1290497606; l=10281; s=domk; d=nomor.de; h=Mime-Version:To:References:Date:Subject:Content-Type:From: X-RZG-CLASS-ID:X-RZG-AUTH; bh=D98f8YyroYA/7qzrSwIN30QC8Ng=; b=fv1dYaEhKmYrzI7AEGzYUbRnzD0dI5f/NdYkfZ06PwcnImaqgfWOTrqR34YTVJs6EF5 wUFm6TF0OYbH6plXCfmhUpShi628xKxEvqqf2VVQ5wpmVVJzK9GXbrdVoYI3K3kl0BV57 hI1B7NLuNG55qOyMBok8reYK6sWlNc8Wv4o= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu18+1EZfOQVAS4z6gUSvLg= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.163] (business-213-023-252-114.static.arcor-ip.net [213.23.252.114]) by post.strato.de (fruni mo19) (RZmta 24.6) with ESMTP id C012femAN4JITd for ; Tue, 23 Nov 2010 08:33:26 +0100 (MET) From: Thomas Stockhammer Content-Type: multipart/alternative; boundary=Apple-Mail-139-805276952 Date: Tue, 23 Nov 2010 08:33:25 +0100 References: <20101123072148.DB34428C1A6@core3.amsl.com> To: fecframe@ietf.org Message-Id: <444DD58D-6C4D-4575-8F91-093F352DBB11@nomor.de> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Fecframe] Fwd: New Version Notification for draft-ietf-fecframe-raptor-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 07:32:33 -0000 --Apple-Mail-139-805276952 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Experts, we have reactivated draft-ietf-fecframe-raptor-03. Highlights of the = changes compared to -02 - Update of authors - Alignment with draft-ietf-rmt-bb-fec-raptorq-04 - Some minor editorial updates - Updates of references Comments from the list had already been integrated in -02. I think it is time to get this out of the queue. Best regards Thomas Begin forwarded message: > From: IETF I-D Submission Tool > Date: November 23, 2010 8:21:48 AM GMT+01:00 > To: stockhammer@nomor.de > Cc: watsonm@netflix.com > Subject: New Version Notification for draft-ietf-fecframe-raptor-03=20 >=20 >=20 > A new version of I-D, draft-ietf-fecframe-raptor-03.txt has been = successfully submitted by Thomas Stockhammer and posted to the IETF = repository. >=20 > Filename: draft-ietf-fecframe-raptor > Revision: 03 > Title: Raptor FEC Schemes for FECFRAME > Creation_date: 2010-11-23 > WG ID: fecframe > Number_of_pages: 21 >=20 > Abstract: > This document describes Fully-Specified Forward Error Correction > (FEC) Schemes for the Raptor and RaptorQ codes and their application > to reliable delivery of media streams in the context of FEC > Framework. The Raptor and RaptorQ codes are systematic codes, where > a number of repair symbols are generated from a set of source symbols > and sent in one or more repair flows in addition to the source > symbols that are sent to the receiver(s) within a source flow. The > Raptor and RaptorQ codes offer close to optimal protection against > arbitrary packet losses at a low computational complexity. Six FEC > Schemes are defined, two for protection of arbitrary packet flows, > two that are optimised for small source blocks and another two for > protection of a single flow that already contains a sequence number. > Repair data may be sent over arbitrary datagram transport (e.g. UDP) > or using RTP. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. --Apple-Mail-139-805276952 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: IETF I-D Submission = Tool <idsubmission@ietf.org>
Date: November 23, 2010 8:21:48 AM = GMT+01:00
To: stockhammer@nomor.de
Cc: watsonm@netflix.com
Subject: New Version = Notification for draft-ietf-fecframe-raptor-03 =


A new version of I-D, = draft-ietf-fecframe-raptor-03.txt has been successfully submitted by = Thomas Stockhammer and posted to the IETF = repository.

Filename: = draft-ietf-fecframe-raptor
Revision: 03
Title: Raptor = FEC Schemes for FECFRAME
Creation_date: 2010-11-23
WG ID: = fecframe
Number_of_pages: 21

Abstract:
This document = describes Fully-Specified Forward Error Correction
(FEC) Schemes for = the Raptor and RaptorQ codes and their application
to reliable = delivery of media streams in the context of FEC
Framework.  The = Raptor and RaptorQ codes are systematic codes, where
a number of = repair symbols are generated from a set of source symbols
and sent in = one or more repair flows in addition to the source
symbols that are = sent to the receiver(s) within a source flow.  The
Raptor and = RaptorQ codes offer close to optimal protection against
arbitrary = packet losses at a low computational complexity.  Six = FEC
Schemes are defined, two for protection of arbitrary packet = flows,
two that are optimised for small source blocks and another two = for
protection of a single flow that already contains a sequence = number.
Repair data may be sent over arbitrary datagram transport = (e.g.  UDP)
or using RTP.



The IETF = Secretariat.



stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.



= --Apple-Mail-139-805276952-- From gjshep@gmail.com Tue Nov 23 07:42:20 2010 Return-Path: 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 C6A3328C1A8 for ; Tue, 23 Nov 2010 07:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, 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 kCqQt-rF0HV3 for ; Tue, 23 Nov 2010 07:42:19 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9946328C1B4 for ; Tue, 23 Nov 2010 07:32:31 -0800 (PST) Received: by fxm9 with SMTP id 9so8692fxm.31 for ; Tue, 23 Nov 2010 07:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=KS/ppAmloanXDgfuf9A6OgGDtID8PkmgXC6OyglRWCQ=; b=IwUxXnsXEtZIeqXFlc0xGtEDLr3xsABsQr2K3qFh9VXa5UjBcvNW2xJFru4uy+6IaV J/C2zA3u9KQcwqj2F0mQZkkcPE3wzPmVnirPBGBl3vBJH4gdLbZBxChPYkPLkKWhIWg3 a+Ff1WkLNsOxqRRwLVKcIihEiV3wz/tMEY8sI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=XX76gYLaKqqAo6+QuNDG3hm5UUq3I1Ogy7Z8QKs1bmBfjcJ/dzZbhEbx7GY+T0PiAJ mp5hXktGhiW+oSfoe9pAuYmcKW50xcqB9Ey2V8Dw+P94HRVc8kiDb3UacozoVEzHM77L k9GdXUB+xUAtwRMeaOU/2HGy9y7g/V/U1cMso= MIME-Version: 1.0 Received: by 10.223.107.66 with SMTP id a2mr495698fap.92.1290526405662; Tue, 23 Nov 2010 07:33:25 -0800 (PST) Received: by 10.223.103.135 with HTTP; Tue, 23 Nov 2010 07:33:25 -0800 (PST) In-Reply-To: <444DD58D-6C4D-4575-8F91-093F352DBB11@nomor.de> References: <20101123072148.DB34428C1A6@core3.amsl.com> <444DD58D-6C4D-4575-8F91-093F352DBB11@nomor.de> Date: Tue, 23 Nov 2010 07:33:25 -0800 Message-ID: From: Greg Shepherd To: Thomas Stockhammer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] Fwd: New Version Notification for draft-ietf-fecframe-raptor-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 15:42:20 -0000 Thanks Thomas! Let's move this along quickly. Consider this WGLC. Please post all feedback to the list by the end of next week, Fri, Dec 3rd. Cheers, Greg On Mon, Nov 22, 2010 at 11:33 PM, Thomas Stockhammer wrote: > Experts, > we have reactivated=A0draft-ietf-fecframe-raptor-03. Highlights of the ch= anges > compared to -02 > - Update of authors > - Alignment with=A0draft-ietf-rmt-bb-fec-raptorq-04 > - Some minor editorial updates > - Updates of references > Comments from the list had already been integrated in -02. > I think it is time to get this out of the queue. > Best regards > Thomas > Begin forwarded message: > > From: IETF I-D Submission Tool > Date: November 23, 2010 8:21:48 AM GMT+01:00 > To: stockhammer@nomor.de > Cc: watsonm@netflix.com > Subject: New Version Notification for draft-ietf-fecframe-raptor-03 > > > A new version of I-D, draft-ietf-fecframe-raptor-03.txt has been > successfully submitted by Thomas Stockhammer and posted to the IETF > repository. > > Filename: draft-ietf-fecframe-raptor > Revision: 03 > Title: Raptor FEC Schemes for FECFRAME > Creation_date: 2010-11-23 > WG ID: fecframe > Number_of_pages: 21 > > Abstract: > This document describes Fully-Specified Forward Error Correction > (FEC) Schemes for the Raptor and RaptorQ codes and their application > to reliable delivery of media streams in the context of FEC > Framework. =A0The Raptor and RaptorQ codes are systematic codes, where > a number of repair symbols are generated from a set of source symbols > and sent in one or more repair flows in addition to the source > symbols that are sent to the receiver(s) within a source flow. =A0The > Raptor and RaptorQ codes offer close to optimal protection against > arbitrary packet losses at a low computational complexity. =A0Six FEC > Schemes are defined, two for protection of arbitrary packet flows, > two that are optimised for small source blocks and another two for > protection of a single flow that already contains a sequence number. > Repair data may be sent over arbitrary datagram transport (e.g. =A0UDP) > or using RTP. > > > > The IETF Secretariat. > > > > --- > Dr. Thomas Stockhammer (CEO) ||=A0stockhammer@nomor.de=A0|| phone +49 89 = 978980 > 02 || cell +491725702667 || http://www.nomor-research.com > Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Registerge= richt: > M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FCh= rer: Dr. > Thomas Stockhammer, Dr. Ingo Viering. > > > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > From luby@qualcomm.com Tue Nov 23 11:09:04 2010 Return-Path: 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 68C7A28C120 for ; Tue, 23 Nov 2010 11:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 ulaGPdM1B5GV for ; Tue, 23 Nov 2010 11:09:01 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 9D5523A69AB for ; Tue, 23 Nov 2010 11:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1290539399; x=1322075399; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"f ecframe@ietf.org"=20|CC:=20"Luby,=20Mi chael"=20|Date:=20Tue,=2023=20Nov=2020 10=2011:09:56=20-0800|Subject:=20Comments=20on:=20I-D=20A ction:draft-ietf-fecframe-raptor-03.txt|Thread-Topic:=20C omments=20on:=20I-D=20Action:draft-ietf-fecframe-raptor-0 3.txt|Thread-Index:=20AcuK4IDKONvlK10zRtSF8XrA5IhRzQAYYMi o|Message-ID:=20 |In-Reply-To:=20<20101123073002.17186.86542.idtracker@loc alhost>|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mi crosoft-Entourage/13.7.0.100913|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=gqfs5S7tDyh4snEUnwFP/hLNT4YqLM8mv+ICu18QMns=; b=nMHfYUTXG60bNMzmwsthAqJUzd0LLmVUIE8ctCDDxHvcfKTPyZPdWUT2 jlu9i+Il6q+4G61mMWS+IkCR7o88vPpURo+A4QJc7i40sHVK46QVzit44 OXphkUrOgAJ5huRX7U6uz7/0BcL+4l5EXtjFmlMNEz36a8QNfur04RN+T 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6176"; a="63860750" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 23 Nov 2010 11:09:59 -0800 X-IronPort-AV: E=Sophos;i="4.59,242,1288594800"; d="scan'208";a="31757006" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 23 Nov 2010 11:09:59 -0800 Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 23 Nov 2010 11:09:59 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 23 Nov 2010 11:09:58 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Tue, 23 Nov 2010 11:09:53 -0800 From: "Luby, Michael" To: "fecframe@ietf.org" Date: Tue, 23 Nov 2010 11:09:56 -0800 Thread-Topic: Comments on: I-D Action:draft-ietf-fecframe-raptor-03.txt Thread-Index: AcuK4IDKONvlK10zRtSF8XrA5IhRzQAYYMio Message-ID: In-Reply-To: <20101123073002.17186.86542.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Fecframe] Comments on: I-D Action:draft-ietf-fecframe-raptor-03.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:09:04 -0000 Some comments on draft-ietf-fecframe-raptor-03.txt below. General nits: (1) Change "signalled" to "signaled" (2) Change "modelled" to "modeled" (3) Change "arbitary" to "arbitrary" (4) Change "thepadding" to "the padding" (5) Change "handware" to "hardware" Particulars: (6) Section 6.3.2 refers to Section 6.4 for the definition of I_repair: it vaguely says that The ESI value placed into a repair packet is given by the following formula: "ESI_repair =3D I_repair + SBL, where I_repair is the index of the repair symbol in the sequence of repair symbols generated according to Section 6.4, where the first repair symbol has index 0, the second index 1 etc. and SBL is the Source Block Length." If you look at Section 6.4, it just says that you shall use the Raptor in IETF RFC 5053 or the RaptorQ in the draft specification. But, if you look into either Raptor or RaptorQ, you will see that the indexing of the repair symbols starts at K, where K is the SBL, and thus you need to reinterpret t= o understand the ESI K in the Raptor or RaptorQ specification corresponds to I_repair =3D 0, and then use this in the above, which gives you back exactl= y the same ESI as would have been specified by Raptor or RaptorQ. This whole thing is overly confusing, and I think it would be better to just replace the above with: "The ESI value placed into a repair packet is calculated as specified in Section 5.3.2 of [RFC5053] when [RFC5053] is used and as specified in Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] when [I-D.ietf-rmt-bb-fec-raptorq] is used, where K=3DSBL." (7) Section 7.1, the second bullet point here is pretty confusing. Suggest changing it from: "A restricted set of possible source block sizes is specified. This allows explicit operation sequences for encoding the restricted set of block sizes to be pre-calculated and embedded in software or handware." To: "The possible choices of the source block size for a stream is restricted t= o a small specified set of sizes. This allows explicit operation sequences for encoding and decoding the restricted set of source block sizes to be pre-calculated and embedded in software or hardware." (8) Section 7.3.2, similar comment to (6) above. Suggest rewording: "The ESI value placed into a repair packet is given by the following formula: ESI_repair =3D I_repair + MSBL Where I_repair is the index of the repair symbol in the sequence of repair symbols generated according to Section 6.4, where the first repair symbol has index 0, the second index 1 etc. and MSBL is the Maximum Source Block Length signalled in the FEC Scheme Specific Information. The Source Block Length field of the Repair FEC Payload ID field SHALL be set to the number of symbols included in the Source Packet Information of packets associated with the source block." To: "The ESI value placed into a repair packet is calculated as X + MSBL - SBL, where X would be the ESI value of the repair packet if the ESI were calculated as specified in Section 5.3.2 of [RFC5053] when [RFC5053] is use= d and as specified in Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] when [I-D.ietf-rmt-bb-fec-raptorq] is used, where K=3DSBL. The value of SBL SHAL= L be at most the value of MSBL." (9) Section 8.1.3: The text for the second set of formats is a copy of the first set and should be changed. Specifically, The ESI in the second set o= f formats should be specified as 24 bits, not 16 bits, and the ESI text shoul= d be listed third, not second (to match the order of the parameters in Fig. 7). Mike=20 =20 =20 On 11/22/10 11:30 PM, "Internet-Drafts@ietf.org" wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the FEC Framework Working Group of the IETF. >=20 >=20 > Title : Raptor FEC Schemes for FECFRAME > Author(s) : M. Watson, T. Stockhammer > Filename : draft-ietf-fecframe-raptor-03.txt > Pages : 21 > Date : 2010-11-22 >=20 > This document describes Fully-Specified Forward Error Correction > (FEC) Schemes for the Raptor and RaptorQ codes and their application > to reliable delivery of media streams in the context of FEC > Framework. The Raptor and RaptorQ codes are systematic codes, where > a number of repair symbols are generated from a set of source symbols > and sent in one or more repair flows in addition to the source > symbols that are sent to the receiver(s) within a source flow. The > Raptor and RaptorQ codes offer close to optimal protection against > arbitrary packet losses at a low computational complexity. Six FEC > Schemes are defined, two for protection of arbitrary packet flows, > two that are optimised for small source blocks and another two for > protection of a single flow that already contains a sequence number. > Repair data may be sent over arbitrary datagram transport (e.g. UDP) > or using RTP. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From abegen@cisco.com Wed Nov 24 07:38:01 2010 Return-Path: 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 D79DF28C231 for ; Wed, 24 Nov 2010 07:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.739 X-Spam-Level: X-Spam-Status: No, score=-9.739 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] 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 jvqfMbavq52W for ; Wed, 24 Nov 2010 07:38:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A2D4028C0E1 for ; Wed, 24 Nov 2010 07:38:00 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArADAGPA7EyrRN+K/2dsb2JhbACUN45FcaM2mzmFRwSEW4ka X-IronPort-AV: E=Sophos;i="4.59,248,1288569600"; d="scan'208";a="222809951" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 24 Nov 2010 15:39:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oAOFd0Hp023034; Wed, 24 Nov 2010 15:39:00 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.4675); Wed, 24 Nov 2010 07:39:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Nov 2010 07:38:54 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DBBA865@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on: I-D Action:draft-ietf-fecframe-raptor-03.txt Thread-Index: AcuK4IDKONvlK10zRtSF8XrA5IhRzQAYYMioACpnX9A= From: "Ali C. Begen (abegen)" To: "Luby, Michael" , X-OriginalArrivalTime: 24 Nov 2010 15:39:00.0261 (UTC) FILETIME=[B6EBD550:01CB8BED] Subject: Re: [Fecframe] Comments on: I-D Action:draft-ietf-fecframe-raptor-03.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 15:38:02 -0000 In addition, please use proper capitalization for the frequently used = terms like "Repair packet", "Payload ID", etc. Also you might wanna remove the definitions and acronyms from your = draft, and simply refer to: https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ to stay consistent (there is still a slight change the text could be = modified in the framework draft). Or, please make sure that the text = will be updated before the RFC publication. In the SDP example, there are some typos. I am only copying the lines = that need to be fixed: a=3Dgroup:FEC-FR S1 R1 (Update the a=3Dgroup line in the second = paragraph of section 10 as well) ... m=3Dapplication 30000 UDP/FEC ... a=3Dfec-repair-flow: encoding-id=3D0; fssi=3DKmax:8192,T:128,P:A a=3Drepair-window:200ms In the repair-flow line, you are using 0 for the encoding-id. But, that = is now what is registered for a particular FEC scheme you are defining = here. 0 is special and should probably be reserved (I will put that note = in the next framework revision). Actually, in Section 12.1, instead of saying XXX, you should put numbers = starting from 1. So that IANA knows what to register. Once you do that, = update the repair-flow line in the SDP to reflect the proper fec scheme = for your example. Update the reference 4756bis to RFC 5956. You are missing the informative references section. From what I can = tell, there are a few references that are informative - not normative. = You should fix this. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Luby, Michael > Sent: Tuesday, November 23, 2010 2:10 PM > To: fecframe@ietf.org > Subject: [Fecframe] Comments on: I-D = Action:draft-ietf-fecframe-raptor-03.txt >=20 > Some comments on draft-ietf-fecframe-raptor-03.txt below. >=20 > General nits: >=20 > (1) Change "signalled" to "signaled" > (2) Change "modelled" to "modeled" > (3) Change "arbitary" to "arbitrary" > (4) Change "thepadding" to "the padding" > (5) Change "handware" to "hardware" >=20 > Particulars: >=20 > (6) Section 6.3.2 refers to Section 6.4 for the definition of = I_repair: it > vaguely says that >=20 > The ESI value placed into a repair > packet is given by the following formula: >=20 > "ESI_repair =3D I_repair + SBL, >=20 > where I_repair is the index of the repair symbol in the sequence of > repair symbols generated according to Section 6.4, where the first > repair symbol has index 0, the second index 1 etc. and SBL is the > Source Block Length." >=20 > If you look at Section 6.4, it just says that you shall use the Raptor = in > IETF RFC 5053 or the RaptorQ in the draft specification. But, if you = look > into either Raptor or RaptorQ, you will see that the indexing of the = repair > symbols starts at K, where K is the SBL, and thus you need to = reinterpret to > understand the ESI K in the Raptor or RaptorQ specification = corresponds to > I_repair =3D 0, and then use this in the above, which gives you back = exactly > the same ESI as would have been specified by Raptor or RaptorQ. This = whole > thing is overly confusing, and I think it would be better to just = replace > the above with: >=20 > "The ESI value placed into a repair packet is calculated as specified = in > Section 5.3.2 of [RFC5053] when [RFC5053] is used and as specified in > Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] when > [I-D.ietf-rmt-bb-fec-raptorq] is used, where K=3DSBL." >=20 >=20 > (7) Section 7.1, the second bullet point here is pretty confusing. = Suggest > changing it from: >=20 > "A restricted set of possible source block sizes is specified. > This allows explicit operation sequences for encoding the > restricted set of block sizes to be pre-calculated and embedded = in > software or handware." >=20 > To: > "The possible choices of the source block size for a stream is = restricted to > a small specified set of sizes. This allows explicit operation = sequences > for encoding and decoding the restricted set of source block sizes to = be > pre-calculated and embedded in software or hardware." >=20 >=20 > (8) Section 7.3.2, similar comment to (6) above. Suggest rewording: >=20 > "The ESI value placed into a repair > packet is given by the following formula: >=20 > ESI_repair =3D I_repair + MSBL >=20 > Where I_repair is the index of the repair symbol in the sequence of > repair symbols generated according to Section 6.4, where the first > repair symbol has index 0, the second index 1 etc. and MSBL is the > Maximum Source Block Length signalled in the FEC Scheme Specific > Information. The Source Block Length field of the Repair FEC = Payload > ID field SHALL be set to the number of symbols included in the = Source > Packet Information of packets associated with the source block." >=20 > To: >=20 > "The ESI value placed into a repair packet is calculated as X + MSBL - = SBL, > where X would be the ESI value of the repair packet if the ESI were > calculated as specified in Section 5.3.2 of [RFC5053] when [RFC5053] = is used > and as specified in Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] = when > [I-D.ietf-rmt-bb-fec-raptorq] is used, where K=3DSBL. The value of SBL = SHALL > be at most the value of MSBL." >=20 > (9) Section 8.1.3: The text for the second set of formats is a copy = of the > first set and should be changed. Specifically, The ESI in the second = set of > formats should be specified as 24 bits, not 16 bits, and the ESI text = should > be listed third, not second (to match the order of the parameters in = Fig. > 7). >=20 > Mike >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 11/22/10 11:30 PM, "Internet-Drafts@ietf.org" = > wrote: >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the FEC Framework Working Group of the = IETF. > > > > > > Title : Raptor FEC Schemes for FECFRAME > > Author(s) : M. Watson, T. Stockhammer > > Filename : draft-ietf-fecframe-raptor-03.txt > > Pages : 21 > > Date : 2010-11-22 > > > > This document describes Fully-Specified Forward Error Correction > > (FEC) Schemes for the Raptor and RaptorQ codes and their application > > to reliable delivery of media streams in the context of FEC > > Framework. The Raptor and RaptorQ codes are systematic codes, where > > a number of repair symbols are generated from a set of source = symbols > > and sent in one or more repair flows in addition to the source > > symbols that are sent to the receiver(s) within a source flow. The > > Raptor and RaptorQ codes offer close to optimal protection against > > arbitrary packet losses at a low computational complexity. Six FEC > > Schemes are defined, two for protection of arbitrary packet flows, > > two that are optimised for small source blocks and another two for > > protection of a single flow that already contains a sequence number. > > Repair data may be sent over arbitrary datagram transport (e.g. = UDP) > > or using RTP. > > > > A URL for this Internet-Draft is: > > = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From ietfdbh@comcast.net Wed Nov 24 09:59:42 2010 Return-Path: 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 271E83A68E0 for ; Wed, 24 Nov 2010 09:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qtfJTlOgpUGD for ; Wed, 24 Nov 2010 09:59:40 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id D53B53A6991 for ; Wed, 24 Nov 2010 09:59:40 -0800 (PST) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta11.emeryville.ca.mail.comcast.net with comcast id b1pQ1f0051afHeLAB60hmA; Wed, 24 Nov 2010 18:00:41 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta17.emeryville.ca.mail.comcast.net with comcast id b60e1f00E2JQnJT8d60ft6; Wed, 24 Nov 2010 18:00:40 +0000 From: "David Harrington" To: "'Thomas Stockhammer'" , References: <20101123072148.DB34428C1A6@core3.amsl.com> <444DD58D-6C4D-4575-8F91-093F352DBB11@nomor.de> Date: Wed, 24 Nov 2010 13:00:29 -0500 Message-ID: <1A4FC6EDB8C14D15A121CCD3C7358E34@23FX1C1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07DF_01CB8BD7.92FCC660" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 In-Reply-To: <444DD58D-6C4D-4575-8F91-093F352DBB11@nomor.de> Thread-index: AcuK4LvnPh9Vku7BRVmN1NcaHF+T0gBIFQSA Subject: Re: [Fecframe] Fwd: New Version Notification fordraft-ietf-fecframe-raptor-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 17:59:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_07DF_01CB8BD7.92FCC660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, =20 I see you aligned with bb-fec-raptor. This implies it is also aligned with fecframe-framework. Please explicitly check that the doc is consistent with the framework doc. =20 David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell)=20 _____ =20 From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Thomas Stockhammer Sent: Tuesday, November 23, 2010 2:33 AM To: fecframe@ietf.org Subject: [Fecframe] Fwd: New Version Notification fordraft-ietf-fecframe-raptor-03 Experts,=20 we have reactivated draft-ietf-fecframe-raptor-03. Highlights of the changes compared to -02 - Update of authors - Alignment with draft-ietf-rmt-bb-fec-raptorq-04 - Some minor editorial updates - Updates of references Comments from the list had already been integrated in -02. I think it is time to get this out of the queue. Best regards Thomas Begin forwarded message: From: IETF I-D Submission Tool Date: November 23, 2010 8:21:48 AM GMT+01:00 To: stockhammer@nomor.de Cc: watsonm@netflix.com Subject: New Version Notification for draft-ietf-fecframe-raptor-03=20 A new version of I-D, draft-ietf-fecframe-raptor-03.txt has been successfully submitted by Thomas Stockhammer and posted to the IETF repository. Filename: draft-ietf-fecframe-raptor Revision: 03 Title: Raptor FEC Schemes for FECFRAME Creation_date: 2010-11-23 WG ID: fecframe Number_of_pages: 21 Abstract: This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. The IETF Secretariat. --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. ------=_NextPart_000_07DF_01CB8BD7.92FCC660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Thomas,
 
I see you aligned with = bb-fec-raptor.
This implies it is also aligned with=20 fecframe-framework.
Please explicitly check that the doc is = consistent with=20 the framework doc.
 
David=20 Harrington
Director, IETF Transport Area
ietfdbh@comcast.net = (preferred=20 for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 = (cell)=20

From: fecframe-bounces@ietf.org=20 [mailto:fecframe-bounces@ietf.org] On Behalf Of Thomas=20 Stockhammer
Sent: Tuesday, November 23, 2010 2:33 = AM
To:=20 fecframe@ietf.org
Subject: [Fecframe] Fwd: New Version = Notification=20 fordraft-ietf-fecframe-raptor-03

Experts,

we have reactivated draft-ietf-fecframe-raptor-03. = Highlights of the=20 changes compared to -02
- Update of authors
- Alignment with draft-ietf-rmt-bb-fec-raptorq-04
- Some minor editorial updates
- Updates of references

Comments from the list had already been integrated in -02.

I think it is time to get this out of the queue.

Best regards

Thomas

Begin forwarded message:

From:=20 IETF=20 I-D Submission Tool <idsubmission@ietf.org>
Date:=20 November 23, = 2010=20 8:21:48 AM GMT+01:00
To: = stockhammer@nomor.de
<= /DIV>
Cc: = watsonm@netflix.com
Subject:=20 New=20 Version Notification for draft-ietf-fecframe-raptor-03=20


A new version of I-D, draft-ietf-fecframe-raptor-03.txt has = been=20 successfully submitted by Thomas Stockhammer and posted to the IETF=20 repository.

Filename: = draft-ietf-fecframe-raptor
Revision: = 03
Title: Raptor FEC = Schemes for=20 FECFRAME
Creation_date: 2010-11-23
WG ID: fecframe
Number_of_pages:=20 21

Abstract:
This document describes Fully-Specified = Forward Error=20 Correction
(FEC) Schemes for the Raptor and RaptorQ codes and = their=20 application
to reliable delivery of media streams in the context = of=20 FEC
Framework.  The Raptor and RaptorQ codes are systematic = codes,=20 where
a number of repair symbols are generated from a set of = source=20 symbols
and sent in one or more repair flows in addition to the=20 source
symbols that are sent to the receiver(s) within a source = flow.=20  The
Raptor and RaptorQ codes offer close to optimal = protection=20 against
arbitrary packet losses at a low computational = complexity.=20  Six FEC
Schemes are defined, two for protection of = arbitrary packet=20 flows,
two that are optimised for small source blocks and another = two=20 for
protection of a single flow that already contains a sequence=20 number.
Repair data may be sent over arbitrary datagram transport = (e.g.=20  UDP)
or using RTP.



The IETF=20 Secretariat.



---
Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || = phone +49=20 89 978980 02 || cell +491725702667 || http://www.nomor-research.com<= /DIV>
Nomor = Research GmbH=20  -  Sitz der Gesellschaft: M=FCnchen - Registergericht: = M=FCnchen, HRB=20 165856 =96 Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. = Thomas=20 Stockhammer, Dr. Ingo Viering.




------=_NextPart_000_07DF_01CB8BD7.92FCC660-- From Internet-Drafts@ietf.org Thu Nov 25 11:30:03 2010 Return-Path: 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 0D27D28C0E6; Thu, 25 Nov 2010 11:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, 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 IUQ91p4LxJGs; Thu, 25 Nov 2010 11:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31633A6A82; Thu, 25 Nov 2010 11:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101125193001.16083.70034.idtracker@localhost> Date: Thu, 25 Nov 2010 11:30:01 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 19:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : RTP Payload Format for Raptor FEC Author(s) : M. Watson, T. Stockhammer Filename : draft-ietf-fecframe-rtp-raptor-04.txt Pages : 25 Date : 2010-11-25 This document specifies an RTP payload format for Forward Error Correction /(FEC) repair data produced by the Raptor FEC schemes. Raptor FEC schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the payload format which is required for the use of RTP to carry Raptor repair flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-rtp-raptor-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-25112915.I-D@ietf.org> --NextPart-- From stockhammer@nomor.de Thu Nov 25 11:44:43 2010 Return-Path: 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 D2A1A28C0CE for ; Thu, 25 Nov 2010 11:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] 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 OqG4GGhqqJx5 for ; Thu, 25 Nov 2010 11:44:42 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by core3.amsl.com (Postfix) with ESMTP id 387F928C169 for ; Thu, 25 Nov 2010 11:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1290714342; l=12041; s=domk; d=nomor.de; h=Mime-Version:To:References:Date:Subject:Content-Type:From: X-RZG-CLASS-ID:X-RZG-AUTH; bh=7ZpX4IMvmw2X5sunrA3TT5KMLTc=; b=Ey5uWq/oXsQ+EIUae0t8O2zH/kqKNaGaIvtnnTHqa/RK1zOGrF9Onzp4JSRcQXBE0aK oiYv+3AXLO3BHTaR1TDJwFyKbmVx9uBl2QQSeFf2ow4xc1xT+QjXraNzGbJ6af+9IGneu dpRxi7UYpLYG63Fc6cZipTmUVQa3nT1fmfc= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [10.0.1.4] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (fruni mo47) (RZmta 24.6) with ESMTP id K002d3mAPHH0uM for ; Thu, 25 Nov 2010 20:45:41 +0100 (MET) From: Thomas Stockhammer Content-Type: multipart/alternative; boundary=Apple-Mail-71-1022011487 Date: Thu, 25 Nov 2010 20:45:40 +0100 References: <20101125193001.16083.70034.idtracker@localhost> To: fecframe@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Fecframe] Fwd: I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 19:44:43 -0000 --Apple-Mail-71-1022011487 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Experts, we also have reactivated draft-ietf-fecframe-rtp-raptor-04. Highlights = of the changes compared to -03 - Update of authors - Alignment with draft-ietf-rmt-bb-fec-raptorq-04 - Alignment with draft-ietf-fecframe-raptor-03 - Alignment with draft-ietf-fecframe-11 - Some minor editorial updates - Updates of references - A significant amount of comments from Ali are integrated in the = revised version. Non-implemented comments were resolved offline with Ali - Some small comments from Mike Luby on terminology are integrated. Thanks to Ali and Mike. I think it is time to get this out of the queue.=20 The document should also be forwarded to AVT once we have a stable = version. Thanks and Best regards and Happy Thanksgivings ... Thomas Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: November 25, 2010 8:30:01 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: fecframe@ietf.org > Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the FEC Framework Working Group of the = IETF. >=20 >=20 > Title : RTP Payload Format for Raptor FEC > Author(s) : M. Watson, T. Stockhammer > Filename : draft-ietf-fecframe-rtp-raptor-04.txt > Pages : 25 > Date : 2010-11-25 >=20 > This document specifies an RTP payload format for Forward Error > Correction /(FEC) repair data produced by the Raptor FEC schemes. > Raptor FEC schemes are specified for use with the IETF FEC Framework > which supports transport of repair data over both UDP and RTP. This > document specifies the payload format which is required for the use > of RTP to carry Raptor repair flows. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. --Apple-Mail-71-1022011487 Content-Type: multipart/mixed; boundary=Apple-Mail-72-1022011488 --Apple-Mail-72-1022011488 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: November 25, 2010 8:30:01 PM = GMT+01:00
Subject: [Fecframe] I-D = Action:draft-ietf-fecframe-rtp-raptor-04.txt

= A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the FEC Framework Working = Group of the IETF.


Title =           : RTP = Payload Format for Raptor FEC
Author(s) =       : M. Watson, T. Stockhammer
Filename =        : = draft-ietf-fecframe-rtp-raptor-04.txt
Pages =           : = 25
= Date =            : = 2010-11-25

This document specifies an RTP payload format for = Forward Error
Correction /(FEC) repair data produced by the Raptor = FEC schemes.
Raptor FEC schemes are specified for use with the IETF = FEC Framework
which supports transport of repair data over both UDP = and RTP.  This
document specifies the payload format which is = required for the use
of RTP to carry Raptor repair flows.

A = URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-rapto= r-04.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-72-1022011488 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2010-11-25112915.I-D@ietf.org>

--Apple-Mail-72-1022011488 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
_______________________________________________
Fecf= rame mailing = list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecfram= e

stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.



= --Apple-Mail-72-1022011488-- --Apple-Mail-71-1022011487-- From stockhammer@nomor.de Thu Nov 25 11:48:28 2010 Return-Path: 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 3CAFC3A68DC for ; Thu, 25 Nov 2010 11:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6] 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 rWp9Dxvs+fH5 for ; Thu, 25 Nov 2010 11:48:27 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by core3.amsl.com (Postfix) with ESMTP id 86CC83A69A4 for ; Thu, 25 Nov 2010 11:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1290714568; l=6500; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=lVezZD/MXBATV2ACZwaPuAQjWnY=; b=M4cySR+jSzxK0avO37R14rDAjLPYMA/CPZNYFbEJPFP3x3v64F5QzBWFMGngRozopTV R4mOypfWt0Zwqko6dhb/6K5xX9Sosknt+9q03P4/oWQL73/9gRhmUmI8hh8hjKPaZ45JG O1xern8X1l/ojdS6VA2YlKqkxmIt9rM+jhU= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [10.0.1.4] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (mrclete mo13) (RZmta 24.6) with ESMTP id y03b1amAPJ2IbM ; Thu, 25 Nov 2010 20:49:27 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: Date: Thu, 25 Nov 2010 20:49:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Luby, Michael" X-Mailer: Apple Mail (2.1082) Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Comments on: I-D Action:draft-ietf-fecframe-raptor-03.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 19:48:28 -0000 Mike, thanks! I will integrate all your suggestions in a revised version. = Before posting a revision, I will await any additional comments received = by Fri, Dec 3rd. Thomas On Nov 23, 2010, at 8:09 PM, Luby, Michael wrote: > Some comments on draft-ietf-fecframe-raptor-03.txt below. >=20 > General nits: >=20 > (1) Change "signalled" to "signaled" > (2) Change "modelled" to "modeled" > (3) Change "arbitary" to "arbitrary" > (4) Change "thepadding" to "the padding" > (5) Change "handware" to "hardware" >=20 > Particulars: >=20 > (6) Section 6.3.2 refers to Section 6.4 for the definition of = I_repair: it > vaguely says that >=20 > The ESI value placed into a repair > packet is given by the following formula: >=20 > "ESI_repair =3D I_repair + SBL, >=20 > where I_repair is the index of the repair symbol in the sequence of > repair symbols generated according to Section 6.4, where the first > repair symbol has index 0, the second index 1 etc. and SBL is the > Source Block Length." >=20 > If you look at Section 6.4, it just says that you shall use the Raptor = in > IETF RFC 5053 or the RaptorQ in the draft specification. But, if you = look > into either Raptor or RaptorQ, you will see that the indexing of the = repair > symbols starts at K, where K is the SBL, and thus you need to = reinterpret to > understand the ESI K in the Raptor or RaptorQ specification = corresponds to > I_repair =3D 0, and then use this in the above, which gives you back = exactly > the same ESI as would have been specified by Raptor or RaptorQ. This = whole > thing is overly confusing, and I think it would be better to just = replace > the above with: >=20 > "The ESI value placed into a repair packet is calculated as specified = in > Section 5.3.2 of [RFC5053] when [RFC5053] is used and as specified in > Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] when > [I-D.ietf-rmt-bb-fec-raptorq] is used, where K=3DSBL." >=20 >=20 > (7) Section 7.1, the second bullet point here is pretty confusing. = Suggest > changing it from: >=20 > "A restricted set of possible source block sizes is specified. > This allows explicit operation sequences for encoding the > restricted set of block sizes to be pre-calculated and embedded = in > software or handware." >=20 > To: > "The possible choices of the source block size for a stream is = restricted to > a small specified set of sizes. This allows explicit operation = sequences > for encoding and decoding the restricted set of source block sizes to = be > pre-calculated and embedded in software or hardware." >=20 >=20 > (8) Section 7.3.2, similar comment to (6) above. Suggest rewording: >=20 > "The ESI value placed into a repair > packet is given by the following formula: >=20 > ESI_repair =3D I_repair + MSBL >=20 > Where I_repair is the index of the repair symbol in the sequence of > repair symbols generated according to Section 6.4, where the first > repair symbol has index 0, the second index 1 etc. and MSBL is the > Maximum Source Block Length signalled in the FEC Scheme Specific > Information. The Source Block Length field of the Repair FEC = Payload > ID field SHALL be set to the number of symbols included in the = Source > Packet Information of packets associated with the source block." >=20 > To: >=20 > "The ESI value placed into a repair packet is calculated as X + MSBL - = SBL, > where X would be the ESI value of the repair packet if the ESI were > calculated as specified in Section 5.3.2 of [RFC5053] when [RFC5053] = is used > and as specified in Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] = when > [I-D.ietf-rmt-bb-fec-raptorq] is used, where K=3DSBL. The value of SBL = SHALL > be at most the value of MSBL." >=20 > (9) Section 8.1.3: The text for the second set of formats is a copy = of the > first set and should be changed. Specifically, The ESI in the second = set of > formats should be specified as 24 bits, not 16 bits, and the ESI text = should > be listed third, not second (to match the order of the parameters in = Fig. > 7). >=20 > Mike=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 11/22/10 11:30 PM, "Internet-Drafts@ietf.org" = > wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the FEC Framework Working Group of the = IETF. >>=20 >>=20 >> Title : Raptor FEC Schemes for FECFRAME >> Author(s) : M. Watson, T. Stockhammer >> Filename : draft-ietf-fecframe-raptor-03.txt >> Pages : 21 >> Date : 2010-11-22 >>=20 >> This document describes Fully-Specified Forward Error Correction >> (FEC) Schemes for the Raptor and RaptorQ codes and their application >> to reliable delivery of media streams in the context of FEC >> Framework. The Raptor and RaptorQ codes are systematic codes, where >> a number of repair symbols are generated from a set of source symbols >> and sent in one or more repair flows in addition to the source >> symbols that are sent to the receiver(s) within a source flow. The >> Raptor and RaptorQ codes offer close to optimal protection against >> arbitrary packet losses at a low computational complexity. Six FEC >> Schemes are defined, two for protection of arbitrary packet flows, >> two that are optimised for small source blocks and another two for >> protection of a single flow that already contains a sequence number. >> Repair data may be sent over arbitrary datagram transport (e.g. UDP) >> or using RTP. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-03.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From stockhammer@nomor.de Thu Nov 25 15:14:31 2010 Return-Path: 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 EFDFB28C0E8 for ; Thu, 25 Nov 2010 15:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6] 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 W+FasucwJJTJ for ; Thu, 25 Nov 2010 15:14:29 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id 7DCD128C10B for ; Thu, 25 Nov 2010 15:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1290726929; l=8575; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=/Id7WN2Kk0zADuymVExCFY65LGY=; b=T8MB95ILsfPqJIr9rODhc4dGkEuO2WAbTwIcdiajDQsFcJ0arr562ZkQwuiKXU5HMtm HWW0fph1SqucqbvIZTEXg1w9CnV3k3EpTBWh3qThlko3SBpzfOQZglWlMgZxpC49dTUZp y8RnGRAEAZnZzVXMUgYwV+Rs8fifqIN2QLw= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [10.0.1.4] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (mrclete mo51) (RZmta 24.6) with ESMTP id a05ecfmAPKhZ5G ; Fri, 26 Nov 2010 00:15:26 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DBBA865@xmb-sjc-215.amer.cisco.com> Date: Fri, 26 Nov 2010 00:15:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBA865@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1082) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Comments on: I-D Action:draft-ietf-fecframe-raptor-03.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 23:14:31 -0000 Ali, thanks! I will integrate all your suggestions in a revised version. = Before posting a revision, I will await any additional comments received = by Fri, Dec 3rd. Thomas On Nov 24, 2010, at 4:38 PM, Ali C. Begen (abegen) wrote: > In addition, please use proper capitalization for the frequently used = terms like "Repair packet", "Payload ID", etc. >=20 > Also you might wanna remove the definitions and acronyms from your = draft, and simply refer to: > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ >=20 > to stay consistent (there is still a slight change the text could be = modified in the framework draft). Or, please make sure that the text = will be updated before the RFC publication. >=20 > In the SDP example, there are some typos. I am only copying the lines = that need to be fixed: >=20 > a=3Dgroup:FEC-FR S1 R1 (Update the a=3Dgroup line in the second = paragraph of section 10 as well) > ... > m=3Dapplication 30000 UDP/FEC > ... > a=3Dfec-repair-flow: encoding-id=3D0; fssi=3DKmax:8192,T:128,P:A > a=3Drepair-window:200ms >=20 >=20 > In the repair-flow line, you are using 0 for the encoding-id. But, = that is now what is registered for a particular FEC scheme you are = defining here. 0 is special and should probably be reserved (I will put = that note in the next framework revision). >=20 > Actually, in Section 12.1, instead of saying XXX, you should put = numbers starting from 1. So that IANA knows what to register. Once you = do that, update the repair-flow line in the SDP to reflect the proper = fec scheme for your example. >=20 > Update the reference 4756bis to RFC 5956. >=20 > You are missing the informative references section. =46rom what I can = tell, there are a few references that are informative - not normative. = You should fix this. >=20 > -acbegen >=20 >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Luby, Michael >> Sent: Tuesday, November 23, 2010 2:10 PM >> To: fecframe@ietf.org >> Subject: [Fecframe] Comments on: I-D = Action:draft-ietf-fecframe-raptor-03.txt >>=20 >> Some comments on draft-ietf-fecframe-raptor-03.txt below. >>=20 >> General nits: >>=20 >> (1) Change "signalled" to "signaled" >> (2) Change "modelled" to "modeled" >> (3) Change "arbitary" to "arbitrary" >> (4) Change "thepadding" to "the padding" >> (5) Change "handware" to "hardware" >>=20 >> Particulars: >>=20 >> (6) Section 6.3.2 refers to Section 6.4 for the definition of = I_repair: it >> vaguely says that >>=20 >> The ESI value placed into a repair >> packet is given by the following formula: >>=20 >> "ESI_repair =3D I_repair + SBL, >>=20 >> where I_repair is the index of the repair symbol in the sequence of >> repair symbols generated according to Section 6.4, where the first >> repair symbol has index 0, the second index 1 etc. and SBL is the >> Source Block Length." >>=20 >> If you look at Section 6.4, it just says that you shall use the = Raptor in >> IETF RFC 5053 or the RaptorQ in the draft specification. But, if you = look >> into either Raptor or RaptorQ, you will see that the indexing of the = repair >> symbols starts at K, where K is the SBL, and thus you need to = reinterpret to >> understand the ESI K in the Raptor or RaptorQ specification = corresponds to >> I_repair =3D 0, and then use this in the above, which gives you back = exactly >> the same ESI as would have been specified by Raptor or RaptorQ. This = whole >> thing is overly confusing, and I think it would be better to just = replace >> the above with: >>=20 >> "The ESI value placed into a repair packet is calculated as specified = in >> Section 5.3.2 of [RFC5053] when [RFC5053] is used and as specified in >> Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] when >> [I-D.ietf-rmt-bb-fec-raptorq] is used, where K=3DSBL." >>=20 >>=20 >> (7) Section 7.1, the second bullet point here is pretty confusing. = Suggest >> changing it from: >>=20 >> "A restricted set of possible source block sizes is specified. >> This allows explicit operation sequences for encoding the >> restricted set of block sizes to be pre-calculated and embedded = in >> software or handware." >>=20 >> To: >> "The possible choices of the source block size for a stream is = restricted to >> a small specified set of sizes. This allows explicit operation = sequences >> for encoding and decoding the restricted set of source block sizes to = be >> pre-calculated and embedded in software or hardware." >>=20 >>=20 >> (8) Section 7.3.2, similar comment to (6) above. Suggest rewording: >>=20 >> "The ESI value placed into a repair >> packet is given by the following formula: >>=20 >> ESI_repair =3D I_repair + MSBL >>=20 >> Where I_repair is the index of the repair symbol in the sequence of >> repair symbols generated according to Section 6.4, where the first >> repair symbol has index 0, the second index 1 etc. and MSBL is the >> Maximum Source Block Length signalled in the FEC Scheme Specific >> Information. The Source Block Length field of the Repair FEC = Payload >> ID field SHALL be set to the number of symbols included in the = Source >> Packet Information of packets associated with the source block." >>=20 >> To: >>=20 >> "The ESI value placed into a repair packet is calculated as X + MSBL = - SBL, >> where X would be the ESI value of the repair packet if the ESI were >> calculated as specified in Section 5.3.2 of [RFC5053] when [RFC5053] = is used >> and as specified in Section 4.4.2 of [I-D.ietf-rmt-bb-fec-raptorq] = when >> [I-D.ietf-rmt-bb-fec-raptorq] is used, where K=3DSBL. The value of = SBL SHALL >> be at most the value of MSBL." >>=20 >> (9) Section 8.1.3: The text for the second set of formats is a copy = of the >> first set and should be changed. Specifically, The ESI in the second = set of >> formats should be specified as 24 bits, not 16 bits, and the ESI text = should >> be listed third, not second (to match the order of the parameters in = Fig. >> 7). >>=20 >> Mike >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 11/22/10 11:30 PM, "Internet-Drafts@ietf.org" = >> wrote: >>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the FEC Framework Working Group of the = IETF. >>>=20 >>>=20 >>> Title : Raptor FEC Schemes for FECFRAME >>> Author(s) : M. Watson, T. Stockhammer >>> Filename : draft-ietf-fecframe-raptor-03.txt >>> Pages : 21 >>> Date : 2010-11-22 >>>=20 >>> This document describes Fully-Specified Forward Error Correction >>> (FEC) Schemes for the Raptor and RaptorQ codes and their application >>> to reliable delivery of media streams in the context of FEC >>> Framework. The Raptor and RaptorQ codes are systematic codes, where >>> a number of repair symbols are generated from a set of source = symbols >>> and sent in one or more repair flows in addition to the source >>> symbols that are sent to the receiver(s) within a source flow. The >>> Raptor and RaptorQ codes offer close to optimal protection against >>> arbitrary packet losses at a low computational complexity. Six FEC >>> Schemes are defined, two for protection of arbitrary packet flows, >>> two that are optimised for small source blocks and another two for >>> protection of a single flow that already contains a sequence number. >>> Repair data may be sent over arbitrary datagram transport (e.g. = UDP) >>> or using RTP. >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-03.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From abegen@cisco.com Fri Nov 26 07:33:41 2010 Return-Path: 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 6EA833A6B16 for ; Fri, 26 Nov 2010 07:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.597 X-Spam-Level: X-Spam-Status: No, score=-10.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 J5qby-L2bQAe for ; Fri, 26 Nov 2010 07:33:40 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E193D3A6A47 for ; Fri, 26 Nov 2010 07:33:39 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEFi70yrR7Hu/2dsb2JhbACjD3GlZ5pxhUcEhFyJGg X-IronPort-AV: E=Sophos;i="4.59,261,1288569600"; d="scan'208";a="293336167" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2010 15:34:43 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oAQFYhEx019430 for ; Fri, 26 Nov 2010 15:34:43 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.4675); Fri, 26 Nov 2010 07:34:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Nov 2010 07:34:27 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAAE4@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed changes to the framework draft - part 1 (ops/managament) Thread-Index: AcuNfo7wfornwcCiSNWhtQX6vxYQAQ== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 26 Nov 2010 15:34:43.0710 (UTC) FILETIME=[72D4C1E0:01CB8D7F] Subject: [Fecframe] Proposed changes to the framework draft - part 1 (ops/managament) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 15:33:41 -0000 Hi everyone, As you know the framework draft is in the IESG review process. As we = discussed in the last meeting, for two of these issues (the others were = already addressed) we would like to consult with the WG. This email is = about the DISCUSS relating to the ops/management issues. There will be a = separate thread for the security issues. Please see the comments from the IESG and then the proposed changes in = the framework draft below. We need your input so that we can provide a = revision soon. Comment from Adrian F.: It would be helpful, I think, if a framework/architecture like this=20 included a discussion of how the systems and networks described are operated and managed. You might look at RFC 5706 for guidance. Discuss from Dan R.: I would like to raise the issue raised by Adrian to a DISCUSS - such a = document is expected to include information about operational impact and = manageability of devices and networks that will comply to the framework, also indication = about what kind of operations and manageability information future = specifications of protocols that comply to the framework would include. This document = includes no such information. I would like to discuss this in the call, maybe these = issues are covered in other fecframe documents, or future work planned by the = WG. -- Some background: Essentially, the IESG wants to make sure that the WG has discussed these = issues adequately and wants to see a text for some guidelines. As a = matter of fact, in the early days, the design team has discussed these = issues in detail (both in the IETF meetings as well as offsite = meetings). The general consensus was that the FEC schemes differed = widely about their capabilities, application and deployment scenarios = such that coming up with a single tool that worked for all of them was = almost impossible. Certain apps are one-way meaning that they don't have = any kind of feedback back from receivers (e.g., broadcast), while some = of them may collect detailed feedback (maybe it is a one-to-one app) or = occasional transport-layer feedback (such as multicast). These = applications have different management aspects. If any, they also have = different requirements or features for collecting feedback, processing = it and acting on it. Their data structures also vary for carrying the = feedback. On the operations side, it is not advisable for the framework draft to = explicitly list what the applications (sender or receiver or a = middle-box) could do upon observing something in particular or receiving = a specific feedback. At best, the framework can make use of existing = tools as much as possible and to the extent possible. For example, for = repair flows using RTP transport, benefiting from all the features of = RTCP mechanisms is strongly encouraged since RTCP has already solved = many of these issues in an agnostic way of the data carried with RTP. Overall, the framework as it stands now makes use of existing = specifications as much as possible and does not dictate the use of any = particular technology for transporting FEC data, managing the endpoints, = signaling the configuration information, or encoding the configuration = information. We had this flexibility since the beginning to cover all = the wide range of all possible scenarios where this framework (and the = resulting CDPs and schemes) could be used. Proposed changes to the framework: I think the IESG is right for expecting to see some text about this. My = proposal is to have a summary at the end of the document mostly = mentioning the things I provided above (of course after incorporating = any feedback from you). If anybody has another proposal or objects to this, please speak up. If = you are OK with this, your email would also help to show the WG = consensus to the IESG. Thanks, -acbegen=20 From stockhammer@nomor.de Fri Nov 26 08:33:32 2010 Return-Path: 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 E833A28C0E4 for ; Fri, 26 Nov 2010 08:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 IzsOIYfTTsCp for ; Fri, 26 Nov 2010 08:33:31 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.161]) by core3.amsl.com (Postfix) with ESMTP id 558E63A6B1E for ; Fri, 26 Nov 2010 08:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1290789272; l=4620; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=dWJJxGY/DjdB/N88W3aDXJCpjn8=; b=UJryeeQfOYaFPlS+HUQjVno5Kx3KolCupwhJEzKwMyT8n6eKv/MxylXArCfV5UabSjA mMFHzJWA944hW5otJpXGtALTrtexscvv2+vb8oFLdpIFOYU0f+tsS36dvJopHFR3zRkIq KDX1VB72MiKm+c2QurUXbJkDmSVUdGIKkUo= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [10.0.1.4] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (jimi mo57) (RZmta 24.6) with ESMTP id w052e4mAQF4gU2 ; Fri, 26 Nov 2010 17:34:32 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAAE4@xmb-sjc-215.amer.cisco.com> Date: Fri, 26 Nov 2010 17:34:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EB4D17F-46C6-4C1E-8E97-1CA0A57FF2E4@nomor.de> References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAAE4@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" X-Mailer: Apple Mail (2.1082) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Proposed changes to the framework draft - part 1 (ops/managament) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 16:33:33 -0000 +1 On Nov 26, 2010, at 4:34 PM, Ali C. Begen (abegen) wrote: > Hi everyone, >=20 > As you know the framework draft is in the IESG review process. As we = discussed in the last meeting, for two of these issues (the others were = already addressed) we would like to consult with the WG. This email is = about the DISCUSS relating to the ops/management issues. There will be a = separate thread for the security issues. >=20 > Please see the comments from the IESG and then the proposed changes in = the framework draft below. We need your input so that we can provide a = revision soon. >=20 > Comment from Adrian F.: >=20 > It would be helpful, I think, if a framework/architecture like this=20 > included a discussion of how the systems and networks described are > operated and managed. You might look at RFC 5706 for guidance. >=20 > Discuss from Dan R.: >=20 > I would like to raise the issue raised by Adrian to a DISCUSS - such a = document > is expected to include information about operational impact and = manageability of > devices and networks that will comply to the framework, also = indication about > what kind of operations and manageability information future = specifications of > protocols that comply to the framework would include. This document = includes no > such information. I would like to discuss this in the call, maybe = these issues > are covered in other fecframe documents, or future work planned by the = WG. >=20 > -- >=20 > Some background: >=20 > Essentially, the IESG wants to make sure that the WG has discussed = these issues adequately and wants to see a text for some guidelines. As = a matter of fact, in the early days, the design team has discussed these = issues in detail (both in the IETF meetings as well as offsite = meetings). The general consensus was that the FEC schemes differed = widely about their capabilities, application and deployment scenarios = such that coming up with a single tool that worked for all of them was = almost impossible. Certain apps are one-way meaning that they don't have = any kind of feedback back from receivers (e.g., broadcast), while some = of them may collect detailed feedback (maybe it is a one-to-one app) or = occasional transport-layer feedback (such as multicast). These = applications have different management aspects. If any, they also have = different requirements or features for collecting feedback, processing = it and acting on it. Their data structures also vary for carrying the = feedback. >=20 > On the operations side, it is not advisable for the framework draft to = explicitly list what the applications (sender or receiver or a = middle-box) could do upon observing something in particular or receiving = a specific feedback. At best, the framework can make use of existing = tools as much as possible and to the extent possible. For example, for = repair flows using RTP transport, benefiting from all the features of = RTCP mechanisms is strongly encouraged since RTCP has already solved = many of these issues in an agnostic way of the data carried with RTP. >=20 > Overall, the framework as it stands now makes use of existing = specifications as much as possible and does not dictate the use of any = particular technology for transporting FEC data, managing the endpoints, = signaling the configuration information, or encoding the configuration = information. We had this flexibility since the beginning to cover all = the wide range of all possible scenarios where this framework (and the = resulting CDPs and schemes) could be used. >=20 > Proposed changes to the framework: >=20 > I think the IESG is right for expecting to see some text about this. = My proposal is to have a summary at the end of the document mostly = mentioning the things I provided above (of course after incorporating = any feedback from you). >=20 > If anybody has another proposal or objects to this, please speak up. = If you are OK with this, your email would also help to show the WG = consensus to the IESG. >=20 > Thanks, > -acbegen=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From gjshep@gmail.com Fri Nov 26 10:04:40 2010 Return-Path: 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 D586528C102 for ; Fri, 26 Nov 2010 10:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, 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 9D6vWctI2oIJ for ; Fri, 26 Nov 2010 10:04:39 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 945DF3A6A69 for ; Fri, 26 Nov 2010 10:04:38 -0800 (PST) Received: by bwz12 with SMTP id 12so2244706bwz.31 for ; Fri, 26 Nov 2010 10:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=1kU3otQM44rWJstZhEFH76JdF8AnBaQgxYKwdCUr2BY=; b=T1q1ZgcTiX2nYm3WGlDsLyIIGLlfgJFDtv90uS/+9U1sk0oO52GfvaGOm1SeCAf2Ga ZEpxI3mr48WKz/yzoJaphwBmbhBTEpP7g/lScn/q/wJlKbQQjMHfQk5ZpffODB6cFzfZ TyFP6oejtbRMH/M3Qr19eaGHxUhILh9LDhgfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=bB1a+pA2aAkAl0qKO71Zuo+WhY1JMKwOiHTdFQ0KpYolyt966G5F6TgzsryY6A/z+q 9WH8BpXJgxO4kYiDuEvj4rEv+vKc8BXJ7+PziYJ64h5VCQuASGRIkCNxKlAT+EcGT7Xz O7+i21HGL/4DcV+btmrxjygph/z+2KqXwJnFs= MIME-Version: 1.0 Received: by 10.204.64.80 with SMTP id d16mr2232098bki.181.1290794741674; Fri, 26 Nov 2010 10:05:41 -0800 (PST) Received: by 10.204.112.71 with HTTP; Fri, 26 Nov 2010 10:05:41 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAAE4@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAAE4@xmb-sjc-215.amer.cisco.com> Date: Fri, 26 Nov 2010 10:05:41 -0800 Message-ID: From: Greg Shepherd To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] Proposed changes to the framework draft - part 1 (ops/managament) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 18:04:41 -0000 Thanks Ali! I support your proposal. Greg On Fri, Nov 26, 2010 at 7:34 AM, Ali C. Begen (abegen) w= rote: > Hi everyone, > > As you know the framework draft is in the IESG review process. As we disc= ussed in the last meeting, for two of these issues (the others were already= addressed) we would like to consult with the WG. This email is about the D= ISCUSS relating to the ops/management issues. There will be a separate thre= ad for the security issues. > > Please see the comments from the IESG and then the proposed changes in th= e framework draft below. We need your input so that we can provide a revisi= on soon. > > Comment from Adrian F.: > > It would be helpful, I think, if a framework/architecture like this > included a discussion of how the systems and networks described are > operated and managed. You might look at RFC 5706 for guidance. > > Discuss from Dan R.: > > I would like to raise the issue raised by Adrian to a DISCUSS - such a do= cument > is expected to include information about operational impact and manageabi= lity of > devices and networks that will comply to the framework, also indication a= bout > what kind of operations and manageability information future specificatio= ns of > protocols that comply to the framework would include. This document inclu= des no > such information. I would like to discuss this in the call, maybe these i= ssues > are covered in other fecframe documents, or future work planned by the WG= . > > -- > > Some background: > > Essentially, the IESG wants to make sure that the WG has discussed these = issues adequately and wants to see a text for some guidelines. As a matter = of fact, in the early days, the design team has discussed these issues in d= etail (both in the IETF meetings as well as offsite meetings). The general = consensus was that the FEC schemes differed widely about their capabilities= , application and deployment scenarios such that coming up with a single to= ol that worked for all of them was almost impossible. Certain apps are one-= way meaning that they don't have any kind of feedback back from receivers (= e.g., broadcast), while some of them may collect detailed feedback (maybe i= t is a one-to-one app) or occasional transport-layer feedback (such as mult= icast). These applications have different management aspects. If any, they = also have different requirements or features for collecting feedback, proce= ssing it and acting on it. Their data structures also vary for carrying the= feedback. > > On the operations side, it is not advisable for the framework draft to ex= plicitly list what the applications (sender or receiver or a middle-box) co= uld do upon observing something in particular or receiving a specific feedb= ack. At best, the framework can make use of existing tools as much as possi= ble and to the extent possible. For example, for repair flows using RTP tra= nsport, benefiting from all the features of RTCP mechanisms is strongly enc= ouraged since RTCP has already solved many of these issues in an agnostic w= ay of the data carried with RTP. > > Overall, the framework as it stands now makes use of existing specificati= ons as much as possible and does not dictate the use of any particular tech= nology for transporting FEC data, managing the endpoints, signaling the con= figuration information, or encoding the configuration information. We had t= his flexibility since the beginning to cover all the wide range of all poss= ible scenarios where this framework (and the resulting CDPs and schemes) co= uld be used. > > Proposed changes to the framework: > > I think the IESG is right for expecting to see some text about this. My p= roposal is to have a summary at the end of the document mostly mentioning t= he things I provided above (of course after incorporating any feedback from= you). > > If anybody has another proposal or objects to this, please speak up. If y= ou are OK with this, your email would also help to show the WG consensus to= the IESG. > > Thanks, > -acbegen > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From gjshep@gmail.com Fri Nov 26 10:10:13 2010 Return-Path: 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 890DF28C0F6 for ; Fri, 26 Nov 2010 10:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, 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 hb-wdKdcH6Cf for ; Fri, 26 Nov 2010 10:10:12 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 3BE8228C0FA for ; Fri, 26 Nov 2010 10:10:12 -0800 (PST) Received: by bwz12 with SMTP id 12so2249066bwz.31 for ; Fri, 26 Nov 2010 10:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=/XlDow1y+AbJ/ZH53vyrhRuethSzcX3SikGAyXUV9V4=; b=r7ScTBBymzVx4uoUqdofgesSz2jMYR4GBJK6KfT0eJqonExKxZoKGo3BtDrxp5Iyud x8O6gdfglIhNxKAe8BNfwZD4qkEXp/GiB+v+U20cW5FLry0emyT80it2pXi5PtlUPmDA SkPGUKpElHEU16dAr4VL5JXwR90NKMI+JfbZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=JBzvdzEWXOlcZRsH7yD0xTz4SP75uj+LCHB/csM5GxJy0jXpiaRZufEsY2Lu8XgLDS dw9++erwsRNKtPdwKVkPRiiWyIR4iz1UlBVnCaw1o2d3j8nYrB4YL/zwW19nUb0wgTlJ 7/uq4m7yXndNaZvGoAQPloEDbycqhJw+MPtBI= MIME-Version: 1.0 Received: by 10.204.152.139 with SMTP id g11mr2218269bkw.127.1290795075585; Fri, 26 Nov 2010 10:11:15 -0800 (PST) Received: by 10.204.112.71 with HTTP; Fri, 26 Nov 2010 10:11:15 -0800 (PST) Date: Fri, 26 Nov 2010 10:11:15 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WG Minutes X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 18:10:13 -0000 First, a huge thank you to Ali for stepping here to chair in my absence. Here are the minutes from the meeting. Please let me know if you have any corrections/clarifications or if you approve of the minutes as is. I'd like to post these asap. Thanks, Greg ----snip--- The interim chair goes over the agenda and draft status. Thomas S. is the new editor for the Raptor drafts. Questions about Raptor drafts (should they be informational as opposed to standards track?). Magnus says there is benefit in publishing them in standards track (as RMT did). The AD wants to confirm that the next two drafts (that Vincent is to present) are in the charter or not. They are not in the charter specifically but they are within the scope of FEC schemes. Vincent starts with the first slide deck. Goes over the issues (related to IPR) that were addressed in the latest version. Says the draft is pretty mature to be adopted. The chair will ask the list. The second slide deck. This is the RTP payload format for the RS codes. It will be finished by the next meeting, and accompanies the RS draft. AVT will have to review this and the chair will ask the WG to adopt it or not. The AD - on the mic - says that if these FEC schemes will not be implemented by multiple vendors, they could actually go thru the AD-sponsored path. The third deck. Motivation for this work is the low-decoding complexity for high-bitrate apps. It has different use cases compared to other existing FEC schemes. Discussing a very recent paper that explains the code and its performance. The AD asks whether there is any IPR on this. Vincent says "today, there is not on this draft but there are some IPR disclosures on a related RFC," which is 5170. Ali starts discussing the IESG comments for the framework draft (Ali is the new editor). * Concerning Management and Operations: AD: IESG want to make sure that you properly thought about these issues, so try to put some simple text and guidelines. What should an operator like to know? What should a FECFRAME implementation provide? * Concerning Congestion Control: AD: If you don't know the history of the WG, it's hard to figure out why there is this rule of no more than twice the bandwidth. Colin: There is a frequent misunderstanding about congestion control and FEC. * Concerning Security: Vincent: I'm the one who performed the SecDir review for this document. I think it's extremely important to have a detailed "security considerations" section since this is a framework document that is referenced by all other FECFRAME documents. Among the things I think are required is a "mandatory to implement but not necessarily to use" security mechanism. It seems that requiring IPsec/ESP be mandatory is fine. AD: I agree. David (AD hat off): if we anticipate that FECFRAME will be used for something else than real-time flows, for instance for MIKEY or other applications, then it's better to mention it. MIKEY was just an example. Magnus: You can use it as well for DNS. It needs to be better clarified. David: You can have a discussion on how to apply it to a specific use-case in the Operations and Management section. Concerning some fields starting from 0: Colin: Clarify the assumptions about wrapping. There's also an issue about possible rekeying before the end of a block. You can have a look at the RTP security considerations. Discussion started on how to handle future FEC Schemes if the FECFRAME is closed. Proposal is to have schemes with RTP framing of repair packets be managed by the AVT WG, and other schemes by the TSV WG. ---snip---