From csp@csperkins.org Fri May 1 02:26:41 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 83B833A684A; Fri, 1 May 2009 02:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 xZvZjf9C1Qki; Fri, 1 May 2009 02:26:40 -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 CF24C28C167; Fri, 1 May 2009 02:26:01 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Lzp1h-0001CY-Wo; Fri, 01 May 2009 09:27:25 +0000 Message-Id: <8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> From: Colin Perkins To: Roni Even In-Reply-To: <49fa9d9c.0305560a.5885.7b1f@mx.google.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 10:27:24 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> <49fa0498.0405560a.615f.677e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> <49fa9d9c.0305560a.5885.7b1f@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 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, 01 May 2009 09:26:41 -0000 On 1 May 2009, at 07:56, Roni Even wrote: > Hi Ali, > This is up to the WG to decide if they want to have support for SSRC > multiplexing and the implications of this support. I am not sure > what you mean by "we cannot have a parameter", I see only your view > on the list. The grouping mechanism would seem to be sufficient. Why do we need a special-purpose mechanism, when we can reuse a general approach? Colin > If only session multiplexing is allowed then the draft should > clearly state it and in this case I am not sure why you are > registering the video, audio and text media subtypes. > > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, May 01, 2009 2:45 AM > To: Roni Even; vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- > ietf-fecframe-interleaved-fec-scheme-04 > > Hi Roni, > > Thanks for the references. However, we cannot have a parameter that > will relate the FEC stream to the source as RFC 4588 did with "apt" > since a lot of possibilities (multiple sources and/or multiple > repair flows) are possible with FEC. Instead, we use grouping and > this works just fine in session multiplexing. > > Regarding SSRC multiplexing of source and FEC streams, I don't think > giving an explicit example is needed or it is a good idea for this > draft since SSRC-level grouping is just introduced in 4756bis and it > will include such examples anyway (actually the version I submitted > today includes an example). We should better only provide session > multiplexing examples in this draft. This also emphasizes the > recommended way of doing FEC. > > Reg the registration of the media types and SDP mappings, I believe > the draft has the necessary details. > > BR, > -acbegen > >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: Thursday, April 30, 2009 1:03 PM >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr >> Cc: avt@ietf.org; fecframe@ietf.org >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification >> for draft-ietf-fecframe-interleaved-fec-scheme-04 >> >> Ali, >> You can find examples in section 8.6 to 8.8 of RFC 4588, >> notice that there is an optional parameter for the rtx stream >> that defines the relation between the original and the rtx >> stream. Similar solution is also specified for redundant >> encoding red payload type (RFC 2198). You are offering both >> streams with different payload type numbers in the same m-line. >> In this case the media type must be video or audio same as >> the media type of the protected stream. This is why you >> needed the registration for type audio and video >> >> Roni >> >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: Thursday, April 30, 2009 10:01 PM >> To: Roni Even; vincent.roca@inrialpes.fr >> Cc: avt@ietf.org; fecframe@ietf.org >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification >> for draft-ietf-fecframe-interleaved-fec-scheme-04 >> >> Hi Roni, >> >>> I noticed that the fec framework will allow SSRC >> >> Yes, it will not be the recommended way of using FEC, but it >> will be supported. The 4756bis draft also supports it now. >> >>> multiplexing, are you going to specify this in this draft in >>> the SDP offer answer section. >> >> I am not sure what I need to specify additionally in this >> section regarding SSRC multiplexing. Could you let me know if >> there is such an example? >> >>> Maybe you should also discuss when to use application media >>> type and when to use video or audio >> >> I believe the FEC is always application type, we did >> registration for video, audio, etc. since FEC could relate to >> sessions carrying such types. >> >> BR, >> -acbegen >> >>> >>> >>> Roni >>> >>> >>> >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>> Behalf Of Ali C. Begen (abegen) >>> Sent: Thursday, April 30, 2009 3:54 PM >>> To: vincent.roca@inrialpes.fr >>> Cc: avt@ietf.org; fecframe@ietf.org >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 >>> >>> >>> >>> Hi Vincent >>> >>> This draft is not an fec scheme so it is not related to fec >>> framework. It is an rtp payload format draft. The wglc has >>> been running almost a month now. If you have comments in this >>> perspective, pls submit them soon. >>> >>> >>> >>> >>> -acbegen >>> >>> ----- Original Message ----- >>> From: Vincent Roca >>> To: Ali C. Begen (abegen) >>> Cc: fecframe@ietf.org ; avt@ietf.org >> >>> Sent: Thu Apr 30 03:58:35 2009 >>> Subject: Re: [Fecframe] FW: New Version Notification for >>> draft-ietf-fecframe-interleaved-fec-scheme-04 >>> >>> Hello Ali, >>> >>> I'm not in favor of finalizing the WGLC for this document. >>> IMHO we must, >>> first of all, finalize the framework document itself. >>> >>> For instance, the terminology used by the interleaved-fec-scheme I-D >>> (section 3.1.) is not in line with the terminology used by the >>> fecframe-framework-03 I-D (Section 2): >>> "Source Flow" vs. "Source data flow" >>> "Repair Flow" vs. "Repair data flow" >>> "Source Symbol" vs. nothing >>> "Repair Symbol" vs. nothing >>> "Source Packet" vs. nothing >>> "Repair Packet" vs. nothing >>> And as I said before, IMHO the terminology proposed in the framework >>> I-D should be discussed too. >>> >>> So let's do things in the right order, especially as the framework >>> WGLC finishes soon. >>> >>> Additionally, I may have some comments for the >>> interleaved-fec-scheme-04 >>> I-D. Since I missed the WGLC deadline, you have the right to >>> blame me ;-) >>> and I apologize in advance. >>> >>> Regards, >>> >>> Vincent >>> >>> >>> Ali C. Begen (abegen) wrote: >>>> This version addresses the comments received from fecframe >>> and avt so far. >>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl >> eaved-fec-scheme-04.txt >>>> >>>> >>>> Fecframe chairs, >>>> >>>> Could we proceed and finalize WGLC? >>>> >>>> -acbegen >>>> >>>> >>>> -----Original Message----- >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>>> Sent: Wednesday, April 29, 2009 2:56 PM >>>> To: Ali C. Begen (abegen) >>>> Subject: New Version Notification for >>> draft-ietf-fecframe-interleaved-fec-scheme-04 >>>> >>>> >>>> A new version of I-D, >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been >>> successfuly submitted by Ali Begen and posted to the IETF >> repository. >>>> >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme >>>> Revision: 04 >>>> Title: RTP Payload Format for 1-D >>> Interleaved Parity FEC >>>> Creation_date: 2009-04-29 >>>> WG ID: fecframe >>>> Number_of_pages: 31 >>>> >>>> Abstract: >>>> This document defines a new RTP payload format for the >> Forward Error >>>> Correction (FEC) that is generated by the 1-D interleaved >>> parity code >>>> from a source media encapsulated in RTP. The 1-D >> interleaved parity >>>> code is a systematic code, where a number of repair symbols are >>>> generated from a set of source symbols and sent in a repair flow >>>> separate from the source flow that carries the source >> symbols. The >>>> 1-D interleaved parity code offers a good protection >> against bursty >>>> packet losses at a cost of decent complexity. The new >>> payload format >>>> defined in this document is used (with some exceptions) >> as a part of >>>> the DVB Application-layer FEC specification. >>>> >>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>> >>> >> >> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From ron.even.tlv@gmail.com Fri May 1 03:23: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 A4A5B3A6D78; Fri, 1 May 2009 03:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416, 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 d5ZM3+JSU23q; Fri, 1 May 2009 03:23:04 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 707513A6C4E; Fri, 1 May 2009 03:23:03 -0700 (PDT) Received: by fxm2 with SMTP id 2so2260882fxm.37 for ; Fri, 01 May 2009 03:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Gzdnw3DdSyydl/WJn3EFuJKqVUVskiZPpSk7lWLZcow=; b=VpmPg8rLzmThtXqCYrpJ7Yv/rws1pa4fIZhMt/PqQkGGd4voZEfFVILLiWB9yAD8c6 SUgpW/6Be1aKuOIwHHJS23qDEhuKAgDxD7T/hYT9P7SqXKyRXMoGQ6oNrEuZDdrUYLxA hEmI+IW7KGodTdItrbOvDfm3GqRhDlYNDt+1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=X/EMO0Q/UvUxOhEVAk8Wdh4yD+lzl+Q/w783s+nKPcCypustEyTVj/ieD9t+8D4ecG swPjVbJ5rWf7D3ODhWDHjMtTHI4Q3KqqFSmqZTVumvk2bRhdKLZ7472yyj7T47WHiXw3 RgNfclhhcleyhydHql71CORFMTVzqx6IRq93c= Received: by 10.86.86.10 with SMTP id j10mr2771498fgb.37.1241173466324; Fri, 01 May 2009 03:24:26 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id l19sm550988fgb.17.2009.05.01.03.24.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 03:24:25 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49f9ea83.0637560a.4488.62d2@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com> <49fa0498.0405560a.615f.677e@mx.google.com> <04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com> <49fa9d9c.0305560a.5885.7b1f@mx.google.com> <8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> In-Reply-To: <8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> Date: Fri, 1 May 2009 13:22:18 +0300 Message-ID: <49facdd9.1358560a.4af5.fffff1ed@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKPwmfVmenxPpkQq6VFXZFKfLSIgABp6gw Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 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, 01 May 2009 10:23:05 -0000 Colin, I am not sure that grouping will work when you have SSRC multiplexing and both the protected stream and the fec stream are in the same m-line, the mid attribute is per m-line Roni -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Friday, May 01, 2009 12:27 PM To: Roni Even Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; fecframe@ietf.org Subject: Re: [AVT] [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 On 1 May 2009, at 07:56, Roni Even wrote: > Hi Ali, > This is up to the WG to decide if they want to have support for SSRC > multiplexing and the implications of this support. I am not sure > what you mean by "we cannot have a parameter", I see only your view > on the list. The grouping mechanism would seem to be sufficient. Why do we need a special-purpose mechanism, when we can reuse a general approach? Colin > If only session multiplexing is allowed then the draft should > clearly state it and in this case I am not sure why you are > registering the video, audio and text media subtypes. > > Roni > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Friday, May 01, 2009 2:45 AM > To: Roni Even; vincent.roca@inrialpes.fr > Cc: avt@ietf.org; fecframe@ietf.org > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- > ietf-fecframe-interleaved-fec-scheme-04 > > Hi Roni, > > Thanks for the references. However, we cannot have a parameter that > will relate the FEC stream to the source as RFC 4588 did with "apt" > since a lot of possibilities (multiple sources and/or multiple > repair flows) are possible with FEC. Instead, we use grouping and > this works just fine in session multiplexing. > > Regarding SSRC multiplexing of source and FEC streams, I don't think > giving an explicit example is needed or it is a good idea for this > draft since SSRC-level grouping is just introduced in 4756bis and it > will include such examples anyway (actually the version I submitted > today includes an example). We should better only provide session > multiplexing examples in this draft. This also emphasizes the > recommended way of doing FEC. > > Reg the registration of the media types and SDP mappings, I believe > the draft has the necessary details. > > BR, > -acbegen > >> -----Original Message----- >> From: Roni Even [mailto:ron.even.tlv@gmail.com] >> Sent: Thursday, April 30, 2009 1:03 PM >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr >> Cc: avt@ietf.org; fecframe@ietf.org >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification >> for draft-ietf-fecframe-interleaved-fec-scheme-04 >> >> Ali, >> You can find examples in section 8.6 to 8.8 of RFC 4588, >> notice that there is an optional parameter for the rtx stream >> that defines the relation between the original and the rtx >> stream. Similar solution is also specified for redundant >> encoding red payload type (RFC 2198). You are offering both >> streams with different payload type numbers in the same m-line. >> In this case the media type must be video or audio same as >> the media type of the protected stream. This is why you >> needed the registration for type audio and video >> >> Roni >> >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: Thursday, April 30, 2009 10:01 PM >> To: Roni Even; vincent.roca@inrialpes.fr >> Cc: avt@ietf.org; fecframe@ietf.org >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification >> for draft-ietf-fecframe-interleaved-fec-scheme-04 >> >> Hi Roni, >> >>> I noticed that the fec framework will allow SSRC >> >> Yes, it will not be the recommended way of using FEC, but it >> will be supported. The 4756bis draft also supports it now. >> >>> multiplexing, are you going to specify this in this draft in >>> the SDP offer answer section. >> >> I am not sure what I need to specify additionally in this >> section regarding SSRC multiplexing. Could you let me know if >> there is such an example? >> >>> Maybe you should also discuss when to use application media >>> type and when to use video or audio >> >> I believe the FEC is always application type, we did >> registration for video, audio, etc. since FEC could relate to >> sessions carrying such types. >> >> BR, >> -acbegen >> >>> >>> >>> Roni >>> >>> >>> >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On >>> Behalf Of Ali C. Begen (abegen) >>> Sent: Thursday, April 30, 2009 3:54 PM >>> To: vincent.roca@inrialpes.fr >>> Cc: avt@ietf.org; fecframe@ietf.org >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 >>> >>> >>> >>> Hi Vincent >>> >>> This draft is not an fec scheme so it is not related to fec >>> framework. It is an rtp payload format draft. The wglc has >>> been running almost a month now. If you have comments in this >>> perspective, pls submit them soon. >>> >>> >>> >>> >>> -acbegen >>> >>> ----- Original Message ----- >>> From: Vincent Roca >>> To: Ali C. Begen (abegen) >>> Cc: fecframe@ietf.org ; avt@ietf.org >> >>> Sent: Thu Apr 30 03:58:35 2009 >>> Subject: Re: [Fecframe] FW: New Version Notification for >>> draft-ietf-fecframe-interleaved-fec-scheme-04 >>> >>> Hello Ali, >>> >>> I'm not in favor of finalizing the WGLC for this document. >>> IMHO we must, >>> first of all, finalize the framework document itself. >>> >>> For instance, the terminology used by the interleaved-fec-scheme I-D >>> (section 3.1.) is not in line with the terminology used by the >>> fecframe-framework-03 I-D (Section 2): >>> "Source Flow" vs. "Source data flow" >>> "Repair Flow" vs. "Repair data flow" >>> "Source Symbol" vs. nothing >>> "Repair Symbol" vs. nothing >>> "Source Packet" vs. nothing >>> "Repair Packet" vs. nothing >>> And as I said before, IMHO the terminology proposed in the framework >>> I-D should be discussed too. >>> >>> So let's do things in the right order, especially as the framework >>> WGLC finishes soon. >>> >>> Additionally, I may have some comments for the >>> interleaved-fec-scheme-04 >>> I-D. Since I missed the WGLC deadline, you have the right to >>> blame me ;-) >>> and I apologize in advance. >>> >>> Regards, >>> >>> Vincent >>> >>> >>> Ali C. Begen (abegen) wrote: >>>> This version addresses the comments received from fecframe >>> and avt so far. >>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl >> eaved-fec-scheme-04.txt >>>> >>>> >>>> Fecframe chairs, >>>> >>>> Could we proceed and finalize WGLC? >>>> >>>> -acbegen >>>> >>>> >>>> -----Original Message----- >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>>> Sent: Wednesday, April 29, 2009 2:56 PM >>>> To: Ali C. Begen (abegen) >>>> Subject: New Version Notification for >>> draft-ietf-fecframe-interleaved-fec-scheme-04 >>>> >>>> >>>> A new version of I-D, >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been >>> successfuly submitted by Ali Begen and posted to the IETF >> repository. >>>> >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme >>>> Revision: 04 >>>> Title: RTP Payload Format for 1-D >>> Interleaved Parity FEC >>>> Creation_date: 2009-04-29 >>>> WG ID: fecframe >>>> Number_of_pages: 31 >>>> >>>> Abstract: >>>> This document defines a new RTP payload format for the >> Forward Error >>>> Correction (FEC) that is generated by the 1-D interleaved >>> parity code >>>> from a source media encapsulated in RTP. The 1-D >> interleaved parity >>>> code is a systematic code, where a number of repair symbols are >>>> generated from a set of source symbols and sent in a repair flow >>>> separate from the source flow that carries the source >> symbols. The >>>> 1-D interleaved parity code offers a good protection >> against bursty >>>> packet losses at a cost of decent complexity. The new >>> payload format >>>> defined in this document is used (with some exceptions) >> as a part of >>>> the DVB Application-layer FEC specification. >>>> >>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>> >>> >> >> > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From jonathan@vidyo.com Fri May 1 08:39:06 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 7C20828C22D; Fri, 1 May 2009 08:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 CE+aDClqwkpR; Fri, 1 May 2009 08:39:04 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id B31E73A7092; Fri, 1 May 2009 08:36:48 -0700 (PDT) Received: from be150.mail.lan ([10.110.20.150]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 11:38:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 11:38:07 -0400 Message-ID: <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> In-Reply-To: <49facdd9.1358560a.4af5.fffff1ed@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [Fecframe] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnKPwmfVmenxPpkQq6VFXZFKfLSIgABp6gwAAtB7mA= References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com><49f9ea83.0637560a.4488.62d2@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com><49fa0498.0405560a.615f.677e@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com><49fa9d9c.0305560a.5885.7b1f@mx.google.com><8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> <49facdd9.1358560a.4af5.fffff1ed@mx.google.com> From: "Jonathan Lennox" To: "Roni Even" , "Colin Perkins" X-OriginalArrivalTime: 01 May 2009 15:38:12.0514 (UTC) FILETIME=[D62D3820:01C9CA72] Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 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, 01 May 2009 15:39:06 -0000 The intention is to use ssrc-group (from draft-ietf-mmusic-source-attributes) for ssrc grouping. --=20 Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, May 01, 2009 6:22 AM > To: 'Colin Perkins' > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft- > ietf-fecframe-interleaved-fec-scheme-04 >=20 > Colin, > I am not sure that grouping will work when you have SSRC multiplexing > and > both the protected stream and the fec stream are in the same m-line, > the mid > attribute is per m-line >=20 >=20 > Roni >=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, May 01, 2009 12:27 PM > To: Roni Even > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > On 1 May 2009, at 07:56, Roni Even wrote: > > Hi Ali, > > This is up to the WG to decide if they want to have support for SSRC > > multiplexing and the implications of this support. I am not sure > > what you mean by "we cannot have a parameter", I see only your view > > on the list. >=20 > The grouping mechanism would seem to be sufficient. Why do we need a > special-purpose mechanism, when we can reuse a general approach? >=20 > Colin >=20 >=20 >=20 >=20 > > If only session multiplexing is allowed then the draft should > > clearly state it and in this case I am not sure why you are > > registering the video, audio and text media subtypes. > > > > Roni > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, May 01, 2009 2:45 AM > > To: Roni Even; vincent.roca@inrialpes.fr > > Cc: avt@ietf.org; fecframe@ietf.org > > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- > > ietf-fecframe-interleaved-fec-scheme-04 > > > > Hi Roni, > > > > Thanks for the references. However, we cannot have a parameter that > > will relate the FEC stream to the source as RFC 4588 did with "apt" > > since a lot of possibilities (multiple sources and/or multiple > > repair flows) are possible with FEC. Instead, we use grouping and > > this works just fine in session multiplexing. > > > > Regarding SSRC multiplexing of source and FEC streams, I don't think > > giving an explicit example is needed or it is a good idea for this > > draft since SSRC-level grouping is just introduced in 4756bis and it > > will include such examples anyway (actually the version I submitted > > today includes an example). We should better only provide session > > multiplexing examples in this draft. This also emphasizes the > > recommended way of doing FEC. > > > > Reg the registration of the media types and SDP mappings, I believe > > the draft has the necessary details. > > > > BR, > > -acbegen > > > >> -----Original Message----- > >> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >> Sent: Thursday, April 30, 2009 1:03 PM > >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr > >> Cc: avt@ietf.org; fecframe@ietf.org > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >> > >> Ali, > >> You can find examples in section 8.6 to 8.8 of RFC 4588, > >> notice that there is an optional parameter for the rtx stream > >> that defines the relation between the original and the rtx > >> stream. Similar solution is also specified for redundant > >> encoding red payload type (RFC 2198). You are offering both > >> streams with different payload type numbers in the same m-line. > >> In this case the media type must be video or audio same as > >> the media type of the protected stream. This is why you > >> needed the registration for type audio and video > >> > >> Roni > >> > >> -----Original Message----- > >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > >> Sent: Thursday, April 30, 2009 10:01 PM > >> To: Roni Even; vincent.roca@inrialpes.fr > >> Cc: avt@ietf.org; fecframe@ietf.org > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >> > >> Hi Roni, > >> > >>> I noticed that the fec framework will allow SSRC > >> > >> Yes, it will not be the recommended way of using FEC, but it > >> will be supported. The 4756bis draft also supports it now. > >> > >>> multiplexing, are you going to specify this in this draft in > >>> the SDP offer answer section. > >> > >> I am not sure what I need to specify additionally in this > >> section regarding SSRC multiplexing. Could you let me know if > >> there is such an example? > >> > >>> Maybe you should also discuss when to use application media > >>> type and when to use video or audio > >> > >> I believe the FEC is always application type, we did > >> registration for video, audio, etc. since FEC could relate to > >> sessions carrying such types. > >> > >> BR, > >> -acbegen > >> > >>> > >>> > >>> Roni > >>> > >>> > >>> > >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > >>> Behalf Of Ali C. Begen (abegen) > >>> Sent: Thursday, April 30, 2009 3:54 PM > >>> To: vincent.roca@inrialpes.fr > >>> Cc: avt@ietf.org; fecframe@ietf.org > >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification > >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >>> > >>> > >>> > >>> Hi Vincent > >>> > >>> This draft is not an fec scheme so it is not related to fec > >>> framework. It is an rtp payload format draft. The wglc has > >>> been running almost a month now. If you have comments in this > >>> perspective, pls submit them soon. > >>> > >>> > >>> > >>> > >>> -acbegen > >>> > >>> ----- Original Message ----- > >>> From: Vincent Roca > >>> To: Ali C. Begen (abegen) > >>> Cc: fecframe@ietf.org ; avt@ietf.org > >> > >>> Sent: Thu Apr 30 03:58:35 2009 > >>> Subject: Re: [Fecframe] FW: New Version Notification for > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > >>> > >>> Hello Ali, > >>> > >>> I'm not in favor of finalizing the WGLC for this document. > >>> IMHO we must, > >>> first of all, finalize the framework document itself. > >>> > >>> For instance, the terminology used by the interleaved-fec-scheme I- > D > >>> (section 3.1.) is not in line with the terminology used by the > >>> fecframe-framework-03 I-D (Section 2): > >>> "Source Flow" vs. "Source data flow" > >>> "Repair Flow" vs. "Repair data flow" > >>> "Source Symbol" vs. nothing > >>> "Repair Symbol" vs. nothing > >>> "Source Packet" vs. nothing > >>> "Repair Packet" vs. nothing > >>> And as I said before, IMHO the terminology proposed in the > framework > >>> I-D should be discussed too. > >>> > >>> So let's do things in the right order, especially as the framework > >>> WGLC finishes soon. > >>> > >>> Additionally, I may have some comments for the > >>> interleaved-fec-scheme-04 > >>> I-D. Since I missed the WGLC deadline, you have the right to > >>> blame me ;-) > >>> and I apologize in advance. > >>> > >>> Regards, > >>> > >>> Vincent > >>> > >>> > >>> Ali C. Begen (abegen) wrote: > >>>> This version addresses the comments received from fecframe > >>> and avt so far. > >>>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl > >> eaved-fec-scheme-04.txt > >>>> > >>>> > >>>> Fecframe chairs, > >>>> > >>>> Could we proceed and finalize WGLC? > >>>> > >>>> -acbegen > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >>>> Sent: Wednesday, April 29, 2009 2:56 PM > >>>> To: Ali C. Begen (abegen) > >>>> Subject: New Version Notification for > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > >>>> > >>>> > >>>> A new version of I-D, > >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been > >>> successfuly submitted by Ali Begen and posted to the IETF > >> repository. > >>>> > >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme > >>>> Revision: 04 > >>>> Title: RTP Payload Format for 1-D > >>> Interleaved Parity FEC > >>>> Creation_date: 2009-04-29 > >>>> WG ID: fecframe > >>>> Number_of_pages: 31 > >>>> > >>>> Abstract: > >>>> This document defines a new RTP payload format for the > >> Forward Error > >>>> Correction (FEC) that is generated by the 1-D interleaved > >>> parity code > >>>> from a source media encapsulated in RTP. The 1-D > >> interleaved parity > >>>> code is a systematic code, where a number of repair symbols are > >>>> generated from a set of source symbols and sent in a repair flow > >>>> separate from the source flow that carries the source > >> symbols. The > >>>> 1-D interleaved parity code offers a good protection > >> against bursty > >>>> packet losses at a cost of decent complexity. The new > >>> payload format > >>>> defined in this document is used (with some exceptions) > >> as a part of > >>>> the DVB Application-layer FEC specification. > >>>> > >>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> > >>>> _______________________________________________ > >>>> Fecframe mailing list > >>>> Fecframe@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fecframe > >>> > >>> > >> > >> > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Fri May 1 09:04:15 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 601753A70F8; Fri, 1 May 2009 09:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WncsjtpUFde; Fri, 1 May 2009 09:04:13 -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 A78D23A70C6; Fri, 1 May 2009 09:04:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,279,1238976000"; d="scan'208";a="161009828" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 01 May 2009 16:05:37 +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 n41G5bi2001065; Fri, 1 May 2009 09:05:37 -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.13.8) with ESMTP id n41G5bwR008757; Fri, 1 May 2009 16:05:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 09:05:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 May 2009 09:05:11 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093494E3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] [AVT] FW: NewVersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnKPwmfVmenxPpkQq6VFXZFKfLSIgABp6gwAAtB7mAAAPAN4A== References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com><49f9ea83.0637560a.4488.62d2@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com><49fa0498.0405560a.615f.677e@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com><49fa9d9c.0305560a.5885.7b1f@mx.google.com><8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org><49facdd9.1358560a.4af5.fffff1ed@mx.google.com> <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> From: "Ali C. Begen (abegen)" To: "Jonathan Lennox" , "Roni Even" , "Colin Perkins" X-OriginalArrivalTime: 01 May 2009 16:05:37.0406 (UTC) FILETIME=[AA9BD1E0:01C9CA76] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11443; t=1241193937; x=1242057937; 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]=20[AVT]=20FW=3A=20NewVersion Notification=09for=09draft-ietf-fecframe-interleaved-fec-sch eme-04 |Sender:=20; bh=hIL3uqLFmyRfVD92lAyEfbAr9vizIfbadBYCCo+fcFo=; b=eGttK+uWFba41FA2evt7Ec1PlAEwj05v3Uiv7ir5GU9GMX6YdWNO8E0qw5 e1U29dNO3EOA0b9VxmKfrcb7mdAuIc/RnCLqlhzM5hJD5aTthv+SGue4v85X 1TwHSbU4bOgvlXWHsbibIlgOuTtLz+ZLLGi/4ST0+n7FajNyTgHUU=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: NewVersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 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, 01 May 2009 16:04:15 -0000 Yes, this has been discussed in mmusic very recently and I updated the = 4756bis draft accordingly. http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-02.txt -acbegen =20 > -----Original Message----- > From: fecframe-bounces@ietf.org=20 > [mailto:fecframe-bounces@ietf.org] On Behalf Of Jonathan Lennox > Sent: Friday, May 01, 2009 8:38 AM > To: Roni Even; Colin Perkins > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [Fecframe] [AVT] FW: NewVersionNotification for=20 > draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > The intention is to use ssrc-group (from > draft-ietf-mmusic-source-attributes) for ssrc grouping. >=20 > --=20 > Jonathan Lennox > Vidyo, Inc > jonathan@vidyo.com >=20 >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, May 01, 2009 6:22 AM > > To: 'Colin Perkins' > > Cc: avt@ietf.org; fecframe@ietf.org > > Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft- > > ietf-fecframe-interleaved-fec-scheme-04 > >=20 > > Colin, > > I am not sure that grouping will work when you have SSRC=20 > multiplexing > > and > > both the protected stream and the fec stream are in the same m-line, > > the mid > > attribute is per m-line > >=20 > >=20 > > Roni > >=20 > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: Friday, May 01, 2009 12:27 PM > > To: Roni Even > > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; fecframe@ietf.org > > Subject: Re: [AVT] [Fecframe] FW: New Version Notification for > > draft-ietf-fecframe-interleaved-fec-scheme-04 > >=20 > > On 1 May 2009, at 07:56, Roni Even wrote: > > > Hi Ali, > > > This is up to the WG to decide if they want to have=20 > support for SSRC > > > multiplexing and the implications of this support. I am not sure > > > what you mean by "we cannot have a parameter", I see only=20 > your view > > > on the list. > >=20 > > The grouping mechanism would seem to be sufficient. Why do we need a > > special-purpose mechanism, when we can reuse a general approach? > >=20 > > Colin > >=20 > >=20 > >=20 > >=20 > > > If only session multiplexing is allowed then the draft should > > > clearly state it and in this case I am not sure why you are > > > registering the video, audio and text media subtypes. > > > > > > Roni > > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Friday, May 01, 2009 2:45 AM > > > To: Roni Even; vincent.roca@inrialpes.fr > > > Cc: avt@ietf.org; fecframe@ietf.org > > > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for > draft- > > > ietf-fecframe-interleaved-fec-scheme-04 > > > > > > Hi Roni, > > > > > > Thanks for the references. However, we cannot have a=20 > parameter that > > > will relate the FEC stream to the source as RFC 4588 did=20 > with "apt" > > > since a lot of possibilities (multiple sources and/or multiple > > > repair flows) are possible with FEC. Instead, we use grouping and > > > this works just fine in session multiplexing. > > > > > > Regarding SSRC multiplexing of source and FEC streams, I=20 > don't think > > > giving an explicit example is needed or it is a good idea for this > > > draft since SSRC-level grouping is just introduced in=20 > 4756bis and it > > > will include such examples anyway (actually the version I=20 > submitted > > > today includes an example). We should better only provide session > > > multiplexing examples in this draft. This also emphasizes the > > > recommended way of doing FEC. > > > > > > Reg the registration of the media types and SDP mappings,=20 > I believe > > > the draft has the necessary details. > > > > > > BR, > > > -acbegen > > > > > >> -----Original Message----- > > >> From: Roni Even [mailto:ron.even.tlv@gmail.com] > > >> Sent: Thursday, April 30, 2009 1:03 PM > > >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr > > >> Cc: avt@ietf.org; fecframe@ietf.org > > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > > >> > > >> Ali, > > >> You can find examples in section 8.6 to 8.8 of RFC 4588, > > >> notice that there is an optional parameter for the rtx stream > > >> that defines the relation between the original and the rtx > > >> stream. Similar solution is also specified for redundant > > >> encoding red payload type (RFC 2198). You are offering both > > >> streams with different payload type numbers in the same m-line. > > >> In this case the media type must be video or audio same as > > >> the media type of the protected stream. This is why you > > >> needed the registration for type audio and video > > >> > > >> Roni > > >> > > >> -----Original Message----- > > >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > >> Sent: Thursday, April 30, 2009 10:01 PM > > >> To: Roni Even; vincent.roca@inrialpes.fr > > >> Cc: avt@ietf.org; fecframe@ietf.org > > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > > >> > > >> Hi Roni, > > >> > > >>> I noticed that the fec framework will allow SSRC > > >> > > >> Yes, it will not be the recommended way of using FEC, but it > > >> will be supported. The 4756bis draft also supports it now. > > >> > > >>> multiplexing, are you going to specify this in this draft in > > >>> the SDP offer answer section. > > >> > > >> I am not sure what I need to specify additionally in this > > >> section regarding SSRC multiplexing. Could you let me know if > > >> there is such an example? > > >> > > >>> Maybe you should also discuss when to use application media > > >>> type and when to use video or audio > > >> > > >> I believe the FEC is always application type, we did > > >> registration for video, audio, etc. since FEC could relate to > > >> sessions carrying such types. > > >> > > >> BR, > > >> -acbegen > > >> > > >>> > > >>> > > >>> Roni > > >>> > > >>> > > >>> > > >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > > >>> Behalf Of Ali C. Begen (abegen) > > >>> Sent: Thursday, April 30, 2009 3:54 PM > > >>> To: vincent.roca@inrialpes.fr > > >>> Cc: avt@ietf.org; fecframe@ietf.org > > >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification > > >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 > > >>> > > >>> > > >>> > > >>> Hi Vincent > > >>> > > >>> This draft is not an fec scheme so it is not related to fec > > >>> framework. It is an rtp payload format draft. The wglc has > > >>> been running almost a month now. If you have comments in this > > >>> perspective, pls submit them soon. > > >>> > > >>> > > >>> > > >>> > > >>> -acbegen > > >>> > > >>> ----- Original Message ----- > > >>> From: Vincent Roca > > >>> To: Ali C. Begen (abegen) > > >>> Cc: fecframe@ietf.org ; avt@ietf.org > > >> > > >>> Sent: Thu Apr 30 03:58:35 2009 > > >>> Subject: Re: [Fecframe] FW: New Version Notification for > > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > > >>> > > >>> Hello Ali, > > >>> > > >>> I'm not in favor of finalizing the WGLC for this document. > > >>> IMHO we must, > > >>> first of all, finalize the framework document itself. > > >>> > > >>> For instance, the terminology used by the interleaved-fec-scheme > I- > > D > > >>> (section 3.1.) is not in line with the terminology used by the > > >>> fecframe-framework-03 I-D (Section 2): > > >>> "Source Flow" vs. "Source data flow" > > >>> "Repair Flow" vs. "Repair data flow" > > >>> "Source Symbol" vs. nothing > > >>> "Repair Symbol" vs. nothing > > >>> "Source Packet" vs. nothing > > >>> "Repair Packet" vs. nothing > > >>> And as I said before, IMHO the terminology proposed in the > > framework > > >>> I-D should be discussed too. > > >>> > > >>> So let's do things in the right order, especially as=20 > the framework > > >>> WGLC finishes soon. > > >>> > > >>> Additionally, I may have some comments for the > > >>> interleaved-fec-scheme-04 > > >>> I-D. Since I missed the WGLC deadline, you have the right to > > >>> blame me ;-) > > >>> and I apologize in advance. > > >>> > > >>> Regards, > > >>> > > >>> Vincent > > >>> > > >>> > > >>> Ali C. Begen (abegen) wrote: > > >>>> This version addresses the comments received from fecframe > > >>> and avt so far. > > >>>> > > >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl > > >> eaved-fec-scheme-04.txt > > >>>> > > >>>> > > >>>> Fecframe chairs, > > >>>> > > >>>> Could we proceed and finalize WGLC? > > >>>> > > >>>> -acbegen > > >>>> > > >>>> > > >>>> -----Original Message----- > > >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > >>>> Sent: Wednesday, April 29, 2009 2:56 PM > > >>>> To: Ali C. Begen (abegen) > > >>>> Subject: New Version Notification for > > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > > >>>> > > >>>> > > >>>> A new version of I-D, > > >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been > > >>> successfuly submitted by Ali Begen and posted to the IETF > > >> repository. > > >>>> > > >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme > > >>>> Revision: 04 > > >>>> Title: RTP Payload Format for 1-D > > >>> Interleaved Parity FEC > > >>>> Creation_date: 2009-04-29 > > >>>> WG ID: fecframe > > >>>> Number_of_pages: 31 > > >>>> > > >>>> Abstract: > > >>>> This document defines a new RTP payload format for the > > >> Forward Error > > >>>> Correction (FEC) that is generated by the 1-D interleaved > > >>> parity code > > >>>> from a source media encapsulated in RTP. The 1-D > > >> interleaved parity > > >>>> code is a systematic code, where a number of repair symbols are > > >>>> generated from a set of source symbols and sent in a=20 > repair flow > > >>>> separate from the source flow that carries the source > > >> symbols. The > > >>>> 1-D interleaved parity code offers a good protection > > >> against bursty > > >>>> packet losses at a cost of decent complexity. The new > > >>> payload format > > >>>> defined in this document is used (with some exceptions) > > >> as a part of > > >>>> the DVB Application-layer FEC specification. > > >>>> > > >>> > > >>>> > > >>>> > > >>>> The IETF Secretariat. > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Fecframe mailing list > > >>>> Fecframe@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/fecframe > > >>> > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > >=20 > >=20 > >=20 > > -- > > Colin Perkins > > http://csperkins.org/ > >=20 > >=20 > >=20 > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From ron.even.tlv@gmail.com Fri May 1 11:08:17 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 75DC53A6B92; Fri, 1 May 2009 11:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 3ZbwJ7LhdeLJ; Fri, 1 May 2009 11:08:15 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 2F8513A69B2; Fri, 1 May 2009 11:08:15 -0700 (PDT) Received: by fxm2 with SMTP id 2so2437721fxm.37 for ; Fri, 01 May 2009 11:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=hxf6Gvj/LcltY0oJGVR/5dsKiBnECMD7cyC3KJ+/Atc=; b=o6zqRZFn5mQO0SxdXKO9C1jpkBfXgClCipO8v+JtC7kRMt7qw8XR7Ahki5one2lSpG BFx9Cx5Eid6yRNXkBx7BEH9Gxj0shC0LsZdmDT5OJiVRu/ErG/XEFa/7jQLpMM8cd4y+ gom4rv+M39s5ChQ4hU2c1BYWq0B8PpyPnsRxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=lYlYE58pGdfrdanxIS9ZOsdh4ergtGhxYlNjc89TDjD2mX7lVVWaREQd9LxaWge9Am hmE2V9Y+vjKfLnVyvIlHHVs+uZl1H7JkBfju16g29ho1kR9G7Np7DGwOBHsYXKRvuotz 30lVEX8XPhEoJZmZIpnqctMS9Z1jc8bm/BD3E= Received: by 10.103.108.18 with SMTP id k18mr1790263mum.40.1241201378201; Fri, 01 May 2009 11:09:38 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-57-219.red.bezeqint.net [79.177.57.219]) by mx.google.com with ESMTPS id j9sm8989816mue.21.2009.05.01.11.09.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 May 2009 11:09:37 -0700 (PDT) From: "Roni Even" To: "'Jonathan Lennox'" , "'Colin Perkins'" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com><49f9ea83.0637560a.4488.62d2@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934913F@xmb-sjc-215.amer.cisco.com><49fa0498.0405560a.615f.677e@mx.google.com><04CAD96D4C5A3D48B1919248A8FE0D540934937B@xmb-sjc-215.amer.cisco.com><49fa9d9c.0305560a.5885.7b1f@mx.google.com><8BEBE133-BC38-4001-8083-190782BF9949@csperkins.org> <49facdd9.1358560a.4af5.fffff1ed@mx.google.com> <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> In-Reply-To: <6B55710E7F51AD4B93F336052113B85F8C7C93@be150.mail.lan> Date: Fri, 1 May 2009 21:07:28 +0300 Message-ID: <49fb3ae1.09a1660a.55c1.4898@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnKPwmfVmenxPpkQq6VFXZFKfLSIgABp6gwAAtB7mAABSwIMA== Content-Language: en-us Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] [AVT] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 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, 01 May 2009 18:08:17 -0000 Jonathan, Thanks for the reference. I suggest that if ssrc multiplexing is allowed there should be some text referencing the mmusic-source-attribute draft and explaining the limitation comparing to the session multiplexing. Roni Even -----Original Message----- From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Friday, May 01, 2009 6:38 PM To: Roni Even; Colin Perkins Cc: avt@ietf.org; fecframe@ietf.org Subject: RE: [AVT] [Fecframe] FW: New VersionNotification for draft-ietf-fecframe-interleaved-fec-scheme-04 The intention is to use ssrc-group (from draft-ietf-mmusic-source-attributes) for ssrc grouping. -- Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, May 01, 2009 6:22 AM > To: 'Colin Perkins' > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New VersionNotification for draft- > ietf-fecframe-interleaved-fec-scheme-04 > > Colin, > I am not sure that grouping will work when you have SSRC multiplexing > and > both the protected stream and the fec stream are in the same m-line, > the mid > attribute is per m-line > > > Roni > > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, May 01, 2009 12:27 PM > To: Roni Even > Cc: 'Ali C. Begen (abegen)'; avt@ietf.org; fecframe@ietf.org > Subject: Re: [AVT] [Fecframe] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-04 > > On 1 May 2009, at 07:56, Roni Even wrote: > > Hi Ali, > > This is up to the WG to decide if they want to have support for SSRC > > multiplexing and the implications of this support. I am not sure > > what you mean by "we cannot have a parameter", I see only your view > > on the list. > > The grouping mechanism would seem to be sufficient. Why do we need a > special-purpose mechanism, when we can reuse a general approach? > > Colin > > > > > > If only session multiplexing is allowed then the draft should > > clearly state it and in this case I am not sure why you are > > registering the video, audio and text media subtypes. > > > > Roni > > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Friday, May 01, 2009 2:45 AM > > To: Roni Even; vincent.roca@inrialpes.fr > > Cc: avt@ietf.org; fecframe@ietf.org > > Subject: RE: [AVT] [Fecframe] FW: New Version Notification for draft- > > ietf-fecframe-interleaved-fec-scheme-04 > > > > Hi Roni, > > > > Thanks for the references. However, we cannot have a parameter that > > will relate the FEC stream to the source as RFC 4588 did with "apt" > > since a lot of possibilities (multiple sources and/or multiple > > repair flows) are possible with FEC. Instead, we use grouping and > > this works just fine in session multiplexing. > > > > Regarding SSRC multiplexing of source and FEC streams, I don't think > > giving an explicit example is needed or it is a good idea for this > > draft since SSRC-level grouping is just introduced in 4756bis and it > > will include such examples anyway (actually the version I submitted > > today includes an example). We should better only provide session > > multiplexing examples in this draft. This also emphasizes the > > recommended way of doing FEC. > > > > Reg the registration of the media types and SDP mappings, I believe > > the draft has the necessary details. > > > > BR, > > -acbegen > > > >> -----Original Message----- > >> From: Roni Even [mailto:ron.even.tlv@gmail.com] > >> Sent: Thursday, April 30, 2009 1:03 PM > >> To: Ali C. Begen (abegen); vincent.roca@inrialpes.fr > >> Cc: avt@ietf.org; fecframe@ietf.org > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >> > >> Ali, > >> You can find examples in section 8.6 to 8.8 of RFC 4588, > >> notice that there is an optional parameter for the rtx stream > >> that defines the relation between the original and the rtx > >> stream. Similar solution is also specified for redundant > >> encoding red payload type (RFC 2198). You are offering both > >> streams with different payload type numbers in the same m-line. > >> In this case the media type must be video or audio same as > >> the media type of the protected stream. This is why you > >> needed the registration for type audio and video > >> > >> Roni > >> > >> -----Original Message----- > >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > >> Sent: Thursday, April 30, 2009 10:01 PM > >> To: Roni Even; vincent.roca@inrialpes.fr > >> Cc: avt@ietf.org; fecframe@ietf.org > >> Subject: RE: [AVT] [Fecframe] FW: New Version Notification > >> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >> > >> Hi Roni, > >> > >>> I noticed that the fec framework will allow SSRC > >> > >> Yes, it will not be the recommended way of using FEC, but it > >> will be supported. The 4756bis draft also supports it now. > >> > >>> multiplexing, are you going to specify this in this draft in > >>> the SDP offer answer section. > >> > >> I am not sure what I need to specify additionally in this > >> section regarding SSRC multiplexing. Could you let me know if > >> there is such an example? > >> > >>> Maybe you should also discuss when to use application media > >>> type and when to use video or audio > >> > >> I believe the FEC is always application type, we did > >> registration for video, audio, etc. since FEC could relate to > >> sessions carrying such types. > >> > >> BR, > >> -acbegen > >> > >>> > >>> > >>> Roni > >>> > >>> > >>> > >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On > >>> Behalf Of Ali C. Begen (abegen) > >>> Sent: Thursday, April 30, 2009 3:54 PM > >>> To: vincent.roca@inrialpes.fr > >>> Cc: avt@ietf.org; fecframe@ietf.org > >>> Subject: Re: [AVT] [Fecframe] FW: New Version Notification > >>> for draft-ietf-fecframe-interleaved-fec-scheme-04 > >>> > >>> > >>> > >>> Hi Vincent > >>> > >>> This draft is not an fec scheme so it is not related to fec > >>> framework. It is an rtp payload format draft. The wglc has > >>> been running almost a month now. If you have comments in this > >>> perspective, pls submit them soon. > >>> > >>> > >>> > >>> > >>> -acbegen > >>> > >>> ----- Original Message ----- > >>> From: Vincent Roca > >>> To: Ali C. Begen (abegen) > >>> Cc: fecframe@ietf.org ; avt@ietf.org > >> > >>> Sent: Thu Apr 30 03:58:35 2009 > >>> Subject: Re: [Fecframe] FW: New Version Notification for > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > >>> > >>> Hello Ali, > >>> > >>> I'm not in favor of finalizing the WGLC for this document. > >>> IMHO we must, > >>> first of all, finalize the framework document itself. > >>> > >>> For instance, the terminology used by the interleaved-fec-scheme I- > D > >>> (section 3.1.) is not in line with the terminology used by the > >>> fecframe-framework-03 I-D (Section 2): > >>> "Source Flow" vs. "Source data flow" > >>> "Repair Flow" vs. "Repair data flow" > >>> "Source Symbol" vs. nothing > >>> "Repair Symbol" vs. nothing > >>> "Source Packet" vs. nothing > >>> "Repair Packet" vs. nothing > >>> And as I said before, IMHO the terminology proposed in the > framework > >>> I-D should be discussed too. > >>> > >>> So let's do things in the right order, especially as the framework > >>> WGLC finishes soon. > >>> > >>> Additionally, I may have some comments for the > >>> interleaved-fec-scheme-04 > >>> I-D. Since I missed the WGLC deadline, you have the right to > >>> blame me ;-) > >>> and I apologize in advance. > >>> > >>> Regards, > >>> > >>> Vincent > >>> > >>> > >>> Ali C. Begen (abegen) wrote: > >>>> This version addresses the comments received from fecframe > >>> and avt so far. > >>>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interl > >> eaved-fec-scheme-04.txt > >>>> > >>>> > >>>> Fecframe chairs, > >>>> > >>>> Could we proceed and finalize WGLC? > >>>> > >>>> -acbegen > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >>>> Sent: Wednesday, April 29, 2009 2:56 PM > >>>> To: Ali C. Begen (abegen) > >>>> Subject: New Version Notification for > >>> draft-ietf-fecframe-interleaved-fec-scheme-04 > >>>> > >>>> > >>>> A new version of I-D, > >>> draft-ietf-fecframe-interleaved-fec-scheme-04.txt has been > >>> successfuly submitted by Ali Begen and posted to the IETF > >> repository. > >>>> > >>>> Filename: draft-ietf-fecframe-interleaved-fec-scheme > >>>> Revision: 04 > >>>> Title: RTP Payload Format for 1-D > >>> Interleaved Parity FEC > >>>> Creation_date: 2009-04-29 > >>>> WG ID: fecframe > >>>> Number_of_pages: 31 > >>>> > >>>> Abstract: > >>>> This document defines a new RTP payload format for the > >> Forward Error > >>>> Correction (FEC) that is generated by the 1-D interleaved > >>> parity code > >>>> from a source media encapsulated in RTP. The 1-D > >> interleaved parity > >>>> code is a systematic code, where a number of repair symbols are > >>>> generated from a set of source symbols and sent in a repair flow > >>>> separate from the source flow that carries the source > >> symbols. The > >>>> 1-D interleaved parity code offers a good protection > >> against bursty > >>>> packet losses at a cost of decent complexity. The new > >>> payload format > >>>> defined in this document is used (with some exceptions) > >> as a part of > >>>> the DVB Application-layer FEC specification. > >>>> > >>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> > >>>> _______________________________________________ > >>>> Fecframe mailing list > >>>> Fecframe@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/fecframe > >>> > >>> > >> > >> > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From stewe@stewe.org Sat May 2 20:03: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 D8A773A6930; Sat, 2 May 2009 20:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 ZBcNIFYdmo9b; Sat, 2 May 2009 20:02:59 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 79B1C3A6837; Sat, 2 May 2009 20:02:58 -0700 (PDT) Received: from [192.168.1.103] (unverified [75.60.27.134]) by stewe.org (SurgeMail 3.9e) with ESMTP id 256289-1743317 for multiple; Sun, 03 May 2009 05:04:21 +0200 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Sat, 02 May 2009 20:04:17 -0700 From: Stephan Wenger To: "avt@ietf.org" , "fecframe@ietf.org" Message-ID: Thread-Topic: MPEG liaison statement to the IETF Thread-Index: AcnLm9iJ3QTOagKUU02cbiSVJ8NneA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3324139460_8448992" X-Originating-IP: 75.60.27.134 X-Authenticated-User: stewe@stewe.org Subject: [Fecframe] MPEG liaison statement to the IETF 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, 03 May 2009 03:03:02 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3324139460_8448992 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi all, MPEG has sent a liaison statement (29n10339) to the IETF related to their intention to work on media transport. I assume it will show up in the IETF=B9s liaison tracker shortly. Meanwhile, if you need a copy and can=B9t pull the MPEG documents yourself, email me. The IETF=B9s email system does not allow me to add the .zip file the statement came in, and it=B9s too big i= n unzipped format. Clearly, there is overlap, if not competition, between AVT=B9s work and what MPEG anticipates, at least for some applications. I=B9m also copying fecframe. While the overlap in this case is less clear, I have reasons to believe that MPEG may touch our interests here as well. Arguably, there is a similar overlap/competition to the work performed in numerous other SDOs. The work appears to be in a very early stage. They are calling for a workshop during their forthcoming London meeting. Perhaps some of you are interested in submitting statements or attending the workshop... Regards, Stephan P.s.: I have an opinion about the intentions and plans behind this statement, but it would be impolite to voice it. --B_3324139460_8448992 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable MPEG liaison statement to the IETF Hi all,
MPEG has sent a liaison statement (29n10339) to the IETF related to their i= ntention to work on media transport.  I assume it will show up in the I= ETF’s liaison tracker shortly.  Meanwhile, if you need a copy and= can’t pull the MPEG documents yourself, email me.  The IETF̵= 7;s email system does not allow me to add the .zip file the statement came i= n, and it’s too big in unzipped format.
Clearly, there is overlap, if not competition, between AVT’s work and= what MPEG anticipates, at least for some applications.  I’m also= copying fecframe.  While the overlap in this case is less clear, I hav= e reasons to believe that MPEG may touch our interests here as well.  A= rguably, there is a similar overlap/competition to the work performed in num= erous other SDOs.  
The work appears to be in a very early stage.  They are calling for a = workshop during their forthcoming London meeting.  Perhaps some of you = are interested in submitting statements or attending the workshop...
Regards,
Stephan
P.s.: I have an opinion about the intentions and plans behind this statemen= t, but it would be impolite to voice it.
 --B_3324139460_8448992-- From tendyntu@huawei.com Mon May 4 00:12: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 3A4EF3A6C11 for ; Mon, 4 May 2009 00:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.217 X-Spam-Level: * X-Spam-Status: No, score=1.217 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 CdKIyJkJKdS7 for ; Mon, 4 May 2009 00:12:24 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A0BEB3A6D5D for ; Mon, 4 May 2009 00:10:54 -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 <0KJ3006GQYO6W0@szxga03-in.huawei.com> for fecframe@ietf.org; Mon, 04 May 2009 15:12:06 +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 <0KJ3001NLYO6DH@szxga03-in.huawei.com> for fecframe@ietf.org; Mon, 04 May 2009 15:12:06 +0800 (CST) Received: from z61302 ([10.85.208.250]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ300M3NYO5OR@szxml04-in.huawei.com> for fecframe@ietf.org; Mon, 04 May 2009 15:12:05 +0800 (CST) Date: Mon, 04 May 2009 15:12:05 +0800 From: Zou ZiXuan To: fecframe@ietf.org Message-id: <008801c9cc87$a1336100$e39a2300$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/related; boundary="Boundary_(ID_y0vYfkrjh3KKbMhLHBhwxg)" Content-language: zh-cn Thread-index: AcnMh54PuVolB7i2QEacHsouN7K5vA== Subject: [Fecframe] transmit source payload ID in separate flow 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, 04 May 2009 07:12:30 -0000 һ MIME ʽĶಿʼ --Boundary_(ID_y0vYfkrjh3KKbMhLHBhwxg) Content-type: multipart/alternative; boundary="Boundary_(ID_OgpfBc/KGyHwbntxovktGQ)" --Boundary_(ID_OgpfBc/KGyHwbntxovktGQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I have a question on the source FEC payload ID, which I think belongs to FEC Framework . I would appreciate for comments on this question. "Draft-ietf-fecframe-framework-03" and "draft-ietf-fecframe-interleaved-fec-scheme-04" both mentioned the case where source FEC packet does not carry source FEC payload ID for FEC protection. The reason for not having source FEC payload ID is that the sequence number (if exist) can take the source FEC payload ID's place. This brings backward compatibility to FEC-incapable client. RTP was said to be an example that can be applied to this case. But this works based on a requirement that the source FEC packets have to be of identical length, which is not necessarily met during FEC protection. RTP packet length may vary during streaming. So, though there is sequence number, sometimes the source FEC payload ID is still a must. In such a case, if we still want to have backward compatibility by not changing the source packet format, a possible way to follow is to transmit the source FEC payload IDs in separate packets. In order to indicate the position of source packet in a source block, the sequence number of source packet would also be sent along with the source FEC payload ID. For example, we could define a packet format with at least the following content: the sequence number of the very first source packet of a source block, followed by source FEC payload ID of all source packets of the same source block. These metrics collaboratively determines the position of a source packet in a source block. The comments on the above are welcome. Best Regards. Zou ZiXuan, Ph.D, Senior Research Staff Media & Communication Laboratory Corporate Research Department huawei_logo Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: 86-0755-28789364 Fax: 86-0755-28567643 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! --Boundary_(ID_OgpfBc/KGyHwbntxovktGQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

         I have a question on the source FEC payload ID, which I think belongs to FEC Framework . I would appreciate for comments on this question.

 

“Draft-ietf-fecframe-framework-03” and “draft-ietf-fecframe-interleaved-fec-scheme-04” both mentioned the case where source FEC packet does not carry source FEC payload ID for FEC protection. The reason for not having source FEC payload ID is that the sequence number (if exist) can take the source FEC payload ID’s place. This brings backward compatibility to FEC-incapable client. RTP was said to be an example that can be applied to this case. But this works based on a requirement that the source FEC packets have to be of identical length, which is not necessarily met during FEC protection. RTP packet length may vary during streaming. So, though there is sequence number, sometimes the source FEC payload ID is still a must.

In such a case, if we still want to have backward compatibility by not changing the source packet format, a possible way to follow is to transmit the source FEC payload IDs in separate packets. In order to indicate the position of source packet in a source block, the sequence number of source packet would also be sent along with the source FEC payload ID. For example, we could define a packet format with at least the following content: the sequence number of the very first source packet of a source block, followed by source FEC payload ID of all source packets of the same source block. These metrics collaboratively determines the position of a source packet in a source block.

The comments on the above are welcome.

        

Best Regards.

 

Zou ZiXuan, Ph.D, Senior Research Staff
Media & Communication Laboratory

Corporate Research Department huawei_logo


Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: 86-0755-28789364
Fax: 86-0755-28567643
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!

--Boundary_(ID_OgpfBc/KGyHwbntxovktGQ)-- --Boundary_(ID_y0vYfkrjh3KKbMhLHBhwxg) Content-id: Content-type: image/jpeg; name=image001.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_y0vYfkrjh3KKbMhLHBhwxg)-- From vincent.roca@inrialpes.fr Mon May 4 08:09:09 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 B03BF3A6FBF; Mon, 4 May 2009 08:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSZcfunV5OAj; Mon, 4 May 2009 08:09:08 -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 9C1D53A6B5F; Mon, 4 May 2009 08:09:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238968800"; d="txt'?scan'208";a="39426093" 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; 04 May 2009 17:10:31 +0200 Message-ID: <49FF0566.4080000@inrialpes.fr> Date: Mon, 04 May 2009 17:10:30 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Marshall Eubanks , "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------050005040300070204020209" Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 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, 04 May 2009 15:09:09 -0000 This is a multi-part message in MIME format. --------------050005040300070204020209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Ali, As promised, here are my comments for your I-D. And sorry for being rather late. Regards, Vincent --------------050005040300070204020209 Content-Type: text/plain; name="fecframe-interleaved-fec-04_comments.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fecframe-interleaved-fec-04_comments.txt" Comments to draft-ietf-fecframe-interleaved-fec-scheme-04 Vincent - May 3rd, 2009 ---------------------------------------------------------- For discussion... I- Main comments ---------------- 1/** Introduction, p.4 It is said: "Note that the sender MUST transmit the source and repair packets in different source and repair flows, respectively to offer backward compatibility (See Section 4)." The fact that source an repair packets belong to different flows is not sufficient to offer backward compatibility, since the notion of source/repair flow says nothing about the way these flows are transported in transport flows (see Definition, section 3.1). This sentence suggests on the contrary that they are transported independently which is not necessarily the case (cf. last week mailing list thread). I suggest: "Note that the source and repair packets belong to different source and repair flows, and the sender MUST provide a way for the receivers to demultiplex them, even in the case they are sent in the same transport flow (i.e., same source/destination IP/port with UDP). This is required to offer backward compatibility (See Section 4)." I also suggest to clarify the Source/Repair Flow definitions in Section 3.1, to say explicitly that there are different possible mappings to transport flow(s). 2/** Section 4.2, p13: It is said: o Synchronization Source (SSRC): The SSRC value SHALL be randomly assigned as suggested by [RFC3550]. This allows the sender to multiplex the source and repair flows on the same port, or multiplex multiple repair flows on a single port. I suggest to refer to "transport flows", i.e., in case of UDP, the 5-tuple, rather than "port" which is much more imprecise. BTW, do you refer to the source or destination port in the above sentence, and what about the source/destination address? 3/** Fig. 3: Current figure looks like the following: [...] + ------------- | XOR | ------------- = +===+ |C_1| +===+ I don't like the "+ XOR" in the above figure, since it suggests (to me at least) that the {S_1 .. S_XXX} symbols are "summed" with a XOR symbol to produce the C_1. I'd prefer something like: XOR sum of set +-------------+ | S_1 | | S_L+1 | | . | | . | | . | | S_(D-1)xL+1 | +-------------+ = +===+ |C_1| +===+ (and something similar with the 1D/2D I-D) 4/** Section 4.2 "Repair Packets", p12, RTP header clarifications. I don't like the sentences: "This bit is obtained by applying protection to the corresponding XX bits from the RTP headers of the source packets protected by this repair packet". We don't apply any protection to produce this bit, this is the contrary. I suggest: "This bit is equal to the XOR sum of the corresponding XX bits from the RTP headers of the source packets protected by this repair packet". 5/** Section 4.2, p 15: It is said (last sentence): "Instead, a systematic approach is inherently more efficient." I don't like the "systematic" adjective above. I suggest: Instead, providing implicitly the list, thanks to the {base sequence number; D; L} tuple and the knowledge of the associated algorithm, is more efficient." 6/** Section 5.2.1, p21: It is said: "The size of the repair-window is related to how fast the sender will send the repair packets." I don't agree with the wording "how fast". It's more a matter of delay with the transmission of the repair packet for a given source packet than a "bandwidth" issue". I suggest: "The size of the repair-window is related to the maximum delay between the transmission of a source packet and the associated repair packet." 7/** Section 6, p.22: It is said: "This section provides a complete specification of the 1-D interleaved parity code." This is not only a specification of the code, but also of the new RTP payload format for these codes. 8/** Section 6, p.23: It is said: "Note that if the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. Due to this possible padding and mandatory FEC header, a repair packet usually has a larger size than the source packets it protects. This may cause problems if the resulting repair packet size exceeds the Maximum Transmission Unit (MTU) size of the path over which the repair flow is sent." Several issues: - it's not only a problem of different payload lengths. If two packets have the same payload lengths but different variable length lists/ extensions, then the bit streams will have different length too. The first sentence should be corrected. - we need to define what "the longest packet" means. Is it for this set of source packets (I assume yes) or for all the packets of the session (if this has a meaning)? - we need to define what "length" means. Is it only the payload length, or does it include the various variable length extensions/lists? - a repair packet ALWAYS (rather than "usually") has a larger size than the source packets it protects (even the longest one, because of the additional 16 byte FEC header in that case). 9/** Section 6.3.1, p 25: The following formula is provided to generate the source packet sequence number: p*_snb + i * L This equation should take into account the possible wrapping of this 16-bit RTP sequence number field. I suggest: (p*_snb + i * L) modulo (65536) 10/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 It is said: 2. For the repair packet associated with set T, compute the bit string in the same fashion except use the PT recovery field instead of the PT field and TS recovery field instead of the Timestamp field, and set the CSRC list, header extension and padding to null regardless of the values of the CC field, X bit and P bit. This is not clear at all to me (even if I understand the intent). The structure of the bit string is the same, but the values are the ones that have been received. So, saying "compute the XXX field in the same fashion..." is misleading, as well as "XXX recovery field". I suggest: 2. For the repair packet associated with set T, construct the bit string similarly, using the values received in the repair packet for the PT and TS fields, ... 11/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 I also suggest a different ordering, since as such there is an incoherency: In step 1, we cannot "compute the bit string as described in section 6.2", since we still don't know at this stage the maximum length, and so the required padding. But if we switch the order, everything works well. I suggest (reorder + merge): 1. For the repair packet... 2. For each of the source packets, ... If the bit string generated is shorter than the string generated for the repair packet... 12/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 It is said, in step 14: 14. Take the next 16 bits of the recovered bit string and set Y to whatever unsigned integer this represents (assuming network- order). Take Y bytes from the recovered bit string... Two points: - I suggest saying explicitly that "Y" is a new unsigned integer variable (it was not clear to me when reading it first); - I also suggest saying explicitly that Y must first be converted to host order, otherwise funny things will happen on our little endian machines ;-) To summarize, I suggest: 14. Take the next 16 bits of the recovered bit string and set the new variable Y to whatever unsigned integer this represents (assuming network-order). Convert Y to host byte order and then take Y bytes from the recovered bit string... 13/** Section 13.2 "Informative references" Why is reference RFC2733 in the informative section whereas the goal of this document is to "extend the Forward Error Correction (FEC) header defined in [RFC2733]"? It deserves a Normative Ref IMHO. II- Typos and minor comments ---------------------------- ** Section 3.3: I don't think that the bitwise table of XOR sums is needed. ** Section 6.3. Source Packet Reconstruction, p24: I suggest (1st sentence): ...reconstruct the missing source packets. ^^^^^^ ** Section 6.3.1, p25: if there is only one source packet missing in set T. ^^^^ (removed "is") ** Section 7, SDP example. We can probably remove the extra " " space in "repair-window: 200000" (i.e., like the other parameters). --------------050005040300070204020209-- From abegen@cisco.com Mon May 4 09:06: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 DFE7B3A686D for ; Mon, 4 May 2009 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 jMPEIq-g9FTO for ; Mon, 4 May 2009 09:06:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CFF3B3A6FA9 for ; Mon, 4 May 2009 09:05:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238976000"; d="scan'208";a="297963226" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 May 2009 16:07:22 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n44G7MqV019069; Mon, 4 May 2009 09:07:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n44G7MYP015030; Mon, 4 May 2009 16:07:22 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 09:07:22 -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: Mon, 4 May 2009 09:07:12 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093C3184@xmb-sjc-215.amer.cisco.com> In-Reply-To: <008801c9cc87$a1336100$e39a2300$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] transmit source payload ID in separate flow Thread-Index: AcnMh54PuVolB7i2QEacHsouN7K5vAASgYdQ References: <008801c9cc87$a1336100$e39a2300$@com> From: "Ali C. Begen (abegen)" To: "Zou ZiXuan" , X-OriginalArrivalTime: 04 May 2009 16:07:22.0302 (UTC) FILETIME=[685EEDE0:01C9CCD2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3494; t=1241453242; x=1242317242; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20transmit=20source=20payloa d=20ID=20in=20separate=20flow |Sender:=20; bh=8U56mLERqEwzTZCCJxiVBBAdSBBG2vv2P+y0K+kAe/U=; b=yB/Zgv4nsO/QCLhcDHYbp/VYX0yAiOSym1W4QeNjo+1Is8v+VxDXRLFML1 A8YTq2CCY0cEoRbk1SwgKGefHGQqdK/HyRMdPZXIrrFFWPpeHsgfus5xmNgo O2iHiRM4Do; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Fecframe] transmit source payload ID in separate flow 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, 04 May 2009 16:06:39 -0000 Hi Zou, Inline. > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Zou ZiXuan > Sent: Monday, May 04, 2009 12:12 AM > To: fecframe@ietf.org > Subject: [Fecframe] transmit source payload ID in separate flow >=20 > Hi, >=20 > I have a question on the source FEC payload ID, which I think = belongs to FEC Framework . I > would appreciate for comments on this question. >=20 >=20 >=20 > =93Draft-ietf-fecframe-framework-03=94 and = =93draft-ietf-fecframe-interleaved-fec-scheme-04=94 both mentioned > the case where source FEC packet does not carry source FEC payload ID = for FEC protection. The reason > for not having source FEC payload ID is that the sequence number (if = exist) can take the source FEC > payload ID=92s place. This brings backward compatibility to = FEC-incapable client. RTP was said to be an Yes. > example that can be applied to this case. But this works based on a = requirement that the source FEC > packets have to be of identical length, which is not necessarily met = during FEC protection. RTP packet > length may vary during streaming. So, though there is sequence number, = sometimes the source FEC > payload ID is still a must. Sure they can vary. And in the interleaved draft, we don't care. There = is a field in the FEC header, called "Length recovery" which determines = the length of the recovered packet. =20 > In such a case, if we still want to have backward compatibility by not = changing the source packet > format, a possible way to follow is to transmit the source FEC payload = IDs in separate packets. In > order to indicate the position of source packet in a source block, the = sequence number of source > packet would also be sent along with the source FEC payload ID. For = example, we could define a packet > format with at least the following content: the sequence number of the = very first source packet of a > source block, followed by source FEC payload ID of all source packets = of the same source block. These > metrics collaboratively determines the position of a source packet in = a source block. Keeping the source packets unchanged is of course desirable. However, = generating a new flow may bring up other issues, like needing a new = multicast group, etc. So, the trade-off must be examined well. BR, -acbegen =20 > The comments on the above are welcome. >=20 >=20 >=20 > Best Regards. >=20 >=20 >=20 > Zou ZiXuan, Ph.D, Senior Research Staff > Media & Communication Laboratory >=20 > Corporate Research Department huawei_logo >=20 >=20 > Huawei Industrial Base > Bantian Longgang > Shenzhen 518129, P.R.China > Tel: 86-0755-28789364 > Fax: 86-0755-28567643 > 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! From abegen@cisco.com Mon May 4 14:27: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 5DF7C3A67AC; Mon, 4 May 2009 14:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 L1cL1u-KX89B; Mon, 4 May 2009 14:27:40 -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 C941B3A6AE2; Mon, 4 May 2009 14:27:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,293,1238976000"; d="scan'208";a="180674154" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 04 May 2009 21:29:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n44LT739030835; Mon, 4 May 2009 14:29:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n44LT6D0014702; Mon, 4 May 2009 21:29:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 14:29:06 -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: Mon, 4 May 2009 14:27:39 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093C3454@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49FF0566.4080000@inrialpes.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 Thread-Index: AcnMynwidu69tWVRSmm/MDDTLaYEWQAIcLmg References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49FF0566.4080000@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Vincent Roca" , "Marshall Eubanks" X-OriginalArrivalTime: 04 May 2009 21:29:06.0852 (UTC) FILETIME=[5AC77E40:01C9CCFF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11268; t=1241472547; x=1242336547; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20FW=3A=20New=20Version=20No tification=20for=09draft-ietf-fecframe-interleaved-fec-schem e-04 |Sender:=20; bh=E3YXyc4//MZHbNSmRfJaveU6h14lxREiZdPnkz03QY4=; b=HWvCCmqSde5eftIuChg/9k81suhjPHMD9Q23zhn1PiJJ3OFO0RRe1WYFI9 FOUVWq8OqLTl13yezGlPY1s0zAgdtPM9XXjNVzXSmpj2UH6b3f0Grlhd8/Je 3GSe2i0Gp0; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 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, 04 May 2009 21:27:42 -0000 Thanks for the detailed review. I'll get most of them into the next = revision. I have some comments for some of them, though. Inline. 1/** Introduction, p.4 It is said: "Note that the sender MUST transmit the source and repair packets in different source and repair flows, respectively to offer backward compatibility (See Section 4)." The fact that source an repair packets belong to different flows is not sufficient to offer backward compatibility, since the notion of source/repair flow says nothing about the way these flows are transported in transport flows (see Definition, section 3.1). This sentence suggests on the contrary that they are transported independently which is not necessarily the case (cf. last week mailing list thread). I suggest: "Note that the source and repair packets belong to different source and repair flows, and the sender MUST provide a way for the receivers to demultiplex them, even in the case they are sent in the same transport flow (i.e., same source/destination IP/port with UDP). This is required to offer backward compatibility (See Section 4)." Ali: Sounds good. I also suggest to clarify the Source/Repair Flow definitions in Section 3.1, to say explicitly that there are different possible mappings to transport flow(s). Ali: This should rather go to the framework draft. 2/** Section 4.2, p13: It is said: o Synchronization Source (SSRC): The SSRC value SHALL be randomly assigned as suggested by [RFC3550]. This allows the sender to multiplex the source and repair flows on the same port, or multiplex multiple repair flows on a single port.=20 I suggest to refer to "transport flows", i.e., in case of UDP, the 5-tuple, rather than "port" which is much more imprecise. BTW, do you refer to the source or destination port in the above sentence, and what about the source/destination address? Ali: If two RTP streams are sent to different IP addresses, they are = different RTP sessions anyway. Random SSRCs help when we send two RTP = streams in the same RTP session. Source address/port is irrelevant. So, = I don't see any confusion here. 3/** Fig. 3:=20 Current figure looks like the following: [...] + =20 -------------=20 | XOR | -------------=20 =3D =20 +=3D=3D=3D+ =20 |C_1| =20 +=3D=3D=3D+ =20 I don't like the "+ XOR" in the above figure, since it suggests (to me at least) that the {S_1 .. S_XXX} symbols are "summed" with a XOR symbol to produce the C_1. I'd prefer something like: XOR sum of set +-------------+ | S_1 | | S_L+1 | | . | | . | | . | | S_(D-1)xL+1 | +-------------+ =3D =20 +=3D=3D=3D+ =20 |C_1| =20 +=3D=3D=3D+=20 (and something similar with the 1D/2D I-D) Ali: I believe the context is clear here as the source, repair and = operation are encapsulated differently. 4/** Section 4.2 "Repair Packets", p12, RTP header clarifications. I don't like the sentences: "This bit is obtained by applying protection to the corresponding XX bits from the RTP headers of the source packets protected by this repair packet". We don't apply any protection to produce this bit, this is the contrary. I suggest: "This bit is equal to the XOR sum of the corresponding XX bits from the RTP headers of the source packets protected by this repair packet". Ali: I am sorry but I don't get your point. I could say "applying XOR = operation" but the difference is negligible. 5/** Section 4.2, p 15: It is said (last sentence): "Instead, a systematic approach is inherently more efficient." I don't like the "systematic" adjective above. I suggest: Instead, providing implicitly the list, thanks to the {base sequence number; D; L} tuple and the knowledge of the associated algorithm, is more efficient." Ali: I could say "systematized" if you like it better because systematic = or systematized captures what I would like to say. =20 6/** Section 5.2.1, p21: It is said: "The size of the repair-window is related to how fast the sender will send the repair packets." I don't agree with the wording "how fast". It's more a matter of delay with the transmission of the repair packet for a given source packet than a "bandwidth" issue". I suggest: "The size of the repair-window is related to the maximum delay between the transmission of a source packet and the associated repair packet." Ali: OK 7/** Section 6, p.22: It is said: "This section provides a complete specification of the 1-D interleaved parity code." This is not only a specification of the code, but also of the new RTP payload format for these codes. Ali: OK 8/** Section 6, p.23: It is said: "Note that if the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. Due to this possible padding and mandatory FEC header, a repair packet usually has a larger size than the source packets it protects. This may cause problems if the resulting repair packet size exceeds the Maximum Transmission Unit (MTU) size of the path over which the repair flow is sent." Several issues: - it's not only a problem of different payload lengths. If two packets have the same payload lengths but different variable length lists/ extensions, then the bit streams will have different length too. The first sentence should be corrected. Ali: Right. - we need to define what "the longest packet" means. Is it for this set of source packets (I assume yes) or for all the packets of the session (if this has a meaning)? Ali: Within this source block and I believe it is pretty clear. - we need to define what "length" means. Is it only the payload length, or does it include the various variable length extensions/lists? Ali: The first item above will take care of this. - a repair packet ALWAYS (rather than "usually") has a larger size than the source packets it protects (even the longest one, because of the additional 16 byte FEC header in that case). Ali: I'd agree with this. But 2733 did not use "always" in the text. Not = sure whether we should stick with it, though. 9/** Section 6.3.1, p 25: The following formula is provided to generate the source packet=20 sequence number: p*_snb + i * L This equation should take into account the possible wrapping of this 16-bit RTP sequence number field. I suggest: (p*_snb + i * L) modulo (65536) Ali: Yes, wrapping should be taken into account. 10/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 It is said: 2. For the repair packet associated with set T, compute the bit string in the same fashion except use the PT recovery field instead of the PT field and TS recovery field instead of the Timestamp field, and set the CSRC list, header extension and padding to null regardless of the values of the CC field, X bit and P bit. This is not clear at all to me (even if I understand the intent). The structure of the bit string is the same, but the values are the ones that have been received. So, saying "compute the XXX field in the same fashion..." is misleading, as well as "XXX recovery field". I suggest: 2. For the repair packet associated with set T, construct the bit string similarly, using the values received in the repair packet for the PT and TS fields, ... Ali: No. We need to explicitly say the "PT/TS recovery fields" here = since there are also the PT and TS fields in the RTP header. 11/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 I also suggest a different ordering, since as such there is an incoherency: In step 1, we cannot "compute the bit string as described in section 6.2", since we still don't know at this stage the maximum length, and so the required padding. But if we switch the order, everything works well. I suggest (reorder + merge): 1. For the repair packet... 2. For each of the source packets, ... If the bit string generated is shorter than the string generated for the repair packet... Ali: Not that this is incorrect, but the current text is not incorrect, = either. Padding does not change the bitstring and necessary padding can = always be added. I suggest to keep the current text to be consistent = with 2733. 12/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 It is said, in step 14: 14. Take the next 16 bits of the recovered bit string and set Y to whatever unsigned integer this represents (assuming network- order). Take Y bytes from the recovered bit string... Two points: - I suggest saying explicitly that "Y" is a new unsigned integer variable (it was not clear to me when reading it first); - I also suggest saying explicitly that Y must first be converted to host order, otherwise funny things will happen on our little endian machines ;-) To summarize, I suggest: 14. Take the next 16 bits of the recovered bit string and set the new variable Y to whatever unsigned integer this represents (assuming network-order). Convert Y to host byte order and then take Y bytes from the recovered bit string... Ali: Sounds good. 13/** Section 13.2 "Informative references" Why is reference RFC2733 in the informative section whereas the goal=20 of this document is to "extend the Forward Error Correction (FEC) header defined in [RFC2733]"? It deserves a Normative Ref IMHO. Ali: Because it has been obsoleted and the fact that the current spec = does not need RFC 2733 to be implemented.=20 II- Typos and minor comments ---------------------------- ** Section 3.3: I don't think that the bitwise table of XOR sums is = needed. ** Section 6.3. Source Packet Reconstruction, p24: I suggest (1st sentence): ...reconstruct the missing source packets. ^^^^^^ Ali: Good idea. ** Section 6.3.1, p25: if there is only one source packet missing in set T.=20 ^^^^ (removed "is") Ali: Good catch. ** Section 7, SDP example. We can probably remove the extra " " space in "repair-window: 200000" (i.e., like the other parameters). Ali: We should.=20 Thanks, -acbegen > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Monday, May 04, 2009 8:10 AM > To: Marshall Eubanks; Ali C. Begen (abegen) > Cc: avt@ietf.org; fecframe@ietf.org > Subject: Re: [Fecframe] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec-scheme-04 >=20 > Hello Ali, >=20 > As promised, here are my comments for your I-D. > And sorry for being rather late. > Regards, >=20 > Vincent From tendyntu@huawei.com Mon May 4 19:33: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 F157F3A6BDD for ; Mon, 4 May 2009 19:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=0.354, 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 oPsv1os2tu4R for ; Mon, 4 May 2009 19:33:57 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BDEA53A6AE1 for ; Mon, 4 May 2009 19:33:56 -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 <0KJ500D61GIOTW@szxga03-in.huawei.com> for fecframe@ietf.org; Tue, 05 May 2009 10:35:12 +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 <0KJ5008PQGIOM5@szxga03-in.huawei.com> for fecframe@ietf.org; Tue, 05 May 2009 10:35:12 +0800 (CST) Received: from z61302 ([10.85.208.250]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ5004BBGIN40@szxml04-in.huawei.com> for fecframe@ietf.org; Tue, 05 May 2009 10:35:12 +0800 (CST) Date: Tue, 05 May 2009 10:35:11 +0800 From: Zou ZiXuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D54093C3184@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , fecframe@ietf.org Message-id: <00bc01c9cd2a$1d6d6980$58483c80$@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: AcnMh54PuVolB7i2QEacHsouN7K5vAASgYdQABRa1BA= References: <008801c9cc87$a1336100$e39a2300$@com> <04CAD96D4C5A3D48B1919248A8FE0D54093C3184@xmb-sjc-215.amer.cisco.com> Subject: Re: [Fecframe] transmit source payload ID in separate flow 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, 05 May 2009 02:33:58 -0000 Hi, Ali, Inline > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Tuesday, May 05, 2009 12:07 AM > To: Zou ZiXuan; fecframe@ietf.org > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > Hi Zou, > > Inline. > > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf Of Zou ZiXuan > > Sent: Monday, May 04, 2009 12:12 AM > > To: fecframe@ietf.org > > Subject: [Fecframe] transmit source payload ID in separate flow > > > > Hi, > > > > I have a question on the source FEC payload ID, which I think > belongs to FEC Framework . I > > would appreciate for comments on this question. > > > > > > > > "Draft-ietf-fecframe-framework-03" and > "draft-ietf-fecframe-interleaved-fec-scheme-04" both mentioned > > the case where source FEC packet does not carry source FEC payload ID > for FEC protection. The reason > > for not having source FEC payload ID is that the sequence number (if exist) > can take the source FEC > > payload ID's place. This brings backward compatibility to FEC-incapable > client. RTP was said to be an > > Yes. > > > example that can be applied to this case. But this works based on a > requirement that the source FEC > > packets have to be of identical length, which is not necessarily met during > FEC protection. RTP packet > > length may vary during streaming. So, though there is sequence number, > sometimes the source FEC > > payload ID is still a must. > > Sure they can vary. And in the interleaved draft, we don't care. There is a field > in the FEC header, called "Length recovery" which determines the length of > the recovered packet. > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. But it does exist under other circumstance like using Raptor code for content delivery protection. My question is basically related to the description in FEC framework draft related to unchanged source packet. It only cover the case of excluding FEC payload ID during protection. I think we should add some text in FEC framework draft regarding taking FEC payload ID out and transmitting it in separate packets. > > > In such a case, if we still want to have backward compatibility by not > changing the source packet > > format, a possible way to follow is to transmit the source FEC payload IDs > in separate packets. In > > order to indicate the position of source packet in a source block, the > sequence number of source > > packet would also be sent along with the source FEC payload ID. For > example, we could define a packet > > format with at least the following content: the sequence number of the very > first source packet of a > > source block, followed by source FEC payload ID of all source packets of > the same source block. These > > metrics collaboratively determines the position of a source packet in a > source block. > > Keeping the source packets unchanged is of course desirable. However, > generating a new flow may bring up other issues, like needing a new > multicast group, etc. So, the trade-off must be examined well. [ZiXuan] Sharing a session among repair packet flow (or source packet flow) and "source FEC payload ID" flow is probably a way to go for your concern. For client making a distinguish between two flows, payload type multiplexing of some kind is probably needed. A "FEC header" with a PT field of different value shall be used for identifying different flows. > > BR, > -acbegen > > > > The comments on the above are welcome. > > > > > > > > Best Regards. > > > > > > > > Zou ZiXuan, Ph.D, Senior Research Staff > > Media & Communication Laboratory > > > > Corporate Research Department huawei_logo > > > > > > Huawei Industrial Base > > Bantian Longgang > > Shenzhen 518129, P.R.China > > Tel: 86-0755-28789364 > > Fax: 86-0755-28567643 > > 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! From abegen@cisco.com Mon May 4 19:58:15 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 A9FB73A67EF for ; Mon, 4 May 2009 19:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 f8Q-M9KXYHQt for ; Mon, 4 May 2009 19:58:14 -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 6F2F33A6359 for ; Mon, 4 May 2009 19:58:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,294,1238976000"; d="scan'208";a="298306693" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 May 2009 02:59:28 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n452xS0u016459; Mon, 4 May 2009 19:59:28 -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.13.8) with ESMTP id n452xSsS010926; Tue, 5 May 2009 02:59:28 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 19:59:28 -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: Mon, 4 May 2009 19:58:55 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093C3616@xmb-sjc-215.amer.cisco.com> In-Reply-To: <00bc01c9cd2a$1d6d6980$58483c80$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] transmit source payload ID in separate flow Thread-Index: AcnMh54PuVolB7i2QEacHsouN7K5vAASgYdQABRa1BAAAn270A== References: <008801c9cc87$a1336100$e39a2300$@com> <04CAD96D4C5A3D48B1919248A8FE0D54093C3184@xmb-sjc-215.amer.cisco.com> <00bc01c9cd2a$1d6d6980$58483c80$@com> From: "Ali C. Begen (abegen)" To: "Zou ZiXuan" , X-OriginalArrivalTime: 05 May 2009 02:59:28.0724 (UTC) FILETIME=[81892140:01C9CD2D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6056; t=1241492368; x=1242356368; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20RE=3A=20[Fecframe]=20transmit=20source=20payloa d=20ID=20in=20separate=20flow |Sender:=20; bh=0yDnfco/jwzJ+DzxF4b7LwE6ACy/fdIaf6QWj6c4FY0=; b=ijl2/J/cIhAzQkXCISjTrtg0iJr5+lLbG38KFLCnXlWhRIujUAjAU3ugtd 33A68zTLtdsxMZ5sP4LKBB4Og9JBBcX/CqNkIUfs/eUosHiSsjKy8jOL2cyh C3gfOX8Rin; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Fecframe] transmit source payload ID in separate flow 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, 05 May 2009 02:58:15 -0000 > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. = But > it does exist under other circumstance like using Raptor code for > content delivery protection. My question is basically related to the > description in FEC framework draft related to unchanged source packet. > It only cover the case of excluding FEC payload ID during protection. = I > think we should add some text in FEC framework draft regarding taking > FEC payload ID out and transmitting it in separate packets. I guess you can propose some text to Mark that explains your motivation = and how to make this work in practice. Whether this approach will be = taken or not by an implementation, it depends, but we can certainly = mention it in the framework draft. BR, -acbegen > -----Original Message----- > From: Zou ZiXuan [mailto:tendyntu@huawei.com] > Sent: Monday, May 04, 2009 7:35 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: RE: [Fecframe] transmit source payload ID in separate flow >=20 > Hi, Ali, > Inline >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Tuesday, May 05, 2009 12:07 AM > > To: Zou ZiXuan; fecframe@ietf.org > > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > > Hi Zou, > > > > Inline. > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] > On > > Behalf Of Zou ZiXuan > > > Sent: Monday, May 04, 2009 12:12 AM > > > To: fecframe@ietf.org > > > Subject: [Fecframe] transmit source payload ID in separate flow > > > > > > Hi, > > > > > > I have a question on the source FEC payload ID, which I > think > > belongs to FEC Framework . I > > > would appreciate for comments on this question. > > > > > > > > > > > > "Draft-ietf-fecframe-framework-03" and > > "draft-ietf-fecframe-interleaved-fec-scheme-04" both mentioned > > > the case where source FEC packet does not carry source FEC payload > ID > > for FEC protection. The reason > > > for not having source FEC payload ID is that the sequence number = (if > exist) > > can take the source FEC > > > payload ID's place. This brings backward compatibility to > FEC-incapable > > client. RTP was said to be an > > > > Yes. > > > > > example that can be applied to this case. But this works based on = a > > requirement that the source FEC > > > packets have to be of identical length, which is not necessarily = met > during > > FEC protection. RTP packet > > > length may vary during streaming. So, though there is sequence > number, > > sometimes the source FEC > > > payload ID is still a must. > > > > Sure they can vary. And in the interleaved draft, we don't care. = There > is a field > > in the FEC header, called "Length recovery" which determines the > length of > > the recovered packet. > > > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. = But > it does exist under other circumstance like using Raptor code for > content delivery protection. My question is basically related to the > description in FEC framework draft related to unchanged source packet. > It only cover the case of excluding FEC payload ID during protection. = I > think we should add some text in FEC framework draft regarding taking > FEC payload ID out and transmitting it in separate packets. > > > > > In such a case, if we still want to have backward compatibility by > not > > changing the source packet > > > format, a possible way to follow is to transmit the source FEC > payload IDs > > in separate packets. In > > > order to indicate the position of source packet in a source block, > the > > sequence number of source > > > packet would also be sent along with the source FEC payload ID. = For > > example, we could define a packet > > > format with at least the following content: the sequence number of > the very > > first source packet of a > > > source block, followed by source FEC payload ID of all source > packets of > > the same source block. These > > > metrics collaboratively determines the position of a source packet > in a > > source block. > > > > Keeping the source packets unchanged is of course desirable. = However, > > generating a new flow may bring up other issues, like needing a new > > multicast group, etc. So, the trade-off must be examined well. > [ZiXuan] Sharing a session among repair packet flow (or source packet > flow) and "source FEC payload ID" flow is probably a way to go for = your > concern. For client making a distinguish between two flows, payload = type > multiplexing of some kind is probably needed. A "FEC header" with a PT > field of different value shall be used for identifying different = flows. > > > > BR, > > -acbegen > > > > > > > The comments on the above are welcome. > > > > > > > > > > > > Best Regards. > > > > > > > > > > > > Zou ZiXuan, Ph.D, Senior Research Staff > > > Media & Communication Laboratory > > > > > > Corporate Research Department huawei_logo > > > > > > > > > Huawei Industrial Base > > > Bantian Longgang > > > Shenzhen 518129, P.R.China > > > Tel: 86-0755-28789364 > > > Fax: 86-0755-28567643 > > > 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! From vincent.roca@inrialpes.fr Tue May 5 07:44:21 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 C924D3A6C2E; Tue, 5 May 2009 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGUR6V6Cn3Im; Tue, 5 May 2009 07:44:20 -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 CC72A3A6A21; Tue, 5 May 2009 07:44:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,297,1238968800"; d="scan'208";a="39486264" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2009 16:45:44 +0200 Message-ID: <4A005118.40107@inrialpes.fr> Date: Tue, 05 May 2009 16:45:44 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D54066184FC@xmb-sjc-215.amer.cisco.com> <49FF0566.4080000@inrialpes.fr> <04CAD96D4C5A3D48B1919248A8FE0D54093C3454@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54093C3454@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Marshall Eubanks , avt@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-04 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, 05 May 2009 14:44:21 -0000 Hello Ali, A few answers inline, after removing the points where we agree. Ali C. Begen (abegen) wrote: > 1/** Introduction, p.4 [...] > I also suggest to clarify the Source/Repair Flow definitions in > Section 3.1, to say explicitly that there are different possible > mappings to transport flow(s). > > Ali: This should rather go to the framework draft. VR: Since the intent was to keep this document more or less independent from the framework I-D, it would make sense to put it here too. > 2/** Section 4.2, p13: > It is said: > o Synchronization Source (SSRC): The SSRC value SHALL be randomly > assigned as suggested by [RFC3550]. This allows the sender to > multiplex the source and repair flows on the same port, or > multiplex multiple repair flows on a single port. > > I suggest to refer to "transport flows", i.e., in case of UDP, the > 5-tuple, rather than "port" which is much more imprecise. BTW, do you > refer to the source or destination port in the above sentence, and > what about the source/destination address? > > Ali: If two RTP streams are sent to different IP addresses, they are different > RTP sessions anyway. Random SSRCs help when we send two RTP streams in the same > RTP session. Source address/port is irrelevant. So, I don't see any confusion here. VR: No, there is a confusion. Imagine that the sender uses different destination addresses, but the same destination port. In that case we don't need the SSRC. Saying "on the same port" without saying "and the same destination address" is misleading. I suggest: This allows the sender to multiplex the source and repair flows on the same RTP session (i.e., same destination address and port), or multiplex multiple repair flows on the same RTP session. > 3/** Fig. 3: > Current figure looks like the following: > [...] > + > ------------- > | XOR | > ------------- > = > +===+ > |C_1| > +===+ > > I don't like the "+ XOR" in the above figure, since it suggests (to me > at least) that the {S_1 .. S_XXX} symbols are "summed" with a XOR symbol > to produce the C_1. I'd prefer something like: > > XOR sum of set > +-------------+ > | S_1 | > | S_L+1 | > | . | > | . | > | . | > | S_(D-1)xL+1 | > +-------------+ > = > +===+ > |C_1| > +===+ > > (and something similar with the 1D/2D I-D) > > Ali: I believe the context is clear here as the source, repair and operation are encapsulated differently. VR: you're right, the encapsulation is different, I didn't notice. However I still don't like the XOR box which remains misleading IMHO. But you are the editor, I let you decide. > 4/** Section 4.2 "Repair Packets", p12, RTP header clarifications. > I don't like the sentences: > "This bit is obtained by applying protection to the corresponding > XX bits from the RTP headers of the source packets protected by > this repair packet". > > We don't apply any protection to produce this bit, this is the contrary. > I suggest: > "This bit is equal to the XOR sum of the corresponding XX bits > from the RTP headers of the source packets protected by this > repair packet". > > Ali: I am sorry but I don't get your point. I could say "applying XOR operation" > but the difference is negligible. VR: I don't like "by applying protection" or "by applying XOR operation" in the sentence and prefer my wording. Here also, you are the editor. > 8/** Section 6, p.23: > It is said: > "Note that if the payload lengths of the source packets are not equal, > each shorter packet MUST be padded to the length of the longest > packet by adding octet 0's at the end. Due to this possible padding > and mandatory FEC header, a repair packet usually has a larger size > than the source packets it protects. This may cause problems if the > resulting repair packet size exceeds the Maximum Transmission Unit > (MTU) size of the path over which the repair flow is sent." > > Several issues: > - a repair packet ALWAYS (rather than "usually") has a larger size > than the source packets it protects (even the longest one, because > of the additional 16 byte FEC header in that case). > > Ali: I'd agree with this. But 2733 did not use "always" in the text. Not > sure whether we should stick with it, though. VR: I was not aware of the RFC2733 wording. In any case, if there's a small mistake in this RFC, I don't see any good reason to reproduce it here. > 10/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 > It is said: > 2. For the repair packet associated with set T, compute the bit > string in the same fashion except use the PT recovery field > instead of the PT field and TS recovery field instead of the > Timestamp field, and set the CSRC list, header extension and > padding to null regardless of the values of the CC field, X bit > and P bit. > This is not clear at all to me (even if I understand the intent). > The structure of the bit string is the same, but the values are the > ones that have been received. So, saying "compute the XXX field in > the same fashion..." is misleading, as well as "XXX recovery field". > > I suggest: > 2. For the repair packet associated with set T, construct the bit > string similarly, using the values received in the repair > packet for the PT and TS fields, ... > > Ali: No. We need to explicitly say the "PT/TS recovery fields" here since > there are also the PT and TS fields in the RTP header. VR: Oups, you're right! I forgot that the "TP (resp. TS) recovery field" comes from the FEC Header. We can perhaps clarify the original wording to avoid such a mistake in the future (even if it's now clear to me): 2. For the repair packet associated with set T, compute the bit string in the same fashion, except that we use the PT (resp. TS) recovery field of the FEC header instead of the PT (resp. Timestamp) field of the RTP header,... > 11/** Section 6.3.2. "Recovering the RTP Header and Payload", p 25 > > I also suggest a different ordering, since as such there is an > incoherency: In step 1, we cannot "compute the bit string as described > in section 6.2", since we still don't know at this stage the maximum > length, and so the required padding. > But if we switch the order, everything works well. > > I suggest (reorder + merge): > 1. For the repair packet... > 2. For each of the source packets, ... If the bit string generated > is shorter than the string generated for the repair packet... > > Ali: Not that this is incorrect, but the current text is not incorrect, > either. Padding does not change the bitstring and necessary padding can > always be added. I suggest to keep the current text to be consistent with 2733. VR: As you want, but I'll swap the order if I implement it ;-) Cheers, Vincent From yekuiwang@huawei.com Tue May 5 08:20: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 5965D3A6AA8; Tue, 5 May 2009 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 HHv14i8NPjKA; Tue, 5 May 2009 08:20:37 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 4247828C130; Tue, 5 May 2009 08:20:37 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ600CQ2FZVGO@usaga02-in.huawei.com>; Tue, 05 May 2009 08:21:32 -0700 (PDT) Received: from W90946 ([10.193.125.102]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ600I6YFYXMG@usaga02-in.huawei.com>; Tue, 05 May 2009 08:21:31 -0700 (PDT) Date: Tue, 05 May 2009 11:20:53 -0400 From: Ye-Kui Wang In-reply-to: To: 'Stephan Wenger' , avt@ietf.org, fecframe@ietf.org Message-id: <2333479506674276BA8D2C5B9A04CD00@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_eoYm4PotupYXz5n/jpxQNw)" Thread-index: AcnLm9iJ3QTOagKUU02cbiSVJ8NneAB+HTYQ References: X-Mailman-Approved-At: Tue, 05 May 2009 08:23:41 -0700 Subject: Re: [Fecframe] [AVT] MPEG liaison statement to the IETF 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, 05 May 2009 15:20:42 -0000 This is a multi-part message in MIME format. --Boundary_(ID_eoYm4PotupYXz5n/jpxQNw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Information of the planned MPEG workshop can be found at http://www.chiariglione.org/mpeg/hot_news.htm. The background reason for the work item and the workshop can be found in the announcement of the workshop (named Workshop on MMT (MPEG Media Transport) on the website). BR, YK _____ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Saturday, May 02, 2009 11:04 PM To: avt@ietf.org; fecframe@ietf.org Subject: [AVT] MPEG liaison statement to the IETF Hi all, MPEG has sent a liaison statement (29n10339) to the IETF related to their intention to work on media transport. I assume it will show up in the IETF's liaison tracker shortly. Meanwhile, if you need a copy and can't pull the MPEG documents yourself, email me. The IETF's email system does not allow me to add the .zip file the statement came in, and it's too big in unzipped format. Clearly, there is overlap, if not competition, between AVT's work and what MPEG anticipates, at least for some applications. I'm also copying fecframe. While the overlap in this case is less clear, I have reasons to believe that MPEG may touch our interests here as well. Arguably, there is a similar overlap/competition to the work performed in numerous other SDOs. The work appears to be in a very early stage. They are calling for a workshop during their forthcoming London meeting. Perhaps some of you are interested in submitting statements or attending the workshop... Regards, Stephan P.s.: I have an opinion about the intentions and plans behind this statement, but it would be impolite to voice it. --Boundary_(ID_eoYm4PotupYXz5n/jpxQNw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT MPEG liaison statement to the IETF
Information of the planned MPEG workshop can be found at http://www.chiariglione.org/mpeg/hot_news.htm. The background reason for the work item and the workshop can be found in the announcement of the workshop (named Workshop on MMT (MPEG Media Transport) on the website).
 
BR, YK

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Saturday, May 02, 2009 11:04 PM
To: avt@ietf.org; fecframe@ietf.org
Subject: [AVT] MPEG liaison statement to the IETF

Hi all,
MPEG has sent a liaison statement (29n10339) to the IETF related to their intention to work on media transport.  I assume it will show up in the IETF’s liaison tracker shortly.  Meanwhile, if you need a copy and can’t pull the MPEG documents yourself, email me.  The IETF’s email system does not allow me to add the .zip file the statement came in, and it’s too big in unzipped format.
Clearly, there is overlap, if not competition, between AVT’s work and what MPEG anticipates, at least for some applications.  I’m also copying fecframe.  While the overlap in this case is less clear, I have reasons to believe that MPEG may touch our interests here as well.  Arguably, there is a similar overlap/competition to the work performed in numerous other SDOs.  
The work appears to be in a very early stage.  They are calling for a workshop during their forthcoming London meeting.  Perhaps some of you are interested in submitting statements or attending the workshop...
Regards,
Stephan
P.s.: I have an opinion about the intentions and plans behind this statement, but it would be impolite to voice it.
--Boundary_(ID_eoYm4PotupYXz5n/jpxQNw)-- From abegen@cisco.com Tue May 5 13:39:13 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 12F2228C275; Tue, 5 May 2009 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 XU6UgHEXPqKM; Tue, 5 May 2009 13:39:10 -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 A641F3A6DC2; Tue, 5 May 2009 13:39:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,299,1238976000"; d="scan'208";a="74791579" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 05 May 2009 20:40:37 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n45KebET015148; Tue, 5 May 2009 13:40:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n45KebTe018640; Tue, 5 May 2009 20:40:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 13:40:37 -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: Tue, 5 May 2009 13:40:13 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093C39D9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 Thread-Index: AcnNwXff8G2zzjlBRrCxdg/CrbxxiAAAA8ig From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 05 May 2009 20:40:37.0538 (UTC) FILETIME=[BF1B2820:01C9CDC1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2046; t=1241556037; x=1242420037; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20=2 0=20=20=20=20=20=20=20=20draft-ietf-fecframe-interleaved-fec -scheme-05=20 |Sender:=20; bh=anoN1MNehcjA7GmaMaiGFfRsRj48aOdKIE1cm8jEaUI=; b=g726bN+HL9DeZ8RFiBS50a5axE/SqMexHap6DvetIp6ukdN3/PnGXn7A0F cfk4bfNP7QNNrqRztgz5AdISoIoFl43fcpCBVQjYAL4CIfpxK/0kGC0IqC1+ EYHWefz4wM; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: avt@ietf.org Subject: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 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, 05 May 2009 20:39:13 -0000 VGhpcyBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIGZyb20gVmluY2VudC4NCg0KTWFyc2hhbGwsIGNv dWxkIHdlIGZpbmFsaXplIFdHTEM/DQoNCkJSLA0KLWFjYmVnZW4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIFttYWlsdG86aWRz dWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFR1ZXNkYXksIE1heSAwNSwgMjAwOSAxOjM3IFBN DQpUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNSAN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1mZWNmcmFtZS1pbnRlcmxlYXZl ZC1mZWMtc2NoZW1lLTA1LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgQWxp IEJlZ2VuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBk cmFmdC1pZXRmLWZlY2ZyYW1lLWludGVybGVhdmVkLWZlYy1zY2hlbWUNClJldmlzaW9uOgkgMDUN ClRpdGxlOgkJIFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgMS1EIEludGVybGVhdmVkIFBhcml0eSBG RUMNCkNyZWF0aW9uX2RhdGU6CSAyMDA5LTA1LTA1DQpXRyBJRDoJCSBmZWNmcmFtZQ0KTnVtYmVy X29mX3BhZ2VzOiAzMQ0KDQpBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBS VFAgcGF5bG9hZCBmb3JtYXQgZm9yIHRoZSBGb3J3YXJkIEVycm9yDQpDb3JyZWN0aW9uIChGRUMp IHRoYXQgaXMgZ2VuZXJhdGVkIGJ5IHRoZSAxLUQgaW50ZXJsZWF2ZWQgcGFyaXR5IGNvZGUNCmZy b20gYSBzb3VyY2UgbWVkaWEgZW5jYXBzdWxhdGVkIGluIFJUUC4gIFRoZSAxLUQgaW50ZXJsZWF2 ZWQgcGFyaXR5DQpjb2RlIGlzIGEgc3lzdGVtYXRpYyBjb2RlLCB3aGVyZSBhIG51bWJlciBvZiBy ZXBhaXIgc3ltYm9scyBhcmUNCmdlbmVyYXRlZCBmcm9tIGEgc2V0IG9mIHNvdXJjZSBzeW1ib2xz IGFuZCBzZW50IGluIGEgcmVwYWlyIGZsb3cNCnNlcGFyYXRlIGZyb20gdGhlIHNvdXJjZSBmbG93 IHRoYXQgY2FycmllcyB0aGUgc291cmNlIHN5bWJvbHMuICBUaGUNCjEtRCBpbnRlcmxlYXZlZCBw YXJpdHkgY29kZSBvZmZlcnMgYSBnb29kIHByb3RlY3Rpb24gYWdhaW5zdCBidXJzdHkNCnBhY2tl dCBsb3NzZXMgYXQgYSBjb3N0IG9mIGRlY2VudCBjb21wbGV4aXR5LiAgVGhlIG5ldyBwYXlsb2Fk IGZvcm1hdA0KZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIHVzZWQgKHdpdGggc29tZSBleGNl cHRpb25zKSBhcyBhIHBhcnQgb2YNCnRoZSBEVkIgQXBwbGljYXRpb24tbGF5ZXIgRkVDIHNwZWNp ZmljYXRpb24uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQuDQoNCg0K From root@core3.amsl.com Tue May 5 13:45: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 A5B8D3A6AFE; Tue, 5 May 2009 13:45: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: <20090505204501.A5B8D3A6AFE@core3.amsl.com> Date: Tue, 5 May 2009 13:45:01 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-interleaved-fec-scheme-05.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : RTP Payload Format for 1-D Interleaved Parity FEC Author(s) : A. Begen Filename : draft-ietf-fecframe-interleaved-fec-scheme-05.txt Pages : 31 Date : 2009-05-05 This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-interleaved-fec-scheme-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-05133710.I-D@ietf.org> --NextPart-- From ron.even.tlv@gmail.com Tue May 5 14:36:39 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 622F53A68FA; Tue, 5 May 2009 14:36:39 -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 JgZ71GAz0477; Tue, 5 May 2009 14:36:38 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 67E7C3A6DD7; Tue, 5 May 2009 14:36:30 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so1678227fge.18 for ; Tue, 05 May 2009 14:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=BMYnm9dhApm3kmDc6IFzdNyhlaki3zRBNdMKpigJw2M=; b=VqGitj5x6t612LsWSsH5cUPh+a1hXc7Ax626khHoK2OTnUMWEL/MN+GTKOlDgEb62E /9valNMkqyoFK3ckG4fBxi4bme+jcdPjDNr8ZEXLRPghITWqoW1eLONxgB7y5cM87Dmm YiIZIc8XjTjlCZCgrePehKrNBut6oe6GmnNqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=w5G8UTz7Uk1AgyyWJZpT+nNQ9ZDpPFxSAKYHq1s+qZvRuB5sI+dvOzDUKpuuknO7Rp GoXD5PibfdbMKDjqQk5TyEBZow3jqtstzc1dOteUI3gI2nOgJLY/YacLLp65Lv7B+pJ+ duqtpSU5ZuR9rlM1O7hAZB5ZTnd4gBLlVmT14= Received: by 10.86.49.16 with SMTP id w16mr633825fgw.4.1241559474745; Tue, 05 May 2009 14:37:54 -0700 (PDT) Received: from windows8d787f9 (bzq-79-180-27-88.red.bezeqint.net [79.180.27.88]) by mx.google.com with ESMTPS id 4sm9221203fge.18.2009.05.05.14.37.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 May 2009 14:37:54 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D54093C39D9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54093C39D9@xmb-sjc-215.amer.cisco.com> Date: Wed, 6 May 2009 00:36:01 +0300 Message-ID: <4a00b1b2.0405560a.2c8d.2f0c@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnNwXff8G2zzjlBRrCxdg/CrbxxiAAAA8igAAHGtiA= Content-Language: en-us Cc: avt@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 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, 05 May 2009 21:36:39 -0000 Ali, Is there a reason to reference RFC 4756 and not reference also draft-ietf-mmusic-source-attributes if ssrc multiplexing is allowed. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Tuesday, May 05, 2009 11:40 PM To: fecframe@ietf.org Cc: avt@ietf.org Subject: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 This addresses the comments from Vincent. Marshall, could we finalize WGLC? BR, -acbegen -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, May 05, 2009 1:37 PM To: Ali C. Begen (abegen) Subject: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-05.txt has been successfuly submitted by Ali Begen and posted to the IETF repository. Filename: draft-ietf-fecframe-interleaved-fec-scheme Revision: 05 Title: RTP Payload Format for 1-D Interleaved Parity FEC Creation_date: 2009-05-05 WG ID: fecframe Number_of_pages: 31 Abstract: This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of decent complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. The IETF Secretariat. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Tue May 5 15:26:43 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 5B30A3A6DD2; Tue, 5 May 2009 15:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 FzLeb2mWO+K5; Tue, 5 May 2009 15:26:42 -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 985243A6E91; Tue, 5 May 2009 15:26:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,299,1238976000"; d="scan'208";a="162163563" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 May 2009 22:27:30 +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 n45MRUtp010289; Tue, 5 May 2009 15:27:30 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n45MRU5r006591; Tue, 5 May 2009 22:27: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.1830); Tue, 5 May 2009 15:27:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 May 2009 15:26:25 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54093C3ADB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4a00b1b2.0405560a.2c8d.2f0c@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 Thread-Index: AcnNwXff8G2zzjlBRrCxdg/CrbxxiAAAA8igAAHGtiAAAddskA== References: <04CAD96D4C5A3D48B1919248A8FE0D54093C39D9@xmb-sjc-215.amer.cisco.com> <4a00b1b2.0405560a.2c8d.2f0c@mx.google.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , X-OriginalArrivalTime: 05 May 2009 22:27:30.0503 (UTC) FILETIME=[AD87F570:01C9CDD0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2813; t=1241562450; x=1242426450; 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[AVT]=20FW=3A=20New=20Version=20Notific ation=20for=09draft-ietf-fecframe-interleaved-fec-scheme-05 |Sender:=20; bh=d9rB6gGHvjBAGNC5sekI6L8o5arDJJ9qdMzrARHThJE=; b=A6cAE4OvU5XPxeijjX71QtQGOqpLXwm/Lfvk5kMZrPX3sWqLNMRLt0IsH6 UoMfCjT8oc93t8zCS/JE+J2AF4C66SL7LPBFNZ73M+C6FO7J0SspBVA0TQu7 6vy7KzXOu3; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: avt@ietf.org Subject: Re: [Fecframe] [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-05 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, 05 May 2009 22:26:43 -0000 I wanted to make a reference 4756 for now. Later, I will change it to = 4756bis if we can move quickly on that draft. This way it will be much = cleaner IMO (the new draft includes both session and ssrc multiplexing = scenarios). So, I'd appreciate if you and others could provide comments for 4756bis. -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Tuesday, May 05, 2009 2:36 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Cc: avt@ietf.org > Subject: RE: [AVT] FW: New Version Notification for = draft-ietf-fecframe-interleaved-fec- > scheme-05 >=20 > Ali, >=20 > Is there a reason to reference RFC 4756 and not reference also > draft-ietf-mmusic-source-attributes if ssrc multiplexing is allowed. >=20 >=20 > Roni >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ali C. > Begen (abegen) > Sent: Tuesday, May 05, 2009 11:40 PM > To: fecframe@ietf.org > Cc: avt@ietf.org > Subject: [AVT] FW: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-05 >=20 > This addresses the comments from Vincent. >=20 > Marshall, could we finalize WGLC? >=20 > BR, > -acbegen >=20 >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, May 05, 2009 1:37 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for > draft-ietf-fecframe-interleaved-fec-scheme-05 >=20 >=20 > A new version of I-D, = draft-ietf-fecframe-interleaved-fec-scheme-05.txt has > been successfuly submitted by Ali Begen and posted to the IETF = repository. >=20 > Filename: draft-ietf-fecframe-interleaved-fec-scheme > Revision: 05 > Title: RTP Payload Format for 1-D Interleaved Parity FEC > Creation_date: 2009-05-05 > WG ID: fecframe > Number_of_pages: 31 >=20 > Abstract: > This document defines a new RTP payload format for the Forward Error > Correction (FEC) that is generated by the 1-D interleaved parity code > from a source media encapsulated in RTP. The 1-D interleaved parity > code is a systematic code, where a number of repair symbols are > generated from a set of source symbols and sent in a repair flow > separate from the source flow that carries the source symbols. The > 1-D interleaved parity code offers a good protection against bursty > packet losses at a cost of decent complexity. The new payload format > defined in this document is used (with some exceptions) as a part of > the DVB Application-layer FEC specification. >=20 >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From watson@qualcomm.com Tue May 5 16:04:16 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5343A6A6F for ; Tue, 5 May 2009 16:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=-1.537, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgPFoCtRTIoM for ; Tue, 5 May 2009 16:04:06 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 6E46E3A687A for ; Tue, 5 May 2009 16:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1241564733; x=1273100733; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20" Ali=20C.=20Begen=20(abegen)"=20,=0D=0A =20=20=20=20=20=20=20=20Mathieu=20Cunche=0D=0A=09|CC:=20"alice.albano@inrialpes.fr" =20,=0D=0A=20=20=20=20=20=20 =20=20"fecframe@ietf.org"=20|Date:=20T ue,=205=20May=202009=2016:05:17=20-0700|Subject:=20Re:=20 [Fecframe]=20Remark=20on=20the=20textual=20representation =20of=20FSSI=20fields|Thread-Topic:=20[Fecframe]=20Remark =20on=20the=20textual=20representation=20of=20FSSI=20fiel ds|Thread-Index:=20AcnJokSIKRDNxVJDTu6vOjdfjR0DWgAD5SmAAQ kG0is=3D|Message-ID:=20|In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D54093490 2C@xmb-sjc-215.amer.cisco.com>|Accept-Language:=20en-US |Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C626143D2CDE6watsonqualcommcom_"|MIME-Version: =201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5606" =3B=20a=3D"17810680"; bh=TfXimH/BkWEr5Q2aPTRHJxWuUM3O59vFrcVihUA1sYw=; b=q/j+iMeYl41Dpsd60vjHDJy+MavvmnA/z4mrKrbbA9Ms5Tpa1R51hM51 7uHK2u4aaOVvsgoZGapRe8iKVnkHoThva4NsmxaIAzOoRVOk7WgnV5V08 jBkCuQ9TQG059CYB3DKkpI3VNGUQbtszyjYZekL8VdhzP/fqTlBEr5JvB g=; X-IronPort-AV: E=McAfee;i="5300,2777,5606"; a="17810680" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2009 16:05:31 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n45N5Ubp007714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 May 2009 16:05:30 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n45N5PR3018301 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 May 2009 16:05:26 -0700 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 5 May 2009 16:05:25 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Tue, 5 May 2009 16:05:24 -0700 From: "Watson, Mark" To: "Ali C. Begen (abegen)" , Mathieu Cunche Date: Tue, 5 May 2009 16:05:17 -0700 Thread-Topic: [Fecframe] Remark on the textual representation of FSSI fields Thread-Index: AcnJokSIKRDNxVJDTu6vOjdfjR0DWgAD5SmAAQkG0is= Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540934902C@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C626143D2CDE6watsonqualcommcom_" MIME-Version: 1.0 Cc: "alice.albano@inrialpes.fr" , "fecframe@ietf.org" Subject: Re: [Fecframe] Remark on the textual representation of FSSI fields 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, 05 May 2009 23:04:17 -0000 --_000_C626143D2CDE6watsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, My understand/recollection is the following: (1) The FSSI and SS-FSSI are octet strings, and the meaning of their conten= ts is defined by the FEC Scheme (2) Any framework-compliant CDP must be able to carry the FSSI and SS-FSSI = intact, without making any assumptions in the CDP about what they might con= tain except that they are octet strings (3) In SDP we would use base64 to represent these octet strings I don't see how we can make these fields "human readable" in SDP without re= quiring every FEC Scheme to define an alternative human readable version of= the FSSI and SS-FSSI. I think we went round this loop before. I agree that (3) needs to be specified in the SDP draft. Btw, with the recent introduction of RTP into the Framework and the associa= ted definition of RTP Payload Formats for each FEC Scheme we decided (in a = discussion late last year, I think), to define RTP Payload Format Parameter= s for the scheme-specific information that would otherwise be in the FSSI a= nd SS-FSSI fields. These are in fact human-readable and are specified in th= e a=3Dfmpt line in SDP rather than by using the a=3Dfec-repair-flow attribu= te. a=3Dfec-repair-flow is only used in the case that the flow is signalle= d as UDP/FEC on the m=3D line rather than RTP/AVP. This too needs to be cla= rified in the SDP draft. ...Mark On 4/30/09 9:44 AM, "Ali C. Begen (abegen)" wrote: Hi Mathieu, Inline. > -----Original Message----- > From: Mathieu Cunche [mailto:mathieu.cunche@inrialpes.fr] > Sent: Thursday, April 30, 2009 7:45 AM > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org; alice.albano@inrialpes.fr > Subject: Re: [Fecframe] Remark on the textual representation > of FSSI fields > > Hi Ali, > > Thanks for the link. To summarize this 2007 discussion, there are > basically two issues: > > - Does the FSSI need to be encoded into human-readable form or not? > > Compactness is not an issue. We agree. > Having a human readable encoding can ease debugging. We agree. > SDP is only one possible way of carrying the FSSI, and we > must not restrict the kind of signaling mechanism. We agree. Yup. > - Where should this encoding be specified? > > Quoting Mark: > "It is the responsibility of the FEC Scheme specification > to define the contents of the Scheme-specific information > and the responsibility of the CDP specification to specify > how it is carried in a protocol." > However, there is no clear conclusion on this point. I will let Mark comment on this one. I agree with the earlier part (definin= g the contens of the SSI). > (Don't hesitate to correct us if we missed/misunderstood something) > > > In any case, the issue must be fixed, since: > - arbitrary binary content (like FSSI) cannot be directly represented > in SDP > - current I-Ds already use different assumptions > - none of them specifies what should be done, worse they contradict > one another Yes, we need to make a decision. > More specifically: > SDP elem =3D> "octet string", without precision, and examples > are provided: ss-fssi=3D1Q2A3Z; fssi=3D4W5S6X > raptor =3D> not specified, but the example: ss-fssi=3D5hu=3D > suggests Base64 is used > > > Concerning point 1, we have several possibilities: > - use base64: its compactness is not an asset in this case, but > it remains simple and well known. > > - use hexadecimal: it's much more user friendly than base64 > encoding, especially with a structured FSSI. > > - use an ASCII encoding of the whole FSSI value: for instance, > with an FSSI composed of two 16bit fields, containing 10 and 8 > respectively, the whole FSSI value is: > 00001010 00001000 (bin) =3D 2568 (dec), encoded as the ASCII > string "fssi=3D2568" > This is a bit tricky however! > > - another ASCII alternative is to carry the ASCII string for each > FSSI internal field, separated by a comma (for instance). > With the above example: "fssi=3D10,8" > Simple, human readable, but no longer opaque and rather tricky! We need input from the WG on this as it will apply to almost all drafts. > One open question: does SDP have any mechanism to specify, within > the SDP file itself, the encoding used for the binary->textual > transformation. Eg., a way to say that what follows is in hexadecimal > or is base64 encoded? If this is permitted, this encoding can be > left unspecified with SDP. In case of another protocol, an explicit > rule can be defined if need be. I'd think this is possible based on the text you cited yesterday, but I am = not sure. > Concerning point 2, our feeling is that the encoding of the FSSI > should be defined in the SDP Element, i.e., where it is used. Agree, I will update the draft once we reach a consensus here. To do that, = we need to hear from FECframe folks. And this discussion is really overdue. BR, -acbegen > > Regards, > > Mathieu, Alice and Vincent > > > > Ali C. Begen (abegen) wrote: > > Hi Mathieu, > > > > Thanks for bringing this up. My feeling is that the FEC > scheme drafts should define the content of the FSSI > information (i.e., what needs to go in there) but they do not > normally need to define how the FSSI should be encoded in the > SDP since FEC schemes may use other ways to convey the > configuration information. However, if a scheme uses RTP, we > clearly need the SDP encodings for that scheme as RTP will > imply using SDP. > > > > For the encoding in SDP, we could use base64 as the default > format. However, this has the disadvantage of not being > human-readable. When we consider RTCP instrumentation in the > middle boxes in the network, the opaque data is not a good > idea, either. Just because it saves some bits won't make it > an ideal encoding format. So, personally I prefer ascii. And > when I look at most other formatting parameters (like the > ones for RTP), they are all ascii. > > > > There are certain semantics that are not scheme specific, > and they should be in ascii format in the SDP (like > a=3Drepair-window) anyway. > > > > We had a similar discussion in 2007. Look at the archives here: > > > http://www.ietf.org/mail-archive/web/fecframe-proto/current/mail7.html > > > > Comments? > > > > -acbegen > > > > > >> -----Original Message----- > >> From: fecframe-bounces@ietf.org > >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Mathieu Cunche > >> Sent: Wednesday, April 29, 2009 5:10 AM > >> To: fecframe@ietf.org > >> Cc: alice.albano@inrialpes.fr > >> Subject: [Fecframe] Remark on the textual representation of > >> FSSI fields > >> > >> Hello everybody, > >> > >> We have a remark on the the way the FSSI (FEC Scheme-Specific > >> Information) and the SS-FSSI (Sender-Side FSSI) binary fields > >> are converted into a character string for SDP. > >> In fact we haven't found any specification in the various > >> FECFRAME I-Ds on the way this conversion should be done. > >> > >> From RFC4566 "Session Description Protocol", p.33: > >> "Encoding considerations: > >> SDP files are primarily UTF-8 format text. The "a=3Dcharset:" > >> attribute may be used to signal the presence of other > >> character sets in certain parts of an SDP file (see > >> Section 6 of RFC 4566 > >> ). Arbitrary > >> binary content cannot be directly represented in SDP." > >> > >> We are typically in the case where we need a textual encoding > >> of the binary SS-FSSI/FSSI "octet string". > >> > >> In the SDP example provided in draft-ietf-fecframe-raptor-00 > >> (section 10) it seems that the encoding used is Base64. However > >> this is never explicitly said (!), neither in this I-D nor in > >> any other I-D (see extracts at the end of the email). > >> ----------- > >> [...] > >> a=3Dfec-repair-flow: scheme-id=3D0; ss-fssi=3D5hu=3D > >> ------------ > >> (BTW: the above SDP description is erroneous, since SS-FSSI > >> is never defined elsewhere in this I-D and on the opposite > >> the FSSI is missing) > >> > >> > >> Base64 seems to be the best solution (more compact than > >> an hexadecimal string). Should this encoding be definitively > >> adopted? And in this case, where should it be specified? > >> > >> Our feeling is that: > >> - it should be clarified in each FEC scheme document (as > >> is the case with RFC 5170/4.2.4.2 (LDPC) and > >> RFC 5510/4.2.4.2 (Reed-Solomon)), when a textual encoding > >> is needed for the "octet string"; > >> > >> - it should be specified in the sdp-elements I-D, section 3.3. > >> as well. > >> > >> Regards, > >> > >> > >> Mathieu, Alice and Vincent > >> > >> NB: here are the I-D extracts that mention SS-FSSI and FSSI: > >> > >> ------------ > >> > >> > >> * SDP Elements for FEC Framework > >> (draft-ietf-fecframe-sdp-elements-02): > >> > >> - page 6: "The variable-length opaque SS-FSSI and FSSI > containers > >> transmit the information in the form of an octet > string. The FEC > >> schemes define the structure of this octet string, which > >> may contain > >> multiple distinct elements." > >> > >> - page 10: " The OPTIONAL parameters 'ss-fssi' and 'fssi' > >> are opaque > >> containers to convey the FEC-Scheme-Specific Information > >> (FSSI) that > >> includes the information that is specific to the FEC > >> scheme used by > >> the CDP and is necessary for proper FEC encoding and decoding > >> operations. The FSSI required only by the sender (called > >> Sender-Side FSSI) MUST be communicated in the container > >> specified by > >> the parameter 'ss-fssi'. Any other FSSI MUST be > >> communicated in the > >> container specified by the parameter 'fssi'. In both > containers, > >> FSSI is transmitted in the form of an octet string. The > >> FEC schemes > >> define the structure of this octet string, which MAY contain > >> multiple distinct elements. If the FEC scheme does not > >> require any > >> specific information, the 'ss-fssi' and 'fssi' > parameters MAY be > >> null and ignored." > >> > >> MC =3D> this text should be fixed since "transmitting the FSSI > >> in the form > >> of an octet string" is not possible. > >> > >> > >> * Methods to convey FEC Framework Configuration Information > >> (draft-ietf-fecframe-config-signaling-01.txt) > >> > >> - page 5: "Additionally, the encoding format for each FEC > >> Framework > >> configuration parameter must be defined in terms of a > sequence of > >> octets that can be embedded within the payload of the signaling > >> protocol message(s). The length of the encoding format > >> MUST either > >> be fixed, or derived by examining the encoded octets > themselves. > >> For example, the initial octets may include some kind of length > >> indication. [...]The reader may refer to the SDP > elements document > >> [FECSDP], which describes the usage of 'SDP' encoding > format as an > >> example encoding format for FEC framework configuration > >> information." > >> > >> MC =3D> with Base64 encoding, there is no need to add any > "initial octet > >> to include a length indication". It's the goal of > the final "=3D" > >> or "=3D=3D" characters. > >> > >> > >> * Raptor FEC Schemes for FECFRAME (draft-ietf-fecframe-raptor-00) > >> > >> - page 8: "The scheme-specific elements of the FEC Framework > >> Configuration information for this scheme are as follows: > >> Maximum Source Block Length A non-negative integer > less than 213, > >> in units of symbols > >> Encoding Symbol Size A non-negative integer less than 216, in > >> units of bytes > >> An encoding format for this information in a 4 octet field is > >> defined as follows: > >> > >> 1 2 > >> 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > >> 5 6 7 8 9 0 1 > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Symbol Size (T) | Max. Source > >> Block Length | > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> Figure 1: FEC Scheme Specific Information > >> > >> MC =3D> the "encoding format" here refers to the binary encoding, not > >> the final encoding to be used when this binary encoding must > >> be carried in SDP or any textual representation. > >> > >> > >> * And of course, we need to fix our Reed-Solomon I-D too... > >> > >> > >> _______________________________________________ > >> 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 --_000_C626143D2CDE6watsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] Remark on the textual representation of FSSI fields</= TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>All,<BR> <BR> My understand/recollection is the following:<BR> <BR> (1) The FSSI and SS-FSSI are octet strings, and the meaning of their conten= ts is defined by the FEC Scheme<BR> (2) Any framework-compliant CDP must be able to carry the FSSI and SS-FSSI = intact, without making any assumptions in the CDP about what they might con= tain except that they are octet strings<BR> (3) In SDP we would use base64 to represent these octet strings<BR> <BR> I don’t see how we can make these fields “human readable”= in SDP without requiring every FEC Scheme to define an alternative human r= eadable version of the FSSI and SS-FSSI. I think we went round this loop be= fore.<BR> <BR> I agree that (3) needs to be specified in the SDP draft.<BR> <BR> Btw, with the recent introduction of RTP into the Framework and the associa= ted definition of RTP Payload Formats for each FEC Scheme we decided (in a = discussion late last year, I think), to define RTP Payload Format Parameter= s for the scheme-specific information that would otherwise be in the FSSI a= nd SS-FSSI fields. These <B>are</B> in fact human-readable and are specifie= d in the a=3Dfmpt line in SDP rather than by using the a=3Dfec-repair-flow = attribute.  a=3Dfec-repair-flow is only used in the case that the flow= is signalled as UDP/FEC on the m=3D line rather than RTP/AVP. This too nee= ds to be clarified in the SDP draft.<BR> <BR> ...Mark<BR> <BR> <BR> On 4/30/09 9:44 AM, "Ali C. Begen (abegen)" <<a href=3D"abegen= @cisco.com">abegen@cisco.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>Hi Mathieu,<BR> <BR> Inline.<BR> <BR> > -----Original Message-----<BR> > From: Mathieu Cunche [<a href=3D"mailto:mathieu.cunche@inrialpes.fr">m= ailto:mathieu.cunche@inrialpes.fr</a>]<BR> > Sent: Thursday, April 30, 2009 7:45 AM<BR> > To: Ali C. Begen (abegen)<BR> > Cc: <a href=3D"fecframe@ietf.org">fecframe@ietf.org</a>; <a href=3D"al= ice.albano@inrialpes.fr">alice.albano@inrialpes.fr</a><BR> > Subject: Re: [Fecframe] Remark on the textual representation<BR> > of FSSI fields<BR> ><BR> > Hi Ali,<BR> ><BR> > Thanks for the link. To summarize this 2007 discussion, there are<BR> > basically two issues:<BR> ><BR> > - Does the FSSI need to be encoded into human-readable form or not?<BR= > ><BR> >       Compactness is not an issue. We ag= ree.<BR> >       Having a human readable encoding c= an ease debugging. We agree.<BR> >       SDP is only one possible way of ca= rrying the FSSI, and we<BR> >       must not restrict the kind of sign= aling mechanism. We agree.<BR> <BR> Yup.<BR> <BR> > - Where should this encoding be specified?<BR> ><BR> >       Quoting Mark:<BR> >       "It is the responsibility of = the FEC Scheme specification<BR> >       to define the contents of the Sche= me-specific information<BR> >       and the responsibility of the CDP = specification to specify<BR> >       how it is carried in a protocol.&q= uot;<BR> >       However, there is no clear conclus= ion on this point.<BR> <BR> I will let Mark comment on this one. I agree with the earlier part (definin= g the contens of the SSI).<BR> <BR> > (Don't hesitate to correct us if we missed/misunderstood something)<BR= > ><BR> ><BR> > In any case, the issue must be fixed, since:<BR> > - arbitrary binary content (like FSSI) cannot be directly represented<= BR> >   in SDP<BR> > - current I-Ds already use different assumptions<BR> > - none of them specifies what should be done, worse they contradict<BR= > >   one another<BR> <BR> Yes, we need to make a decision.<BR> <BR> <BR> > More specifically:<BR> >       SDP elem =3D> "octet strin= g", without precision, and examples<BR> >            &nbs= p;  are provided: ss-fssi=3D1Q2A3Z; fssi=3D4W5S6X<BR> >       raptor =3D> not specified, but = the example: ss-fssi=3D5hu=3D<BR> >            &nbs= p;  suggests Base64 is used<BR> ><BR> ><BR> > Concerning point 1, we have several possibilities:<BR> > - use base64: its compactness is not an asset in this case, but<BR> >   it remains simple and well known.<BR> ><BR> > - use hexadecimal: it's much more user friendly than base64<BR> >   encoding, especially with a structured FSSI.<BR> ><BR> > - use an ASCII encoding of the whole FSSI value: for instance,<BR> >   with an FSSI composed of two 16bit fields, containing 10 a= nd 8<BR> >   respectively, the whole FSSI value is:<BR> >       00001010 00001000 (bin) =3D 2568 (= dec), encoded as the ASCII<BR> >       string "fssi=3D2568"<BR> >   This is a bit tricky however!<BR> ><BR> > - another ASCII alternative is to carry the ASCII string for each<BR> >   FSSI internal field, separated by a comma (for instance).<= BR> >   With the above example: "fssi=3D10,8"<BR> >   Simple, human readable, but no longer opaque and rather tr= icky!<BR> <BR> We need input from the WG on this as it will apply to almost all drafts.<BR= > <BR> <BR> > One open question: does SDP have any mechanism to specify, within<BR> > the SDP file itself, the encoding used for the binary->textual<BR> > transformation. Eg., a way to say that what follows is in hexadecimal<= BR> > or is base64 encoded? If this is permitted, this encoding can be<BR> > left unspecified with SDP. In case of another protocol, an explicit<BR= > > rule can be defined if need be.<BR> <BR> I'd think this is possible based on the text you cited yesterday, but I am = not sure.<BR> <BR> <BR> > Concerning point 2, our feeling is that the encoding of the FSSI<BR> > should be defined in the SDP Element, i.e., where it is used.<BR> <BR> Agree, I will update the draft once we reach a consensus here. To do that, = we need to hear from FECframe folks. And this discussion is really overdue.= <BR> <BR> BR,<BR> -acbegen<BR> <BR> <BR> ><BR> > Regards,<BR> ><BR> >     Mathieu, Alice and Vincent<BR> ><BR> ><BR> ><BR> > Ali C. Begen (abegen) wrote:<BR> > > Hi Mathieu,<BR> > ><BR> > > Thanks for bringing this up. My feeling is that the FEC<BR> > scheme drafts should define the content of the FSSI<BR> > information (i.e., what needs to go in there) but they do not<BR> > normally need to define how the FSSI should be encoded in the<BR> > SDP since FEC schemes may use other ways to convey the<BR> > configuration information. However, if a scheme uses RTP, we<BR> > clearly need the SDP encodings for that scheme as RTP will<BR> > imply using SDP.<BR> > ><BR> > > For the encoding in SDP, we could use base64 as the default<BR> > format. However, this has the disadvantage of not being<BR> > human-readable. When we consider RTCP instrumentation in the<BR> > middle boxes in the network, the opaque data is not a good<BR> > idea, either. Just because it saves some bits won't make it<BR> > an ideal encoding format. So, personally I prefer ascii. And<BR> > when I look at most other formatting parameters (like the<BR> > ones for RTP), they are all ascii.<BR> > ><BR> > > There are certain semantics that are not scheme specific,<BR> > and they should be in ascii format in the SDP (like<BR> > a=3Drepair-window) anyway.<BR> > ><BR> > > We had a similar discussion in 2007. Look at the archives here:<B= R> > ><BR> > <a href=3D"http://www.ietf.org/mail-archive/web/fecframe-proto/current= /mail7.html">http://www.ietf.org/mail-archive/web/fecframe-proto/current/ma= il7.html</a><BR> > ><BR> > > Comments?<BR> > ><BR> > > -acbegen<BR> > ><BR> > >  <BR> > >> -----Original Message-----<BR> > >> From: <a href=3D"fecframe-bounces@ietf.org">fecframe-bounces@= ietf.org</a><BR> > >> [<a href=3D"mailto:fecframe-bounces@ietf.org">mailto:fecframe= -bounces@ietf.org</a>] On Behalf Of Mathieu Cunche<BR> > >> Sent: Wednesday, April 29, 2009 5:10 AM<BR> > >> To: <a href=3D"fecframe@ietf.org">fecframe@ietf.org</a><BR> > >> Cc: <a href=3D"alice.albano@inrialpes.fr">alice.albano@inrial= pes.fr</a><BR> > >> Subject: [Fecframe] Remark on the textual representation of<B= R> > >> FSSI fields<BR> > >><BR> > >> Hello everybody,<BR> > >><BR> > >> We have a remark on the the way the  FSSI (FEC Scheme-Sp= ecific<BR> > >> Information) and the SS-FSSI (Sender-Side FSSI) binary fields= <BR> > >> are converted into a character string for SDP.<BR> > >> In fact we haven't found any specification in the various<BR> > >> FECFRAME I-Ds on the way this conversion should be done.<BR> > >><BR> > >> From RFC4566 "Session Description Protocol", p.33:<= BR> > >>     "Encoding considerations:<BR> > >>     SDP files are primarily UTF-8 format = text. The "a=3Dcharset:"<BR> > >>     attribute may be used to signal the p= resence of other<BR> > >>     character sets in certain parts of an= SDP file (see<BR> > >>     Section 6 of RFC 4566<BR> > >>     <<a href=3D"http://tools.ietf.org/= html/rfc4566#section-6>">http://tools.ietf.org/html/rfc4566#section-6>= ;</a>). Arbitrary<BR> > >>     binary content cannot be directly rep= resented in SDP."<BR> > >><BR> > >> We are typically in the case where we need a textual encoding= <BR> > >> of the binary SS-FSSI/FSSI "octet string".<BR> > >><BR> > >> In the SDP example provided in draft-ietf-fecframe-raptor-00<= BR> > >> (section 10) it seems that the encoding used is Base64. Howev= er<BR> > >> this is never explicitly said (!), neither in this I-D nor in= <BR> > >> any other I-D (see extracts at the end of the email).<BR> > >> -----------<BR> > >>     [...]<BR> > >>     a=3Dfec-repair-flow: scheme-id=3D0; s= s-fssi=3D5hu=3D<BR> > >> ------------<BR> > >> (BTW: the above SDP description is erroneous, since SS-FSSI<B= R> > >>  is never defined elsewhere in this I-D and on the oppos= ite<BR> > >>  the FSSI is missing)<BR> > >><BR> > >><BR> > >> Base64 seems to be the best solution (more compact than<BR> > >> an hexadecimal string). Should this encoding be definitively<= BR> > >> adopted? And in this case, where should it be specified?<BR> > >><BR> > >> Our feeling is that:<BR> > >> - it should be clarified in each FEC scheme document (as<BR> > >>   is the case with RFC 5170/4.2.4.2 (LDPC) and<BR> > >>   RFC 5510/4.2.4.2 (Reed-Solomon)), when a textual = encoding<BR> > >>   is needed for the "octet string";<BR> > >><BR> > >> - it should be specified in the sdp-elements I-D, section 3.3= .<BR> > >>   as well.<BR> > >><BR> > >> Regards,<BR> > >><BR> > >><BR> > >>     Mathieu, Alice and Vincent<BR> > >><BR> > >> NB: here are the I-D extracts that mention SS-FSSI and FSSI:<= BR> > >><BR> > >> ------------<BR> > >><BR> > >><BR> > >> * SDP Elements for FEC Framework<BR> > >> (draft-ietf-fecframe-sdp-elements-02):<BR> > >><BR> > >>     - page 6: "The variable-length o= paque SS-FSSI and FSSI<BR> > containers<BR> > >>     transmit the information in the form = of an octet<BR> > string. The FEC<BR> > >>     schemes define the structure of this = octet string, which<BR> > >> may contain<BR> > >>     multiple distinct elements."<BR> > >><BR> > >>     - page 10: " The OPTIONAL parame= ters 'ss-fssi' and 'fssi'<BR> > >> are opaque<BR> > >>     containers to convey the FEC-Scheme-S= pecific Information<BR> > >> (FSSI) that<BR> > >>     includes the information that is spec= ific to the FEC<BR> > >> scheme used by<BR> > >>     the CDP and is necessary for proper F= EC encoding and decoding<BR> > >>     operations.  The FSSI required o= nly by the sender (called<BR> > >>     Sender-Side FSSI) MUST be communicate= d in the container<BR> > >> specified by<BR> > >>     the parameter 'ss-fssi'. Any other FS= SI MUST be<BR> > >> communicated in the<BR> > >>     container specified by the parameter = 'fssi'.  In both<BR> > containers,<BR> > >>     FSSI is transmitted in the form of an= octet string.  The<BR> > >> FEC schemes<BR> > >>     define the structure of this octet st= ring, which MAY contain<BR> > >>     multiple distinct elements.  If = the FEC scheme does not<BR> > >> require any<BR> > >>     specific information, the 'ss-fssi' a= nd 'fssi'<BR> > parameters MAY be<BR> > >>     null and ignored."<BR> > >><BR> > >> MC =3D> this text should be fixed since "transmitting= the FSSI<BR> > >> in the form<BR> > >>       of an octet string" = is not possible.<BR> > >><BR> > >><BR> > >> * Methods to convey FEC Framework Configuration Information<B= R> > >> (draft-ietf-fecframe-config-signaling-01.txt)<BR> > >><BR> > >>     - page 5: "Additionally, the enc= oding format for each FEC<BR> > >> Framework<BR> > >>     configuration parameter must be defin= ed in terms of a<BR> > sequence of<BR> > >>     octets that can be embedded within th= e payload of the signaling<BR> > >>     protocol message(s).  The length= of the encoding format<BR> > >> MUST either<BR> > >>     be fixed, or derived by examining the= encoded octets<BR> > themselves.<BR> > >>     For example, the initial octets may i= nclude some kind of length<BR> > >>     indication. [...]The reader may refer= to the SDP<BR> > elements document<BR> > >>     [FECSDP], which describes the usage o= f 'SDP' encoding<BR> > format as an<BR> > >>     example encoding format for FEC frame= work configuration<BR> > >> information."<BR> > >><BR> > >> MC =3D> with Base64 encoding, there is no need to add any<= BR> > "initial octet<BR> > >>       to include a length indic= ation". It's the goal of<BR> > the final "=3D"<BR> > >>       or "=3D=3D" cha= racters.<BR> > >><BR> > >><BR> > >> * Raptor FEC Schemes for FECFRAME (draft-ietf-fecframe-raptor= -00)<BR> > >><BR> > >>     - page 8: "The scheme-specific e= lements of the FEC Framework<BR> > >>     Configuration information for this sc= heme are as follows:<BR> > >>     Maximum Source Block Length  A n= on-negative integer<BR> > less than 213,<BR> > >>     in units of symbols<BR> > >>     Encoding Symbol Size  A non-nega= tive integer less than 216, in<BR> > >>     units of bytes<BR> > >>     An encoding format for this informati= on in a 4 octet field is<BR> > >>     defined as follows:<BR> > >><BR> > >>           &= nbsp;           &nbs= p;         1    = ;            &n= bsp;  2        <BR> > >>           3= <BR> > >>           &= nbsp; 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4<BR> > >> 5 6 7 8 9 0 1<BR> > >>           <= BR> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+<BR> > >>           &= nbsp;|       Symbol Size (T)   &nbs= p;     |   Max. Source<BR> > >> Block Length    |<BR> > >>           <= BR> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+<BR> > >><BR> > >>           &= nbsp;          Figure 1: = FEC Scheme Specific Information<BR> > >><BR> > >> MC =3D> the "encoding format" here refers to the= binary encoding, not<BR> > >>       the final encoding to be = used when this binary encoding must<BR> > >>       be carried in SDP or any = textual representation.<BR> > >><BR> > >><BR> > >> * And of course, we need to fix our Reed-Solomon I-D too...<B= R> > >><BR> > >><BR> > >> _______________________________________________<BR> > >> Fecframe mailing list<BR> > >> <a href=3D"Fecframe@ietf.org">Fecframe@ietf.org</a><BR> > >> <a href=3D"https://www.ietf.org/mailman/listinfo/fecframe">ht= tps://www.ietf.org/mailman/listinfo/fecframe</a><BR> > >><BR> > >>    <BR> > ><BR> > ><BR> > >  <BR> ><BR> ><BR> _______________________________________________<BR> Fecframe mailing list<BR> <a href=3D"Fecframe@ietf.org">Fecframe@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/fecframe">https://www.ietf= .org/mailman/listinfo/fecframe</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C626143D2CDE6watsonqualcommcom_-- From tendyntu@huawei.com Tue May 5 23:38:46 2009 Return-Path: <tendyntu@huawei.com> X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E2F3A6B70 for <fecframe@core3.amsl.com>; Tue, 5 May 2009 23:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=1.374, 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 32skxeWmWBql for <fecframe@core3.amsl.com>; Tue, 5 May 2009 23:38:39 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id DCB173A6B0F for <fecframe@ietf.org>; Tue, 5 May 2009 23:38:31 -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 <0KJ700HNGMIJ75@szxga02-in.huawei.com> for fecframe@ietf.org; Wed, 06 May 2009 14:39:56 +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 <0KJ700CDCMIJSY@szxga02-in.huawei.com> for fecframe@ietf.org; Wed, 06 May 2009 14:39:55 +0800 (CST) Received: from z61302 ([10.85.208.250]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ700A2HMIJY5@szxml06-in.huawei.com> for fecframe@ietf.org; Wed, 06 May 2009 14:39:55 +0800 (CST) Date: Wed, 06 May 2009 14:39:55 +0800 From: Zou ZiXuan <tendyntu@huawei.com> In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D54093C3616@xmb-sjc-215.amer.cisco.com> To: fecframe@ietf.org, watson@qualcomm.com Message-id: <00fa01c9ce15$77c712a0$675537e0$@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: AcnMh54PuVolB7i2QEacHsouN7K5vAASgYdQABRa1BAAAn270AA0aXmw References: <008801c9cc87$a1336100$e39a2300$@com> <04CAD96D4C5A3D48B1919248A8FE0D54093C3184@xmb-sjc-215.amer.cisco.com> <00bc01c9cd2a$1d6d6980$58483c80$@com> <04CAD96D4C5A3D48B1919248A8FE0D54093C3616@xmb-sjc-215.amer.cisco.com> Subject: Re: [Fecframe] transmit source payload ID in separate flow X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 May 2009 06:38:46 -0000 Hi Mark, We made some comments in mail list on FEC framework draft (see inline). The comments focus on the case of not having source FEC payload ID in source packet, if the source packet has sequence number. This leads to backward compatibility. But it requires the source FEC packet to be of identical size, which sometime does not practically stand. RTP over NAL+H.264 encoded payload is a good example, where packet size can vary. In this example, for some FEC scheme free of the requirement of fixing packet size, like Raptor, the source FEC payload ID is still needed. But keeping source packet unchanged is still possible. A way to follow is to transmit the source FEC payload IDs in separate packet flows. In order to indicate the position of source packet in a source block, the sequence number of source packet would also be sent along with the source FEC payload ID. For example, we could define a packet format with at least the following content: the sequence number of the very first source packet of a source block, followed by source FEC payload ID of all source packets of the same source block. These metrics collaboratively determines the position of a source packet in a source block. I think we may add some relevant text to the fec framework draft to complement the back-ward compatibility description. We'v submitted a internet-draft to fec framework, disclosing our ideas in greater details, hopefully appears in mail list today or tomorrow. Your comments and opinions will be very appreciated. > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Tuesday, May 05, 2009 10:59 AM > To: Zou ZiXuan; fecframe@ietf.org > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. But > > it does exist under other circumstance like using Raptor code for > > content delivery protection. My question is basically related to the > > description in FEC framework draft related to unchanged source packet. > > It only cover the case of excluding FEC payload ID during protection. I > > think we should add some text in FEC framework draft regarding taking > > FEC payload ID out and transmitting it in separate packets. > > I guess you can propose some text to Mark that explains your motivation and > how to make this work in practice. Whether this approach will be taken or not > by an implementation, it depends, but we can certainly mention it in the > framework draft. > > BR, > -acbegen > > > > > -----Original Message----- > > From: Zou ZiXuan [mailto:tendyntu@huawei.com] > > Sent: Monday, May 04, 2009 7:35 PM > > To: Ali C. Begen (abegen); fecframe@ietf.org > > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > > Hi, Ali, > > Inline > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Tuesday, May 05, 2009 12:07 AM > > > To: Zou ZiXuan; fecframe@ietf.org > > > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > > > > Hi Zou, > > > > > > Inline. > > > > > > > -----Original Message----- > > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] > > On > > > Behalf Of Zou ZiXuan > > > > Sent: Monday, May 04, 2009 12:12 AM > > > > To: fecframe@ietf.org > > > > Subject: [Fecframe] transmit source payload ID in separate flow > > > > > > > > Hi, > > > > > > > > I have a question on the source FEC payload ID, which I > > think > > > belongs to FEC Framework . I > > > > would appreciate for comments on this question. > > > > > > > > > > > > > > > > "Draft-ietf-fecframe-framework-03" and > > > "draft-ietf-fecframe-interleaved-fec-scheme-04" both mentioned > > > > the case where source FEC packet does not carry source FEC payload > > ID > > > for FEC protection. The reason > > > > for not having source FEC payload ID is that the sequence number (if > > exist) > > > can take the source FEC > > > > payload ID's place. This brings backward compatibility to > > FEC-incapable > > > client. RTP was said to be an > > > > > > Yes. > > > > > > > example that can be applied to this case. But this works based on a > > > requirement that the source FEC > > > > packets have to be of identical length, which is not necessarily met > > during > > > FEC protection. RTP packet > > > > length may vary during streaming. So, though there is sequence > > number, > > > sometimes the source FEC > > > > payload ID is still a must. > > > > > > Sure they can vary. And in the interleaved draft, we don't care. There > > is a field > > > in the FEC header, called "Length recovery" which determines the > > length of > > > the recovered packet. > > > > > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. But > > it does exist under other circumstance like using Raptor code for > > content delivery protection. My question is basically related to the > > description in FEC framework draft related to unchanged source packet. > > It only cover the case of excluding FEC payload ID during protection. I > > think we should add some text in FEC framework draft regarding taking > > FEC payload ID out and transmitting it in separate packets. > > > > > > > In such a case, if we still want to have backward compatibility by > > not > > > changing the source packet > > > > format, a possible way to follow is to transmit the source FEC > > payload IDs > > > in separate packets. In > > > > order to indicate the position of source packet in a source block, > > the > > > sequence number of source > > > > packet would also be sent along with the source FEC payload ID. For > > > example, we could define a packet > > > > format with at least the following content: the sequence number of > > the very > > > first source packet of a > > > > source block, followed by source FEC payload ID of all source > > packets of > > > the same source block. These > > > > metrics collaboratively determines the position of a source packet > > in a > > > source block. > > > > > > Keeping the source packets unchanged is of course desirable. However, > > > generating a new flow may bring up other issues, like needing a new > > > multicast group, etc. So, the trade-off must be examined well. > > [ZiXuan] Sharing a session among repair packet flow (or source packet > > flow) and "source FEC payload ID" flow is probably a way to go for your > > concern. For client making a distinguish between two flows, payload type > > multiplexing of some kind is probably needed. A "FEC header" with a PT > > field of different value shall be used for identifying different flows. > > > > > > BR, > > > -acbegen > > > > > > > > > > The comments on the above are welcome. > > > > > > > > > > > > > > > > Best Regards. > > > > > > > > > > > > > > > > Zou ZiXuan, Ph.D, Senior Research Staff > > > > Media & Communication Laboratory > > > > > > > > Corporate Research Department huawei_logo > > > > > > > > > > > > Huawei Industrial Base > > > > Bantian Longgang > > > > Shenzhen 518129, P.R.China > > > > Tel: 86-0755-28789364 > > > > Fax: 86-0755-28567643 > > > > 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! From watson@qualcomm.com Wed May 6 09:05:15 2009 Return-Path: <watson@qualcomm.com> X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D3A3A6DDB for <fecframe@core3.amsl.com>; Wed, 6 May 2009 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.682 X-Spam-Level: X-Spam-Status: No, score=-103.682 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id runZgGfgnFic for <fecframe@core3.amsl.com>; Wed, 6 May 2009 09:04:59 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 361C228C150 for <fecframe@ietf.org>; Wed, 6 May 2009 09:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1241625934; x=1273161934; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20<watson@qualcomm.com>|To:=20Z ou=20ZiXuan=20<tendyntu@huawei.com>,=20"fecframe@ietf.org "=20<fecframe@ietf.org>|Date:=20Wed,=206=20May=202009=200 9:05:19=20-0700|Subject:=20Re:=20[Fecframe]=20transmit=20 source=20payload=20ID=20in=20separate=20flow |Thread-Topic:=20[Fecframe]=20transmit=20source=20payload =20ID=20in=20separate=20flow|Thread-Index:=20AcnMh54PuVol B7i2QEacHsouN7K5vAASgYdQABRa1BAAAn270AA0aXmwABgcK/g=3D |Message-ID:=20<C626FA5A.2CE20%watson@qualcomm.com> |In-Reply-To:=20<00fa01c9ce15$77c712a0$675537e0$@com> |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C626FA5A2CE20watsonqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5607"=3B=20a=3D"17841430"; bh=Dc7khdm+Lt5mC4wrbvvyRncsWpHlsGgjKbRFIcxFxi4=; b=l8V765EcXlyK8kQAIrP7Joli7VFZOpqLD/jFLgSbHlwUzg2RefseiquR ZkiIgxDISL567VpaMzFo+EZGEFsPB1tQ+9AukHSnWyfnaSCh9L0WouR3C ykfRPC6ugiAM/MoXPOizeS4shCfa4pNHV+kj16VCJei5o1cnIre868URq w=; X-IronPort-AV: E=McAfee;i="5300,2777,5607"; a="17841430" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 May 2009 09:05:34 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n46G5YAB030964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 09:05:34 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n46G5L5b013243 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 May 2009 09:05:33 -0700 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 6 May 2009 09:05:21 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Wed, 6 May 2009 09:05:20 -0700 From: "Watson, Mark" <watson@qualcomm.com> To: Zou ZiXuan <tendyntu@huawei.com>, "fecframe@ietf.org" <fecframe@ietf.org> Date: Wed, 6 May 2009 09:05:19 -0700 Thread-Topic: [Fecframe] transmit source payload ID in separate flow Thread-Index: AcnMh54PuVolB7i2QEacHsouN7K5vAASgYdQABRa1BAAAn270AA0aXmwABgcK/g= Message-ID: <C626FA5A.2CE20%watson@qualcomm.com> In-Reply-To: <00fa01c9ce15$77c712a0$675537e0$@com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C626FA5A2CE20watsonqualcommcom_" MIME-Version: 1.0 Subject: Re: [Fecframe] transmit source payload ID in separate flow X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework <fecframe.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/fecframe> List-Post: <mailto:fecframe@ietf.org> List-Help: <mailto:fecframe-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 May 2009 16:05:15 -0000 --_000_C626FA5A2CE20watsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zou, It is not correct that the source packet sizes must be fixed when the Expli= cit Source FEC Payload ID is not used. For example, in draft-fecframe-rapto= r we define an FEC Scheme for a "Single Sequenced Flow" which can handle va= riable source packet sizes and requires only that some kind of sequence num= ber is available in the source packets. As with the interleaved draft, every packet occupies the same amount of spa= ce in the source block for encoding and decoding, so packets shorter than t= his have to be padded with zeros (in the source block). This padding is nev= er sent, but it does mean that to recover a lost source packet an amount of= repair data equal to the maximum packet size is needed, independent of the= size of the actual packet being recovered. You can indeed improve on this by allocating each packet space in the sourc= e block which is closer to the packet's actual size and signalling in some = way the positioning of the packets (either in the Explicit Source FEC Paylo= ad Id, or in another way such as you have proposed). However, simply signalling the full Explicit Source FEC Payload Id for ever= y packet may not be efficient: in the Raptor case, for example, the Explici= t Source FEC Payload Id contains the Source Block Number and the Encoding S= ymbol Id (4 bytes per packet). Since you have the 2-byte sequence number in= every source packet in fact your 'separate flow' signalling needs only the= initial sequence number for the block and one byte more per packet to spec= ify the packet size in symbols. In fact less than one byte may be sufficien= t depending on the symbol size. So, the details should be dependent on the FEC Scheme, just as the contents= of the Explicit Source FEC Payload ID are defined by the FEC Scheme and be= cause the format of the source block itself is defined in the FEC Scheme. F= or this reason I would prefer not to specify this in the Framework, but to = leave it to FEC Schemes to provide such a mechanism if they choose. Of course if there is a generic mechanism that could be reused by multiple = FEC Schemes then this could be published separately. I look forward to seeing your draft - note that you also have to consider h= ow reliability will be provided for the extra signalling packets and IMO yo= u might as well also provide support for combined protection of multiple so= urce flows which is not otherwise available when sequence numbers are used. ...Mark On 5/5/09 11:39 PM, "Zou ZiXuan" <tendyntu@huawei.com> wrote: Hi Mark, We made some comments in mail list on FEC framework draft (see inline). The comments focus on the case of not having source FEC payload ID in source packet, if the source packet has sequence number. This leads to backward compatibility. But it requires the source FEC packet to be of identical size, which sometime does not practically stand. RTP over NAL+H.264 encoded payload is a good example, where packet size can vary. In this example, for some FEC scheme free of the requirement of fixing packet size, like Raptor, the source FEC payload ID is still needed. But keeping source packet unchanged is still possible. A way to follow is to transmit the source FEC payload IDs in separate packet flows. In order to indicate the position of source packet in a source block, the sequence number of source packet would also be sent along with the source FEC payload ID. For example, we could define a packet format with at least the following content: the sequence number of the very first source packet of a source block, followed by source FEC payload ID of all source packets of the same source block. These metrics collaboratively determines the position of a source packet in a source block. I think we may add some relevant text to the fec framework draft to complement the back-ward compatibility description. We'v submitted a internet-draft to fec framework, disclosing our ideas in greater details, hopefully appears in mail list today or tomorrow. Your comments and opinions will be very appreciated. > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Tuesday, May 05, 2009 10:59 AM > To: Zou ZiXuan; fecframe@ietf.org > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. But > > it does exist under other circumstance like using Raptor code for > > content delivery protection. My question is basically related to the > > description in FEC framework draft related to unchanged source packet. > > It only cover the case of excluding FEC payload ID during protection. I > > think we should add some text in FEC framework draft regarding taking > > FEC payload ID out and transmitting it in separate packets. > > I guess you can propose some text to Mark that explains your motivation and > how to make this work in practice. Whether this approach will be taken or not > by an implementation, it depends, but we can certainly mention it in the > framework draft. > > BR, > -acbegen > > > > > -----Original Message----- > > From: Zou ZiXuan [mailto:tendyntu@huawei.com] > > Sent: Monday, May 04, 2009 7:35 PM > > To: Ali C. Begen (abegen); fecframe@ietf.org > > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > > Hi, Ali, > > Inline > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Tuesday, May 05, 2009 12:07 AM > > > To: Zou ZiXuan; fecframe@ietf.org > > > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > > > > Hi Zou, > > > > > > Inline. > > > > > > > -----Original Message----- > > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] > > On > > > Behalf Of Zou ZiXuan > > > > Sent: Monday, May 04, 2009 12:12 AM > > > > To: fecframe@ietf.org > > > > Subject: [Fecframe] transmit source payload ID in separate flow > > > > > > > > Hi, > > > > > > > > I have a question on the source FEC payload ID, which I > > think > > > belongs to FEC Framework . I > > > > would appreciate for comments on this question. > > > > > > > > > > > > > > > > "Draft-ietf-fecframe-framework-03" and > > > "draft-ietf-fecframe-interleaved-fec-scheme-04" both mentioned > > > > the case where source FEC packet does not carry source FEC payload > > ID > > > for FEC protection. The reason > > > > for not having source FEC payload ID is that the sequence number (if > > exist) > > > can take the source FEC > > > > payload ID's place. This brings backward compatibility to > > FEC-incapable > > > client. RTP was said to be an > > > > > > Yes. > > > > > > > example that can be applied to this case. But this works based on a > > > requirement that the source FEC > > > > packets have to be of identical length, which is not necessarily met > > during > > > FEC protection. RTP packet > > > > length may vary during streaming. So, though there is sequence > > number, > > > sometimes the source FEC > > > > payload ID is still a must. > > > > > > Sure they can vary. And in the interleaved draft, we don't care. There > > is a field > > > in the FEC header, called "Length recovery" which determines the > > length of > > > the recovered packet. > > > > > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. But > > it does exist under other circumstance like using Raptor code for > > content delivery protection. My question is basically related to the > > description in FEC framework draft related to unchanged source packet. > > It only cover the case of excluding FEC payload ID during protection. I > > think we should add some text in FEC framework draft regarding taking > > FEC payload ID out and transmitting it in separate packets. > > > > > > > In such a case, if we still want to have backward compatibility by > > not > > > changing the source packet > > > > format, a possible way to follow is to transmit the source FEC > > payload IDs > > > in separate packets. In > > > > order to indicate the position of source packet in a source block, > > the > > > sequence number of source > > > > packet would also be sent along with the source FEC payload ID. For > > > example, we could define a packet > > > > format with at least the following content: the sequence number of > > the very > > > first source packet of a > > > > source block, followed by source FEC payload ID of all source > > packets of > > > the same source block. These > > > > metrics collaboratively determines the position of a source packet > > in a > > > source block. > > > > > > Keeping the source packets unchanged is of course desirable. However, > > > generating a new flow may bring up other issues, like needing a new > > > multicast group, etc. So, the trade-off must be examined well. > > [ZiXuan] Sharing a session among repair packet flow (or source packet > > flow) and "source FEC payload ID" flow is probably a way to go for your > > concern. For client making a distinguish between two flows, payload type > > multiplexing of some kind is probably needed. A "FEC header" with a PT > > field of different value shall be used for identifying different flows. > > > > > > BR, > > > -acbegen > > > > > > > > > > The comments on the above are welcome. > > > > > > > > > > > > > > > > Best Regards. > > > > > > > > > > > > > > > > Zou ZiXuan, Ph.D, Senior Research Staff > > > > Media & Communication Laboratory > > > > > > > > Corporate Research Department huawei_logo > > > > > > > > > > > > Huawei Industrial Base > > > > Bantian Longgang > > > > Shenzhen 518129, P.R.China > > > > Tel: 86-0755-28789364 > > > > Fax: 86-0755-28567643 > > > > 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! --_000_C626FA5A2CE20watsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [Fecframe] transmit source payload ID in separate flow Hi Zou,

It is not correct that the source packet sizes must be fixed when the Expli= cit Source FEC Payload ID is not used. For example, in draft-fecframe-rapto= r we define an FEC Scheme for a “Single Sequenced Flow” which c= an handle variable source packet sizes and requires only that some kind of = sequence number is available in the source packets.

As with the interleaved draft, every packet occupies the same amount of spa= ce in the source block for encoding and decoding, so packets shorter than t= his have to be padded with zeros (in the source block). This padding is nev= er sent, but it does mean that to recover a lost source packet an amount of= repair data equal to the maximum packet size is needed, independent of the= size of the actual packet being recovered.

You can indeed improve on this by allocating each packet space in the sourc= e block which is closer to the packet’s actual size and signalling in= some way the positioning of the packets (either in the Explicit Source FEC= Payload Id, or in another way such as you have proposed).

However, simply signalling the full Explicit Source FEC Payload Id for ever= y packet may not be efficient: in the Raptor case, for example, the Explici= t Source FEC Payload Id contains the Source Block Number and the Encoding S= ymbol Id (4 bytes per packet). Since you have the 2-byte sequence number in= every source packet in fact your ‘separate flow’ signalling ne= eds only the initial sequence number for the block and one byte more per pa= cket to specify the packet size in symbols. In fact less than one byte may = be sufficient depending on the symbol size.

So, the details should be dependent on the FEC Scheme, just as the contents= of the Explicit Source FEC Payload ID are defined by the FEC Scheme and be= cause the format of the source block itself is defined in the FEC Scheme. F= or this reason I would prefer not to specify this in the Framework, but to = leave it to FEC Schemes to provide such a mechanism if they choose.

Of course if there is a generic mechanism that could be reused by multiple = FEC Schemes then this could be published separately.

I look forward to seeing your draft – note that you also have to cons= ider how reliability will be provided for the extra signalling packets and = IMO you might as well also provide support for combined protection of multi= ple source flows which is not otherwise available when sequence numbers are= used.

...Mark




On 5/5/09 11:39 PM, "Zou ZiXuan" <tendyntu@huawei.com> wrote:

Hi Mark,
        We made some comments in ma= il list on FEC framework draft (see
inline). The comments focus on the case of not having source FEC payload ID in source packet, if the source packet has sequence number. This
leads to backward compatibility. But it requires the source FEC packet
to be of identical size, which sometime does not practically stand. RTP
over NAL+H.264 encoded payload is a good example, where packet size can
vary. In this example, for some FEC scheme free of the requirement of
fixing packet size, like Raptor, the source FEC payload ID is still
needed. But keeping source packet unchanged is still possible. A way to
follow is to transmit the source FEC payload IDs in separate packet
flows. In order to indicate the position of source packet in a source
block, the sequence number of source packet would also be sent along
with the source FEC payload ID. For example, we could define a packet
format with at least the following content: the sequence number of the
very first source packet of a source block, followed by source FEC
payload ID of all source packets of the same source block. These metrics collaboratively determines the position of a source packet in a source
block. I think we may add some relevant text to the fec framework draft
to complement the back-ward compatibility description.

We'v submitted a internet-draft to fec framework, disclosing our ideas
in greater details, hopefully appears in mail list today or tomorrow.
Your comments and opinions will be very appreciated.


> -----Original Message-----
> From: Ali C. Begen (abegen) [mailt= o:abegen@cisco.com]
> Sent: Tuesday, May 05, 2009 10:59 AM
> To: Zou ZiXuan; fecframe@ietf.org > Subject: RE: [Fecframe] transmit source payload ID in separate flow >
> > [ZiXuan] Agree, it's indeed not a problem in the interleaved draf= t.
But
> > it does exist under other circumstance like using Raptor code for=
> > content delivery protection. My question is basically related to = the
> > description in FEC framework draft related to unchanged source packet.
> > It only cover the case of excluding FEC payload ID during
protection. I
> > think we should add some text in FEC framework draft regarding taking
> > FEC payload ID out and transmitting it in separate packets.
>
> I guess you can propose some text to Mark that explains your
motivation and
> how to make this work in practice. Whether this approach will be taken=
or not
> by an implementation, it depends, but we can certainly mention it in the
> framework draft.
>
> BR,
> -acbegen
>
>
>
> > -----Original Message-----
> > From: Zou ZiXuan [mailto:t= endyntu@huawei.com]
> > Sent: Monday, May 04, 2009 7:35 PM
> > To: Ali C. Begen (abegen); fecframe= @ietf.org
> > Subject: RE: [Fecframe] transmit source payload ID in separate fl= ow
> >
> > Hi, Ali,
> >     Inline
> >
> > > -----Original Message-----
> > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
> > > Sent: Tuesday, May 05, 2009 12:07 AM
> > > To: Zou ZiXuan; fecframe@ietf.= org
> > > Subject: RE: [Fecframe] transmit source payload ID in separa= te
flow
> > >
> > > Hi Zou,
> > >
> > > Inline.
> > >
> > > > -----Original Message-----
> > > > From: fecframe-bo= unces@ietf.org
[mailto:fecframe-bounces@ietf.= org]
> > On
> > > Behalf Of Zou ZiXuan
> > > > Sent: Monday, May 04, 2009 12:12 AM
> > > > To: fecframe@ietf.org=
> > > > Subject: [Fecframe] transmit source payload ID in separ= ate flow
> > > >
> > > > Hi,
> > > >
> > > >          I= have a question on the source FEC payload ID, which I
> > think
> > > belongs to FEC Framework . I
> > > > would appreciate for comments on this question.
> > > >
> > > >
> > > >
> > > > "Draft-ietf-fecframe-framework-03" and
> > > "draft-ietf-fecframe-interleaved-fec-scheme-04" bo= th mentioned
> > > > the case where source FEC packet does not carry source = FEC
payload
> > ID
> > > for FEC protection. The reason
> > > > for not having source FEC payload ID is that the sequen= ce number
(if
> > exist)
> > > can take the source FEC
> > > > payload ID's place. This brings backward compatibility = to
> > FEC-incapable
> > > client. RTP was said to be an
> > >
> > > Yes.
> > >
> > > > example that can be applied to this case. But this work= s based
on a
> > > requirement that the source FEC
> > > > packets have to be of identical length, which is not ne= cessarily
met
> > during
> > > FEC protection. RTP packet
> > > > length may vary during streaming. So, though there is s= equence
> > number,
> > > sometimes the source FEC
> > > > payload ID is still a must.
> > >
> > > Sure they can vary. And in the interleaved draft, we don't c= are.
There
> > is a field
> > > in the FEC header, called "Length recovery" which = determines the
> > length of
> > > the recovered packet.
> > >
> > [ZiXuan] Agree, it's indeed not a problem in the interleaved draf= t.
But
> > it does exist under other circumstance like using Raptor code for=
> > content delivery protection. My question is basically related to = the
> > description in FEC framework draft related to unchanged source packet.
> > It only cover the case of excluding FEC payload ID during
protection. I
> > think we should add some text in FEC framework draft regarding taking
> > FEC payload ID out and transmitting it in separate packets.
> > >
> > > > In such a case, if we still want to have backward compa= tibility
by
> > not
> > > changing the source packet
> > > > format, a possible way to follow is to transmit the sou= rce FEC
> > payload IDs
> > > in separate packets. In
> > > > order to indicate the position of source packet in a so= urce
block,
> > the
> > > sequence number of source
> > > > packet would also be sent along with the source FEC pay= load ID.
For
> > > example, we could define a packet
> > > > format with at least the following content: the sequenc= e number
of
> > the very
> > > first source packet of a
> > > > source block, followed by source FEC payload ID of all = source
> > packets of
> > > the same source block. These
> > > > metrics collaboratively determines the position of a so= urce
packet
> > in a
> > > source block.
> > >
> > > Keeping the source packets unchanged is of course desirable.=
However,
> > > generating a new flow may bring up other issues, like needin= g a
new
> > > multicast group, etc. So, the trade-off must be examined wel= l.
> > [ZiXuan] Sharing a session among repair packet flow (or source packet
> > flow) and "source FEC payload ID" flow is probably a wa= y to go for
your
> > concern. For client making a distinguish between two flows, paylo= ad
type
> > multiplexing of some kind is probably needed. A "FEC header&= quot; with a
PT
> > field of different value shall be used for identifying different<= BR> flows.
> > >
> > > BR,
> > > -acbegen
> > >
> > >
> > > > The comments on the above are welcome.
> > > >
> > > >
> > > >
> > > > Best Regards.
> > > >
> > > >
> > > >
> > > > Zou ZiXuan, Ph.D, Senior Research Staff
> > > > Media & Communication Laboratory
> > > >
> > > > Corporate Research Department huawei_logo
> > > >
> > > >
> > > > Huawei Industrial Base
> > > > Bantian Longgang
> > > > Shenzhen 518129, P.R.China
> > > > Tel: 86-0755-28789364
> > > > Fax: 86-0755-28567643
> > > > E-mail: tendyntu@huawei= .com
> > > > www.huawei.com
> > > >
> >
------------------------------------------------------------------------ > > ------------------------------
> > > > -------------------------------
> > > > This e-mail and its attachments contain confidential in= formation
> > 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!


--_000_C626FA5A2CE20watsonqualcommcom_-- From tendyntu@huawei.com Thu May 7 02:56:28 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 B19A23A6DB0 for ; Thu, 7 May 2009 02:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.361 X-Spam-Level: *** X-Spam-Status: No, score=3.361 tagged_above=-999 required=5 tests=[AWL=-3.440, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345] 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 z2q3VfLwFbJr for ; Thu, 7 May 2009 02:56:26 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id ECB083A6CA8 for ; Thu, 7 May 2009 02:56:25 -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 <0KJ900EUZQC6EY@szxga01-in.huawei.com> for fecframe@ietf.org; Thu, 07 May 2009 17:57:43 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ900DLMQC67R@szxga01-in.huawei.com> for fecframe@ietf.org; Thu, 07 May 2009 17:57:42 +0800 (CST) Received: from z61302 ([10.85.208.186]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ900KEHQC322@szxml06-in.huawei.com> for fecframe@ietf.org; Thu, 07 May 2009 17:57:42 +0800 (CST) Date: Thu, 07 May 2009 17:57:39 +0800 From: zouzixuan 61302 In-reply-to: To: "'Watson, Mark'" , fecframe@ietf.org Message-id: <05ec01c9cefa$41d14770$c573d650$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WaV6vYY1/yGSlDbxAq7ODw)" Content-language: zh-cn Thread-index: AcnMh54PuVolB7i2QEacHsouN7K5vAASgYdQABRa1BAAAn270AA0aXmwABgcK/gAJsErIA== References: <00fa01c9ce15$77c712a0$675537e0$@com> Subject: [Fecframe] =?gb2312?b?tPC4tDogIHRyYW5zbWl0IHNvdXJjZSBwYXlsb2Fk?= =?gb2312?b?IElEIGluIHNlcGFyYXRlIGZsb3c=?= 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, 07 May 2009 09:56:28 -0000 һ MIME ʽĶಿʼ --Boundary_(ID_WaV6vYY1/yGSlDbxAq7ODw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, Mark Inline Hi Zou, It is not correct that the source packet sizes must be fixed when the Explicit Source FEC Payload ID is not used. For example, in draft-fecframe-raptor we define an FEC Scheme for a =A1=B0Single = Sequenced Flow=A1=B1 which can handle variable source packet sizes and requires = only that some kind of sequence number is available in the source packets. As with the interleaved draft, every packet occupies the same amount of space in the source block for encoding and decoding, so packets shorter = than this have to be padded with zeros (in the source block). This padding is never sent, =20 but it does mean that to recover a lost source packet an amount of = repair data equal to the maximum packet size is needed, independent of the size = of the actual packet being recovered. Agree.=20 You can indeed improve on this by allocating each packet space in the = source block which is closer to the packet=A1=AFs actual size and signalling in = some way the positioning of the packets (either in the Explicit Source FEC Payload Id, or in another way such as you have proposed). However, simply signalling the full Explicit Source FEC Payload Id for = every packet may not be efficient: in the Raptor case, for example, the = Explicit Source FEC Payload Id contains the Source Block Number and the Encoding Symbol Id (4 bytes per packet). Since you have the 2-byte sequence = number in every source packet in fact your =A1=AEseparate flow=A1=AF signalling = needs only the initial sequence number for the block and one byte more per packet to specify the packet size in symbols. In fact less than one byte may be sufficient depending on the symbol size. This is exactly a good idea. In fact, we disclosed a similar solution in = the draft, which is called =A1=B0source FEC Payload MIU=A1=B1 , which has = =A1=B0initial sequence number=A1=B1 field for the same purpose.=20 =20 So, the details should be dependent on the FEC Scheme, just as the = contents of the Explicit Source FEC Payload ID are defined by the FEC Scheme and because the format of the source block itself is defined in the FEC = Scheme. For this reason I would prefer not to specify this in the Framework, but = to leave it to FEC Schemes to provide such a mechanism if they choose. =20 Of course if there is a generic mechanism that could be reused by = multiple FEC Schemes then this could be published separately. We=A1=AFv taken this concern into account by defining a =A1=B0FEC header = format=A1=B1, Please see the draft. I look forward to seeing your draft =A8C note that you also have to = consider how reliability will be provided for the extra signalling packets and=20 =20 IMO you might as well also provide support for combined protection of multiple source flows which is not otherwise available when sequence = numbers are used. Yes, we=A1=AFv had a solution for supporting multiple source flows = protection, see the draft enclosed. Please see the draft. =20 =20 On 5/5/09 11:39 PM, "Zou ZiXuan" wrote: Hi Mark, We made some comments in mail list on FEC framework draft (see inline). The comments focus on the case of not having source FEC payload ID in source packet, if the source packet has sequence number. This leads to backward compatibility. But it requires the source FEC packet to be of identical size, which sometime does not practically stand. RTP over NAL+H.264 encoded payload is a good example, where packet size can vary. In this example, for some FEC scheme free of the requirement of fixing packet size, like Raptor, the source FEC payload ID is still needed. But keeping source packet unchanged is still possible. A way to follow is to transmit the source FEC payload IDs in separate packet flows. In order to indicate the position of source packet in a source block, the sequence number of source packet would also be sent along with the source FEC payload ID. For example, we could define a packet format with at least the following content: the sequence number of the very first source packet of a source block, followed by source FEC payload ID of all source packets of the same source block. These metrics collaboratively determines the position of a source packet in a source block. I think we may add some relevant text to the fec framework draft to complement the back-ward compatibility description. We'v submitted a internet-draft to fec framework, disclosing our ideas in greater details, hopefully appears in mail list today or tomorrow. Your comments and opinions will be very appreciated. > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Tuesday, May 05, 2009 10:59 AM > To: Zou ZiXuan; fecframe@ietf.org > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. But > > it does exist under other circumstance like using Raptor code for > > content delivery protection. My question is basically related to the > > description in FEC framework draft related to unchanged source packet. > > It only cover the case of excluding FEC payload ID during protection. I > > think we should add some text in FEC framework draft regarding taking > > FEC payload ID out and transmitting it in separate packets. > > I guess you can propose some text to Mark that explains your motivation and > how to make this work in practice. Whether this approach will be taken or not > by an implementation, it depends, but we can certainly mention it in the > framework draft. > > BR, > -acbegen > > > > > -----Original Message----- > > From: Zou ZiXuan [mailto:tendyntu@huawei.com] > > Sent: Monday, May 04, 2009 7:35 PM > > To: Ali C. Begen (abegen); fecframe@ietf.org > > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > > Hi, Ali, > > Inline > > > > > -----Original Message----- > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > > Sent: Tuesday, May 05, 2009 12:07 AM > > > To: Zou ZiXuan; fecframe@ietf.org > > > Subject: RE: [Fecframe] transmit source payload ID in separate flow > > > > > > Hi Zou, > > > > > > Inline. > > > > > > > -----Original Message----- > > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] > > On > > > Behalf Of Zou ZiXuan > > > > Sent: Monday, May 04, 2009 12:12 AM > > > > To: fecframe@ietf.org > > > > Subject: [Fecframe] transmit source payload ID in separate flow > > > > > > > > Hi, > > > > > > > > I have a question on the source FEC payload ID, which I > > think > > > belongs to FEC Framework . I > > > > would appreciate for comments on this question. > > > > > > > > > > > > > > > > "Draft-ietf-fecframe-framework-03" and > > > "draft-ietf-fecframe-interleaved-fec-scheme-04" both mentioned > > > > the case where source FEC packet does not carry source FEC payload > > ID > > > for FEC protection. The reason > > > > for not having source FEC payload ID is that the sequence number (if > > exist) > > > can take the source FEC > > > > payload ID's place. This brings backward compatibility to > > FEC-incapable > > > client. RTP was said to be an > > > > > > Yes. > > > > > > > example that can be applied to this case. But this works based on a > > > requirement that the source FEC > > > > packets have to be of identical length, which is not necessarily met > > during > > > FEC protection. RTP packet > > > > length may vary during streaming. So, though there is sequence > > number, > > > sometimes the source FEC > > > > payload ID is still a must. > > > > > > Sure they can vary. And in the interleaved draft, we don't care. There > > is a field > > > in the FEC header, called "Length recovery" which determines the > > length of > > > the recovered packet. > > > > > [ZiXuan] Agree, it's indeed not a problem in the interleaved draft. But > > it does exist under other circumstance like using Raptor code for > > content delivery protection. My question is basically related to the > > description in FEC framework draft related to unchanged source packet. > > It only cover the case of excluding FEC payload ID during protection. I > > think we should add some text in FEC framework draft regarding taking > > FEC payload ID out and transmitting it in separate packets. > > > > > > > In such a case, if we still want to have backward compatibility by > > not > > > changing the source packet > > > > format, a possible way to follow is to transmit the source FEC > > payload IDs > > > in separate packets. In > > > > order to indicate the position of source packet in a source block, > > the > > > sequence number of source > > > > packet would also be sent along with the source FEC payload ID. For > > > example, we could define a packet > > > > format with at least the following content: the sequence number of > > the very > > > first source packet of a > > > > source block, followed by source FEC payload ID of all source > > packets of > > > the same source block. These > > > > metrics collaboratively determines the position of a source packet > > in a > > > source block. > > > > > > Keeping the source packets unchanged is of course desirable. However, > > > generating a new flow may bring up other issues, like needing a new > > > multicast group, etc. So, the trade-off must be examined well. > > [ZiXuan] Sharing a session among repair packet flow (or source packet > > flow) and "source FEC payload ID" flow is probably a way to go for your > > concern. For client making a distinguish between two flows, payload type > > multiplexing of some kind is probably needed. A "FEC header" with a PT > > field of different value shall be used for identifying different flows. > > > > > > BR, > > > -acbegen > > > > > > > > > > The comments on the above are welcome. > > > > > > > > > > > > > > > > Best Regards. > > > > > > > > > > > > > > > > Zou ZiXuan, Ph.D, Senior Research Staff > > > > Media & Communication Laboratory > > > > > > > > Corporate Research Department huawei_logo > > > > > > > > > > > > Huawei Industrial Base > > > > Bantian Longgang > > > > Shenzhen 518129, P.R.China > > > > Tel: 86-0755-28789364 > > > > Fax: 86-0755-28567643 > > > > 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! --Boundary_(ID_WaV6vYY1/yGSlDbxAq7ODw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Re: [Fecframe] transmit source payload ID in separate = flow

Hi, = Mark

Inline=

Hi = Zou,

=


It is not correct that the source packet sizes must be fixed when the = Explicit Source FEC Payload ID is not used. For example, in draft-fecframe-raptor = we define an FEC Scheme for a =A1=B0Single Sequenced Flow=A1=B1 which can = handle variable source packet sizes and requires only that some kind of sequence number = is available in the source packets.

As with the interleaved draft, every packet occupies the same amount of = space in the source block for encoding and decoding, so packets shorter than = this have to be padded with zeros (in the source block). This padding is = never sent,

 

 but = it does mean that to recover a lost source packet an amount of repair data equal to = the maximum packet size is needed, independent of the size of the actual = packet being recovered.

Agree.



You can indeed improve on this by allocating each packet space in the = source block which is closer to the packet=A1=AFs actual size and signalling in = some way the positioning of the packets (either in the Explicit Source FEC = Payload Id, or in another way such as you have proposed).



However, simply signalling the full Explicit Source FEC Payload Id for = every packet may not be efficient: in the Raptor case, for example, the = Explicit Source FEC Payload Id contains the Source Block Number and the Encoding = Symbol Id (4 bytes per packet). Since you have the 2-byte sequence number in every = source packet in fact your =A1=AEseparate flow=A1=AF signalling needs only the = initial sequence number for the block and one byte more per packet to specify the packet = size in symbols. In fact less than one byte may be sufficient depending on the = symbol size.
This is exactly a good idea. In fact, we disclosed a = similar solution in the draft, which is called =A1=B0source FEC Payload = MIU=A1=B1 , which has =A1=B0initial sequence number=A1=B1 field for the same purpose.

 


So, the details should be dependent on the FEC Scheme, just as the = contents of the Explicit Source FEC Payload ID are defined by the FEC Scheme and = because the format of the source block itself is defined in the FEC Scheme. For = this reason I would prefer not to specify this in the Framework, but to leave = it to FEC Schemes to provide such a mechanism if they choose.

 

Of course = if there is a generic mechanism that could be reused by multiple FEC Schemes then = this could be published separately.

We=A1=AFv taken this concern into account by defining a =A1=B0FEC header = format=A1=B1, Please see the draft.

I look forward to seeing your draft =A8C note that you also have to = consider how reliability will be provided for the extra signalling packets and =

 

IMO you = might as well also provide support for combined protection of multiple source = flows which is not otherwise available when sequence numbers are = used.

Yes, we=A1=AFv had a solution for supporting multiple source flows = protection, see the draft enclosed. Please see the draft.

 

 




On 5/5/09 11:39 PM, "Zou ZiXuan" <tendyntu@huawei.com> wrote:

Hi = Mark,
        We made some comments in = mail list on FEC framework draft (see
inline). The comments focus on the case of not having source FEC = payload
ID in source packet, if the source packet has sequence number. This
leads to backward compatibility. But it requires the source FEC = packet
to be of identical size, which sometime does not practically stand. = RTP
over NAL+H.264 encoded payload is a good example, where packet size = can
vary. In this example, for some FEC scheme free of the requirement = of
fixing packet size, like Raptor, the source FEC payload ID is still
needed. But keeping source packet unchanged is still possible. A way = to
follow is to transmit the source FEC payload IDs in separate packet
flows. In order to indicate the position of source packet in a = source
block, the sequence number of source packet would also be sent along
with the source FEC payload ID. For example, we could define a = packet
format with at least the following content: the sequence number of = the
very first source packet of a source block, followed by source FEC
payload ID of all source packets of the same source block. These = metrics
collaboratively determines the position of a source packet in a = source
block. I think we may add some relevant text to the fec framework = draft
to complement the back-ward compatibility description.

We'v submitted a internet-draft to fec framework, disclosing our = ideas
in greater details, hopefully appears in mail list today or = tomorrow.
Your comments and opinions will be very appreciated.


> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
> Sent: Tuesday, May 05, 2009 10:59 AM
> To: Zou ZiXuan; fecframe@ietf.org
> Subject: RE: [Fecframe] transmit source payload ID in separate = flow
>
> > [ZiXuan] Agree, it's indeed not a problem in the interleaved = draft.
But
> > it does exist under other circumstance like using Raptor code = for
> > content delivery protection. My question is basically related = to the
> > description in FEC framework draft related to unchanged = source
packet.
> > It only cover the case of excluding FEC payload ID during
protection. I
> > think we should add some text in FEC framework draft = regarding
taking
> > FEC payload ID out and transmitting it in separate = packets.
>
> I guess you can propose some text to Mark that explains your
motivation and
> how to make this work in practice. Whether this approach will be = taken
or not
> by an implementation, it depends, but we can certainly mention it = in
the
> framework draft.
>
> BR,
> -acbegen
>
>
>
> > -----Original Message-----
> > From: Zou ZiXuan [mailto:tendyntu@huawei.com]
> > Sent: Monday, May 04, 2009 7:35 PM
> > To: Ali C. Begen (abegen); fecframe@ietf.org
> > Subject: RE: [Fecframe] transmit source payload ID in separate = flow
> >
> > Hi, Ali,
> >     Inline
> >
> > > -----Original Message-----
> > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
> > > Sent: Tuesday, May 05, 2009 12:07 AM
> > > To: Zou ZiXuan; fecframe@ietf.org
> > > Subject: RE: [Fecframe] transmit source payload ID in = separate
flow
> > >
> > > Hi Zou,
> > >
> > > Inline.
> > >
> > > > -----Original Message-----
> > > > From: fecframe-bounces@ietf.org
[mailto:fecframe-bounces@ietf.or= g]
> > On
> > > Behalf Of Zou ZiXuan
> > > > Sent: Monday, May 04, 2009 12:12 AM
> > > > To: fecframe@ietf.org
> > > > Subject: [Fecframe] transmit source payload ID in = separate flow
> > > >
> > > > Hi,
> > > >
> > > > =          I have a question on the source FEC payload ID, which I
> > think
> > > belongs to FEC Framework . I
> > > > would appreciate for comments on this question.
> > > >
> > > >
> > > >
> > > > "Draft-ietf-fecframe-framework-03" and
> > > "draft-ietf-fecframe-interleaved-fec-scheme-04" = both mentioned
> > > > the case where source FEC packet does not carry = source FEC
payload
> > ID
> > > for FEC protection. The reason
> > > > for not having source FEC payload ID is that the = sequence number
(if
> > exist)
> > > can take the source FEC
> > > > payload ID's place. This brings backward = compatibility to
> > FEC-incapable
> > > client. RTP was said to be an
> > >
> > > Yes.
> > >
> > > > example that can be applied to this case. But this = works based
on a
> > > requirement that the source FEC
> > > > packets have to be of identical length, which is not necessarily
met
> > during
> > > FEC protection. RTP packet
> > > > length may vary during streaming. So, though there = is sequence
> > number,
> > > sometimes the source FEC
> > > > payload ID is still a must.
> > >
> > > Sure they can vary. And in the interleaved draft, we = don't care.
There
> > is a field
> > > in the FEC header, called "Length recovery" = which determines the
> > length of
> > > the recovered packet.
> > >
> > [ZiXuan] Agree, it's indeed not a problem in the interleaved = draft.
But
> > it does exist under other circumstance like using Raptor code = for
> > content delivery protection. My question is basically related = to the
> > description in FEC framework draft related to unchanged = source
packet.
> > It only cover the case of excluding FEC payload ID during
protection. I
> > think we should add some text in FEC framework draft = regarding
taking
> > FEC payload ID out and transmitting it in separate = packets.
> > >
> > > > In such a case, if we still want to have backward compatibility
by
> > not
> > > changing the source packet
> > > > format, a possible way to follow is to transmit the = source FEC
> > payload IDs
> > > in separate packets. In
> > > > order to indicate the position of source packet in a = source
block,
> > the
> > > sequence number of source
> > > > packet would also be sent along with the source FEC = payload ID.
For
> > > example, we could define a packet
> > > > format with at least the following content: the = sequence number
of
> > the very
> > > first source packet of a
> > > > source block, followed by source FEC payload ID of = all source
> > packets of
> > > the same source block. These
> > > > metrics collaboratively determines the position of a = source
packet
> > in a
> > > source block.
> > >
> > > Keeping the source packets unchanged is of course = desirable.
However,
> > > generating a new flow may bring up other issues, like = needing a
new
> > > multicast group, etc. So, the trade-off must be examined = well.
> > [ZiXuan] Sharing a session among repair packet flow (or = source
packet
> > flow) and "source FEC payload ID" flow is probably a = way to go for
your
> > concern. For client making a distinguish between two flows, = payload
type
> > multiplexing of some kind is probably needed. A "FEC header" with a
PT
> > field of different value shall be used for identifying = different
flows.
> > >
> > > BR,
> > > -acbegen
> > >
> > >
> > > > The comments on the above are welcome.
> > > >
> > > >
> > > >
> > > > Best Regards.
> > > >
> > > >
> > > >
> > > > Zou ZiXuan, Ph.D, Senior Research Staff
> > > > Media & Communication Laboratory
> > > >
> > > > Corporate Research Department huawei_logo
> > > >
> > > >
> > > > Huawei Industrial Base
> > > > Bantian Longgang
> > > > Shenzhen 518129, P.R.China
> > > > Tel: 86-0755-28789364
> > > > Fax: 86-0755-28567643
> > > > E-mail: tendyntu@huawei.com
> > > > www.huawei.com
> > > >
> >
------------------------------------------------------------------------<= br> > > ------------------------------
> > > > -------------------------------
> > > > 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!

--Boundary_(ID_WaV6vYY1/yGSlDbxAq7ODw)-- From tendyntu@huawei.com Thu May 7 19:38:54 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 592153A7027 for ; Thu, 7 May 2009 19:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[AWL=1.524, 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 fETRdNfPoajJ for ; Thu, 7 May 2009 19:38:53 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0BC1E3A6944 for ; Thu, 7 May 2009 19:38:53 -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 <0KJB00MUH0R6ON@szxga01-in.huawei.com> for fecframe@ietf.org; Fri, 08 May 2009 10:40:18 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJB0089X0R574@szxga01-in.huawei.com> for fecframe@ietf.org; Fri, 08 May 2009 10:40:17 +0800 (CST) Received: from z61302 ([10.85.208.186]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJB00HPW0R1OW@szxml06-in.huawei.com> for fecframe@ietf.org; Fri, 08 May 2009 10:40:17 +0800 (CST) Date: Fri, 08 May 2009 10:40:13 +0800 From: zouzixuan 61302 To: fecframe@ietf.org Message-id: <000501c9cf86$5018f530$f04adf90$@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: AcnPhk5rjpOJfIMpTWWTHcp8noHwjQ== Subject: [Fecframe] new draft "Source FEC Payload Mapping Information for Sequence Flow" 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, 08 May 2009 02:38:54 -0000 Hi, all A new draft "Source FEC Payload Mapping Information for Sequence Flow" is posted: Per FEC framework, FEC source packet carries source FEC payload ID for FEC protection of arbitrary packet flow. This document specifies a FEC payload header and a source FEC payload mapping information unit (MIU) to enable carrying source FEC payload ID(s) in separate packet flow for FEC protection of sequence flow over unreliable transport. The FEC payload MIU consists of flexible source FEC payload ID(s) to be compatible with different FEC schemes. Please find the draft in: http://tools.ietf.org/html/draft-zixuan-fecframe-source-mi-00 The comments and feedback are appreciated. Best 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! From tme@multicasttech.com Fri May 8 06:41:20 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 AC0483A6A74 for ; Fri, 8 May 2009 06:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBjs-kcFPsUx for ; Fri, 8 May 2009 06:41:19 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 52DDA28C194 for ; Fri, 8 May 2009 06:41:12 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id AD28E3C2354B for ; Fri, 8 May 2009 09:42:39 -0400 (EDT) Message-Id: <8DE26861-6433-4521-9D3C-937F7AD82C93@multicasttech.com> From: Marshall Eubanks To: fecframe@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 8 May 2009 09:42:36 -0400 X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Fri, 08 May 2009 07:24:40 -0700 Subject: [Fecframe] Minutes for IETF 74 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, 08 May 2009 13:41:20 -0000 I apologize for this delay - and many thanks to Ulas Kozat for being the scribe ! Vincent, do you remember the answer to the question asked at the end - the answer was not recorded. Regards Marshall IETF 74, FEC Framework (FECFrame) Meeting Minutes Chairs Greg Shepherd Marshall Eubanks ========================================================= THURSDAY, March 26, 2009 1300-1500 Afternoon Session I Continental 3 TSV fecframe AGENDA o Administriva - Mailing list: fecframe@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fecframe - Charter : http://www.ietf.org/html.charters/fecframe-charter.html - Scribe(s)? - Blue Sheets o Agenda Bashing 5 minutes Chairs o Review and status of work items 10 minutes Chairs RFC published ------------ Expired (On Hold) ------------ Forward Error Correction (FEC) Framework Active Drafts ------------ draft-ietf-fecframe-1d2d-parity-scheme draft-ietf-fecframe-config-signaling draft-ietf-fecframe-dvb-al-fec draft-ietf-fecframe-framework draft-ietf-fecframe-interleaved-fec-scheme draft-ietf-fecframe-pseudo-cdp draft-ietf-fecframe-raptor -00 draft-ietf-fecframe-rtp-raptor draft-ietf-fecframe-sdp-elements Active Drafts (Presentations & Discussions) ------------- Ali Begen draft-ietf-fecframe-interleaved-fec-scheme-02.txt 5 minutes draft-ietf-fecframe-dvb-al-fec-01.txt 5 minutes Mark Watson draft-ietf-fecframe-rtp-raptor-01.txt 10 minutes Ulas C. Kozat draft-ietf-fecframe-pseudo-cdp 5 minutes New Drafts (Presentations & Discussions) ------------- Vincent Roca draft-roca-fecframe-rs-00.txt 10 minutes ------ Notes for FECFRAME WG: ----- draft-ietf-fecframe-dvb-al-fec-01.txt: Q: Do you mean RTP profile or a payload format? A: RTP profile. Q: DVB does not use SDP, so what is the concern? A: They want to use SDP but there is no way of defining FEC parameters in SDP. Q: Do you want to provide such support then? A: That is the intention, but not very hopeful. Q: What is the intention of this document? It does repeat and reference DVB AL-FEC heavily, rather should it be referencing other IETF draft documents? A: This is an informational draft that simply says if you want to use DVB AL-FEC, this is the reference document to use for the actual protocol. Q: Ready for WGLC? 4-5 to 0 in favor of WGLC. ----- draft-ietf-fecframe-interleaved-fec-scheme-02.txt: Q: The discussion on CNAME, does it also hold for multicast? A: Yes. Q: Does minimum offer mean minimum D parameter? A: Yes. Q: What do you mean by multiple offers? A: Multiple m lines to choose from a single offer should be the right terminology. Q: Is there an IANA consideration? A: Yes. Q: Is this a fully specified FEC Scheme or does it just define an RTP payload format? A: It is not a fully specified FEC Scheme. Q: Should we make it a fully specified FEC Scheme? Q: Ready for WGLC? 4-5 to 0 in favor of WGLC. ----- draft-ietf-fecframe-rtp-raptor-01.txt: Q: Is there any IANA consideration? A: Registration for the payload types are needed. Q: RTP payload type documents needs to be WGLC at AVT as well? A: We just last call and cross-post it. Q: Ready for WGLC? 6 to 0 in favor of WGLC. Should we call for WGLC for framework document before passing others to WGLC? All voted yes to WGLC for the framework. Afterwards the rest will be called. ----- draft-ietf-fecframe-pseudo-cdp: Dependent on framework, SDP, and signaling documents. ----- draft-roca-fecframe-rs-00.txt Q: What is the use case for this code? From watson@qualcomm.com Fri May 8 15:57:20 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 F1ED228C125 for ; Fri, 8 May 2009 15:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.284 X-Spam-Level: X-Spam-Status: No, score=-103.284 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MTrA4OY5dRR for ; Fri, 8 May 2009 15:57:18 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 74E3A3A6A3C for ; Fri, 8 May 2009 15:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1241823527; x=1273359527; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20V incent=20Roca=20,=0D=0A=20=20 =20=20=20=20=20=20"fecframe@ietf.org"=0D=0A=09|Date:=20Fri,=208=20May=202009=2015:58:36=20-0700 |Subject:=20Re:=20[Fecframe]=20Review=20of=20draft-ietf-f ecframe-framework-03|Thread-Topic:=20[Fecframe]=20Review =20of=20draft-ietf-fecframe-framework-03|Thread-Index:=20 Acm0VugAoKmWQ/BYTKy/+Qhi/Rokdwb2Zyyl|Message-ID:=20|In-Reply-To:=20<49D5FF8D.8 020806@inrialpes.fr>|Accept-Language:=20en-US |Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5609"=3B=20a=3D"17964396"; bh=hXoyyPyZwzyE5wtYe7m+J+wFaYXjhH2Phm5OtSje+90=; b=ZTxzV74dvLN9oi2zZnaLTAV9knj4R+7W8NRmAOdfOnvxpQlSupyKbGDi ftnsY7k9TivOcNCjjA5Io3O2oQFkZ2nPBtJ3bgGHt1j6J7GhJ93u+NEm4 KAlco7KKXcgrw9Yqo81VrgcnyXDdvz0RY/gXMc9TDNcCaXKbz3MmEcaUz 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5609"; a="17964396" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 May 2009 15:58:47 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n48MwlJn014302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 May 2009 15:58:47 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n48Mwfff010229 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 May 2009 15:58:46 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 8 May 2009 15:58:41 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Fri, 8 May 2009 15:58:41 -0700 From: "Watson, Mark" To: Vincent Roca , "fecframe@ietf.org" Date: Fri, 8 May 2009 15:58:36 -0700 Thread-Topic: [Fecframe] Review of draft-ietf-fecframe-framework-03 Thread-Index: Acm0VugAoKmWQ/BYTKy/+Qhi/Rokdwb2Zyyl Message-ID: In-Reply-To: <49D5FF8D.8020806@inrialpes.fr> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-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: Fri, 08 May 2009 22:57:20 -0000 HI Vincent, Thanks for these comments. I have cut&paste them below and put my responses inline. Regards, Mark Comments to draft-ietf-fecframe-framework-03 - VR ------------------------------------------------- For discussion... 1/ Terminology: --------------- The terminology is not sufficiently well defined and throughout the text we find several terms for the same concept (I won't list them here). I tried t= o compile them below. At the sender, from top to bottom: * the application layer provides "Source Transport Data Payloads" through one or several "Source Data Flow(s)". * the "Source Transport Data Payloads" are gathered in a "Source Block". * after the F, L and padding fields have been added to each "Source Transport Data Payload" for the purpose of FEC encoding, the resulting unit of data is called the "Source Packet Information (SPI)" (NB: this comes from the Raptor I-D). * from the FEC scheme point of view, we now have "Source Symbols" (i.e., a subset of the "Source Packet Information") and "Repair Symbols". They are globally called "Encoding Symbols". * the unit of data containing the source information, plus the "Explicit Source FEC Payload ID" (if used), is now called the "FEC Source Packet". It is given to the transport protocol. * the unit of data containing repair information, plus the "Repair FEC Payload ID", is now called "FEC Repair Packet". It can contain one or mor= e "repair symbols" depending on the FEC scheme. It is given to the transpor= t protocol. We should discuss the above names IMHO... In particular I'm not satisfied by the "Source Transport Data Payloads" which follows the transport protocol point of view (payload given to the transport protocol) rather than what leaves the application layer. Additionally, it's no longer the transport payload if the "Explicit Source FEC Payload ID" is appended by the FEC framework. I suggest: "Application Source Data Units", or simply "Application Data Units". MW> The idea was that this is the payload that the application would otherwise give directly to the transport protocol if the FEC Framework was not in the way. But Application Data Unit it better, I agree. (I don't thin= k 'Source' is required) There is also a clash between the "Source Packet Information" and the "Source Transport Data Payload". The two names should be close to one another. I suggest: "Application (Source) Data Unit Information" MW> Agree I think that, inside the FEC scheme itself, the usual terminology (source/repair/encoding symbols) must be used. This is common terminology with the FEC schemes coming from the RMT WG. Then we must make sure that the agreed terminology, and only it, is used in this I-D and others. 2/ Section 6.5. "FEC Framework Configuration Information" --------------------------------------------------------- I have several comments WRT the pieces of information included in the FFCI. 2.1/ It is said:=20 " 1. Identification of the packet flow(s) carrying FEC Repair packets, known as the FEC repair flow(s)." I think we need more than just an identification. We need to know the *number* of FEC repair flows for this FEC framework instance and the *definition* of each FEC repair flow (e.g., the associated tuple). MW> Yes, "Identification" was meant in the sense of 'sufficient description to identify' (i.e. Flow specification) rather than the sense of 'an identifier'. I think "specification' of the packet flow(s)..." might be better. 2.2/ It is said: " b. An integer identifier for this flow definition (i.e. tuple). This identifier MUST be unique amongst all source packet flows which are protected by the same FEC repair flow." So, if I follow this text, if a source flow is protected by 2 FEC repair flows, this source flow can be assigned two different identifiers. This is a bit strange! I suggest that the identifier be unique among a FEC framework instance. The drawback I see, however, when this identifier is encoded in a single byte (e.g. Raptor or R-), is the limited number (256) o= f source data flows that can be protected globally. But is 256 really an issue? MW> No, each source flow is assigned a single identifier (I can make this clearer). The uniqueness requirement is that if two source flows are protected by a single repair flow, then the two source flows must have different identifiers. 2.3/ It is said: " 4. The length of the Explicit Source FEC Payload Id, in bytes" Why should the length be communicated to the FEC framework instance whereas the Explicit Source FEC Payload ID is totally defined by the FEC scheme, whose FEC Encoding ID is provided to the FEC framework? MW> The purpose of this was to allow receivers that supported the FEC Framework, but do not support the specific FEC Scheme, to remove the Explicit Source FEC Payload Id and use the source packets. 3/ Section 8. "Transport protocols" ----------------------------------- It is said: "The following transport protocols are supported:" What does "supported" mean, since the framework is relatively independent o= f the transport protocol used (it impacts the tuple used to identify flows an= d it should preserve the data unit boundaries, but that's all). I'd be in favor of having a less directive text, like: "The FEC framework is compatible with any transport protocol that fulfills the requirements (e.g., in terms of real-time delivery of datagrams) of the original source data flows. Examples of such protocols include: o User Datagram Protocol (UDP) o Datagram Congestion Control Protocol (DCCP)" MW> Fine by me! 4/ Section 9.1 "Normative requirements" --------------------------------------- I do understand and agree with the fact that there is a reasonable limit to the repair overhead. However I'm wondering if it makes sense to provide an actual figure. This limit depends on the target use-case, and the framework I-D specifies the architecture, not the use-case. There is also a potential problem with the current wording: " The bandwidth of FEC Repair packet flows MUST NOT exceed the bandwidth of the source packet flows being protected." In complex scenarios, it could result in non desirable limitations. This ca= n be the case with Fig. 1 of draft-ietf-fecframe-sdp-elements-02: ____| FEC FRAMEWORK / | INSTANCE / | 3: Repair Flow / SOURCE FLOWS / | FEC FRAMEWORK 0: Source Flow |___/ |------| INSTANCE __| 1: Source Flow | | 4: Repair Flow | | 2: Source Flow | | FEC FRAMEWORK |__________________________| INSTANCE | 5: Repair Flow | 6: Repair Flow | 7: Repair Flow Admittedly (1) the total bit rate of the 7 repair flows can be lower than that of the 3 source flows and (2) there are several framework instances. But this is an example where the section 9.1 limit can be a problem if we measure the aggregated repair flow bandwidth at the sending host. I suggest to have a less directive text, like: The bandwidth of FEC Repair packet flows MUST NOT exceed a certain threshol= d of the bandwidth of the source packet flows being protected. This threshold depends on the use-case where the FEC framework is used. When transmissions take place over Internet, the bandwidth of the FEC Repair packet flow(s) of a single FEC framework instance MUST NOT exceed the bandwidth of the source packet flow(s). MW> We have to be careful here. Currently, the framework avoids causing congestion control problems by specifying this hard requirement that bounds the repair bandwidth by the source bandwidth. We can then be sure that the repair bandwidth will be subject to the same congestion control response as the source flows. In any case I agree with you, Mark, that using FEC codes in a rateless way is definitively useless ;-) MW> Well, I wouldn't go as far as to suggest that ;-) Perhaps in a multicas= t streaming environment ... 5/ Section 6.2. "Structure of the source block" ----------------------------------------------- It is said: " For each source transport payload included in a source block, the following information is provided to the FEC Scheme: o A description of the source transport flow with which the transport payload is associated (See 6.5)" I'd rather provide the "identification" of the source flow. The description of the flow is provided only once, upon FEC framework instantiation initialization. MW> I think this must have been an error. You are right it should be the identifier defined in the FEC Framework Configuration Information that should be supplied to the FEC Scheme. 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id" ---------------------------------------------------------- I don't think that any of the current FEC schemes specifies this Generic Explicit Source FEC Payload Id. This is a problem... Besides, how is the 2 byte counter managed? Does it take into account the source block structure or not? It seems that it is the case, but it is not clearly said that the counter should be reset to 0 at the beginning of a new source block. Additionally, the various FEC schemes can have different maximum source block sizes which means that the source block structure can differ. Maybe we should say that all the FEC schemes MUST share the same source block structure if we want the FEC Source Packets to be shared between the various FEC schemes. MW> This was added rather late. The idea was to allow, in principle, for a source flow to be protected by multiple FEC Schemes without those schemes having to be aware of each other. But as you say it works only if the schemes support the Generic Explicit Source FEC Payload Id". MW> It does not take into account the source block structure, rather the other way round: the source block structure is constrained by the requirement that a source block contains a set of packets with contiguous sequence numbers. MW> To use this, the FEC scheme essentially has to specify the sequence number range that makes up a source block in each repair packet for the block (or in sufficient of the repair packets that it is sufficiently likel= y it will be received). Additional comments: -------------------- ** Current I-D mentions either "Content Delivery Protocol" or CDP. I suggest to use only CDP throughout of the text. MW> OK ** Section 6.6. "FEC Scheme requirements" It is said: " ...and the valid packet payload sizes (where packet payload refers to the space - not necessarily contiguous - within a packet dedicated to carrying encoding symbol bytes)." Sorry, I don't understand "not necessarily contiguous". MW> I think this was added to accommodate things like RFC2733 and SMPTE-2022-1 where the repair bytes are stored into a repair packet in a non-contiguous way (for example repair bytes covering the CC fields of the RTP headers of the source packets are put into the CC field of the repair packet.) I agree it is not at all clear. Since these things are not now being proposed as FEC Schemes, perhaps we should delete the 'not necessaril= y contiguous'.=20 I also suggest to say: "...and the valid transport (e.g., UDP) datagram payload sizes". (if I understand correctly the goal). MW> Yes, this would be clearer. On 4/3/09 5:22 AM, "Vincent Roca" wrote: > Mark, everybody, >=20 > Since the goal was to start a WGLC on the framework document, I anticipat= ed > a little bit the announce... (sorry if it creates problems). > Here are my comments. >=20 > Regards, >=20 > Vincent >=20 From vincent.roca@inrialpes.fr Mon May 11 04:07:12 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 AABA33A6CA0 for ; Mon, 11 May 2009 04:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_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 vo1snUZuaJ+k for ; Mon, 11 May 2009 04:07:11 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id E14263A6BEA for ; Mon, 11 May 2009 04:07:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,327,1238968800"; d="scan'208";a="25937745" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2009 13:08:38 +0200 Message-ID: <4A080736.7040600@inrialpes.fr> Date: Mon, 11 May 2009 13:08:38 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: "Watson, Mark" References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-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: Mon, 11 May 2009 11:07:12 -0000 Hello Mark, Since we agree for most comments, I only leave below the ones for which we still need to discuss. > 1/ Terminology: > --------------- [...] VR: So, to summarize our discussion, here is the current proposal: At the sender, from top to bottom: * the application layer provides "Application Data Units", through one or several "Source Data Flow(s)". * a certain number of "Application Data Units" are gathered in a "Source Block". * after the F, L and padding fields have been added to each "Application Data Unit" for the purpose of FEC encoding, the resulting unit of data is called the "Application Data Unit Information (ADUI)". NB: this comes from the Raptor I-D * from the FEC scheme point of view, we now have "Source Symbols" (i.e., a subset of the "Application Data Unit Information") and "Repair Symbols". They are globally called "Encoding Symbols". NB: this is in line with the RMT WG terminology used for FEC schemes * the unit of data containing the source information (i.e., an "Application Data Unit") plus the "Explicit Source FEC Payload ID" (if used), is now called the "FEC Source Packet". It is given to the transport protocol. * the unit of data containing repair information, plus the "Repair FEC Payload ID", is now called "FEC Repair Packet". It can contain one or more "Repair Symbols" depending on the FEC scheme. It is given to the transport protocol. Do we agree? > Then we must make sure that the agreed terminology, and only it, is used in > this I-D and others. VR: ...the necessary second step! > 2/ Section 6.5. "FEC Framework Configuration Information" > --------------------------------------------------------- > > I have several comments WRT the pieces of information included in the FFCI. > [...] > 2.2/ It is said: > " b. An integer identifier for this flow definition (i.e. > tuple). This identifier MUST be unique amongst all source > packet flows which are protected by the same FEC repair flow." > > So, if I follow this text, if a source flow is protected by 2 FEC repair > flows, this source flow can be assigned two different identifiers. This is > a bit strange! I suggest that the identifier be unique among a FEC > framework instance. The drawback I see, however, when this identifier is > encoded in a single byte (e.g. Raptor or R-), is the limited number (256) of > source data flows that can be protected globally. But is 256 really an > issue? > > MW> No, each source flow is assigned a single identifier (I can make this > clearer). The uniqueness requirement is that if two source flows are > protected by a single repair flow, then the two source flows must have > different identifiers. VR: Sorry, but I still don't see clearly to what extent the identifier should be unique in your answer. When you say: "each source flow is assigned a single identifier", is it for the whole fecframe instance or not? And the second sentence of your answer does not clarify this at all. > 2.3/ It is said: > " 4. The length of the Explicit Source FEC Payload Id, in bytes" > Why should the length be communicated to the FEC framework instance whereas > the Explicit Source FEC Payload ID is totally defined by the FEC scheme, > whose FEC Encoding ID is provided to the FEC framework? > > MW> The purpose of this was to allow receivers that supported the FEC > Framework, but do not support the specific FEC Scheme, to remove the > Explicit Source FEC Payload Id and use the source packets. VR: Okay, said this way, it makes sense. You can perhaps clarify the intent in the original text. > 4/ Section 9.1 "Normative requirements" > --------------------------------------- > > I do understand and agree with the fact that there is a reasonable limit to > the > repair overhead. However I'm wondering if it makes sense to provide an > actual > figure. This limit depends on the target use-case, and the framework I-D > specifies the architecture, not the use-case. [...] > I suggest to have a less directive text, like: > > The bandwidth of FEC Repair packet flows MUST NOT exceed a certain threshold > of the bandwidth of the source packet flows being protected. This threshold > depends on the use-case where the FEC framework is used. When transmissions > take place over Internet, the bandwidth of the FEC Repair packet flow(s) of > a > single FEC framework instance MUST NOT exceed the bandwidth of the source > packet flow(s). > > MW> We have to be careful here. Currently, the framework avoids causing > congestion control problems by specifying this hard requirement that bounds > the repair bandwidth by the source bandwidth. We can then be sure that the > repair bandwidth will be subject to the same congestion control response as > the source flows. VR: I do agree that we need to be careful here. As already said in section 9, the only goal is to: "require at a minimum that the use of this framework with any given application, in any given environment, does not cause congestion issues which the application alone would not itself cause" The second constraint is for sure needed. But the first constraint is application/environment specific and no numerical value, applicable to all possible applications/environments, should be specified IMHO, unless there is a strong analysis showing this value is meaningful which I don't see here. Said differently, why this minimum code rate 0.5 rather than, for instance, 0.4 or 0.6? Which one is the best value and why? > In any case I agree with you, Mark, that using FEC codes in a rateless way > is definitively useless ;-) > > MW> Well, I wouldn't go as far as to suggest that ;-) Perhaps in a multicast > streaming environment ... VR: This is however what you are suggesting with the above requirement which holds no matter the application/environement, even if the text mentions "bandwidth" rather than "code rates" (there's a direct mapping between the two concepts). > 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id" > ---------------------------------------------------------- > > I don't think that any of the current FEC schemes specifies this > Generic Explicit Source FEC Payload Id. This is a problem... > > Besides, how is the 2 byte counter managed? Does it take into account > the source block structure or not? It seems that it is the case, but > it is not clearly said that the counter should be reset to 0 at the > beginning of a new source block. > > Additionally, the various FEC schemes can have different maximum source > block sizes which means that the source block structure can differ. > Maybe we should say that all the FEC schemes MUST share the same > source block structure if we want the FEC Source Packets to be shared > between the various FEC schemes. > > MW> This was added rather late. The idea was to allow, in principle, for a > source flow to be protected by multiple FEC Schemes without those schemes > having to be aware of each other. But as you say it works only if the > schemes support the Generic Explicit Source FEC Payload Id". > > MW> It does not take into account the source block structure, rather the > other way round: the source block structure is constrained by the > requirement that a source block contains a set of packets with contiguous > sequence numbers. > > MW> To use this, the FEC scheme essentially has to specify the sequence > number range that makes up a source block in each repair packet for the > block (or in sufficient of the repair packets that it is sufficiently likely > it will be received). VR: Okay, I understand the possible way of using the counter. It should perhaps be clarified in the document if this Generic Explicit Source FEC Payload Id is to remain. Regards, Vincent From vincent.roca@inrialpes.fr Mon May 11 05:27:03 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 48E013A6ABF for ; Mon, 11 May 2009 05:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVigKquIHGWe for ; Mon, 11 May 2009 05:27:02 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 20B213A69C2 for ; Mon, 11 May 2009 05:27:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,327,1238968800"; d="scan'208";a="27515974" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2009 14:28:31 +0200 Message-ID: <4A0819EE.2020802@inrialpes.fr> Date: Mon, 11 May 2009 14:28:30 +0200 From: Vincent Roca User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Marshall Eubanks References: <8DE26861-6433-4521-9D3C-937F7AD82C93@multicasttech.com> In-Reply-To: <8DE26861-6433-4521-9D3C-937F7AD82C93@multicasttech.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: fecframe@ietf.org Subject: Re: [Fecframe] Minutes for IETF 74 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, 11 May 2009 12:27:03 -0000 Hello Marshall, > Vincent, do you remember the answer to the question asked at the end - > the answer was not > recorded. [...] > ----- draft-roca-fecframe-rs-00.txt > > Q: What is the use case for this code? Here is my record of the discussion around our I-D, which includes in particular the important remark from Mark concerning potential IPRs that must be recorded in the minutes. -------- Mark W.: He informs the group that there may be IPR(s) applying to this I-D. A disclosure will be issued if needed. Q: What is the target use-case for R-S codes? Vincent: R-S are well known, systematic codes, with ideal erasure recovery capabilities. They are well suited when having small blocks is not an issue (usually the case with real-time applications) and for "medium bit rate" flows. Q: What is the encoding/decoding complexity? Vincent: we'll send more information on the list. Marshall: Do you ask this I-D to be WG Item? Vincent: Not yet because many sections are still missing in this version. Our goal is to revise the document for IETF75 first, and then to ask for the group opinion. --------- Regards, Vincent From tme@multicasttech.com Mon May 11 06:30: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 72AF63A6C3F for ; Mon, 11 May 2009 06:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.922 X-Spam-Level: X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD4p8DHLZIPE for ; Mon, 11 May 2009 06:30:24 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 9D9913A6B9F for ; Mon, 11 May 2009 06:30:24 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 5A4B23C6F691; Mon, 11 May 2009 09:31:55 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Vincent Roca In-Reply-To: <4A0819EE.2020802@inrialpes.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 09:31:54 -0400 References: <8DE26861-6433-4521-9D3C-937F7AD82C93@multicasttech.com> <4A0819EE.2020802@inrialpes.fr> X-Mailer: Apple Mail (2.930.3) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Minutes for IETF 74 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, 11 May 2009 13:30:25 -0000 OK, excellent, this has been added to the minutes. By the way, Mark, what is the status of that IPR disclosure ? Regards Marshall On May 11, 2009, at 8:28 AM, Vincent Roca wrote: > Hello Marshall, > > >> Vincent, do you remember the answer to the question asked at the >> end - >> the answer was not >> recorded. > [...] >> ----- draft-roca-fecframe-rs-00.txt >> >> Q: What is the use case for this code? > > > Here is my record of the discussion around our I-D, > which includes in particular the important remark > from Mark concerning potential IPRs that must be > recorded in the minutes. > > -------- > > Mark W.: He informs the group that there may be IPR(s) applying > to this I-D. A disclosure will be issued if needed. > > Q: What is the target use-case for R-S codes? > Vincent: R-S are well known, systematic codes, with ideal erasure > recovery capabilities. They are well suited when having small blocks > is not an issue (usually the case with real-time applications) and > for "medium bit rate" flows. > > Q: What is the encoding/decoding complexity? > Vincent: we'll send more information on the list. > > Marshall: Do you ask this I-D to be WG Item? > Vincent: Not yet because many sections are still missing in this > version. Our goal is to revise the document for IETF75 first, and > then to ask for the group opinion. > > --------- > > Regards, > > Vincent > From watson@qualcomm.com Mon May 11 09:29:18 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 99B0D3A6B28 for ; Mon, 11 May 2009 09:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.476 X-Spam-Level: X-Spam-Status: No, score=-105.476 tagged_above=-999 required=5 tests=[AWL=1.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-cAUJ+HS2Bp for ; Mon, 11 May 2009 09:29:05 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 43CDE3A68DC for ; Mon, 11 May 2009 09:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1242059436; x=1273595436; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20V incent=20Roca=20|CC:=20"fecfra me@ietf.org"=20|Date:=20Mon,=2011=20Ma y=202009=2009:30:05=20-0700|Subject:=20Re:=20[Fecframe] =20Review=20of=20draft-ietf-fecframe-framework-03 |Thread-Topic:=20[Fecframe]=20Review=20of=20draft-ietf-fe cframe-framework-03|Thread-Index:=20AcnSKOxSI+W5zmFUSKu8g hnALYL2ZAALNEti|Message-ID:=20|In-Reply-To:=20<4A080736.7040600@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C62DA09D2CF53watsonqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5612"=3B=20a=3D"18028542"; bh=9gLgldZ4JD5UKZBmDLvqAp5GbzUDliGLkjFDWc6FqAA=; b=BDoVLTq+3enS/iC2MC+hHr6igzJUcc9J7KFIlzw9d3tiFoIcWI6pe1hb hwSim0xTHjjGK2LOUlgFIefO2akM6RDY48eIA8IC3oEvlNdAxtsX9Vw8B 6ymHKb/LkJsZZxMHM4SlZk5YaRbE8V4etxwZgfLDAfu+EbAI5/t6wYB6D o=; X-IronPort-AV: E=McAfee;i="5300,2777,5612"; a="18028542" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2009 09:30:35 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4BGUZ41016402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 May 2009 09:30:35 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4BGUWvc031323 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 May 2009 09:30:33 -0700 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 11 May 2009 09:30:33 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Mon, 11 May 2009 09:30:32 -0700 From: "Watson, Mark" To: Vincent Roca Date: Mon, 11 May 2009 09:30:05 -0700 Thread-Topic: [Fecframe] Review of draft-ietf-fecframe-framework-03 Thread-Index: AcnSKOxSI+W5zmFUSKu8ghnALYL2ZAALNEti Message-ID: In-Reply-To: <4A080736.7040600@inrialpes.fr> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C62DA09D2CF53watsonqualcommcom_" MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-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: Mon, 11 May 2009 16:29:18 -0000 --_000_C62DA09D2CF53watsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable HI Vincent, Thanks for your response. Some further comments inline marked 'MW2'. There = are perhaps two issues which require discussion/confirmation from the list: (1) The change in terminology from "Source Transport Payloads" to "Applicat= ion Data Unit" (2) The explicit requirement that repair bandwidth must not exceed source b= andwidth: I'd especially like to hear from Magnus. I have no objection to r= elaxing this if the remaining text is likely to be acceptable to the IESG t= o address the congestion issue, but I am not sure that is the case. ...Mark On 5/11/09 4:08 AM, "Vincent Roca" wrote: Hello Mark, Since we agree for most comments, I only leave below the ones for which we still need to discuss. > 1/ Terminology: > --------------- [...] VR: So, to summarize our discussion, here is the current proposal: At the sender, from top to bottom: * the application layer provides "Application Data Units", through one or several "Source Data Flow(s)". * a certain number of "Application Data Units" are gathered in a "Source Block". * after the F, L and padding fields have been added to each "Application Data Unit" for the purpose of FEC encoding, the resulting unit of data is called the "Application Data Unit Information (ADUI)". NB: this comes from the Raptor I-D * from the FEC scheme point of view, we now have "Source Symbols" (i.e., a subset of the "Application Data Unit Information") and "Repair Symbols". They are globally called "Encoding Symbols". NB: this is in line with the RMT WG terminology used for FEC schemes * the unit of data containing the source information (i.e., an "Application Data Unit") plus the "Explicit Source FEC Payload ID" (if used), is now called the "FEC Source Packet". It is given to the transport protocol. * the unit of data containing repair information, plus the "Repair FEC Payload ID", is now called "FEC Repair Packet". It can contain one or more "Repair Symbols" depending on the FEC scheme. It is given to the transport protocol. Do we agree? MW2> We do. I just want to check everyone else is happy with this. > Then we must make sure that the agreed terminology, and only it, is used = in > this I-D and others. VR: ...the necessary second step! > 2/ Section 6.5. "FEC Framework Configuration Information" > --------------------------------------------------------- > > I have several comments WRT the pieces of information included in the FFC= I. > [...] > 2.2/ It is said: > " b. An integer identifier for this flow definition (i.e. > tuple). This identifier MUST be unique amongst all source > packet flows which are protected by the same FEC repair flow." > > So, if I follow this text, if a source flow is protected by 2 FEC repair > flows, this source flow can be assigned two different identifiers. This i= s > a bit strange! I suggest that the identifier be unique among a FEC > framework instance. The drawback I see, however, when this identifier is > encoded in a single byte (e.g. Raptor or R-), is the limited number (256)= of > source data flows that can be protected globally. But is 256 really an > issue? > > MW> No, each source flow is assigned a single identifier (I can make this > clearer). The uniqueness requirement is that if two source flows are > protected by a single repair flow, then the two source flows must have > different identifiers. VR: Sorry, but I still don't see clearly to what extent the identifier should be unique in your answer. When you say: "each source flow is assigned a single identifier", is it for the whole fecframe instance or not? And the second sentence of your answer does not clarify this at all. MW2> Re-reading this, in fact what is stated is equivalent to requiring uni= queness within a framework instance. What is stated is that for each repair= flow, every source flow protected by that repair flow must have a differen= t identifier from every other source flow protected by the same repair flow= . I.e. Source flows that are to be combined into a single source block must= have different identifiers. But a set of source flows that are to be prote= cted together is exactly what characterises a framework instance. I don't t= hink the framework draft limits this flow identifier to 1 byte - though I m= ay have missed that. Certainly the Raptor draft does limit it. I don't thin= k the framework draft needs to provide a limit, but it does need to require= that values are allocated from zero upwards. > 4/ Section 9.1 "Normative requirements" > --------------------------------------- > > I do understand and agree with the fact that there is a reasonable limit = to > the > repair overhead. However I'm wondering if it makes sense to provide an > actual > figure. This limit depends on the target use-case, and the framework I-D > specifies the architecture, not the use-case. [...] > I suggest to have a less directive text, like: > > The bandwidth of FEC Repair packet flows MUST NOT exceed a certain thresh= old > of the bandwidth of the source packet flows being protected. This thresho= ld > depends on the use-case where the FEC framework is used. When transmissio= ns > take place over Internet, the bandwidth of the FEC Repair packet flow(s) = of > a > single FEC framework instance MUST NOT exceed the bandwidth of the source > packet flow(s). > > MW> We have to be careful here. Currently, the framework avoids causing > congestion control problems by specifying this hard requirement that boun= ds > the repair bandwidth by the source bandwidth. We can then be sure that th= e > repair bandwidth will be subject to the same congestion control response = as > the source flows. VR: I do agree that we need to be careful here. As already said in section 9, the only goal is to: "require at a minimum that the use of this framework with any given application, in any given environment, does not cause congestion issues which the application alone would not itself cause" The second constraint is for sure needed. But the first constraint is application/environment specific and no numerical value, applicable to all possible applications/environments, should be specified IMHO, unless there is a strong analysis showing this value is meaningful which I don't see here. Said differently, why this minimum code rate 0.5 rather than, for instance, 0.4 or 0.6? Which one is the best value and why? > In any case I agree with you, Mark, that using FEC codes in a rateless wa= y > is definitively useless ;-) > > MW> Well, I wouldn't go as far as to suggest that ;-) Perhaps in a multic= ast > streaming environment ... VR: This is however what you are suggesting with the above requirement which holds no matter the application/environement, even if the text mentions "bandwidth" rather than "code rates" (there's a direct mapping between the two concepts). MW2> There are many ways rateless codes can be useful. There is only a dire= ct mapping between bandwidth and code rate if you always send all the symbo= ls. So for example there are applications where it is useful to be able to = generate many more symbols than you eventually send. In terms of congestion= control, it is bandwidth which is the concern, not the rate of the code fr= om which the symbols were taken. > 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id" > ---------------------------------------------------------- > > I don't think that any of the current FEC schemes specifies this > Generic Explicit Source FEC Payload Id. This is a problem... > > Besides, how is the 2 byte counter managed? Does it take into account > the source block structure or not? It seems that it is the case, but > it is not clearly said that the counter should be reset to 0 at the > beginning of a new source block. > > Additionally, the various FEC schemes can have different maximum source > block sizes which means that the source block structure can differ. > Maybe we should say that all the FEC schemes MUST share the same > source block structure if we want the FEC Source Packets to be shared > between the various FEC schemes. > > MW> This was added rather late. The idea was to allow, in principle, for = a > source flow to be protected by multiple FEC Schemes without those schemes > having to be aware of each other. But as you say it works only if the > schemes support the Generic Explicit Source FEC Payload Id". > > MW> It does not take into account the source block structure, rather the > other way round: the source block structure is constrained by the > requirement that a source block contains a set of packets with contiguous > sequence numbers. > > MW> To use this, the FEC scheme essentially has to specify the sequence > number range that makes up a source block in each repair packet for the > block (or in sufficient of the repair packets that it is sufficiently lik= ely > it will be received). VR: Okay, I understand the possible way of using the counter. It should perhaps be clarified in the document if this Generic Explicit Source FEC Payload Id is to remain. MW2> Sure. Regards, Vincent --_000_C62DA09D2CF53watsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] Review of draft-ietf-fecframe-framework-03 HI Vincent,

Thanks for your response. Some further comments inline marked ‘MW2= 217;. There are perhaps two issues which require discussion/confirmation fr= om the list:
(1) The change in terminology from “Source Transport Payloads” = to “Application Data Unit”
(2) The explicit requirement that repair bandwidth must not exceed source b= andwidth: I’d especially like to hear from Magnus. I have no objectio= n to relaxing this if the remaining text is likely to be acceptable to the = IESG to address the congestion issue, but I am not sure that is the case.
...Mark

On 5/11/09 4:08 AM, "Vincent Roca" <vincent.roca@inrialpes.fr> wrote:

Hello Mark,

Since we agree for most comments, I only leave below the ones for which
we still need to discuss.


> 1/ Terminology:
> ---------------
[...]

VR: So, to summarize our discussion, here is the current proposal:

At the sender, from top to bottom:

* the application layer provides "Application Data Units", throug= h
  one or several "Source Data Flow(s)".

* a certain number of "Application Data Units" are gathered in a<= BR>   "Source Block".

* after the F, L and padding fields have been added to each
  "Application Data Unit" for the purpose of FEC encodi= ng, the
  resulting unit of data is called the "Application Data Uni= t
  Information (ADUI)".
  NB: this comes from the Raptor I-D

* from the FEC scheme point of view, we now have "Source Symbols"=
  (i.e., a subset of the "Application Data Unit Information&= quot;) and
  "Repair Symbols". They are globally called "Enco= ding Symbols".
  NB: this is in line with the RMT WG terminology used for FEC sc= hemes

* the unit of data containing the source information (i.e., an
  "Application Data Unit") plus the "Explicit Sour= ce FEC Payload ID"
  (if used), is now called the "FEC Source Packet". It = is given to
  the transport protocol.

* the unit of data containing repair information, plus the "Repair FEC=
  Payload ID", is now called "FEC Repair Packet". = It can contain one or
  more "Repair Symbols" depending on the FEC scheme. It= is given to the
  transport protocol.

Do we agree?



> Then we must make sure that the agreed terminology, and only it, is us= ed in
> this I-D and others.

VR: ...the necessary second step!


> 2/ Section 6.5. "FEC Framework Configuration Information" > ---------------------------------------------------------
>
> I have several comments WRT the pieces of information included in the = FFCI.
>
[...]
> 2.2/ It is said:
> "        b.  An integer i= dentifier for this flow definition (i.e.
>          tuple).  Th= is identifier MUST be unique amongst all source
>          packet flows whi= ch are protected by the same FEC repair flow."
>
> So, if I follow this text, if a source flow is protected by 2 FEC repa= ir
> flows, this source flow can be assigned two different identifiers. Thi= s is
> a bit strange! I suggest that the identifier be unique among a FEC
> framework instance. The drawback I see, however, when this identifier = is
> encoded in a single byte (e.g. Raptor or R-), is the limited number (2= 56) of
> source data flows that can be protected globally. But is 256 really an=
> issue?
>
> MW> No, each source flow is assigned a single identifier (I can mak= e this
> clearer). The uniqueness requirement is that if two source flows are > protected by a single repair flow, then the two source flows must have=
> different identifiers.

VR: Sorry, but I still don't see clearly to what extent the
identifier should be unique in your answer. When you say:
"each source flow is assigned a single identifier", is it
for the whole fecframe instance or not? And the second sentence
of your answer does not clarify this at all.


> 4/ Section 9.1 "Normative requirements"
> ---------------------------------------
>
> I do understand and agree with the fact that there is a reasonable lim= it to
> the
> repair overhead. However I'm wondering if it makes sense to provide an=
> actual
> figure. This limit depends on the target use-case, and the framework I= -D
> specifies the architecture, not the use-case.

[...]
> I suggest to have a less directive text, like:
>
> The bandwidth of FEC Repair packet flows MUST NOT exceed a certain thr= eshold
> of the bandwidth of the source packet flows being protected. This thre= shold
> depends on the use-case where the FEC framework is used. When transmis= sions
> take place over Internet, the bandwidth of the FEC Repair packet flow(= s) of
> a
> single FEC framework instance MUST NOT exceed the bandwidth of the sou= rce
> packet flow(s).
>
> MW> We have to be careful here. Currently, the framework avoids cau= sing
> congestion control problems by specifying this hard requirement that b= ounds
> the repair bandwidth by the source bandwidth. We can then be sure that= the
> repair bandwidth will be subject to the same congestion control respon= se as
> the source flows.

VR: I do agree that we need to be careful here.
As already said in section 9, the only goal is to:
     "require at a minimum that the use of th= is framework
      with any given application, in any give= n environment,
      does not cause congestion issues which = the application
      alone would not itself cause"

The second constraint is for sure needed. But the first constraint
is application/environment specific and no numerical value,
applicable to all possible applications/environments, should be
specified IMHO, unless there is a strong analysis showing this
value is meaningful which I don't see here.
Said differently, why this minimum code rate 0.5 rather than,
for instance, 0.4 or 0.6? Which one is the best value and why?

> In any case I agree with you, Mark, that using FEC codes in a rateless= way
> is definitively useless ;-)
>
> MW> Well, I wouldn't go as far as to suggest that ;-) Perhaps in a = multicast
> streaming environment ...

VR: This is however what you are suggesting with the above
requirement which holds no matter the application/environement,
even if the text mentions "bandwidth" rather than "code rate= s"
(there's a direct mapping between the two concepts).


> 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id" > ----------------------------------------------------------
>
> I don't think that any of the current FEC schemes specifies this
> Generic Explicit Source FEC Payload Id. This is a problem...
>
> Besides, how is the 2 byte counter managed? Does it take into account<= BR> > the source block structure or not? It seems that it is the case, but > it is not clearly said that the counter should be reset to 0 at the > beginning of a new source block.
>
> Additionally, the various FEC schemes can have different maximum sourc= e
> block sizes which means that the source block structure can differ. > Maybe we should say that all the FEC schemes MUST share the same
> source block structure if we want the FEC Source Packets to be shared<= BR> > between the various FEC schemes.
>
> MW> This was added rather late. The idea was to allow, in principle= , for a
> source flow to be protected by multiple FEC Schemes without those sche= mes
> having to be aware of each other. But as you say it works only if the<= BR> > schemes support the Generic Explicit Source FEC Payload Id".
>
> MW> It does not take into account the source block structure, rathe= r the
> other way round: the source block structure is constrained by the
> requirement that a source block contains a set of packets with contigu= ous
> sequence numbers.
>
> MW> To use this, the FEC scheme essentially has to specify the sequ= ence
> number range that makes up a source block in each repair packet for th= e
> block (or in sufficient of the repair packets that it is sufficiently = likely
> it will be received).

VR: Okay, I understand the possible way of using the counter.
It should perhaps be clarified in the document if this Generic
Explicit Source FEC Payload Id is to remain.


Regards,

  Vincent

 --_000_C62DA09D2CF53watsonqualcommcom_-- From watson@qualcomm.com Mon May 11 09:36: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 8BDA228C165 for ; Mon, 11 May 2009 09:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhr+wtXT9KYk for ; Mon, 11 May 2009 09:36:23 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 2C7BC3A695B for ; Mon, 11 May 2009 09:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1242059850; x=1273595850; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20M arshall=20Eubanks=20,=0D=0A=20=20 =20=20=20=20=20=20Vincent=20Roca=0D=0A=09|CC:=20"fecframe@ietf.org"=20|Date:=20Mon,=2011=20May=202009=2009:36:06=20-0700 |Subject:=20Re:=20[Fecframe]=20Minutes=20for=20IETF=2074 |Thread-Topic:=20[Fecframe]=20Minutes=20for=20IETF=2074 |Thread-Index:=20AcnSPN96llCjan/vTWy/pHOeVdmFDQAGbUwY |Message-ID:=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C62DA2062CF55watsonqualcommcom_"|MIME-Version: =201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5612" =3B=20a=3D"18025881"; bh=D6/QYtgiWIfUXO90JEUucDrUXRwreqN6aYs56j6GBO8=; b=UJwDoFAwLLx1jisBI9eqNKoQp1Bu4mbRVUO2sHOYWf6MZaMJ1ry6+NWW i/UaJHX+qXHVgt++alIRNOfw7wRN6ljobY701qlxUawpqSNeCa801AMKc buv/7xF/0QEQSQUKAV3Q0+SDdgMO4a49rkRqCqPYMc3qxzA9Yt6I1uhsY U=; X-IronPort-AV: E=McAfee;i="5300,2777,5612"; a="18025881" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2009 09:37:19 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4BGbJ0M017423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 May 2009 09:37:19 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4BGbI77019610 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 May 2009 09:37:19 -0700 (PDT) Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 11 May 2009 09:37:18 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Mon, 11 May 2009 09:37:18 -0700 From: "Watson, Mark" To: Marshall Eubanks , Vincent Roca Date: Mon, 11 May 2009 09:36:06 -0700 Thread-Topic: [Fecframe] Minutes for IETF 74 Thread-Index: AcnSPN96llCjan/vTWy/pHOeVdmFDQAGbUwY Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C62DA2062CF55watsonqualcommcom_" MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Minutes for IETF 74 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, 11 May 2009 16:36:24 -0000 --_000_C62DA2062CF55watsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marshall, Our legal people are looking in to whether a disclosure is necessary. I wil= l ping them. ...Mark On 5/11/09 6:31 AM, "Marshall Eubanks" wrote: OK, excellent, this has been added to the minutes. By the way, Mark, what is the status of that IPR disclosure ? Regards Marshall On May 11, 2009, at 8:28 AM, Vincent Roca wrote: > Hello Marshall, > > >> Vincent, do you remember the answer to the question asked at the >> end - >> the answer was not >> recorded. > [...] >> ----- draft-roca-fecframe-rs-00.txt >> >> Q: What is the use case for this code? > > > Here is my record of the discussion around our I-D, > which includes in particular the important remark > from Mark concerning potential IPRs that must be > recorded in the minutes. > > -------- > > Mark W.: He informs the group that there may be IPR(s) applying > to this I-D. A disclosure will be issued if needed. > > Q: What is the target use-case for R-S codes? > Vincent: R-S are well known, systematic codes, with ideal erasure > recovery capabilities. They are well suited when having small blocks > is not an issue (usually the case with real-time applications) and > for "medium bit rate" flows. > > Q: What is the encoding/decoding complexity? > Vincent: we'll send more information on the list. > > Marshall: Do you ask this I-D to be WG Item? > Vincent: Not yet because many sections are still missing in this > version. Our goal is to revise the document for IETF75 first, and > then to ask for the group opinion. > > --------- > > Regards, > > Vincent > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe --_000_C62DA2062CF55watsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] Minutes for IETF 74 Marshall,

Our legal people are looking in to whether a disclosure is necessary. I wil= l ping them.

...Mark


On 5/11/09 6:31 AM, "Marshall Eubanks" <tme@multicasttech.com> wrote:

OK, excellent, this has been added to the m= inutes.

By the way, Mark, what is the status of that IPR disclosure ?

Regards
Marshall

On May 11, 2009, at 8:28 AM, Vincent Roca wrote:

> Hello Marshall,
>
>
>> Vincent, do you remember the answer to the question asked at the <= BR> >> end -
>> the answer was not
>> recorded.
> [...]
>> ----- draft-roca-fecframe-rs-00.txt
>>
>> Q: What is the use case for this code?
>
>
> Here is my record of the discussion around our I-D,
> which includes in particular the important remark
> from Mark concerning potential IPRs that must be
> recorded in the minutes.
>
> --------
>
> Mark W.: He informs the group that there may be IPR(s) applying
> to this I-D. A disclosure will be issued if needed.
>
> Q: What is the target use-case for R-S codes?
> Vincent: R-S are well known, systematic codes, with ideal erasure
> recovery capabilities. They are well suited when having small blocks > is not an issue (usually the case with real-time applications) and
> for "medium bit rate" flows.
>
> Q: What is the encoding/decoding complexity?
> Vincent: we'll send more information on the list.
>
> Marshall: Do you ask this I-D to be WG Item?
> Vincent: Not yet because many sections are still missing in this
> version. Our goal is to revise the document for IETF75 first, and
> then to ask for the group opinion.
>
> ---------
>
> Regards,
>
>  Vincent
>

_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf= .org/mailman/listinfo/fecframe

--_000_C62DA2062CF55watsonqualcommcom_-- From luby@qualcomm.com Mon May 11 09:54:44 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 A21433A695B for ; Mon, 11 May 2009 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.75 X-Spam-Level: X-Spam-Status: No, score=-103.75 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8yoXKue7itj for ; Mon, 11 May 2009 09:54:31 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 468623A68F5 for ; Mon, 11 May 2009 09:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1242060962; x=1273596962; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Luby,=20Michael"=20|To:=20"W atson,=20Mark"=20,=0D=0A=20=20=20=20 =20=20=20=20Vincent=20Roca=0D=0A=09|CC:=20"fecframe@ietf.org"=20,=0D =0A=20=20=20=20=20=20=20=20"Luby,=20Michael"=0D=0A=09|Date:=20Mon,=2011=20May=202009=2009:55:54 =20-0700|Subject:=20Re:=20[Fecframe]=20Review=20of=20draf t-ietf-fecframe-framework-03|Thread-Topic:=20[Fecframe] =20Review=20of=20draft-ietf-fecframe-framework-03 |Thread-Index:=20AcnSKOxSI+W5zmFUSKu8ghnALYL2ZAALNEtiAADm 0R4=3D|Message-ID:=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C62DA6AA30C1lubyqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5612"=3B=20a=3D"18026809"; bh=PC/cRQVgf/Nl9KLkXLh7SEl8Snwvf/QS1B1fZO3fWyU=; b=ELP/dDCNmY93J6G8UzH1q5IzcQ4iNs49dnF7z8lO43d3wWKtZRgn/OJN TnzgrzIyh2j/mnt02yFYMYCnkqMNMHr1SbEw0LXJXL7bjqO/UcL8XsX+5 hHG/h79UedD3cIN13H7oVIbQmibUf+vl4Remzv7wdcJCVpP3lNARLpzVV k=; X-IronPort-AV: E=McAfee;i="5300,2777,5612"; a="18026809" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2009 09:56:02 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4BGu1BC020032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 May 2009 09:56:02 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4BGu15p000329 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 May 2009 09:56:01 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 11 May 2009 09:56:00 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Mon, 11 May 2009 09:56:00 -0700 From: "Luby, Michael" To: "Watson, Mark" , Vincent Roca Date: Mon, 11 May 2009 09:55:54 -0700 Thread-Topic: [Fecframe] Review of draft-ietf-fecframe-framework-03 Thread-Index: AcnSKOxSI+W5zmFUSKu8ghnALYL2ZAALNEtiAADm0R4= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C62DA6AA30C1lubyqualcommcom_" MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-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: Mon, 11 May 2009 16:54:44 -0000 --_000_C62DA6AA30C1lubyqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One input on (2) below: we have customers where limiting the amount of band= width allocated for repair to that of the original source stream would be a= severe restriction, as the loss conditions they face are much more than 5= 0% even on average for streaming applications (and thus the bandwidth they = need to provide to the repair stream to achieve reasonable quality video st= reaming is much more than that of the original source stream). These situa= tions come up in the defense/military, where the senders/receivers are quit= e mobile, wireless connectivity, and the need for high quality streaming vi= deo is paramount. I would not want to restrict these types of applications= from using this framework. On 5/11/09 9:30 AM, "Watson, Mark" wrote: HI Vincent, Thanks for your response. Some further comments inline marked 'MW2'. There = are perhaps two issues which require discussion/confirmation from the list: (1) The change in terminology from "Source Transport Payloads" to "Applicat= ion Data Unit" (2) The explicit requirement that repair bandwidth must not exceed source b= andwidth: I'd especially like to hear from Magnus. I have no objection to r= elaxing this if the remaining text is likely to be acceptable to the IESG t= o address the congestion issue, but I am not sure that is the case. ...Mark On 5/11/09 4:08 AM, "Vincent Roca" wrote: Hello Mark, Since we agree for most comments, I only leave below the ones for which we still need to discuss. > 1/ Terminology: > --------------- [...] VR: So, to summarize our discussion, here is the current proposal: At the sender, from top to bottom: * the application layer provides "Application Data Units", through one or several "Source Data Flow(s)". * a certain number of "Application Data Units" are gathered in a "Source Block". * after the F, L and padding fields have been added to each "Application Data Unit" for the purpose of FEC encoding, the resulting unit of data is called the "Application Data Unit Information (ADUI)". NB: this comes from the Raptor I-D * from the FEC scheme point of view, we now have "Source Symbols" (i.e., a subset of the "Application Data Unit Information") and "Repair Symbols". They are globally called "Encoding Symbols". NB: this is in line with the RMT WG terminology used for FEC schemes * the unit of data containing the source information (i.e., an "Application Data Unit") plus the "Explicit Source FEC Payload ID" (if used), is now called the "FEC Source Packet". It is given to the transport protocol. * the unit of data containing repair information, plus the "Repair FEC Payload ID", is now called "FEC Repair Packet". It can contain one or more "Repair Symbols" depending on the FEC scheme. It is given to the transport protocol. Do we agree? MW2> We do. I just want to check everyone else is happy with this. > Then we must make sure that the agreed terminology, and only it, is used = in > this I-D and others. VR: ...the necessary second step! > 2/ Section 6.5. "FEC Framework Configuration Information" > --------------------------------------------------------- > > I have several comments WRT the pieces of information included in the FFC= I. > [...] > 2.2/ It is said: > " b. An integer identifier for this flow definition (i.e. > tuple). This identifier MUST be unique amongst all source > packet flows which are protected by the same FEC repair flow." > > So, if I follow this text, if a source flow is protected by 2 FEC repair > flows, this source flow can be assigned two different identifiers. This i= s > a bit strange! I suggest that the identifier be unique among a FEC > framework instance. The drawback I see, however, when this identifier is > encoded in a single byte (e.g. Raptor or R-), is the limited number (256)= of > source data flows that can be protected globally. But is 256 really an > issue? > > MW> No, each source flow is assigned a single identifier (I can make this > clearer). The uniqueness requirement is that if two source flows are > protected by a single repair flow, then the two source flows must have > different identifiers. VR: Sorry, but I still don't see clearly to what extent the identifier should be unique in your answer. When you say: "each source flow is assigned a single identifier", is it for the whole fecframe instance or not? And the second sentence of your answer does not clarify this at all. MW2> Re-reading this, in fact what is stated is equivalent to requiring uni= queness within a framework instance. What is stated is that for each repair= flow, every source flow protected by that repair flow must have a differen= t identifier from every other source flow protected by the same repair flow= . I.e. Source flows that are to be combined into a single source block must= have different identifiers. But a set of source flows that are to be prote= cted together is exactly what characterises a framework instance. I don't t= hink the framework draft limits this flow identifier to 1 byte - though I m= ay have missed that. Certainly the Raptor draft does limit it. I don't thin= k the framework draft needs to provide a limit, but it does need to require= that values are allocated from zero upwards. > 4/ Section 9.1 "Normative requirements" > --------------------------------------- > > I do understand and agree with the fact that there is a reasonable limit = to > the > repair overhead. However I'm wondering if it makes sense to provide an > actual > figure. This limit depends on the target use-case, and the framework I-D > specifies the architecture, not the use-case. [...] > I suggest to have a less directive text, like: > > The bandwidth of FEC Repair packet flows MUST NOT exceed a certain thresh= old > of the bandwidth of the source packet flows being protected. This thresho= ld > depends on the use-case where the FEC framework is used. When transmissio= ns > take place over Internet, the bandwidth of the FEC Repair packet flow(s) = of > a > single FEC framework instance MUST NOT exceed the bandwidth of the source > packet flow(s). > > MW> We have to be careful here. Currently, the framework avoids causing > congestion control problems by specifying this hard requirement that boun= ds > the repair bandwidth by the source bandwidth. We can then be sure that th= e > repair bandwidth will be subject to the same congestion control response = as > the source flows. VR: I do agree that we need to be careful here. As already said in section 9, the only goal is to: "require at a minimum that the use of this framework with any given application, in any given environment, does not cause congestion issues which the application alone would not itself cause" The second constraint is for sure needed. But the first constraint is application/environment specific and no numerical value, applicable to all possible applications/environments, should be specified IMHO, unless there is a strong analysis showing this value is meaningful which I don't see here. Said differently, why this minimum code rate 0.5 rather than, for instance, 0.4 or 0.6? Which one is the best value and why? > In any case I agree with you, Mark, that using FEC codes in a rateless wa= y > is definitively useless ;-) > > MW> Well, I wouldn't go as far as to suggest that ;-) Perhaps in a multic= ast > streaming environment ... VR: This is however what you are suggesting with the above requirement which holds no matter the application/environement, even if the text mentions "bandwidth" rather than "code rates" (there's a direct mapping between the two concepts). MW2> There are many ways rateless codes can be useful. There is only a dire= ct mapping between bandwidth and code rate if you always send all the symbo= ls. So for example there are applications where it is useful to be able to = generate many more symbols than you eventually send. In terms of congestion= control, it is bandwidth which is the concern, not the rate of the code fr= om which the symbols were taken. > 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id" > ---------------------------------------------------------- > > I don't think that any of the current FEC schemes specifies this > Generic Explicit Source FEC Payload Id. This is a problem... > > Besides, how is the 2 byte counter managed? Does it take into account > the source block structure or not? It seems that it is the case, but > it is not clearly said that the counter should be reset to 0 at the > beginning of a new source block. > > Additionally, the various FEC schemes can have different maximum source > block sizes which means that the source block structure can differ. > Maybe we should say that all the FEC schemes MUST share the same > source block structure if we want the FEC Source Packets to be shared > between the various FEC schemes. > > MW> This was added rather late. The idea was to allow, in principle, for = a > source flow to be protected by multiple FEC Schemes without those schemes > having to be aware of each other. But as you say it works only if the > schemes support the Generic Explicit Source FEC Payload Id". > > MW> It does not take into account the source block structure, rather the > other way round: the source block structure is constrained by the > requirement that a source block contains a set of packets with contiguous > sequence numbers. > > MW> To use this, the FEC scheme essentially has to specify the sequence > number range that makes up a source block in each repair packet for the > block (or in sufficient of the repair packets that it is sufficiently lik= ely > it will be received). VR: Okay, I understand the possible way of using the counter. It should perhaps be clarified in the document if this Generic Explicit Source FEC Payload Id is to remain. MW2> Sure. Regards, Vincent --_000_C62DA6AA30C1lubyqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] Review of draft-ietf-fecframe-framework-03 One input on (2) below: we have customers where limiting the amount o= f bandwidth allocated for repair to that of the original source stream woul= d be a severe restriction, as the loss conditions they face are much more &= nbsp;than 50% even on average for streaming applications (and thus the band= width they need to provide to the repair stream to achieve reasonable quali= ty video streaming is much more than that of the original source stream). &= nbsp;These situations come up in the defense/military, where the senders/re= ceivers are quite mobile, wireless connectivity, and the need for high qual= ity streaming video is paramount.  I would not want to restrict these = types of applications from using this framework.


On 5/11/09 9:30 AM, "Watson, Mark" <watson@qualcomm.com> wrote:

HI Vincent,

Thanks for your response. Some further comments inline marked ‘MW2= 217;. There are perhaps two issues which require discussion/confirmation fr= om the list:
(1) The change in terminology from “Source Transport Payloads” = to “Application Data Unit”
(2) The explicit requirement that repair bandwidth must not exceed source b= andwidth: I’d especially like to hear from Magnus. I have no objectio= n to relaxing this if the remaining text is likely to be acceptable to the = IESG to address the congestion issue, but I am not sure that is the case.
...Mark

On 5/11/09 4:08 AM, "Vincent Roca" <vincent.roca@inrialpes.fr> wrote:

Hello Mark,

Since we agree for most comments, I only leave below the ones for which
we still need to discuss.


> 1/ Terminology:
> ---------------
[...]

VR: So, to summarize our discussion, here is the current proposal:

At the sender, from top to bottom:

* the application layer provides "Application Data Units", throug= h
  one or several "Source Data Flow(s)".

* a certain number of "Application Data Units" are gathered in a<= BR>   "Source Block".

* after the F, L and padding fields have been added to each
  "Application Data Unit" for the purpose of FEC encodi= ng, the
  resulting unit of data is called the "Application Data Uni= t
  Information (ADUI)".
  NB: this comes from the Raptor I-D

* from the FEC scheme point of view, we now have "Source Symbols"=
  (i.e., a subset of the "Application Data Unit Information&= quot;) and
  "Repair Symbols". They are globally called "Enco= ding Symbols".
  NB: this is in line with the RMT WG terminology used for FEC sc= hemes

* the unit of data containing the source information (i.e., an
  "Application Data Unit") plus the "Explicit Sour= ce FEC Payload ID"
  (if used), is now called the "FEC Source Packet". It = is given to
  the transport protocol.

* the unit of data containing repair information, plus the "Repair FEC=
  Payload ID", is now called "FEC Repair Packet". = It can contain one or
  more "Repair Symbols" depending on the FEC scheme. It= is given to the
  transport protocol.

Do we agree?



> Then we must make sure that the agreed terminology, and only it, is us= ed in
> this I-D and others.

VR: ...the necessary second step!


> 2/ Section 6.5. "FEC Framework Configuration Information" > ---------------------------------------------------------
>
> I have several comments WRT the pieces of information included in the = FFCI.
>
[...]
> 2.2/ It is said:
> "        b.  An integer i= dentifier for this flow definition (i.e.
>          tuple).  Th= is identifier MUST be unique amongst all source
>          packet flows whi= ch are protected by the same FEC repair flow."
>
> So, if I follow this text, if a source flow is protected by 2 FEC repa= ir
> flows, this source flow can be assigned two different identifiers. Thi= s is
> a bit strange! I suggest that the identifier be unique among a FEC
> framework instance. The drawback I see, however, when this identifier = is
> encoded in a single byte (e.g. Raptor or R-), is the limited number (2= 56) of
> source data flows that can be protected globally. But is 256 really an=
> issue?
>
> MW> No, each source flow is assigned a single identifier (I can mak= e this
> clearer). The uniqueness requirement is that if two source flows are > protected by a single repair flow, then the two source flows must have=
> different identifiers.

VR: Sorry, but I still don't see clearly to what extent the
identifier should be unique in your answer. When you say:
"each source flow is assigned a single identifier", is it
for the whole fecframe instance or not? And the second sentence
of your answer does not clarify this at all.


> 4/ Section 9.1 "Normative requirements"
> ---------------------------------------
>
> I do understand and agree with the fact that there is a reasonable lim= it to
> the
> repair overhead. However I'm wondering if it makes sense to provide an=
> actual
> figure. This limit depends on the target use-case, and the framework I= -D
> specifies the architecture, not the use-case.

[...]
> I suggest to have a less directive text, like:
>
> The bandwidth of FEC Repair packet flows MUST NOT exceed a certain thr= eshold
> of the bandwidth of the source packet flows being protected. This thre= shold
> depends on the use-case where the FEC framework is used. When transmis= sions
> take place over Internet, the bandwidth of the FEC Repair packet flow(= s) of
> a
> single FEC framework instance MUST NOT exceed the bandwidth of the sou= rce
> packet flow(s).
>
> MW> We have to be careful here. Currently, the framework avoids cau= sing
> congestion control problems by specifying this hard requirement that b= ounds
> the repair bandwidth by the source bandwidth. We can then be sure that= the
> repair bandwidth will be subject to the same congestion control respon= se as
> the source flows.

VR: I do agree that we need to be careful here.
As already said in section 9, the only goal is to:
     "require at a minimum that the use of th= is framework
      with any given application, in any give= n environment,
      does not cause congestion issues which = the application
      alone would not itself cause"

The second constraint is for sure needed. But the first constraint
is application/environment specific and no numerical value,
applicable to all possible applications/environments, should be
specified IMHO, unless there is a strong analysis showing this
value is meaningful which I don't see here.
Said differently, why this minimum code rate 0.5 rather than,
for instance, 0.4 or 0.6? Which one is the best value and why?

> In any case I agree with you, Mark, that using FEC codes in a rateless= way
> is definitively useless ;-)
>
> MW> Well, I wouldn't go as far as to suggest that ;-) Perhaps in a = multicast
> streaming environment ...

VR: This is however what you are suggesting with the above
requirement which holds no matter the application/environement,
even if the text mentions "bandwidth" rather than "code rate= s"
(there's a direct mapping between the two concepts).


> 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id" > ----------------------------------------------------------
>
> I don't think that any of the current FEC schemes specifies this
> Generic Explicit Source FEC Payload Id. This is a problem...
>
> Besides, how is the 2 byte counter managed? Does it take into account<= BR> > the source block structure or not? It seems that it is the case, but > it is not clearly said that the counter should be reset to 0 at the > beginning of a new source block.
>
> Additionally, the various FEC schemes can have different maximum sourc= e
> block sizes which means that the source block structure can differ. > Maybe we should say that all the FEC schemes MUST share the same
> source block structure if we want the FEC Source Packets to be shared<= BR> > between the various FEC schemes.
>
> MW> This was added rather late. The idea was to allow, in principle= , for a
> source flow to be protected by multiple FEC Schemes without those sche= mes
> having to be aware of each other. But as you say it works only if the<= BR> > schemes support the Generic Explicit Source FEC Payload Id".
>
> MW> It does not take into account the source block structure, rathe= r the
> other way round: the source block structure is constrained by the
> requirement that a source block contains a set of packets with contigu= ous
> sequence numbers.
>
> MW> To use this, the FEC scheme essentially has to specify the sequ= ence
> number range that makes up a source block in each repair packet for th= e
> block (or in sufficient of the repair packets that it is sufficiently = likely
> it will be received).

VR: Okay, I understand the possible way of using the counter.
It should perhaps be clarified in the document if this Generic
Explicit Source FEC Payload Id is to remain.


Regards,

  Vincent

 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Review of draft-ietf-fecframe-framework-03 Thread-Index: AcnSKOxSI+W5zmFUSKu8ghnALYL2ZAALNEtiAAQblXA= References: <4A080736.7040600@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Watson, Mark" , "Vincent Roca" X-OriginalArrivalTime: 11 May 2009 18:29:20.0887 (UTC) FILETIME=[66BC1870:01C9D266] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10667; t=1242066561; x=1242930561; 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]=20Review=20of=20draft-ietf-f ecframe-framework-03 |Sender:=20; bh=mrwU2EVV4XG4OtZgux0WPO5i8UbE7iFoMWz/dzp96qg=; b=HZyoWfS2HANcgnetvvjHJ70Q+OK8PvwujLjFYk/p9DbnWDVrs/suo/u5nr 8zSZ4h4bApeMAabBrg+SxjB3nnEfxONkyL9oA37o8uTkMMK1intgSYBr2UVC hZ6rpdCGkn; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: fecframe@ietf.org Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-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: Mon, 11 May 2009 18:27:51 -0000 > MW2> We do. I just want to check everyone else is happy with this. I am OK with the definitions here. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Watson, > Mark > Sent: Monday, May 11, 2009 9:30 AM > To: Vincent Roca > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-03 >=20 > HI Vincent, >=20 > Thanks for your response. Some further comments inline marked = =91MW2=92. There are perhaps two > issues which require discussion/confirmation from the list: > (1) The change in terminology from =93Source Transport Payloads=94 to = =93Application Data Unit=94 > (2) The explicit requirement that repair bandwidth must not exceed = source bandwidth: I=92d > especially like to hear from Magnus. I have no objection to relaxing = this if the remaining > text is likely to be acceptable to the IESG to address the congestion = issue, but I am not > sure that is the case. >=20 > ...Mark >=20 > On 5/11/09 4:08 AM, "Vincent Roca" wrote: >=20 >=20 >=20 > Hello Mark, >=20 > Since we agree for most comments, I only leave below the ones for = which > we still need to discuss. >=20 >=20 > > 1/ Terminology: > > --------------- > [...] >=20 > VR: So, to summarize our discussion, here is the current proposal: >=20 > At the sender, from top to bottom: >=20 > * the application layer provides "Application Data Units", through > one or several "Source Data Flow(s)". >=20 > * a certain number of "Application Data Units" are gathered in a > "Source Block". >=20 > * after the F, L and padding fields have been added to each > "Application Data Unit" for the purpose of FEC encoding, the > resulting unit of data is called the "Application Data Unit > Information (ADUI)". > NB: this comes from the Raptor I-D >=20 > * from the FEC scheme point of view, we now have "Source Symbols" > (i.e., a subset of the "Application Data Unit Information") and > "Repair Symbols". They are globally called "Encoding Symbols". > NB: this is in line with the RMT WG terminology used for FEC = schemes >=20 > * the unit of data containing the source information (i.e., an > "Application Data Unit") plus the "Explicit Source FEC Payload ID" > (if used), is now called the "FEC Source Packet". It is given to > the transport protocol. >=20 > * the unit of data containing repair information, plus the "Repair = FEC > Payload ID", is now called "FEC Repair Packet". It can contain one = or > more "Repair Symbols" depending on the FEC scheme. It is given to = the > transport protocol. >=20 > Do we agree? >=20 >=20 >=20 > MW2> We do. I just want to check everyone else is happy with this. >=20 >=20 >=20 >=20 > > Then we must make sure that the agreed terminology, and only it, is = used in > > this I-D and others. >=20 > VR: ...the necessary second step! >=20 >=20 > > 2/ Section 6.5. "FEC Framework Configuration Information" > > --------------------------------------------------------- > > > > I have several comments WRT the pieces of information included in = the FFCI. > > > [...] > > 2.2/ It is said: > > " b. An integer identifier for this flow definition (i.e. > > tuple). This identifier MUST be unique amongst all source > > packet flows which are protected by the same FEC repair = flow." > > > > So, if I follow this text, if a source flow is protected by 2 FEC = repair > > flows, this source flow can be assigned two different identifiers. = This is > > a bit strange! I suggest that the identifier be unique among a FEC > > framework instance. The drawback I see, however, when this = identifier is > > encoded in a single byte (e.g. Raptor or R-), is the limited number = (256) of > > source data flows that can be protected globally. But is 256 really = an > > issue? > > > > MW> No, each source flow is assigned a single identifier (I can = make this > > clearer). The uniqueness requirement is that if two source flows = are > > protected by a single repair flow, then the two source flows must = have > > different identifiers. >=20 > VR: Sorry, but I still don't see clearly to what extent the > identifier should be unique in your answer. When you say: > "each source flow is assigned a single identifier", is it > for the whole fecframe instance or not? And the second sentence > of your answer does not clarify this at all. >=20 >=20 >=20 > MW2> Re-reading this, in fact what is stated is equivalent to = requiring uniqueness within > a framework instance. What is stated is that for each repair flow, = every source flow > protected by that repair flow must have a different identifier from = every other source > flow protected by the same repair flow. I.e. Source flows that are to = be combined into a > single source block must have different identifiers. But a set of = source flows that are to > be protected together is exactly what characterises a framework = instance. I don=92t think > the framework draft limits this flow identifier to 1 byte =96 though I = may have missed that. > Certainly the Raptor draft does limit it. I don=92t think the = framework draft needs to > provide a limit, but it does need to require that values are allocated = from zero upwards. >=20 >=20 >=20 > > 4/ Section 9.1 "Normative requirements" > > --------------------------------------- > > > > I do understand and agree with the fact that there is a reasonable = limit to > > the > > repair overhead. However I'm wondering if it makes sense to provide = an > > actual > > figure. This limit depends on the target use-case, and the = framework I-D > > specifies the architecture, not the use-case. >=20 > [...] > > I suggest to have a less directive text, like: > > > > The bandwidth of FEC Repair packet flows MUST NOT exceed a certain = threshold > > of the bandwidth of the source packet flows being protected. This = threshold > > depends on the use-case where the FEC framework is used. When = transmissions > > take place over Internet, the bandwidth of the FEC Repair packet = flow(s) of > > a > > single FEC framework instance MUST NOT exceed the bandwidth of the = source > > packet flow(s). > > > > MW> We have to be careful here. Currently, the framework avoids = causing > > congestion control problems by specifying this hard requirement = that bounds > > the repair bandwidth by the source bandwidth. We can then be sure = that the > > repair bandwidth will be subject to the same congestion control = response as > > the source flows. >=20 > VR: I do agree that we need to be careful here. > As already said in section 9, the only goal is to: > "require at a minimum that the use of this framework > with any given application, in any given environment, > does not cause congestion issues which the application > alone would not itself cause" >=20 > The second constraint is for sure needed. But the first constraint > is application/environment specific and no numerical value, > applicable to all possible applications/environments, should be > specified IMHO, unless there is a strong analysis showing this > value is meaningful which I don't see here. > Said differently, why this minimum code rate 0.5 rather than, > for instance, 0.4 or 0.6? Which one is the best value and why? >=20 > > In any case I agree with you, Mark, that using FEC codes in a = rateless way > > is definitively useless ;-) > > > > MW> Well, I wouldn't go as far as to suggest that ;-) Perhaps in a = multicast > > streaming environment ... >=20 > VR: This is however what you are suggesting with the above > requirement which holds no matter the application/environement, > even if the text mentions "bandwidth" rather than "code rates" > (there's a direct mapping between the two concepts). >=20 >=20 >=20 > MW2> There are many ways rateless codes can be useful. There is only a = direct mapping > between bandwidth and code rate if you always send all the symbols. So = for example there > are applications where it is useful to be able to generate many more = symbols than you > eventually send. In terms of congestion control, it is bandwidth which = is the concern, not > the rate of the code from which the symbols were taken. >=20 >=20 >=20 > > 6/ Section 6.3.1. "Generic Explicit Source FEC Payload Id" > > ---------------------------------------------------------- > > > > I don't think that any of the current FEC schemes specifies this > > Generic Explicit Source FEC Payload Id. This is a problem... > > > > Besides, how is the 2 byte counter managed? Does it take into = account > > the source block structure or not? It seems that it is the case, = but > > it is not clearly said that the counter should be reset to 0 at the > > beginning of a new source block. > > > > Additionally, the various FEC schemes can have different maximum = source > > block sizes which means that the source block structure can differ. > > Maybe we should say that all the FEC schemes MUST share the same > > source block structure if we want the FEC Source Packets to be = shared > > between the various FEC schemes. > > > > MW> This was added rather late. The idea was to allow, in = principle, for a > > source flow to be protected by multiple FEC Schemes without those = schemes > > having to be aware of each other. But as you say it works only if = the > > schemes support the Generic Explicit Source FEC Payload Id". > > > > MW> It does not take into account the source block structure, = rather the > > other way round: the source block structure is constrained by the > > requirement that a source block contains a set of packets with = contiguous > > sequence numbers. > > > > MW> To use this, the FEC scheme essentially has to specify the = sequence > > number range that makes up a source block in each repair packet for = the > > block (or in sufficient of the repair packets that it is = sufficiently likely > > it will be received). >=20 > VR: Okay, I understand the possible way of using the counter. > It should perhaps be clarified in the document if this Generic > Explicit Source FEC Payload Id is to remain. >=20 >=20 >=20 > MW2> Sure. >=20 >=20 >=20 > Regards, >=20 > Vincent >=20 >=20 From tme@americafree.tv Wed May 13 11:19:46 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 8C95C28C21E for ; Wed, 13 May 2009 11:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC+qZfkUT1dr for ; Wed, 13 May 2009 11:19:46 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 2D8C928C202 for ; Wed, 13 May 2009 11:19:45 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 827A83CAE0F8 for ; Wed, 13 May 2009 14:21:17 -0400 (EDT) Message-Id: <0B942159-446E-40F6-9EA7-9B48D35108B1@americafree.tv> From: Marshall Eubanks To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 13 May 2009 14:21:17 -0400 References: <20090513180513.6619B28C203@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: [Fecframe] Fwd: 75th IETF - WG/BOF Scheduling 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, 13 May 2009 18:19:46 -0000 Note well. Begin forwarded message: > From: IETF Agenda > Date: May 13, 2009 2:05:13 PM EDT > To: Working Group Chairs > Cc: irsg@isi.edu, bofchairs@ietf.org > Subject: 75th IETF - WG/BOF Scheduling > > ----------------------------------------------------------------- > 75th IETF =96 Stockholm, Sweden > Meeting Dates: July 26-31, 2009 > Host: .SE > ----------------------------------------------------------------- > IETF meetings start Monday morning and run through Friday mid-=20 > afternoon > (15:15). > > We are accepting scheduling requests for all Working Groups and BOFs > starting. The milestones and deadlines for scheduling-related =20 > activities > are as follows: > > NOTE: cutoff dates are subject to change. > > May 25, Monday - Cutoff date for requests to schedule Working Group > meetings and for preliminary BOF proposals to ADs at 17:00 PDT (24:00 > UTC/GMT). > June 8, Monday - Cutoff date for requests to Area Directors to =20 > schedule > BOFs at 17:00 PDT (24:00 UTC/GMT). > June 15, Monday - Cutoff date for Area Directors to approve BOFs at =20= > 17:00 > PDT (24:00 UTC/GMT). > June 19, Friday - Preliminary agenda published for comment. > July 1, Wednesday - Cutoff date for requests to reschedule Working =20 > Group > and BOF meetings 17:00 PDT (24:00 UTC/GMT). > July 6, Monday - Final agenda to be published. > July 15, Wednesday - Draft Working Group agendas due by 17:00 PT =20 > (24:00 > UTC/GMT). > July 20, Monday - Revised Working Group agendas due by 17:00 PT (24:00 > UTC/GMT). > > Submitting Requests for Working Group and BOF Sessions > > Please submit requests to schedule your Working Group sessions using =20= > the > "IETF Meeting Session Request Tool," a Web-based tool for submitting =20= > all > of the information that the Secretariat requires to schedule your > sessions. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > Please send requests to schedule your BOF sessions to agenda@ietf.org. > Please include the acronym of your BOF in the subject line of the =20 > message, > and include all of the information specified in item (4) of =20 > "Requesting > Meeting Sessions at IETF Meetings" in the body. (This document is > included below.) > > Submitting Session Agendas > > For the convenience of meeting attendees, we ask that you submit the > agendas for your Working Group sessions as early as possible. Draft > Working Group agendas are due Wednesday, July 15 by 17:00 PDT (24:00 > UTC/GMT). Revised Working Group agendas are due no later than Monday, > July 20 at 17:00 PDT (24:00 UTC/GMT). The proposed agenda for a BOF > session should be submitted along with your request for a session. =20= > Please > be sure to copy your Area Director on that message. > > Please submit the agendas for your Working Group sessions using the =20= > "IETF > Meeting Materials Management Tool," a Web-based tool for making your > meeting agenda, minutes, and presentation slides available to the > community before, during, and after an IETF meeting. If you are a BOF > chair, then you may use the tool to submit a revised agenda as well as > other materials for your BOF once the BOF has been approved. > > The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi > > Additional information about this tool is available at: > > http://www.ietf.org/instructions/meeting_materials_tool.html > > Agendas submitted via the tool will be available to the public on the > "IETF Meeting Materials" Web page as soon as they are submitted. > > The URL for the "IETF 75 Meeting Materials" Web page is: > > = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D75= > > If you are a Working Group chair, then you already have accounts on =20= > the > "IETF Meeting Session Request Tool" and the "IETF Meeting Materials > Management Tool." The same User ID and password will work for both =20= > tools. > If you are a BOF chair who is not also a Working Group chair, then =20= > you > will be given an account on the "IETF Meeting Materials Management =20 > Tool" > when your BOF has been approved. If you require assistance in using > either tool, or wish to report a bug, then please send a message to: > ietf-action@ietf.org. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience, comprehensive information on requesting meeting > sessions at IETF 75 is presented below: > > 1. Requests to schedule Working Group sessions should be submitted =20 > using > the "IETF Meeting Session Request Tool," a Web-based tool for =20 > submitting > all of the information required by the Secretariat to schedule your > sessions. The URL for the tool is: > > https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi > > Instructions for using the tool are available at: > > http://www.ietf.org/instructions/session_request_tool_instruction.html > > If you require an account on this tool, or assistance in using it, =20 > then > please send a message to ietf-action@ietf.org. If you are unable to =20= > use > the tool, then you may send your request via e-mail to =20 > agenda@ietf.org, > with a copy to the appropriate Area Director(s). > > Requests to schedule BOF sessions must be sent to agenda@ietf.org =20 > with a > copy to the appropriate Area Director(s). > > When submitting a Working Group or BOF session request by e-mail, =20 > please > include the Working Group or BOF acronym in the Subject line. > > 2. BOFs will NOT be scheduled unless the Area Director(s) approved > request is accompanied by a BOF'S FULL NAME AND ACRONYM, AREA, =20 > CHAIR(S) > NAME(S) (given together with e-mail address(es)), AN AGENDA AND FULL > DESCRIPTION, and the information requested in (4) below. (Please =20 > read the > BOF Procedure at: http://www.ietf.org/ietf/1bof-procedures.txt before > requesting a session for a BOF.) > > 3. A Working Group may request either one or two sessions. If your > Working Group requires more than two sessions, then your request =20 > must be > approved by an Area Director. Additional sessions will be assigned, =20= > based > on availability, after Wednesday, July 1 at 17:00 PDT (24:00 UTC/=20 > GMT), the > cut-off date for requests to reschedule a session. > > 4. You MUST provide the following information before a Working Group =20= > or > BOF session will be scheduled: > > a. Working Group or BOF full name with acronym in brackets: > > b. AREA under which Working Group or BOF appears: > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > d. Expected Attendance (figures from the 74th IETF meeting are > included at the end of this message): > > e. Special requests: > > f. Number of sessions: > > g. Length of session: > - 1 hour > - 1 1/2 hours > - 2 hours > - 2 1/2 hours > > For more information on scheduling Working Group and BOF sessions, =20 > please > refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and =20 > Procedures" > (http://www.ietf.org/rfc/rfc2418.txt). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > For your convenience please find here a list of the IETF Area =20 > Directors > with their e-mail addresses: > > IETF Chair > Russ Housley > > Applications Area (app) > Lisa Dusseault > Alexey Melnikov > > Internet Area (int) > Jari Arkko > Ralph Droms > > Operations & Management Area (ops) > Ronald Bonica > Dan Romascanu > > Real-time Applications and Infrastructure Area (rai) > Cullen Jennings > Robert Sparks > > Routing Area (rtg) > Ross Callon > Adrian Farrel > > Security Area (sec) > Pasi Eronen > Tim Polk > > Transport Area (tsv) > Lars Eggert > Magnus Westerlund > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 74th IETF Meeting Attendance Number > > 6ai 189 > 6lowpan NO SHEETS > 6man 138 > alto 112 > ancp 21 > apparea (AG) 92 > atoca 77 > autoconf 34 > avt 77 > avt (2nd session) 65 > behave 150 > behave (2nd session) 116 > bliss 64 > bmwg 23 > capwap 16 > ccamp 76 > ccamp (2nd session) 55 > csi 16 > dccp 18 > dhc 50 > dime 31 > dkim 46 > dnsop 90 > drinks 69 > dtnrg (RG) 44 > ecrit 80 > emu 35 > fecframe 17 > forces 20 > geopriv 68 > grow 75 > hiprg (RG) 38 > hokey 40 > httpbis 25 > idnabis 70 > idnabis (2nd session) 41 > idr 127 > intarea (AG) 207 > ipfix 32 > ippm 46 > ipsecme 44 > isms 25 > keyprov 24 > kitten 11 > krb-wg 26 > l2vpn 149 > l3vpn 48 > ledbat 30 > lisp 176 > manet 45 > mboned 37 > mediactrl 47 > mext 96 > mif 68 > mip4 35 > mipshop 57 > mmox 77 > mmusic 75 > morg 15 > mpls 144 > mpls (2nd session) 135 > msec 30 > nea 28 > netconf 39 > netext 68 > netmod 25 > netmod (2nd session) 32 > nfsv4 22 > nsis 23 > oauth 105 > opsarea (AG) 86 > opsec 24 > ospf 34 > p2prg 99 > p2psip 71 > pce 63 > pcn 24 > pim 41 > pkix 50 > pmol 27 > pre8prob 44 > pwe3 115 > radext 19 > rtgarea (AG) 122 > rmt 12 > roll 69 > rrg (RG) 106 > rtgwg 112 > saag (AG) 116 > sasl 24 > savi 60 > shara 155 > sidr 77 > sieve 17 > simple 69 > sip 126 > sip (2nd session) 117 > sipping 92 > softwire 73 > speermint 63 > storm 14 > tcpm 33 > tcpm (2nd session) 59 > tictoc 37 > tls 44 > trill 55 > tsvarea (AG) 72 > tsvwg 47 > v6ops 126 > v6ops (second session) 65 > vcarddav 18 > xcon 48 > xmpp2 86 > yam 41 > > Regards Marshall Eubanks CEO / AmericaFree.TV From root@core3.amsl.com Sun May 24 23: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 3A07A3A69B1; Sun, 24 May 2009 23:15:00 -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: <20090525061501.3A07A3A69B1@core3.amsl.com> Date: Sun, 24 May 2009 23:15:01 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 06:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : RTP Payload Format for Non-Interleaved and Interleaved Parity FEC Author(s) : A. Begen Filename : draft-ietf-fecframe-1d2d-parity-scheme-01.txt Pages : 39 Date : 2009-05-24 This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-1d2d-parity-scheme-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-1d2d-parity-scheme-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-24231440.I-D@ietf.org> --NextPart-- From abegen@cisco.com Sun May 24 23:29: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 D33543A6E45; Sun, 24 May 2009 23:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 jDQRB6wanTxV; Sun, 24 May 2009 23:29:30 -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 EE4CA3A6E53; Sun, 24 May 2009 23:29:29 -0700 (PDT) X-Files: draft-ietf-fecframe-1d2d-parity-scheme-01.URL : 106 X-IronPort-AV: E=Sophos;i="4.41,243,1241395200"; d="url'?scan'208";a="310169651" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 May 2009 06:31:11 +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 n4P6VAY0029277; Sun, 24 May 2009 23:31:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4P6VAEI024700; Mon, 25 May 2009 06:31:10 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 May 2009 23:31:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9DD02.648F38B7" Date: Sun, 24 May 2009 23:31:03 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54095E1974@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] I-D Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt Thread-Index: AcndALTE0vhLEce8TlyfMdInJpEN8QAAVY7A From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 25 May 2009 06:31:10.0661 (UTC) FILETIME=[64BDE750:01C9DD02] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2889; t=1243233070; x=1244097070; 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=20[Fecframe]=20I-D=20Action=3Adraft-ietf- fecframe-1d2d-parity-scheme-01.txt |Sender:=20; bh=N0Ho0xnHO2Q1MY+iFtLSNrVSPa+XkWoPOOI5bLoq3bo=; b=bvXuLgr8QpOrDScAyOGXFjt96YXv/clf2KbS+pro9dsgHB0CD0GXkgxZjk /xy4u7cTbanCrlOeGp+AFwagsp5XWpYLKOJHf+D+4g99gFU8JAllxFCK8zbb 72itUcFfHn; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: avt@ietf.org Subject: [Fecframe] FW: I-D Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2009 06:29:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9DD02.648F38B7 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I completed the missing sections and fixed a few editorial issues. This = version should be a complete one. Comments are welcome. http://www.ietf.org/internet-drafts/draft-ietf-fecframe-1d2d-parity-schem= e-01.txt -acbegen -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Internet-Drafts@ietf.org Sent: Sunday, May 24, 2009 11:15 PM To: i-d-announce@ietf.org Cc: fecframe@ietf.org Subject: [Fecframe] I-D = Action:draft-ietf-fecframe-1d2d-parity-scheme-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the FEC Framework Working Group of the = IETF. Title : RTP Payload Format for Non-Interleaved and = Interleaved Parity FEC Author(s) : A. Begen Filename : draft-ietf-fecframe-1d2d-parity-scheme-01.txt Pages : 39 Date : 2009-05-24 This document defines new RTP payload formats for the Forward Error Correction (FEC) that is generated by the non-interleaved and interleaved parity codes from a source media encapsulated in RTP. These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The non-interleaved and interleaved parity codes offer a good protection against random and bursty packet losses, respectively, at a cost of decent complexity. The RTP payload formats that are defined in this document address the scalability issues experienced with the earlier specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and offer several improvements. Due to these changes, the new payload formats are not backward compatible with the earlier specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-1d2d-parity-schem= e-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C9DD02.648F38B7 Content-Type: application/octet-stream; name="draft-ietf-fecframe-1d2d-parity-scheme-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-fecframe-1d2d-parity-scheme-01.URL Content-Disposition: attachment; filename="draft-ietf-fecframe-1d2d-parity-scheme-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWZlY2ZyYW1lLTFkMmQtcGFyaXR5LXNjaGVtZS0wMS50eHQNCg== ------_=_NextPart_001_01C9DD02.648F38B7-- From magnus.westerlund@ericsson.com Wed May 27 06: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 7E6343A687B for ; Wed, 27 May 2009 06:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 L8oaH6LVs210 for ; Wed, 27 May 2009 06:32:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 53FEA3A67AA for ; Wed, 27 May 2009 06:32:26 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-96-4a1d4118d2bc Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 4E.BD.30868.8114D1A4; Wed, 27 May 2009 15:33:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 15:33:12 +0200 Received: from [147.214.183.61] ([147.214.183.61]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 May 2009 15:33:11 +0200 Message-ID: <4A1D4117.1000008@ericsson.com> Date: Wed, 27 May 2009 15:33:11 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Watson, Mark" References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 May 2009 13:33:11.0467 (UTC) FILETIME=[ADF1C7B0:01C9DECF] X-Brightmail-Tracker: AAAAAA== Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-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, 27 May 2009 13:32:27 -0000 Watson, Mark skrev: > (2) The explicit requirement that repair bandwidth must not exceed > source bandwidth: I’d especially like to hear from Magnus. I have no > objection to relaxing this if the remaining text is likely to be > acceptable to the IESG to address the congestion issue, but I am not > sure that is the case. Hi, Catching up on the WG. When it comes to congestion control it is a required feature for general network usage. Under some circumstances one can clearly use the framework without congestion control due to dedicated resources. However, in general one need a mechanism to detect also failure cases when one has dedicated resources. I don't have an issue with making it clear that with dedicated/reserved resources it is acceptable to not have congestion control, although if possible it is recommended. For general Internet usage one clearly needs to be congestion responsive. It is the WG's responsibility to ensure that you have such a mechanism in place. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 watson@qualcomm.com Wed May 27 15:08:32 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 F355F3A6ED2 for ; Wed, 27 May 2009 15:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.735 X-Spam-Level: X-Spam-Status: No, score=-105.735 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQMS88O0EVQW for ; Wed, 27 May 2009 15:08:26 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 19F7A3A6E8D for ; Wed, 27 May 2009 15:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1243462209; x=1274998209; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20|To:=20M agnus=20Westerlund=20|CC: =20Vincent=20Roca=20,=0D=0A=20 =20=20=20=20=20=20=20"fecframe@ietf.org"=0D=0A=09|Date:=20Wed,=2027=20May=202009=2015:09:55=20- 0700|Subject:=20Re:=20[Fecframe]=20Review=20of=20draft-ie tf-fecframe-framework-03|Thread-Topic:=20[Fecframe]=20Rev iew=20of=20draft-ietf-fecframe-framework-03|Thread-Index: =20Acnez7bRgAbxTtqBS1i7Po3+bm8o3wASCasT|Message-ID:=20|In-Reply-To:=20<4A1D411 7.1000008@ericsson.com>|Accept-Language:=20en-US |Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C64308432DEC4watsonqualcommcom_"|MIME-Version: =201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5628" =3B=20a=3D"18664663"; bh=BF8a2fBvyqfeimNKc1hftgYQnxm3w/9iwgNQGogSJH8=; b=UjOW5dAJRIBN1n9ziiyT2duNPMc4afYTNHQpWwykunRS75nUEGvAYypn d3Fwpa4wEvRiVBELWugtnKwp9ttwbqs8HYd+Wm3av3WjUNDYeOyhsZDlA p8KJ05CPI2piq0fD6JHidIcNmnj+rS1TtjMJdT3uK9tNRl9I72+yeWiFt w=; X-IronPort-AV: E=McAfee;i="5300,2777,5628"; a="18664663" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2009 15:10:08 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4RMA8lZ013892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 15:10:08 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4RM9wap017905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 May 2009 15:09:58 -0700 (PDT) Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 27 May 2009 15:09:58 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Wed, 27 May 2009 15:09:57 -0700 From: "Watson, Mark" To: Magnus Westerlund Date: Wed, 27 May 2009 15:09:55 -0700 Thread-Topic: [Fecframe] Review of draft-ietf-fecframe-framework-03 Thread-Index: Acnez7bRgAbxTtqBS1i7Po3+bm8o3wASCasT Message-ID: In-Reply-To: <4A1D4117.1000008@ericsson.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C64308432DEC4watsonqualcommcom_" MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-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, 27 May 2009 22:08:32 -0000 --_000_C64308432DEC4watsonqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Magnus, What we have (effectively) said is that the use of FECFRAME should not make= the application less responsive to congestion than it was before the FEC f= low was added. You write "For general Internet usage one clearly needs to be congestion re= sponsive. It is the WG's responsibility to ensure that you have such a mech= anism in place.". Now, if all the IETF-standardised protocols that might be= used as source flows with FECFRAME were congestion responsive, we would ha= ve no problem: we could always rely on the source flow responding to conges= tion and we require that the repair flow follows the source flow. However, there exist source protocols which are not congestion responsive -= for example RTP. Are you saying that the FECFRAME group needs to provide a= congestion-controlled version of RTP before the FECFRAME work can be publi= shed ? Or that we need to define a generic congestion control to be applied= to any FECFRAME flows (source + repair - there would seem to be no point i= n having only the repair flow respond to congestion). This would seem to be= the only way to discharge a 'responsibility to ensure that we have such a = mechanism in place'. ...Mark On 5/27/09 6:33 AM, "Magnus Westerlund" wr= ote: Watson, Mark skrev: > (2) The explicit requirement that repair bandwidth must not exceed > source bandwidth: I'd especially like to hear from Magnus. I have no > objection to relaxing this if the remaining text is likely to be > acceptable to the IESG to address the congestion issue, but I am not > sure that is the case. Hi, Catching up on the WG. When it comes to congestion control it is a required feature for general network usage. Under some circumstances one can clearly use the framework without congestion control due to dedicated resources. However, in general one need a mechanism to detect also failure cases when one has dedicated resources. I don't have an issue with making it clear that with dedicated/reserved resources it is acceptable to not have congestion control, although if possible it is recommended. For general Internet usage one clearly needs to be congestion responsive. It is the WG's responsibility to ensure that you have such a mechanism in place. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_C64308432DEC4watsonqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] Review of draft-ietf-fecframe-framework-03 Magnus,

What we have (effectively) said is that the use of FECFRAME should not make= the application less responsive to congestion than it was before the FEC f= low was added.

You write “For general Internet usage one clearly needs to be congest= ion responsive. It is the WG's responsibility to ensure that you have such = a mechanism in place.”. Now, if all the IETF-standardised protocols t= hat might be used as source flows with FECFRAME were congestion responsive,= we would have no problem: we could always rely on the source flow respondi= ng to congestion and we require that the repair flow follows the source flo= w.

However, there exist source protocols which are not congestion responsive &= #8211; for example RTP. Are you saying that the FECFRAME group needs to pro= vide a congestion-controlled version of RTP before the FECFRAME work can be= published ? Or that we need to define a generic congestion control to be a= pplied to any FECFRAME flows (source + repair – there would seem to b= e no point in having only the repair flow respond to congestion). This woul= d seem to be the only way to discharge a ‘responsibility to ensure th= at we have such a mechanism in place’.

...Mark

 


On 5/27/09 6:33 AM, "Magnus Westerlund" <magnus.westerlund@ericsson.com> wrote:

Watson, Mark skrev:
> (2) The explicit requirement that repair bandwidth must not exceed
> source bandwidth: I’d especially like to hear from Magnus. I hav= e no
> objection to relaxing this if the remaining text is likely to be
> acceptable to the IESG to address the congestion issue, but I am not > sure that is the case.

Hi,

Catching up on the WG. When it comes to congestion control it is a
required feature for general network usage. Under some circumstances one can clearly use the framework without congestion control due to
dedicated resources. However, in general one need a mechanism to detect
also failure cases when one has dedicated resources.

I don't have an issue with making it clear that with dedicated/reserved
resources it is acceptable to not have congestion control, although if
possible it is recommended. For general Internet usage one clearly needs to be congestion responsive. It is the WG's responsibility to ensure
that you have such a mechanism in place.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB           &nb= sp;    | Phone  +46 10 7148287
Färögatan 6          = ;      | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_C64308432DEC4watsonqualcommcom_-- From magnus.westerlund@ericsson.com Thu May 28 01:38:20 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 D3FB23A685C for ; Thu, 28 May 2009 01:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 GTAE5i5l5JkB for ; Thu, 28 May 2009 01:38:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 86A0E3A698C for ; Thu, 28 May 2009 01:38:19 -0700 (PDT) X-AuditID: c1b4fb3e-b7b78ae000007894-52-4a1e4de0ffc2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 15.FB.30868.0ED4E1A4; Thu, 28 May 2009 10:40:00 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 May 2009 10:39:59 +0200 Received: from [147.214.183.61] ([147.214.183.61]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 May 2009 10:39:59 +0200 Message-ID: <4A1E4DDF.9000203@ericsson.com> Date: Thu, 28 May 2009 10:39:59 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Watson, Mark" References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 May 2009 08:39:59.0655 (UTC) FILETIME=[E2D20B70:01C9DF6F] X-Brightmail-Tracker: AAAAAA== Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Review of draft-ietf-fecframe-framework-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, 28 May 2009 08:38:20 -0000 Watson, Mark skrev: > Magnus, > > What we have (effectively) said is that the use of FECFRAME should not > make the application less responsive to congestion than it was before > the FEC flow was added. > > You write “For general Internet usage one clearly needs to be congestion > responsive. It is the WG's responsibility to ensure that you have such a > mechanism in place.”. Now, if all the IETF-standardised protocols that > might be used as source flows with FECFRAME were congestion responsive, > we would have no problem: we could always rely on the source flow > responding to congestion and we require that the repair flow follows the > source flow. > > However, there exist source protocols which are not congestion > responsive – for example RTP. Are you saying that the FECFRAME group > needs to provide a congestion-controlled version of RTP before the > FECFRAME work can be published ? Or that we need to define a generic > congestion control to be applied to any FECFRAME flows (source + repair > – there would seem to be no point in having only the repair flow respond > to congestion). This would seem to be the only way to discharge a > ‘responsibility to ensure that we have such a mechanism in place’. I wouldn't classify RTP as congestion unresponsive. With RTCP it is possible to react on a bit longer than RTT timescales. That can at least prevent congestion collapse. However, SSM deployements makes things more difficult. For unicast it can clearly work if you implement things, which has been the major issue with RTP reaction to congestion. What I want in the architecture document is a discussion of the issues around congestion control, and when it is possible to not have it. To make it clear that for certain type of deployment may need more mechanism that what is available currently. I would prefer that you had a full solution for all usages, but I am not going to require it. This is useful stuff and in a number of deployments this will not be an issue. In others this will need to be taken very seriously. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------