From abegen@cisco.com Mon Mar 2 13:52:19 2009 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 997D728C0E3; Mon, 2 Mar 2009 13:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qMwZ3YLEdz2W; Mon, 2 Mar 2009 13:52:18 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 991C228C21A; Mon, 2 Mar 2009 13:52:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,291,1233532800"; d="scan'208";a="138624263" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2009 21:52:45 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n22Lqj32020428; Mon, 2 Mar 2009 13:52:45 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n22LqjjB010367; Mon, 2 Mar 2009 21:52:45 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 13:52:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2009 13:51:16 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408C4EB46@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using the same CNAME for multiple hosts Thread-Index: AcmbgQNH99oNfu0USg+/0JnbJ2MZhA== From: "Ali C. Begen (abegen)" To: "IETF AVT WG" X-OriginalArrivalTime: 02 Mar 2009 21:52:45.0053 (UTC) FILETIME=[38118AD0:01C99B81] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1832; t=1236030765; x=1236894765; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20Using=20the=20same=20CNAME=20for=20multiple=20h osts |Sender:=20; bh=lhgd3S0msO2pmuOh4+PQv+enDuzVc6pvPNHbpbSiUYM=; b=sxcqwZCJIvZear1SLdwmnn6k3AtRWvCDfS/VEqOBqiEynfUb+n7m7gsVmd fZQoCq7bxnQq3wGPQbTCt+BpCND3iIsap8DaReW1EB+qzX9461Yh8cYpVbBG 2HXXQRqiUnbkJFrpw+Hhw4GEXVatsIi+EOfCjCDhxcFxttqYXMpR0=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: fecframe@ietf.org Subject: [Fecframe] Using the same CNAME for multiple hosts 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, 02 Mar 2009 21:52:19 -0000 (Copying fecframe as well) Magnus brought up a concern in the last fecframe session regarding the use of the same CNAME by multiple hosts. Here is a scenario: RTP FEC SOURCE ---> ENCODER ---> FEC Stream ---> RTP | Receiver +--------------Source Stream --> (RR) This is a simple scenario, in more complex systems, there could be different FEC encoders producing different FEC streams from the same source stream. In other scenarios, multiple RTP source streams could be combined and fed together to an FEC encoder. RFC 4756 has the source/repair grouping semantics for SDP: a=3Dgroup:fec s1 r1 On the RTP side, RFC 2733 used the same SSRC value for both source and repair streams for easier association. Later, RFC 5109 did the same thing. Now, following the rules of RTP and based on the suggestions from various individuals, we would like to use distinct (random) SSRC values for the source and repair streams. This allows the sender to multiplex source and repair streams on a single port (good for easier NAT traversal, etc). We propose to use the CNAME field for association between the repair and source streams. This provides us greater flexibility. This approach requires the use of the same CNAME by different hosts (a common CNAME could be produced based on an algorithm). However, a naive RTP device MAY assume that data from different flows with the same CNAME come from the same host. Since this is not the case in our scenario, such devices will break in our approach! Does anybody see a potential problem here? Any objections to our proposal? If so, please speak up. We have multiple drafts using this approach and we need to hear objections (if any) before we complete those drafts. Thanks. -acbegen From tme@multicasttech.com Tue Mar 3 12:41:40 2009 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 B3D343A69CE for ; Tue, 3 Mar 2009 12:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.563 X-Spam-Level: X-Spam-Status: No, score=-103.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 QnKs9hSu3VJn for ; Tue, 3 Mar 2009 12:41:39 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 99E363A6924 for ; Tue, 3 Mar 2009 12:41:39 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14846624 for fecframe@ietf.org; Tue, 03 Mar 2009 15:41:35 -0500 Message-Id: From: Marshall Eubanks To: fecframe@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Mar 2009 15:42:01 -0500 References: <4D6ADA68-BE88-4953-9357-82CB635A7A30@isoc.org> X-Mailer: Apple Mail (2.930.3) Subject: [Fecframe] Fwd: Tools to Publish I-Ds with pre-5378 Content 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, 03 Mar 2009 20:41:40 -0000 Note well - this does NOT apply to entirely new text. Marshall Begin forwarded message: > From: Ray Pelletier > Date: March 3, 2009 3:40:07 PM EST > To: IETF Discussion > Cc: Trustees > Subject: Tools to Publish I-Ds with pre-5378 Content > > All; > > Several tools to publish Internet Drafts have implemented the IETF > Trust's recent policy changes that provide a work-around to the > issues raised by the inclusion of material from contributions > published before 10 November 2008. You may have already been aware > of one or more of the tools from other lists, or discussions on this > list, but the Trust wanted to consolidate the information to ensure > its general and aggregated availability, even at this time, just 24 > hours before the -00 deadline for IETF 74. > > If your Internet Draft contains pre-5378 Material as to which the > IETF Trust has not been granted, or may not have been granted, the > necessary permissions to allow modification of such pre-5378 > Material outside the IETF Standards Process then section 6.c.iii > from http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf must > be included in the draft. > > Volunteers who created and maintain the tools have implemented the > updates: > > 1. idnits - (thanks Henrik Levkowetz) > 2. Word template - (thanks Joe Touch) > 3. xml2rfc - (thanks Bill Fenner and Marshall Rose) > > The tools can be found at: > 1. idnits - http://tools.ietf.org/tools/ > 2. Word template - http://tools.ietf.org/inventory/author-tools.shtml > 3. xml2rfc - http://xml.resource.org/experimental.html > > A little more info on the xml2rfc variants (borrowed from Julian > Reschke - thanks) > > This version, v1.34pre3, implements the IETF Trust language of > November, 2008 and > February, 2009. > > Briefly, you want to set the 'ipr' attribute of the element > to one of these values: > > trust200811 > noModificationTrust200811 > noDerivativesTrust200811 > trust200902 > noModificationTrust200902 > noDerivativesTrust200902 > pre5378Trust20090 > > The final value in the list above is probably the one of interest to > most folks. > > At this point, only the *200902* variants should be relevant (not > all of > those changed from 200811, but we added all of them for consistency). > > (1) "trust200902" is the value to choose when no restrictions are > being made. > > (2) "noModificationTrust200902" adds > > "This document may not be modified, and derivative works of it may not > be created, except to format it for publication as an RFC or to > translate it into languages other than English." > > as defined in Section 6.c.i of > . > > > (3) "noDerivativesTrust200902" adds > > "This document may not be modified, and derivative works of it may not > be created, and it may not be published except as an Internet-Draft." > > as defined in Section 6.c.ii of > . > > > (4) "pre5378Trust200902" adds > > "This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November 10, > 2008. The person(s) controlling the copyright in some of this material > may not have granted the IETF Trust the right to allow modifications > of > such material outside the IETF Standards Process. Without obtaining an > adequate license from the person(s) controlling the copyright in such > materials, this document may not be modified outside the IETF > Standards > Process, and derivative works of it may not be created outside the > IETF > Standards Process, except to format it for publication as an RFC or to > translate it into languages other than English." > > as defined in Section 6.c.iii of > . > This is the new variant that was introduced because of the problems > discovered in November with RFC 5378. > > Ray > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From vincent.roca@inrialpes.fr Wed Mar 4 07:58:10 2009 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 C543928C3BA for ; Wed, 4 Mar 2009 07:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 sRRnzwcGLDxX for ; Wed, 4 Mar 2009 07:58:10 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 71C9328C3B9 for ; Wed, 4 Mar 2009 07:57:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,301,1233529200"; d="scan'208";a="25058510" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2009 16:58:19 +0100 Message-ID: <49AEA51A.5050107@inrialpes.fr> Date: Wed, 04 Mar 2009 16:58:18 +0100 From: Vincent Roca User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: fecframe@ietf.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [Fecframe] [Fwd: New Version Notification for draft-roca-fecframe-rs-00] 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, 04 Mar 2009 15:58:10 -0000 Hello, FYI, we just submitted an I-D describing the use of Reed-Solomon codes in the context of FecFrame (I should say "starting to describe" since several sections are still TBD) . http://www.ietf.org/internet-drafts/draft-roca-fecframe-rs-00.txt This document inherits from http://tools.ietf.org/html/draft-ietf-rmt-bb-fec-rs-05 https://datatracker.ietf.org/idtracker/draft-ietf-rmt-bb-fec-rs/ the code specifications. Regards, Vincent, Mathieu, Jerome, Amine, and Kazu. -------- Original Message -------- Subject: New Version Notification for draft-roca-fecframe-rs-00 Date: Wed, 4 Mar 2009 07:46:10 -0800 (PST) From: IETF I-D Submission Tool To: vincent.roca@inria.fr CC: kazuhisa@sfc.wide.ad.jp, jerome.lacan@isae.fr, mathieu.cunche@inria.fr, Amine.Bouabdallah@isae.fr A new version of I-D, draft-roca-fecframe-rs-00.txt has been successfuly submitted by Vincent Roca and posted to the IETF repository. Filename: draft-roca-fecframe-rs Revision: 00 Title: Reed-Solomon Forward Error Correction (FEC) Schemes for FECFRAME Creation_date: 2009-03-04 WG ID: Independent Submission Number_of_pages: 32 Abstract: This document describes four fully-specified FEC schemes for Reed- Solomon codes that can be used to protect media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of sparse parity check based FEC codes. However, this complexity remains compatible with software codecs. The first scheme is for Reed-Solomon codes over GF(2^^m), with m in {2..16}, a global FEC encoding and arbitrary packet flows. The second scheme is for Reed-Solomon codes over GF(2^^m), with m in {2..16}, the general case FEC encoding, and arbitrary packet flows. The third (resp. fourth) scheme is similar to the first (resp. second) scheme, with the exception that it is for a single sequenced flow. The IETF Secretariat. From vincent.roca@inrialpes.fr Thu Mar 5 01:32:10 2009 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 7468628C2DF for ; Thu, 5 Mar 2009 01:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 z81f2ZefRFlO for ; Thu, 5 Mar 2009 01:32:09 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 3B2FE28C132 for ; Thu, 5 Mar 2009 01:32:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,305,1233529200"; d="scan'208";a="36123931" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2009 10:32:36 +0100 Message-ID: <49AF9C34.7080605@inrialpes.fr> Date: Thu, 05 Mar 2009 10:32:36 +0100 From: Vincent Roca User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Watson, Mark" , fecframe@ietf.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Fecframe] IPR disclosures and fecframe activities 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, 05 Mar 2009 09:32:10 -0000 Mark, I searched the IETF IPR disclosure site about possible declarations related to the fecframe WG. There's *nothing* as of today, March 5th! https://datatracker.ietf.org/ipr/search/?option=wg_search&wg_search=fecframe I remember that DF made a disclosure in Dec. 2005 related to draft-watson-tsvwg-fec-sf-00: --- # 2005-12-13 ID # 674 https://datatracker.ietf.org/ipr/674/ --- No other IPR disclosure has been made during the past 3+ years AFAIK, whereas this I-D lays the fondations of the fecframe activities. Hence my questions: - Can your company update the IPR disclosure to clarify the fact it does concern the fecframe WG (if still relevant, of course)? - In particular, can your company provide the list of patents (disclosure # 674 only mentions "one or more patent claims" without any detail)? - Does your new company still commit to grant a "royalty-free license", as was the case in IPR disclosure # 674? Answers to the above questions would be of upmost importance, in particular to whoever implements the fecframe specifications, be it for commercial purposes or not. Thanks! Regards, Vincent From tme@multicasttech.com Fri Mar 6 06:51:16 2009 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 B4D6C3A69E7 for ; Fri, 6 Mar 2009 06:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 GAucTq3Ypyai for ; Fri, 6 Mar 2009 06:51:15 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 9FC523A6C86 for ; Fri, 6 Mar 2009 06:51:15 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14876110; Fri, 06 Mar 2009 09:51:06 -0500 Message-Id: From: Marshall Eubanks To: fecframe@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-3-345868077 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Mar 2009 09:51:45 -0500 References: <49b108a3.0405560a.2334.ffff9c9a@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: Roni Even Subject: [Fecframe] Fwd: Using the same CNAME for multiple hosts 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, 06 Mar 2009 14:51:17 -0000 --Apple-Mail-3-345868077 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I am sending this for Roni. Some mail weirdness is still going on. Marshall Begin forwarded message: > From: "Roni Even" > Date: March 6, 2009 6:26:22 AM EST > To: > Cc: "'Marshall Eubanks'" > Subject: Using the same CNAME for multiple hosts > > I am resending to fecframe. > > Hi Ali, > I had some offline discussion with Colin and Steve Casner. > All of us think that this approach is OK. RFC 3550 does not require > that the CNAME will be attached to a specific endpoint. > The relevant text is > " > If each application creates its CNAME independently, the resulting > CNAMEs may not be identical as would be required to provide a > binding > across multiple media tools belonging to one participant in a set > of > related RTP sessions. If cross-media binding is required, it may > be > necessary for the CNAME of each tool to be externally configured > with > the same value by a coordination tool. " > > This says that you will need a way to coordinate the CNAME and to > keep it for the relevant streams. > Example is a video with repair stream and the associated audio > stream should all have the same CNAME. > > Note that you may have a case when one host (FEC encoder) may use > multiple CNAMEs. > > The PROBLEM I see is with RFC 5109 mostly section 14.1 that explains > why you shall not multiplex both streams based on SSRC. > This was a change from RFC 2733. Maybe it will be good to review > this text in RFC 5109 and update the draft. > > Regards > Roni Even > --Apple-Mail-3-345868077 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I am sending this for Roni. = Some mail weirdness is still going = on. 

