From fecframe-bounces@ietf.org Mon Sep 8 08:55:26 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFDD3A69F4; Mon, 8 Sep 2008 08:55:26 -0700 (PDT) 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 9AC523A6817 for ; Mon, 8 Sep 2008 08:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE8RODtzRn-h for ; Mon, 8 Sep 2008 08:55:25 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by core3.amsl.com (Postfix) with ESMTP id C7DB43A6A44 for ; Mon, 8 Sep 2008 08:55:24 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id s16so275147wxc.31 for ; Mon, 08 Sep 2008 08:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=H1Xrb06nZ/IpczJBbsOacQlTPATjD7T5MOYH4NC6/2k=; b=HzURt6FLocbQA0BNlYQ/gJf+ptZRG7PnfKIMj7Jc+f7KWmu24dBq5V1Acg9MN7LKx0 S6FjCKySohiBnOT1iHllGH5j3RiNhN3s877airaqeHUzNRvJIr3H5AI05Mm5PmqH+V01 QvB/23eQfUkvcTf/A6CNyr3te12c+nTQavDuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=pdOjroJ0BJjjrkXOW2liC9dPF5KoLKzvBPKjIBCTJDRAmcmDTTjlFJj9ZW+9KF0RJA WtnBCqRF9Hq80GYR3w6ZkQSBoEetSk8YgkbK32AU3u3H5YteYBPF9mJo2r2o15+XQgOX v0vROhYPKQXXQFirCbPzX1SWG3DKQlRcdVhn4= Received: by 10.100.171.10 with SMTP id t10mr15702086ane.123.1220889321895; Mon, 08 Sep 2008 08:55:21 -0700 (PDT) Received: by 10.100.135.12 with HTTP; Mon, 8 Sep 2008 08:55:21 -0700 (PDT) Message-ID: <38c19b540809080855m3985efcfk121e3524090b01ca@mail.gmail.com> Date: Mon, 8 Sep 2008 08:55:21 -0700 From: "Greg Shepherd" To: fecframe@ietf.org, iesg-secretary@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [Fecframe] Interim Meeting Announcement 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org We will be having a FECFrame working group interim meeting next month in California, San Francisco bay area. Exact location TBD. The agenda will be assembled and sent in a follow-up message. Starting 1200 Oct 20 - 1700 Oct 22 Calling for hosts! As I said before, getting a conference room at the Cisco San Jose campus is always a fall-back option, but I want to open this up first to anyone would like to host the meeting. I'd expect no more than 6-10 in attendance, but we will require dial-in attendance for those who can't travel. Thanks, Greg _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 8 13:08:34 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651333A6A6D; Mon, 8 Sep 2008 13:08:34 -0700 (PDT) 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 53E883A694F; Mon, 8 Sep 2008 13:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 wNaXwUd33mQl; Mon, 8 Sep 2008 13:08:32 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 467C43A6A33; Mon, 8 Sep 2008 13:08:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,360,1217808000"; d="scan'208";a="20116480" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Sep 2008 20:08:34 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m88K8YSV005140; Mon, 8 Sep 2008 16:08:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m88K8YoL023004; Mon, 8 Sep 2008 20:08:34 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 16:08:34 -0400 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Sep 2008 16:09:10 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6061B3DA5@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <38c19b540809080855m3985efcfk121e3524090b01ca@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Interim Meeting Announcement Thread-Index: AckRy24BcbJqWb1wRlymBIWZ/+izmAAIyiRg References: <38c19b540809080855m3985efcfk121e3524090b01ca@mail.gmail.com> From: "Rajiv Asati (rajiva)" To: "Greg Shepherd" , , X-OriginalArrivalTime: 08 Sep 2008 20:08:34.0140 (UTC) FILETIME=[ABF1A9C0:01C911EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1218; t=1220904514; x=1221768514; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20(rajiva)=22=20 |Subject:=20RE=3A=20[Fecframe]=20Interim=20Meeting=20Announ cement |Sender:=20 |To:=20=22Greg=20Shepherd=22=20,=20,=0A=20=20=20=20=20=20=20=20; bh=r5jUx/E770QXXIIasMSRiPd+CkohhBbDdAWXsiAsUNA=; b=GwqPXVU291QEstiOMi6qRGY7dxp12NRFP/0JCoHaaYrzD7G5QY+2k/Qixa /UQVIEnfiOtYa3A1F82YcQFOVNHvqmGCBQDdZnblvZus7ur8IasBVcGeTah2 HpCZ/FnBeR; Authentication-Results: rtp-dkim-2; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Fecframe] Interim Meeting Announcement 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Greg, If the place of the meeting can be decided ASAP, then it would help us tremendously to decide whether we should fly into SJC or SFO. Thanks. Cheers, Rajiv > -----Original Message----- > From: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd > Sent: Monday, September 08, 2008 11:55 AM > To: fecframe@ietf.org; iesg-secretary@ietf.org > Subject: [Fecframe] Interim Meeting Announcement > > We will be having a FECFrame working group interim meeting next month > in California, San Francisco bay area. Exact location TBD. The agenda > will be assembled and sent in a follow-up message. > > Starting 1200 Oct 20 - 1700 Oct 22 > > Calling for hosts! As I said before, getting a conference room at the > Cisco San Jose campus is always a fall-back option, but I want to open > this up first to anyone would like to host the meeting. I'd expect no > more than 6-10 in attendance, but we will require dial-in attendance > for those who can't travel. > > Thanks, > Greg > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 8 13:09:42 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7A93A681F; Mon, 8 Sep 2008 13:09:42 -0700 (PDT) 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 8C0303A681F; Mon, 8 Sep 2008 13:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.091 X-Spam-Level: X-Spam-Status: No, score=-103.091 tagged_above=-999 required=5 tests=[AWL=0.508, 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 WkF1XJ4n9wjq; Mon, 8 Sep 2008 13:09:40 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 922CC3A6359; Mon, 8 Sep 2008 13:09:40 -0700 (PDT) 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 12886337; Mon, 08 Sep 2008 16:09:43 -0400 Message-Id: From: Marshall Eubanks To: "Rajiv Asati (rajiva)" In-Reply-To: <15B86BC7352F864BB53A47B540C089B6061B3DA5@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 8 Sep 2008 16:09:40 -0400 References: <38c19b540809080855m3985efcfk121e3524090b01ca@mail.gmail.com> <15B86BC7352F864BB53A47B540C089B6061B3DA5@xmb-rtp-20b.amer.cisco.com> X-Mailer: Apple Mail (2.926) Cc: iesg-secretary@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] Interim Meeting Announcement 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Our assumption is that this meeting will be in the SJC zone. Of course, until the venue is settled, this may change. Regards Marshall On Sep 8, 2008, at 4:09 PM, Rajiv Asati (rajiva) wrote: > Hi Greg, > > If the place of the meeting can be decided ASAP, then it would help us > tremendously to decide whether we should fly into SJC or SFO. > > Thanks. > > Cheers, > Rajiv > >> -----Original Message----- >> From: fecframe-bounces@ietf.org >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd >> Sent: Monday, September 08, 2008 11:55 AM >> To: fecframe@ietf.org; iesg-secretary@ietf.org >> Subject: [Fecframe] Interim Meeting Announcement >> >> We will be having a FECFrame working group interim meeting next month >> in California, San Francisco bay area. Exact location TBD. The agenda >> will be assembled and sent in a follow-up message. >> >> Starting 1200 Oct 20 - 1700 Oct 22 >> >> Calling for hosts! As I said before, getting a conference room at the >> Cisco San Jose campus is always a fall-back option, but I want to >> open >> this up first to anyone would like to host the meeting. I'd expect no >> more than 6-10 in attendance, but we will require dial-in attendance >> for those who can't travel. >> >> Thanks, >> Greg >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 8 13:55:51 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAD83A6971; Mon, 8 Sep 2008 13:55:51 -0700 (PDT) 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 AF7C53A6971 for ; Mon, 8 Sep 2008 13:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 3YCyLX6nRUsk for ; Mon, 8 Sep 2008 13:55:49 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by core3.amsl.com (Postfix) with ESMTP id 9A8B63A687C for ; Mon, 8 Sep 2008 13:55:49 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id s16so383903wxc.31 for ; Mon, 08 Sep 2008 13:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gP/nwlD8ehACdGTwNMCmy0/Vn1AcxdkPvGjdUJ4tnrE=; b=pQ/7YktK9TtZaxvHRSBweq1VJSyjceU4EvgAHahzbpvPGlkNXaV3U3aV6cV4phhYTW 1B9NfrbSE8qlgMXoeDKmzJHGjKM2IKKV/w8T0LSrI3ynp5g4/SfC3RGL3MCu4o6+zg+s SismUUF86zlcMAI6PlH70B8q2oBLwKJzI/Fbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IHtmALRJqMV6TinhQ9RDXnIOtDxY/5w1D/HdAfvZlbbt5zM0r71uu+SunnnmLS9kBW wFrQj0GREMquwDwqxv8gaCvqe2oxjNlScWN8HTLAUb5c2Kc9ZEEd8+dCyRaHrbLETiCJ o3Pf+7eGairbQLnJNA+dBbyS6tZ5+FGOYxK90= Received: by 10.100.47.13 with SMTP id u13mr16273361anu.56.1220907352316; Mon, 08 Sep 2008 13:55:52 -0700 (PDT) Received: by 10.100.135.12 with HTTP; Mon, 8 Sep 2008 13:55:52 -0700 (PDT) Message-ID: <38c19b540809081355o743d9426pd5c4b5feb404f4bb@mail.gmail.com> Date: Mon, 8 Sep 2008 13:55:52 -0700 From: "Greg Shepherd" To: "Marshall Eubanks" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <38c19b540809080855m3985efcfk121e3524090b01ca@mail.gmail.com> <15B86BC7352F864BB53A47B540C089B6061B3DA5@xmb-rtp-20b.amer.cisco.com> Cc: iesg-secretary@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] Interim Meeting Announcement 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Rajiv, Let's at least give this notice 48 hrs for the others around the world to consider and respond. I'm already booking a meeting room in SJ now as the fall-back to ensure we do in fact have a fall-back. I believe the other soft offer of hosting was also in the south bay. But for me, my only direct option is a flight into SFO and a drive down so I don't fully understand the difference. ;-) Cheers, Greg On Mon, Sep 8, 2008 at 1:09 PM, Marshall Eubanks wrote: > Our assumption is that this meeting will be in the SJC zone. > > Of course, until the venue is settled, this may change. > > Regards > Marshall > > On Sep 8, 2008, at 4:09 PM, Rajiv Asati (rajiva) wrote: > >> Hi Greg, >> >> If the place of the meeting can be decided ASAP, then it would help us >> tremendously to decide whether we should fly into SJC or SFO. >> >> Thanks. >> >> Cheers, >> Rajiv >> >>> -----Original Message----- >>> From: fecframe-bounces@ietf.org >>> [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd >>> Sent: Monday, September 08, 2008 11:55 AM >>> To: fecframe@ietf.org; iesg-secretary@ietf.org >>> Subject: [Fecframe] Interim Meeting Announcement >>> >>> We will be having a FECFrame working group interim meeting next month >>> in California, San Francisco bay area. Exact location TBD. The agenda >>> will be assembled and sent in a follow-up message. >>> >>> Starting 1200 Oct 20 - 1700 Oct 22 >>> >>> Calling for hosts! As I said before, getting a conference room at the >>> Cisco San Jose campus is always a fall-back option, but I want to open >>> this up first to anyone would like to host the meeting. I'd expect no >>> more than 6-10 in attendance, but we will require dial-in attendance >>> for those who can't travel. >>> >>> Thanks, >>> Greg >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 8 14:21:25 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360BE3A6AB1; Mon, 8 Sep 2008 14:21:25 -0700 (PDT) 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 815413A6A96; Mon, 8 Sep 2008 14:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 xNNRAZhRj67k; Mon, 8 Sep 2008 14:21:22 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 114FB3A6AB1; Mon, 8 Sep 2008 14:21:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,360,1217808000"; d="scan'208";a="20101032" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Sep 2008 21:21:25 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m88LLPIx018680; Mon, 8 Sep 2008 17:21:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m88LLPPH021082; Mon, 8 Sep 2008 21:21:25 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 17:21:25 -0400 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Sep 2008 17:21:15 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B6061B3E43@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <38c19b540809081355o743d9426pd5c4b5feb404f4bb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Interim Meeting Announcement Thread-Index: AckR9UlYRWEOmjnyTEqNHVRRYwSwuQAAwQDA References: <38c19b540809080855m3985efcfk121e3524090b01ca@mail.gmail.com> <15B86BC7352F864BB53A47B540C089B6061B3DA5@xmb-rtp-20b.amer.cisco.com> <38c19b540809081355o743d9426pd5c4b5feb404f4bb@mail.gmail.com> From: "Rajiv Asati (rajiva)" To: "Greg Shepherd" , "Marshall Eubanks" X-OriginalArrivalTime: 08 Sep 2008 21:21:25.0164 (UTC) FILETIME=[D946FEC0:01C911F8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3107; t=1220908885; x=1221772885; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rajiva@cisco.com; z=From:=20=22Rajiv=20Asati=20(rajiva)=22=20 |Subject:=20RE=3A=20[Fecframe]=20Interim=20Meeting=20Announ cement |Sender:=20 |To:=20=22Greg=20Shepherd=22=20,=0A=20=20 =20=20=20=20=20=20=22Marshall=20Eubanks=22=20; bh=7GkgAZAzXv/C+9L6wwPSeEv4yuSluBjp+rFNiVs2uAo=; b=eE4vIJzYAMymj4ftVEUiwMPiZeBIqNmvrglbRJ1dUaoMYU3dFjCeqCEQfh HrZL5ijwYSNLINeqodTmhYSjupuyFapDG2drwBTxEUFaWIZLBNF9sUsWcXQS sX/Xoi1Ll2; Authentication-Results: rtp-dkim-1; header.From=rajiva@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: iesg-secretary@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] Interim Meeting Announcement 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org > Let's at least give this notice 48 hrs for the others around the world > to consider and respond. Indeed. > my only direct option is a flight into SFO and a drive down so I don't > fully understand the difference. ;-) There are many differences for me to fly out of RDU - - Arrival time difference (10:30am vs 12:30pm) - Airfare difference (~$150) - Driving time (from the airport) difference (an hour vs. 10 mins) Cheers, Rajiv > -----Original Message----- > From: Greg Shepherd [mailto:gjshep@gmail.com] > Sent: Monday, September 08, 2008 4:56 PM > To: Marshall Eubanks > Cc: Rajiv Asati (rajiva); fecframe@ietf.org; iesg-secretary@ietf.org > Subject: Re: [Fecframe] Interim Meeting Announcement > > Rajiv, > > Let's at least give this notice 48 hrs for the others around the world > to consider and respond. I'm already booking a meeting room in SJ now > as the fall-back to ensure we do in fact have a fall-back. I believe > the other soft offer of hosting was also in the south bay. But for me, > my only direct option is a flight into SFO and a drive down so I don't > fully understand the difference. ;-) > > Cheers, > Greg > > > On Mon, Sep 8, 2008 at 1:09 PM, Marshall Eubanks > wrote: > > Our assumption is that this meeting will be in the SJC zone. > > > > Of course, until the venue is settled, this may change. > > > > Regards > > Marshall > > > > On Sep 8, 2008, at 4:09 PM, Rajiv Asati (rajiva) wrote: > > > >> Hi Greg, > >> > >> If the place of the meeting can be decided ASAP, then it > would help us > >> tremendously to decide whether we should fly into SJC or SFO. > >> > >> Thanks. > >> > >> Cheers, > >> Rajiv > >> > >>> -----Original Message----- > >>> From: fecframe-bounces@ietf.org > >>> [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd > >>> Sent: Monday, September 08, 2008 11:55 AM > >>> To: fecframe@ietf.org; iesg-secretary@ietf.org > >>> Subject: [Fecframe] Interim Meeting Announcement > >>> > >>> We will be having a FECFrame working group interim > meeting next month > >>> in California, San Francisco bay area. Exact location > TBD. The agenda > >>> will be assembled and sent in a follow-up message. > >>> > >>> Starting 1200 Oct 20 - 1700 Oct 22 > >>> > >>> Calling for hosts! As I said before, getting a conference > room at the > >>> Cisco San Jose campus is always a fall-back option, but I > want to open > >>> this up first to anyone would like to host the meeting. > I'd expect no > >>> more than 6-10 in attendance, but we will require dial-in > attendance > >>> for those who can't travel. > >>> > >>> Thanks, > >>> Greg > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >>> > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe > > > > > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 8 19:06:58 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC3F3A6ADC; Mon, 8 Sep 2008 19:06:58 -0700 (PDT) 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 ABCB23A6A5A for ; Mon, 8 Sep 2008 19:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wsw3dh878fT5 for ; Mon, 8 Sep 2008 19:06:56 -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 0DA1C3A6ADC for ; Mon, 8 Sep 2008 19:06:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,362,1217808000"; d="scan'208";a="100356289" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 Sep 2008 02:06:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8926tMG028165; Mon, 8 Sep 2008 19:06:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8926tfh009795; Tue, 9 Sep 2008 02:06:55 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); Mon, 8 Sep 2008 19:06:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Sep 2008 19:06:32 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5407BB4469@xmb-sjc-215.amer.cisco.com> In-Reply-To: <38c19b540809080855m3985efcfk121e3524090b01ca@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Interim Meeting Announcement thread-index: AckRy3gZFLzjSrYoR7KrhQdJbphxrgAVRaSA References: <38c19b540809080855m3985efcfk121e3524090b01ca@mail.gmail.com> From: "Ali C. Begen (abegen)" To: "Greg Shepherd" , X-OriginalArrivalTime: 09 Sep 2008 02:06:55.0622 (UTC) FILETIME=[BBD37260:01C91220] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1170; t=1220926015; x=1221790015; c=relaxed/simple; s=sjdkim2002; 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:=20RE=3A=20[Fecframe]=20Interim=20Meeting=20Announ cement |Sender:=20; bh=DzjyYChi/1ZZ9PytfR8WG39YeX5ZqBYw2Eu4sgVzykk=; b=MewYnKWyoPw3XutL7oSQGU+ubgUhUmEFQRiV8JMMuxpL6/LgtKQN1PSdsv aUu2oyHllqcsnsojT/Xf77DtTCQ+0U/noCongbE11kH+BQQqijG2NwiTOPI5 P6Di4GBoIm; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Fecframe] Interim Meeting Announcement 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org These dates work for me and will give us enough time beore the next ietf deadline. BR, -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd > Sent: Monday, September 08, 2008 6:55 PM > To: fecframe@ietf.org; iesg-secretary@ietf.org > Subject: [Fecframe] Interim Meeting Announcement > > We will be having a FECFrame working group interim meeting > next month in California, San Francisco bay area. Exact > location TBD. The agenda will be assembled and sent in a > follow-up message. > > Starting 1200 Oct 20 - 1700 Oct 22 > > Calling for hosts! As I said before, getting a conference > room at the Cisco San Jose campus is always a fall-back > option, but I want to open this up first to anyone would like > to host the meeting. I'd expect no more than 6-10 in > attendance, but we will require dial-in attendance for those > who can't travel. > > Thanks, > Greg > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Thu Sep 11 13:49:34 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A04728C0D0; Thu, 11 Sep 2008 13:49:34 -0700 (PDT) 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 6702D28C0EE for ; Thu, 11 Sep 2008 13:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8QM+xORoZDD for ; Thu, 11 Sep 2008 13:46:52 -0700 (PDT) Received: from mtxmxout5.matrox.com (mtxmxout5.matrox.com [138.11.2.95]) by core3.amsl.com (Postfix) with ESMTP id 8FA5928C0D0 for ; Thu, 11 Sep 2008 13:46:52 -0700 (PDT) Received: from venus.matrox.com (venus.matrox.com [192.168.1.30]) by mtxmxout5.matrox.com (Postfix) with ESMTP id C2E951C6977 for ; Thu, 11 Sep 2008 16:46:43 -0400 (EDT) Received: (from ssmsp@localhost) by venus.matrox.com (8.13.2/8.13.2) id m8BKkh63004165 for fecframe@ietf.org; Thu, 11 Sep 2008 16:46:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by venus.matrox.com (Postfix) with ESMTP id 5F39F4D06D for ; Thu, 11 Sep 2008 16:46:43 -0400 (EDT) X-Virus-MTX-Scanned: by Matrox Virus scanner at venus.matrox.com Received: from venus.matrox.com ([127.0.0.1]) by localhost (venus.matrox.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hxD5TWngDBU0 for ; Thu, 11 Sep 2008 16:46:43 -0400 (EDT) Received: from pluton.matrox.com (pluton.matrox.com [192.168.8.7]) by venus.matrox.com (Postfix) with ESMTP id 4526C4D064 for ; Thu, 11 Sep 2008 16:46:43 -0400 (EDT) Received: from swoptvoip (dyn-66-134.matrox.com [192.168.66.134]) by pluton.matrox.com (Postfix) with ESMTP id 009297F485 for ; Thu, 11 Sep 2008 16:46:43 -0400 (EDT) From: "Guy Bonneau" To: Date: Thu, 11 Sep 2008 16:46:12 -0400 Message-ID: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AckUT2sr70SmVerqSmyGtU3HmmIKUg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-D Interleaved Parity FEC" 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org While reviewing RFC 2733 and RTP Payload format for 1-D Interleaved Parity FEC I found a discrepancy related to the processing of the timestamp between the 2 documents. In RFC 2733 section 6.1 it is stated : "The timestamp MUST be set to the value of the media RTP clock at the instant the FEC packet is transmitted. This results in the TS value in FEC packets to be monotonically increasing, independent of the FEC scheme..." In "RTP Payload format for 1-D Interleaved Parity FEC" it is stated : o Timestamp (TS): The timestamp MUST be set to the timestamp of the source packet whose sequence number is the lowest among the source packets protected by this repair packet. Please comment _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Thu Sep 11 20:07:56 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E9B3A6ADC; Thu, 11 Sep 2008 20:07:56 -0700 (PDT) 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 D5D303A6ADC for ; Thu, 11 Sep 2008 20:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 yo4xW671ZgTx for ; Thu, 11 Sep 2008 20:07:53 -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 AC4183A686A for ; Thu, 11 Sep 2008 20:07:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,385,1217808000"; d="scan'208";a="153969472" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2008 03:08:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m8C381jP019819; Thu, 11 Sep 2008 20:08:01 -0700 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 m8C381mp013472; Fri, 12 Sep 2008 03:08:01 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); Thu, 11 Sep 2008 20:08:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Sep 2008 20:07:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" thread-index: AckUT2sr70SmVerqSmyGtU3HmmIKUgAClYXQ References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> From: "Ali C. Begen (abegen)" To: "Guy Bonneau" , X-OriginalArrivalTime: 12 Sep 2008 03:08:00.0811 (UTC) FILETIME=[C3B027B0:01C91484] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3047; t=1221188881; x=1222052881; c=relaxed/simple; s=sjdkim4002; 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:=20RE=3A=20[Fecframe]=20Timestamps=20issue=20in=20 Draft=20=22RTP=20Payload=20format=20for=201-DInterleaved=20P arity=20FEC=22 |Sender:=20; bh=Yfdg8QYlAAQtiMCU2Q/WEGCUodFYY60QecGnOZmANjI=; b=SpDM3zZS31BSq3ONbhF4XC2DVrLav6NE1LQJzEv2LDgOm+zrzJokIZAB/q 6YNVeBSfMOstZ6kqch4ycfhXDDyTbSXZhSebG/y+ZxOhK8pUBDsabhqMrgCR JdrRtKUFPF; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org You are correct. Note that the 1-D draft is adopting SMPTE 2022-1 spec and fixing the RTP issues with it. The SMPTE spec does not use the timestamp field at all (receivers ignore it and what the sender puts in that field is undefined). In our draft, we use it and set it as you described below. The motivation for this change from 2733 is that the clock at the instant the fec packet is transmitted is not a very useful information. It does not help in FEC decoding process, either. Furthermore, unlike the source RTP packets, FEC packets don't have a synchronization issue. So their transmission time is not very critical (as long as they arrive on time for FEC decoding). Instead, during our discussions, we decided to set it differently. Of course, FEC packets identify which source packets they protect (based on the SN base, L, D). However, if the FEC packet is received earlier than the source packets it protects (might be the case), by checking the timestamp field, we can now know the timestamp of the earliest source packet that is protected by this packet (in addition to its seqnum). This is a useful information. Or, if that earliest source packet won't arrive (i.e., it is lost), we will know by when we have to recover it. OTOH, if the source packets are received earlier than the FEC packet, the timestamp info would not be that useful. We can think of it as follows as well: The FEC packet has some information from that earliest source packet. That source packet was sampled at time say, t, so, it makes sense to put the value of t in the timestamp field of the fec packet. (RFC 3550 says that "The timestamp reflects the sampling instant of the first octet in the RTP data packet.") BR, -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On Behalf Of Guy Bonneau > Sent: Thursday, September 11, 2008 11:46 PM > To: fecframe@ietf.org > Subject: [Fecframe] Timestamps issue in Draft "RTP Payload > format for 1-DInterleaved Parity FEC" > > While reviewing RFC 2733 and RTP Payload format for 1-D > Interleaved Parity FEC I found a discrepancy related to the > processing of the timestamp between the 2 documents. > > In RFC 2733 section 6.1 it is stated : > > "The timestamp MUST be set to the value of the media RTP > clock at the instant the FEC packet is transmitted. This > results in the TS value in FEC packets to be monotonically > increasing, independent of the FEC scheme..." > > In "RTP Payload format for 1-D Interleaved Parity FEC" it is stated : > > o Timestamp (TS): The timestamp MUST be set to the > timestamp of the > source packet whose sequence number is the lowest among > the source > packets protected by this repair packet. > > Please comment > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Sep 12 01:43:40 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4710F3A67A6; Fri, 12 Sep 2008 01:43:40 -0700 (PDT) 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 581533A63C9; Fri, 12 Sep 2008 01:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=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 5tnTwPS47eGM; Fri, 12 Sep 2008 01:43:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E9D553A67A6; Fri, 12 Sep 2008 01:43:36 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 79DEA20D23; Fri, 12 Sep 2008 10:43:42 +0200 (CEST) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-c7-48ca2bbe4bf5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 40EF7204D3; Fri, 12 Sep 2008 10:43:42 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 10:43:39 +0200 Received: from [147.214.183.33] ([147.214.183.33]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Sep 2008 10:43:38 +0200 Message-ID: <48CA2BBB.6030009@ericsson.com> Date: Fri, 12 Sep 2008 10:43:39 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 12 Sep 2008 08:43:38.0889 (UTC) FILETIME=[A6EAFF90:01C914B3] X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG , fecframe@ietf.org Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Ali C. Begen (abegen) skrev: > You are correct. Note that the 1-D draft is adopting SMPTE 2022-1 spec > and fixing the RTP issues with it. The SMPTE spec does not use the > timestamp field at all (receivers ignore it and what the sender puts in > that field is undefined). In our draft, we use it and set it as you > described below. > = > The motivation for this change from 2733 is that the clock at the > instant the fec packet is transmitted is not a very useful information. > It does not help in FEC decoding process, either. Furthermore, unlike > the source RTP packets, FEC packets don't have a synchronization issue. > So their transmission time is not very critical (as long as they arrive > on time for FEC decoding). = > = > Instead, during our discussions, we decided to set it differently. Of > course, FEC packets identify which source packets they protect (based on > the SN base, L, D). However, if the FEC packet is received earlier than > the source packets it protects (might be the case), by checking the > timestamp field, we can now know the timestamp of the earliest source > packet that is protected by this packet (in addition to its seqnum). > This is a useful information. Or, if that earliest source packet won't > arrive (i.e., it is lost), we will know by when we have to recover it. > > OTOH, if the source packets are received earlier than the FEC packet, > the timestamp info would not be that useful. > = > We can think of it as follows as well: The FEC packet has some > information from that earliest source packet. That source packet was > sampled at time say, t, so, it makes sense to put the value of t in the > timestamp field of the fec packet. = > = > (RFC 3550 says that "The timestamp reflects the sampling instant of the > first octet in the RTP data packet.") The problem with this definition is that you are completely screwing up = the RTCP jitter calculation. Sure, RTCP jitter calculations are screwed = up by some other RTP payload formats, like video with multiple packets = for the same frame. However, there is a trade-off here. I am not certain = that the timestamp of the source packet are that useful as you anyway = have an explicit reference to the packets you will need. If the SN base = packet hasn't arrived, then the repair packet is early. Not particular = likely unless strange transport reordering mechanisms are in place. If = as you say the repair packet arrives after SN base source packet, then = you can look up the corresponding timestamp. So in this case, I don't see how loseing the possibility use the RTCP = jitter for something useful on the FEC stream is motivated. And if the = FEC stream jitter measurements works decently, then they can be used to = cover for source streams that aren't able to utilize the jitter measurement. I think we should include AVT in RTP related discussions. I also need to = add this bit of information to the RTP payload how to. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Sep 12 08:44:02 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4923928C0F5; Fri, 12 Sep 2008 08:44:02 -0700 (PDT) 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 CF77E3A6B8B; Fri, 12 Sep 2008 08:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 5FH0U3Oj3E4U; Fri, 12 Sep 2008 08:43:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C3D863A6B70; Fri, 12 Sep 2008 08:43:58 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 12 Sep 2008 15:42:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8CFgEx9007115; Fri, 12 Sep 2008 08:42:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8CFgE6n025923; Fri, 12 Sep 2008 15:42:14 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); Fri, 12 Sep 2008 08:42:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 08:41:59 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1B8@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft - RTP Payload Format for Non-Interleaved and Interleaved Parity FEC thread-index: AckU7hgAEKwZsWcCS6mz4/ooKlsMUQ== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 12 Sep 2008 15:42:03.0678 (UTC) FILETIME=[1A89CBE0:01C914EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1500; t=1221234134; x=1222098134; c=relaxed/simple; s=sjdkim2002; 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:=20New=20draft=20-=20RTP=20Payload=20Format=20for= 20Non-Interleaved=20and=20Interleaved=20Parity=20FEC |Sender:=20; bh=pwYKueXJwFUOmDj4uI5jk1KtkWiT0KQCRXwtyPQtNsg=; b=rkIiQ4ePB1TyEPeqoInczKjX/m75g1m8Ugsuae5juThbv6b/Loc0TGgEom qKgfMlVWXfZH5+M6IZaZkh5meA59rOwwjHEUJFl1vfn4xRDdnuFF0htcWktd /dNBQ00tTP; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org Subject: [Fecframe] New draft - RTP Payload Format for Non-Interleaved and Interleaved Parity FEC 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi everyone, I've submitted a new payload format draft for the interleaved and non-interleaved parity FEC protection for source RTP streams. This draft attempts to address the scalability issues that the earlier similar specs had and provides several improvements (in terms of complying with RTP). In particular, this payload format is suitable for high-bitrate media flows and can provide protection against long bursty losses. Comments/questions are welcome. Thanks, -acbegen http://www.ietf.org/internet-drafts/draft-begen-fecframe-1d2d-parity-sch eme-01.txt Abstract: This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, 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 non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Sep 12 08:56:44 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615DD3A6BBE; Fri, 12 Sep 2008 08:56:44 -0700 (PDT) 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 142903A6952; Fri, 12 Sep 2008 08:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 BrTY2AjOEwnq; Fri, 12 Sep 2008 08:56:37 -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 70A483A6BC0; Fri, 12 Sep 2008 08:56:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,390,1217808000"; d="scan'208";a="154350689" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2008 15:56:45 +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 m8CFuj9l007379; Fri, 12 Sep 2008 08:56:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8CFujMX009385; Fri, 12 Sep 2008 15:56:45 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); Fri, 12 Sep 2008 08:56:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 08:56:43 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <48CA2BBB.6030009@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" thread-index: AckUs7x+FK2u6oMmT3G1cZnqCinprwAO3YHw References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> <48CA2BBB.6030009@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 12 Sep 2008 15:56:45.0082 (UTC) FILETIME=[27E55FA0:01C914F0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4907; t=1221235005; x=1222099005; 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 |Subject:=20RE=3A=20[Fecframe]=20Timestamps=20issue=20in=20 Draft=20=22RTP=20Payload=20format=20for=201-DInterleaved=20P arity=20FEC=22 |Sender:=20; bh=clHLYdd8H0HO5uKKQnTSiXaoiz+pAky4G0zGtON9zOs=; b=CoMSYNj/SbUthZRpMpD/c2nj6VmRdxWY6ora04Ao75oNZ4PLTdGGt77zz2 0G3KQPDrzyaXYgC/TO8F62D4OeJFAFtxdXD+UQxGRrUQI6gR03+zqr/jQRIO jFYuRzvdfO; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF AVT WG , fecframe@ietf.org Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hi Magnus, Comments are inline. = > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] = > Sent: Friday, September 12, 2008 11:44 AM > To: Ali C. Begen (abegen) > Cc: Guy Bonneau; fecframe@ietf.org; IETF AVT WG > Subject: Re: [Fecframe] Timestamps issue in Draft "RTP = > Payload format for 1-DInterleaved Parity FEC" > = > Ali C. Begen (abegen) skrev: > > You are correct. Note that the 1-D draft is adopting SMPTE = > 2022-1 spec = > > and fixing the RTP issues with it. The SMPTE spec does not use the = > > timestamp field at all (receivers ignore it and what the = > sender puts = > > in that field is undefined). In our draft, we use it and = > set it as you = > > described below. > > = > > The motivation for this change from 2733 is that the clock at the = > > instant the fec packet is transmitted is not a very useful = > information. > > It does not help in FEC decoding process, either. = > Furthermore, unlike = > > the source RTP packets, FEC packets don't have a = > synchronization issue. > > So their transmission time is not very critical (as long as they = > > arrive on time for FEC decoding). > > = > > Instead, during our discussions, we decided to set it = > differently. Of = > > course, FEC packets identify which source packets they = > protect (based = > > on the SN base, L, D). However, if the FEC packet is = > received earlier = > > than the source packets it protects (might be the case), by = > checking = > > the timestamp field, we can now know the timestamp of the earliest = > > source packet that is protected by this packet (in addition = > to its seqnum). > > This is a useful information. Or, if that earliest source = > packet won't = > > arrive (i.e., it is lost), we will know by when we have to = > recover it. > > > > OTOH, if the source packets are received earlier than the = > FEC packet, = > > the timestamp info would not be that useful. > > = > > We can think of it as follows as well: The FEC packet has some = > > information from that earliest source packet. That source = > packet was = > > sampled at time say, t, so, it makes sense to put the value of t in = > > the timestamp field of the fec packet. > > = > > (RFC 3550 says that "The timestamp reflects the sampling instant of = > > the first octet in the RTP data packet.") > = > The problem with this definition is that you are completely = > screwing up the RTCP jitter calculation. Sure, RTCP jitter = > calculations are screwed up by some other RTP payload = > formats, like video with multiple packets for the same frame. = We are not touching the jitter measurement for the source packets. But, yes= , our setting will disable the jitter measurement for the FEC packets. > However, there is a trade-off here. I am not certain that the = > timestamp of the source packet are that useful as you anyway = > have an explicit reference to the packets you will need. If = > the SN base packet hasn't arrived, then the repair packet is = > early. Not particular likely unless strange transport = > reordering mechanisms are in place. If as you say the repair = > packet arrives after SN base source packet, then you can look = > up the corresponding timestamp. Agree. = > So in this case, I don't see how loseing the possibility use = > the RTCP jitter for something useful on the FEC stream is = > motivated. And if the FEC stream jitter measurements works = > decently, then they can be used to cover for source streams = > that aren't able to utilize the jitter measurement. I don't think jitter measurements based on the FEC packets could be effecti= vely used for estimating the jitter for the source packets. There are sever= al different sending arrangements adopted for sending the FEC packets that = will mess up the measurements anyway. Furthermore, the repair packets might= be sent over a different network, qos class, etc. But, why do you need something like this in the first place? We can measure= the jitter in the source stream itself. > I think we should include AVT in RTP related discussions. I = > also need to add this bit of information to the RTP payload how to. Agree. Thanks for the note. -acbegen > Cheers > = > Magnus Westerlund > = > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > = _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Fri Sep 12 10:34:56 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7CD3A6BB2; Fri, 12 Sep 2008 10:34:56 -0700 (PDT) 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 372CB3A6BB2; Fri, 12 Sep 2008 10:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=0.440, 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 udYJI2JzdKQO; Fri, 12 Sep 2008 10:34:53 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id A61183A6953; Fri, 12 Sep 2008 10:34:52 -0700 (PDT) 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 12949815; Fri, 12 Sep 2008 13:35:00 -0400 Message-Id: <9773ABF9-CAC5-4561-A982-BBCA824CF836@multicasttech.com> From: Marshall Eubanks To: mboned@ietf.org, fecframe@ietf.org, l3vpn@ietf.org Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 12 Sep 2008 13:34:58 -0400 References: <20080912164811.74CF63A6C4E@core3.amsl.com> X-Mailer: Apple Mail (2.926) Subject: [Fecframe] Fwd: Nomcom call for candidates 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org If you have candidates (including yourself), please send them in. Regards Marshall Begin forwarded message: > From: NomCom Chair > Date: September 12, 2008 12:48:11 PM EDT > To: Working Group Chairs > Subject: Nomcom call for candidates > > The message below was just sent to the IETF-Annoucne list. > However, it order to get to as many people as possible, I am asking WG > chairs a favor. Please forward the message to your working groups. > > Thank you, > Joel M. Halpern > > The 2008-9 IETF Nominating Committee needs your help. > We have started getting candidates. > If we are going to do our job in time, we have only 3 more weeks to > get > enough candidates to have a reasonable pool for all the jobs. > At the moment, we do not have a reasonable pool for any jobs. > > If you are willing to serve, please nominate yourself. > If there is someone you think would do a good job, please nominate > them. > > The web site at: > http://wiki.tools.ietf.org/group/nomcom/08 > Has the list of positions we are seeking people for, as well as > tools for > providing both nominations and feedback. > > Alternatively, you can submit nominations by sending email to me. > > Please help us. > > Thank you, > Joel M. Halpern > jmh@joelhalpern.com > nomcom-chair@ietf.org _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Sun Sep 14 02:38:35 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9BA83A6A38; Sun, 14 Sep 2008 02:38:35 -0700 (PDT) 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 877E23A6A2A; Sun, 14 Sep 2008 02:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GRc3XRvXaiox; Sun, 14 Sep 2008 02:38:33 -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 529B33A69BE; Sun, 14 Sep 2008 02:38:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,396,1217808000"; d="scan'208,217";a="155093254" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Sep 2008 09:38:33 +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 m8E9cXtc031003; Sun, 14 Sep 2008 02:38:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8E9cXBC002855; Sun, 14 Sep 2008 09:38:33 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); Sun, 14 Sep 2008 02:38:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 14 Sep 2008 02:38:24 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5407C5E897@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Presenting new 1-D and 2-D proposals in SMPTE thread-index: AckWTaHOq3BTZ/w+THStJOY7ppxmEw== From: "Ali C. Begen (abegen)" To: "Marshall Eubanks" X-OriginalArrivalTime: 14 Sep 2008 09:38:33.0688 (UTC) FILETIME=[A798ED80:01C9164D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7980; t=1221385113; x=1222249113; 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 |Subject:=20Presenting=20new=201-D=20and=202-D=20proposals= 20in=20SMPTE |Sender:=20; bh=bITf9U34Nxc/7NXFfoFq/SpaF2lVtvQk55CKhRme5bU=; b=tXBMkCA5Y0QxsMUz+pq2cViWitXdWfz31EtUZnKWw/AOjRmVNVO4T1IwqD U25ILBgBfCFn3Ohx1APjzXKsCjjspcBakxvBCcIeRqRdmPw8IVH/6EyN5Opw dDY9SNezS9; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF AVT WG , fecframe@ietf.org Subject: [Fecframe] Presenting new 1-D and 2-D proposals in SMPTE 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: , Content-Type: multipart/mixed; boundary="===============1762764212==" Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org This is a multi-part message in MIME format. --===============1762764212== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9164D.A7467358" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9164D.A7467358 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear Marshall, The VSF Web site says that you (one of the FECframe WG chairs) are scheduled to give a talk on the recent developments in FEC in the next VSF meeting that will take place in early October.=20 http://www.videoservicesforum.org/upcoming_events/2008-10_MtgSeries-Aust inTX/VSFAgenda-Oct2008.pdf I believe this is a perfect opportunity to engage with our colleagues in the SMPTE/VSF technical groups who are working towards new FEC protection schemes and provide them updates on the following two issues: 1- WG-adopted RTP payload format for 1-D interleaved FEC protection:=20 http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec- scheme-00.txt This draft adopts the FEC header of SMPTE 2022-1 (2007) and provide fixes to non-RTP-compliant parts. It also registers a new RTP payload format with IANA for the interleaved FEC. Currently, this draft is being specified for the base layer of the AL-FEC protocol developed by DVB. It is important to note that we are trying to update the SMPTE's spec, rather we are trying to produce an RTP-compliant version that could be adopted by vendors/SDOs that want to have RTP-compliant interleaved FEC protection.=20 2- New/fresh RTP payload format proposal for interleaved and non-interleaved parity FEC protection: http://www.ietf.org/internet-drafts/draft-begen-fecframe-1d2d-parity-sch eme-01.txt The existing specs for protecting the RTP source streams unfortunately have scalability issues (including the one above). When we have high-bitrate media flows such as UltraHD or when we need protection against long bursty errors (such as device/route failures in the core), the existing specs won't work. In the last IETF discussion, you mentioned that SMPTE started working on this problem and that indeed shows the need for a solution. The current version of the draft was produced after a substantial update based on the discussions we had during the last IETF (July) meeting. (The initial version was presented in March). This draft attempts to register the new payload formats for both non-interleaved and interleaved FEC and to be fully RTP compliant. Due to changes in the header and its settings, this draft is not backward compatible with the existing specs. I would appreciate if you could include discussions around these two drafts in your talk next month. Even better, it would be great if you could provide the SMPTE/VSF groups a heads-up in their email lists (I believe their lists require membership) about these works at IETF. We would welcome their suggestions and collaboration on these drafts, especially for defining the new RTP payload formats (#2 above). If you need, I can provide you some slides for your presentation. Thanks and best regards, -acbegen ------_=_NextPart_001_01C9164D.A7467358 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Presenting new 1-D and 2-D proposals in SMPTE

Dear = Marshall,

The VSF Web site says that = you (one of the FECframe WG chairs) are scheduled to give a talk on the = recent developments in FEC in the next VSF meeting that will take place = in early October.

http://www.videoservicesforum.org/upcoming_events/2008-10_= MtgSeries-AustinTX/VSFAgenda-Oct2008.pdf

I believe this is a perfect = opportunity to engage with our colleagues in the SMPTE/VSF technical = groups who are working towards new FEC protection schemes and provide = them updates on the following two issues:

1- WG-adopted RTP = payload format for 1-D interleaved FEC protection:

http://www.ietf.org/internet-drafts/draft-ietf-fecframe-in= terleaved-fec-scheme-00.txt

This draft adopts the FEC = header of SMPTE 2022-1 (2007) and provide fixes to non-RTP-compliant = parts. It also registers a new RTP payload format with IANA for the = interleaved FEC. Currently, this draft is being specified for the base = layer of the AL-FEC protocol developed by DVB. It is important to note = that we are trying to update the SMPTE's spec, rather we are trying to = produce an RTP-compliant version that could be adopted by vendors/SDOs = that want to have RTP-compliant interleaved FEC protection. =

2- New/fresh RTP payload = format proposal for interleaved and non-interleaved parity FEC = protection:

http://www.ietf.org/internet-drafts/draft-begen-fecframe-1= d2d-parity-scheme-01.txt

The existing specs for = protecting the RTP source streams unfortunately have scalability issues = (including the one above). When we have high-bitrate media flows such as = UltraHD or when we need protection against long bursty errors (such as = device/route failures in the core), the existing specs won't work. In = the last IETF discussion, you mentioned that SMPTE started working on = this problem and that indeed shows the need for a = solution.

The current version of the = draft was produced after a substantial update based on the discussions = we had during the last IETF (July) meeting. (The initial version was = presented in March). This draft attempts to register the new payload = formats for both non-interleaved and interleaved FEC and to be fully RTP = compliant. Due to changes in the header and its settings, this draft is = not backward compatible with the existing specs.

I would appreciate if you = could include discussions around these two drafts in your talk next = month. Even better, it would be great if you could provide the SMPTE/VSF = groups a heads-up in their email lists (I believe their lists require = membership) about these works at IETF. We would welcome their = suggestions and collaboration on these drafts, especially for defining = the new RTP payload formats (#2 above).

If you need, I can provide = you some slides for your presentation.

Thanks and best = regards,

-acbegen

------_=_NextPart_001_01C9164D.A7467358-- --===============1762764212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe --===============1762764212==-- From fecframe-bounces@ietf.org Mon Sep 15 04:22:21 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B493A6B1F; Mon, 15 Sep 2008 04:22:21 -0700 (PDT) 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 2E4643A6B1E; Mon, 15 Sep 2008 04:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=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 l2kMF3Aeuq1F; Mon, 15 Sep 2008 04:22:19 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 07EC73A6B1F; Mon, 15 Sep 2008 04:22:18 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7F1CA20550; Mon, 15 Sep 2008 13:22:22 +0200 (CEST) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-e0-48ce456e5bea Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5B56B2045F; Mon, 15 Sep 2008 13:22:22 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 13:22:22 +0200 Received: from [147.214.183.33] ([147.214.183.33]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 13:22:22 +0200 Message-ID: <48CE456D.3030707@ericsson.com> Date: Mon, 15 Sep 2008 13:22:21 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> <48CA2BBB.6030009@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 15 Sep 2008 11:22:22.0052 (UTC) FILETIME=[52679A40:01C91725] X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG , fecframe@ietf.org Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Ali C. Begen (abegen) skrev: > = >> So in this case, I don't see how loseing the possibility use = >> the RTCP jitter for something useful on the FEC stream is = >> motivated. And if the FEC stream jitter measurements works = >> decently, then they can be used to cover for source streams = >> that aren't able to utilize the jitter measurement. > = > I don't think jitter measurements based on the FEC packets could be effec= tively used for estimating the jitter for the source packets. There are sev= eral different sending arrangements adopted for sending the FEC packets tha= t will mess up the measurements anyway. Furthermore, the repair packets mig= ht be sent over a different network, qos class, etc. Okay, so you are saying that despite the FEC source intention to = correctly timestamp data as being sent a downstream node will mess with = this so that it can't be used reliably? > = > But, why do you need something like this in the first place? We can measu= re the jitter in the source stream itself. > = As there are a number of RTP payload formats that you can't do jitter = measurements on, especially for video, using the FEC RTP stream for this = would allow jitter measurements also in these cases that otherwise can't = be covered at all with the regular measurements. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 15 04:46:36 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C253A6803; Mon, 15 Sep 2008 04:46:36 -0700 (PDT) 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 BCDDF3A6803; Mon, 15 Sep 2008 04:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 QkSc+dQ+2GgR; Mon, 15 Sep 2008 04:46:34 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 2DA5D3A67E7; Mon, 15 Sep 2008 04:46:34 -0700 (PDT) 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 12987141; Mon, 15 Sep 2008 07:46:44 -0400 Message-Id: <44E65499-3332-4D53-BB45-ED33FCAA2DE0@multicasttech.com> From: Marshall Eubanks To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 15 Sep 2008 07:46:43 -0400 References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> <48CA2BBB.6030009@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.926) Cc: IETF AVT WG , fecframe@ietf.org Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Hello; On Sep 12, 2008, at 11:56 AM, Ali C. Begen (abegen) wrote: > Hi Magnus, > > Comments are inline. > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Friday, September 12, 2008 11:44 AM >> To: Ali C. Begen (abegen) >> Cc: Guy Bonneau; fecframe@ietf.org; IETF AVT WG >> Subject: Re: [Fecframe] Timestamps issue in Draft "RTP >> Payload format for 1-DInterleaved Parity FEC" >> >> Ali C. Begen (abegen) skrev: >>> You are correct. Note that the 1-D draft is adopting SMPTE >> 2022-1 spec >>> and fixing the RTP issues with it. The SMPTE spec does not use the >>> timestamp field at all (receivers ignore it and what the >> sender puts >>> in that field is undefined). In our draft, we use it and >> set it as you >>> described below. >>> >>> The motivation for this change from 2733 is that the clock at the >>> instant the fec packet is transmitted is not a very useful >> information. >>> It does not help in FEC decoding process, either. >> Furthermore, unlike >>> the source RTP packets, FEC packets don't have a >> synchronization issue. >>> So their transmission time is not very critical (as long as they >>> arrive on time for FEC decoding). >>> >>> Instead, during our discussions, we decided to set it >> differently. Of >>> course, FEC packets identify which source packets they >> protect (based >>> on the SN base, L, D). However, if the FEC packet is >> received earlier >>> than the source packets it protects (might be the case), by >> checking >>> the timestamp field, we can now know the timestamp of the earliest >>> source packet that is protected by this packet (in addition >> to its seqnum). >>> This is a useful information. Or, if that earliest source >> packet won't >>> arrive (i.e., it is lost), we will know by when we have to >> recover it. >>> >>> OTOH, if the source packets are received earlier than the >> FEC packet, >>> the timestamp info would not be that useful. >>> >>> We can think of it as follows as well: The FEC packet has some >>> information from that earliest source packet. That source >> packet was >>> sampled at time say, t, so, it makes sense to put the value of t in >>> the timestamp field of the fec packet. >>> >>> (RFC 3550 says that "The timestamp reflects the sampling instant of >>> the first octet in the RTP data packet.") >> >> The problem with this definition is that you are completely >> screwing up the RTCP jitter calculation. Sure, RTCP jitter >> calculations are screwed up by some other RTP payload >> formats, like video with multiple packets for the same frame. > > We are not touching the jitter measurement for the source packets. = > But, yes, our setting will disable the jitter measurement for the = > FEC packets. > >> However, there is a trade-off here. I am not certain that the >> timestamp of the source packet are that useful as you anyway >> have an explicit reference to the packets you will need. If >> the SN base packet hasn't arrived, then the repair packet is >> early. Not particular likely unless strange transport >> reordering mechanisms are in place. If as you say the repair >> packet arrives after SN base source packet, then you can look >> up the corresponding timestamp. > > Agree. > >> So in this case, I don't see how loseing the possibility use >> the RTCP jitter for something useful on the FEC stream is >> motivated. And if the FEC stream jitter measurements works >> decently, then they can be used to cover for source streams >> that aren't able to utilize the jitter measurement. > > I don't think jitter measurements based on the FEC packets could be = > effectively used for estimating the jitter for the source packets. = > There are several different sending arrangements adopted for sending = > the FEC packets that will mess up the measurements anyway. = > Furthermore, the repair packets might be sent over a different = > network, qos class, etc. > I would disagree with this. Precisely because you might send the FEC = packets differently, it would be useful to know their time delay & jitter. Suppose you put FEC packets in a QOS = class that causes them to sometimes arrive too late, because of = buffering or path differences. How would I be able to troubleshoot = that at the receiver if they - all have a timestamp a few 100 milliseconds or more too early (the = lowest sequence number means a large delay) and - will likely have jumps in this time stamp delay due to, e.g., = dropped frames in the encoder ? However, there could be FEC schemes where the original clock is not = available (i.e., middleware FEC). So, maybe the text should be The timestamp MUST be set to the value of the media RTP clock at the instant the FEC packet is transmitted, if the media RTP clock is = avalable to the sender of the FEC packets. If the media RTP clock is not available to the sender of the FEC packets, the timestamp MUST be set to the = value of a parallel RTP clock maintained by the sender, and this RTP clock SHOULD be = synchronized with the media RTP clock. Note that the SMPTE spec is silent here, so they are not a issue. Regards Marshall > But, why do you need something like this in the first place? We can = > measure the jitter in the source stream itself. > > >> I think we should include AVT in RTP related discussions. I >> also need to add this bit of information to the RTP payload how to. > > Agree. Thanks for the note. > > -acbegen > >> Cheers >> >> Magnus Westerlund >> >> IETF Transport Area Director & TSVWG Chair >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> F=E4r=F6gatan 6 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 15 07:10:16 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC7F3A6B1B; Mon, 15 Sep 2008 07:10:16 -0700 (PDT) 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 6172628C100; Mon, 15 Sep 2008 07:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 RyeSzfIt6Yxp; Mon, 15 Sep 2008 07:10:07 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 24C123A6B03; Mon, 15 Sep 2008 07:10:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,401,1217808000"; d="scan'208";a="45643852" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 15 Sep 2008 14:10:18 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8FEAIsN032240; Mon, 15 Sep 2008 07:10:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8FEAI09025434; Mon, 15 Sep 2008 14:10:18 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); Mon, 15 Sep 2008 07:10:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Sep 2008 07:08:48 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5407C5E97F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <48CE456D.3030707@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" thread-index: AckXJVtwn8VWH6z9Ql6SM4emp6knWAAFWVLQ References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> <48CA2BBB.6030009@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> <48CE456D.3030707@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 15 Sep 2008 14:10:18.0167 (UTC) FILETIME=[C83CBC70:01C9173C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2581; t=1221487818; x=1222351818; 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:=20RE=3A=20[Fecframe]=20Timestamps=20issue=20in=20 Draft=20=22RTP=20Payload=20format=20for=201-DInterleaved=20P arity=20FEC=22 |Sender:=20; bh=cHSKoXEsd2Rwxp6rqtVFRrvQgVXQ9yFhPhoJXniR+NM=; b=jEE0QPCuzJpHEl1ceHykhJn9kSNb/SO5IqU9ZN93ktASk3laKtRRUWdzex hApq0XubDNeUAZ3wk1Uee9GbaS1uqB4Fo2OPvWUCBmzeGGZDZHPsTtlyhfCA Iz5msDrcwelrObnCO6F+g+Z6ZzFlzXjweOuaer7aqMjXfTGqE0a2s=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: IETF AVT WG , fecframe@ietf.org Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org > Ali C. Begen (abegen) skrev: > > = > >> So in this case, I don't see how loseing the possibility = > use the RTCP = > >> jitter for something useful on the FEC stream is motivated. And if = > >> the FEC stream jitter measurements works decently, then = > they can be = > >> used to cover for source streams that aren't able to utilize the = > >> jitter measurement. > > = > > I don't think jitter measurements based on the FEC packets = > could be effectively used for estimating the jitter for the = > source packets. There are several different sending = > arrangements adopted for sending the FEC packets that will = > mess up the measurements anyway. Furthermore, the repair = > packets might be sent over a different network, qos class, etc. > = > Okay, so you are saying that despite the FEC source intention = > to correctly timestamp data as being sent a downstream node = > will mess with this so that it can't be used reliably? Yes. The sender may timestamp the FEC packets carefully and it also knows w= hich sending arrangement it will use to send them. However, as long as this= information (how the FEC packets were sent at the sender side, e.g., it ma= y be bursty, interleaved, etc), the receiver will not be able to make an ac= curate jitter measurement. = = > > = > > But, why do you need something like this in the first = > place? We can measure the jitter in the source stream itself. > > = > = > As there are a number of RTP payload formats that you can't = > do jitter measurements on, especially for video, using the = > FEC RTP stream for this would allow jitter measurements also = > in these cases that otherwise can't be covered at all with = > the regular measurements. I understand your point now. I did not think of this problem before. I also= agree that it would be cool to estimate the source jitter from the FEC pac= kets. However, per my comments above, I am not sure whether we can do it re= liably. -acbegen > Cheers > = > Magnus Westerlund > = > IETF Transport Area Director & TSVWG Chair > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > F=E4r=F6gatan 6 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > = _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 15 07:10:31 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD643A6835; Mon, 15 Sep 2008 07:10:31 -0700 (PDT) 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 0A7D928C124; Mon, 15 Sep 2008 07:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 4vhQKjiCQCf4; Mon, 15 Sep 2008 07:10:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 87FA628C0EA; Mon, 15 Sep 2008 07:10:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,401,1217808000"; d="scan'208";a="45643963" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-5.cisco.com with ESMTP; 15 Sep 2008 14:10:39 +0000 Received: from 12-187-208-241.att-inc.com ([10.21.70.202]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m8FDif6n015763; Mon, 15 Sep 2008 06:44:41 -0700 Message-Id: <7A3AAC37-DF43-48FB-B787-DA1FD822CF8F@cisco.com> From: David R Oran To: Marshall Eubanks In-Reply-To: <44E65499-3332-4D53-BB45-ED33FCAA2DE0@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 15 Sep 2008 07:10:38 -0700 References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> <48CA2BBB.6030009@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> <44E65499-3332-4D53-BB45-ED33FCAA2DE0@multicasttech.com> X-Mailer: Apple Mail (2.928.1) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7010; t=1221486282; x=1222350282; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Fecframe]=20Timestamps=20issue=20in=20 Draft=20=22RTP=20Payload=20format=20for=201-DInterleaved=20P arity=20FEC=22 |Sender:=20 |To:=20Marshall=20Eubanks=20; bh=r0YCbgfvVUV2Gs/KCQ5DDizHXGqXispZ2wXmQp3uy6w=; b=n9vZOiEKvGL9KDh9hYQkj6y7Q2+uVn6Pk7MO2dRRN5rAkE26zJxVdVv4A3 Zu424unuPsBZlZKKAbWd4Upi24i5OLWuDTzNX/Voi8y8DNk+OE3j3sovYuD5 fYzxWvUbIB; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: IETF AVT WG , fecframe@ietf.org Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org I tend to agree with Marshall's comments below. A couple of more = things embedded. On Sep 15, 2008, at 4:46 AM, Marshall Eubanks wrote: > Hello; > > On Sep 12, 2008, at 11:56 AM, Ali C. Begen (abegen) wrote: > >> Hi Magnus, >> >> Comments are inline. >> >>> -----Original Message----- >>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>> Sent: Friday, September 12, 2008 11:44 AM >>> To: Ali C. Begen (abegen) >>> Cc: Guy Bonneau; fecframe@ietf.org; IETF AVT WG >>> Subject: Re: [Fecframe] Timestamps issue in Draft "RTP >>> Payload format for 1-DInterleaved Parity FEC" >>> >>> Ali C. Begen (abegen) skrev: >>>> You are correct. Note that the 1-D draft is adopting SMPTE >>> 2022-1 spec >>>> and fixing the RTP issues with it. The SMPTE spec does not use the >>>> timestamp field at all (receivers ignore it and what the >>> sender puts >>>> in that field is undefined). In our draft, we use it and >>> set it as you >>>> described below. >>>> >>>> The motivation for this change from 2733 is that the clock at the >>>> instant the fec packet is transmitted is not a very useful >>> information. >>>> It does not help in FEC decoding process, either. >>> Furthermore, unlike >>>> the source RTP packets, FEC packets don't have a >>> synchronization issue. >>>> So their transmission time is not very critical (as long as they >>>> arrive on time for FEC decoding). >>>> >>>> Instead, during our discussions, we decided to set it >>> differently. Of >>>> course, FEC packets identify which source packets they >>> protect (based >>>> on the SN base, L, D). However, if the FEC packet is >>> received earlier >>>> than the source packets it protects (might be the case), by >>> checking >>>> the timestamp field, we can now know the timestamp of the earliest >>>> source packet that is protected by this packet (in addition >>> to its seqnum). >>>> This is a useful information. Or, if that earliest source >>> packet won't >>>> arrive (i.e., it is lost), we will know by when we have to >>> recover it. >>>> >>>> OTOH, if the source packets are received earlier than the >>> FEC packet, >>>> the timestamp info would not be that useful. >>>> >>>> We can think of it as follows as well: The FEC packet has some >>>> information from that earliest source packet. That source >>> packet was >>>> sampled at time say, t, so, it makes sense to put the value of t in >>>> the timestamp field of the fec packet. >>>> >>>> (RFC 3550 says that "The timestamp reflects the sampling instant of >>>> the first octet in the RTP data packet.") >>> >>> The problem with this definition is that you are completely >>> screwing up the RTCP jitter calculation. Sure, RTCP jitter >>> calculations are screwed up by some other RTP payload >>> formats, like video with multiple packets for the same frame. >> >> We are not touching the jitter measurement for the source packets. >> But, yes, our setting will disable the jitter measurement for the >> FEC packets. >> >>> However, there is a trade-off here. I am not certain that the >>> timestamp of the source packet are that useful as you anyway >>> have an explicit reference to the packets you will need. If >>> the SN base packet hasn't arrived, then the repair packet is >>> early. Not particular likely unless strange transport >>> reordering mechanisms are in place. If as you say the repair >>> packet arrives after SN base source packet, then you can look >>> up the corresponding timestamp. >> >> Agree. >> >>> So in this case, I don't see how loseing the possibility use >>> the RTCP jitter for something useful on the FEC stream is >>> motivated. And if the FEC stream jitter measurements works >>> decently, then they can be used to cover for source streams >>> that aren't able to utilize the jitter measurement. >> >> I don't think jitter measurements based on the FEC packets could be >> effectively used for estimating the jitter for the source packets. >> There are several different sending arrangements adopted for sending >> the FEC packets that will mess up the measurements anyway. >> Furthermore, the repair packets might be sent over a different >> network, qos class, etc. >> > > I would disagree with this. Precisely because you might send the FEC > packets differently, it would be useful to > know their time delay & jitter. Suppose you put FEC packets in a QOS > class that causes them to sometimes arrive too late, because of > buffering or path differences. How would I be able to troubleshoot > that at the receiver if they > In fact, if anything differs about the 5-tuple in the IP header, not = just the DSCP, the packets might get routed differently. This of = course inclues the case where the FEC is sent to a separate multicast = group. > - all have a timestamp a few 100 milliseconds or more too early (the > lowest sequence number means a large delay) and > - will likely have jumps in this time stamp delay due to, e.g., > dropped frames in the encoder ? > > However, there could be FEC schemes where the original clock is not > available (i.e., middleware FEC). So, > maybe the text should be > > The timestamp MUST be set to the value of the media RTP clock at the > instant the FEC packet is transmitted, if the media RTP clock is > avalable to > the sender of the FEC packets. If the media RTP clock is not available > to the sender of the FEC packets, the timestamp MUST be set to the > value of a parallel RTP > clock maintained by the sender, and this RTP clock SHOULD be > synchronized with the > media RTP clock. > This works for me. DaveO. > Note that the SMPTE spec is silent here, so they are not a issue. > > Regards > Marshall > > > >> But, why do you need something like this in the first place? We can >> measure the jitter in the source stream itself. > > >> >> >>> I think we should include AVT in RTP related discussions. I >>> also need to add this bit of information to the RTP payload how to. >> >> Agree. Thanks for the note. >> >> -acbegen >> >>> Cheers >>> >>> Magnus Westerlund >>> >>> IETF Transport Area Director & TSVWG Chair >>> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 8 4048287 >>> F=E4r=F6gatan 6 | Fax +46 8 7575550 >>> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 15 07:56:54 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA6A28C160; Mon, 15 Sep 2008 07:56:54 -0700 (PDT) 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 6167428C114; Mon, 15 Sep 2008 07:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_SE=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 v7yKbQ+aKR6q; Mon, 15 Sep 2008 07:56:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7919128C105; Mon, 15 Sep 2008 07:56:48 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 60F6521412; Mon, 15 Sep 2008 16:56:58 +0200 (CEST) X-AuditID: c1b4fb3e-a7e83bb000007a96-a6-48ce77ba083f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 31D70213F1; Mon, 15 Sep 2008 16:56:58 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 16:56:57 +0200 Received: from [147.214.183.33] ([147.214.183.33]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 16:56:57 +0200 Message-ID: <48CE77B9.8000001@ericsson.com> Date: Mon, 15 Sep 2008 16:56:57 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Marshall Eubanks References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> <48CA2BBB.6030009@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> <44E65499-3332-4D53-BB45-ED33FCAA2DE0@multicasttech.com> In-Reply-To: <44E65499-3332-4D53-BB45-ED33FCAA2DE0@multicasttech.com> X-Enigmail-Version: 0.95.6 X-OriginalArrivalTime: 15 Sep 2008 14:56:57.0688 (UTC) FILETIME=[4CE1BD80:01C91743] X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG , fecframe@ietf.org Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Marshall Eubanks skrev: >> >> I don't think jitter measurements based on the FEC packets could be = >> effectively used for estimating the jitter for the source packets. = >> There are several different sending arrangements adopted for sending = >> the FEC packets that will mess up the measurements anyway. = >> Furthermore, the repair packets might be sent over a different = >> network, qos class, etc. >> > = > I would disagree with this. Precisely because you might send the FEC = > packets differently, it would be useful to > know their time delay & jitter. Suppose you put FEC packets in a QOS = > class that causes them to sometimes arrive too late, because of = > buffering or path differences. How would I be able to troubleshoot that = > at the receiver if they > = > - all have a timestamp a few 100 milliseconds or more too early (the = > lowest sequence number means a large delay) and > - will likely have jumps in this time stamp delay due to, e.g., dropped = > frames in the encoder ? > = > However, there could be FEC schemes where the original clock is not = > available (i.e., middleware FEC). So, > maybe the text should be > = > The timestamp MUST be set to the value of the media RTP clock at the > instant the FEC packet is transmitted, if the media RTP clock is = > avalable to > the sender of the FEC packets. If the media RTP clock is not available > to the sender of the FEC packets, the timestamp MUST be set to the value = > of a parallel RTP > clock maintained by the sender, and this RTP clock SHOULD be = > synchronized with the > media RTP clock. > = > Note that the SMPTE spec is silent here, so they are not a issue. > = Marshall, If I understand you correctly you seem to want to have two things. Both = a media timestamp that tells one in the relation to what media is = handled at an asy glance and the possibility to measure transport = jitter. To me those two aren't really complementary. Using media = timestamp means errors in the timestamp. Only if you use transmission = timestamping will you get reliable transport jitter measurement. So = which function is the most important here? To certain degree the freedom of definition do works for the sender. = Because he knows which regime that is been used and can thus determine = if the RTCP jitter values from the receiver can be used or not. But if = one tries to make any receiver side use of the timestamp in this case it = is very problematic if one thinks it is media timestamps but they in = reality are transport timestamps. So if we really are going for = flexibility here there need to be explicit mention that the receiver = can't reliably detect which it is. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 F=E4r=F6gatan 6 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 15 11:05:45 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E753A6BCC; Mon, 15 Sep 2008 11:05:45 -0700 (PDT) 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 4FA5C3A6BBC; Mon, 15 Sep 2008 11:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9GOeh2xzWzai; Mon, 15 Sep 2008 11:05:42 -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 4792D3A6B7C; Mon, 15 Sep 2008 11:05:42 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Sep 2008 18:05:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8FI5r01002776; Mon, 15 Sep 2008 11:05:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m8FI5rRV025300; Mon, 15 Sep 2008 18:05:53 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); Mon, 15 Sep 2008 11:05:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Sep 2008 11:04:59 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5407C5EB38@xmb-sjc-215.amer.cisco.com> In-Reply-To: <44E65499-3332-4D53-BB45-ED33FCAA2DE0@multicasttech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" thread-index: AckXKLtfglHdDHGPTV6bBVI8g+62pAAM/zlQ References: <0415461A7AF6488CB18892EDCF904ABE@dorvalmatrox.matrox.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A0A5@xmb-sjc-215.amer.cisco.com> <48CA2BBB.6030009@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5407C0A1C6@xmb-sjc-215.amer.cisco.com> <44E65499-3332-4D53-BB45-ED33FCAA2DE0@multicasttech.com> From: "Ali C. Begen (abegen)" To: "Marshall Eubanks" X-OriginalArrivalTime: 15 Sep 2008 18:05:53.0449 (UTC) FILETIME=[B1859990:01C9175D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3556; t=1221501953; x=1222365953; c=relaxed/simple; s=sjdkim2002; 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:=20RE=3A=20[Fecframe]=20Timestamps=20issue=20in=20 Draft=20=22RTP=20Payload=20format=20for=201-DInterleaved=20P arity=20FEC=22 |Sender:=20; bh=YbcVv8MQfCC98+Db+SK7gKrEWIAi82y/G+b8NsaWj8I=; b=SP07riIoriISiI6qgq9BMZPoFVPj2uGSQ68cvS8omEY5SOlasyVevODjHg uJHebpRkpaLfbETkTZULf6202HhGp2As8wyC2s2JtYZ3RfaGqvH2GQJDJROB /x7fAyH6gZ; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IETF AVT WG , fecframe@ietf.org Subject: Re: [Fecframe] Timestamps issue in Draft "RTP Payload format for 1-DInterleaved Parity FEC" 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org > > I don't think jitter measurements based on the FEC packets could be = > > effectively used for estimating the jitter for the source packets. > > There are several different sending arrangements adopted = > for sending = > > the FEC packets that will mess up the measurements anyway. > > Furthermore, the repair packets might be sent over a different = > > network, qos class, etc. > > > = > I would disagree with this. Precisely because you might send = > the FEC packets differently, it would be useful to know their = > time delay & jitter. Suppose you put FEC packets in a QOS = > class that causes them to sometimes arrive too late, because = > of buffering or path differences. How would I be able to = > troubleshoot that at the receiver if they It is possible to make estimations regarding the delay of the FEC packets b= ased on the timestamp definition in the current draft and the source block = size. But, I agree it won't be accurate. But, as I explained earlier, even if we use the RTP clock at the time of th= e transmission as the timestamp, it still won't help us accurately estimate= the delay/jitter at the receiver side. (BTW, the initial version (draft-be= gen-fecframe-1d2d-parity-scheme-00.txt) had this definition. The current de= finition is new in the -01 version) > - all have a timestamp a few 100 milliseconds or more too = > early (the lowest sequence number means a large delay) and > - will likely have jumps in this time stamp delay due to, = > e.g., dropped frames in the encoder ? > = > However, there could be FEC schemes where the original clock = > is not available (i.e., middleware FEC). So, maybe the text should be > = > The timestamp MUST be set to the value of the media RTP clock = > at the instant the FEC packet is transmitted, if the media = > RTP clock is avalable to the sender of the FEC packets. If = > the media RTP clock is not available to the sender of the FEC = > packets, the timestamp MUST be set to the value of a parallel = > RTP clock maintained by the sender, and this RTP clock SHOULD = > be synchronized with the media RTP clock. If the WG agrees, I am OK with this suggested text but I still don't think = it will bring much to the table. > Note that the SMPTE spec is silent here, so they are not a issue. Indeed. They don't use it. -acbegen = > Regards > Marshall > = > = > = > > But, why do you need something like this in the first place? We can = > > measure the jitter in the source stream itself. > = > = > > > > > >> I think we should include AVT in RTP related discussions. I > >> also need to add this bit of information to the RTP payload how to. > > > > Agree. Thanks for the note. > > > > -acbegen > > > >> Cheers > >> > >> Magnus Westerlund > >> > >> IETF Transport Area Director & TSVWG Chair > >> = > ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> = > ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 8 4048287 > >> F=E4r=F6gatan 6 | Fax +46 8 7575550 > >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >> = > ---------------------------------------------------------------------- > >> > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > = > = _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 22 10:03:30 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BC73A6BAB; Mon, 22 Sep 2008 10:03:30 -0700 (PDT) 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 55C5D3A6AD0 for ; Mon, 22 Sep 2008 10:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-drkMOtIlRR for ; Mon, 22 Sep 2008 10:03:25 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by core3.amsl.com (Postfix) with ESMTP id 78FAA3A69E8 for ; Mon, 22 Sep 2008 10:03:25 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id c49so462668wra.17 for ; Mon, 22 Sep 2008 10:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=rNAlxTCs2grLRIAPUb46AHTwOvDLEstVa7uchfIoqMQ=; b=qxhyIHwq4Hw3dribOluxduZP+EEcaCj5PiptZFSpbclSQT0TeGtJQiNMUewLFiozGm YNDYJEH+xcX+vim6Dpmt/a9fUikWRcPjYqSu01L7EEU3RMnXz7hA3xGhnIty45U1SXy5 AtuWBScnHnxEaaDRN4pXFa3UaygjSyCBaBfIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=eGhMVxEf90lKgHOVRzOPBiGWzR+QL3hIZ9qb6Nmck9H4X56jJxoTJwHNEri1EYnVlE 1ZxwaYGeJJ4f0FElNMpb8tcjhVZ66tJ6N06D6d8T01xxkr8mj0SKONjCvbtfmL1yv6GM Fzh5+T+eR09I/5gtZmytn+VTKBfwfy67wA4fA= Received: by 10.100.144.11 with SMTP id r11mr3297657and.52.1222103006471; Mon, 22 Sep 2008 10:03:26 -0700 (PDT) Received: by 10.100.112.16 with HTTP; Mon, 22 Sep 2008 10:03:26 -0700 (PDT) Message-ID: <38c19b540809221003q16b83e98i671ce5fdc693352c@mail.gmail.com> Date: Mon, 22 Sep 2008 10:03:26 -0700 From: "Greg Shepherd" To: fecframe@ietf.org In-Reply-To: <20080916191902.7DD2E3A69F2@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080916191902.7DD2E3A69F2@core3.amsl.com> Subject: [Fecframe] Fwd: FECFRAME Working Group Interim Meeting, October 20-22, 2008, San Jose, CA 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org This announcement went out to the IETF-announce list, but I don't think the final details were copied here. So, due to the lack of any other host stepping-up, we'll host the meeting at the cisco campus in San Jose, California. Dates, times, locations and map links are below. I'll put together a straw agenda from our discussions in Dublin, but please feel free to send items to the list before then. I'll be on travel (some work, some fun) between Sept 29 - Oct 18th and will have on and off email access so we should get the agenda nailed down this week. Thanks, Greg ---------- Forwarded message ---------- From: IETF Secretariat Date: Tue, Sep 16, 2008 at 12:19 PM Subject: FECFRAME Working Group Interim Meeting, October 20-22, 2008, San Jose, CA To: IETF Announcement list Cc: gjshep@gmail.com, tme@multicasttech.com, magnus.westerlund@ericsson.com The FECFrame working group will be having an interim meeting next month in San Jose, California. The agenda will be assembled and sent in a follow-up message. Starting 1200 Oct 20 - 1700 Oct 22 Location: Cisco Systems, San Jose, CA Cisco San Jose, Building 16 http://maps.google.com/maps/ms?client=firefox-a&hl=en&ie=UTF8&msa=0&msid=109496039069852425144.00000112df60cca861566&ll=37.409233,-121.926205&spn=0.031668,0.028968&t=h&z=15 Mon, Oct 20th Rm. Honolua Bay, 3rd floor 1200-1700 Tues, Oct 21st Rm. Surfside Jetty, 2nd floor 0900-1700 Wed, Oct 22nd Rm. Uluwatu, 2nd floor 0900-1700 Local hotel options: http://maps.google.com/maps?f=q&hl=en&geocode=&q=hotel&sll=37.409233,-121.926205&sspn=0.031668,0.028968&ie=UTF8&ll=37.416527,-121.922193&spn=0.031665,0.028968&t=h&z=15 _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From fecframe-bounces@ietf.org Mon Sep 29 10:26:35 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA7A3A6979; Mon, 29 Sep 2008 10:26:35 -0700 (PDT) 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 446E43A6979 for ; Mon, 29 Sep 2008 10:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 Zy+gD0Gxtgch for ; Mon, 29 Sep 2008 10:26:31 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 1FFD93A6870 for ; Mon, 29 Sep 2008 10:26:31 -0700 (PDT) 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 13177918; Mon, 29 Sep 2008 13:25:51 -0400 Message-Id: <883465E7-26A8-451E-98A4-EC4A27FAE4E7@multicasttech.com> From: Marshall Eubanks To: Greg Shepherd In-Reply-To: <38c19b540809221003q16b83e98i671ce5fdc693352c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 29 Sep 2008 13:25:50 -0400 References: <20080916191902.7DD2E3A69F2@core3.amsl.com> <38c19b540809221003q16b83e98i671ce5fdc693352c@mail.gmail.com> X-Mailer: Apple Mail (2.926) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Fwd: FECFRAME Working Group Interim Meeting, October 20-22, 2008, San Jose, CA 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: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org SGF2ZSB3ZSBjb21lIHVwIHdpdGggYSBwcmVmZXJyZWQgaG90ZWwgZm9yIHRoaXMgPwoKV2hhdCBh Ym91dCB0aGUKSG9tZXN0ZWFkIFNhbiBKb3NlIC0gTWlscGl0YXPigI4KMzMwIEN5cHJlc3MgRHIK TWlscGl0YXMsIENBIDk1MDM1Cig0MDgpIDQzMy05NzAwCmhvbWVzdGVhZGhvdGVscy5jb23igI4K ClJlZ2FyZHMKTWFyc2hhbGwKCgpPbiBTZXAgMjIsIDIwMDgsIGF0IDE6MDMgUE0sIEdyZWcgU2hl cGhlcmQgd3JvdGU6Cgo+IFRoaXMgYW5ub3VuY2VtZW50IHdlbnQgb3V0IHRvIHRoZSBJRVRGLWFu bm91bmNlIGxpc3QsIGJ1dCBJIGRvbid0Cj4gdGhpbmsgdGhlIGZpbmFsIGRldGFpbHMgd2VyZSBj b3BpZWQgaGVyZS4KPgo+IFNvLCBkdWUgdG8gdGhlIGxhY2sgb2YgYW55IG90aGVyIGhvc3Qgc3Rl cHBpbmctdXAsIHdlJ2xsIGhvc3QgdGhlCj4gbWVldGluZyBhdCB0aGUgY2lzY28gY2FtcHVzIGlu IFNhbiBKb3NlLCBDYWxpZm9ybmlhLiBEYXRlcywgdGltZXMsCj4gbG9jYXRpb25zIGFuZCBtYXAg bGlua3MgYXJlIGJlbG93Lgo+Cj4gSSdsbCBwdXQgdG9nZXRoZXIgYSBzdHJhdyBhZ2VuZGEgZnJv bSBvdXIgZGlzY3Vzc2lvbnMgaW4gRHVibGluLCBidXQKPiBwbGVhc2UgZmVlbCBmcmVlIHRvIHNl bmQgaXRlbXMgdG8gdGhlIGxpc3QgYmVmb3JlIHRoZW4uCj4KPiBJJ2xsIGJlIG9uIHRyYXZlbCAo c29tZSB3b3JrLCBzb21lIGZ1bikgYmV0d2VlbiBTZXB0IDI5IC0gT2N0IDE4dGggYW5kCj4gd2ls bCBoYXZlIG9uIGFuZCBvZmYgZW1haWwgYWNjZXNzIHNvIHdlIHNob3VsZCBnZXQgdGhlIGFnZW5k YSBuYWlsZWQKPiBkb3duIHRoaXMgd2Vlay4KPgo+IFRoYW5rcywKPiBHcmVnCj4KPiAtLS0tLS0t LS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0KPiBGcm9tOiBJRVRGIFNlY3JldGFyaWF0 IDxpZXRmLXNlY3JldGFyaWF0QGlldGYub3JnPgo+IERhdGU6IFR1ZSwgU2VwIDE2LCAyMDA4IGF0 IDEyOjE5IFBNCj4gU3ViamVjdDogRkVDRlJBTUUgV29ya2luZyBHcm91cCBJbnRlcmltIE1lZXRp bmcsIE9jdG9iZXIgMjAtMjIsIDIwMDgsCj4gU2FuICBKb3NlLCBDQQo+IFRvOiBJRVRGIEFubm91 bmNlbWVudCBsaXN0IDxpZXRmLWFubm91bmNlQGlldGYub3JnPgo+IENjOiBnanNoZXBAZ21haWwu Y29tLCB0bWVAbXVsdGljYXN0dGVjaC5jb20sIG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bQo+Cj4KPiBUaGUgRkVDRnJhbWUgd29ya2luZyBncm91cCB3aWxsIGJlIGhhdmluZyBhbiBpbnRl cmltIG1lZXRpbmcgbmV4dCAgCj4gbW9udGgKPiBpbiBTYW4gSm9zZSwgQ2FsaWZvcm5pYS4gVGhl IGFnZW5kYSB3aWxsIGJlIGFzc2VtYmxlZCBhbmQKPiBzZW50IGluIGEgZm9sbG93LXVwIG1lc3Nh Z2UuCj4KPiBTdGFydGluZyAxMjAwIE9jdCAyMCAtIDE3MDAgT2N0IDIyCj4KPiBMb2NhdGlvbjoK Pgo+IENpc2NvIFN5c3RlbXMsIFNhbiBKb3NlLCBDQQo+Cj4gQ2lzY28gU2FuIEpvc2UsIEJ1aWxk aW5nIDE2Cj4gaHR0cDovL21hcHMuZ29vZ2xlLmNvbS9tYXBzL21zP2NsaWVudD1maXJlZm94LWEm aGw9ZW4maWU9VVRGOCZtc2E9MCZtc2lkPTEwOTQ5NjAzOTA2OTg1MjQyNTE0NC4wMDAwMDExMmRm NjBjY2E4NjE1NjYmbGw9MzcuNDA5MjMzLC0xMjEuOTI2MjA1JnNwbj0wLjAzMTY2OCwwLjAyODk2 OCZ0PWgmej0xNQo+IE1vbiwgT2N0IDIwdGgKPiBSbS4gSG9ub2x1YSBCYXksIDNyZCBmbG9vcgo+ IDEyMDAtMTcwMAo+Cj4gVHVlcywgT2N0IDIxc3QKPiBSbS4gU3VyZnNpZGUgSmV0dHksIDJuZCBm bG9vcgo+IDA5MDAtMTcwMAo+Cj4gV2VkLCBPY3QgMjJuZAo+IFJtLiBVbHV3YXR1LCAybmQgZmxv b3IKPiAwOTAwLTE3MDAKPgo+IExvY2FsIGhvdGVsIG9wdGlvbnM6Cj4gaHR0cDovL21hcHMuZ29v Z2xlLmNvbS9tYXBzP2Y9cSZobD1lbiZnZW9jb2RlPSZxPWhvdGVsJnNsbD0zNy40MDkyMzMsLTEy MS45MjYyMDUmc3Nwbj0wLjAzMTY2OCwwLjAyODk2OCZpZT1VVEY4JmxsPTM3LjQxNjUyNywtMTIx LjkyMjE5MyZzcG49MC4wMzE2NjUsMC4wMjg5NjgmdD1oJno9MTUKPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IEZlY2ZyYW1lIG1haWxpbmcgbGlzdAo+ IEZlY2ZyYW1lQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9mZWNmcmFtZQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KRmVjZnJhbWUgbWFpbGluZyBsaXN0CkZlY2ZyYW1lQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZmVjZnJhbWUK From fecframe-bounces@ietf.org Mon Sep 29 10:29:58 2008 Return-Path: X-Original-To: fecframe-archive@megatron.ietf.org Delivered-To: ietfarch-fecframe-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E553C3A693C; Mon, 29 Sep 2008 10:29:58 -0700 (PDT) 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 071D33A6870 for ; Mon, 29 Sep 2008 10:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 HqQRSOEgWb4i for ; Mon, 29 Sep 2008 10:29:57 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id ED3473A693C for ; Mon, 29 Sep 2008 10:29:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,333,1220227200"; d="scan'208";a="22316869" Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-4.cisco.com with ESMTP; 29 Sep 2008 17:29:23 +0000 Received: from dhcp-161-44-173-246.cisco.com (dhcp-161-44-173-246.cisco.com [161.44.173.246]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m8TH2Xmm026482; Mon, 29 Sep 2008 10:02:34 -0700 Message-Id: From: David R Oran To: Marshall Eubanks In-Reply-To: <883465E7-26A8-451E-98A4-EC4A27FAE4E7@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 29 Sep 2008 13:29:22 -0400 References: <20080916191902.7DD2E3A69F2@core3.amsl.com> <38c19b540809221003q16b83e98i671ce5fdc693352c@mail.gmail.com> <883465E7-26A8-451E-98A4-EC4A27FAE4E7@multicasttech.com> X-Mailer: Apple Mail (2.929.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2923; t=1222707754; x=1223571754; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[Fecframe]=20Fwd=3A=20FECFRAME=20Workin g=20Group=20Interim=20Meeting,=20October=2020-22,=202008,=20 San=20Jose,=20CA |Sender:=20 |To:=20Marshall=20Eubanks=20; bh=XNK8GPmoLSDGNoOb6o6/QC2cw/pl3/EEGdql2x1ZtHY=; b=kjsj6mbtPD5roF92Iob8XT08VOyoIGRvYfEgiC6uoyr7+Bi18b0AJuGSzP XDXeZ98XOS8zB6RKNMfvckH2f6bf+3mCqXzBCwCBQF4YjUaL6HjDyShKEcsp J77BiJ/dyz; Authentication-Results: imail.cisco.com; header.From=oran@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] Fwd: FECFRAME Working Group Interim Meeting, October 20-22, 2008, San Jose, CA 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: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Sender: fecframe-bounces@ietf.org Errors-To: fecframe-bounces@ietf.org Ck9uIFNlcCAyOSwgMjAwOCwgYXQgMToyNSBQTSwgTWFyc2hhbGwgRXViYW5rcyB3cm90ZToKCj4g SGF2ZSB3ZSBjb21lIHVwIHdpdGggYSBwcmVmZXJyZWQgaG90ZWwgZm9yIHRoaXMgPwo+Cj4gV2hh dCBhYm91dCB0aGUKPiBIb21lc3RlYWQgU2FuIEpvc2UgLSBNaWxwaXRhc+KAjgo+IDMzMCBDeXBy ZXNzIERyCj4gTWlscGl0YXMsIENBIDk1MDM1Cj4gKDQwOCkgNDMzLTk3MDAKPiBob21lc3RlYWRo b3RlbHMuY29t4oCOCj4KSXQncyBPSy4gSSd2ZSBzdGF5ZWQgdGhlcmUuClBlcnNvbmFsIHByZWZl cmVuY2UgaXMgdGhlIEhpbHRvbiBHYXJkZW4gSW5uIG9uIHRoZSBvdGhlciBzaWRlIG9mIDIzNyAg CmJlY2F1c2UgaXQncyBpbiBNY0NhcnRoeSBSYW5jaCB3aGVyZSB0aGVyZSdzIGEgQm9yZGVycyBh bmQgYSAgClN0YXJidWNrcy4gQWxzbyBhY2NlcHRhYmxlIGlzIHRoZSBTdGF5YnJpZGdlIFN1aXRl cyB3aGljaCBJIGJlbGlldmUgaXMgIApyaWdodCBhY3Jvc3MgZnJvbSB0aGUgSG9tZXN0ZWFkLgoK RGF2ZU8uCgo+IFJlZ2FyZHMKPiBNYXJzaGFsbAo+Cj4KPiBPbiBTZXAgMjIsIDIwMDgsIGF0IDE6 MDMgUE0sIEdyZWcgU2hlcGhlcmQgd3JvdGU6Cj4KPj4gVGhpcyBhbm5vdW5jZW1lbnQgd2VudCBv dXQgdG8gdGhlIElFVEYtYW5ub3VuY2UgbGlzdCwgYnV0IEkgZG9uJ3QKPj4gdGhpbmsgdGhlIGZp bmFsIGRldGFpbHMgd2VyZSBjb3BpZWQgaGVyZS4KPj4KPj4gU28sIGR1ZSB0byB0aGUgbGFjayBv ZiBhbnkgb3RoZXIgaG9zdCBzdGVwcGluZy11cCwgd2UnbGwgaG9zdCB0aGUKPj4gbWVldGluZyBh dCB0aGUgY2lzY28gY2FtcHVzIGluIFNhbiBKb3NlLCBDYWxpZm9ybmlhLiBEYXRlcywgdGltZXMs Cj4+IGxvY2F0aW9ucyBhbmQgbWFwIGxpbmtzIGFyZSBiZWxvdy4KPj4KPj4gSSdsbCBwdXQgdG9n ZXRoZXIgYSBzdHJhdyBhZ2VuZGEgZnJvbSBvdXIgZGlzY3Vzc2lvbnMgaW4gRHVibGluLCBidXQK Pj4gcGxlYXNlIGZlZWwgZnJlZSB0byBzZW5kIGl0ZW1zIHRvIHRoZSBsaXN0IGJlZm9yZSB0aGVu Lgo+Pgo+PiBJJ2xsIGJlIG9uIHRyYXZlbCAoc29tZSB3b3JrLCBzb21lIGZ1bikgYmV0d2VlbiBT ZXB0IDI5IC0gT2N0IDE4dGggIAo+PiBhbmQKPj4gd2lsbCBoYXZlIG9uIGFuZCBvZmYgZW1haWwg YWNjZXNzIHNvIHdlIHNob3VsZCBnZXQgdGhlIGFnZW5kYSBuYWlsZWQKPj4gZG93biB0aGlzIHdl ZWsuCj4+Cj4+IFRoYW5rcywKPj4gR3JlZwo+Pgo+PiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNz YWdlIC0tLS0tLS0tLS0KPj4gRnJvbTogSUVURiBTZWNyZXRhcmlhdCA8aWV0Zi1zZWNyZXRhcmlh dEBpZXRmLm9yZz4KPj4gRGF0ZTogVHVlLCBTZXAgMTYsIDIwMDggYXQgMTI6MTkgUE0KPj4gU3Vi amVjdDogRkVDRlJBTUUgV29ya2luZyBHcm91cCBJbnRlcmltIE1lZXRpbmcsIE9jdG9iZXIgMjAt MjIsIDIwMDgsCj4+IFNhbiAgSm9zZSwgQ0EKPj4gVG86IElFVEYgQW5ub3VuY2VtZW50IGxpc3Qg PGlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+Cj4+IENjOiBnanNoZXBAZ21haWwuY29tLCB0bWVAbXVs dGljYXN0dGVjaC5jb20sIG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQo+Pgo+Pgo+PiBU aGUgRkVDRnJhbWUgd29ya2luZyBncm91cCB3aWxsIGJlIGhhdmluZyBhbiBpbnRlcmltIG1lZXRp bmcgbmV4dCAgCj4+IG1vbnRoCj4+IGluIFNhbiBKb3NlLCBDYWxpZm9ybmlhLiBUaGUgYWdlbmRh IHdpbGwgYmUgYXNzZW1ibGVkIGFuZAo+PiBzZW50IGluIGEgZm9sbG93LXVwIG1lc3NhZ2UuCj4+ Cj4+IFN0YXJ0aW5nIDEyMDAgT2N0IDIwIC0gMTcwMCBPY3QgMjIKPj4KPj4gTG9jYXRpb246Cj4+ Cj4+IENpc2NvIFN5c3RlbXMsIFNhbiBKb3NlLCBDQQo+Pgo+PiBDaXNjbyBTYW4gSm9zZSwgQnVp bGRpbmcgMTYKPj4gaHR0cDovL21hcHMuZ29vZ2xlLmNvbS9tYXBzL21zP2NsaWVudD1maXJlZm94 LWEmaGw9ZW4maWU9VVRGOCZtc2E9MCZtc2lkPTEwOTQ5NjAzOTA2OTg1MjQyNTE0NC4wMDAwMDEx MmRmNjBjY2E4NjE1NjYmbGw9MzcuNDA5MjMzLC0xMjEuOTI2MjA1JnNwbj0wLjAzMTY2OCwwLjAy ODk2OCZ0PWgmej0xNQo+PiBNb24sIE9jdCAyMHRoCj4+IFJtLiBIb25vbHVhIEJheSwgM3JkIGZs b29yCj4+IDEyMDAtMTcwMAo+Pgo+PiBUdWVzLCBPY3QgMjFzdAo+PiBSbS4gU3VyZnNpZGUgSmV0 dHksIDJuZCBmbG9vcgo+PiAwOTAwLTE3MDAKPj4KPj4gV2VkLCBPY3QgMjJuZAo+PiBSbS4gVWx1 d2F0dSwgMm5kIGZsb29yCj4+IDA5MDAtMTcwMAo+Pgo+PiBMb2NhbCBob3RlbCBvcHRpb25zOgo+ PiBodHRwOi8vbWFwcy5nb29nbGUuY29tL21hcHM/Zj1xJmhsPWVuJmdlb2NvZGU9JnE9aG90ZWwm c2xsPTM3LjQwOTIzMywtMTIxLjkyNjIwNSZzc3BuPTAuMDMxNjY4LDAuMDI4OTY4JmllPVVURjgm bGw9MzcuNDE2NTI3LC0xMjEuOTIyMTkzJnNwbj0wLjAzMTY2NSwwLjAyODk2OCZ0PWgmej0xNQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBGZWNm cmFtZSBtYWlsaW5nIGxpc3QKPj4gRmVjZnJhbWVAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mZWNmcmFtZQo+Cj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGZWNmcmFtZSBtYWlsaW5nIGxpc3QKPiBGZWNm cmFtZUBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZmVj ZnJhbWUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkZl Y2ZyYW1lIG1haWxpbmcgbGlzdApGZWNmcmFtZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lCg==