From abegen@cisco.com Tue Sep 1 01:48:49 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB143A67DB for ; Tue, 1 Sep 2009 01:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 nMeTorLdnS71 for ; Tue, 1 Sep 2009 01:48:48 -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 457BF28C194 for ; Tue, 1 Sep 2009 01:48:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANp8nEqrR7MV/2dsb2JhbADDQIhBAY9eBYQa X-IronPort-AV: E=Sophos;i="4.44,311,1249257600"; d="scan'208";a="235694332" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Sep 2009 08:48:55 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n818mtX2013855 for ; Tue, 1 Sep 2009 01:48:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n818mtOX002309 for ; Tue, 1 Sep 2009 08:48: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.3959); Tue, 1 Sep 2009 01:48:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AucP Bb8f BkRb B7NX CLu1 CNCD CNup D94P EKfy FEy5 F3fm GiSV IIIE J8hb Kkl0 L/u8; 1; ZgBlAGMAZgByAGEAbQBlAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {08D22190-4A20-4F6A-8C12-AB8625787D85}; YQBiAGUAZwBlAG4AQABjAGkAcwBjAG8ALgBjAG8AbQA=; Tue, 01 Sep 2009 08:48:49 GMT; QQBiAHMAdAByAGEAYwB0ACAAcAByAG8AcABvAHMAYQBsACAAZgBvAHIAIAB0AGgAZQAgAGQAdgBiACAAYQBsAC0AZgBlAGMAIABkAHIAYQBmAHQA MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {08D22190-4A20-4F6A-8C12-AB8625787D85} Content-class: urn:content-classes:message Date: Tue, 1 Sep 2009 01:48:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A11943D@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abstract proposal for the dvb al-fec draft Thread-Index: Acoq4QYBLehgttaBQ3+vdNAS/YdMJQ== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 01 Sep 2009 08:48:55.0231 (UTC) FILETIME=[09B474F0:01CA2AE1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=795; t=1251794935; x=1252658935; 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:=20Abstract=20proposal=20for=20the=20dvb=20al-fec= 20draft |Sender:=20; bh=iUeZEOLBwb2+Bs3lLToG0PPzF/heyIV5gJiGV48GghA=; b=KlSnZh6cVOIoTRN6Yy80Xbt01J/G8AHUptHiBnUQvPLVdkB/Q1wk/rlj6u PCu/SfBF3hlG/hTOyBUM9m/MZJUAUUre0NEVORtLN4Q40Ur4OetPYXdMVo9/ han7ynRI8AZI4wZaUYsA+IItAdy4RnaVB165wRuurURNY6E98d0E8=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Fecframe] Abstract proposal for the dvb al-fec draft X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 08:48:49 -0000 Any comments, suggestions? -acbegen The Annex E of the DVB-IPTV technical specification defines an optional = Application-layer Forward Error Correction (AL-FEC) protocol to protect = the streaming media carried over RTP transport. The DVB-IPTV AL-FEC = protocol uses two layers for FEC protection. The first (base) layer is = based on the 1-D interleaved parity code. The second (enhancement) layer = is based on the Raptor code. By offering a layered approach, the DVB = AL-FEC offers a good protection against both bursty and random packet = losses at a cost of decent complexity. This document describes how one = can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved = parity code and Raptor code that have already been specified in separate = documents. From magnus.westerlund@ericsson.com Tue Sep 1 05:17:02 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CB628DC66; Tue, 1 Sep 2009 05:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.568 X-Spam-Level: X-Spam-Status: No, score=-5.568 tagged_above=-999 required=5 tests=[AWL=0.681, 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 jDRObEIElGii; Tue, 1 Sep 2009 05:17:01 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 55DA228DD6F; Tue, 1 Sep 2009 05:09:31 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-42-4a9d0f0784f8 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 2A.67.06532.70F0D9A4; Tue, 1 Sep 2009 14:09:43 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 14:09:42 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Sep 2009 14:09:42 +0200 Message-ID: <4A9D0F06.8070004@ericsson.com> Date: Tue, 01 Sep 2009 14:09:42 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Marshall Eubanks References: <4A84CD53.2030707@rogers.com> <0EE62614-11D9-4172-B868-D0EA7DEFD455@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D5409FE0943@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Sep 2009 12:09:42.0745 (UTC) FILETIME=[16953490:01CA2AFD] X-Brightmail-Tracker: AAAAAA== Cc: Tom Taylor , Colin Perkins , fecframe@ietf.org, IETF AVT WG Subject: Re: [Fecframe] [AVT] New work at the SMPTE on television contribution mediastreams over IP networks using RTP X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 12:17:02 -0000 A clarification on the process of getting formal liaisons Marshall Eubanks skrev: > - That we respond ASAP to the Wendy Aylsworth with an email stating that > we intend to work with them > and to set up liaisons. (Does this have to go through the IESG, or can > it be done informally?) The email itself > can just say we intend to do it, without even specifying names. IAB are responsible for formal liaison relations with other bodies. So they are the ones to contact if you want to establish a formal one. cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From wwwrun@core3.amsl.com Tue Sep 8 14:03:37 2009 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B3B803A691A; Tue, 8 Sep 2009 14:03:37 -0700 (PDT) To: abegen@cisco.com,stockhammer@nomor.de From: IETF Secretariat Message-Id: <20090908210337.B3B803A691A@core3.amsl.com> Date: Tue, 8 Sep 2009 14:03:37 -0700 (PDT) X-Mailman-Approved-At: Tue, 08 Sep 2009 14:07:09 -0700 Cc: tme@multicasttech.com, ipr-announce@ietf.org, fecframe@ietf.org Subject: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 21:03:37 -0000 Dear Ali Begen, Thomas Stockhammer: An IPR disclosure that pertains to your Internet-Draft entitled "DVB Application-Layer Hybrid FEC Protection" (draft-ietf-fecframe-dvb-al-fec) was submitted to the IETF Secretariat on 2009-09-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1187/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-02." The IETF Secretariat From wwwrun@core3.amsl.com Tue Sep 8 14:04:38 2009 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2AE403A6AA1; Tue, 8 Sep 2009 14:04:37 -0700 (PDT) To: watson@qualcomm.com From: IETF Secretariat Message-Id: <20090908210438.2AE403A6AA1@core3.amsl.com> Date: Tue, 8 Sep 2009 14:04:38 -0700 (PDT) X-Mailman-Approved-At: Tue, 08 Sep 2009 14:07:09 -0700 Cc: tme@multicasttech.com, ipr-announce@ietf.org, fecframe@ietf.org Subject: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-01 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 21:04:38 -0000 Dear Mark Watson: An IPR disclosure that pertains to your Internet-Draft entitled "Raptor FEC Schemes for FECFRAME" (draft-ietf-fecframe-raptor) was submitted to the IETF Secretariat on 2009-09-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1186/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-01." The IETF Secretariat From gjshep@gmail.com Mon Sep 14 07:25:01 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2181E28C157 for ; Mon, 14 Sep 2009 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, GB_I_LETTER=-2] 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 6V29EVJMEwaF for ; Mon, 14 Sep 2009 07:24:59 -0700 (PDT) Received: from mail-qy0-f178.google.com (mail-qy0-f178.google.com [209.85.221.178]) by core3.amsl.com (Postfix) with ESMTP id 646433A687B for ; Mon, 14 Sep 2009 07:24:59 -0700 (PDT) Received: by qyk8 with SMTP id 8so2428288qyk.24 for ; Mon, 14 Sep 2009 07:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=arVtkzo9tV9usTLky2b7SHmEUIwDs7lh7bLYtpL8idA=; b=rU+ub8VhJN15LEX2VZCz6SZNOI4T4lnWN2BmLt1uH+dsEx1+9qR9woPQE6esg0xo9O yM5D83Zq2RqCjk+KmgBGpQNih25m36yXqlheXiaJOFHSFRS7XrTMI076Rqp2x/HpX3TL aEoFmQUMzuMHaM6y3G/XtkpDzOOXKbm1Q9zGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=KwG5mDsXXe2m2FZNCNLw1WZy4VlIM5e78V2dJoS88RMINp7vYDkuEMGhMEEpeB/0ka qCOWrBSbKaOpapFqIDNJB/kWbiJ604F72gKjCj+kVkSkGQgYtL3444CKrCg/+VlDuv7P T8ORaJ8kvfYOoSw3Raq8Nyjjq8Sz6hd34UNRY= MIME-Version: 1.0 Received: by 10.229.27.19 with SMTP id g19mr1334971qcc.11.1252938338471; Mon, 14 Sep 2009 07:25:38 -0700 (PDT) In-Reply-To: <70662174A302471A91CEB46BA292BA87@china.huawei.com> References: <38c19b540908261210o2603c144j32367830f91bc2b6@mail.gmail.com> <70662174A302471A91CEB46BA292BA87@china.huawei.com> Date: Mon, 14 Sep 2009 07:25:38 -0700 Message-ID: <38c19b540909140725s590e4285nd57d14c186322350@mail.gmail.com> From: Greg Shepherd To: Ye-Kui Wang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] FECFrame WG Minutes IETF 75 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 14:25:01 -0000 Thanks. I've corrected the minutes and reposted. Greg On Mon, Aug 31, 2009 at 8:58 AM, Ye-Kui Wang wrote: > > A couple of more comments: > >> Zou ZiXuan (ZZ): draft-zixuan-fecframe-source-mi-0 =E2=80=93 >> presenting for colleagues >> >> AB: Is it okay for the repair packet to have the FEC payload >> header =E2=80=93 it must have something anyway =E2=80=93 but you are add= ing >> this kind of header to the source packets? >> >> ZZ: No, FEC payload header is not added to the source packet, >> it=E2=80=99s added to the repair packet and the information mapping pack= et. >> >> AB: Do we really need to consider non-framework capable receivers? >> >> ME: I don=E2=80=99t believe this violates our charter. But why are >> you doing this work? >> >> ZZ: For RTP receivers that my use FEC but do not support the >> FECFramework. >> > > What I said was something like "For RTP receivers not using FEC and not s= upport the FECFramework, e.g. RFC 3984 recievers". > >> AB: We don=E2=80=99t modify the source packets anyway so this is not >> a problem. >> >> ZZ: The draft says it is recommended though optional to >> include this data. >> >> AB: All the cenarios we are aware of already use RTP and have >> sequence numbers so don=E2=80=99t need to include this data. >> >> ME: Chairs should prepair a letter to the list for use cases >> to see if we have responses. >> >> AB: This MIU would have to go into a separate datagram. What >> happens if it is lost or reordered. We need to be protected, >> robust at the receiver side. >> > > After the above comment I said that the draft does specify ways for robus= tness, but anyway first of all we need to justify that the problem is valid= and needs a solution. I think it is valueable for readers of the minutes t= o understand better the context if this comment is added. > > BR, YK > >> -----Original Message----- >> From: fecframe-bounces@ietf.org >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd >> Sent: Wednesday, August 26, 2009 3:11 PM >> To: fecframe@ietf.org >> Subject: [Fecframe] FECFrame WG Minutes IETF 75 >> >> Please take a look at the posted minutes and send me any >> corrections/feedback. They are available on the IETF WG >> materials page but I've pasted them here for your reading pleasure. >> >> Thanks, >> Greg >> >> ----snip---- >> >> FECFrame WG Minutes, IETF 75, Stockholm, Sweden, July 27th >> >> Greg Shepherd (GS) =E2=80=93 Agenda and status >> Framework draft should be ready for last call after the meeting >> =C2=A0 =C2=A0 =C2=A0 But we missed the cake =E2=98=B9 >> >> GS (for Mark Watson) >> Draft-ietf-fecframe-framework-05: >> =C2=A0 =C2=A0 =C2=A0 Many comments on the list. Most were clarification = of >> terms. IANA considerations defined. No large changes to the >> framework per se, just mostly clarifications. Should be ready >> for last call after this meeting. >> >> Draft-ietf-fecframe-raptor-01: >> Some minor clarifications, and updated contact info. Also >> should be ready for last call after the meeting. >> >> Marshall Eubanks (ME): >> =C2=A0 =C2=A0 =C2=A0 Should we have the framework document go through th= e >> whole last-call process? >> >> GS: We had to rev it, due to so many comments on the list. So >> it will go through the last call process as it is now and >> will reflect any new comments agreed upon through the process. >> >> Ali Begen (AB): >> =C2=A0 =C2=A0 =C2=A0 Draft-ietf-fecframe-sdp-elements-03 >> =C2=A0 =C2=A0 =C2=A0 Just a couple of issues in the previous version but >> were outside this draft, regarding grouping issues in SDP. >> =C2=A0 =C2=A0 =C2=A0 MMUSIC has updated RFC3388bis so it should be going= for >> last call, and accordingly updated RFC4756bis. We now have >> what we needed for the grouping semantics. >> =C2=A0 =C2=A0 =C2=A0 I asked for last-call from MMUSIC for this draft. >> Waiting on people from this group to read and review. Please >> review so we can finalize RFC4756bis. It is a normative >> reference for the SDP-Elements draft. >> =C2=A0 =C2=A0 =C2=A0 Second issue of the SDP draft was the priority of r= epair flows. >> Previously we had a priority parameter in SDP to indicate >> decoding order of the repair flows set by the sender side. >> But =E2=80=9Cpriority=E2=80=9D word had several prior meanings. So now w= e=E2=80=99re >> going with preference level. >> It is optional. If you have multiple repair flows but you >> want your receivers to start decoding from a particular >> repair flow you can set the priority of decoding in SDP. >> Whether they follow the preference level is optional. >> =C2=A0 =C2=A0 =C2=A0 One issue that came up on the list was about a text= ual >> representation of the FEC scheme-specific information field. >> Some think it should be a human-readable ASCII field and >> others think it should be binary. We need to make a decision. >> >> ME: Are there any existing deployments? >> ME: I have a mild preference to ASCII. >> AB: I think you are an exception. >> GS: From memory the only issue which arose was around the >> deployment of a middle box that needed to decode the FEC >> Scheme-specific information field. >> AB: Still an open issue. >> >> Collin Perkins (CP): If it=E2=80=99s going into SDP in needs to be text. >> =C2=A0 =C2=A0 =C2=A0 SDP work in the IETF has always defined to be ASCII >> human-readable >> =C2=A0 =C2=A0 =C2=A0 If it=E2=80=99s something that has been defined in = another >> standards body as a binary block then we =E2=80=A6.mumble, mumble.. >> =C2=A0 =C2=A0 =C2=A0 Show the counter example >> =C2=A0 =C2=A0 =C2=A0 Ultimately it doesn=E2=80=99t make much difference.= ASCII may >> be easier to debug, binary may be more efficient =E2=80=93 pick one >> and move on. >> >> AB: The whole information field is maybe 10 digits >> >> Room: Base64 =E2=80=93 1 hand >> =C2=A0 =C2=A0 =C2=A0 ASCII =E2=80=93 7 hands >> >> AB: We=E2=80=99re going to go with ASCII. This info will be included >> in the draft then I=E2=80=99ll ask to move to last call. Of course it >> will be waiting on the framework draft. >> >> GS: On process, can we forward them all at the same time >> though they are dependent. Magnus? Can they progress together? >> >> Magnus Westerlund (MW): Once you=E2=80=99ve established WG consensus, >> you can move them in parallel. Still need individual proto write-ups. >> >> Zou ZiXuan (ZZ): draft-zixuan-fecframe-source-mi-0 =E2=80=93 >> presenting for colleagues >> >> AB: Is it okay for the repair packet to have the FEC payload >> header =E2=80=93 it must have something anyway =E2=80=93 but you are add= ing >> this kind of header to the source packets? >> >> ZZ: No, FEC payload header is not added to the source packet, >> it=E2=80=99s added to the repair packet and the information mapping pack= et. >> >> AB: Do we really need to consider non-framework capable receivers? >> >> ME: I don=E2=80=99t believe this violates our charter. But why are >> you doing this work? >> >> ZZ: For RTP receivers that my use FEC but do not support the >> FECFramework. >> >> AB: We don=E2=80=99t modify the source packets anyway so this is not >> a problem. >> >> ZZ: The draft says it is recommended though optional to >> include this data. >> >> AB: All the cenarios we are aware of already use RTP and have >> sequence numbers so don=E2=80=99t need to include this data. >> >> ME: Chairs should prepair a letter to the list for use cases >> to see if we have responses. >> >> AB: This MIU would have to go into a separate datagram. What >> happens if it is lost or reordered. We need to be protected, >> robust at the receiver side. >> >> Einat Yellin (EY): draft-galanos-fecframe-rtp-reedsolomon-mf-00 >> >> Dave Oran (DO): There is an obvious goal for >> video-conferencing which is not in your goal list which is >> low source delay. Low recovery delay obviously, but long >> block will add more delay so are you going to show how this >> also provides low source delay? >> >> EY: Some background =E2=80=93 trying to compensate for burst packet >> loss across multiple RTP flows. >> =C2=A0 =C2=A0 =C2=A0 The motivation is for video but there is nothing in= the >> draft specifying the application for video only so any RTP >> payload would work. >> >> CP: Just trying to understand the use case. So you have an >> audio flow and a video flow and you want to generate one >> repair flow for the two or is it layered video flows? So all >> the flows are generated from the same host/user? >> >> EY: Different video flows which could be layered video or >> multiple video for a 3D video. >> >> CP: Just trying to see how they would map to RTP and it would >> be easier if they were in someway related rather than separate. >> >> Bill Versteig (BV): Is this fundamentally about how they map >> mutiple flows in the FEC or is there something Reedsolomon >> specific? A method to combine flows and map to FEC is >> interesting in the broad sense outside of just Reedsolomon >> specifically. >> >> EY: We don=E2=80=99t specify the specification of Reedsolomon. >> >> ME: It would be a good design goal to allow different FEC >> schemes to be dropped into this solution. >> >> EY: It would be more useful to have one draft to define in >> the generic sense. >> >> CP: You=E2=80=99re missing the case where you have multiple SSRCs in >> one RTP session >> >> BV: let=E2=80=99s fix these stream coralation problems in a non >> FEC-specific way so that we have a framework solution and we >> won=E2=80=99t have to do this for every FEC. >> >> CP: Try to think of more general use cases provided it >> doesn=E2=80=99t break this use case. >> >> ME: If this is going to be applied in a more generic case >> then we should have some sort of registry. >> >> CP: We have a registry =E2=80=93 it=E2=80=99s the MIME-type registry. >> >> CP: You show repair window in microsecs? Perhaps RTP >> timestamp units instead, but complicated for multiple rows, >> that way it exactly maps onto the source flows. >> >> CP: Great open issues as applied to RTP >> =C2=A0 =C2=A0 =C2=A0 FEC across unrelated RTP (AVT) flows >> =C2=A0 =C2=A0 =C2=A0 Strongly encouraged to bring to the RTP WG >> =C2=A0 =C2=A0 =C2=A0 Great interest in solving these issues >> =C2=A0 =C2=A0 =C2=A0 When you start trying to apply FEC across unrelated >> sessions then you have really big problems defining what is >> what and delineating things. >> It=E2=80=99s not clear that this can be fixed within how RTP works. >> =C2=A0 =C2=A0 =C2=A0 This would fit better as an AVT draft to be reviewe= d by >> FECFrame. >> Most of the complexity is in the RTP integration, independent >> of any FEC. >> >> Vincent Roca (VR): draft-roca-fecframe-rs-01 >> >> AB: DVB was working on un-equal protection for media flows. >> What happened to that? UpperLayer-FEC >> >> Jeff Goldberg (JG): It changed chairs but should still be active >> >> AB: 1&2 multiple source flows? (Yes) >> =C2=A0 =C2=A0 =C2=A0 We should work together for a common >> =C2=A0 =C2=A0 =C2=A0 Protection of multiple source flow doc is already a= WG Item >> >> VR: LDPC-staircase >> >> VR: LDPC >> =C2=A0 =C2=A0 =C2=A0 WG Item? (to the list) >> >> AB: Pub request of interleave draft >> =C2=A0 =C2=A0 =C2=A0 1D/2D draft status? >> >> JG: LIason sent to DVB >> =C2=A0 =C2=A0 =C2=A0 DVB-AL FEC Draft >> SMTP ref 2022 / draft is incomplete >> DVB punting back to IETF $ SMPTE >> =C2=A0 =C2=A0 =C2=A0 Time to complete our work >> =C2=A0 =C2=A0 =C2=A0 No need to be contingent or wait on liason >> >> VR: General RPT payload format? >> >> CP: Definded by payload type >> =C2=A0 =C2=A0 =C2=A0 Multiple flow protection trick to go to AVT >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> > > > From vincent.roca@inrialpes.fr Mon Sep 14 07:28:23 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3892228C16B for ; Mon, 14 Sep 2009 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVTHov3i+qRj for ; Mon, 14 Sep 2009 07:28:22 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id EEDF928C16A for ; Mon, 14 Sep 2009 07:28:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,383,1249250400"; d="eml'208?scan'208,208";a="46543401" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2009 16:29:04 +0200 Message-ID: <4AAE5330.1090403@inrialpes.fr> Date: Mon, 14 Sep 2009 16:29:04 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "fecframe@ietf.org" , "Luby, Michael" , "Watson, Mark" X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------070901000408020105040209" Subject: [Fecframe] [Fwd: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-01] X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 14:28:23 -0000 This is a multi-part message in MIME format. --------------070901000408020105040209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello everybody, I am forwarding the IPR disclosure we received last week to the fecframe mailing list, so that everybody be aware of the situation. Concerning the IPR disclosure now... Mike and Mark, After looking at the disclosure, I see that the disclosure relates to an "unpublished pending patent application". Indeed, a search on various dedicated sites did not enable me to retrieve any document. Since I do want to understand your concern, could you please answer to the following questions: - Do I understand the situation correctly? - Do you plan to provide the above document(s) to the fecframe WG or to the authors, even if they are not published? - If not, do you plan to indicate which part(s) of our I-D is covered according to you, and why? Thanks in advance. Cheers, Vincent --------------070901000408020105040209 Content-Type: message/rfc822; name="Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement aboutIPR related to draft-roca-fecframe-rs-01.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Posting of IPR Disclosure related to QUALCOMM Incorporated's"; filename*1=" Statement about IPR related to draft-roca-fecframe-rs-01.em"; filename*2="l" Return-Path: Received: from murder ([unix socket]) by dwimmerlaik.inrialpes.fr (Cyrus v2.2.12) with LMTPA; Tue, 08 Sep 2009 21:02:05 +0200 X-Sieve: CMU Sieve 2.2 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id n88J245p018272; Tue, 8 Sep 2009 21:02:05 +0200 (MEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0AAAdHpkpAqmIgiWdsb2JhbACQNwGLBQEBAQoLCAkYw0CEGAU X-IronPort-AV: E=Sophos;i="4.44,353,1249250400"; d="scan'208";a="46212497" Received: from mail.ietf.org ([64.170.98.32]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 Sep 2009 21:01:58 +0200 Received: by core3.amsl.com (Postfix, from userid 30) id 66E3C28C332; Tue, 8 Sep 2009 12:01:21 -0700 (PDT) To: vincent.roca@inria.fr, jerome.lacan@isae.fr, kazuhisa@sfc.wide.ad.jp, mathieu.cunche@inria.fr, Amine.Bouabdallah@isae.fr From: IETF Secretariat Subject: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-01 Cc: housley@vigilsec.com, ipr-announce@ietf.org Message-Id: <20090908190121.66E3C28C332@core3.amsl.com> Date: Tue, 8 Sep 2009 12:01:21 -0700 (PDT) Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amine Bouabdallah: An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Solomon Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe-rs) was submitted to the IETF Secretariat on 2009-09-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1183/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-01." The IETF Secretariat --------------070901000408020105040209-- From root@core3.amsl.com Wed Sep 16 09:15:01 2009 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 82CDF28C111; Wed, 16 Sep 2009 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090916161501.82CDF28C111@core3.amsl.com> Date: Wed, 16 Sep 2009 09:15:01 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-dvb-al-fec-03.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 16:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : DVB-IPTV Application-Layer Hybrid FEC Protection Author(s) : A. Begen, T. Stockhammer Filename : draft-ietf-fecframe-dvb-al-fec-03.txt Pages : 11 Date : 2009-09-16 The Annex E of the DVB-IPTV technical specification defines an optional Application-layer Forward Error Correction (AL-FEC) protocol to protect the streaming media carried over RTP transport. The DVB- IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers a good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-dvb-al-fec-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-dvb-al-fec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-16090215.I-D@ietf.org> --NextPart-- From abegen@cisco.com Wed Sep 16 09:37:02 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E995F3A686B for ; Wed, 16 Sep 2009 09:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 d+W99Y6Fer40 for ; Wed, 16 Sep 2009 09:37:02 -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 12FEF3A684F for ; Wed, 16 Sep 2009 09:37:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAL+xsEqrR7PD/2dsb2JhbACZb60yiEwBkF0FhBc X-IronPort-AV: E=Sophos;i="4.44,398,1249257600"; d="scan'208";a="94759806" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 16 Sep 2009 16:37:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n8GGbpU1012961 for ; Wed, 16 Sep 2009 09:37:51 -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.14.3) with ESMTP id n8GGbpDH009602 for ; Wed, 16 Sep 2009 16:37:51 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.3959); Wed, 16 Sep 2009 09:37:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 16 Sep 2009 09:37:45 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A300E56@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-dvb-al-fec-03 Thread-Index: Aco25y3QdLgLWgWIQRWeXJgkNsknEAABGmsg From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 16 Sep 2009 16:37:51.0464 (UTC) FILETIME=[08672680:01CA36EC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2414; t=1253119071; x=1253983071; 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:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-ietf-fecframe-dvb-al-fec-03=20 |Sender:=20; bh=bG0xy44CjHsfFZ1d/8oLfb13eiSJCEpYIMKvg7fTMY4=; b=u6aYzD9Jv07LkdICG2jbuESUS99RatwN4UK+IW25ATjH9uKKq8Uptr8bQ+ Z3nHkcukMq55PY1iHvC/9eGp0kcdAQyrVS7IBPI/DHCpC2K0bA5Uh+DVjQS2 hHAKwvCvsm; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-dvb-al-fec-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 16:37:03 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgY29tbWVudHMgd2UgcmVjZWl2ZWQgZHVyaW5nIHRo ZSBpbml0aWFsIFdHTEMgcHJvY2Vzcy4gUGxlYXNlIHJldmlldyB0aGlzIG9uZSBhbmQgbGV0IHVz IGtub3cgaWYgeW91IGhhdmUgZnVydGhlciBjb21tZW50cy4NCg0KaHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1pZXRmLWZlY2ZyYW1lLWR2Yi1hbC1mZWMtMDMudHh0DQoNCkNoYWlycywNCkNv dWxkIHlvdSBzdGFydCBhIG5ldyBXR0xDIHByb2Nlc3M/DQoNClRoYW5rcywNCi1hY2JlZ2VuDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRv b2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBTZXB0 ZW1iZXIgMTYsIDIwMDkgMTI6MDIgUE0NClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCkNjOiBz dG9ja2hhbW1lckBub21vci5kZQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1pZXRmLWZlY2ZyYW1lLWR2Yi1hbC1mZWMtMDMgDQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWlldGYtZmVjZnJhbWUtZHZiLWFsLWZlYy0wMy50eHQgaGFzIGJlZW4gc3Vj Y2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdlbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1mZWNmcmFtZS1kdmItYWwtZmVjDQpS ZXZpc2lvbjoJIDAzDQpUaXRsZToJCSBEVkItSVBUViBBcHBsaWNhdGlvbi1MYXllciBIeWJyaWQg RkVDIFByb3RlY3Rpb24NCkNyZWF0aW9uX2RhdGU6CSAyMDA5LTA5LTE2DQpXRyBJRDoJCSBmZWNm cmFtZQ0KTnVtYmVyX29mX3BhZ2VzOiAxMQ0KDQpBYnN0cmFjdDoNClRoZSBBbm5leCBFIG9mIHRo ZSBEVkItSVBUViB0ZWNobmljYWwgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGFuDQpvcHRpb25hbCBB cHBsaWNhdGlvbi1sYXllciBGb3J3YXJkIEVycm9yIENvcnJlY3Rpb24gKEFMLUZFQykgcHJvdG9j b2wNCnRvIHByb3RlY3QgdGhlIHN0cmVhbWluZyBtZWRpYSBjYXJyaWVkIG92ZXIgUlRQIHRyYW5z cG9ydC4gIFRoZSBEVkItDQpJUFRWIEFMLUZFQyBwcm90b2NvbCB1c2VzIHR3byBsYXllcnMgZm9y IEZFQyBwcm90ZWN0aW9uLiAgVGhlIGZpcnN0DQooYmFzZSkgbGF5ZXIgaXMgYmFzZWQgb24gdGhl IDEtRCBpbnRlcmxlYXZlZCBwYXJpdHkgY29kZS4gIFRoZSBzZWNvbmQNCihlbmhhbmNlbWVudCkg bGF5ZXIgaXMgYmFzZWQgb24gdGhlIFJhcHRvciBjb2RlLiAgQnkgb2ZmZXJpbmcgYQ0KbGF5ZXJl ZCBhcHByb2FjaCwgdGhlIERWQi1JUFRWIEFMLUZFQyBwcm90b2NvbCBvZmZlcnMgYSBnb29kDQpw cm90ZWN0aW9uIGFnYWluc3QgYm90aCBidXJzdHkgYW5kIHJhbmRvbSBwYWNrZXQgbG9zc2VzIGF0 IGEgY29zdCBvZg0KZGVjZW50IGNvbXBsZXhpdHkuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBo b3cgb25lIGNhbiBpbXBsZW1lbnQgdGhlDQpEVkItSVBUViBBTC1GRUMgcHJvdG9jb2wgYnkgdXNp bmcgdGhlIDEtRCBpbnRlcmxlYXZlZCBwYXJpdHkgY29kZSBhbmQNClJhcHRvciBjb2RlIHRoYXQg aGF2ZSBhbHJlYWR5IGJlZW4gc3BlY2lmaWVkIGluIHNlcGFyYXRlIGRvY3VtZW50cy4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From tme@americafree.tv Thu Sep 17 06:10:05 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD7A28C260 for ; Thu, 17 Sep 2009 06:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 hTbN9UIYhdM9 for ; Thu, 17 Sep 2009 06:10:05 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id B6B913A6AFA for ; Thu, 17 Sep 2009 06:10:03 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 65FB94BF5590 for ; Thu, 17 Sep 2009 09:10:55 -0400 (EDT) Message-Id: From: Marshall Eubanks To: fecframe@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Sep 2009 09:10:55 -0400 References: <20090909194505.8F1CD28C2DD@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [Fecframe] Fwd: IESG Statement on Copyright X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 13:10:05 -0000 Note well. Begin forwarded message: > From: IESG Secretary > Date: September 9, 2009 3:45:05 PM EDT > To: ietf-announce@ietf.org > Cc: wgchairs@ietf.org, ietf@ietf.org > Subject: IESG Statement on Copyright > Reply-To: iesg@ietf.org > > This IESG Statement obsoletes all earlier IESG Statements regarding > Copyright statements in MIB and PIB Modules. > > The IESG is providing this guidance to align current practice with > RFC 5377, RFC 5378, and the resulting IETF Trust Legal Provisions > (TLP) > (http://trustee.ietf.org/license-info). > > IETF Contributions and IETF Documents often include code components > that are intended to be directly processed by a computer. Examples of > such code components include ABNF definitions, XML Schemas, XML DTDs, > XML RelaxNG definitions, tables of values, MIBs, PIBs, ASN.1, and > classical programming source code. The IETF Trust maintains a list of > code component types. A link to this list can be found on this web > page: http://trustee.ietf.org/license-info. > > In addition to the code component types listed, any text found between > the markers <CODE BEGINS> and <CODE ENDS> shall be > considered > a code component. Authors may wish to use these markers as clear > delimiters of code components. > > Authors are encouraged to collect code into a separate section or > appendix. > > The TLP requires copyright notice in IETF Documents, but not > necessarily > in each code component within an IETF Document. Authors may choose to > include a copyright notice as a comment when a significant amount of > code is collected together. For example, authors may include a > copyright notice in a comment as part of an ASN.1 module or a > representation of a classical programming language file. If IETF > Document authors choose to include a code component copyright notice > comment, they must follow the guidance in Section 6.d of the TLP. > Implementors that extract any code component from the IETF Document > must > include the BSD license text as described in Section 4.e of the TLP. > From gjshep@gmail.com Thu Sep 17 06:46:00 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176473A677E for ; Thu, 17 Sep 2009 06:46:00 -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 iLDW7gkJ57K7 for ; Thu, 17 Sep 2009 06:45:59 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 4896E3A685C for ; Thu, 17 Sep 2009 06:45:59 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 8so11840qwh.31 for ; Thu, 17 Sep 2009 06:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=FYL2TVRCiDFICbDp4bGdtCak7wvJ6PVbmoqO6BDM11w=; b=DeG43jhgcCpnK+r6XGya9QLLPr5pEtbhIP8NuoDo+/78ZHjc1R6QkNsTHN6iFe0xwL TTu/ALce6hUBBsLm8W7LXdOMV+++1Fv/seN0MzakHWbXVV9bT+nfi8rCbkUB4SXSZeBZ MuDgCgDwovqiniudBsp/Z25vzsNkfpGHRq+Lk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=d1ATC5NKeAPeB1SLBjRd5buSMGJjiu88AsYIl0dedGc0ZU0CdAx3eM9SW82DPnoFoN 9xpc59lCfCAkXM2m9XFNQfE9PKIOLuaccsWADwg6ApCeoj9aG4HHg266t/KAQ9m6QqTT sokPLouHffx8U7dVBh2pwsoCxy3mgVDT8Sy4g= MIME-Version: 1.0 Received: by 10.229.9.130 with SMTP id l2mr14003qcl.41.1253195207267; Thu, 17 Sep 2009 06:46:47 -0700 (PDT) Date: Thu, 17 Sep 2009 06:46:47 -0700 Message-ID: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 13:46:00 -0000 I'm following-up with action items from our last WG meeting in Stockholm. We wanted to get some feedback from the list on potential use cases for the proposal: http://www.ietf.org/id/draft-zixuan-fecframe-source-mi-00.txt ..and to ask if the WG members feels this is a draft we want to take on as a FECFrame WG Item. Please respond by the end of next week - Sept 25th. Thanks, Greg From abegen@cisco.com Thu Sep 17 06:55:35 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA7528C152 for ; Thu, 17 Sep 2009 06:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 LSgk1IhJ8npX for ; Thu, 17 Sep 2009 06:55:34 -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 7E6BC28C11E for ; Thu, 17 Sep 2009 06:55:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAvdsUqrR7PD/2dsb2JhbADFcIhOAZBABYQY X-IronPort-AV: E=Sophos;i="4.44,403,1249257600"; d="scan'208";a="205674754" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 17 Sep 2009 13:56:26 +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 n8HDuQKQ027382; Thu, 17 Sep 2009 06:56:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8HDuQ9h020263; Thu, 17 Sep 2009 13:56:26 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.3959); Thu, 17 Sep 2009 06:56:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Sep 2009 06:55:45 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> In-Reply-To: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] draft-zixuan-fecframe-source-mi ?? Thread-Index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/w References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 17 Sep 2009 13:56:26.0115 (UTC) FILETIME=[A5E5ED30:01CA379E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1145; t=1253195786; x=1254059786; 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]=20draft-zixuan-fecframe-sour ce-mi=20?? |Sender:=20; bh=amNiITPGsz9EcKFZG1dH/hqSi9GsIWJd/N6wlRjW6Pw=; b=AonAkvVTt5s334ZDoui0HuQM8+vznMNVQqHCol3jf3nI3tAfzo4BDIC+Cr mUHiwK+xSpqOR6IBNVzUFiP/hwFxE51xLuEXXN86LoTbqhvD8DEDv6J3tugv 5FZlGGhJGd; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 13:55:35 -0000 There were several comments from myself and some others during the = meeting about the applicability of this draft, the validity of the = problem and some details on the bits on the wire. Will the authors be addressing those comments with a revision before we = move forward? -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Greg > Shepherd > Sent: Thursday, September 17, 2009 9:47 AM > To: fecframe@ietf.org > Subject: [Fecframe] draft-zixuan-fecframe-source-mi ?? >=20 > I'm following-up with action items from our last WG meeting in > Stockholm. We wanted to get some feedback from the list on potential > use cases for the proposal: >=20 > http://www.ietf.org/id/draft-zixuan-fecframe-source-mi-00.txt >=20 > ..and to ask if the WG members feels this is a draft we want to take > on as a FECFrame WG Item. >=20 > Please respond by the end of next week - Sept 25th. >=20 > Thanks, > Greg > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From tendyntu@huawei.com Fri Sep 18 03:51:25 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B235C28C1A8 for ; Fri, 18 Sep 2009 03:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph-WkC7R3OPo for ; Fri, 18 Sep 2009 03:51:24 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 545C13A67ED for ; Fri, 18 Sep 2009 03:51:24 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ500K8OY6VIV@szxga03-in.huawei.com> for fecframe@ietf.org; Fri, 18 Sep 2009 18:52:07 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ5009BCY6VQ2@szxga03-in.huawei.com> for fecframe@ietf.org; Fri, 18 Sep 2009 18:52:07 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ500LDVY6VKX@szxml06-in.huawei.com> for fecframe@ietf.org; Fri, 18 Sep 2009 18:52:07 +0800 (CST) Date: Fri, 18 Sep 2009 18:52:07 +0800 From: zouzixuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , gjshep@gmail.com, fecframe@ietf.org Message-id: <00ad01ca384e$10f8b620$32ea2260$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQA= References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 10:51:25 -0000 Hi, All The followings are from minutes of the last 75th IEFT meeting > AB: We don't modify the source packets anyway so this is not > a problem. [zou] In order to answer the concerns in the last meeting about why we brought up this draft, I think we should first clarify the need of Source Payload ID argued by Ali's comments as the above. We gave the following scenario/explanation to show the need of Source Payload ID. 1) Combined protection of multiple source flows For the case where one FEC repair Flow providing protection to multiple source flow, the explicit Source FEC Payload ID, according to the "draft-fecframe-framework", has to be used no matter if the protected source flows is "sequenced" or not. 2) Single Sequenced Flow Case Per draft-fecframe-raptor, the FEC scheme defined for "Single Sequenced Flow" protection works well for source packet in fixed size without explicit source payload ID. But for the source packet of variable size, the source packets must be padded with zeros to occupy the same amount of space (equals to the length of Source Packet Information) in the source block for FEC encoding/decoding. The padded bytes are not sent, but require on the receiver side that the amount of repair data for recovering a lost source packet equals to the length of Source Packet Information. But this probably has a downside: the amount of repair data needed would be much more than the case where padding is not used, and thus impact the FEC decoding efficiency. So an alternate to handle this issue is to not use padding, and therefore the Source Payload ID is still needed for making FEC works with variable source packet size. > AB: Do we really need to consider non-framework capable receivers? > > ME: I don't believe this violates our charter. But why are > you doing this work? > > ZZ: For RTP receivers that my use FEC but do not support the > FECFramework. [zou] As we had answered Marshall, the FECFramework source packet with Source Payload ID lead to incompatibility to those receivers not align with this Framework. The draft "draft-zixuan-fecframe-source-miu" is proposed for solving this issue. Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Thursday, September 17, 2009 9:56 PM To: gjshep@gmail.com; fecframe@ietf.org Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? There were several comments from myself and some others during the meeting about the applicability of this draft, the validity of the problem and some details on the bits on the wire. Will the authors be addressing those comments with a revision before we move forward? -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg > Shepherd > Sent: Thursday, September 17, 2009 9:47 AM > To: fecframe@ietf.org > Subject: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > I'm following-up with action items from our last WG meeting in > Stockholm. We wanted to get some feedback from the list on potential > use cases for the proposal: > > http://www.ietf.org/id/draft-zixuan-fecframe-source-mi-00.txt > > ..and to ask if the WG members feels this is a draft we want to take > on as a FECFrame WG Item. > > Please respond by the end of next week - Sept 25th. > > 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 abegen@cisco.com Fri Sep 18 04:04:01 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AE1A3A69C1 for ; Fri, 18 Sep 2009 04:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 IFFMLNeZuXA3 for ; Fri, 18 Sep 2009 04:04:00 -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 F410F3A6982 for ; Fri, 18 Sep 2009 04:03:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALIGs0qrR7MV/2dsb2JhbAC0X4hQAZApBYQc X-IronPort-AV: E=Sophos;i="4.44,409,1249257600"; d="scan'208";a="243732984" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 18 Sep 2009 11:04:54 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8IB4rVR020794; Fri, 18 Sep 2009 04:04:53 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8IB4rwb023524; Fri, 18 Sep 2009 11:04:53 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 04:04:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Sep 2009 04:04:01 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> In-Reply-To: <00ad01ca384e$10f8b620$32ea2260$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] draft-zixuan-fecframe-source-mi ?? Thread-Index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oA== References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> From: "Ali C. Begen (abegen)" To: "zouzixuan" , , X-OriginalArrivalTime: 18 Sep 2009 11:04:53.0698 (UTC) FILETIME=[D98D7A20:01CA384F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5258; t=1253271893; x=1254135893; 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]=20draft-zixuan-fecframe-sour ce-mi=20?? |Sender:=20; bh=DEV288Js5eZWpxNSb/umkJxwsU+RFR0FXwW9Nvy74pI=; b=jz5TNmmFsqvL1Xo1bCFwoPteu0ZNQfCGgyd4rlv/796GdSt/jrEy2twnWA DrhEunYET92pmL8r0g2rHxALPRXQ8mvnbn4WQNzhEQomvqFb8H+2NodLtqir hcmtGE48eGlBIMWY1AcTXA7pVjgbEd7yNfqV3+0dLv500IzVHjWXk=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 11:04:01 -0000 > 1) Combined protection of multiple source flows >=20 > For the case where one FEC repair Flow providing protection to = multiple > source flow, the explicit Source FEC Payload ID, according to the > "draft-fecframe-framework", has to be used no matter if the protected = source > flows is "sequenced" or not. Where does it say this? In section 6.3., it says: The FEC Scheme determines whether the Explicit = Source FEC Payload ID field is required. This determination is specific = to each transport flow. So, it makes a difference whether the flow is sequenced or not. =20 > 2) Single Sequenced Flow Case >=20 > Per draft-fecframe-raptor, the FEC scheme defined for "Single = Sequenced > Flow" protection works well for source packet in fixed size without = explicit > source payload ID. >=20 > But for the source packet of variable size, the source packets must be > padded with zeros to occupy the same amount of space (equals to the = length > of Source Packet Information) in the source block for FEC = encoding/decoding. > The padded bytes are not sent, but require on the receiver side that = the > amount of repair data for recovering a lost source packet equals to = the > length of Source Packet Information. But this probably has a downside: = the > amount of repair data needed would be much more than the case where = padding > is not used, and thus impact the FEC decoding efficiency. So an = alternate to I am not sure how inefficient padding is. Is it really a better = trade-off to use source fec payload id?=20 > handle this issue is to not use padding, and therefore the Source = Payload ID > is still needed for making FEC works with variable source packet size. >=20 >=20 > > AB: Do we really need to consider non-framework capable receivers? > > > > ME: I don't believe this violates our charter. But why are > > you doing this work? > > > > ZZ: For RTP receivers that my use FEC but do not support the > > FECFramework. >=20 > [zou] As we had answered Marshall, the FECFramework source packet with > Source Payload ID lead to incompatibility to those receivers not align = with > this Framework. The draft "draft-zixuan-fecframe-source-miu" is = proposed for > solving this issue. I am still not getting this. If RTP is used, there is no need to modify = the source packets, so existing RTP receivers will have no problems. = But, is it your goal to make them (i.e., the RTP receivers that don't = support the framework) still benefit from the fec packets generated by = an FEC scheme (which is based on framework)?=20 -acbegen =20 > Zou ZiXuan, Senior Research Staff > Media & Communication Lab > HUAWEI TECHNOLOGIES CO.,LTD. >=20 > Address: Huawei Industrial Base > Bantian Longgang > Shenzhen 518129, P.R.China > Tel: +86 0755 28789364 > Fax: +86 0755 28788317 > E-mail: tendyntu@huawei.com > www.huawei.com > = -------------------------------------------------------------------------= --- > --------------------------------------------------------- > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed = above. Any > use of the > information contained herein in any way (including, but not limited = to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, = please > notify the sender by > phone or email immediately and delete it! >=20 >=20 > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf > Of Ali C. Begen (abegen) > Sent: Thursday, September 17, 2009 9:56 PM > To: gjshep@gmail.com; fecframe@ietf.org > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? >=20 > There were several comments from myself and some others during the = meeting > about the applicability of this draft, the validity of the problem and = some > details on the bits on the wire. >=20 > Will the authors be addressing those comments with a revision before = we move > forward? >=20 > -acbegen >=20 > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On > Behalf Of Greg > > Shepherd > > Sent: Thursday, September 17, 2009 9:47 AM > > To: fecframe@ietf.org > > Subject: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > I'm following-up with action items from our last WG meeting in > > Stockholm. We wanted to get some feedback from the list on potential > > use cases for the proposal: > > > > http://www.ietf.org/id/draft-zixuan-fecframe-source-mi-00.txt > > > > ..and to ask if the WG members feels this is a draft we want to take > > on as a FECFrame WG Item. > > > > Please respond by the end of next week - Sept 25th. > > > > 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 tendyntu@huawei.com Sat Sep 19 00:51:19 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB0683A69FC for ; Sat, 19 Sep 2009 00:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 713pxIg1vpwr for ; Sat, 19 Sep 2009 00:51:18 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 4CB0E3A67E5 for ; Sat, 19 Sep 2009 00:51:18 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ700JNDKIROJ@szxga02-in.huawei.com> for fecframe@ietf.org; Sat, 19 Sep 2009 15:52:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ700A3LKIRSP@szxga02-in.huawei.com> for fecframe@ietf.org; Sat, 19 Sep 2009 15:52:03 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ700GASKIRU1@szxml04-in.huawei.com> for fecframe@ietf.org; Sat, 19 Sep 2009 15:52:03 +0800 (CST) Date: Sat, 19 Sep 2009 15:52:02 +0800 From: zouzixuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , gjshep@gmail.com, fecframe@ietf.org Message-id: <00ce01ca38fe$1364eb30$3a2ec190$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZg References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 07:51:19 -0000 Hi, Ali inline Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, September 18, 2009 7:04 PM > To: zouzixuan; gjshep@gmail.com; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > 1) Combined protection of multiple source flows > > > > For the case where one FEC repair Flow providing protection to multiple > > source flow, the explicit Source FEC Payload ID, according to the > > "draft-fecframe-framework", has to be used no matter if the protected > source > > flows is "sequenced" or not. > > Where does it say this? > > In section 6.3., it says: The FEC Scheme determines whether the Explicit Source > FEC Payload ID field is required. This determination is specific to each > transport flow. > > So, it makes a difference whether the flow is sequenced or not. The above case is not from the framework draft. I mean in this case, the Source FEC Payload ID specified in the fecframework draft is a must, at least applies to the FEC schemes involved in the scope of IETF, such as LDPC, RS, Raptor and 1-D Interleaved Parity FEC. > > > 2) Single Sequenced Flow Case > > > > Per draft-fecframe-raptor, the FEC scheme defined for "Single Sequenced > > Flow" protection works well for source packet in fixed size without explicit > > source payload ID. > > > > But for the source packet of variable size, the source packets must be > > padded with zeros to occupy the same amount of space (equals to the length > > of Source Packet Information) in the source block for FEC encoding/decoding. > > The padded bytes are not sent, but require on the receiver side that the > > amount of repair data for recovering a lost source packet equals to the > > length of Source Packet Information. But this probably has a downside: the > > amount of repair data needed would be much more than the case where > padding > > is not used, and thus impact the FEC decoding efficiency. So an alternate to > > I am not sure how inefficient padding is. Is it really a better trade-off to use > source fec payload id? As I explained above, in principle, it is better to use source fec payload id. -zou > > > handle this issue is to not use padding, and therefore the Source Payload ID > > is still needed for making FEC works with variable source packet size. > > > > > > > AB: Do we really need to consider non-framework capable receivers? > > > > > > ME: I don't believe this violates our charter. But why are > > > you doing this work? > > > > > > ZZ: For RTP receivers that my use FEC but do not support the > > > FECFramework. > > > > [zou] As we had answered Marshall, the FECFramework source packet with > > Source Payload ID lead to incompatibility to those receivers not align with > > this Framework. The draft "draft-zixuan-fecframe-source-miu" is proposed for > > solving this issue. > > I am still not getting this. If RTP is used, there is no need to modify the source > packets, so existing RTP receivers will have no problems. But, is it your goal to > make them (i.e., the RTP receivers that don't support the framework) still > benefit from the fec packets generated by an FEC scheme (which is based on > framework)? That is the reason why we give the above case of multiple source flows. There is need to modify the source-packets in that case, as explicit source payload ID is needed. -zou > > -acbegen > > > > Zou ZiXuan, Senior Research Staff > > Media & Communication Lab > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > Address: Huawei Industrial Base > > Bantian Longgang > > Shenzhen 518129, P.R.China > > Tel: +86 0755 28789364 > > Fax: +86 0755 28788317 > > E-mail: tendyntu@huawei.com > > www.huawei.com > > ---------------------------------------------------------------------------- > > --------------------------------------------------------- > > This e-mail and its attachments contain confidential information from > > HUAWEI, which > > is intended only for the person or entity whose address is listed above. Any > > use of the > > information contained herein in any way (including, but not limited to, > > total or partial > > disclosure, reproduction, or dissemination) by persons other than the > > intended > > recipient(s) is prohibited. If you receive this e-mail in error, please > > notify the sender by > > phone or email immediately and delete it! > > > > > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf > > Of Ali C. Begen (abegen) > > Sent: Thursday, September 17, 2009 9:56 PM > > To: gjshep@gmail.com; fecframe@ietf.org > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > There were several comments from myself and some others during the > meeting > > about the applicability of this draft, the validity of the problem and some > > details on the bits on the wire. > > > > Will the authors be addressing those comments with a revision before we > move > > forward? > > > > -acbegen > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > > Behalf Of Greg > > > Shepherd > > > Sent: Thursday, September 17, 2009 9:47 AM > > > To: fecframe@ietf.org > > > Subject: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > I'm following-up with action items from our last WG meeting in > > > Stockholm. We wanted to get some feedback from the list on potential > > > use cases for the proposal: > > > > > > http://www.ietf.org/id/draft-zixuan-fecframe-source-mi-00.txt > > > > > > ..and to ask if the WG members feels this is a draft we want to take > > > on as a FECFrame WG Item. > > > > > > Please respond by the end of next week - Sept 25th. > > > > > > 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 abegen@cisco.com Sat Sep 19 01:44:29 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA1828C0DE for ; Sat, 19 Sep 2009 01:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 AVNBOx9t9xtE for ; Sat, 19 Sep 2009 01:44:28 -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 181993A687C for ; Sat, 19 Sep 2009 01:44:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGM3tEqrR7MV/2dsb2JhbAC1fIhQAY9eBYQb X-IronPort-AV: E=Sophos;i="4.44,414,1249257600"; d="scan'208";a="244091643" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 19 Sep 2009 08:45:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8J8jOSL013181; Sat, 19 Sep 2009 01:45:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8J8jOIt017899; Sat, 19 Sep 2009 08:45:24 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.3959); Sat, 19 Sep 2009 01:45:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Sep 2009 01:45:20 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <00ce01ca38fe$1364eb30$3a2ec190$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] draft-zixuan-fecframe-source-mi ?? Thread-Index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXA= References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> From: "Ali C. Begen (abegen)" To: "zouzixuan" , , X-OriginalArrivalTime: 19 Sep 2009 08:45:23.0966 (UTC) FILETIME=[873779E0:01CA3905] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7356; t=1253349924; x=1254213924; 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]=20draft-zixuan-fecframe-sour ce-mi=20?? |Sender:=20; bh=mNiDzBt8GGEr03lUr2ZCmxouCQUyZcxiBpfwWM5USBw=; b=L/4tPKzTOcQQxKaBxQS6MONPvFNsxCWAJyPrVuXvVSuDxie4+m1VnlrcCu sFB2NTWUOSg+sAftPRHjyTBwTN03DzdU5xKRBmG3TO+1b/Fy1H4YGpvvy4Tw TaiKaoVs+0etchpDQBPCbd9n6xMyi+A67mA9CpuCaoVMrX2OvoFAg=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 08:44:29 -0000 > > > 1) Combined protection of multiple source flows > > > > > > For the case where one FEC repair Flow providing protection to = multiple > > > source flow, the explicit Source FEC Payload ID, according to the > > > "draft-fecframe-framework", has to be used no matter if the = protected > > source > > > flows is "sequenced" or not. > > > > Where does it say this? >=20 > > > > In section 6.3., it says: The FEC Scheme determines whether the = Explicit > Source > > FEC Payload ID field is required. This determination is specific to = each > > transport flow. > > > > So, it makes a difference whether the flow is sequenced or not. >=20 > The above case is not from the framework draft. I mean in this case, = the > Source FEC Payload ID specified in the fecframework draft is a must, = at In which cases you are considering is the *explicit* source payload id a = must? > least applies to the FEC schemes involved in the scope of IETF, such = as > LDPC, RS, Raptor and 1-D Interleaved Parity FEC. Source fec payload is of course required but in sequenced streams, it is = already in the source itself. What else do we need? =20 > > > > > 2) Single Sequenced Flow Case > > > > > > Per draft-fecframe-raptor, the FEC scheme defined for "Single = Sequenced > > > Flow" protection works well for source packet in fixed size = without > explicit > > > source payload ID. > > > > > > But for the source packet of variable size, the source packets = must be > > > padded with zeros to occupy the same amount of space (equals to = the > length > > > of Source Packet Information) in the source block for FEC > encoding/decoding. > > > The padded bytes are not sent, but require on the receiver side = that the > > > amount of repair data for recovering a lost source packet equals = to the > > > length of Source Packet Information. But this probably has a = downside: > the > > > amount of repair data needed would be much more than the case = where > > padding > > > is not used, and thus impact the FEC decoding efficiency. So an > alternate to > > > > I am not sure how inefficient padding is. Is it really a better = trade-off > to use > > source fec payload id? > As I explained above, in principle, it is better to use source fec = payload > id. I am sorry, I am not following this. > -zou > > > > > handle this issue is to not use padding, and therefore the Source > Payload ID > > > is still needed for making FEC works with variable source packet = size. > > > > > > > > > > AB: Do we really need to consider non-framework capable = receivers? > > > > > > > > ME: I don't believe this violates our charter. But why are > > > > you doing this work? > > > > > > > > ZZ: For RTP receivers that my use FEC but do not support the > > > > FECFramework. > > > > > > [zou] As we had answered Marshall, the FECFramework source packet = with > > > Source Payload ID lead to incompatibility to those receivers not = align > with > > > this Framework. The draft "draft-zixuan-fecframe-source-miu" is = proposed > for > > > solving this issue. > > > > I am still not getting this. If RTP is used, there is no need to = modify > the source > > packets, so existing RTP receivers will have no problems. But, is it = your > goal to > > make them (i.e., the RTP receivers that don't support the framework) = still > > benefit from the fec packets generated by an FEC scheme (which is = based on > > framework)? >=20 > That is the reason why we give the above case of multiple source = flows. > There is need to modify the source-packets in that case, as explicit = source > payload ID is needed. First of all, there were concerns raised in the meeting regarding the = use of multiple source RTP streams in FEC encoding. Not all RTP streams = can be simply encoded in the same FEC source block because of the clock = issues. Assuming that you are using source RTP streams that could be combined, = you still don't need explicit source payload IDs. Finally, for RTP = receivers that do not support the FEC framework, you can write an RTP = payload format draft as I did for the 1-d interleaved fec. Using an fec = scheme based on the framework is not really a requirement and does not = make any sense for those who don't support the framework anyway. Cheers, -acbegen > -zou > > > > -acbegen > > > > > > > Zou ZiXuan, Senior Research Staff > > > Media & Communication Lab > > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > > > Address: Huawei Industrial Base > > > Bantian Longgang > > > Shenzhen 518129, P.R.China > > > Tel: +86 0755 28789364 > > > Fax: +86 0755 28788317 > > > E-mail: tendyntu@huawei.com > > > www.huawei.com > > > > = -------------------------------------------------------------------------= --- > > > --------------------------------------------------------- > > > This e-mail and its attachments contain confidential information = from > > > HUAWEI, which > > > is intended only for the person or entity whose address is listed = above. > Any > > > use of the > > > information contained herein in any way (including, but not = limited to, > > > total or partial > > > disclosure, reproduction, or dissemination) by persons other than = the > > > intended > > > recipient(s) is prohibited. If you receive this e-mail in error, = please > > > notify the sender by > > > phone or email immediately and delete it! > > > > > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On > > Behalf > > > Of Ali C. Begen (abegen) > > > Sent: Thursday, September 17, 2009 9:56 PM > > > To: gjshep@gmail.com; fecframe@ietf.org > > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > There were several comments from myself and some others during the > > meeting > > > about the applicability of this draft, the validity of the problem = and > some > > > details on the bits on the wire. > > > > > > Will the authors be addressing those comments with a revision = before we > > move > > > forward? > > > > > > -acbegen > > > > > > > -----Original Message----- > > > > From: fecframe-bounces@ietf.org = [mailto:fecframe-bounces@ietf.org] On > > > Behalf Of Greg > > > > Shepherd > > > > Sent: Thursday, September 17, 2009 9:47 AM > > > > To: fecframe@ietf.org > > > > Subject: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > I'm following-up with action items from our last WG meeting in > > > > Stockholm. We wanted to get some feedback from the list on = potential > > > > use cases for the proposal: > > > > > > > > http://www.ietf.org/id/draft-zixuan-fecframe-source-mi-00.txt > > > > > > > > ..and to ask if the WG members feels this is a draft we want to = take > > > > on as a FECFrame WG Item. > > > > > > > > Please respond by the end of next week - Sept 25th. > > > > > > > > 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 tendyntu@huawei.com Tue Sep 22 20:14:30 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59C43A659B for ; Tue, 22 Sep 2009 20:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FexhKxdo97PM for ; Tue, 22 Sep 2009 20:14:29 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 002A53A68FA for ; Tue, 22 Sep 2009 20:14:21 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE00AOWMDGQ2@szxga02-in.huawei.com> for fecframe@ietf.org; Wed, 23 Sep 2009 11:15:16 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE00EUIMDGND@szxga02-in.huawei.com> for fecframe@ietf.org; Wed, 23 Sep 2009 11:15:16 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQE006SWMDGGM@szxml06-in.huawei.com> for fecframe@ietf.org; Wed, 23 Sep 2009 11:15:16 +0800 (CST) Date: Wed, 23 Sep 2009 11:15:16 +0800 From: zouzixuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , fecframe@ietf.org Message-id: <000601ca3bfc$1289f970$379dec50$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsA== References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 03:14:31 -0000 Hi, Ali > > The above case is not from the framework draft. I mean in this case, the > > Source FEC Payload ID specified in the fecframework draft is a must, at > > In which cases you are considering is the *explicit* source payload id a must? In case of a RTP Video flow and its coupled RTP audio flow within a RTP session. -zou > > > > [zou] As we had answered Marshall, the FECFramework source packet > with > > > > Source Payload ID lead to incompatibility to those receivers not align > > with > > > > this Framework. The draft "draft-zixuan-fecframe-source-miu" is > proposed > > for > > > > solving this issue. > > > > > > I am still not getting this. If RTP is used, there is no need to modify > > the source > > > packets, so existing RTP receivers will have no problems. We think there is still need to modify the source packet if RTP is used, given "the case of a RTP Video flow and its coupled RTP audio flow within a RTP session " stands. -zou But, is it your > > goal to > > > make them (i.e., the RTP receivers that don't support the framework) still > > > benefit from the fec packets generated by an FEC scheme (which is based > on > > > framework)? Nope, our goal is to make those (RTP receiver) who don't support the framework still can parse and process the source packets. That's why we brought up this draft, proposing a packet format for carrying the source payload ID in a flow separated from the source packet flow for sequence-flow case, where source packet is not modified. Your point against our draft, in my understanding, is that the source payload id is essentially not necessary for RTP (i.e. sequence flow). IMO, I do not agree with your point. So I raised the above case - a Video RTP flow and its coupled audio RTP flow within a RTP session, for which your point would not stand. >Using an fec scheme based on the framework is not > really a requirement and does not make any sense for those who don't support > the framework anyway. So a question here is whether we can ignore the coexistence of framework and non-framework clients in practice. Our intention is to make our proposal a complementary in FECFramework to cover the client diversity. Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Saturday, September 19, 2009 4:45 PM > To: zouzixuan; gjshep@gmail.com; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > 1) Combined protection of multiple source flows > > > > > > > > For the case where one FEC repair Flow providing protection to multiple > > > > source flow, the explicit Source FEC Payload ID, according to the > > > > "draft-fecframe-framework", has to be used no matter if the protected > > > source > > > > flows is "sequenced" or not. > > > > > > Where does it say this? > > > > > > > > In section 6.3., it says: The FEC Scheme determines whether the Explicit > > Source > > > FEC Payload ID field is required. This determination is specific to each > > > transport flow. > > > > > > So, it makes a difference whether the flow is sequenced or not. > > > > The above case is not from the framework draft. I mean in this case, the > > Source FEC Payload ID specified in the fecframework draft is a must, at > > In which cases you are considering is the *explicit* source payload id a must? > > > least applies to the FEC schemes involved in the scope of IETF, such as > > LDPC, RS, Raptor and 1-D Interleaved Parity FEC. > > Source fec payload is of course required but in sequenced streams, it is already > in the source itself. What else do we need? > > > > > > > > 2) Single Sequenced Flow Case > > > > > > > > Per draft-fecframe-raptor, the FEC scheme defined for "Single Sequenced > > > > Flow" protection works well for source packet in fixed size without > > explicit > > > > source payload ID. > > > > > > > > But for the source packet of variable size, the source packets must be > > > > padded with zeros to occupy the same amount of space (equals to the > > length > > > > of Source Packet Information) in the source block for FEC > > encoding/decoding. > > > > The padded bytes are not sent, but require on the receiver side that the > > > > amount of repair data for recovering a lost source packet equals to the > > > > length of Source Packet Information. But this probably has a downside: > > the > > > > amount of repair data needed would be much more than the case where > > > padding > > > > is not used, and thus impact the FEC decoding efficiency. So an > > alternate to > > > > > > I am not sure how inefficient padding is. Is it really a better trade-off > > to use > > > source fec payload id? > > As I explained above, in principle, it is better to use source fec payload > > id. > > I am sorry, I am not following this. > > > -zou > > > > > > > handle this issue is to not use padding, and therefore the Source > > Payload ID > > > > is still needed for making FEC works with variable source packet size. > > > > > > > > > > > > > AB: Do we really need to consider non-framework capable receivers? > > > > > > > > > > ME: I don't believe this violates our charter. But why are > > > > > you doing this work? > > > > > > > > > > ZZ: For RTP receivers that my use FEC but do not support the > > > > > FECFramework. > > > > > > > > [zou] As we had answered Marshall, the FECFramework source packet > with > > > > Source Payload ID lead to incompatibility to those receivers not align > > with > > > > this Framework. The draft "draft-zixuan-fecframe-source-miu" is > proposed > > for > > > > solving this issue. > > > > > > I am still not getting this. If RTP is used, there is no need to modify > > the source > > > packets, so existing RTP receivers will have no problems. But, is it your > > goal to > > > make them (i.e., the RTP receivers that don't support the framework) still > > > benefit from the fec packets generated by an FEC scheme (which is based > on > > > framework)? > > > > That is the reason why we give the above case of multiple source flows. > > There is need to modify the source-packets in that case, as explicit source > > payload ID is needed. > > First of all, there were concerns raised in the meeting regarding the use of > multiple source RTP streams in FEC encoding. Not all RTP streams can be > simply encoded in the same FEC source block because of the clock issues. > > Assuming that you are using source RTP streams that could be combined, you > still don't need explicit source payload IDs. Finally, for RTP receivers that do not > support the FEC framework, you can write an RTP payload format draft as I did > for the 1-d interleaved fec. Using an fec scheme based on the framework is not > really a requirement and does not make any sense for those who don't support > the framework anyway. > > Cheers, > -acbegen > > > -zou > > > > > > -acbegen > > > > > > > > > > Zou ZiXuan, Senior Research Staff > > > > Media & Communication Lab > > > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > > > > > Address: Huawei Industrial Base > > > > Bantian Longgang > > > > Shenzhen 518129, P.R.China > > > > Tel: +86 0755 28789364 > > > > Fax: +86 0755 28788317 > > > > E-mail: tendyntu@huawei.com > > > > www.huawei.com > > > > > > ---------------------------------------------------------------------------- > > > > --------------------------------------------------------- > > > > This e-mail and its attachments contain confidential information from > > > > HUAWEI, which > > > > is intended only for the person or entity whose address is listed above. > > Any > > > > use of the > > > > information contained herein in any way (including, but not limited to, > > > > total or partial > > > > disclosure, reproduction, or dissemination) by persons other than the > > > > intended > > > > recipient(s) is prohibited. If you receive this e-mail in error, please > > > > notify the sender by > > > > phone or email immediately and delete it! > > > > > > > > > > > > -----Original Message----- > > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > > > Behalf > > > > Of Ali C. Begen (abegen) > > > > Sent: Thursday, September 17, 2009 9:56 PM > > > > To: gjshep@gmail.com; fecframe@ietf.org > > > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > There were several comments from myself and some others during the > > > meeting > > > > about the applicability of this draft, the validity of the problem and > > some > > > > details on the bits on the wire. > > > > > > > > Will the authors be addressing those comments with a revision before we > > > move > > > > forward? > > > > > > > > -acbegen > > > > > > > > > -----Original Message----- > > > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] > On > > > > Behalf Of Greg > > > > > Shepherd > > > > > Sent: Thursday, September 17, 2009 9:47 AM > > > > > To: fecframe@ietf.org > > > > > Subject: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > > > I'm following-up with action items from our last WG meeting in > > > > > Stockholm. We wanted to get some feedback from the list on potential > > > > > use cases for the proposal: > > > > > > > > > > http://www.ietf.org/id/draft-zixuan-fecframe-source-mi-00.txt > > > > > > > > > > ..and to ask if the WG members feels this is a draft we want to take > > > > > on as a FECFrame WG Item. > > > > > > > > > > Please respond by the end of next week - Sept 25th. > > > > > > > > > > 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 abegen@cisco.com Tue Sep 22 20:28:26 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8343A683F for ; Tue, 22 Sep 2009 20:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 sFvzrRoSZ3qv for ; Tue, 22 Sep 2009 20:28:24 -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 DBD8B3A6805 for ; Tue, 22 Sep 2009 20:28:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANsyuUqrR7PD/2dsb2JhbAC9QohPAZAnBYQb X-IronPort-AV: E=Sophos;i="4.44,435,1249257600"; d="scan'208";a="394120613" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Sep 2009 03:29:30 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n8N3TUQB025461; Tue, 22 Sep 2009 20:29:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8N3TUMS018517; Wed, 23 Sep 2009 03:29:30 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.3959); Tue, 22 Sep 2009 20:29:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 20:29:26 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <000601ca3bfc$1289f970$379dec50$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] draft-zixuan-fecframe-source-mi ?? Thread-Index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLw References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> <000601ca3bfc$1289f970$379dec50$@com> From: "Ali C. Begen (abegen)" To: "zouzixuan" , X-OriginalArrivalTime: 23 Sep 2009 03:29:29.0951 (UTC) FILETIME=[0F654EF0:01CA3BFE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=324; t=1253676570; x=1254540570; 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]=20draft-zixuan-fecframe-sour ce-mi=20?? |Sender:=20; bh=qx70Xu0lPSoeE/517OMoeB7YrxVR2wyM6fxRhVYnIsY=; b=i1uXzHV2+3aWqv1jVoxoqvFtC1y10jZ8GLT8PSKblycaR4C58FHOs0dc2F DlLobzSfSchlbTE7YdVSo6vuGNkspBxfe0+rGppNaeDCC90mGt7p7TAfDFHW KmC1QSRkxK; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 03:28:26 -0000 First question, are you suggesting to apply FEC to the combination of a = video and audio RTP stream? Second question, assuming the above case is true, I am still not sure = why you need an additional flow carrying the source payload ids. Is it = because there are two streams? Could you explain? Cheers, acbegen. From tendyntu@huawei.com Wed Sep 23 01:29:04 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B57D3A69B1 for ; Wed, 23 Sep 2009 01:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=0.841, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha-X+h1Pj0Nx for ; Wed, 23 Sep 2009 01:29:02 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A9A093A6783 for ; Wed, 23 Sep 2009 01:29:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQF00D2S0U5HY@szxga03-in.huawei.com> for fecframe@ietf.org; Wed, 23 Sep 2009 16:27:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQF00MJ10U5PM@szxga03-in.huawei.com> for fecframe@ietf.org; Wed, 23 Sep 2009 16:27:41 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQF00BCU0U4YA@szxml04-in.huawei.com> for fecframe@ietf.org; Wed, 23 Sep 2009 16:27:41 +0800 (CST) Date: Wed, 23 Sep 2009 16:27:40 +0800 From: zouzixuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , fecframe@ietf.org Message-id: <002301ca3c27$b73056b0$25910410$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UjP0eqvG/bnJVklfPJ2D4g)" Content-language: zh-cn Thread-index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLwAABgvlA= References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> <000601ca3bfc$1289f970$379dec50$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com> X-Mailman-Approved-At: Wed, 23 Sep 2009 05:15:23 -0700 Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 08:29:04 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_UjP0eqvG/bnJVklfPJ2D4g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT > > First question, are you suggesting to apply FEC to the combination of a video > and audio RTP stream? > Second question, assuming the above case is true, I am still not sure why you > need an additional flow carrying the source payload ids. Is it because there are > two streams? Could you explain? It's not this case that just result in the need of carrying source play id in additional flow. It is this case to prove the need of source payload id for RTP flow. Because you need a source payload id, you gotta transfer it to the client, either in source packet as current FEC framework specified, or in an additional flow described in our draft. The latter choice for transferring the source payload is for making source packet accessible to non-fecframework clients. This table shows an example of multiple flows. The table depicts the structure of a source block, which is filled up with the packets (of length 16, 17 19 15 and 8 bytes) from two sequenced flows. The packets from two flows are identified by flow id 0 and 1, respectively. For FEC decoding, the receiver needs to know the position of each packet in the source block. The sequence number can only tell the order of a packet in the flow it belongs to in the source block. There is no way to tell where a packet exactly is in the source block. Source Payload ID is thus in this case needed. Would you please give a solution which is free of source payload id? 0 16 B0,0 B0,1 B0,2 B0,3 B0,4 B0,5 B0,6 B0,7 B0,8 B0,9 B0,10 B0,11 B0,12 B0,13 B0,14 B0,15 0 0 0 0 17 B1,0 B1,1 B1,2 B1,3 B1,4 B1,5 B1,6 B1,7 B1,8 B1,9 B1,10 B1,11 B1,12 B1,13 B1,14 B1,15 B1,16 0 0 1 19 B2,0 B2,1 B2,2 B2,3 B2,4 B2,5 B2,6 B2,7 B2,8 B2,9 B2,10 B2,11 B2,12 B2,13 B2,14 B2,15 B2,16 B2,17 B2,18 0 15 B3,0 B3,1 B3,2 B3,3 B3,4 B3,5 B3,6 B3,7 B3,8 B3,9 B3,10 B3,11 B3,12 B3,13 B3,14 0 0 0 0 1 8 B4,0 B4,1 B4,2 B4,3 B4,4 B4,5 B4,6 B4,7 Hope this is clear. Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Wednesday, September 23, 2009 11:29 AM > To: zouzixuan; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > First question, are you suggesting to apply FEC to the combination of a video > and audio RTP stream? > > Second question, assuming the above case is true, I am still not sure why you > need an additional flow carrying the source payload ids. Is it because there are > two streams? Could you explain? > > Cheers, acbegen. --Boundary_(ID_UjP0eqvG/bnJVklfPJ2D4g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

>

> First question, are you suggesting to apply FEC to the combination of a video

> and audio RTP stream?

 

> Second question, assuming the above case is true, I am still not sure why you

> need an additional flow carrying the source payload ids. Is it because there are

> two streams? Could you explain?

 

It's not this case that just result in the need of carrying source play id in additional flow. It is this case to prove the need of source payload id for RTP flow. Because you need a source payload id, you gotta transfer it to the client, either in source packet as current FEC framework specified, or in an additional flow described in our draft. The latter choice for transferring the source payload is for making source packet accessible to non-fecframework clients.

 

This table shows an example of multiple flows. The table depicts the structure of a source block, which is filled up with the packets (of length 16, 17 19 15 and 8 bytes) from two sequenced flows. The packets from two flows are identified by flow id 0 and 1, respectively. For FEC decoding, the receiver needs to know the position of each packet in the source block. The sequence number can only tell the order of a packet in the flow it belongs to in the source block. There is no way to tell where a packet exactly is in the source block. Source Payload ID is thus in this case needed. Would you please give a solution which is free of source payload id?

 

0

16

B0,0

B0,1

B0,2

B0,3

B0,4

B0,5

B0,6

B0,7

B0,8

B0,9

B0,10

B0,11

B0,12

B0,13

B0,14

B0,15

0

0

0

0

17

B1,0

B1,1

B1,2

B1,3

B1,4

B1,5

B1,6

B1,7

B1,8

B1,9

B1,10

B1,11

B1,12

B1,13

B1,14

B1,15

B1,16

0

0

1

19

B2,0

B2,1

B2,2

B2,3

B2,4

B2,5

B2,6

B2,7

B2,8

B2,9

B2,10

B2,11

B2,12

B2,13

B2,14

B2,15

B2,16

B2,17

B2,18

0

15

B3,0

B3,1

B3,2

B3,3

B3,4

B3,5

B3,6

B3,7

B3,8

B3,9

B3,10

B3,11

B3,12

B3,13

B3,14

0

0

0

0

1

8

B4,0

B4,1

B4,2

B4,3

B4,4

B4,5

B4,6

B4,7

 

 

Hope this is clear.

 

Zou ZiXuan, Senior Research Staff

Media & Communication Lab

HUAWEI TECHNOLOGIES CO.,LTD.

 

Address: Huawei Industrial Base

Bantian Longgang

Shenzhen 518129, P.R.China

Tel: +86 0755 28789364

Fax: +86 0755 28788317

E-mail: tendyntu@huawei.com

www.huawei.com

-------------------------------------------------------------------------------------------------------------------------------------

This e-mail and its attachments contain confidential information from HUAWEI, which

is intended only for the person or entity whose address is listed above. Any use of the

information contained herein in any way (including, but not limited to, total or partial

disclosure, reproduction, or dissemination) by persons other than the intended

recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by

phone or email immediately and delete it!

 

 

> -----Original Message-----

> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]