Marshall

Begin forwarded = message:

From: "Roni Even" <ron.even.tlv@gmail.com><= /div>
Date: March 6, 2009 6:26:22 AM = EST
Cc: "'Marshall Eubanks'" <tme@multicasttech.com>
Subject: = Using the same CNAME for multiple = hosts

=
I am resending to = fecframe.
 
Hi Ali,
I = had some offline discussion with Colin and Steve = Casner.
All of us think that this approach is OK. RFC = 3550 does not require that the CNAME will be attached to a specific = endpoint.
The relevant text is
If each application creates its CNAME = independently, the resulting
   CNAMEs may not = be identical as would be required to provide a = binding
   across multiple media tools = belonging to one participant in a set of
   necessary for the CNAME of = each tool to be externally configured with
 
This says that you will need = a way to coordinate the CNAME and to keep it for the relevant = streams.
Example is a video with repair stream and the = associated audio stream should all have the same = CNAME.
 
Note that you may have a = case when one host (FEC encoder) may use multiple = CNAMEs.
 
The PROBLEM I see is with = RFC 5109 mostly section 14.1 that explains why you shall not multiplex = both streams based on SSRC.
This was a change from RFC = 2733. Maybe it will be good to review this text in RFC 5109 and update = the draft.
 
Regards
To: Date: Fri, 6 Mar 2009 18:00:53 +0200 Message-ID: <49b148fa.0af5660a.08c9.4008@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01C99E85.8097A2B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmeTmD1x82vh+xLSlKyHx8YQWzDmw== Content-language: en-us X-Mailman-Approved-At: Fri, 06 Mar 2009 08:07:07 -0800 Subject: [Fecframe] Using the same CNAME for multiple hosts 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, 06 Mar 2009 16:01:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D1_01C99E85.8097A2B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am resending again to fecframe. Hi Ali, I had some offline discussion with Colin and Steve Casner. All of us think that this approach is OK. RFC 3550 does not require that the CNAME will be attached to a specific endpoint. The relevant text is " If each application creates its CNAME independently, the resulting CNAMEs may not be identical as would be required to provide a binding across multiple media tools belonging to one participant in a set of related RTP sessions. If cross-media binding is required, it may be necessary for the CNAME of each tool to be externally configured with the same value by a coordination tool. " This says that you will need a way to coordinate the CNAME and to keep it for the relevant streams. Example is a video with repair stream and the associated audio stream should all have the same CNAME. Note that you may have a case when one host (FEC encoder) may use multiple CNAMEs. The PROBLEM I see is with RFC 5109 mostly section 14.1 that explains why you shall not multiplex both streams based on SSRC. This was a change from RFC 2733. Maybe it will be good to review this text in RFC 5109 and update the draft. Regards Roni Even ------=_NextPart_000_00D1_01C99E85.8097A2B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am resending again to fecframe.

 

