From gjshep@gmail.com Tue Sep 7 16:33:19 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 9CB3A3A6997 for ; Tue, 7 Sep 2010 16:33:19 -0700 (PDT) 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 MEBUynAhx4ME for ; Tue, 7 Sep 2010 16:33:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 729FC3A6984 for ; Tue, 7 Sep 2010 16:33:18 -0700 (PDT) Received: by iwn3 with SMTP id 3so6583862iwn.31 for ; Tue, 07 Sep 2010 16:33:46 -0700 (PDT) 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:content-type; bh=aEdOpvisNdCPvJHWZ5tqgxR62bs0y3+814gdSATqROs=; b=BADChhuMEfKwsRsZpJE0MNzQolPAJqL4b500gZUZ1xvW2kPbFAkZtCSF5tnXBmL9cQ fa7YTNj/B3SxlzNdxj2g6NWHrRxowBrZ7vYK6Z/3VlVenr+DDVU3aGMupHxg7vBp/t83 t63L4ze7DzDEx2CsFoAhZfutDk4mgmfa1rrXM= 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:content-type; b=Ynyez1Lgt4O4nR84f0mJCCakVrx1vAJNW1V4aUGkke+ATRtGmBzCSJfde3z8gdOogF JdXeckAwDQFWKRoDDzZdtSU3X5EdM9JLf7gL4aws93PFNzd1Je+ws/k2/c/hVqaV0lyq j39IzxOAseg9si5W5ErEPj/EIRMEYJNlu9YSQ= MIME-Version: 1.0 Received: by 10.231.36.202 with SMTP id u10mr3451189ibd.64.1283902426029; Tue, 07 Sep 2010 16:33:46 -0700 (PDT) Received: by 10.231.146.67 with HTTP; Tue, 7 Sep 2010 16:33:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Sep 2010 16:33:45 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] Fwd: Important Dates for IETF 79 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, 07 Sep 2010 23:33:19 -0000 ---------- Forwarded message ---------- From: David Harrington Date: Tue, Sep 7, 2010 at 9:20 AM Subject: Important Dates for IETF 79 To: TSV chairs , TSV Dir , tsv-area@ietf.org Hi, Just a reminder. Important dates for the Beijing IETF: 2010-09-13 (Monday): Cutoff date for BOF proposal requests to Area Directors at 17:00 PT (24:00 UTC). To request a BOF, please see instructions on Requesting a BOF. 2010-09-27 (Monday): Cutoff date for requests to schedule Working Group meetings at 17:00 PT (24:00 UTC). To request a Working Group session, use the IETF Meeting Session Request Tool. 2010-09-27 (Monday): Cutoff date for Area Directors to approve BOFs at 17:00 PT (24:00 UTC). 2010-10-06 (Wednesday): Preliminary agenda published for comment. 2010-10-11 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (24:00 UTC). 2010-10-11 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (24:00 UTC). 2010-10-15 (Friday): Final agenda to be published. 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (24:00 UTC), upload using IETF ID Submission Tool. 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT (24:00 UTC), upload using IETF ID Submission Tool. 2010-10-27 (Wednesday): Draft Working Group agendas due by 17:00 PT (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-11-01 (Monday): Revised Working Group agendas due by 17:00 PT (01:00 Tuesday, November 02 UTC), upload using IETF Meeting Materials Management Tool. Note that the first two cutoff dates (BOF requests, WG meetings scheduling) are very close. Also, although the draft WG agendas are required later in the process we strongly prefer that all WGs submit draft agendas together with the request to schedule meetings. Thanks, David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From root@core3.amsl.com Wed Sep 8 11:15:05 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1503C3A698C; Wed, 8 Sep 2010 11:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100908181503.1503C3A698C@core3.amsl.com> Date: Wed, 8 Sep 2010 11:15:02 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-framework-10.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, 08 Sep 2010 18:15:12 -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 Filename : draft-ietf-fecframe-framework-10.txt Pages : 38 Date : 2010-09-08 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 Forward Error Correction 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 Forward Error Correction 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-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-08110353.I-D@ietf.org> --NextPart-- From abegen@cisco.com Tue Sep 21 10:55:50 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 DCE5F3A6A7D for ; Tue, 21 Sep 2010 10:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.256 X-Spam-Level: X-Spam-Status: No, score=-10.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_93=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 wNjhmTPsgWyG for ; Tue, 21 Sep 2010 10:55:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C9B8C3A6A62 for ; Tue, 21 Sep 2010 10:55:49 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAaPmEyrR7Hu/2dsb2JhbACUNo10cag8nEGFQQSETohu X-IronPort-AV: E=Sophos;i="4.56,400,1280707200"; d="scan'208";a="592733719" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 21 Sep 2010 17:56:14 +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 o8LHuFcm001031 for ; Tue, 21 Sep 2010 17:56:15 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); Tue, 21 Sep 2010 10:56:14 -0700 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: Tue, 21 Sep 2010 10:55:27 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D2D3014@xmb-sjc-215.amer.cisco.com> In-Reply-To: <20100921170606.617B0E0685@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RFC 5956 on Forward Error Correction Grouping Semantics inthe Session Description Protocol Thread-Index: ActZr2YSn7/IykX1S6qef0ur6/+RtAABr/5g References: <20100921170606.617B0E0685@rfc-editor.org> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 21 Sep 2010 17:56:14.0910 (UTC) FILETIME=[48B78DE0:01CB59B6] Subject: [Fecframe] FW: [MMUSIC] RFC 5956 on Forward Error Correction Grouping Semantics inthe Session Description Protocol 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, 21 Sep 2010 17:55:51 -0000 FYI. -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of rfc-editor@rfc-editor.org Sent: Tuesday, September 21, 2010 1:06 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: mmusic@ietf.org; rfc-editor@rfc-editor.org Subject: [MMUSIC] RFC 5956 on Forward Error Correction Grouping = Semantics inthe Session Description Protocol A new Request for Comments is now available in online RFC libraries. =20 RFC 5956 Title: Forward Error Correction Grouping Semantics=20 in the Session Description Protocol=20 Author: A. Begen Status: Standards Track Stream: IETF Date: September 2010 Mailbox: abegen@cisco.com Pages: 14 Characters: 29530 Obsoletes: RFC4756 I-D Tag: draft-ietf-mmusic-rfc4756bis-10.txt URL: http://www.rfc-editor.org/rfc/rfc5956.txt This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888). These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. [STANDARDS TRACK] This document is a product of the Multiparty Multimedia Session Control = Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and = suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From tme@americafree.tv Thu Sep 23 07:55: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 766583A6B18; Thu, 23 Sep 2010 07:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 3Skx4q4C3XUj; Thu, 23 Sep 2010 07:55:52 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 283F83A6B69; Thu, 23 Sep 2010 07:55:52 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 0DF198E942D5; Thu, 23 Sep 2010 10:56:21 -0400 (EDT) From: Marshall Eubanks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Sep 2010 10:56:20 -0400 Message-Id: To: IESG , TSV Dir Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: fecframe@ietf.org Subject: [Fecframe] TSV-DIR review of draft-ietf-fecframe-framework-10 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, 23 Sep 2010 14:55:56 -0000 I've reviewed this document as part of the transport area directorate's = ongoing effort to review key IETF documents. These comments were written = primarily for the transport area directors, but are copied to the = document's authors for their information and to allow them to address = any issues raised. The authors should consider this review together with = any other last-call comments they receive. Please always CC = tsv-dir@ietf.org if you reply to or forward this review. I apologize for being late with this, but there is an important = transport issue in this document that I think needs to be discussed.=20 I should say first that I was part of the design team meetings that lead = to this document, and co-chaired the WG during part of its development, = but what follows is entirely my opinion.=20 This document sets up the overall framework for using Forward Erasure = Correction (FEC) in a standards based fashion. The only real transport issue with the FECFRAME work in general, and = this document in particular, is related to Congestion Control and is = described well in Section 8 of the current document, which includes both = an "Informative Note" (offset from the main text) and Normative = Requirements (in Section 8.1). FEC does have to deal with congestion control. The intended use of the = FEC framework is to protect (i.e., provide redundancy for) arbitrary = flows over unreliable transport. That unreliable transport at present is = predominately UDP, which does not include congestion control. In = practice, FEC can be applied in the middle of the network (say, at the = border of a wireless domain), can be applied multiple times, etc. There = is also typically no constraint on the amount of FEC applied _from the = FEC protocols_ (i.e., the FEC could in principle be many times the = bandwidth of the original flow). If the FEC bandwidth was not limited it = would, as a worst case, make possible a "tcp fairness attack," where the = original flow was limited to some tcp fairness bandwidth, but an = arbitrary bandwidth was obtained through a sufficient number of FEC = packets. That may not be likely, but FEC in practice may be adaptive = (i.e., the FEC bandwidth can be increased or decreased in response to = network conditions), and that definitely carries a danger of true = congestive collapse (where the FEC bandwidth increases without bound as = more packets are lost). So, it was pretty clear to everyone that some sort of congestion control = would be required for the FEC framework.=20 There was a solid consensus that FEC should be limited to some = proportion of the underlying flow, so the question then becomes, what is = the maximum percentage for FEC flows? There were lengthy discussions = about this.=20 There were proposals that this be limited to the 5% allowed to RTCP = (maybe with a RFC 3556 type extension), but this seemed too restrictive = (in any wireless network with RFI, for example, 5% would likely be too = low). The argument was made (and gained consensus) that the important = feature is that the FEC packet flows be limited to some proportion of = the underlying flow (and thus adapt based on whatever congestion control = is applied to the underlying flow) and that it MUST not be allowed to = grow without bound, but that on that basis a fairly large percentage = should be OK. So, the adopted text is (Section 8.1) : The bandwidth of FEC Repair packet flows MUST NOT exceed the = bandwidth of the source packet flows being=20 protected. This allows for a doubling of the underlying transport bandwidth, but = not an unlimited increase in bandwidth. There was consensus that this = would allow for almost any realistic FEC scenario, as really high packet = loss scenarios tend to at least create problems with signaling of flows = and are likely to be simply unusable for real time media transport.=20 So, the FEC framework allows for a potential doubling of UDP bandwidth, = but no more, and relies on the the underlying application for congestion = control. At any rate, I do not think it will cause congestive collapse, = as there is no mechanism that allows for bandwidth to grow without bound = as network conditions worsen. I think that that is adequate and = recommend that this document be approved.=20 Regards Marshall Eubanks From ietfdbh@comcast.net Fri Sep 24 06:28:08 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 7B3073A6B42 for ; Fri, 24 Sep 2010 06:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, 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 t5efdADmlCIo for ; Fri, 24 Sep 2010 06:28:07 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 6430E3A6AB4 for ; Fri, 24 Sep 2010 06:28:07 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id Ac8c1f0061GhbT851dUgPn; Fri, 24 Sep 2010 13:28:40 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta07.westchester.pa.mail.comcast.net with comcast id AdUf1f0062JQnJT3TdUf3A; Fri, 24 Sep 2010 13:28:39 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , References: <20100923054125.05F463A6928@core3.amsl.com><04CAD96D4C5A3D48B1919248A8FE0D540D39E8E9@xmb-sjc-215.amer.cisco.com><4C9AF06D.8040109@piuha.net> <04CAD96D4C5A3D48B1919248A8FE0D540D39E8EA@xmb-sjc-215.amer.cisco.com> Date: Fri, 24 Sep 2010 09:28:01 -0400 Message-ID: <6CB3AC602FDA48D4AB3A3F997DD71F4A@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-index: Acta5sCeM+KgL3kAQ9S0RSj0tec97gAAAl5wAEDme6A= In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D39E8EA@xmb-sjc-215.amer.cisco.com> Cc: fecframe-chairs@tools.ietf.org, draft-ietf-fecframe-sdp-elements@tools.ietf.org Subject: Re: [Fecframe] DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements 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, 24 Sep 2010 13:28:08 -0000 Hi, I see you are on top of most of the comments and DISCUSSes already. Great! I agree with publishing an update so they can clear if they want. dbh > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of Ali C. Begen (abegen) > Sent: Thursday, September 23, 2010 2:17 AM > To: Jari Arkko > Cc: ari.keranen@ericsson.com; fecframe-chairs@tools.ietf.org; > iesg@ietf.org; draft-ietf-fecframe-sdp-elements@tools.ietf.org > Subject: RE: DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements > > I am holding onto the revision until I hear from all the > members. Then a revision will be on its way. > > Cheers, acbegen. > > > -----Original Message----- > > From: Jari Arkko [mailto:jari.arkko@piuha.net] > > Sent: Thursday, September 23, 2010 2:15 AM > > To: Ali C. Begen (abegen) > > Cc: iesg@ietf.org; fecframe-chairs@tools.ietf.org; > > ari.keranen@ericsson.com; draft-ietf-fecframe-sdp- > > elements@tools.ietf.org > > Subject: Re: DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements > > > > That was fast! Is there a new draft already so that I could clear? > > > > Jari > > > > Ali C. Begen (abegen) kirjoitti: > > > > > >> -----Original Message----- > > >> From: Jari Arkko [mailto:jari.arkko@piuha.net] > > >> Sent: Thursday, September 23, 2010 1:41 AM > > >> To: iesg@ietf.org > > >> Cc: ari.keranen@ericsson.com; fecframe-chairs@tools.ietf.org; > > >> draft-ietf-fecframe-sdp-elements@tools.ietf.org > > >> Subject: DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements > > >> > > >> Discuss: > > >> Please correct the use of ', |, HT from the ABNF, and remove any > > >> duplication. > > >> > > > > > > Already did. > > > > > > > > >>> If the FEC scheme does not require any specific > information, the > > >>> 'ss-fssi' and 'fssi' parameters MAY be null and ignored. > > >>> > > >> The ABNF allows both leaving these constructs out completely, or > > >> specifying them without any elements. Which one, or > either one do > > >> you mean here? Please clarify. > > >> > > > > > > I think the following change will fix this (section 4.5): > > > sender-info = element *( ',' element ) > > > > > > And in the text, we will say if there is not fssi info, > the construct will not appear. > > > > > > > > >> Capitalization of udp/fec needs to be consistent throughout the > > >> spec. > > >> > > > > > > OK will check again. > > > > > > > > >> Comment: > > >> These issues came up in a review by Ari Keranen: > > >> > > >> 4.5. Repair Flows > > >> > > >> sender-info = [ element *( ',' element ) ] > > >> > > >> Shouldn't use "'" character in ABNF (same problem in multiple > > >> places) > > >> > > > > > > I guess it should be: > > > sender-info = [ element *( "," element ) ] > > > > > > > > >> separator = "(" | ")" | "<" | ">" | "@" > > >> | "," | ";" | ":" | "\" | <"> > > >> | "/" | "[" | "]" | "?" | "=" > > >> | "{" | "}" | SP | HT > > >> > > >> Should use "/" instead of "|" for alternatives. Should use "HTAB" > > >> instead of "HT"? > > >> > > > > > > Yes, fixed it already. > > > > > > > > >> Rules element, name, token, value, and separator are > defined twice. > > >> > > > > > > Will remove the second copies. > > > > > > > > >> If the FEC scheme does not require any specific > > >> information, the 'ss-fssi' and 'fssi' parameters MAY > be null and > > >> ignored. > > >> > > >> By "be null" do you mean "not exist" or something else? > > >> > > > > > > I will revise this as I described above. > > > > > > > > >> 6.1. One Source Flow, One Repair Flow and One FEC Scheme > > >> > > >> m=application 30000 udp/fec > > >> > > >> change "udp/fec" into "UDP/FEC" to be consistent with sec 4.1. > > >> > > > > > > Will do. > > > > > > Thanks. > > > -acbegen > > > > > From ietfdbh@comcast.net Fri Sep 24 06:34:23 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 B531B3A69A9 for ; Fri, 24 Sep 2010 06:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 Ru8Y3W4W-Wpd for ; Fri, 24 Sep 2010 06:34:22 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id 66B433A6997 for ; Fri, 24 Sep 2010 06:34:22 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta14.westchester.pa.mail.comcast.net with comcast id AanV1f0021ZXKqc5EdavNj; Fri, 24 Sep 2010 13:34:55 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta21.westchester.pa.mail.comcast.net with comcast id Adau1f00N2JQnJT3hdauGa; Fri, 24 Sep 2010 13:34:55 +0000 From: "David Harrington" To: References: <20100923061319.1C9803A6848@core3.amsl.com> Date: Fri, 24 Sep 2010 09:34:17 -0400 Message-ID: <673BFD772BB04FFE81726AB015C22246@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-index: Acta5n8B1SQjs77BQQSmZ+5o76qAQABBdtrA In-Reply-To: <20100923061319.1C9803A6848@core3.amsl.com> Cc: fecframe-chairs@tools.ietf.org, draft-ietf-fecframe-framework@tools.ietf.org Subject: Re: [Fecframe] COMMENT: draft-ietf-fecframe-framework 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, 24 Sep 2010 13:34:23 -0000 Hi, Many of the comments should be fairly simple to address. Marshall Eubanks did a tsv-dir review that discusses the considerations of congestion control. http://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ under History The document only talks about limiting to twice the bandwidth of the source flow. I think more text would be helpful so people understand what was considered, not just the result. Yu might be able to cut-and-paste some text from Marshall's review. I think those are all fairly simple fixes. I agree with publishing an update so they can clear if they want. The operations and management should be addressesd to satisfy the DISCUSS by Dan (which started as a comment from Adrian): "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 compy to the framework, also indication about what kind of operations and manageability information future specifications of protocols that comply to the framwork 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." dbh > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of Adrian Farrel > Sent: Thursday, September 23, 2010 2:13 AM > To: iesg@ietf.org > Cc: fecframe-chairs@tools.ietf.org; > draft-ietf-fecframe-framework@tools.ietf.org > Subject: COMMENT: draft-ietf-fecframe-framework > > Comment: > > Thanks for this document. > > I have a Comment that might generate a substantial piece of > work for you. I do not feel strongly enough to enter a > Discuss, but it would be great if you thought about it and > maybe added to the document. > > 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. > > -- > > I have a cople minor comments about Section 8 > > The authors of this draft are primarily interested in > applications > > s/draft/document/ > > We propose a third approach, which is to require at a > minimum that > the use of this framework with any given application, > in any given > environment, does not cause congestion issues which the > application alone would not itself cause i.e. the use of this > framework must not make things worse. > > This is a Standards Track document. s/propose/define/ > From abegen@cisco.com Fri Sep 24 06:36: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 972303A6B90 for ; Fri, 24 Sep 2010 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_111=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 LSpc3uvOYk1O for ; Fri, 24 Sep 2010 06:35:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4597C3A6997 for ; Fri, 24 Sep 2010 06:35:59 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB9GnEyrR7Ht/2dsb2JhbACiQXGoB5wnhUMEhFCIbg X-IronPort-AV: E=Sophos;i="4.57,229,1283731200"; d="scan'208";a="240000373" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2010 13:36:31 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8ODaV9A025607; Fri, 24 Sep 2010 13:36:31 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Sep 2010 06:36:30 -0700 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: Fri, 24 Sep 2010 06:36:20 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D39ED14@xmb-sjc-215.amer.cisco.com> In-Reply-To: <6CB3AC602FDA48D4AB3A3F997DD71F4A@23FX1C1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements Thread-Index: Acta5sCeM+KgL3kAQ9S0RSj0tec97gAAAl5wAEDme6AAALmNkA== References: <20100923054125.05F463A6928@core3.amsl.com><04CAD96D4C5A3D48B1919248A8FE0D540D39E8E9@xmb-sjc-215.amer.cisco.com><4C9AF06D.8040109@piuha.net> <04CAD96D4C5A3D48B1919248A8FE0D540D39E8EA@xmb-sjc-215.amer.cisco.com> <6CB3AC602FDA48D4AB3A3F997DD71F4A@23FX1C1> From: "Ali C. Begen (abegen)" To: "David Harrington" , X-OriginalArrivalTime: 24 Sep 2010 13:36:30.0968 (UTC) FILETIME=[7F33F780:01CB5BED] Cc: fecframe-chairs@tools.ietf.org, draft-ietf-fecframe-sdp-elements@tools.ietf.org Subject: Re: [Fecframe] DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements 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, 24 Sep 2010 13:36:01 -0000 Sure, I fixed all the issues except the one related to IANA registration = and for that I sent an email to IANA, waiting for their response. -acbegen > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, September 24, 2010 9:28 AM > To: Ali C. Begen (abegen); fecframe@ietf.org > Cc: fecframe-chairs@tools.ietf.org; = draft-ietf-fecframe-sdp-elements@tools.ietf.org > Subject: RE: DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements >=20 > Hi, >=20 > I see you are on top of most of the comments and DISCUSSes already. > Great! > I agree with publishing an update so they can clear if they want. >=20 > dbh >=20 > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > > Behalf Of Ali C. Begen (abegen) > > Sent: Thursday, September 23, 2010 2:17 AM > > To: Jari Arkko > > Cc: ari.keranen@ericsson.com; fecframe-chairs@tools.ietf.org; > > iesg@ietf.org; draft-ietf-fecframe-sdp-elements@tools.ietf.org > > Subject: RE: DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements > > > > I am holding onto the revision until I hear from all the > > members. Then a revision will be on its way. > > > > Cheers, acbegen. > > > > > -----Original Message----- > > > From: Jari Arkko [mailto:jari.arkko@piuha.net] > > > Sent: Thursday, September 23, 2010 2:15 AM > > > To: Ali C. Begen (abegen) > > > Cc: iesg@ietf.org; fecframe-chairs@tools.ietf.org; > > > ari.keranen@ericsson.com; draft-ietf-fecframe-sdp- > > > elements@tools.ietf.org > > > Subject: Re: DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements > > > > > > That was fast! Is there a new draft already so that I could clear? > > > > > > Jari > > > > > > Ali C. Begen (abegen) kirjoitti: > > > > > > > >> -----Original Message----- > > > >> From: Jari Arkko [mailto:jari.arkko@piuha.net] > > > >> Sent: Thursday, September 23, 2010 1:41 AM > > > >> To: iesg@ietf.org > > > >> Cc: ari.keranen@ericsson.com; fecframe-chairs@tools.ietf.org; > > > >> draft-ietf-fecframe-sdp-elements@tools.ietf.org > > > >> Subject: DISCUSS and COMMENT: draft-ietf-fecframe-sdp-elements > > > >> > > > >> Discuss: > > > >> Please correct the use of ', |, HT from the ABNF, and remove > any > > > >> duplication. > > > >> > > > > > > > > Already did. > > > > > > > > > > > >>> If the FEC scheme does not require any specific > > information, the > > > >>> 'ss-fssi' and 'fssi' parameters MAY be null and ignored. > > > >>> > > > >> The ABNF allows both leaving these constructs out completely, > or > > > >> specifying them without any elements. Which one, or > > either one do > > > >> you mean here? Please clarify. > > > >> > > > > > > > > I think the following change will fix this (section 4.5): > > > > sender-info =3D element *( ',' element ) > > > > > > > > And in the text, we will say if there is not fssi info, > > the construct will not appear. > > > > > > > > > > > >> Capitalization of udp/fec needs to be consistent throughout the >=20 > > > >> spec. > > > >> > > > > > > > > OK will check again. > > > > > > > > > > > >> Comment: > > > >> These issues came up in a review by Ari Keranen: > > > >> > > > >> 4.5. Repair Flows > > > >> > > > >> sender-info =3D [ element *( ',' element ) ] > > > >> > > > >> Shouldn't use "'" character in ABNF (same problem in multiple > > > >> places) > > > >> > > > > > > > > I guess it should be: > > > > sender-info =3D [ element *( "," element ) ] > > > > > > > > > > > >> separator =3D "(" | ")" | "<" | ">" | "@" > > > >> | "," | ";" | ":" | "\" | <"> > > > >> | "/" | "[" | "]" | "?" | "=3D" > > > >> | "{" | "}" | SP | HT > > > >> > > > >> Should use "/" instead of "|" for alternatives. Should use > "HTAB" > > > >> instead of "HT"? > > > >> > > > > > > > > Yes, fixed it already. > > > > > > > > > > > >> Rules element, name, token, value, and separator are > > defined twice. > > > >> > > > > > > > > Will remove the second copies. > > > > > > > > > > > >> If the FEC scheme does not require any specific > > > >> information, the 'ss-fssi' and 'fssi' parameters MAY > > be null and > > > >> ignored. > > > >> > > > >> By "be null" do you mean "not exist" or something else? > > > >> > > > > > > > > I will revise this as I described above. > > > > > > > > > > > >> 6.1. One Source Flow, One Repair Flow and One FEC Scheme > > > >> > > > >> m=3Dapplication 30000 udp/fec > > > >> > > > >> change "udp/fec" into "UDP/FEC" to be consistent with sec 4.1. > > > >> > > > > > > > > Will do. > > > > > > > > Thanks. > > > > -acbegen > > > > > > > > From root@core3.amsl.com Sun Sep 26 21:00:02 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 856873A6C49; Sun, 26 Sep 2010 21:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100927040002.856873A6C49@core3.amsl.com> Date: Sun, 26 Sep 2010 21:00:02 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-sdp-elements-09.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: Mon, 27 Sep 2010 04:00:02 -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 : Session Description Protocol Elements for FEC Framework Author(s) : A. Begen Filename : draft-ietf-fecframe-sdp-elements-09.txt Pages : 19 Date : 2010-09-26 This document specifies the use of Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-sdp-elements-09.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-sdp-elements-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-26204859.I-D@ietf.org> --NextPart--