> Sent: Wednesday, September 23, 2009 11:29 AM

> To: zouzixuan; fecframe@ietf.org

> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??

>

> First question, are you suggesting to apply FEC to the combination of a video

> and audio RTP stream?

>

> Second question, assuming the above case is true, I am still not sure why you

> need an additional flow carrying the source payload ids. Is it because there are

> two streams? Could you explain?

>

> Cheers, acbegen.

--Boundary_(ID_UjP0eqvG/bnJVklfPJ2D4g)-- From abegen@cisco.com Wed Sep 23 09:07:52 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78C13A6A98 for ; Wed, 23 Sep 2009 09:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 dVpFlqFjE5XF for ; Wed, 23 Sep 2009 09:07:51 -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 88E5A3A69BA for ; Wed, 23 Sep 2009 09:07:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABDluUqrR7MV/2dsb2JhbAC+d4EYCAGHLgGQFwWCLYFu X-IronPort-AV: E=Sophos;i="4.44,439,1249257600"; d="scan'208";a="394513561" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 23 Sep 2009 16:08:58 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8NG8v0d018010; Wed, 23 Sep 2009 09:08:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8NG8vmu028718; Wed, 23 Sep 2009 16:08:57 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.3959); Wed, 23 Sep 2009 09:08:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Sep 2009 09:08:45 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A3935A8@xmb-sjc-215.amer.cisco.com> In-Reply-To: <002301ca3c27$b73056b0$25910410$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] draft-zixuan-fecframe-source-mi ?? Thread-Index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLwAABgvlAAGNW3EA== References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> <000601ca3bfc$1289f970$379dec50$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com> <002301ca3c27$b73056b0$25910410$@com> From: "Ali C. Begen (abegen)" To: "zouzixuan" , X-OriginalArrivalTime: 23 Sep 2009 16:08:56.0803 (UTC) FILETIME=[275B2330:01CA3C68] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6050; t=1253722137; x=1254586137; 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]=20draft-zixuan-fecframe-sour ce-mi=20?? |Sender:=20; bh=tAkRaVHtMJh5fKEM7bUdvxDWEakpIvtZ/GwObaldG1I=; b=lY6x9GW8HLsjus+WTpWME4muk4uEcXf5FfrB0MxQHVw3mjhgtio124IcQA zUcbmp2JAg1Tx5BG2HpgwCpfcomg7xAn7+r1ivtz1wAF/gqsir/LlpHJSiQF MEmVEl/qeXrO2ffIVbey4lKgDuXoG6BAlVPZ1cp+qOAiECndeGqLc=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Ali C. Begen \(abegen\)" List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 16:07:52 -0000 There are multiple things here used as an excuse to depart from the = convention used in the framework. The main goal here seems to provide the non-framework capable RTP = applications a way of using the nice features of the framework. In this = example, "a nice feature" stands for the protection of multiple RTP = streams together. I will let others comment on this, too, but = personally, I am not sure whether we should be doing this. On one hand, = we want the nice features, but at the same time we don=92t wanna support = the framework, and the excuse is the backward compatibility in = environments with both framework-capable and incapable RTP receivers. In = addition, using an additional flow may increase the chances of failure = since if source fec payload id=92s are lost, receiver will be clueless. = This deserves a consensus from the WG, probably from AVT, too. Furthermore, I believe two RTP streams can be still protected together = w/o any additional source fec payload id=92s (You asked for an example, = and I will try to explain in simple words). If certain features of the = RTP streams are known (which is usually the case), by using a systematic = approach (not in the sense of systematic FEC), things can probably be = worked out. In your example, I believe in each source block you wanna do = a different order of the source packets and flows, so things are quite = unpredictable. E.g., packet 16 and 17 are before packet 15 of the same = flow, packet 19 is before packet 8 of the other flow, and packets = belonging to flows 0 and 1 are dispersed, any particular reason? But, if you follow a systematic approach, your CDP can convey the = mapping out of band, and decoding will know what to expect and how to = decode. Remember that there will be constraints on which RTP streams you = can combine prior to FEC encoding (this was brought up in the last = meeting). If all the RTP streams belong to the same RTP session, their SSRC's will = be different, so SSRC+seqnum should uniquely identify each source = packet. But, this would not work if the RTP streams would be from = different sessions. In that case, they could share same SSRC's, and I = can see the complications. Cheers, acbegen. From: zouzixuan [mailto:tendyntu@huawei.com]=20 Sent: Wednesday, September 23, 2009 4:28 AM To: Ali C. Begen (abegen); fecframe@ietf.org Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >=20 > First question, are you suggesting to apply FEC to the combination of = a video > and audio RTP stream? > Second question, assuming the above case is true, I am still not sure = why you > need an additional flow carrying the source payload ids. Is it because = there are > two streams? Could you explain? It's not this case that just result in the need of carrying source play = id in additional flow. It is this case to prove the need of source = payload id for RTP flow. Because you need a source payload id, you gotta = transfer it to the client, either in source packet as current FEC = framework specified, or in an additional flow described in our draft. = The latter choice for transferring the source payload is for making = source packet accessible to non-fecframework clients.=20 This table shows an example of multiple flows. The table depicts the = structure of a source block, which is filled up with the packets (of = length 16, 17 19 15 and 8 bytes) from two sequenced flows. The packets = from two flows are identified by flow id 0 and 1, respectively. For FEC = decoding, the receiver needs to know the position of each packet in the = source block. The sequence number can only tell the order of a packet in = the flow it belongs to in the source block. There is no way to tell = where a packet exactly is in the source block. Source Payload ID is thus = in this case needed. Would you please give a solution which is free of = source payload id? 0 16 B0,0 B0,1 B0,2 B0,3 B0,4 B0,5 B0,6 B0,7 B0,8 B0,9 B0,10 B0,11 B0,12 B0,13 B0,14 B0,15 0 0 0 0 17 B1,0 B1,1 B1,2 B1,3 B1,4 B1,5 B1,6 B1,7 B1,8 B1,9 B1,10 B1,11 B1,12 B1,13 B1,14 B1,15 B1,16 0 0 1 19 B2,0 B2,1 B2,2 B2,3 B2,4 B2,5 B2,6 B2,7 B2,8 B2,9 B2,10 B2,11 B2,12 B2,13 B2,14 B2,15 B2,16 B2,17 B2,18 0 15 B3,0 B3,1 B3,2 B3,3 B3,4 B3,5 B3,6 B3,7 B3,8 B3,9 B3,10 B3,11 B3,12 B3,13 B3,14 0 0 0 0 1 8 B4,0 B4,1 B4,2 B4,3 B4,4 B4,5 B4,6 B4,7 Hope this is clear. Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD.=20 Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Wednesday, September 23, 2009 11:29 AM > To: zouzixuan; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >=20 > First question, are you suggesting to apply FEC to the combination of = a video > and audio RTP stream? >=20 > Second question, assuming the above case is true, I am still not sure = why you > need an additional flow carrying the source payload ids. Is it because = there are > two streams? Could you explain? >=20 > Cheers, acbegen. From abegen@cisco.com Wed Sep 23 09:51:38 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3153A6911; Wed, 23 Sep 2009 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 CdAhvtof-m9J; Wed, 23 Sep 2009 09:51:37 -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 7A2833A6906; Wed, 23 Sep 2009 09:51:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABDvuUqrR7PE/2dsb2JhbACZS6VbiE8BkBUFhBs X-IronPort-AV: E=Sophos;i="4.44,439,1249257600"; d="scan'208";a="245851348" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Sep 2009 16:52:44 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8NGqiNo006377; Wed, 23 Sep 2009 09:52:44 -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.14.3) with ESMTP id n8NGqh8Q001008; Wed, 23 Sep 2009 16:52:44 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.3959); Wed, 23 Sep 2009 09:52:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 23 Sep 2009 09:52:36 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A3935F9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-mmusic-rfc4756bis-03 Thread-Index: Aco8bf7PWFOmmuErRbuKRfBYZMZt4AAAAoJg From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 23 Sep 2009 16:52:41.0260 (UTC) FILETIME=[43A77EC0:01CA3C6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2304; t=1253724764; x=1254588764; 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:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-ietf-mmusic-rfc4756bis-03=20 |Sender:=20; bh=8rF2s4ZwKF/eTwchH/wFh9/hR1i+54qoextX9gKbrvo=; b=WAkAavzqCOugshG+E+7XkXsaLeBZcFsUtuGqeSMh64eCanzJDQd9vLGFI1 E88gdPhZsskGmIWwsPgInWZr21IQbZXabzYcwxKweZvmPJuCOdjDH4n/hKRi vdilTrkryL; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Fecframe] FW: New Version Notification for draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 16:51:38 -0000 QSByZXZpc2lvbiBoYXMgYmVlbiBqdXN0IHBvc3RlZCB0byBhZGRyZXNzIHRoZSBjb21tZW50IGZy b20gQ29saW4uIEkgYWxzbyBmaXhlZCBhIGZldyBvbGRlciByZWZlcmVuY2VzLiBJIGJlbGlldmUg d2UgYXJlIHJlYWR5IGZvciBsYXN0IGNhbGwuDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtaWV0Zi1tbXVzaWMtcmZjNDc1NmJpcy0wMy50eHQNCg0KDQpDaGVlcnMsIGFjYmVnZW4uDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRv b2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBTZXB0 ZW1iZXIgMjMsIDIwMDkgMTI6NTAgUE0NClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1tbXVzaWMtcmZjNDc1 NmJpcy0wMyANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1tbXVzaWMtcmZj NDc1NmJpcy0wMy50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdl biBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt aWV0Zi1tbXVzaWMtcmZjNDc1NmJpcw0KUmV2aXNpb246CSAwMw0KVGl0bGU6CQkgRm9yd2FyZCBF cnJvciBDb3JyZWN0aW9uIEdyb3VwaW5nIFNlbWFudGljcyBpbiBTZXNzaW9uIERlc2NyaXB0aW9u IFByb3RvY29sDQpDcmVhdGlvbl9kYXRlOgkgMjAwOS0wOS0yMw0KV0cgSUQ6CQkgbW11c2ljDQpO dW1iZXJfb2ZfcGFnZXM6IDEyDQoNCkFic3RyYWN0Og0KVGhlIFNlc3Npb24gRGVzY3JpcHRpb24g UHJvdG9jb2wgKFNEUCkgc3VwcG9ydHMgZ3JvdXBpbmcgbWVkaWEgbGluZXMuDQpTRFAgYWxzbyBo YXMgc2VtYW50aWNzIGRlZmluZWQgZm9yIGdyb3VwaW5nIHRoZSBhc3NvY2lhdGVkIHNvdXJjZSBh bmQNCkZvcndhcmQgRXJyb3IgQ29ycmVjdGlvbiAoRkVDKS1iYXNlZCByZXBhaXIgZmxvd3MuICBI b3dldmVyLCB0aGUNCnNlbWFudGljcyB0aGF0IHdhcyBkZWZpbmVkIGluIFJGQyA0NzU2IGdlbmVy YWxseSBmYWlsIHRvIHByb3ZpZGUgdGhlDQpzcGVjaWZpYyBncm91cGluZyByZWxhdGlvbnNoaXBz IGJldHdlZW4gdGhlIHNvdXJjZSBhbmQgcmVwYWlyIGZsb3dzDQp3aGVuIHRoZXJlIGFyZSBtb3Jl IHRoYW4gb25lIHNvdXJjZSBhbmQvb3IgcmVwYWlyIGZsb3dzIGluIHRoZSBzYW1lDQpncm91cC4g IEZ1cnRoZXJtb3JlLCB0aGUgZXhpc3Rpbmcgc2VtYW50aWNzIGRvZXMgbm90IHN1cHBvcnQNCmRl c2NyaWJpbmcgYWRkaXRpdmUgcmVwYWlyIGZsb3dzLiAgVGhpcyBkb2N1bWVudCBhZGRyZXNzZXMg dGhlc2UNCmlzc3VlcyBieSBpbnRyb2R1Y2luZyBuZXcgRkVDIGdyb3VwaW5nIHNlbWFudGljcy4g IFNTUkMtbGV2ZWwNCmdyb3VwaW5nIHNlbWFudGljcyBpcyBhbHNvIGludHJvZHVjZWQgaW4gdGhp cyBkb2N1bWVudCBmb3IgUmVhbC10aW1lDQpUcmFuc3BvcnQgUHJvdG9jb2wgKFJUUCkgc3RyZWFt cyB1c2luZyBTU1JDIG11bHRpcGxleGluZy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From tendyntu@huawei.com Wed Sep 23 20:23:22 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421B93A67AE for ; Wed, 23 Sep 2009 20:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0m82ZL4IagO for ; Wed, 23 Sep 2009 20:23:20 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BF76E3A68B2 for ; Wed, 23 Sep 2009 20:23:14 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQG008O2HGB3T@szxga02-in.huawei.com> for fecframe@ietf.org; Thu, 24 Sep 2009 11:24:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQG00I88HGBZW@szxga02-in.huawei.com> for fecframe@ietf.org; Thu, 24 Sep 2009 11:24:11 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQG00G1EHGA1K@szxml04-in.huawei.com> for fecframe@ietf.org; Thu, 24 Sep 2009 11:24:11 +0800 (CST) Date: Thu, 24 Sep 2009 11:24:10 +0800 From: zouzixuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540A3935A8@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , fecframe@ietf.org Message-id: <007401ca3cc6$7b947b00$72bd7100$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLwAABgvlAAGNW3EAAX8BAA References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> <000601ca3bfc$1289f970$379dec50$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com> <002301ca3c27$b73056b0$25910410$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3935A8@xmb-sjc-215.amer.cisco.com> Cc: tme@multicasttech.com Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 03:23:22 -0000 Hi, Ali It's a good suggestion that others join the discussion on this. The point here is that whether we need to take the backward compatibility into account in FEC Framework or not. We may not ignore a fact that the diversity of clients exists in practice. We didn't mean to make the idea we proposed to be something depart from the framework. We just hope to complement the framework so that it can be practically more adaptable. Best regards, Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Thursday, September 24, 2009 12:09 AM > To: zouzixuan; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > There are multiple things here used as an excuse to depart from the convention > used in the framework. > > The main goal here seems to provide the non-framework capable RTP > applications a way of using the nice features of the framework. In this example, > "a nice feature" stands for the protection of multiple RTP streams together. I > will let others comment on this, too, but personally, I am not sure whether we > should be doing this. On one hand, we want the nice features, but at the same > time we don't wanna support the framework, and the excuse is the backward > compatibility in environments with both framework-capable and incapable RTP > receivers. In addition, using an additional flow may increase the chances of > failure since if source fec payload id's are lost, receiver will be clueless. This > deserves a consensus from the WG, probably from AVT, too. > > Furthermore, I believe two RTP streams can be still protected together w/o any > additional source fec payload id's (You asked for an example, and I will try to > explain in simple words). If certain features of the RTP streams are known > (which is usually the case), by using a systematic approach (not in the sense of > systematic FEC), things can probably be worked out. In your example, I believe > in each source block you wanna do a different order of the source packets and > flows, so things are quite unpredictable. E.g., packet 16 and 17 are before > packet 15 of the same flow, packet 19 is before packet 8 of the other flow, and > packets belonging to flows 0 and 1 are dispersed, any particular reason? > > But, if you follow a systematic approach, your CDP can convey the mapping out > of band, and decoding will know what to expect and how to decode. Remember > that there will be constraints on which RTP streams you can combine prior to > FEC encoding (this was brought up in the last meeting). > > If all the RTP streams belong to the same RTP session, their SSRC's will be > different, so SSRC+seqnum should uniquely identify each source packet. But, > this would not work if the RTP streams would be from different sessions. In > that case, they could share same SSRC's, and I can see the complications. > > Cheers, acbegen. > > > From: zouzixuan [mailto:tendyntu@huawei.com] > Sent: Wednesday, September 23, 2009 4:28 AM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > First question, are you suggesting to apply FEC to the combination of a video > > and audio RTP stream? > > > Second question, assuming the above case is true, I am still not sure why you > > need an additional flow carrying the source payload ids. Is it because there > are > > two streams? Could you explain? > > It's not this case that just result in the need of carrying source play id in > additional flow. It is this case to prove the need of source payload id for RTP > flow. Because you need a source payload id, you gotta transfer it to the client, > either in source packet as current FEC framework specified, or in an additional > flow described in our draft. The latter choice for transferring the source > payload is for making source packet accessible to non-fecframework clients. > > This table shows an example of multiple flows. The table depicts the structure > of a source block, which is filled up with the packets (of length 16, 17 19 15 and > 8 bytes) from two sequenced flows. The packets from two flows are identified > by flow id 0 and 1, respectively. For FEC decoding, the receiver needs to know > the position of each packet in the source block. The sequence number can only > tell the order of a packet in the flow it belongs to in the source block. There is > no way to tell where a packet exactly is in the source block. Source Payload ID is > thus in this case needed. Would you please give a solution which is free of > source payload id? > > 0 > 16 > B0,0 > B0,1 > B0,2 > B0,3 > B0,4 > B0,5 > B0,6 > B0,7 > B0,8 > B0,9 > B0,10 > B0,11 > B0,12 > B0,13 > B0,14 > B0,15 > 0 > 0 > 0 > 0 > 17 > B1,0 > B1,1 > B1,2 > B1,3 > B1,4 > B1,5 > B1,6 > B1,7 > B1,8 > B1,9 > B1,10 > B1,11 > B1,12 > B1,13 > B1,14 > B1,15 > B1,16 > 0 > 0 > 1 > 19 > B2,0 > B2,1 > B2,2 > B2,3 > B2,4 > B2,5 > B2,6 > B2,7 > B2,8 > B2,9 > B2,10 > B2,11 > B2,12 > B2,13 > B2,14 > B2,15 > B2,16 > B2,17 > B2,18 > 0 > 15 > B3,0 > B3,1 > B3,2 > B3,3 > B3,4 > B3,5 > B3,6 > B3,7 > B3,8 > B3,9 > B3,10 > B3,11 > B3,12 > B3,13 > B3,14 > 0 > 0 > 0 > 0 > 1 > 8 > B4,0 > B4,1 > B4,2 > B4,3 > B4,4 > B4,5 > B4,6 > B4,7 > > > Hope this is clear. > > Zou ZiXuan, Senior Research Staff > Media & Communication Lab > HUAWEI TECHNOLOGIES CO.,LTD. > > Address: Huawei Industrial Base > Bantian Longgang > Shenzhen 518129, P.R.China > Tel: +86 0755 28789364 > Fax: +86 0755 28788317 > E-mail: tendyntu@huawei.com > www.huawei.com > ---------------------------------------------------------------------------- ------------------------------------ > --------------------- > This e-mail and its attachments contain confidential information from HUAWEI, > which > is intended only for the person or entity whose address is listed above. Any use > of the > information contained herein in any way (including, but not limited to, total or > partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please notify the > sender by > phone or email immediately and delete it! > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Wednesday, September 23, 2009 11:29 AM > > To: zouzixuan; fecframe@ietf.org > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > First question, are you suggesting to apply FEC to the combination of a video > > and audio RTP stream? > > > > Second question, assuming the above case is true, I am still not sure why you > > need an additional flow carrying the source payload ids. Is it because there > are > > two streams? Could you explain? > > > > Cheers, acbegen. From Einat@radvision.com Wed Sep 23 22:23:24 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3FE93A6892 for ; Wed, 23 Sep 2009 22:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxBdkyXkrQij for ; Wed, 23 Sep 2009 22:23:23 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 934473A6822 for ; Wed, 23 Sep 2009 22:23:22 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n8O5baJs022610 for fecframe@ietf.org; Thu, 24 Sep 2009 08:37:36 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n8O5bTTY022600; Thu, 24 Sep 2009 08:37:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Sep 2009 08:24:23 +0300 Message-ID: In-Reply-To: <007401ca3cc6$7b947b00$72bd7100$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] draft-zixuan-fecframe-source-mi ?? Thread-Index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLwAABgvlAAGNW3EAAX8BAAAAOpM1A= References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com><00ad01ca384e$10f8b620$32ea2260$@com><04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com><00ce01ca38fe$1364eb30$3a2ec190$@com><04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com><000601ca3bfc$1289f970$379dec50$@com><04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com><002301ca3c27$b73056b0$25910410$@com><04CAD96D4C5A3D48B1919248A8FE0D540A3935A8@xmb-sjc-215.amer.cisco.com> <007401ca3cc6$7b947b00$72bd7100$@com> From: "Einat Yellin (Lachover)" To: "zouzixuan" , "Ali C. Begen (abegen)" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id n8O5bTTY022600 Cc: tme@multicasttech.com Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 05:23:24 -0000 Hi, Backward compatibility is a major requirement for FEC framework, no doubt. I believe that the discussion here is around whether a separate flow for FEC mapping information is required. While following the discussion, I can relate to the reasons why not having a separate flow as claimed by Ali: a. This is a redundant flow since this information can be conveyed in the FEC repair flow and in SDP even when protecting multiple RTP flows (specifically you can see an example in draft-galanos-fecframe-rtp-reedsolomon-mf-00). b. This separate flow for mapping is also useful only for receivers that support this draft, so the backward compatibility issue remains the same as for the case where mapping is specified in the repair flow. c. A separate flow increases the chance of losing packets. I must say that I don't understand the reasons for using a separate flow. Mr. Zou ZiXuan, is this meant for systems that do not use SDP? Best, Einat -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of zouzixuan Sent: Thursday, September 24, 2009 6:24 AM To: 'Ali C. Begen (abegen)'; fecframe@ietf.org Cc: tme@multicasttech.com Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? Hi, Ali It's a good suggestion that others join the discussion on this. The point here is that whether we need to take the backward compatibility into account in FEC Framework or not. We may not ignore a fact that the diversity of clients exists in practice. We didn't mean to make the idea we proposed to be something depart from the framework. We just hope to complement the framework so that it can be practically more adaptable. Best regards, Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ------------------------------------------------------------------------ ---- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Thursday, September 24, 2009 12:09 AM > To: zouzixuan; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > There are multiple things here used as an excuse to depart from the convention > used in the framework. > > The main goal here seems to provide the non-framework capable RTP > applications a way of using the nice features of the framework. In this example, > "a nice feature" stands for the protection of multiple RTP streams together. I > will let others comment on this, too, but personally, I am not sure whether we > should be doing this. On one hand, we want the nice features, but at the same > time we don't wanna support the framework, and the excuse is the backward > compatibility in environments with both framework-capable and incapable RTP > receivers. In addition, using an additional flow may increase the chances of > failure since if source fec payload id's are lost, receiver will be clueless. This > deserves a consensus from the WG, probably from AVT, too. > > Furthermore, I believe two RTP streams can be still protected together w/o any > additional source fec payload id's (You asked for an example, and I will try to > explain in simple words). If certain features of the RTP streams are known > (which is usually the case), by using a systematic approach (not in the sense of > systematic FEC), things can probably be worked out. In your example, I believe > in each source block you wanna do a different order of the source packets and > flows, so things are quite unpredictable. E.g., packet 16 and 17 are before > packet 15 of the same flow, packet 19 is before packet 8 of the other flow, and > packets belonging to flows 0 and 1 are dispersed, any particular reason? > > But, if you follow a systematic approach, your CDP can convey the mapping out > of band, and decoding will know what to expect and how to decode. Remember > that there will be constraints on which RTP streams you can combine prior to > FEC encoding (this was brought up in the last meeting). > > If all the RTP streams belong to the same RTP session, their SSRC's will be > different, so SSRC+seqnum should uniquely identify each source packet. But, > this would not work if the RTP streams would be from different sessions. In > that case, they could share same SSRC's, and I can see the complications. > > Cheers, acbegen. > > > From: zouzixuan [mailto:tendyntu@huawei.com] > Sent: Wednesday, September 23, 2009 4:28 AM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > First question, are you suggesting to apply FEC to the combination of a video > > and audio RTP stream? > > > Second question, assuming the above case is true, I am still not sure why you > > need an additional flow carrying the source payload ids. Is it because there > are > > two streams? Could you explain? > > It's not this case that just result in the need of carrying source play id in > additional flow. It is this case to prove the need of source payload id for RTP > flow. Because you need a source payload id, you gotta transfer it to the client, > either in source packet as current FEC framework specified, or in an additional > flow described in our draft. The latter choice for transferring the source > payload is for making source packet accessible to non-fecframework clients. > > This table shows an example of multiple flows. The table depicts the structure > of a source block, which is filled up with the packets (of length 16, 17 19 15 and > 8 bytes) from two sequenced flows. The packets from two flows are identified > by flow id 0 and 1, respectively. For FEC decoding, the receiver needs to know > the position of each packet in the source block. The sequence number can only > tell the order of a packet in the flow it belongs to in the source block. There is > no way to tell where a packet exactly is in the source block. Source Payload ID is > thus in this case needed. Would you please give a solution which is free of > source payload id? > > 0 > 16 > B0,0 > B0,1 > B0,2 > B0,3 > B0,4 > B0,5 > B0,6 > B0,7 > B0,8 > B0,9 > B0,10 > B0,11 > B0,12 > B0,13 > B0,14 > B0,15 > 0 > 0 > 0 > 0 > 17 > B1,0 > B1,1 > B1,2 > B1,3 > B1,4 > B1,5 > B1,6 > B1,7 > B1,8 > B1,9 > B1,10 > B1,11 > B1,12 > B1,13 > B1,14 > B1,15 > B1,16 > 0 > 0 > 1 > 19 > B2,0 > B2,1 > B2,2 > B2,3 > B2,4 > B2,5 > B2,6 > B2,7 > B2,8 > B2,9 > B2,10 > B2,11 > B2,12 > B2,13 > B2,14 > B2,15 > B2,16 > B2,17 > B2,18 > 0 > 15 > B3,0 > B3,1 > B3,2 > B3,3 > B3,4 > B3,5 > B3,6 > B3,7 > B3,8 > B3,9 > B3,10 > B3,11 > B3,12 > B3,13 > B3,14 > 0 > 0 > 0 > 0 > 1 > 8 > B4,0 > B4,1 > B4,2 > B4,3 > B4,4 > B4,5 > B4,6 > B4,7 > > > Hope this is clear. > > Zou ZiXuan, Senior Research Staff > Media & Communication Lab > HUAWEI TECHNOLOGIES CO.,LTD. > > Address: Huawei Industrial Base > Bantian Longgang > Shenzhen 518129, P.R.China > Tel: +86 0755 28789364 > Fax: +86 0755 28788317 > E-mail: tendyntu@huawei.com > www.huawei.com > ------------------------------------------------------------------------ ---- ------------------------------------ > --------------------- > This e-mail and its attachments contain confidential information from HUAWEI, > which > is intended only for the person or entity whose address is listed above. Any use > of the > information contained herein in any way (including, but not limited to, total or > partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please notify the > sender by > phone or email immediately and delete it! > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Wednesday, September 23, 2009 11:29 AM > > To: zouzixuan; fecframe@ietf.org > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > First question, are you suggesting to apply FEC to the combination of a video > > and audio RTP stream? > > > > Second question, assuming the above case is true, I am still not sure why you > > need an additional flow carrying the source payload ids. Is it because there > are > > two streams? Could you explain? > > > > Cheers, acbegen. _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From csp@csperkins.org Thu Sep 24 15:32:27 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F300C3A68AD; Thu, 24 Sep 2009 15:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJv68T+67nqU; Thu, 24 Sep 2009 15:32:25 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id C19873A683A; Thu, 24 Sep 2009 15:32:25 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.12]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1MqwsY-0006Fu-Yt; Thu, 24 Sep 2009 22:33:34 +0000 Message-Id: <5226612F-7151-45EE-8438-830E4F16BC4A@csperkins.org> From: Colin Perkins To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A3935F9@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Sep 2009 23:33:33 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D540A3935F9@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [MMUSIC] FW: New Version Notification for draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 22:32:27 -0000 The changes look good to me. Thanks, Colin On 23 Sep 2009, at 17:52, Ali C. Begen (abegen) wrote: > A revision has been just posted to address the comment from Colin. I > also fixed a few older references. I believe we are ready for last > call. > > http://www.ietf.org/id/draft-ietf-mmusic-rfc4756bis-03.txt > > > Cheers, acbegen. > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, September 23, 2009 12:50 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for draft-ietf-mmusic-rfc4756bis-03 > > > A new version of I-D, draft-ietf-mmusic-rfc4756bis-03.txt has been > successfuly submitted by Ali Begen and posted to the IETF repository. > > Filename: draft-ietf-mmusic-rfc4756bis > Revision: 03 > Title: Forward Error Correction Grouping Semantics in Session > Description Protocol > Creation_date: 2009-09-23 > WG ID: mmusic > Number_of_pages: 12 > > Abstract: > The Session Description Protocol (SDP) supports grouping media lines. > SDP also has semantics defined for grouping the associated source and > Forward Error Correction (FEC)-based repair flows. However, the > semantics that was defined in RFC 4756 generally fail to provide the > specific grouping relationships between the source and repair flows > when there are more than one source and/or repair flows in the same > group. Furthermore, the existing semantics does not support > describing additive repair flows. This document addresses these > issues by introducing new FEC grouping semantics. SSRC-level > grouping semantics is also introduced in this document for Real-time > Transport Protocol (RTP) streams using SSRC multiplexing. > > > > The IETF Secretariat. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ From tendyntu@huawei.com Sun Sep 27 02:57:36 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CF63A6805 for ; Sun, 27 Sep 2009 02:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.576 X-Spam-Level: * X-Spam-Status: No, score=1.576 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bayr8ttplEiL for ; Sun, 27 Sep 2009 02:57:34 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 61F493A67A5 for ; Sun, 27 Sep 2009 02:57:34 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQM0072OJPRD3@szxga01-in.huawei.com> for fecframe@ietf.org; Sun, 27 Sep 2009 17:58:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQM00DQ8JPRYG@szxga01-in.huawei.com> for fecframe@ietf.org; Sun, 27 Sep 2009 17:58:39 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQM008GSJPQIZ@szxml04-in.huawei.com> for fecframe@ietf.org; Sun, 27 Sep 2009 17:58:38 +0800 (CST) Date: Sun, 27 Sep 2009 17:58:38 +0800 From: zouzixuan In-reply-to: To: "'Einat Yellin (Lachover)'" , "'Ali C. Begen (abegen)'" , tme@multicasttech.com, gjshep@gmail.com, fecframe@ietf.org Message-id: <006c01ca3f59$16011790$420346b0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLwAABgvlAAGNW3EAAX8BAAAAOpM1AAL0thwA== References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> <000601ca3bfc$1289f970$379dec50$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com> <002301ca3c27$b73056b0$25910410$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3935A8@xmb-sjc-215.amer.cisco.com> <007401ca3cc6$7b947b00$72bd7100$@com> Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 09:57:36 -0000 Hi, Einat, Ali Similar to Einat's explanation on "backward compatible" as stated your draft , our intention is to keep source packet unmodified without adding source payload id to it. And therefore the non-framework client can interpret the source packet. But I'm still not sure if the "backward compatibility" we are referring to here is considered a valuable requirement in FEC framework. I'd like to again use the example we gave in the previous thread we replied to Ali's doubts to explain the need of source payload id for RTP flow. Ali, sorry, I was supposed to gave more detailed information on this. . Here are several assumptions on this example: 1) We assume a FEC-protected audiovisual stream which is combination of a video and a audio RTP flow. ID 0 identify video source data, and ID 1 identify audio source data. The definition of ID can be conveyed through SDP 2) RTP packets length is non-equal, e.g. in 16, 17, 19, 15, 8 bytes, as is shown. 3) A video or audio source packet is fed into a source block in an First-come-First-serve order in which the video and audio packets are generated. In which case we think the source-pay-load ID is needed. For backward-compatibility, the source payload id can be conveyed in an separate flow, which could be either an additional flow or the repair flow. Ali, would you please give a more details on "systematic approach"? I'm not following this. 0 16 B0,0 B0,1 B0,2 B0,3 B0,4 B0,5 B0,6 B0,7 B0,8 B0,9 B0,10 B0,11 B0,12 B0,13 B0,14 B0,15 0 0 0 0 17 B1,0 B1,1 B1,2 B1,3 B1,4 B1,5 B1,6 B1,7 B1,8 B1,9 B1,10 B1,11 B1,12 B1,13 B1,14 B1,15 B1,16 0 0 1 19 B2,0 B2,1 B2,2 B2,3 B2,4 B2,5 B2,6 B2,7 B2,8 B2,9 B2,10 B2,11 B2,12 B2,13 B2,14 B2,15 B2,16 B2,17 B2,18 0 15 B3,0 B3,1 B3,2 B3,3 B3,4 B3,5 B3,6 B3,7 B3,8 B3,9 B3,10 B3,11 B3,12 B3,13 B3,14 0 0 0 0 1 8 B4,0 B4,1 B4,2 B4,3 B4,4 B4,5 B4,6 B4,7 So here I think if we want to have answer on the necessity of the things in our draft, we need to at first have conclusions on the following: 1) whether the "back compatibility" Elinat and me are referring to is a real issue to be considered in FEC framework, And 2) if some cases like this one, which demands source payload id, stands and is representative. Cheers Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Einat Yellin (Lachover) [mailto:Einat@radvision.com] > Sent: Thursday, September 24, 2009 1:24 PM > To: zouzixuan; Ali C. Begen (abegen); fecframe@ietf.org > Cc: tme@multicasttech.com > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > Hi, > Backward compatibility is a major requirement for FEC framework, no > doubt. I believe that the discussion here is around whether a separate > flow for FEC mapping information is required. > > While following the discussion, I can relate to the reasons why not > having a separate flow as claimed by Ali: > a. This is a redundant flow since this information can be conveyed in > the FEC repair flow and in SDP even when protecting multiple RTP flows > (specifically you can see an example in > draft-galanos-fecframe-rtp-reedsolomon-mf-00). > b. This separate flow for mapping is also useful only for receivers that > support this draft, so the backward compatibility issue remains the same > as for the case where mapping is specified in the repair flow. > c. A separate flow increases the chance of losing packets. > > I must say that I don't understand the reasons for using a separate > flow. > Mr. Zou ZiXuan, is this meant for systems that do not use SDP? > > Best, > Einat > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf Of zouzixuan > Sent: Thursday, September 24, 2009 6:24 AM > To: 'Ali C. Begen (abegen)'; fecframe@ietf.org > Cc: tme@multicasttech.com > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > Hi, Ali > It's a good suggestion that others join the discussion on this. > The > point here is that whether we need to take the backward compatibility > into > account in FEC Framework or not. We may not ignore a fact that the > diversity > of clients exists in practice. We didn't mean to make the idea we > proposed > to be something depart from the framework. We just hope to complement > the > framework so that it can be practically more adaptable. > > Best regards, > Zou ZiXuan, Senior Research Staff > Media & Communication Lab > HUAWEI TECHNOLOGIES CO.,LTD. > > Address: Huawei Industrial Base > Bantian Longgang > Shenzhen 518129, P.R.China > Tel: +86 0755 28789364 > Fax: +86 0755 28788317 > E-mail: tendyntu@huawei.com > www.huawei.com > ------------------------------------------------------------------------ > ---- > --------------------------------------------------------- > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any > use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Thursday, September 24, 2009 12:09 AM > > To: zouzixuan; fecframe@ietf.org > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > There are multiple things here used as an excuse to depart from the > convention > > used in the framework. > > > > The main goal here seems to provide the non-framework capable RTP > > applications a way of using the nice features of the framework. In > this > example, > > "a nice feature" stands for the protection of multiple RTP streams > together. I > > will let others comment on this, too, but personally, I am not sure > whether we > > should be doing this. On one hand, we want the nice features, but at > the > same > > time we don't wanna support the framework, and the excuse is the > backward > > compatibility in environments with both framework-capable and > incapable > RTP > > receivers. In addition, using an additional flow may increase the > chances > of > > failure since if source fec payload id's are lost, receiver will be > clueless. This > > deserves a consensus from the WG, probably from AVT, too. > > > > Furthermore, I believe two RTP streams can be still protected together > w/o > any > > additional source fec payload id's (You asked for an example, and I > will > try to > > explain in simple words). If certain features of the RTP streams are > known > > (which is usually the case), by using a systematic approach (not in > the > sense of > > systematic FEC), things can probably be worked out. In your example, I > believe > > in each source block you wanna do a different order of the source > packets > and > > flows, so things are quite unpredictable. E.g., packet 16 and 17 are > before > > packet 15 of the same flow, packet 19 is before packet 8 of the other > flow, and > > packets belonging to flows 0 and 1 are dispersed, any particular > reason? > > > > But, if you follow a systematic approach, your CDP can convey the > mapping > out > > of band, and decoding will know what to expect and how to decode. > Remember > > that there will be constraints on which RTP streams you can combine > prior > to > > FEC encoding (this was brought up in the last meeting). > > > > If all the RTP streams belong to the same RTP session, their SSRC's > will > be > > different, so SSRC+seqnum should uniquely identify each source packet. > But, > > this would not work if the RTP streams would be from different > sessions. > In > > that case, they could share same SSRC's, and I can see the > complications. > > > > Cheers, acbegen. > > > > > > From: zouzixuan [mailto:tendyntu@huawei.com] > > Sent: Wednesday, September 23, 2009 4:28 AM > > To: Ali C. Begen (abegen); fecframe@ietf.org > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > First question, are you suggesting to apply FEC to the combination > of a > video > > > and audio RTP stream? > > > > > Second question, assuming the above case is true, I am still not > sure > why you > > > need an additional flow carrying the source payload ids. Is it > because > there > > are > > > two streams? Could you explain? > > > > It's not this case that just result in the need of carrying source > play id > in > > additional flow. It is this case to prove the need of source payload > id > for RTP > > flow. Because you need a source payload id, you gotta transfer it to > the > client, > > either in source packet as current FEC framework specified, or in an > additional > > flow described in our draft. The latter choice for transferring the > source > > payload is for making source packet accessible to non-fecframework > clients. > > > > This table shows an example of multiple flows. The table depicts the > structure > > of a source block, which is filled up with the packets (of length 16, > 17 > 19 15 and > > 8 bytes) from two sequenced flows. The packets from two flows are > identified > > by flow id 0 and 1, respectively. For FEC decoding, the receiver needs > to > know > > the position of each packet in the source block. The sequence number > can > only > > tell the order of a packet in the flow it belongs to in the source > block. > There is > > no way to tell where a packet exactly is in the source block. Source > Payload ID is > > thus in this case needed. Would you please give a solution which is > free > of > > source payload id? > > > > 0 > > 16 > > B0,0 > > B0,1 > > B0,2 > > B0,3 > > B0,4 > > B0,5 > > B0,6 > > B0,7 > > B0,8 > > B0,9 > > B0,10 > > B0,11 > > B0,12 > > B0,13 > > B0,14 > > B0,15 > > 0 > > 0 > > 0 > > 0 > > 17 > > B1,0 > > B1,1 > > B1,2 > > B1,3 > > B1,4 > > B1,5 > > B1,6 > > B1,7 > > B1,8 > > B1,9 > > B1,10 > > B1,11 > > B1,12 > > B1,13 > > B1,14 > > B1,15 > > B1,16 > > 0 > > 0 > > 1 > > 19 > > B2,0 > > B2,1 > > B2,2 > > B2,3 > > B2,4 > > B2,5 > > B2,6 > > B2,7 > > B2,8 > > B2,9 > > B2,10 > > B2,11 > > B2,12 > > B2,13 > > B2,14 > > B2,15 > > B2,16 > > B2,17 > > B2,18 > > 0 > > 15 > > B3,0 > > B3,1 > > B3,2 > > B3,3 > > B3,4 > > B3,5 > > B3,6 > > B3,7 > > B3,8 > > B3,9 > > B3,10 > > B3,11 > > B3,12 > > B3,13 > > B3,14 > > 0 > > 0 > > 0 > > 0 > > 1 > > 8 > > B4,0 > > B4,1 > > B4,2 > > B4,3 > > B4,4 > > B4,5 > > B4,6 > > B4,7 > > > > > > Hope this is clear. > > > > Zou ZiXuan, Senior Research Staff > > Media & Communication Lab > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > Address: Huawei Industrial Base > > Bantian Longgang > > Shenzhen 518129, P.R.China > > Tel: +86 0755 28789364 > > Fax: +86 0755 28788317 > > E-mail: tendyntu@huawei.com > > www.huawei.com > > > ------------------------------------------------------------------------ > ---- > ------------------------------------ > > --------------------- > > This e-mail and its attachments contain confidential information from > HUAWEI, > > which > > is intended only for the person or entity whose address is listed > above. > Any use > > of the > > information contained herein in any way (including, but not limited > to, > total or > > partial > > disclosure, reproduction, or dissemination) by persons other than the > intended > > recipient(s) is prohibited. If you receive this e-mail in error, > please > notify the > > sender by > > phone or email immediately and delete it! > > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Wednesday, September 23, 2009 11:29 AM > > > To: zouzixuan; fecframe@ietf.org > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > First question, are you suggesting to apply FEC to the combination > of a > video > > > and audio RTP stream? > > > > > > Second question, assuming the above case is true, I am still not > sure > why you > > > need an additional flow carrying the source payload ids. Is it > because > there > > are > > > two streams? Could you explain? > > > > > > Cheers, acbegen. > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Sun Sep 27 10:39:42 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6AC3A63EB for ; Sun, 27 Sep 2009 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[AWL=-1.468, BAYES_50=0.001, J_CHICKENPOX_46=0.6, 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 e5nb0nnAUS0y for ; Sun, 27 Sep 2009 10:39:40 -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 961CB3A67A7 for ; Sun, 27 Sep 2009 10:39:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE5Av0qrR7PE/2dsb2JhbAC8EIhTASsIjUwFgjATCIFT X-IronPort-AV: E=Sophos;i="4.44,461,1249257600"; d="scan'208";a="397265208" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2009 17:40:56 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8RHeuvP004753; Sun, 27 Sep 2009 10:40:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8RHeurE023706; Sun, 27 Sep 2009 17:40:56 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.3959); Sun, 27 Sep 2009 10:40:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Sep 2009 10:40:20 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A43E79B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <006c01ca3f59$16011790$420346b0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] draft-zixuan-fecframe-source-mi ?? Thread-Index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLwAABgvlAAGNW3EAAX8BAAAAOpM1AAL0thwACCllPw References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> <000601ca3bfc$1289f970$379dec50$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com> <002301ca3c27$b73056b0$25910410$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3935A8@xmb-sjc-215.amer.cisco.com> <007401ca3cc6$7b947b00$72bd7100$@com> <006c01ca3f59$16011790$420346b0$@com> From: "Ali C. Begen (abegen)" To: "zouzixuan" , "Einat Yellin (Lachover)" , , , X-OriginalArrivalTime: 27 Sep 2009 17:40:56.0258 (UTC) FILETIME=[AADC2220:01CA3F99] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15736; t=1254073256; x=1254937256; 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]=20draft-zixuan-fecframe-sour ce-mi=20?? |Sender:=20; bh=SZeB9zrdMN0GRbtwUrdyuovJftKPmRXV9Ot/UJ6bkRs=; b=uXndeBQIWWhQznAGy3GAbSR05mkjDb1ZlR+zF1xSVUiJZaWnaB+Bx/gCaJ U+YuCsUz3pJ15zBsA+w867CxhMSXk6MlBoJb2ohQ3kUiLFlxy/rFU9aoGXiP ZVqp+2x0vI; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 17:39:43 -0000 I am not questioning backward compatibility, I am questioning the cost = for it and the scenarios where we want backward compatibility. Einat did = a good summary, so now the WG needs to provide input. Regarding your example, putting the audio and video packets into the = source blocks as they are available does not seem to be a good design = choice to me. When I say "systematic," I mean you can create your source = blocks in a deterministic way (such as 4 packets from stream 1, one = packet from stream 2). Variable-packet size can be handled. Cheers, acbegen. > -----Original Message----- > From: zouzixuan [mailto:tendyntu@huawei.com] > Sent: Sunday, September 27, 2009 5:59 AM > To: 'Einat Yellin (Lachover)'; Ali C. Begen (abegen); = tme@multicasttech.com; > gjshep@gmail.com; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >=20 > Hi, Einat, Ali > Similar to Einat's explanation on "backward compatible" as stated > your draft , our intention is to keep source packet unmodified without > adding source payload id to it. And therefore the non-framework client = can > interpret the source packet. But I'm still not sure if the "backward > compatibility" we are referring to here is considered a valuable = requirement > in FEC framework. >=20 > I'd like to again use the example we gave in the previous thread we > replied to Ali's doubts to explain the need of source payload id for = RTP > flow. Ali, sorry, I was supposed to gave more detailed information on = this. > . > Here are several assumptions on this example: > 1) We assume a FEC-protected audiovisual stream which is > combination of a video and a audio RTP flow. ID 0 identify video = source > data, and ID 1 identify audio source data. The definition of ID can be > conveyed through SDP > 2) RTP packets length is non-equal, e.g. in 16, 17, 19, 15, 8 > bytes, as is shown. > 3) A video or audio source packet is fed into a source block in an > First-come-First-serve order in which the video and audio packets are > generated. >=20 > In which case we think the source-pay-load ID is needed. For > backward-compatibility, the source payload id can be conveyed in an = separate > flow, which could be either an additional flow or the repair flow. >=20 > Ali, would you please give a more details on "systematic approach"? = I'm > not following this. >=20 > 0 16 B0,0 B0,1 B0,2 B0,3 B0,4 B0,5 B0,6 B0,7 > B0,8 B0,9 B0,10 B0,11 B0,12 B0,13 B0,14 B0,15 0 0 0 >=20 > 0 17 B1,0 B1,1 B1,2 B1,3 B1,4 B1,5 B1,6 > B1,7 > B1,8 B1,9 B1,10 B1,11 B1,12 B1,13 B1,14 B1,15 B1,16 0 > 0 >=20 > 1 19 B2,0 B2,1 B2,2 B2,3 B2,4 B2,5 > B2,6 B2,7 > B2,8 B2,9 B2,10 B2,11 B2,12 B2,13 B2,14 B2,15 B2,16 B2,17 > B2,18 >=20 > 0 15 B3,0 B3,1 B3,2 B3,3 B3,4 B3,5 B3,6 > B3,7 > B3,8 B3,9 B3,10 B3,11 B3,12 B3,13 B3,14 0 0 0 > 0 >=20 > 1 8 B4,0 B4,1 B4,2 B4,3 B4,4 B4,5 B4,6 > B4,7 >=20 > So here I think if we want to have answer on the necessity of the = things in > our draft, we need to at first have conclusions on the following: 1) = whether > the "back compatibility" Elinat and me are referring to is a real = issue to > be considered in FEC framework, And 2) if some cases like this one, = which > demands source payload id, stands and is representative. >=20 > Cheers > Zou ZiXuan, Senior Research Staff > Media & Communication Lab > HUAWEI TECHNOLOGIES CO.,LTD. >=20 > Address: Huawei Industrial Base > Bantian Longgang > Shenzhen 518129, P.R.China > Tel: +86 0755 28789364 > Fax: +86 0755 28788317 > E-mail: tendyntu@huawei.com > www.huawei.com > = -------------------------------------------------------------------------= --- > --------------------------------------------------------- > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed = above. Any > use of the > information contained herein in any way (including, but not limited = to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, = please > notify the sender by > phone or email immediately and delete it! >=20 > > -----Original Message----- > > From: Einat Yellin (Lachover) [mailto:Einat@radvision.com] > > Sent: Thursday, September 24, 2009 1:24 PM > > To: zouzixuan; Ali C. Begen (abegen); fecframe@ietf.org > > Cc: tme@multicasttech.com > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > Hi, > > Backward compatibility is a major requirement for FEC framework, no > > doubt. I believe that the discussion here is around whether a = separate > > flow for FEC mapping information is required. > > > > While following the discussion, I can relate to the reasons why not > > having a separate flow as claimed by Ali: > > a. This is a redundant flow since this information can be conveyed = in > > the FEC repair flow and in SDP even when protecting multiple RTP = flows > > (specifically you can see an example in > > draft-galanos-fecframe-rtp-reedsolomon-mf-00). > > b. This separate flow for mapping is also useful only for receivers = that > > support this draft, so the backward compatibility issue remains the = same > > as for the case where mapping is specified in the repair flow. > > c. A separate flow increases the chance of losing packets. > > > > I must say that I don't understand the reasons for using a separate > > flow. > > Mr. Zou ZiXuan, is this meant for systems that do not use SDP? > > > > Best, > > Einat > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On > > Behalf Of zouzixuan > > Sent: Thursday, September 24, 2009 6:24 AM > > To: 'Ali C. Begen (abegen)'; fecframe@ietf.org > > Cc: tme@multicasttech.com > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > Hi, Ali > > It's a good suggestion that others join the discussion on this. > > The > > point here is that whether we need to take the backward = compatibility > > into > > account in FEC Framework or not. We may not ignore a fact that the > > diversity > > of clients exists in practice. We didn't mean to make the idea we > > proposed > > to be something depart from the framework. We just hope to = complement > > the > > framework so that it can be practically more adaptable. > > > > Best regards, > > Zou ZiXuan, Senior Research Staff > > Media & Communication Lab > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > Address: Huawei Industrial Base > > Bantian Longgang > > Shenzhen 518129, P.R.China > > Tel: +86 0755 28789364 > > Fax: +86 0755 28788317 > > E-mail: tendyntu@huawei.com > > www.huawei.com > > = ------------------------------------------------------------------------ > > ---- > > --------------------------------------------------------- > > This e-mail and its attachments contain confidential information = from > > HUAWEI, which > > is intended only for the person or entity whose address is listed = above. > > Any > > use of the > > information contained herein in any way (including, but not limited = to, > > total or partial > > disclosure, reproduction, or dissemination) by persons other than = the > > intended > > recipient(s) is prohibited. If you receive this e-mail in error, = please > > notify the sender by > > phone or email immediately and delete it! > > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Thursday, September 24, 2009 12:09 AM > > > To: zouzixuan; fecframe@ietf.org > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > There are multiple things here used as an excuse to depart from = the > > convention > > > used in the framework. > > > > > > The main goal here seems to provide the non-framework capable RTP > > > applications a way of using the nice features of the framework. In > > this > > example, > > > "a nice feature" stands for the protection of multiple RTP streams > > together. I > > > will let others comment on this, too, but personally, I am not = sure > > whether we > > > should be doing this. On one hand, we want the nice features, but = at > > the > > same > > > time we don't wanna support the framework, and the excuse is the > > backward > > > compatibility in environments with both framework-capable and > > incapable > > RTP > > > receivers. In addition, using an additional flow may increase the > > chances > > of > > > failure since if source fec payload id's are lost, receiver will = be > > clueless. This > > > deserves a consensus from the WG, probably from AVT, too. > > > > > > Furthermore, I believe two RTP streams can be still protected = together > > w/o > > any > > > additional source fec payload id's (You asked for an example, and = I > > will > > try to > > > explain in simple words). If certain features of the RTP streams = are > > known > > > (which is usually the case), by using a systematic approach (not = in > > the > > sense of > > > systematic FEC), things can probably be worked out. In your = example, I > > believe > > > in each source block you wanna do a different order of the source > > packets > > and > > > flows, so things are quite unpredictable. E.g., packet 16 and 17 = are > > before > > > packet 15 of the same flow, packet 19 is before packet 8 of the = other > > flow, and > > > packets belonging to flows 0 and 1 are dispersed, any particular > > reason? > > > > > > But, if you follow a systematic approach, your CDP can convey the > > mapping > > out > > > of band, and decoding will know what to expect and how to decode. > > Remember > > > that there will be constraints on which RTP streams you can = combine > > prior > > to > > > FEC encoding (this was brought up in the last meeting). > > > > > > If all the RTP streams belong to the same RTP session, their = SSRC's > > will > > be > > > different, so SSRC+seqnum should uniquely identify each source = packet. > > But, > > > this would not work if the RTP streams would be from different > > sessions. > > In > > > that case, they could share same SSRC's, and I can see the > > complications. > > > > > > Cheers, acbegen. > > > > > > > > > From: zouzixuan [mailto:tendyntu@huawei.com] > > > Sent: Wednesday, September 23, 2009 4:28 AM > > > To: Ali C. Begen (abegen); fecframe@ietf.org > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > > > > First question, are you suggesting to apply FEC to the = combination > > of a > > video > > > > and audio RTP stream? > > > > > > > Second question, assuming the above case is true, I am still not > > sure > > why you > > > > need an additional flow carrying the source payload ids. Is it > > because > > there > > > are > > > > two streams? Could you explain? > > > > > > It's not this case that just result in the need of carrying source > > play id > > in > > > additional flow. It is this case to prove the need of source = payload > > id > > for RTP > > > flow. Because you need a source payload id, you gotta transfer it = to > > the > > client, > > > either in source packet as current FEC framework specified, or in = an > > additional > > > flow described in our draft. The latter choice for transferring = the > > source > > > payload is for making source packet accessible to non-fecframework > > clients. > > > > > > This table shows an example of multiple flows. The table depicts = the > > structure > > > of a source block, which is filled up with the packets (of length = 16, > > 17 > > 19 15 and > > > 8 bytes) from two sequenced flows. The packets from two flows are > > identified > > > by flow id 0 and 1, respectively. For FEC decoding, the receiver = needs > > to > > know > > > the position of each packet in the source block. The sequence = number > > can > > only > > > tell the order of a packet in the flow it belongs to in the source > > block. > > There is > > > no way to tell where a packet exactly is in the source block. = Source > > Payload ID is > > > thus in this case needed. Would you please give a solution which = is > > free > > of > > > source payload id? > > > > > > 0 > > > 16 > > > B0,0 > > > B0,1 > > > B0,2 > > > B0,3 > > > B0,4 > > > B0,5 > > > B0,6 > > > B0,7 > > > B0,8 > > > B0,9 > > > B0,10 > > > B0,11 > > > B0,12 > > > B0,13 > > > B0,14 > > > B0,15 > > > 0 > > > 0 > > > 0 > > > 0 > > > 17 > > > B1,0 > > > B1,1 > > > B1,2 > > > B1,3 > > > B1,4 > > > B1,5 > > > B1,6 > > > B1,7 > > > B1,8 > > > B1,9 > > > B1,10 > > > B1,11 > > > B1,12 > > > B1,13 > > > B1,14 > > > B1,15 > > > B1,16 > > > 0 > > > 0 > > > 1 > > > 19 > > > B2,0 > > > B2,1 > > > B2,2 > > > B2,3 > > > B2,4 > > > B2,5 > > > B2,6 > > > B2,7 > > > B2,8 > > > B2,9 > > > B2,10 > > > B2,11 > > > B2,12 > > > B2,13 > > > B2,14 > > > B2,15 > > > B2,16 > > > B2,17 > > > B2,18 > > > 0 > > > 15 > > > B3,0 > > > B3,1 > > > B3,2 > > > B3,3 > > > B3,4 > > > B3,5 > > > B3,6 > > > B3,7 > > > B3,8 > > > B3,9 > > > B3,10 > > > B3,11 > > > B3,12 > > > B3,13 > > > B3,14 > > > 0 > > > 0 > > > 0 > > > 0 > > > 1 > > > 8 > > > B4,0 > > > B4,1 > > > B4,2 > > > B4,3 > > > B4,4 > > > B4,5 > > > B4,6 > > > B4,7 > > > > > > > > > Hope this is clear. > > > > > > Zou ZiXuan, Senior Research Staff > > > Media & Communication Lab > > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > > > Address: Huawei Industrial Base > > > Bantian Longgang > > > Shenzhen 518129, P.R.China > > > Tel: +86 0755 28789364 > > > Fax: +86 0755 28788317 > > > E-mail: tendyntu@huawei.com > > > www.huawei.com > > > > > = ------------------------------------------------------------------------ > > ---- > > ------------------------------------ > > > --------------------- > > > This e-mail and its attachments contain confidential information = from > > HUAWEI, > > > which > > > is intended only for the person or entity whose address is listed > > above. > > Any use > > > of the > > > information contained herein in any way (including, but not = limited > > to, > > total or > > > partial > > > disclosure, reproduction, or dissemination) by persons other than = the > > intended > > > recipient(s) is prohibited. If you receive this e-mail in error, > > please > > notify the > > > sender by > > > phone or email immediately and delete it! > > > > > > > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Wednesday, September 23, 2009 11:29 AM > > > > To: zouzixuan; fecframe@ietf.org > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > First question, are you suggesting to apply FEC to the = combination > > of a > > video > > > > and audio RTP stream? > > > > > > > > Second question, assuming the above case is true, I am still not > > sure > > why you > > > > need an additional flow carrying the source payload ids. Is it > > because > > there > > > are > > > > two streams? Could you explain? > > > > > > > > Cheers, acbegen. > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe From tendyntu@huawei.com Mon Sep 28 01:55:58 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FCDC3A67F9 for ; Mon, 28 Sep 2009 01:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMFfue22fvpN for ; Mon, 28 Sep 2009 01:55:57 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7A61F3A67C2 for ; Mon, 28 Sep 2009 01:55:56 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQO00GN1BJ3FU@szxga01-in.huawei.com> for fecframe@ietf.org; Mon, 28 Sep 2009 16:57:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQO00MMJBJ3SK@szxga01-in.huawei.com> for fecframe@ietf.org; Mon, 28 Sep 2009 16:57:03 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQO00244BJ3VG@szxml04-in.huawei.com> for fecframe@ietf.org; Mon, 28 Sep 2009 16:57:03 +0800 (CST) Date: Mon, 28 Sep 2009 16:57:03 +0800 From: zouzixuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540A43E79B@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , "'Einat Yellin (Lachover)'" , tme@multicasttech.com, gjshep@gmail.com, fecframe@ietf.org Message-id: <000001ca4019$a5b58fe0$f120afa0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLwAABgvlAAGNW3EAAX8BAAAAOpM1AAL0thwACCllPwAB/ES3A= References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com> <00ad01ca384e$10f8b620$32ea2260$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com> <00ce01ca38fe$1364eb30$3a2ec190$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com> <000601ca3bfc$1289f970$379dec50$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com> <002301ca3c27$b73056b0$25910410$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A3935A8@xmb-sjc-215.amer.cisco.com> <007401ca3cc6$7b947b00$72bd7100$@com> <006c01ca3f59$16011790$420346b0$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A43E79B@xmb-sjc-215.amer.cisco.com> Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 08:55:58 -0000 Hi, Ali > I am not questioning backward compatibility, I am questioning the cost for it > and the scenarios where we want backward compatibility. Einat did a good > summary, so now the WG needs to provide input. You mean there should be some input on backward compatibility to the framework. > Regarding your example, putting the audio and video packets into the source > blocks as they are available does not seem to be a good design choice to me. > When I say "systematic," I mean you can create your source blocks in a > deterministic way (such as 4 packets from stream 1, one packet from stream 2). > Variable-packet size can be handled. In this "systematic" case, how could we know the position of a packet in the source block? Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Monday, September 28, 2009 1:40 AM > To: zouzixuan; Einat Yellin (Lachover); tme@multicasttech.com; > gjshep@gmail.com; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > I am not questioning backward compatibility, I am questioning the cost for it > and the scenarios where we want backward compatibility. Einat did a good > summary, so now the WG needs to provide input. > > Regarding your example, putting the audio and video packets into the source > blocks as they are available does not seem to be a good design choice to me. > When I say "systematic," I mean you can create your source blocks in a > deterministic way (such as 4 packets from stream 1, one packet from stream 2). > Variable-packet size can be handled. > > Cheers, acbegen. > > > -----Original Message----- > > From: zouzixuan [mailto:tendyntu@huawei.com] > > Sent: Sunday, September 27, 2009 5:59 AM > > To: 'Einat Yellin (Lachover)'; Ali C. Begen (abegen); tme@multicasttech.com; > > gjshep@gmail.com; fecframe@ietf.org > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > Hi, Einat, Ali > > Similar to Einat's explanation on "backward compatible" as stated > > your draft , our intention is to keep source packet unmodified without > > adding source payload id to it. And therefore the non-framework client can > > interpret the source packet. But I'm still not sure if the "backward > > compatibility" we are referring to here is considered a valuable requirement > > in FEC framework. > > > > I'd like to again use the example we gave in the previous thread we > > replied to Ali's doubts to explain the need of source payload id for RTP > > flow. Ali, sorry, I was supposed to gave more detailed information on this. > > . > > Here are several assumptions on this example: > > 1) We assume a FEC-protected audiovisual stream which is > > combination of a video and a audio RTP flow. ID 0 identify video source > > data, and ID 1 identify audio source data. The definition of ID can be > > conveyed through SDP > > 2) RTP packets length is non-equal, e.g. in 16, 17, 19, 15, 8 > > bytes, as is shown. > > 3) A video or audio source packet is fed into a source block in an > > First-come-First-serve order in which the video and audio packets are > > generated. > > > > In which case we think the source-pay-load ID is needed. For > > backward-compatibility, the source payload id can be conveyed in an separate > > flow, which could be either an additional flow or the repair flow. > > > > Ali, would you please give a more details on "systematic approach"? I'm > > not following this. > > > > 0 16 B0,0 B0,1 B0,2 B0,3 B0,4 B0,5 B0,6 > B0,7 > > B0,8 B0,9 B0,10 B0,11 B0,12 B0,13 B0,14 B0,15 0 0 0 > > > > 0 17 B1,0 B1,1 B1,2 B1,3 B1,4 B1,5 B1,6 > > B1,7 > > B1,8 B1,9 B1,10 B1,11 B1,12 B1,13 B1,14 B1,15 B1,16 0 > > 0 > > > > 1 19 B2,0 B2,1 B2,2 B2,3 B2,4 B2,5 > > B2,6 B2,7 > > B2,8 B2,9 B2,10 B2,11 B2,12 B2,13 B2,14 B2,15 B2,16 > B2,17 > > B2,18 > > > > 0 15 B3,0 B3,1 B3,2 B3,3 B3,4 B3,5 B3,6 > > B3,7 > > B3,8 B3,9 B3,10 B3,11 B3,12 B3,13 B3,14 0 0 0 > > 0 > > > > 1 8 B4,0 B4,1 B4,2 B4,3 B4,4 B4,5 B4,6 > > B4,7 > > > > So here I think if we want to have answer on the necessity of the things in > > our draft, we need to at first have conclusions on the following: 1) whether > > the "back compatibility" Elinat and me are referring to is a real issue to > > be considered in FEC framework, And 2) if some cases like this one, which > > demands source payload id, stands and is representative. > > > > Cheers > > Zou ZiXuan, Senior Research Staff > > Media & Communication Lab > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > Address: Huawei Industrial Base > > Bantian Longgang > > Shenzhen 518129, P.R.China > > Tel: +86 0755 28789364 > > Fax: +86 0755 28788317 > > E-mail: tendyntu@huawei.com > > www.huawei.com > > ---------------------------------------------------------------------------- > > --------------------------------------------------------- > > This e-mail and its attachments contain confidential information from > > HUAWEI, which > > is intended only for the person or entity whose address is listed above. Any > > use of the > > information contained herein in any way (including, but not limited to, > > total or partial > > disclosure, reproduction, or dissemination) by persons other than the > > intended > > recipient(s) is prohibited. If you receive this e-mail in error, please > > notify the sender by > > phone or email immediately and delete it! > > > > > -----Original Message----- > > > From: Einat Yellin (Lachover) [mailto:Einat@radvision.com] > > > Sent: Thursday, September 24, 2009 1:24 PM > > > To: zouzixuan; Ali C. Begen (abegen); fecframe@ietf.org > > > Cc: tme@multicasttech.com > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > Hi, > > > Backward compatibility is a major requirement for FEC framework, no > > > doubt. I believe that the discussion here is around whether a separate > > > flow for FEC mapping information is required. > > > > > > While following the discussion, I can relate to the reasons why not > > > having a separate flow as claimed by Ali: > > > a. This is a redundant flow since this information can be conveyed in > > > the FEC repair flow and in SDP even when protecting multiple RTP flows > > > (specifically you can see an example in > > > draft-galanos-fecframe-rtp-reedsolomon-mf-00). > > > b. This separate flow for mapping is also useful only for receivers that > > > support this draft, so the backward compatibility issue remains the same > > > as for the case where mapping is specified in the repair flow. > > > c. A separate flow increases the chance of losing packets. > > > > > > I must say that I don't understand the reasons for using a separate > > > flow. > > > Mr. Zou ZiXuan, is this meant for systems that do not use SDP? > > > > > > Best, > > > Einat > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > > > Behalf Of zouzixuan > > > Sent: Thursday, September 24, 2009 6:24 AM > > > To: 'Ali C. Begen (abegen)'; fecframe@ietf.org > > > Cc: tme@multicasttech.com > > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > Hi, Ali > > > It's a good suggestion that others join the discussion on this. > > > The > > > point here is that whether we need to take the backward compatibility > > > into > > > account in FEC Framework or not. We may not ignore a fact that the > > > diversity > > > of clients exists in practice. We didn't mean to make the idea we > > > proposed > > > to be something depart from the framework. We just hope to complement > > > the > > > framework so that it can be practically more adaptable. > > > > > > Best regards, > > > Zou ZiXuan, Senior Research Staff > > > Media & Communication Lab > > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > > > Address: Huawei Industrial Base > > > Bantian Longgang > > > Shenzhen 518129, P.R.China > > > Tel: +86 0755 28789364 > > > Fax: +86 0755 28788317 > > > E-mail: tendyntu@huawei.com > > > www.huawei.com > > > ------------------------------------------------------------------------ > > > ---- > > > --------------------------------------------------------- > > > This e-mail and its attachments contain confidential information from > > > HUAWEI, which > > > is intended only for the person or entity whose address is listed above. > > > Any > > > use of the > > > information contained herein in any way (including, but not limited to, > > > total or partial > > > disclosure, reproduction, or dissemination) by persons other than the > > > intended > > > recipient(s) is prohibited. If you receive this e-mail in error, please > > > notify the sender by > > > phone or email immediately and delete it! > > > > > > > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Thursday, September 24, 2009 12:09 AM > > > > To: zouzixuan; fecframe@ietf.org > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > There are multiple things here used as an excuse to depart from the > > > convention > > > > used in the framework. > > > > > > > > The main goal here seems to provide the non-framework capable RTP > > > > applications a way of using the nice features of the framework. In > > > this > > > example, > > > > "a nice feature" stands for the protection of multiple RTP streams > > > together. I > > > > will let others comment on this, too, but personally, I am not sure > > > whether we > > > > should be doing this. On one hand, we want the nice features, but at > > > the > > > same > > > > time we don't wanna support the framework, and the excuse is the > > > backward > > > > compatibility in environments with both framework-capable and > > > incapable > > > RTP > > > > receivers. In addition, using an additional flow may increase the > > > chances > > > of > > > > failure since if source fec payload id's are lost, receiver will be > > > clueless. This > > > > deserves a consensus from the WG, probably from AVT, too. > > > > > > > > Furthermore, I believe two RTP streams can be still protected together > > > w/o > > > any > > > > additional source fec payload id's (You asked for an example, and I > > > will > > > try to > > > > explain in simple words). If certain features of the RTP streams are > > > known > > > > (which is usually the case), by using a systematic approach (not in > > > the > > > sense of > > > > systematic FEC), things can probably be worked out. In your example, I > > > believe > > > > in each source block you wanna do a different order of the source > > > packets > > > and > > > > flows, so things are quite unpredictable. E.g., packet 16 and 17 are > > > before > > > > packet 15 of the same flow, packet 19 is before packet 8 of the other > > > flow, and > > > > packets belonging to flows 0 and 1 are dispersed, any particular > > > reason? > > > > > > > > But, if you follow a systematic approach, your CDP can convey the > > > mapping > > > out > > > > of band, and decoding will know what to expect and how to decode. > > > Remember > > > > that there will be constraints on which RTP streams you can combine > > > prior > > > to > > > > FEC encoding (this was brought up in the last meeting). > > > > > > > > If all the RTP streams belong to the same RTP session, their SSRC's > > > will > > > be > > > > different, so SSRC+seqnum should uniquely identify each source packet. > > > But, > > > > this would not work if the RTP streams would be from different > > > sessions. > > > In > > > > that case, they could share same SSRC's, and I can see the > > > complications. > > > > > > > > Cheers, acbegen. > > > > > > > > > > > > From: zouzixuan [mailto:tendyntu@huawei.com] > > > > Sent: Wednesday, September 23, 2009 4:28 AM > > > > To: Ali C. Begen (abegen); fecframe@ietf.org > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > > > > > > > First question, are you suggesting to apply FEC to the combination > > > of a > > > video > > > > > and audio RTP stream? > > > > > > > > > Second question, assuming the above case is true, I am still not > > > sure > > > why you > > > > > need an additional flow carrying the source payload ids. Is it > > > because > > > there > > > > are > > > > > two streams? Could you explain? > > > > > > > > It's not this case that just result in the need of carrying source > > > play id > > > in > > > > additional flow. It is this case to prove the need of source payload > > > id > > > for RTP > > > > flow. Because you need a source payload id, you gotta transfer it to > > > the > > > client, > > > > either in source packet as current FEC framework specified, or in an > > > additional > > > > flow described in our draft. The latter choice for transferring the > > > source > > > > payload is for making source packet accessible to non-fecframework > > > clients. > > > > > > > > This table shows an example of multiple flows. The table depicts the > > > structure > > > > of a source block, which is filled up with the packets (of length 16, > > > 17 > > > 19 15 and > > > > 8 bytes) from two sequenced flows. The packets from two flows are > > > identified > > > > by flow id 0 and 1, respectively. For FEC decoding, the receiver needs > > > to > > > know > > > > the position of each packet in the source block. The sequence number > > > can > > > only > > > > tell the order of a packet in the flow it belongs to in the source > > > block. > > > There is > > > > no way to tell where a packet exactly is in the source block. Source > > > Payload ID is > > > > thus in this case needed. Would you please give a solution which is > > > free > > > of > > > > source payload id? > > > > > > > > 0 > > > > 16 > > > > B0,0 > > > > B0,1 > > > > B0,2 > > > > B0,3 > > > > B0,4 > > > > B0,5 > > > > B0,6 > > > > B0,7 > > > > B0,8 > > > > B0,9 > > > > B0,10 > > > > B0,11 > > > > B0,12 > > > > B0,13 > > > > B0,14 > > > > B0,15 > > > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 17 > > > > B1,0 > > > > B1,1 > > > > B1,2 > > > > B1,3 > > > > B1,4 > > > > B1,5 > > > > B1,6 > > > > B1,7 > > > > B1,8 > > > > B1,9 > > > > B1,10 > > > > B1,11 > > > > B1,12 > > > > B1,13 > > > > B1,14 > > > > B1,15 > > > > B1,16 > > > > 0 > > > > 0 > > > > 1 > > > > 19 > > > > B2,0 > > > > B2,1 > > > > B2,2 > > > > B2,3 > > > > B2,4 > > > > B2,5 > > > > B2,6 > > > > B2,7 > > > > B2,8 > > > > B2,9 > > > > B2,10 > > > > B2,11 > > > > B2,12 > > > > B2,13 > > > > B2,14 > > > > B2,15 > > > > B2,16 > > > > B2,17 > > > > B2,18 > > > > 0 > > > > 15 > > > > B3,0 > > > > B3,1 > > > > B3,2 > > > > B3,3 > > > > B3,4 > > > > B3,5 > > > > B3,6 > > > > B3,7 > > > > B3,8 > > > > B3,9 > > > > B3,10 > > > > B3,11 > > > > B3,12 > > > > B3,13 > > > > B3,14 > > > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 1 > > > > 8 > > > > B4,0 > > > > B4,1 > > > > B4,2 > > > > B4,3 > > > > B4,4 > > > > B4,5 > > > > B4,6 > > > > B4,7 > > > > > > > > > > > > Hope this is clear. > > > > > > > > Zou ZiXuan, Senior Research Staff > > > > Media & Communication Lab > > > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > > > > > Address: Huawei Industrial Base > > > > Bantian Longgang > > > > Shenzhen 518129, P.R.China > > > > Tel: +86 0755 28789364 > > > > Fax: +86 0755 28788317 > > > > E-mail: tendyntu@huawei.com > > > > www.huawei.com > > > > > > > ------------------------------------------------------------------------ > > > ---- > > > ------------------------------------ > > > > --------------------- > > > > This e-mail and its attachments contain confidential information from > > > HUAWEI, > > > > which > > > > is intended only for the person or entity whose address is listed > > > above. > > > Any use > > > > of the > > > > information contained herein in any way (including, but not limited > > > to, > > > total or > > > > partial > > > > disclosure, reproduction, or dissemination) by persons other than the > > > intended > > > > recipient(s) is prohibited. If you receive this e-mail in error, > > > please > > > notify the > > > > sender by > > > > phone or email immediately and delete it! > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > > Sent: Wednesday, September 23, 2009 11:29 AM > > > > > To: zouzixuan; fecframe@ietf.org > > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > > > First question, are you suggesting to apply FEC to the combination > > > of a > > > video > > > > > and audio RTP stream? > > > > > > > > > > Second question, assuming the above case is true, I am still not > > > sure > > > why you > > > > > need an additional flow carrying the source payload ids. Is it > > > because > > > there > > > > are > > > > > two streams? Could you explain? > > > > > > > > > > Cheers, acbegen. > > > > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe From Einat@radvision.com Mon Sep 28 23:30:11 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B683A6A64 for ; Mon, 28 Sep 2009 23:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhBOVTEQQf+k for ; Mon, 28 Sep 2009 23:30:09 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id A1D803A6A14 for ; Mon, 28 Sep 2009 23:30:08 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n8T6iifa028056 for fecframe@ietf.org; Tue, 29 Sep 2009 08:44:44 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n8T6iXff028046; Tue, 29 Sep 2009 08:44:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Sep 2009 08:31:17 +0200 Message-ID: In-Reply-To: <000001ca4019$a5b58fe0$f120afa0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] draft-zixuan-fecframe-source-mi ?? Thread-Index: Aco3nVIPVK5xs7lSTLOi/f8mPCRDaAAAOO/wACvtMQAAACW/oAAqJRZgAAI0kXAAvGdMsAAC9bLwAABgvlAAGNW3EAAX8BAAAAOpM1AAL0thwACCllPwAB/ES3AALYECkA== References: <38c19b540909170646u3e43c5c0vffbfe3e7f6732f20@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D540A301223@xmb-sjc-215.amer.cisco.com><00ad01ca384e$10f8b620$32ea2260$@com><04CAD96D4C5A3D48B1919248A8FE0D540A3927D7@xmb-sjc-215.amer.cisco.com><00ce01ca38fe$1364eb30$3a2ec190$@com><04CAD96D4C5A3D48B1919248A8FE0D540A392B9B@xmb-sjc-215.amer.cisco.com><000601ca3bfc$1289f970$379dec50$@com><04CAD96D4C5A3D48B1919248A8FE0D540A39349B@xmb-sjc-215.amer.cisco.com><002301ca3c27$b73056b0$25910410$@com><04CAD96D4C5A3D48B1919248A8FE0D540A3935A8@xmb-sjc-215.amer.cisco.com><007401ca3cc6$7b947b00$72bd7100$@com><006c01ca3f59$16011790$420346b0$@com><04CAD96D4C5A3D48B1919248A8FE0D540A43E79B@xmb-sjc-215.amer.cisco.com> <000001ca4019$a5b58fe0$f120afa0$@com> From: "Einat Yellin (Lachover)" To: "zouzixuan" , "Ali C. Begen (abegen)" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id n8T6iXff028046 Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 06:30:11 -0000 -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of zouzixuan Sent: Monday, September 28, 2009 10:57 AM To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover); tme@multicasttech.com; gjshep@gmail.com; fecframe@ietf.org Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? Hi, Ali > I am not questioning backward compatibility, I am questioning the cost for it > and the scenarios where we want backward compatibility. Einat did a good > summary, so now the WG needs to provide input. You mean there should be some input on backward compatibility to the framework. > Regarding your example, putting the audio and video packets into the source > blocks as they are available does not seem to be a good design choice to me. > When I say "systematic," I mean you can create your source blocks in a > deterministic way (such as 4 packets from stream 1, one packet from stream 2). > Variable-packet size can be handled. In this "systematic" case, how could we know the position of a packet in the source block? [Einat] There are different ways to signal the source block structure. In our draft we followed rfc 5109 and used the 'base' (first) RTP sequence number along with a bitmap. This works for the cases where what matters is which RTP packets belong to this FEC source block and the order of the packets in the FEC source block is deterministic (from lower SN to higher SN and from lower flow ID to higher flow ID). If a more detailed structure of source block is needed then I agree that the bitmap is not enough. Still, this information can be sent as part of the repair packet header which IMO makes more sense. Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ------------------------------------------------------------------------ ---- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Monday, September 28, 2009 1:40 AM > To: zouzixuan; Einat Yellin (Lachover); tme@multicasttech.com; > gjshep@gmail.com; fecframe@ietf.org > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > I am not questioning backward compatibility, I am questioning the cost for it > and the scenarios where we want backward compatibility. Einat did a good > summary, so now the WG needs to provide input. > > Regarding your example, putting the audio and video packets into the source > blocks as they are available does not seem to be a good design choice to me. > When I say "systematic," I mean you can create your source blocks in a > deterministic way (such as 4 packets from stream 1, one packet from stream 2). > Variable-packet size can be handled. > > Cheers, acbegen. > > > -----Original Message----- > > From: zouzixuan [mailto:tendyntu@huawei.com] > > Sent: Sunday, September 27, 2009 5:59 AM > > To: 'Einat Yellin (Lachover)'; Ali C. Begen (abegen); tme@multicasttech.com; > > gjshep@gmail.com; fecframe@ietf.org > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > Hi, Einat, Ali > > Similar to Einat's explanation on "backward compatible" as stated > > your draft , our intention is to keep source packet unmodified without > > adding source payload id to it. And therefore the non-framework client can > > interpret the source packet. But I'm still not sure if the "backward > > compatibility" we are referring to here is considered a valuable requirement > > in FEC framework. > > > > I'd like to again use the example we gave in the previous thread we > > replied to Ali's doubts to explain the need of source payload id for RTP > > flow. Ali, sorry, I was supposed to gave more detailed information on this. > > . > > Here are several assumptions on this example: > > 1) We assume a FEC-protected audiovisual stream which is > > combination of a video and a audio RTP flow. ID 0 identify video source > > data, and ID 1 identify audio source data. The definition of ID can be > > conveyed through SDP > > 2) RTP packets length is non-equal, e.g. in 16, 17, 19, 15, 8 > > bytes, as is shown. > > 3) A video or audio source packet is fed into a source block in an > > First-come-First-serve order in which the video and audio packets are > > generated. > > > > In which case we think the source-pay-load ID is needed. For > > backward-compatibility, the source payload id can be conveyed in an separate > > flow, which could be either an additional flow or the repair flow. > > > > Ali, would you please give a more details on "systematic approach"? I'm > > not following this. > > > > 0 16 B0,0 B0,1 B0,2 B0,3 B0,4 B0,5 B0,6 > B0,7 > > B0,8 B0,9 B0,10 B0,11 B0,12 B0,13 B0,14 B0,15 0 0 0 > > > > 0 17 B1,0 B1,1 B1,2 B1,3 B1,4 B1,5 B1,6 > > B1,7 > > B1,8 B1,9 B1,10 B1,11 B1,12 B1,13 B1,14 B1,15 B1,16 0 > > 0 > > > > 1 19 B2,0 B2,1 B2,2 B2,3 B2,4 B2,5 > > B2,6 B2,7 > > B2,8 B2,9 B2,10 B2,11 B2,12 B2,13 B2,14 B2,15 B2,16 > B2,17 > > B2,18 > > > > 0 15 B3,0 B3,1 B3,2 B3,3 B3,4 B3,5 B3,6 > > B3,7 > > B3,8 B3,9 B3,10 B3,11 B3,12 B3,13 B3,14 0 0 0 > > 0 > > > > 1 8 B4,0 B4,1 B4,2 B4,3 B4,4 B4,5 B4,6 > > B4,7 > > > > So here I think if we want to have answer on the necessity of the things in > > our draft, we need to at first have conclusions on the following: 1) whether > > the "back compatibility" Elinat and me are referring to is a real issue to > > be considered in FEC framework, And 2) if some cases like this one, which > > demands source payload id, stands and is representative. > > > > Cheers > > Zou ZiXuan, Senior Research Staff > > Media & Communication Lab > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > Address: Huawei Industrial Base > > Bantian Longgang > > Shenzhen 518129, P.R.China > > Tel: +86 0755 28789364 > > Fax: +86 0755 28788317 > > E-mail: tendyntu@huawei.com > > www.huawei.com > > ------------------------------------------------------------------------ ---- > > --------------------------------------------------------- > > This e-mail and its attachments contain confidential information from > > HUAWEI, which > > is intended only for the person or entity whose address is listed above. Any > > use of the > > information contained herein in any way (including, but not limited to, > > total or partial > > disclosure, reproduction, or dissemination) by persons other than the > > intended > > recipient(s) is prohibited. If you receive this e-mail in error, please > > notify the sender by > > phone or email immediately and delete it! > > > > > -----Original Message----- > > > From: Einat Yellin (Lachover) [mailto:Einat@radvision.com] > > > Sent: Thursday, September 24, 2009 1:24 PM > > > To: zouzixuan; Ali C. Begen (abegen); fecframe@ietf.org > > > Cc: tme@multicasttech.com > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > Hi, > > > Backward compatibility is a major requirement for FEC framework, no > > > doubt. I believe that the discussion here is around whether a separate > > > flow for FEC mapping information is required. > > > > > > While following the discussion, I can relate to the reasons why not > > > having a separate flow as claimed by Ali: > > > a. This is a redundant flow since this information can be conveyed in > > > the FEC repair flow and in SDP even when protecting multiple RTP flows > > > (specifically you can see an example in > > > draft-galanos-fecframe-rtp-reedsolomon-mf-00). > > > b. This separate flow for mapping is also useful only for receivers that > > > support this draft, so the backward compatibility issue remains the same > > > as for the case where mapping is specified in the repair flow. > > > c. A separate flow increases the chance of losing packets. > > > > > > I must say that I don't understand the reasons for using a separate > > > flow. > > > Mr. Zou ZiXuan, is this meant for systems that do not use SDP? > > > > > > Best, > > > Einat > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > > > Behalf Of zouzixuan > > > Sent: Thursday, September 24, 2009 6:24 AM > > > To: 'Ali C. Begen (abegen)'; fecframe@ietf.org > > > Cc: tme@multicasttech.com > > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > Hi, Ali > > > It's a good suggestion that others join the discussion on this. > > > The > > > point here is that whether we need to take the backward compatibility > > > into > > > account in FEC Framework or not. We may not ignore a fact that the > > > diversity > > > of clients exists in practice. We didn't mean to make the idea we > > > proposed > > > to be something depart from the framework. We just hope to complement > > > the > > > framework so that it can be practically more adaptable. > > > > > > Best regards, > > > Zou ZiXuan, Senior Research Staff > > > Media & Communication Lab > > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > > > Address: Huawei Industrial Base > > > Bantian Longgang > > > Shenzhen 518129, P.R.China > > > Tel: +86 0755 28789364 > > > Fax: +86 0755 28788317 > > > E-mail: tendyntu@huawei.com > > > www.huawei.com > > > ------------------------------------------------------------------------ > > > ---- > > > --------------------------------------------------------- > > > This e-mail and its attachments contain confidential information from > > > HUAWEI, which > > > is intended only for the person or entity whose address is listed above. > > > Any > > > use of the > > > information contained herein in any way (including, but not limited to, > > > total or partial > > > disclosure, reproduction, or dissemination) by persons other than the > > > intended > > > recipient(s) is prohibited. If you receive this e-mail in error, please > > > notify the sender by > > > phone or email immediately and delete it! > > > > > > > > > > -----Original Message----- > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > Sent: Thursday, September 24, 2009 12:09 AM > > > > To: zouzixuan; fecframe@ietf.org > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > There are multiple things here used as an excuse to depart from the > > > convention > > > > used in the framework. > > > > > > > > The main goal here seems to provide the non-framework capable RTP > > > > applications a way of using the nice features of the framework. In > > > this > > > example, > > > > "a nice feature" stands for the protection of multiple RTP streams > > > together. I > > > > will let others comment on this, too, but personally, I am not sure > > > whether we > > > > should be doing this. On one hand, we want the nice features, but at > > > the > > > same > > > > time we don't wanna support the framework, and the excuse is the > > > backward > > > > compatibility in environments with both framework-capable and > > > incapable > > > RTP > > > > receivers. In addition, using an additional flow may increase the > > > chances > > > of > > > > failure since if source fec payload id's are lost, receiver will be > > > clueless. This > > > > deserves a consensus from the WG, probably from AVT, too. > > > > > > > > Furthermore, I believe two RTP streams can be still protected together > > > w/o > > > any > > > > additional source fec payload id's (You asked for an example, and I > > > will > > > try to > > > > explain in simple words). If certain features of the RTP streams are > > > known > > > > (which is usually the case), by using a systematic approach (not in > > > the > > > sense of > > > > systematic FEC), things can probably be worked out. In your example, I > > > believe > > > > in each source block you wanna do a different order of the source > > > packets > > > and > > > > flows, so things are quite unpredictable. E.g., packet 16 and 17 are > > > before > > > > packet 15 of the same flow, packet 19 is before packet 8 of the other > > > flow, and > > > > packets belonging to flows 0 and 1 are dispersed, any particular > > > reason? > > > > > > > > But, if you follow a systematic approach, your CDP can convey the > > > mapping > > > out > > > > of band, and decoding will know what to expect and how to decode. > > > Remember > > > > that there will be constraints on which RTP streams you can combine > > > prior > > > to > > > > FEC encoding (this was brought up in the last meeting). > > > > > > > > If all the RTP streams belong to the same RTP session, their SSRC's > > > will > > > be > > > > different, so SSRC+seqnum should uniquely identify each source packet. > > > But, > > > > this would not work if the RTP streams would be from different > > > sessions. > > > In > > > > that case, they could share same SSRC's, and I can see the > > > complications. > > > > > > > > Cheers, acbegen. > > > > > > > > > > > > From: zouzixuan [mailto:tendyntu@huawei.com] > > > > Sent: Wednesday, September 23, 2009 4:28 AM > > > > To: Ali C. Begen (abegen); fecframe@ietf.org > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > > > > > > > First question, are you suggesting to apply FEC to the combination > > > of a > > > video > > > > > and audio RTP stream? > > > > > > > > > Second question, assuming the above case is true, I am still not > > > sure > > > why you > > > > > need an additional flow carrying the source payload ids. Is it > > > because > > > there > > > > are > > > > > two streams? Could you explain? > > > > > > > > It's not this case that just result in the need of carrying source > > > play id > > > in > > > > additional flow. It is this case to prove the need of source payload > > > id > > > for RTP > > > > flow. Because you need a source payload id, you gotta transfer it to > > > the > > > client, > > > > either in source packet as current FEC framework specified, or in an > > > additional > > > > flow described in our draft. The latter choice for transferring the > > > source > > > > payload is for making source packet accessible to non-fecframework > > > clients. > > > > > > > > This table shows an example of multiple flows. The table depicts the > > > structure > > > > of a source block, which is filled up with the packets (of length 16, > > > 17 > > > 19 15 and > > > > 8 bytes) from two sequenced flows. The packets from two flows are > > > identified > > > > by flow id 0 and 1, respectively. For FEC decoding, the receiver needs > > > to > > > know > > > > the position of each packet in the source block. The sequence number > > > can > > > only > > > > tell the order of a packet in the flow it belongs to in the source > > > block. > > > There is > > > > no way to tell where a packet exactly is in the source block. Source > > > Payload ID is > > > > thus in this case needed. Would you please give a solution which is > > > free > > > of > > > > source payload id? > > > > > > > > 0 > > > > 16 > > > > B0,0 > > > > B0,1 > > > > B0,2 > > > > B0,3 > > > > B0,4 > > > > B0,5 > > > > B0,6 > > > > B0,7 > > > > B0,8 > > > > B0,9 > > > > B0,10 > > > > B0,11 > > > > B0,12 > > > > B0,13 > > > > B0,14 > > > > B0,15 > > > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 17 > > > > B1,0 > > > > B1,1 > > > > B1,2 > > > > B1,3 > > > > B1,4 > > > > B1,5 > > > > B1,6 > > > > B1,7 > > > > B1,8 > > > > B1,9 > > > > B1,10 > > > > B1,11 > > > > B1,12 > > > > B1,13 > > > > B1,14 > > > > B1,15 > > > > B1,16 > > > > 0 > > > > 0 > > > > 1 > > > > 19 > > > > B2,0 > > > > B2,1 > > > > B2,2 > > > > B2,3 > > > > B2,4 > > > > B2,5 > > > > B2,6 > > > > B2,7 > > > > B2,8 > > > > B2,9 > > > > B2,10 > > > > B2,11 > > > > B2,12 > > > > B2,13 > > > > B2,14 > > > > B2,15 > > > > B2,16 > > > > B2,17 > > > > B2,18 > > > > 0 > > > > 15 > > > > B3,0 > > > > B3,1 > > > > B3,2 > > > > B3,3 > > > > B3,4 > > > > B3,5 > > > > B3,6 > > > > B3,7 > > > > B3,8 > > > > B3,9 > > > > B3,10 > > > > B3,11 > > > > B3,12 > > > > B3,13 > > > > B3,14 > > > > 0 > > > > 0 > > > > 0 > > > > 0 > > > > 1 > > > > 8 > > > > B4,0 > > > > B4,1 > > > > B4,2 > > > > B4,3 > > > > B4,4 > > > > B4,5 > > > > B4,6 > > > > B4,7 > > > > > > > > > > > > Hope this is clear. > > > > > > > > Zou ZiXuan, Senior Research Staff > > > > Media & Communication Lab > > > > HUAWEI TECHNOLOGIES CO.,LTD. > > > > > > > > Address: Huawei Industrial Base > > > > Bantian Longgang > > > > Shenzhen 518129, P.R.China > > > > Tel: +86 0755 28789364 > > > > Fax: +86 0755 28788317 > > > > E-mail: tendyntu@huawei.com > > > > www.huawei.com > > > > > > > ------------------------------------------------------------------------ > > > ---- > > > ------------------------------------ > > > > --------------------- > > > > This e-mail and its attachments contain confidential information from > > > HUAWEI, > > > > which > > > > is intended only for the person or entity whose address is listed > > > above. > > > Any use > > > > of the > > > > information contained herein in any way (including, but not limited > > > to, > > > total or > > > > partial > > > > disclosure, reproduction, or dissemination) by persons other than the > > > intended > > > > recipient(s) is prohibited. If you receive this e-mail in error, > > > please > > > notify the > > > > sender by > > > > phone or email immediately and delete it! > > > > > > > > > > > > > -----Original Message----- > > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > > > Sent: Wednesday, September 23, 2009 11:29 AM > > > > > To: zouzixuan; fecframe@ietf.org > > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > > > > > > > > > First question, are you suggesting to apply FEC to the combination > > > of a > > > video > > > > > and audio RTP stream? > > > > > > > > > > Second question, assuming the above case is true, I am still not > > > sure > > > why you > > > > > need an additional flow carrying the source payload ids. Is it > > > because > > > there > > > > are > > > > > two streams? Could you explain? > > > > > > > > > > Cheers, acbegen. > > > > > > _______________________________________________ > > > 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