Hi Ali,

I had some offline discussion with Colin and = Steve Casner.

All of us think that this approach is OK. RFC = 3550 does not require that the CNAME will be attached to a specific = endpoint.

The relevant text is

"

If each application creates its CNAME = independently, the resulting

   CNAMEs may not be identical as = would be required to provide a binding

   across multiple media tools = belonging to one participant in a set of

   related RTP sessions.  If = cross-media binding is required, it may be

   necessary for the CNAME of each = tool to be externally configured with

   the same value by a coordination = tool. "

 

This says that you will need a way to coordinate = the CNAME and to keep it for the relevant streams.

Example is a video with repair stream and the = associated audio stream should all have the same CNAME.

 

Note that you may have a case when one host (FEC = encoder) may use multiple CNAMEs.

 

The PROBLEM I see is with RFC 5109 mostly = section 14.1 that explains why you shall not multiplex both streams based on = SSRC.

This was a change from RFC 2733. Maybe it will = be good to review this text in RFC 5109 and update the draft.

 

Regards

Roni Even

 

------=_NextPart_000_00D1_01C99E85.8097A2B0-- From root@core3.amsl.com Fri Mar 6 10:45:03 2009 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 778423A696C; Fri, 6 Mar 2009 10:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306184502.778423A696C@core3.amsl.com> Date: Fri, 6 Mar 2009 10:45:01 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-00.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: Fri, 06 Mar 2009 18:45: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 Filename : draft-ietf-fecframe-rtp-raptor-00.txt Pages : 19 Date : 2009-03-04 This document specifies an RTP Payload Format for Forward Error Correction 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-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06103757.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Mar 6 11:15:01 2009 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D8A083A6C67; Fri, 6 Mar 2009 11:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090306191501.D8A083A6C67@core3.amsl.com> Date: Fri, 6 Mar 2009 11:15:01 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-01.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: Fri, 06 Mar 2009 19:15:01 -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 Filename : draft-ietf-fecframe-rtp-raptor-01.txt Pages : 20 Date : 2009-03-06 This document specifies an RTP Payload Format for Forward Error Correction 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-01.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-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-06111134.I-D@ietf.org> --NextPart-- From watson@qualcomm.com Fri Mar 6 11:20:10 2009 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 04DD428C265; Fri, 6 Mar 2009 11:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=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 quu-iBKMnmsy; Fri, 6 Mar 2009 11:20:04 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 82A7728C2CC; Fri, 6 Mar 2009 11:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1236367235; x=1267903235; 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:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20" Internet-Drafts@ietf.org"=20, =0D=0A=20=20=20=20=20=20=20=20"i-d-announce@ietf.org"=20< i-d-announce@ietf.org>|CC:=20"fecframe@ietf.org"=20|Date:=20Fri,=206=20Mar=202009=2011:20:30=20 -0800|Subject:=20Re:=20[Fecframe]=20I-D=20Action:draft-ie tf-fecframe-rtp-raptor-01.txt|Thread-Topic:=20[Fecframe] =20I-D=20Action:draft-ietf-fecframe-rtp-raptor-01.txt |Thread-Index:=20Acmej/g4jvhe8YlbQG6cIK56iHr0kwAAKSVZ |Message-ID:=20 |In-Reply-To:=20<20090306191501.D8A083A6C67@core3.amsl.co m>|Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C5D6B77E2BBCAwatsonqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5545"=3B=20a=3D"16036379"; bh=NBdTps0hSSGfRt8BDvwWKHry1CcWA3Fz99yXxTbw38A=; b=mfh+Rx8Ojv65Jv0qbv8zHqrUlPrOGOxiNpIN1wCLPbfDXEbsYvjxtt5u 3qX7KL8MN9QnzWrD7ZDYHscUZt1h4obdsJOCDt71PKXQBo4nWeDga+Osq l1OG+nPQJR6DByoQw4DjgkBra9D3cECXjoIixNLXPibV1669vTaSl+g73 s=; X-IronPort-AV: E=McAfee;i="5300,2777,5545"; a="16036379" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2009 11:20:35 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n26JKYdF026337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2009 11:20:35 -0800 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n26JKYS9001705 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Mar 2009 11:20:34 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.336.0; Fri, 6 Mar 2009 11:20:34 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Fri, 6 Mar 2009 11:20:33 -0800 From: "Watson, Mark" To: "Internet-Drafts@ietf.org" , "i-d-announce@ietf.org" Date: Fri, 6 Mar 2009 11:20:30 -0800 Thread-Topic: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-01.txt Thread-Index: Acmej/g4jvhe8YlbQG6cIK56iHr0kwAAKSVZ Message-ID: In-Reply-To: <20090306191501.D8A083A6C67@core3.amsl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5D6B77E2BBCAwatsonqualcommcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 06 Mar 2009 11:48:43 -0800 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-01.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: Fri, 06 Mar 2009 19:21:42 -0000 --_000_C5D6B77E2BBCAwatsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, I submitted a -00 of this on Wednesday to meet the -00 deadline, but I had = not made any changes from the initial draft. The main change in this -01 draft is for the case when SDP is used to descr= ibe the session to require normal RTP Payload Format parameters to be used = to carry the 'FEC Object Transmission information', which is FEC parameters= which remain constant for the whole stream (specifically source block size= and symbol size). Previously these were carried in an 'opaque container' i= n a new SDP attribute defined for FECFRAME. The SDP attribute is what would= be used for the UDP case, but for the RTP case it is common (or possibly r= equired) practice (and also easier to understand) to use RTP Payload Format= parameters within the a=3Dfmpt line. This approach is based on the most commonly expressed sentiment (I can't sa= y more than that!) on the email thread cross-posted to AVT/FECFRAME which I= started as an action from the last FECFRAME meeting. I also removed some references to my former employer that I missed in the -= 00. ...Mark On 3/6/09 11:15 AM, "Internet-Drafts@ietf.org" w= rote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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 Filename : draft-ietf-fecframe-rtp-raptor-01.txt Pages : 20 Date : 2009-03-06 This document specifies an RTP Payload Format for Forward Error Correction 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-01.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. --_000_C5D6B77E2BBCAwatsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-01.txt</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>All,<BR> <BR> I submitted a –00 of this on Wednesday to meet the –00 deadline= , but I had not made any changes from the initial draft.<BR> <BR> The main change in this –01 draft is for the case when SDP is used to= describe the session to require normal RTP Payload Format parameters to be= used to carry the ‘FEC Object Transmission information’, which= is FEC parameters which remain constant for the whole stream (specifically= source block size and symbol size). Previously these were carried in an &#= 8216;opaque container’ in a new SDP attribute defined for FECFRAME. T= he SDP attribute is what would be used for the UDP case, but for the RTP ca= se it is common (or possibly required) practice (and also easier to underst= and) to use RTP Payload Format parameters within the a=3Dfmpt line. <BR> <BR> This approach is based on the most commonly expressed sentiment (I can̵= 7;t say more than that!) on the email thread cross-posted to AVT/FECFRAME w= hich I started as an action from the last FECFRAME meeting.<BR> <BR> I also removed some references to my former employer that I missed in the -= 00.<BR> <BR> ...Mark<BR> <BR> On 3/6/09 11:15 AM, "<a href=3D"Internet-Drafts@ietf.org">Internet-Dra= fts@ietf.org</a>" <<a href=3D"Internet-Drafts@ietf.org">Internet-Dr= afts@ietf.org</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>A New Internet-Draft is available from the = on-line Internet-Drafts directories.<BR> This draft is a work item of the FEC Framework Working Group of the IETF.<B= R> <BR> <BR>         Title    &nb= sp;      : RTP Payload Format for Raptor FEC<= BR>         Author(s)    = ;   : M. Watson<BR>         Filename    =     : draft-ietf-fecframe-rtp-raptor-01.txt<BR>         Pages    &nb= sp;      : 20<BR>         Date    &nbs= p;       : 2009-03-06<BR> <BR> This document specifies an RTP Payload Format for Forward Error<BR> Correction repair data produced by the Raptor FEC Schemes.  Raptor<BR> FEC Schemes are specified for use with the IETF FEC Framework which<BR> supports transport of repair data over both UDP and RTP.  This<BR> document specifies the Payload Format which is required for the use<BR> of RTP to carry Raptor repair flows.<BR> <BR> A URL for this Internet-Draft is:<BR> <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-rapt= or-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-rapt= or-01.txt</a><BR> <BR> Internet-Drafts are also available by anonymous FTP at:<BR> <a href=3D"ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet= -drafts/</a><BR> <BR> Below is the data which will enable a MIME compliant mail reader<BR> implementation to automatically retrieve the ASCII version of the<BR> Internet-Draft.<BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C5D6B77E2BBCAwatsonqualcommcom_-- From abegen@cisco.com Sat Mar 7 20:18:30 2009 Return-Path: <abegen@cisco.com> X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF443A6A69; Sat, 7 Mar 2009 20:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9k2uPcpLZDkm; Sat, 7 Mar 2009 20:18:29 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A87B93A6A12; Sat, 7 Mar 2009 20:18:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,321,1233532800"; d="scan'208";a="152443384" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2009 04:19:02 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n284J2ta003540; Sat, 7 Mar 2009 20:19:02 -0800 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.13.8) with ESMTP id n284J2xT007412; Sun, 8 Mar 2009 04:19:02 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Mar 2009 20:19:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Mar 2009 20:18:43 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408CDA020@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49af986b.0437560a.5b42.18d6@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Using the same CNAME for multiple hosts Thread-Index: AcmbgQNH99oNfu0USg+/0JnbJ2MZhAB71Q+QAI0BJgA= References: <04CAD96D4C5A3D48B1919248A8FE0D5408C4EB46@xmb-sjc-215.amer.cisco.com> <49af986b.0437560a.5b42.18d6@mx.google.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Roni Even" <ron.even.tlv@gmail.com>, "IETF AVT WG" <avt@ietf.org> X-OriginalArrivalTime: 08 Mar 2009 04:19:02.0088 (UTC) FILETIME=[02B92C80:01C99FA5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4305; t=1236485942; x=1237349942; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20<abegen@cisco. com> |Subject:=20RE=3A=20[AVT]=20Using=20the=20same=20CNAME=20fo r=20multiple=20hosts |Sender:=20; bh=8vT19GRcDXr+z49t4Y9fYxfxdsj0aRXRl4loakM0l6U=; b=cABsvZGjDGycTfGwtOumI0nL2qWauCtVb8081X9W8QgmEubCdhWbciKgc0 sG835G+trXybH654rx1Ws9Q0QuXMsCKhecNTunzCgn96ghlQnpuiQ3seCJvU HTIxGRAGZj; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] [AVT] Using the same CNAME for multiple hosts X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 08 Mar 2009 04:18:30 -0000 Hi Roni, Thanks for your email. We will take this into consideration. Regarding 5109, I agree with your comments. I am not sure why SSRC multiplexing was not allowed in 5109. If anybody knows the history, that might be useful. If desired by the WG, we can make a quick update on 5109. BR, -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 > Sent: Thursday, March 05, 2009 1:16 AM > To: Ali C. Begen (abegen); 'IETF AVT WG' > Cc: fecframe@ietf.org > Subject: RE: [AVT] Using the same CNAME for multiple hosts >=20 > Hi Ali, > I had some offline discussion with Colin and Steve Casner. > All of us think that this approach is OK. RFC 3550 does not=20 > require that the > CNAME will be attached to a specific endpoint. > The relevant text is > " > If each application creates its CNAME independently, the resulting > CNAMEs may not be identical as would be required to=20 > provide a binding > across multiple media tools belonging to one participant=20 > in a set of > related RTP sessions. If cross-media binding is required,=20 > it may be > necessary for the CNAME of each tool to be externally=20 > configured with > the same value by a coordination tool. " >=20 > This says that you will need a way to coordinate the CNAME=20 > and to keep it > for the relevant streams. > Example is a video with repair stream and the associated=20 > audio stream should > all have the same CNAME. >=20 > Note that you may have a case when one host (FEC encoder) may=20 > use multiple > CNAMEs. >=20 > The PROBLEM I see is with RFC 5109 mostly section 14.1 that=20 > explains why you > shall not multiplex both streams based on SSRC. > This was a change from RFC 2733. Maybe it will be good to=20 > review this text > in RFC 5109 and update the draft. >=20 > Regards > Roni Even >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Ali C. > Begen (abegen) > Sent: Monday, March 02, 2009 11:51 PM > To: IETF AVT WG > Cc: fecframe@ietf.org > Subject: [AVT] Using the same CNAME for multiple hosts >=20 > (Copying fecframe as well) >=20 > Magnus brought up a concern in the last fecframe session regarding the > use of the same CNAME by multiple hosts. >=20 > Here is a scenario: >=20 > RTP FEC > SOURCE ---> ENCODER ---> FEC Stream ---> RTP > | Receiver > +--------------Source Stream --> (RR) >=20 > This is a simple scenario, in more complex systems, there could be > different FEC encoders producing different FEC streams from the same > source stream. In other scenarios, multiple RTP source=20 > streams could be > combined and fed together to an FEC encoder. RFC 4756 has the > source/repair grouping semantics for SDP: a=3Dgroup:fec s1 r1 >=20 > On the RTP side, RFC 2733 used the same SSRC value for both source and > repair streams for easier association. Later, RFC 5109 did the same > thing. >=20 > Now, following the rules of RTP and based on the suggestions from > various individuals, we would like to use distinct (random)=20 > SSRC values > for the source and repair streams. This allows the sender to multiplex > source and repair streams on a single port (good for easier NAT > traversal, etc). We propose to use the CNAME field for association > between the repair and source streams. This provides us greater > flexibility. >=20 > This approach requires the use of the same CNAME by different hosts (a > common CNAME could be produced based on an algorithm).=20 > However, a naive > RTP device MAY assume that data from different flows with the=20 > same CNAME > come from the same host. Since this is not the case in our scenario, > such devices will break in our approach! >=20 > Does anybody see a potential problem here? Any objections to our > proposal? If so, please speak up. We have multiple drafts using this > approach and we need to hear objections (if any) before we complete > those drafts. >=20 > Thanks. > -acbegen >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 From root@core3.amsl.com Sat Mar 7 20:30:01 2009 Return-Path: <root@core3.amsl.com> X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6AC123A6AF3; Sat, 7 Mar 2009 20:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090308043001.6AC123A6AF3@core3.amsl.com> Date: Sat, 7 Mar 2009 20:30:01 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-interleaved-fec-scheme-02.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 08 Mar 2009 04:30:01 -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 1-D Interleaved Parity FEC Author(s) : A. Begen Filename : draft-ietf-fecframe-interleaved-fec-scheme-02.txt Pages : 30 Date : 2009-03-07 This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used as a part of the DVB Application- layer FEC Specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-02.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-interleaved-fec-scheme-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07201917.I-D@ietf.org> --NextPart-- From abegen@cisco.com Sat Mar 7 20:33:11 2009 Return-Path: <abegen@cisco.com> X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783413A6A75 for <fecframe@core3.amsl.com>; Sat, 7 Mar 2009 20:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 203GzlJfcqCJ for <fecframe@core3.amsl.com>; Sat, 7 Mar 2009 20:33:10 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8B6703A67A1 for <fecframe@ietf.org>; Sat, 7 Mar 2009 20:33:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,322,1233532800"; d="scan'208";a="140406522" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2009 04:33:39 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n284XdnN013544 for <fecframe@ietf.org>; Sat, 7 Mar 2009 20:33:39 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n284Xd09010482 for <fecframe@ietf.org>; Sun, 8 Mar 2009 04:33:39 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.1830); Sat, 7 Mar 2009 20:33:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Mar 2009 20:33:36 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408CDA028@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-02 Thread-Index: AcmfpSdjcH32KchxS0GreJXlzpU+6wAAFf6A From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: <fecframe@ietf.org> X-OriginalArrivalTime: 08 Mar 2009 04:33:38.0857 (UTC) FILETIME=[0D518190:01C99FA7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1970; t=1236486819; x=1237350819; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20<abegen@cisco. com> |Subject:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-ietf-fecframe-interleaved-fec-scheme-02=20 |Sender:=20; bh=1o1zNK2i1Fj2Z6UGhl/Hyyoz1Rth90v8CQJP8qKLvjI=; b=X8LGvHm3WNYqBq87shNYu7pGp3SKpJNmbwaCvXkA6QzNMprRUlL+E5IvzE IdLy/gOyOSYs/+Lim676JjkFIG6LJierXBtCohJw7737dzEiDZ/ueGJg8QCc Y7muULyiEb; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 08 Mar 2009 04:33:11 -0000 Hi everyone, I completed the missing sections in this spec. With the informational DVB AL-FEC draft (updated a short time ago), I believe these are ready for WGLC. Note that these two documents are not dependent on the framework draft, thus we can move forward with WGLC. If agreed, a joint FECFRAME/AVT WGLC should take place. I'd appreciate if you could review both documents. Here are the links. http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec- scheme-02.txt http://tools.ietf.org/id/draft-ietf-fecframe-dvb-al-fec-01.txt I am planning to give a quick update on both drafts in the fecframe session. -acbegen =20 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Saturday, March 07, 2009 8:19 PM To: Ali C. Begen (abegen) Subject: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-02=20 A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-02.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. Filename: draft-ietf-fecframe-interleaved-fec-scheme Revision: 02 Title: RTP Payload Format for 1-D Interleaved Parity FEC Creation_date: 2009-03-07 WG ID: fecframe Number_of_pages: 30 Abstract: This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used as a part of the DVB Application- layer FEC Specification. =20 The IETF Secretariat. From root@core3.amsl.com Sat Mar 7 21:00:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 795053A6B7D; Sat, 7 Mar 2009 21:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090308050002.795053A6B7D@core3.amsl.com> Date: Sat, 7 Mar 2009 21:00:02 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-pseudo-cdp-01.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 08 Mar 2009 05: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 : Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework Author(s) : U. Kozat, A. Begen Filename : draft-ietf-fecframe-pseudo-cdp-01.txt Pages : 12 Date : 2009-03-07 This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework document and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-pseudo-cdp-01.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-pseudo-cdp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07204844.I-D@ietf.org> --NextPart-- From abegen@cisco.com Sat Mar 7 21:39:33 2009 Return-Path: <abegen@cisco.com> X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3E13A6A2F for <fecframe@core3.amsl.com>; Sat, 7 Mar 2009 21:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1HegF7qNUIQP for <fecframe@core3.amsl.com>; Sat, 7 Mar 2009 21:39:32 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CED243A6A1A for <fecframe@ietf.org>; Sat, 7 Mar 2009 21:39:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,323,1233532800"; d="scan'208";a="138998392" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2009 05:39:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n285drg4009717; Sat, 7 Mar 2009 21:39:53 -0800 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.13.8) with ESMTP id n285drGs008880; Sun, 8 Mar 2009 05:39:53 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Mar 2009 21:39:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 7 Mar 2009 21:38:18 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408CDA029@xmb-sjc-215.amer.cisco.com> In-Reply-To: <0C15A3B2-36AD-4F7D-884E-A84463A59D62@multicasttech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Reminder and Call for Submissions Thread-Index: AcmZL57Li8khAnsDSViYU9L4+fiqwwGfuxdA References: <0C15A3B2-36AD-4F7D-884E-A84463A59D62@multicasttech.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Marshall Eubanks" <tme@multicasttech.com>, <fecframe@ietf.org> X-OriginalArrivalTime: 08 Mar 2009 05:39:53.0288 (UTC) FILETIME=[4E438C80:01C99FB0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1943; t=1236490793; x=1237354793; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20<abegen@cisco. com> |Subject:=20RE=3A=20[Fecframe]=20Reminder=20and=20Call=20fo r=20Submissions |Sender:=20; bh=uA25P4k2tCxAwOD06VzP8p5uSjZhXSpshZnGCqhpZ5A=; b=Hz7MvJqeW0jC+vSzs1GDEnW73nEy8A+nzobzQKRu106syNCByqrWE3w2zj bTmTCdtmVr5/g62N9O9qphc3VIs0eUUTKQ2fZVU9gGug1nZQeC06CK+Eft0Z uyxmk/ug6r; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Fecframe] Reminder and Call for Submissions X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 08 Mar 2009 05:39:34 -0000 Hi Marshall, I need 15 mins for a quick update on: - draft-ietf-fecframe-dvb-al-fec-01.txt - draft-ietf-fecframe-interleaved-fec-scheme-02.txt=20 My goal is to finalize these drafts soon and go for an WGLC (See my earlier email sent an hour ago). As you know the 1D/2D draft is also pretty much finished. But, I am still holding on the draft in the hopes that VSF/SMPTE folks will provide feedback and we can produce a spec that will satisfy their requirements. I believe it is a good idea if you could present the latest from the VSF/SMPTE side regarding the current status of RFC 2733/SMPTE 2022-1 issues and more importantly, the work-in-progress in VSF. In particular, given that we will likely to have available time in our session, I believe we should discuss the design issues about the FEC for VBR sources. That is a tricky issue. BR, -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Marshall Eubanks > Sent: Friday, February 27, 2009 3:04 PM > To: fecframe@ietf.org > Subject: [Fecframe] Reminder and Call for Submissions >=20 > Please remember these deadlines : >=20 > March 4, 2009 Wednesday - Internet Draft Cut-off for initial=20 > document =20 > (-00) submission by 17:00 PST (01:00 Tuesday, March 5=20 > UTC/GMT), upload =20 > using IETF ID Submission Tool. > March 9, 2009 Monday - Internet Draft final submission cut-off by =20 > 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. > March 11, 2009 Wednesday - Draft Working Group agendas due by 17:00 =20 > PDT (24:00 UTC/GMT), upload using IETF Meeting Materials Management =20 > Tool. >=20 > Also, please send us your requests to speak. >=20 > Regards > Marshall >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From gjshep@gmail.com Mon Mar 9 08:54:51 2009 Return-Path: <gjshep@gmail.com> X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CABF3A6C34 for <fecframe@core3.amsl.com>; Mon, 9 Mar 2009 08:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 Kd3CsgrMoWBp for <fecframe@core3.amsl.com>; Mon, 9 Mar 2009 08:54:50 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id E60413A6B3B for <fecframe@ietf.org>; Mon, 9 Mar 2009 08:54:49 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so1183598ywh.49 for <fecframe@ietf.org>; Mon, 09 Mar 2009 08:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=TKEa0DoSb9A3kZmGmXz+KRg+SfhX52ni9lc2g+BrqOw=; b=iLRV0V5mv8VO3y+Ymj2FcT1obfF3x0cblHB5b6Vjpsqvp5DjX1MnmpSg1n6uexJz4p 9v2inIYZX08fgnwHxNP+x74k3/mwBGYVJ2+LP4teSJkyaIwZRi7bR+gvo76jopwG5XiJ VVmA7baR2NPfyxqQ2ZUh/mLMdIng8nNhJ1b4w= 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 :content-transfer-encoding; b=DwGGSFw7crbEtfRp/y5MSMIpTAKWp62+3lbr0XGy6dO1JyQ8zH+fXtInzHc2hvoZ1b N47xHDMwXDGqT5nA36zYXmXoKbQxx3eoYq52wxeVkj/ctLvRZYHuOGwKzwWYCw3czzKu Z4DkSLZVlyFSQNd6kYWMjxcCwK55rPGNbLqx8= MIME-Version: 1.0 Received: by 10.231.12.12 with SMTP id v12mr1465218ibv.4.1236614123404; Mon, 09 Mar 2009 08:55:23 -0700 (PDT) Date: Mon, 9 Mar 2009 07:55:23 -0800 Message-ID: <38c19b540903090855j53db8fe4uab1111fff193e7e8@mail.gmail.com> From: Greg Shepherd <gjshep@gmail.com> To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Fecframe] Agenda X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 09 Mar 2009 15:54:51 -0000 We have a couple of updated submissions so I'm assuming for now those will be presented in SF. If there is anyone else with something to present please send Marshal and I the subject, relevant doc, and the amount of time you would like. We need to publish the agenda on the 11th so please send me your items ASAP. Thanks, Greg From abegen@cisco.com Sun Mar 29 21:20:33 2009 Return-Path: <abegen@cisco.com> X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0163A69BB for <fecframe@core3.amsl.com>; Sun, 29 Mar 2009 21:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3-wJ9fdgzx+P for <fecframe@core3.amsl.com>; Sun, 29 Mar 2009 21:20:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D522F3A6833 for <fecframe@ietf.org>; Sun, 29 Mar 2009 21:20:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,444,1233532800"; d="scan'208";a="163484809" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Mar 2009 04:21:30 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2U4LUnx009736 for <fecframe@ietf.org>; Sun, 29 Mar 2009 21:21:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n2U4LU1u020464 for <fecframe@ietf.org>; Mon, 30 Mar 2009 04:21:30 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Mar 2009 21:21: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Mar 2009 21:21:28 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5408FAFDE7@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC request on draft-ietf-fecframe-interleaved-fec-scheme Thread-Index: Acmw7v8riVcMMSSXRjSxaOIHgbz3jw== From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: <fecframe@ietf.org> X-OriginalArrivalTime: 30 Mar 2009 04:21:30.0555 (UTC) FILETIME=[004DF0B0:01C9B0EF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=418; t=1238386890; x=1239250890; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20<abegen@cisco. com> |Subject:=20WGLC=20request=20on=20draft-ietf-fecframe-inter leaved-fec-scheme |Sender:=20; bh=z/Nk+rXpgraMogWhkeYSQ2YcrFNEw+7rnDGshCuh6kI=; b=LxqoDKPlNVZsFx9WhDHoKa7cV/gX3Q4zjTQCOsrlHCDC3nEv78kuqPXa4M KMvBlt3hmjyX7O4jYD0aLXZeFsH0AIh9tiBGA57Zdik1TkmA/Zp87agjk3/K nWgYCv9akHEm6eMeEsonNgXnNF/nLV/gtFioETst9A23YvaGMCgBw=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Fecframe] WGLC request on draft-ietf-fecframe-interleaved-fec-scheme X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 30 Mar 2009 04:20:33 -0000 This is regarding the draft-ietf-fecframe-interleaved-fec-scheme draft. Per Mark's request, I double checked the document to make sure that = there was no reference to the FEC framework, an implicit or explicit = one. As decided during the session, we will WGLC the framework draft. But, = this draft does not depend on the framework. So, I would like to request = a WGLC on this one, too. BR, -acbegen