From gjshep@gmail.com Fri Oct 2 07:54: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 05DAA3A68B8 for ; Fri, 2 Oct 2009 07:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-1.933, BAYES_50=0.001, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPn3jvJiRmuP for ; Fri, 2 Oct 2009 07:54:16 -0700 (PDT) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id D678D3A6804 for ; Fri, 2 Oct 2009 07:54:15 -0700 (PDT) Received: by qyk29 with SMTP id 29so972465qyk.32 for ; Fri, 02 Oct 2009 07:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=WOieidaUlVuOzp1Jwt37AhwwlY3KAxa7D+hLGglExCM=; b=G1yHfIoTf6GrklTlk/g1dZ5JZWE+CqDIaZQyNc+iZpRavmJrBHSxIcBWH2Y9/kIEgJ RP5hiad8yElOH+HmA4uTxmEcCjbOzGoIWP8qOOgG33XdQhmrf/N6gqroIHqLuXkHXm+9 3mPKILKfKYhSXCFEJhBxLYWGDd+4Mf6UvACNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; b=GFMQuX+lihuePwy2HKoqbxKs19IjhivlqqXvV5UkKLQw+sXCnqqGFfwhab2tymOEl6 qaBxaBtfY/utA9/fYpSC2GVvL4DLPDg19j+7rp3ffeWGvBehrqrIWjfZ5kDGv/DMwMMi +9hZ6eSjFsjOAMumJpMKCL+aQvYqVjrjER1ro= MIME-Version: 1.0 Received: by 10.229.119.131 with SMTP id z3mr2959088qcq.37.1254495340703; Fri, 02 Oct 2009 07:55:40 -0700 (PDT) Date: Fri, 2 Oct 2009 07:55:40 -0700 Message-ID: <38c19b540910020755g558a461x5b0aead96f2a5638@mail.gmail.com> From: Greg Shepherd To: "Einat Yellin (Lachover)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tme@multicasttech.com, fecframe@ietf.org Subject: [Fecframe] IS: Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 14:54:18 -0000 Thank you for the discussion. I think we have enough information in this thread to make a determination if we want to take on this work in the FECFrame Working Group. Please respond to this message and indicate whether or not you feel we should adopt: draft-zixuan-fecframe-source-mi ..as a working group item. Thanks, Greg On Mon, Sep 28, 2009 at 11:31 PM, Einat Yellin (Lachover) wrote: > > > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf Of zouzixuan > Sent: Monday, September 28, 2009 10:57 AM > To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover); > tme@multicasttech.com; gjshep@gmail.com; fecframe@ietf.org > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > Hi, Ali > >> I am not questioning backward compatibility, I am questioning the cost > for > it >> and the scenarios where we want backward compatibility. Einat did a > good >> summary, so now the WG needs to provide input. > You mean there should be some input on backward compatibility to the > framework. > > >> Regarding your example, putting the audio and video packets into the > source >> blocks as they are available does not seem to be a good design choice > to > me. >> When I say "systematic," I mean you can create your source blocks in a >> deterministic way (such as 4 packets from stream 1, one packet from > stream > 2). >> Variable-packet size can be handled. > > In this "systematic" case, how could we know the position of a packet in > the > source block? > [Einat] There are different ways to signal the source block structure. > In our draft we followed rfc 5109 and used the 'base' (first) RTP > sequence number along with a bitmap. This works for the cases where what > matters is which RTP packets belong to this FEC source block and the > order of the packets in the FEC source block is deterministic (from > lower SN to higher SN and from lower flow ID to higher flow ID). If a > more detailed structure of source block is needed then I agree that the > bitmap is not enough. Still, this information can be sent as part of the > repair packet header which IMO makes more sense. > > Zou ZiXuan, Senior Research Staff > Media & Communication Lab > HUAWEI TECHNOLOGIES CO.,LTD. > > Address: Huawei Industrial Base > Bantian Longgang > Shenzhen 518129, P.R.China > Tel: +86 0755 28789364 > Fax: +86 0755 28788317 > E-mail: tendyntu@huawei.com > www.huawei.com > ------------------------------------------------------------------------ > ---- > --------------------------------------------------------- > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any > use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: Monday, September 28, 2009 1:40 AM >> To: zouzixuan; Einat Yellin (Lachover); tme@multicasttech.com; >> gjshep@gmail.com; fecframe@ietf.org >> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> >> I am not questioning backward compatibility, I am questioning the cost > for > it >> and the scenarios where we want backward compatibility. Einat did a > good >> summary, so now the WG needs to provide input. >> >> Regarding your example, putting the audio and video packets into the > source >> blocks as they are available does not seem to be a good design choice > to > me. >> When I say "systematic," I mean you can create your source blocks in a >> deterministic way (such as 4 packets from stream 1, one packet from > stream > 2). >> Variable-packet size can be handled. >> >> Cheers, acbegen. >> >> > -----Original Message----- >> > From: zouzixuan [mailto:tendyntu@huawei.com] >> > Sent: Sunday, September 27, 2009 5:59 AM >> > To: 'Einat Yellin (Lachover)'; Ali C. Begen (abegen); > tme@multicasttech.com; >> > gjshep@gmail.com; fecframe@ietf.org >> > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > >> > Hi, Einat, Ali >> > =A0 =A0 =A0Similar to Einat's explanation on "backward compatible" as > stated >> > your draft , our intention is to keep source packet unmodified > without >> > adding source payload id to it. And therefore the non-framework > client > can >> > interpret the source packet. But I'm still not sure if the "backward >> > compatibility" we are referring to here is considered a valuable > requirement >> > in FEC framework. >> > >> > =A0 =A0 =A0I'd like to again use the example we gave in the previous > thread we >> > replied to Ali's doubts to explain the need of source payload id for > RTP >> > flow. Ali, sorry, I was supposed to gave more detailed information > on > this. >> > . >> > =A0 =A0 Here are several assumptions on this example: >> > =A0 =A0 =A01) We assume a FEC-protected audiovisual stream which is >> > combination of a video and a audio RTP flow. ID 0 identify video > source >> > data, and ID 1 identify audio source data. The definition of ID can > be >> > conveyed through SDP >> > =A0 =A0 =A02) RTP packets length is non-equal, e.g. in 16, 17, 19, 15,= 8 >> > bytes, as is shown. >> > =A0 =A0 =A03) A video or audio source packet is fed into a source bloc= k in > an >> > First-come-First-serve order in which the video and audio packets > are >> > generated. >> > >> > =A0 =A0In which case we think the source-pay-load ID is needed. For >> > backward-compatibility, the source payload id can be conveyed in an > separate >> > flow, which could be either an additional flow or the repair flow. >> > >> > =A0 =A0Ali, would you please give a more details on "systematic > approach"? > I'm >> > not following this. >> > >> > 0 =A0 =A0 =A0 =A0 16 =A0 =A0 =A0 =A0 =A0 B0,0 =A0 B0,1 =A0B0,2 =A0 B0,= 3 =A0 B0,4 =A0B0,5 =A0B0,6 >> B0,7 >> > B0,8 =A0B0,9 =A0B0,10 =A0B0,11 =A0B0,12 =A0B0,13 =A0B0,14 =A0B0,15 =A0= 0 =A0 =A00 > 0 >> > >> > 0 =A0 =A0 =A0 =A0 17 =A0 =A0 =A0 =A0 =A0 B1,0 =A0 B1,1 =A0B1,2 =A0 =A0= =A0 B1,3 =A0 B1,4 =A0B1,5 > B1,6 >> > B1,7 >> > B1,8 =A0 =A0 =A0 =A0 =A0B1,9 =A0B1,10 =A0B1,11 =A0 =A0 =A0B1,12 B1,13 = =A0B1,14 =A0 =A0 B1,15 > B1,16 =A00 >> > 0 >> > >> > 1 =A0 =A0 =A0 =A0 19 =A0 =A0 =A0 =A0 =A0 B2,0 =A0 B2,1 =A0B2,2 =A0 B2,= 3 =A0 =A0 =A0 B2,4 =A0B2,5 >> > B2,6 =A0 =A0 =A0 =A0B2,7 >> > B2,8 =A0 =A0 =A0 =A0 =A0B2,9 =A0B2,10 =A0B2,11 =A0 =A0 =A0B2,12 B2,13 = =A0B2,14 =A0 =A0 =A0B2,15 > B2,16 >> B2,17 >> > B2,18 >> > >> > 0 =A0 =A0 =A0 =A0 15 =A0 =A0 =A0 =A0 =A0 B3,0 =A0 B3,1 =A0B3,2 =A0 B3,= 3 =A0 =A0 =A0 B3,4 =A0B3,5 > B3,6 >> > B3,7 >> > B3,8 =A0 =A0 =A0 =A0 =A0B3,9 =A0B3,10 =A0B3,11 =A0 =A0 =A0B3,12 B3,13 = =A0B3,14 =A0 =A0 =A0 0 > 0 > 0 >> > 0 >> > >> > 1 =A0 =A0 =A0 =A0 8 =A0 =A0 =A0 =A0B4,0 =A0 =A0 =A0 B4,1 =A0B4,2 =A0 B= 4,3 =A0 =A0 =A0 B4,4 =A0B4,5 > B4,6 >> > B4,7 >> > >> > So here I think if we want to have answer on the necessity of the > things > in >> > our draft, we need to at first have conclusions on the following: 1) > whether >> > the "back compatibility" Elinat and me are referring to is a real > issue > to >> > be considered in FEC framework, And 2) if some cases like this one, > which >> > demands source payload id, stands and is representative. >> > >> > Cheers >> > Zou ZiXuan, Senior Research Staff >> > Media & Communication Lab >> > HUAWEI TECHNOLOGIES CO.,LTD. >> > >> > Address: Huawei Industrial Base >> > Bantian Longgang >> > Shenzhen 518129, P.R.China >> > Tel: +86 0755 28789364 >> > Fax: +86 0755 28788317 >> > E-mail: tendyntu@huawei.com >> > www.huawei.com >> > > ------------------------------------------------------------------------ > ---- >> > --------------------------------------------------------- >> > This e-mail and its attachments contain confidential information > from >> > HUAWEI, which >> > is intended only for the person or entity whose address is listed > above. > Any >> > use of the >> > information contained herein in any way (including, but not limited > to, >> > total or partial >> > disclosure, reproduction, or dissemination) by persons other than > the >> > intended >> > recipient(s) is prohibited. If you receive this e-mail in error, > please >> > notify the sender by >> > phone or email immediately and delete it! >> > >> > > -----Original Message----- >> > > From: Einat Yellin (Lachover) [mailto:Einat@radvision.com] >> > > Sent: Thursday, September 24, 2009 1:24 PM >> > > To: zouzixuan; Ali C. Begen (abegen); fecframe@ietf.org >> > > Cc: tme@multicasttech.com >> > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > >> > > Hi, >> > > Backward compatibility is a major requirement for FEC framework, > no >> > > doubt. I believe that the discussion here is around whether a > separate >> > > flow for FEC mapping information is required. >> > > >> > > While following the discussion, I can relate to the reasons why > not >> > > having a separate flow as claimed by Ali: >> > > a. This is a redundant flow since this information can be conveyed > in >> > > the FEC repair flow and in SDP even when protecting multiple RTP > flows >> > > (specifically you can see an example in >> > > draft-galanos-fecframe-rtp-reedsolomon-mf-00). >> > > b. This separate flow for mapping is also useful only for > receivers > that >> > > support this draft, so the backward compatibility issue remains > the > same >> > > as for the case where mapping is specified in the repair flow. >> > > c. A separate flow increases the chance of losing packets. >> > > >> > > I must say that I don't understand the reasons for using a > separate >> > > flow. >> > > Mr. Zou ZiXuan, is this meant for systems that do not use SDP? >> > > >> > > Best, >> > > Einat >> > > -----Original Message----- >> > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] > On >> > > Behalf Of zouzixuan >> > > Sent: Thursday, September 24, 2009 6:24 AM >> > > To: 'Ali C. Begen (abegen)'; fecframe@ietf.org >> > > Cc: tme@multicasttech.com >> > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > >> > > Hi, Ali >> > > =A0 It's a good suggestion that others join the discussion on this. >> > > The >> > > point here is that whether we need to take the backward > compatibility >> > > into >> > > account in FEC Framework or not. We may not ignore a fact that the >> > > diversity >> > > of clients exists in practice. We didn't mean to make the idea we >> > > proposed >> > > to be something depart from the framework. We just hope to > complement >> > > the >> > > framework so that it can be practically more adaptable. >> > > >> > > Best regards, >> > > Zou ZiXuan, Senior Research Staff >> > > Media & Communication Lab >> > > HUAWEI TECHNOLOGIES CO.,LTD. >> > > >> > > Address: Huawei Industrial Base >> > > Bantian Longgang >> > > Shenzhen 518129, P.R.China >> > > Tel: +86 0755 28789364 >> > > Fax: +86 0755 28788317 >> > > E-mail: tendyntu@huawei.com >> > > www.huawei.com >> > > > ------------------------------------------------------------------------ >> > > ---- >> > > --------------------------------------------------------- >> > > This e-mail and its attachments contain confidential information > from >> > > HUAWEI, which >> > > is intended only for the person or entity whose address is listed > above. >> > > Any >> > > use of the >> > > information contained herein in any way (including, but not > limited > to, >> > > total or partial >> > > disclosure, reproduction, or dissemination) by persons other than > the >> > > intended >> > > recipient(s) is prohibited. If you receive this e-mail in error, > please >> > > notify the sender by >> > > phone or email immediately and delete it! >> > > >> > > >> > > > -----Original Message----- >> > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> > > > Sent: Thursday, September 24, 2009 12:09 AM >> > > > To: zouzixuan; fecframe@ietf.org >> > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > > >> > > > There are multiple things here used as an excuse to depart from > the >> > > convention >> > > > used in the framework. >> > > > >> > > > The main goal here seems to provide the non-framework capable > RTP >> > > > applications a way of using the nice features of the framework. > In >> > > this >> > > example, >> > > > "a nice feature" stands for the protection of multiple RTP > streams >> > > together. I >> > > > will let others comment on this, too, but personally, I am not > sure >> > > whether we >> > > > should be doing this. On one hand, we want the nice features, > but at >> > > the >> > > same >> > > > time we don't wanna support the framework, and the excuse is the >> > > backward >> > > > compatibility in environments with both framework-capable and >> > > incapable >> > > RTP >> > > > receivers. In addition, using an additional flow may increase > the >> > > chances >> > > of >> > > > failure since if source fec payload id's are lost, receiver will > be >> > > clueless. This >> > > > deserves a consensus from the WG, probably from AVT, too. >> > > > >> > > > Furthermore, I believe two RTP streams can be still protected > together >> > > w/o >> > > any >> > > > additional source fec payload id's (You asked for an example, > and I >> > > will >> > > try to >> > > > explain in simple words). If certain features of the RTP streams > are >> > > known >> > > > (which is usually the case), by using a systematic approach (not > in >> > > the >> > > sense of >> > > > systematic FEC), things can probably be worked out. In your > example, > I >> > > believe >> > > > in each source block you wanna do a different order of the > source >> > > packets >> > > and >> > > > flows, so things are quite unpredictable. E.g., packet 16 and 17 > are >> > > before >> > > > packet 15 of the same flow, packet 19 is before packet 8 of the > other >> > > flow, and >> > > > packets belonging to flows 0 and 1 are dispersed, any particular >> > > reason? >> > > > >> > > > But, if you follow a systematic approach, your CDP can convey > the >> > > mapping >> > > out >> > > > of band, and decoding will know what to expect and how to > decode. >> > > Remember >> > > > that there will be constraints on which RTP streams you can > combine >> > > prior >> > > to >> > > > FEC encoding (this was brought up in the last meeting). >> > > > >> > > > If all the RTP streams belong to the same RTP session, their > SSRC's >> > > will >> > > be >> > > > different, so SSRC+seqnum should uniquely identify each source > packet. >> > > But, >> > > > this would not work if the RTP streams would be from different >> > > sessions. >> > > In >> > > > that case, they could share same SSRC's, and I can see the >> > > complications. >> > > > >> > > > Cheers, acbegen. >> > > > >> > > > >> > > > From: zouzixuan [mailto:tendyntu@huawei.com] >> > > > Sent: Wednesday, September 23, 2009 4:28 AM >> > > > To: Ali C. Begen (abegen); fecframe@ietf.org >> > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > > >> > > > > >> > > > > First question, are you suggesting to apply FEC to the > combination >> > > of a >> > > video >> > > > > and audio RTP stream? >> > > > >> > > > > Second question, assuming the above case is true, I am still > not >> > > sure >> > > why you >> > > > > need an additional flow carrying the source payload ids. Is it >> > > because >> > > there >> > > > are >> > > > > two streams? Could you explain? >> > > > >> > > > It's not this case that just result in the need of carrying > source >> > > play id >> > > in >> > > > additional flow. It is this case to prove the need of source > payload >> > > id >> > > for RTP >> > > > flow. Because you need a source payload id, you gotta transfer > it to >> > > the >> > > client, >> > > > either in source packet as current FEC framework specified, or > in an >> > > additional >> > > > flow described in our draft. The latter choice for transferring > the >> > > source >> > > > payload is for making source packet accessible to > non-fecframework >> > > clients. >> > > > >> > > > This table shows an example of multiple flows. The table depicts > the >> > > structure >> > > > of a source block, which is filled up with the packets (of > length > 16, >> > > 17 >> > > 19 15 and >> > > > 8 bytes) from two sequenced flows. The packets from two flows > are >> > > identified >> > > > by flow id 0 and 1, respectively. For FEC decoding, the receiver > needs >> > > to >> > > know >> > > > the position of each packet in the source block. The sequence > number >> > > can >> > > only >> > > > tell the order of a packet in the flow it belongs to in the > source >> > > block. >> > > There is >> > > > no way to tell where a packet exactly is in the source block. > Source >> > > Payload ID is >> > > > thus in this case needed. Would you please give a solution which > is >> > > free >> > > of >> > > > source payload id? >> > > > >> > > > 0 >> > > > 16 >> > > > B0,0 >> > > > B0,1 >> > > > B0,2 >> > > > B0,3 >> > > > B0,4 >> > > > B0,5 >> > > > B0,6 >> > > > B0,7 >> > > > B0,8 >> > > > B0,9 >> > > > B0,10 >> > > > B0,11 >> > > > B0,12 >> > > > B0,13 >> > > > B0,14 >> > > > B0,15 >> > > > 0 >> > > > 0 >> > > > 0 >> > > > 0 >> > > > 17 >> > > > B1,0 >> > > > B1,1 >> > > > B1,2 >> > > > B1,3 >> > > > B1,4 >> > > > B1,5 >> > > > B1,6 >> > > > B1,7 >> > > > B1,8 >> > > > B1,9 >> > > > B1,10 >> > > > B1,11 >> > > > B1,12 >> > > > B1,13 >> > > > B1,14 >> > > > B1,15 >> > > > B1,16 >> > > > 0 >> > > > 0 >> > > > 1 >> > > > 19 >> > > > B2,0 >> > > > B2,1 >> > > > B2,2 >> > > > B2,3 >> > > > B2,4 >> > > > B2,5 >> > > > B2,6 >> > > > B2,7 >> > > > B2,8 >> > > > B2,9 >> > > > B2,10 >> > > > B2,11 >> > > > B2,12 >> > > > B2,13 >> > > > B2,14 >> > > > B2,15 >> > > > B2,16 >> > > > B2,17 >> > > > B2,18 >> > > > 0 >> > > > 15 >> > > > B3,0 >> > > > B3,1 >> > > > B3,2 >> > > > B3,3 >> > > > B3,4 >> > > > B3,5 >> > > > B3,6 >> > > > B3,7 >> > > > B3,8 >> > > > B3,9 >> > > > B3,10 >> > > > B3,11 >> > > > B3,12 >> > > > B3,13 >> > > > B3,14 >> > > > 0 >> > > > 0 >> > > > 0 >> > > > 0 >> > > > 1 >> > > > 8 >> > > > B4,0 >> > > > B4,1 >> > > > B4,2 >> > > > B4,3 >> > > > B4,4 >> > > > B4,5 >> > > > B4,6 >> > > > B4,7 >> > > > >> > > > >> > > > Hope this is clear. >> > > > >> > > > Zou ZiXuan, Senior Research Staff >> > > > Media & Communication Lab >> > > > HUAWEI TECHNOLOGIES CO.,LTD. >> > > > >> > > > Address: Huawei Industrial Base >> > > > Bantian Longgang >> > > > Shenzhen 518129, P.R.China >> > > > Tel: +86 0755 28789364 >> > > > Fax: +86 0755 28788317 >> > > > E-mail: tendyntu@huawei.com >> > > > www.huawei.com >> > > > >> > > > ------------------------------------------------------------------------ >> > > ---- >> > > ------------------------------------ >> > > > --------------------- >> > > > This e-mail and its attachments contain confidential information > from >> > > HUAWEI, >> > > > which >> > > > is intended only for the person or entity whose address is > listed >> > > above. >> > > Any use >> > > > of the >> > > > information contained herein in any way (including, but not > limited >> > > to, >> > > total or >> > > > partial >> > > > disclosure, reproduction, or dissemination) by persons other > than > the >> > > intended >> > > > recipient(s) is prohibited. If you receive this e-mail in error, >> > > please >> > > notify the >> > > > sender by >> > > > phone or email immediately and delete it! >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> > > > > Sent: Wednesday, September 23, 2009 11:29 AM >> > > > > To: zouzixuan; fecframe@ietf.org >> > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > > > >> > > > > First question, are you suggesting to apply FEC to the > combination >> > > of a >> > > video >> > > > > and audio RTP stream? >> > > > > >> > > > > Second question, assuming the above case is true, I am still > not >> > > sure >> > > why you >> > > > > need an additional flow carrying the source payload ids. Is it >> > > because >> > > there >> > > > are >> > > > > two streams? Could you explain? >> > > > > >> > > > > Cheers, acbegen. >> > > >> > > _______________________________________________ >> > > Fecframe mailing list >> > > Fecframe@ietf.org >> > > https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > From Einat@radvision.com Tue Oct 6 07:58: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 C4C0228C1C8 for ; Tue, 6 Oct 2009 07:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.327 X-Spam-Level: X-Spam-Status: No, score=-0.327 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-cA-9guMgxB for ; Tue, 6 Oct 2009 07:58:05 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id E17A728C1AE for ; Tue, 6 Oct 2009 07:58:03 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n96FDCj4025266 for fecframe@ietf.org; Tue, 6 Oct 2009 17:13:12 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n96FD5Y7025258; Tue, 6 Oct 2009 17:13:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Date: Tue, 6 Oct 2009 16:59:48 +0200 Message-ID: In-Reply-To: <38c19b540910020755g558a461x5b0aead96f2a5638@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Item? was: Re: [Fecframe]draft-zixuan-fecframe-source-mi ?? Thread-Index: AcpDcHF1w+1p6A28QdqVhU8kzETCMwDInfVA References: <38c19b540910020755g558a461x5b0aead96f2a5638@mail.gmail.com> From: "Einat Yellin (Lachover)" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id n96FD5Y7025258 Cc: tme@multicasttech.com, fecframe@ietf.org Subject: Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:58:06 -0000 Hi, As I stated previously, I do not fully understand the motivation for using a separate flow for conveying FEC payload mapping information. A generic mapping scheme for building source blocks of the variety of practical FEC codes is a good idea, however I believe that this should be indicated in the designated repair flow. Until it is so, I don't believe that we should adopt draft-zixuan-fecframe-source-mi as a working group item. Best regards, Einat -----Original Message----- From: Greg Shepherd [mailto:gjshep@gmail.com] Sent: Friday, October 02, 2009 4:56 PM To: Einat Yellin (Lachover) Cc: zouzixuan; Ali C. Begen (abegen); tme@multicasttech.com; fecframe@ietf.org Subject: IS: Working Group Item? was: Re: [Fecframe]draft-zixuan-fecframe-source-mi ?? Thank you for the discussion. I think we have enough information in this thread to make a determination if we want to take on this work in the FECFrame Working Group. Please respond to this message and indicate whether or not you feel we should adopt: draft-zixuan-fecframe-source-mi .as a working group item. Thanks, Greg On Mon, Sep 28, 2009 at 11:31 PM, Einat Yellin (Lachover) wrote: > > > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf Of zouzixuan > Sent: Monday, September 28, 2009 10:57 AM > To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover); > tme@multicasttech.com; gjshep@gmail.com; fecframe@ietf.org > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? > > Hi, Ali > >> I am not questioning backward compatibility, I am questioning the cost > for > it >> and the scenarios where we want backward compatibility. Einat did a > good >> summary, so now the WG needs to provide input. > You mean there should be some input on backward compatibility to the > framework. > > >> Regarding your example, putting the audio and video packets into the > source >> blocks as they are available does not seem to be a good design choice > to > me. >> When I say "systematic," I mean you can create your source blocks in a >> deterministic way (such as 4 packets from stream 1, one packet from > stream > 2). >> Variable-packet size can be handled. > > In this "systematic" case, how could we know the position of a packet in > the > source block? > [Einat] There are different ways to signal the source block structure. > In our draft we followed rfc 5109 and used the 'base' (first) RTP > sequence number along with a bitmap. This works for the cases where what > matters is which RTP packets belong to this FEC source block and the > order of the packets in the FEC source block is deterministic (from > lower SN to higher SN and from lower flow ID to higher flow ID). If a > more detailed structure of source block is needed then I agree that the > bitmap is not enough. Still, this information can be sent as part of the > repair packet header which IMO makes more sense. > > Zou ZiXuan, Senior Research Staff > Media & Communication Lab > HUAWEI TECHNOLOGIES CO.,LTD. > > Address: Huawei Industrial Base > Bantian Longgang > Shenzhen 518129, P.R.China > Tel: +86 0755 28789364 > Fax: +86 0755 28788317 > E-mail: tendyntu@huawei.com > www.huawei.com > ------------------------------------------------------------------------ > ---- > --------------------------------------------------------- > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any > use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: Monday, September 28, 2009 1:40 AM >> To: zouzixuan; Einat Yellin (Lachover); tme@multicasttech.com; >> gjshep@gmail.com; fecframe@ietf.org >> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> >> I am not questioning backward compatibility, I am questioning the cost > for > it >> and the scenarios where we want backward compatibility. Einat did a > good >> summary, so now the WG needs to provide input. >> >> Regarding your example, putting the audio and video packets into the > source >> blocks as they are available does not seem to be a good design choice > to > me. >> When I say "systematic," I mean you can create your source blocks in a >> deterministic way (such as 4 packets from stream 1, one packet from > stream > 2). >> Variable-packet size can be handled. >> >> Cheers, acbegen. >> >> > -----Original Message----- >> > From: zouzixuan [mailto:tendyntu@huawei.com] >> > Sent: Sunday, September 27, 2009 5:59 AM >> > To: 'Einat Yellin (Lachover)'; Ali C. Begen (abegen); > tme@multicasttech.com; >> > gjshep@gmail.com; fecframe@ietf.org >> > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > >> > Hi, Einat, Ali >> >      Similar to Einat's explanation on "backward compatible" as > stated >> > your draft , our intention is to keep source packet unmodified > without >> > adding source payload id to it. And therefore the non-framework > client > can >> > interpret the source packet. But I'm still not sure if the "backward >> > compatibility" we are referring to here is considered a valuable > requirement >> > in FEC framework. >> > >> >      I'd like to again use the example we gave in the previous > thread we >> > replied to Ali's doubts to explain the need of source payload id for > RTP >> > flow. Ali, sorry, I was supposed to gave more detailed information > on > this. >> > . >> >     Here are several assumptions on this example: >> >      1) We assume a FEC-protected audiovisual stream which is >> > combination of a video and a audio RTP flow. ID 0 identify video > source >> > data, and ID 1 identify audio source data. The definition of ID can > be >> > conveyed through SDP >> >      2) RTP packets length is non-equal, e.g. in 16, 17, 19, 15, 8 >> > bytes, as is shown. >> >      3) A video or audio source packet is fed into a source block in > an >> > First-come-First-serve order in which the video and audio packets > are >> > generated. >> > >> >    In which case we think the source-pay-load ID is needed. For >> > backward-compatibility, the source payload id can be conveyed in an > separate >> > flow, which could be either an additional flow or the repair flow. >> > >> >    Ali, would you please give a more details on "systematic > approach"? > I'm >> > not following this. >> > >> > 0         16           B0,0   B0,1  B0,2   B0,3   B0,4  B0,5  B0,6 >> B0,7 >> > B0,8  B0,9  B0,10  B0,11  B0,12  B0,13  B0,14  B0,15  0    0 > 0 >> > >> > 0         17           B1,0   B1,1  B1,2       B1,3   B1,4  B1,5 > B1,6 >> > B1,7 >> > B1,8          B1,9  B1,10  B1,11      B1,12 B1,13  B1,14     B1,15 > B1,16  0 >> > 0 >> > >> > 1         19           B2,0   B2,1  B2,2   B2,3       B2,4  B2,5 >> > B2,6        B2,7 >> > B2,8          B2,9  B2,10  B2,11      B2,12 B2,13  B2,14      B2,15 > B2,16 >> B2,17 >> > B2,18 >> > >> > 0         15           B3,0   B3,1  B3,2   B3,3       B3,4  B3,5 > B3,6 >> > B3,7 >> > B3,8          B3,9  B3,10  B3,11      B3,12 B3,13  B3,14       0 > 0 > 0 >> > 0 >> > >> > 1         8        B4,0       B4,1  B4,2   B4,3       B4,4  B4,5 > B4,6 >> > B4,7 >> > >> > So here I think if we want to have answer on the necessity of the > things > in >> > our draft, we need to at first have conclusions on the following: 1) > whether >> > the "back compatibility" Elinat and me are referring to is a real > issue > to >> > be considered in FEC framework, And 2) if some cases like this one, > which >> > demands source payload id, stands and is representative. >> > >> > Cheers >> > Zou ZiXuan, Senior Research Staff >> > Media & Communication Lab >> > HUAWEI TECHNOLOGIES CO.,LTD. >> > >> > Address: Huawei Industrial Base >> > Bantian Longgang >> > Shenzhen 518129, P.R.China >> > Tel: +86 0755 28789364 >> > Fax: +86 0755 28788317 >> > E-mail: tendyntu@huawei.com >> > www.huawei.com >> > > ------------------------------------------------------------------------ > ---- >> > --------------------------------------------------------- >> > This e-mail and its attachments contain confidential information > from >> > HUAWEI, which >> > is intended only for the person or entity whose address is listed > above. > Any >> > use of the >> > information contained herein in any way (including, but not limited > to, >> > total or partial >> > disclosure, reproduction, or dissemination) by persons other than > the >> > intended >> > recipient(s) is prohibited. If you receive this e-mail in error, > please >> > notify the sender by >> > phone or email immediately and delete it! >> > >> > > -----Original Message----- >> > > From: Einat Yellin (Lachover) [mailto:Einat@radvision.com] >> > > Sent: Thursday, September 24, 2009 1:24 PM >> > > To: zouzixuan; Ali C. Begen (abegen); fecframe@ietf.org >> > > Cc: tme@multicasttech.com >> > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > >> > > Hi, >> > > Backward compatibility is a major requirement for FEC framework, > no >> > > doubt. I believe that the discussion here is around whether a > separate >> > > flow for FEC mapping information is required. >> > > >> > > While following the discussion, I can relate to the reasons why > not >> > > having a separate flow as claimed by Ali: >> > > a. This is a redundant flow since this information can be conveyed > in >> > > the FEC repair flow and in SDP even when protecting multiple RTP > flows >> > > (specifically you can see an example in >> > > draft-galanos-fecframe-rtp-reedsolomon-mf-00). >> > > b. This separate flow for mapping is also useful only for > receivers > that >> > > support this draft, so the backward compatibility issue remains > the > same >> > > as for the case where mapping is specified in the repair flow. >> > > c. A separate flow increases the chance of losing packets. >> > > >> > > I must say that I don't understand the reasons for using a > separate >> > > flow. >> > > Mr. Zou ZiXuan, is this meant for systems that do not use SDP? >> > > >> > > Best, >> > > Einat >> > > -----Original Message----- >> > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] > On >> > > Behalf Of zouzixuan >> > > Sent: Thursday, September 24, 2009 6:24 AM >> > > To: 'Ali C. Begen (abegen)'; fecframe@ietf.org >> > > Cc: tme@multicasttech.com >> > > Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > >> > > Hi, Ali >> > >   It's a good suggestion that others join the discussion on this. >> > > The >> > > point here is that whether we need to take the backward > compatibility >> > > into >> > > account in FEC Framework or not. We may not ignore a fact that the >> > > diversity >> > > of clients exists in practice. We didn't mean to make the idea we >> > > proposed >> > > to be something depart from the framework. We just hope to > complement >> > > the >> > > framework so that it can be practically more adaptable. >> > > >> > > Best regards, >> > > Zou ZiXuan, Senior Research Staff >> > > Media & Communication Lab >> > > HUAWEI TECHNOLOGIES CO.,LTD. >> > > >> > > Address: Huawei Industrial Base >> > > Bantian Longgang >> > > Shenzhen 518129, P.R.China >> > > Tel: +86 0755 28789364 >> > > Fax: +86 0755 28788317 >> > > E-mail: tendyntu@huawei.com >> > > www.huawei.com >> > > > ------------------------------------------------------------------------ >> > > ---- >> > > --------------------------------------------------------- >> > > This e-mail and its attachments contain confidential information > from >> > > HUAWEI, which >> > > is intended only for the person or entity whose address is listed > above. >> > > Any >> > > use of the >> > > information contained herein in any way (including, but not > limited > to, >> > > total or partial >> > > disclosure, reproduction, or dissemination) by persons other than > the >> > > intended >> > > recipient(s) is prohibited. If you receive this e-mail in error, > please >> > > notify the sender by >> > > phone or email immediately and delete it! >> > > >> > > >> > > > -----Original Message----- >> > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> > > > Sent: Thursday, September 24, 2009 12:09 AM >> > > > To: zouzixuan; fecframe@ietf.org >> > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > > >> > > > There are multiple things here used as an excuse to depart from > the >> > > convention >> > > > used in the framework. >> > > > >> > > > The main goal here seems to provide the non-framework capable > RTP >> > > > applications a way of using the nice features of the framework. > In >> > > this >> > > example, >> > > > "a nice feature" stands for the protection of multiple RTP > streams >> > > together. I >> > > > will let others comment on this, too, but personally, I am not > sure >> > > whether we >> > > > should be doing this. On one hand, we want the nice features, > but at >> > > the >> > > same >> > > > time we don't wanna support the framework, and the excuse is the >> > > backward >> > > > compatibility in environments with both framework-capable and >> > > incapable >> > > RTP >> > > > receivers. In addition, using an additional flow may increase > the >> > > chances >> > > of >> > > > failure since if source fec payload id's are lost, receiver will > be >> > > clueless. This >> > > > deserves a consensus from the WG, probably from AVT, too. >> > > > >> > > > Furthermore, I believe two RTP streams can be still protected > together >> > > w/o >> > > any >> > > > additional source fec payload id's (You asked for an example, > and I >> > > will >> > > try to >> > > > explain in simple words). If certain features of the RTP streams > are >> > > known >> > > > (which is usually the case), by using a systematic approach (not > in >> > > the >> > > sense of >> > > > systematic FEC), things can probably be worked out. In your > example, > I >> > > believe >> > > > in each source block you wanna do a different order of the > source >> > > packets >> > > and >> > > > flows, so things are quite unpredictable. E.g., packet 16 and 17 > are >> > > before >> > > > packet 15 of the same flow, packet 19 is before packet 8 of the > other >> > > flow, and >> > > > packets belonging to flows 0 and 1 are dispersed, any particular >> > > reason? >> > > > >> > > > But, if you follow a systematic approach, your CDP can convey > the >> > > mapping >> > > out >> > > > of band, and decoding will know what to expect and how to > decode. >> > > Remember >> > > > that there will be constraints on which RTP streams you can > combine >> > > prior >> > > to >> > > > FEC encoding (this was brought up in the last meeting). >> > > > >> > > > If all the RTP streams belong to the same RTP session, their > SSRC's >> > > will >> > > be >> > > > different, so SSRC+seqnum should uniquely identify each source > packet. >> > > But, >> > > > this would not work if the RTP streams would be from different >> > > sessions. >> > > In >> > > > that case, they could share same SSRC's, and I can see the >> > > complications. >> > > > >> > > > Cheers, acbegen. >> > > > >> > > > >> > > > From: zouzixuan [mailto:tendyntu@huawei.com] >> > > > Sent: Wednesday, September 23, 2009 4:28 AM >> > > > To: Ali C. Begen (abegen); fecframe@ietf.org >> > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > > >> > > > > >> > > > > First question, are you suggesting to apply FEC to the > combination >> > > of a >> > > video >> > > > > and audio RTP stream? >> > > > >> > > > > Second question, assuming the above case is true, I am still > not >> > > sure >> > > why you >> > > > > need an additional flow carrying the source payload ids. Is it >> > > because >> > > there >> > > > are >> > > > > two streams? Could you explain? >> > > > >> > > > It's not this case that just result in the need of carrying > source >> > > play id >> > > in >> > > > additional flow. It is this case to prove the need of source > payload >> > > id >> > > for RTP >> > > > flow. Because you need a source payload id, you gotta transfer > it to >> > > the >> > > client, >> > > > either in source packet as current FEC framework specified, or > in an >> > > additional >> > > > flow described in our draft. The latter choice for transferring > the >> > > source >> > > > payload is for making source packet accessible to > non-fecframework >> > > clients. >> > > > >> > > > This table shows an example of multiple flows. The table depicts > the >> > > structure >> > > > of a source block, which is filled up with the packets (of > length > 16, >> > > 17 >> > > 19 15 and >> > > > 8 bytes) from two sequenced flows. The packets from two flows > are >> > > identified >> > > > by flow id 0 and 1, respectively. For FEC decoding, the receiver > needs >> > > to >> > > know >> > > > the position of each packet in the source block. The sequence > number >> > > can >> > > only >> > > > tell the order of a packet in the flow it belongs to in the > source >> > > block. >> > > There is >> > > > no way to tell where a packet exactly is in the source block. > Source >> > > Payload ID is >> > > > thus in this case needed. Would you please give a solution which > is >> > > free >> > > of >> > > > source payload id? >> > > > >> > > > 0 >> > > > 16 >> > > > B0,0 >> > > > B0,1 >> > > > B0,2 >> > > > B0,3 >> > > > B0,4 >> > > > B0,5 >> > > > B0,6 >> > > > B0,7 >> > > > B0,8 >> > > > B0,9 >> > > > B0,10 >> > > > B0,11 >> > > > B0,12 >> > > > B0,13 >> > > > B0,14 >> > > > B0,15 >> > > > 0 >> > > > 0 >> > > > 0 >> > > > 0 >> > > > 17 >> > > > B1,0 >> > > > B1,1 >> > > > B1,2 >> > > > B1,3 >> > > > B1,4 >> > > > B1,5 >> > > > B1,6 >> > > > B1,7 >> > > > B1,8 >> > > > B1,9 >> > > > B1,10 >> > > > B1,11 >> > > > B1,12 >> > > > B1,13 >> > > > B1,14 >> > > > B1,15 >> > > > B1,16 >> > > > 0 >> > > > 0 >> > > > 1 >> > > > 19 >> > > > B2,0 >> > > > B2,1 >> > > > B2,2 >> > > > B2,3 >> > > > B2,4 >> > > > B2,5 >> > > > B2,6 >> > > > B2,7 >> > > > B2,8 >> > > > B2,9 >> > > > B2,10 >> > > > B2,11 >> > > > B2,12 >> > > > B2,13 >> > > > B2,14 >> > > > B2,15 >> > > > B2,16 >> > > > B2,17 >> > > > B2,18 >> > > > 0 >> > > > 15 >> > > > B3,0 >> > > > B3,1 >> > > > B3,2 >> > > > B3,3 >> > > > B3,4 >> > > > B3,5 >> > > > B3,6 >> > > > B3,7 >> > > > B3,8 >> > > > B3,9 >> > > > B3,10 >> > > > B3,11 >> > > > B3,12 >> > > > B3,13 >> > > > B3,14 >> > > > 0 >> > > > 0 >> > > > 0 >> > > > 0 >> > > > 1 >> > > > 8 >> > > > B4,0 >> > > > B4,1 >> > > > B4,2 >> > > > B4,3 >> > > > B4,4 >> > > > B4,5 >> > > > B4,6 >> > > > B4,7 >> > > > >> > > > >> > > > Hope this is clear. >> > > > >> > > > Zou ZiXuan, Senior Research Staff >> > > > Media & Communication Lab >> > > > HUAWEI TECHNOLOGIES CO.,LTD. >> > > > >> > > > Address: Huawei Industrial Base >> > > > Bantian Longgang >> > > > Shenzhen 518129, P.R.China >> > > > Tel: +86 0755 28789364 >> > > > Fax: +86 0755 28788317 >> > > > E-mail: tendyntu@huawei.com >> > > > www.huawei.com >> > > > >> > > > ------------------------------------------------------------------------ >> > > ---- >> > > ------------------------------------ >> > > > --------------------- >> > > > This e-mail and its attachments contain confidential information > from >> > > HUAWEI, >> > > > which >> > > > is intended only for the person or entity whose address is > listed >> > > above. >> > > Any use >> > > > of the >> > > > information contained herein in any way (including, but not > limited >> > > to, >> > > total or >> > > > partial >> > > > disclosure, reproduction, or dissemination) by persons other > than > the >> > > intended >> > > > recipient(s) is prohibited. If you receive this e-mail in error, >> > > please >> > > notify the >> > > > sender by >> > > > phone or email immediately and delete it! >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> > > > > Sent: Wednesday, September 23, 2009 11:29 AM >> > > > > To: zouzixuan; fecframe@ietf.org >> > > > > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ?? >> > > > > >> > > > > First question, are you suggesting to apply FEC to the > combination >> > > of a >> > > video >> > > > > and audio RTP stream? >> > > > > >> > > > > Second question, assuming the above case is true, I am still > not >> > > sure >> > > why you >> > > > > need an additional flow carrying the source payload ids. Is it >> > > because >> > > there >> > > > are >> > > > > two streams? Could you explain? >> > > > > >> > > > > Cheers, acbegen. >> > > >> > > _______________________________________________ >> > > Fecframe mailing list >> > > Fecframe@ietf.org >> > > https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > From tendyntu@huawei.com Fri Oct 9 04:44:23 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F983A659A for ; Fri, 9 Oct 2009 04:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.771 X-Spam-Level: X-Spam-Status: No, score=0.771 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_05=-1.11, 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 mNFJfcT8pdZx for ; Fri, 9 Oct 2009 04:44:16 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 222983A691C for ; Fri, 9 Oct 2009 04:43:58 -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 <0KR800DDLWEQJC@szxga03-in.huawei.com> for fecframe@ietf.org; Fri, 09 Oct 2009 19:40:02 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR800A5FWEQCE@szxga03-in.huawei.com> for fecframe@ietf.org; Fri, 09 Oct 2009 19:40:02 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR800FNIWEOWW@szxml06-in.huawei.com> for fecframe@ietf.org; Fri, 09 Oct 2009 19:40:01 +0800 (CST) Date: Fri, 09 Oct 2009 19:40:00 +0800 From: zouzixuan To: "'Einat Yellin (Lachover)'" , gjshep@gmail.com Message-id: <00c501ca48d5$3cc3a890$b64af9b0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2i5RkSvYNSixEx+L3l5TWw)" Content-language: zh-cn Thread-index: AcpIvWqSu9jpaRmKSNipa3n/tt0MYgAAK3YQ Cc: tme@multicasttech.com, fecframe@ietf.org Subject: Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 11:44:24 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ --Boundary_(ID_2i5RkSvYNSixEx+L3l5TWw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, > Hi, > > As I stated previously, I do not fully understand the motivation for using a > separate flow for conveying FEC payload mapping information. As stated in your draft: "Add padding (bytes containing binary zeroes) so that the byte array is in the size of the largest packet protected by this source block including the two bytes from section a. (The largest packet does not contain zero padding).", conveying FEC payload mapping information in repair flow needs padding. But padding may lead to recovery performance degradation. We give an example, as the figures show below. For the padding case as depicted in Figure 1, the redundant data for recovering the packet of length 11 is 48, which is same as that for the packet of length 40. Figure1. Source block with padding |-Source Block---| +----------------+ |40xxxxxxxxxxxxxx| +----------------+ |xxxxxxxxxxxxxxxx| +----------------+ |xxxxxxxxxx000000| +----------------+ |11xxxxxxxxxxx000| +----------------+ |0000000000000000| +----------------+ |0000000000000000| +----------------+ For a non-padding case as depicted in Figure2, recovering the packet of length 11 only requires redundant data of length 16. The redundancy is much less than the padding case. Figure 2. Source block without padding |-Source Block---| +----------------+ |40xxxxxxxxxxxxxx| +----------------+ |xxxxxxxxxxxxxxxx| +----------------+ |xxxxxxxxxx000000| +----------------+ |11xxxxxxxxxxx000| +----------------+ If choosing non-padding strategy as an alternative for FEC protection, the position of source packet cannot be acquired simply by the sequence number. The information with greater detail, for example ESI of each source packet, have to be conveyed. These information may expand the FEC header in the repair flow to a fairly large size. An alternative is to convey them in a separate flow. > A generic mapping scheme for building source blocks of the variety of practical > FEC codes is a good idea, however I believe that this should be indicated in the > designated repair flow. > > Until it is so, I don't believe that we should adopt > draft-zixuan-fecframe-source-mi as a working group item. > The focus of our draft is on backward-compatibility issue. Separate flow is just an option. Based on the previous discussion on the draft, now we think defining a generic mapping information format for various ways of building source block in practice should be the most important issue for backward compatibility. We suggest to make this work (defining a generic mapping information format) to be a work item. We can update our draft to be the basis of this work. -----Original Message----- > From: Einat Yellin (Lachover) [mailto:Einat@radvision.com] > Sent: Tuesday, October 06, 2009 11:00 PM > To: gjshep@gmail.com > Cc: zouzixuan; Ali C. Begen (abegen); tme@multicasttech.com; > fecframe@ietf.org > Subject: RE: Working Group Item? was: Re: > [Fecframe]draft-zixuan-fecframe-source-mi ?? > > Hi, > > As I stated previously, I do not fully understand the motivation for using a > separate flow for conveying FEC payload mapping information. > > A generic mapping scheme for building source blocks of the variety of practical > FEC codes is a good idea, however I believe that this should be indicated in the > designated repair flow. > > Until it is so, I don't believe that we should adopt > draft-zixuan-fecframe-source-mi as a working group item. > > Best regards, > Einat > > -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of zouzixuan Sent: Monday, September 28, 2009 10:57 AM To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover); tme@multicasttech.com; gjshep@gmail.com; fecframe@ietf.org Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? Hi, Ali > I am not questioning backward compatibility, I am questioning the cost for it > and the scenarios where we want backward compatibility. Einat did a good > summary, so now the WG needs to provide input. You mean there should be some input on backward compatibility to the framework. > Regarding your example, putting the audio and video packets into the source > blocks as they are available does not seem to be a good design choice to me. > When I say "systematic," I mean you can create your source blocks in a > deterministic way (such as 4 packets from stream 1, one packet from stream 2). > Variable-packet size can be handled. In this "systematic" case, how could we know the position of a packet in the source block? [Einat] There are different ways to signal the source block structure. In our draft we followed rfc 5109 and used the 'base' (first) RTP sequence number along with a bitmap. This works for the cases where what matters is which RTP packets belong to this FEC source block and the order of the packets in the FEC source block is deterministic (from lower SN to higher SN and from lower flow ID to higher flow ID). If a more detailed structure of source block is needed then I agree that the bitmap is not enough. Still, this information can be sent as part of the repair packet header which IMO makes more sense. --Boundary_(ID_2i5RkSvYNSixEx+L3l5TWw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

> Hi,

>

> As I stated previously, I do not fully understand the motivation for using a

> separate flow for conveying FEC payload mapping information.

 

                    As stated in your draft: “Add padding (bytes containing binary zeroes) so that the byte array is in the size of the largest packet protected by this source block including the two bytes from section a.  (The largest packet does not contain zero padding).”, conveying FEC payload mapping information in repair flow needs padding. But padding may lead to recovery performance degradation.  We give an example, as the figures show below. 
 
 
For the padding case as depicted in Figure 1, the redundant data for recovering the packet of length 11 is 48, which is same as that for the packet of length 40.
 

Figure1. Source block with padding

|-Source Block---|                  
+----------------+
|40xxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxx000000|
+----------------+
|11xxxxxxxxxxx000|
+----------------+
|0000000000000000|
+----------------+
|0000000000000000|
+----------------+
 
 
 
For a non-padding case as depicted in Figure2, recovering the packet of length 11 only requires redundant data of length 16. The redundancy is much less than the padding case. 
 
                                                    Figure 2. Source block without padding
|-Source Block---|                  
+----------------+
|40xxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxx000000|
+----------------+
|11xxxxxxxxxxx000|
+----------------+

 

If choosing non-padding strategy as an alternative for FEC protection, the position of source packet cannot be acquired simply by the sequence number. The information with greater detail, for example ESI of each source packet, have to be conveyed. These information may expand the FEC header in the repair flow to a fairly large size. An alternative is to convey them in a separate flow.

 

> A generic mapping scheme for building source blocks of the variety of practical

> FEC codes is a good idea, however I believe that this should be indicated in the

> designated repair flow.

>

> Until it is so, I don't believe that we should adopt

> draft-zixuan-fecframe-source-mi as a working group item.

>

The focus of our draft is on backward-compatibility issue. Separate flow is just an option. Based on the previous discussion on the draft, now we think defining a generic mapping information format for various ways of building source block in practice should be the most important issue for backward compatibility. We suggest to make this work (defining a generic mapping information format) to be a work item. We can update our draft to be the basis of this work.

 

-----Original Message-----

> From: Einat Yellin (Lachover) [mailto:Einat@radvision.com]

> Sent: Tuesday, October 06, 2009 11:00 PM

> To: gjshep@gmail.com

> Cc: zouzixuan; Ali C. Begen (abegen); tme@multicasttech.com;

> fecframe@ietf.org

> Subject: RE: Working Group Item? was: Re:

> [Fecframe]draft-zixuan-fecframe-source-mi ??

>

> Hi,

>

> As I stated previously, I do not fully understand the motivation for using a

> separate flow for conveying FEC payload mapping information.

>

> A generic mapping scheme for building source blocks of the variety of practical

> FEC codes is a good idea, however I believe that this should be indicated in the

> designated repair flow.

>

> Until it is so, I don't believe that we should adopt

> draft-zixuan-fecframe-source-mi as a working group item.

>

> Best regards,

> Einat

>

> 

 

-----Original Message-----

From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of zouzixuan

Sent: Monday, September 28, 2009 10:57 AM

To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover); tme@multicasttech.com; gjshep@gmail.com; fecframe@ietf.org

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

 

Hi, Ali

 

> I am not questioning backward compatibility, I am questioning the cost

for

it

> and the scenarios where we want backward compatibility. Einat did a

good

> summary, so now the WG needs to provide input.

You mean there should be some input on backward compatibility to the framework.

 

 

> Regarding your example, putting the audio and video packets into the

source

> blocks as they are available does not seem to be a good design choice

to

me.

> When I say "systematic," I mean you can create your source blocks in a

> deterministic way (such as 4 packets from stream 1, one packet from

stream

2).

> Variable-packet size can be handled.

 

In this "systematic" case, how could we know the position of a packet in the source block?

[Einat] There are different ways to signal the source block structure.

In our draft we followed rfc 5109 and used the 'base' (first) RTP sequence number along with a bitmap. This works for the cases where what matters is which RTP packets belong to this FEC source block and the order of the packets in the FEC source block is deterministic (from lower SN to higher SN and from lower flow ID to higher flow ID). If a more detailed structure of source block is needed then I agree that the bitmap is not enough. Still, this information can be sent as part of the repair packet header which IMO makes more sense.

 

 
--Boundary_(ID_2i5RkSvYNSixEx+L3l5TWw)-- From abegen@cisco.com Fri Oct 9 12:23: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 46FA03A6872 for ; Fri, 9 Oct 2009 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 YaJUdQoQzUrs for ; Fri, 9 Oct 2009 12:23:05 -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 42F943A67AF for ; Fri, 9 Oct 2009 12:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1008; q=dns/txt; s=sjiport01001; t=1255116290; x=1256325890; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Ali=20C.=20Begen=20(abegen)"=20|Subject:=20RE:=20RE:=20Working=20Group=20Item?=20was: =20Re:=20[Fecframe]draft-zixuan-fecframe-source-mi=20=20? ?|Date:=20Fri,=209=20Oct=202009=2012:22:42=20-0700 |Message-ID:=20<04CAD96D4C5A3D48B1919248A8FE0D540A6358F9@ xmb-sjc-215.amer.cisco.com>|To:=20"zouzixuan"=20,=0D=0A=20=20=20=20=20=20=20=20"Einat=20Yelli n=20(Lachover)"=20,=20|Cc:=20,=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<00c501ca48d5$3cc3a890$b64af9b0$ @com>|References:=20<00c501ca48d5$3cc3a890$b64af9b0$@com>; bh=Rru95UV4Q61JdkS9cmZrQO/Kf6JfxVW+xsEaw8AORSk=; b=FQYNh29SkMTa7zhHciTvNTJgGcNVwZN78k1n1gH1AxdFd+iy9OgHMFBM kMyRPhenqQfdexdyB1IT6MNgVddnwDQa64M2aexbtzLLTo02QdnvZCULg 8rQzse8BGg9Yn9yaFoL41jGrEETQX2RdtALCUj8pdCAmy8WtlqbGSp3R3 o=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOsqz0qrRN+J/2dsb2JhbADCcphDhCwE X-IronPort-AV: E=Sophos;i="4.44,534,1249257600"; d="scan'208";a="253723977" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 09 Oct 2009 19:24:50 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n99JOo6Z009989; Fri, 9 Oct 2009 19:24:50 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 12:24:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Oct 2009 12:22:42 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A6358F9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <00c501ca48d5$3cc3a890$b64af9b0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Working Group Item? was: Re: [Fecframe]draft-zixuan-fecframe-source-mi ?? Thread-Index: AcpIvWqSu9jpaRmKSNipa3n/tt0MYgAAK3YQABXKgWA= References: <00c501ca48d5$3cc3a890$b64af9b0$@com> From: "Ali C. Begen (abegen)" To: "zouzixuan" , "Einat Yellin (Lachover)" , X-OriginalArrivalTime: 09 Oct 2009 19:24:50.0572 (UTC) FILETIME=[2BC1F4C0:01CA4916] Cc: tme@multicasttech.com, fecframe@ietf.org Subject: Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 19:23:06 -0000 > The focus of our draft is on backward-compatibility issue. Separate = flow is just an > option. Based on the previous discussion on the draft, now we think = defining a generic What other option(s) do you propose? Using a separate flow requires additional support on the clients already = supporting the framework. Rather than wasting that energy on those = modifications, I'd rather prefer making the non-framework clients = compatible with the framework if they indeed want to benefit from the = framework features. Ow, I suggest the non-compatible clients to stick with the = non-complicated FEC scenarios. This whole stuff is not worth the effort = IMO. -acbegen > mapping information format for various ways of building source block = in practice should be > the most important issue for backward compatibility. We suggest to = make this work > (defining a generic mapping information format) to be a work item. We = can update our draft > to be the basis of this work. From tendyntu@huawei.com Sat Oct 10 02:14: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 4249828C0CF for ; Sat, 10 Oct 2009 02:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_40=-0.185, 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 X6+3Vp3Da9um for ; Sat, 10 Oct 2009 02:14:40 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 30ED228C0D8 for ; Sat, 10 Oct 2009 02:14:40 -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 <0KRA001HYKF0M5@szxga03-in.huawei.com> for fecframe@ietf.org; Sat, 10 Oct 2009 17:16:12 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRA006CQKF0DY@szxga03-in.huawei.com> for fecframe@ietf.org; Sat, 10 Oct 2009 17:16:12 +0800 (CST) Received: from z61302 ([10.85.208.185]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRA003XNKEZAZ@szxml06-in.huawei.com> for fecframe@ietf.org; Sat, 10 Oct 2009 17:16:11 +0800 (CST) Date: Sat, 10 Oct 2009 17:16:11 +0800 From: zouzixuan In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540A6358F9@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , "'Einat Yellin (Lachover)'" , gjshep@gmail.com Message-id: <000a01ca498a$4f201ea0$ed605be0$@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: AcpIvWqSu9jpaRmKSNipa3n/tt0MYgAAK3YQABXKgWAAHPwDgA== References: <00c501ca48d5$3cc3a890$b64af9b0$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A6358F9@xmb-sjc-215.amer.cisco.com> Cc: tme@multicasttech.com, fecframe@ietf.org Subject: Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 09:14:41 -0000 Hi, > > The focus of our draft is on backward-compatibility issue. Separate flow is just > an > > option. Based on the previous discussion on the draft, now we think defining a > generic > > What other option(s) do you propose? Other option can be repair flow. > Ow, I suggest the non-compatible clients to stick with the non-complicated FEC > scenarios. This whole stuff is not worth the effort IMO. > So we need to draw a conclusion on if compatibility is a worth work or not in FEC framework. Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu@huawei.com www.huawei.com ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Saturday, October 10, 2009 3:23 AM > To: zouzixuan; Einat Yellin (Lachover); gjshep@gmail.com > Cc: tme@multicasttech.com; fecframe@ietf.org > Subject: RE: RE: Working Group Item? was: Re: > [Fecframe]draft-zixuan-fecframe-source-mi ?? > > > The focus of our draft is on backward-compatibility issue. Separate flow is just > an > > option. Based on the previous discussion on the draft, now we think defining a > generic > > What other option(s) do you propose? > > Using a separate flow requires additional support on the clients already > supporting the framework. Rather than wasting that energy on those > modifications, I'd rather prefer making the non-framework clients compatible > with the framework if they indeed want to benefit from the framework > features. > > Ow, I suggest the non-compatible clients to stick with the non-complicated FEC > scenarios. This whole stuff is not worth the effort IMO. > > -acbegen > > > mapping information format for various ways of building source block in > practice should be > > the most important issue for backward compatibility. We suggest to make > this work > > (defining a generic mapping information format) to be a work item. We can > update our draft > > to be the basis of this work. From Einat@radvision.com Sat Oct 10 22:18:31 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 45F8428C0E7 for ; Sat, 10 Oct 2009 22:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599, 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 qt+0gI5cq8KS for ; Sat, 10 Oct 2009 22:18:20 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 761B528C121 for ; Sat, 10 Oct 2009 22:17:44 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n9B5IhnA016353 for fecframe@ietf.org; Sun, 11 Oct 2009 07:18:43 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n9B5IDDk016339; Sun, 11 Oct 2009 07:18:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4A32.33C595A2" Date: Sun, 11 Oct 2009 07:18:03 +0200 Message-ID: In-Reply-To: <00c501ca48d5$3cc3a890$b64af9b0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Working Group Item? was: Re:[Fecframe]draft-zixuan-fecframe-source-mi ?? Thread-Index: AcpIvWqSu9jpaRmKSNipa3n/tt0MYgAAK3YQAFzDQYA= References: <00c501ca48d5$3cc3a890$b64af9b0$@com> From: "Einat Yellin (Lachover)" To: "zouzixuan" , Cc: tme@multicasttech.com, fecframe@ietf.org Subject: Re: [Fecframe] Working Group Item? was: Re:draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 05:18:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4A32.33C595A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The recovery performance degradation while padding is there, I agree. However, this is one factor out of many that the application needs to consider while choosing the FEC scheme to use. For example, if recovery performance is critical one can choose using 1D2D scheme, which is less demanding on CPU power. =20 In addition, for high bit rate video applications, such as the one we designed and implemented our scheme for, it is common to use MTU size for RTP packets to reduce overhead. This makes the recovery performance degradation due to padding negligible. =20 Einat =20 From: zouzixuan [mailto:tendyntu@huawei.com]=20 Sent: Friday, October 09, 2009 1:40 PM To: Einat Yellin (Lachover); gjshep@gmail.com Cc: 'Ali C. Begen (abegen)'; tme@multicasttech.com; fecframe@ietf.org Subject: RE: RE: Working Group Item? was: Re:[Fecframe]draft-zixuan-fecframe-source-mi ?? =20 Hi,=20 > Hi, >=20 > As I stated previously, I do not fully understand the motivation for using a > separate flow for conveying FEC payload mapping information. =20 As stated in your draft: "Add padding (bytes containing binary zeroes) so that the byte array is in the size of the largest packet protected by this source block including the two bytes from section a. (The largest packet does not contain zero padding).", conveying FEC payload mapping information in repair flow needs padding. But padding may lead to recovery performance degradation. We give an example, as the figures show below.=20 =20 =20 For the padding case as depicted in Figure 1, the redundant data for recovering the packet of length 11 is 48, which is same as that for the packet of length 40. =20 Figure1. Source block with padding |-Source Block---| =20 +----------------+ |40xxxxxxxxxxxxxx| +----------------+ |xxxxxxxxxxxxxxxx| +----------------+ |xxxxxxxxxx000000| +----------------+ |11xxxxxxxxxxx000| +----------------+ |0000000000000000| +----------------+ |0000000000000000| +----------------+ =20 =20 =20 For a non-padding case as depicted in Figure2, recovering the packet of length 11 only requires redundant data of length 16. The redundancy is much less than the padding case.=20 =20 Figure 2. Source block without padding |-Source Block---| =20 +----------------+ |40xxxxxxxxxxxxxx| +----------------+ |xxxxxxxxxxxxxxxx| +----------------+ |xxxxxxxxxx000000| +----------------+ |11xxxxxxxxxxx000| +----------------+ =20 If choosing non-padding strategy as an alternative for FEC protection, the position of source packet cannot be acquired simply by the sequence number. The information with greater detail, for example ESI of each source packet, have to be conveyed. These information may expand the FEC header in the repair flow to a fairly large size. An alternative is to convey them in a separate flow.=20 =20 > A generic mapping scheme for building source blocks of the variety of practical > FEC codes is a good idea, however I believe that this should be indicated in the > designated repair flow. >=20 > Until it is so, I don't believe that we should adopt > draft-zixuan-fecframe-source-mi as a working group item. >=20 The focus of our draft is on backward-compatibility issue. Separate flow is just an option. Based on the previous discussion on the draft, now we think defining a generic mapping information format for various ways of building source block in practice should be the most important issue for backward compatibility. We suggest to make this work (defining a generic mapping information format) to be a work item. We can update our draft to be the basis of this work.=20 =20 -----Original Message----- > From: Einat Yellin (Lachover) [mailto:Einat@radvision.com] > Sent: Tuesday, October 06, 2009 11:00 PM > To: gjshep@gmail.com > Cc: zouzixuan; Ali C. Begen (abegen); tme@multicasttech.com; > fecframe@ietf.org > Subject: RE: Working Group Item? was: Re: > [Fecframe]draft-zixuan-fecframe-source-mi ?? >=20 > Hi, >=20 > As I stated previously, I do not fully understand the motivation for using a > separate flow for conveying FEC payload mapping information. >=20 > A generic mapping scheme for building source blocks of the variety of practical > FEC codes is a good idea, however I believe that this should be indicated in the > designated repair flow. >=20 > Until it is so, I don't believe that we should adopt > draft-zixuan-fecframe-source-mi as a working group item. >=20 > Best regards, > Einat >=20 >=20 =20 -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of zouzixuan Sent: Monday, September 28, 2009 10:57 AM To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover); tme@multicasttech.com; gjshep@gmail.com; fecframe@ietf.org Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ?? =20 Hi, Ali =20 > I am not questioning backward compatibility, I am questioning the cost for it > and the scenarios where we want backward compatibility. Einat did a good > summary, so now the WG needs to provide input. You mean there should be some input on backward compatibility to the framework. =20 =20 > Regarding your example, putting the audio and video packets into the source > blocks as they are available does not seem to be a good design choice to me. > When I say "systematic," I mean you can create your source blocks in a > deterministic way (such as 4 packets from stream 1, one packet from stream 2). > Variable-packet size can be handled. =20 In this "systematic" case, how could we know the position of a packet in the source block?=20 [Einat] There are different ways to signal the source block structure. In our draft we followed rfc 5109 and used the 'base' (first) RTP sequence number along with a bitmap. This works for the cases where what matters is which RTP packets belong to this FEC source block and the order of the packets in the FEC source block is deterministic (from lower SN to higher SN and from lower flow ID to higher flow ID). If a more detailed structure of source block is needed then I agree that the bitmap is not enough. Still, this information can be sent as part of the repair packet header which IMO makes more sense. =20 =20 ------_=_NextPart_001_01CA4A32.33C595A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The recovery performance degradation while padding is = there, I agree.

However, this is one factor out of many that the = application needs to consider while choosing the FEC scheme to = use.

For example, if recovery performance is critical one can = choose using 1D2D scheme, which is less demanding on CPU = power.

 

In addition, for high bit rate video applications, such = as the one we designed and implemented our scheme for, it is common to use MTU = size for RTP packets to reduce overhead. This makes the recovery performance = degradation due to padding negligible.

 

Einat

 

From:= zouzixuan = [mailto:tendyntu@huawei.com]
Sent: Friday, October 09, 2009 1:40 PM
To: Einat Yellin (Lachover); gjshep@gmail.com
Cc: 'Ali C. Begen (abegen)'; tme@multicasttech.com; = fecframe@ietf.org
Subject: RE: RE: Working Group Item? was: Re:[Fecframe]draft-zixuan-fecframe-source-mi ??

 

Hi,

> Hi,

>

> As I stated previously, I do not fully = understand the motivation for using a

> separate flow for conveying FEC payload = mapping information.

 

         &nbs=
p;          As stated in =
your draft: “Add padding (bytes containing binary zeroes) =
so that the byte array is in the size of the largest packet protected by =
this source block including the two bytes from section a.  (The largest packet =
does not contain zero padding).”, conveying FEC payload mapping information in repair flow =
needs padding. But padding may lead to recovery performance degradation. =
 We give an example, as the figures show below. =

 
 
For the padding case as depicted in Figure 1, the redundant =
data for recovering the packet of length 11 is 48, which is same as that =
for the packet of length =
40.
 

Figure1. Source = block with padding

|-Source Block---|           &=
nbsp;      
+----------------+
|40xxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxx000000|
+----------------+
|11xxxxxxxxxxx000|
+----------------+
|0000000000000000|
+----------------+
|0000000000000000|
+----------------+
 
 
 
For a non-padding case as depicted in Figure2, recovering the packet =
of length 11 only requires redundant data of length 16. The redundancy =
is much less than the padding case. 
 
           &nbs=
p;            =
;            =
            &=
nbsp;   Figure 2. Source block without =
padding
|-Source Block---|           &=
nbsp;      
+----------------+
|40xxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxxxxxxxx|
+----------------+
|xxxxxxxxxx000000|
+----------------+
|11xxxxxxxxxxx000|
+----------------+

 

If choosing = non-padding strategy as an alternative for FEC protection, the position of source = packet cannot be acquired simply by the sequence number. The information with = greater detail, for example ESI of each source packet, have to be conveyed. = These information may expand the FEC header in the repair flow to a fairly = large size. An alternative is to convey them in a separate flow. =

 

> A generic mapping scheme for building = source blocks of the variety of practical

> FEC codes is a good idea, however I believe = that this should be indicated in the

> designated repair flow.

>

> Until it is so, I don't believe that we = should adopt

> draft-zixuan-fecframe-source-mi as a = working group item.

>

The focus of our = draft is on backward-compatibility issue. Separate flow is just an option. Based on = the previous discussion on the draft, now we think defining a generic = mapping information format for various ways of building source block in practice = should be the most important issue for backward compatibility. We suggest to = make this work (defining a generic mapping information format) to be a work item. = We can update our draft to be the basis of this work.

 

-----Original Message-----

> From: Einat Yellin (Lachover) [mailto:Einat@radvision.com]

> Sent: Tuesday, October 06, 2009 11:00 = PM

> To: gjshep@gmail.com

> Cc: zouzixuan; Ali C. Begen (abegen); tme@multicasttech.com;

> fecframe@ietf.org

> Subject: RE: Working Group Item? was: = Re:

> [Fecframe]draft-zixuan-fecframe-source-mi = ??

>

> Hi,

>

> As I stated previously, I do not fully = understand the motivation for using a

> separate flow for conveying FEC payload = mapping information.

>

> A generic mapping scheme for building = source blocks of the variety of practical

> FEC codes is a good idea, however I believe = that this should be indicated in the

> designated repair flow.

>

> Until it is so, I don't believe that we = should adopt

> draft-zixuan-fecframe-source-mi as a = working group item.

>

> Best regards,

> Einat

>

> 

 

-----Original Message-----

From: fecframe-bounces@ietf.org = [mailto:fecframe-bounces@ietf.org] On Behalf Of zouzixuan

Sent: Monday, September 28, 2009 10:57 = AM

To: 'Ali C. Begen (abegen)'; Einat Yellin = (Lachover); tme@multicasttech.com; gjshep@gmail.com; = fecframe@ietf.org

Subject: Re: [Fecframe] = draft-zixuan-fecframe-source-mi ??

 

Hi, Ali

 

> I am not questioning backward = compatibility, I am questioning the cost

for

it

> and the scenarios where we want backward compatibility. Einat did a

good

> summary, so now the WG needs to provide = input.

You mean there should be some input on backward compatibility to the framework.

 

 

> Regarding your example, putting the audio = and video packets into the

source

> blocks as they are available does not seem = to be a good design choice

to

me.

> When I say "systematic," I mean = you can create your source blocks in a

> deterministic way (such as 4 packets from = stream 1, one packet from

stream

2).

> Variable-packet size can be = handled.

 

In this "systematic" case, how could = we know the position of a packet in the source block?

[Einat] There are different ways to signal the = source block structure.

In our draft we followed rfc 5109 and used the = 'base' (first) RTP sequence number along with a bitmap. This works for the = cases where what matters is which RTP packets belong to this FEC source block and = the order of the packets in the FEC source block is deterministic (from lower SN = to higher SN and from lower flow ID to higher flow ID). If a more detailed structure of source block is needed then I agree that the bitmap is not = enough. Still, this information can be sent as part of the repair packet header = which IMO makes more sense.

 

 
------_=_NextPart_001_01CA4A32.33C595A2-- From gjshep@gmail.com Mon Oct 12 02:05:45 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 998BB3A6906 for ; Mon, 12 Oct 2009 02:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7BwjnyOco5i for ; Mon, 12 Oct 2009 02:05:45 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id D29BC3A680D for ; Mon, 12 Oct 2009 02:05:44 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so475061qwb.31 for ; Mon, 12 Oct 2009 02:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=fvakvviBbIfB7h0SWl0W/Wun8oRK68rxBgpOLfJR79Q=; b=jdFv9E0Y7xumxg7LcnwCtPIgCa4Cx9xZXskrq6QZeI9xtzt5s9n+llGzvC8psoe6rD uy+8G/o/6aBR22y8ACUKOgdwMQ+UeOWiiGyy6PPFuta8ARJoJT0jDmV0rJwE/XF2GFz0 9U1B/n/pJe84uNyJbxJoq0pDgpPKO4/nTqdxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=JHQv2mAj+MIIkS0xGqQjpwKbOYIcj9G/HavpPzw4UIX9NRic9pytfHmu7wCYJMF7a0 bQez3P08bJ6gSQqZdQEPv6yUVgP4CkVOQfeXlqUvIy1IeJgODVtOBNQ3r8x1s7Ggz3U5 eXLVq6l27oiqvcf/bGelXVoZAKPYr/tSdO9Xo= MIME-Version: 1.0 Received: by 10.229.43.211 with SMTP id x19mr2318434qce.3.1255338342199; Mon, 12 Oct 2009 02:05:42 -0700 (PDT) Date: Mon, 12 Oct 2009 02:05:42 -0700 Message-ID: <38c19b540910120205v2243376cyb38ed381223a8a8f@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] draft-begen-fecframe-dvb-al-fec X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 09:05:45 -0000 Please consider the message as the last-call announcement for draft-begen-fecframe-dvb-al-fec. We are running up against the dates for Hiroshima and I'd like to get this process moving as quickly as possible. Please read and provide all feedback by the end of this week, Friday Oct 16th 1700 GMT. If there are no significant objections I'll follow-up next week the the Document Shepherd Write-up and a request for publication. Thanks everyone, Greg From orlyp@radvision.com Tue Oct 13 00:01: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 807C83A688A for ; Tue, 13 Oct 2009 00:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JFt5sXJCKVRg for ; Tue, 13 Oct 2009 00:01:01 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id E99013A67FB for ; Tue, 13 Oct 2009 00:01:00 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n9D70iSN019520 for fecframe@ietf.org; Tue, 13 Oct 2009 09:00:44 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n9D70ir6019514 for ; Tue, 13 Oct 2009 09:00:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4BD2.DBE64062" Date: Tue, 13 Oct 2009 09:00:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft: RTP Payload Format for Reed Solomon FEC Thread-Index: AcpL0tqdfJkhBwrvQEChjHzVFJ7VsA== From: "Orly Peck" To: Subject: [Fecframe] new draft: RTP Payload Format for Reed Solomon FEC X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 07:01:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4BD2.DBE64062 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A new draft was posted: "RTP Payload Format for Reed Solomon FEC". This draft is based on the draft-galanos-fecframe-rtp-reedsolomon-mf-00 which was presented at IETF 75 by Einat Yellin.=20 This new draft defines a format for Reed-Solomon for a single flow as was agreed in the IETF meeting. This document defines a new RTP payload format for the Forward Error Correction (FEC) that uses Reed-Solomon codes. The format defined by this document enables the protection of source media encapsulated in RTP with one or more repair flows and is based on the FEC framework. The Reed-Solomon codes used in this document belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against random and bursty packet losses. =20 Please find the draft under: http://tools.ietf.org/id/draft-galanos-fecframe-rtp-reedsolomon-00.txt =20 Comments and feedback are appreciated. =20 Thanks, Orly Peck. =20 ------_=_NextPart_001_01CA4BD2.DBE64062 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

A new draft was posted: “RTP Payload Format for Reed Solomon = FEC”.

This draft is based on the = draft-galanos-fecframe-rtp-reedsolomon-mf-00 which was presented at IETF 75 by Einat Yellin.
This new draft defines a format for Reed-Solomon for a single flow as = was agreed in the IETF meeting.

This document defines a new RTP payload format for = the Forward Error Correction (FEC) that uses Reed-Solomon codes.  The = format defined by this document enables the protection of source media = encapsulated in RTP with

one or more repair flows and is based on the FEC = framework.

The Reed-Solomon codes used in this document belong = to the class of Maximum Distance Separable (MDS) codes which means they offer optimal = protection against random and bursty packet losses.

 

Please =
find the draft under:
http://tools.ietf.org/id/draft-galanos-fecframe-rtp-reedsolomon-00=
.txt
 
Comments =
and feedback are =
appreciated.
 
Thanks,
Orly =
Peck.

 

------_=_NextPart_001_01CA4BD2.DBE64062-- From abegen@cisco.com Wed Oct 14 09:19: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 1983E3A6839 for ; Wed, 14 Oct 2009 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 A5Ue1nXSBwGf for ; Wed, 14 Oct 2009 09:19:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2AC213A6816 for ; Wed, 14 Oct 2009 09:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1117; q=dns/txt; s=sjiport03001; t=1255537180; x=1256746780; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Ali=20C.=20Begen=20(abegen)"=20|Subject:=20FW:=20[MMUSIC]=20WGLC=20on=20draft-ietf-mmu sic-rfc4756bis-03|Date:=20Wed,=2014=20Oct=202009=2009:19: 16=20-0700|Message-ID:=20<04CAD96D4C5A3D48B1919248A8FE0D5 40A636394@xmb-sjc-215.amer.cisco.com>|To:=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20q uoted-printable; bh=yPc9ryCqDsRMJduMqiYRlzJDkr8gXus7+RocOGozvP4=; b=NJ1biRU4D0erYEZY/oreCu33K8AslbhWiKeDqnKkuUo9qC1UrbORHMDQ 7FIleWzaCsuO2wDIlU7rV4CrlHokJKl0QHuTvtTJXXstUbsOCeKqfuyVe dv4NxQLC8VBGRxcN6+XYkGlxzpNinaIhsvJNUKLXOKVqaEJ6kUVK1AF0U E=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANOW1UqrR7Ht/2dsb2JhbADCDJhYhC4E X-IronPort-AV: E=Sophos;i="4.44,559,1249257600"; d="scan'208";a="196651234" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Oct 2009 16:19:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EGJed8024459 for ; Wed, 14 Oct 2009 16:19:40 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 09:19:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 09:19:16 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A636394@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 Thread-Index: AcpM6M4YlHJPdxh7ScGv3yGY13jt2wAANOgQ From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 14 Oct 2009 16:19:40.0468 (UTC) FILETIME=[21AF5F40:01CA4CEA] Subject: [Fecframe] FW: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 16:19:39 -0000 This is the WGLC for the 4756bis draft. Recall that this is an essential update for the framework and needs to = be approved before we can finalize the SDP draft. So, please review it = and send your yeah/nah to mmusic@ietg.org. It is a short spec, won't take much time. http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03 Thanks, acbegen. -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Jean-Francois Mule Sent: Wednesday, October 14, 2009 12:10 PM To: mmusic@ietf.org Cc: Joerg Ott; draft-ietf-mmusic-rfc4756bis@tools.ietf.org Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 This is to start a 2-week working group last call on draft draft-ietf-mmusic-rfc4756bis-03, http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03. The comment period will end on Wednesday October 28. Please send your comments to the mmusic list and the authors. Thank you, Jean-Francois. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From abegen@cisco.com Thu Oct 15 15:50:33 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 39EF428C16E for ; Thu, 15 Oct 2009 15:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 FJ0NJau55v3e for ; Thu, 15 Oct 2009 15:50:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id AF8743A67FA for ; Thu, 15 Oct 2009 15:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1863; q=dns/txt; s=sjiport03001; t=1255647035; x=1256856635; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Ali=20C.=20Begen=20(abegen)"=20|Subject:=20RE:=20[Fecframe]=20FW:=20[MMUSIC]=20WGLC=20 on=20draft-ietf-mmusic-rfc4756bis-03|Date:=20Thu,=2015=20 Oct=202009=2015:50:32=20-0700|Message-ID:=20<04CAD96D4C5A 3D48B1919248A8FE0D540A6E7326@xmb-sjc-215.amer.cisco.com> |To:=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D540A636394 @xmb-sjc-215.amer.cisco.com>|References:=20<04CAD96D4C5A3 D48B1919248A8FE0D540A636394@xmb-sjc-215.amer.cisco.com>; bh=PoVkNAy1XyrF9AY0/dontV/iyzNnNCac7ipgEMFyNCc=; b=OmS7w9IHzmH+AkYVwKhrkRoPIjirMZlDcQUX6k6elJq626P4m4Hz59kJ VBB0smt6rMqsfpPgbFFZl08teU4dH6M443g0+v8Agjl+3hs18066/Q7It NAiSvTfJAiHbt0D1Tw9txcYsEVbGgmYqroPwozT7eE/+gl1q5v4cdwFyY o=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALpD10qrR7Ht/2dsb2JhbADAYZgwhDAE X-IronPort-AV: E=Sophos;i="4.44,568,1249257600"; d="scan'208";a="197065908" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 15 Oct 2009 22:50:35 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9FMoZXQ020046 for ; Thu, 15 Oct 2009 22:50:35 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 15:50:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 15:50:32 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A6E7326@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A636394@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] FW: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 Thread-Index: AcpM6M4YlHJPdxh7ScGv3yGY13jt2wAANOgQAEAJfyA= References: <04CAD96D4C5A3D48B1919248A8FE0D540A636394@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 15 Oct 2009 22:50:35.0485 (UTC) FILETIME=[E860B0D0:01CA4DE9] Subject: Re: [Fecframe] FW: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 22:50:33 -0000 Here is a quick update on the draft based on some comments from MMUSIC. http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-04 Please review this one, if you are planning to do a review. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Ali C. > Begen (abegen) > Sent: Wednesday, October 14, 2009 12:19 PM > To: fecframe@ietf.org > Subject: [Fecframe] FW: [MMUSIC] WGLC on = draft-ietf-mmusic-rfc4756bis-03 >=20 > This is the WGLC for the 4756bis draft. >=20 > Recall that this is an essential update for the framework and needs to = be approved before > we can finalize the SDP draft. So, please review it and send your = yeah/nah to > mmusic@ietg.org. >=20 > It is a short spec, won't take much time. > http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03 >=20 > Thanks, acbegen. >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Jean-Francois > Mule > Sent: Wednesday, October 14, 2009 12:10 PM > To: mmusic@ietf.org > Cc: Joerg Ott; draft-ietf-mmusic-rfc4756bis@tools.ietf.org > Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 >=20 > This is to start a 2-week working group last call on draft > draft-ietf-mmusic-rfc4756bis-03, > http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03. The = comment > period will end on Wednesday October 28. >=20 > Please send your comments to the mmusic list and the authors. >=20 > Thank you, > Jean-Francois. >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From ulas.kozat@gmail.com Fri Oct 16 16:09:14 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 BB51B28C121 for ; Fri, 16 Oct 2009 16:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 RSCxi6yrVvdd for ; Fri, 16 Oct 2009 16:09:14 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id D3A6F3A657C for ; Fri, 16 Oct 2009 16:09:13 -0700 (PDT) Received: by ywh13 with SMTP id 13so3423976ywh.29 for ; Fri, 16 Oct 2009 16:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q1jOLgbqem8d7Nt6yqYuoDEPFUaBTqng34ICnrrj5LY=; b=hRf4gFjgAS5K4iyLVlVJmzc4uriajNFTGkR3/+xB6A0jqGENWlwEntHq9LT9O/OL53 2/lFdL0J/4nhA2wiGObfwZAb4vp0Gw9d1TaCopk6Tw0aKpjUvs/jigVdY28bVcutBtpC ntnfmC8A83nixn+A1z3e/Q6uPNN8zXs4w51hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tc4s7Gn17iLQ3WsB4p45aSVIOV40NFXmiyzpaHXaCwTcZQEteI5fOoJ0SHMzEF1lsZ kRIoJyKy3EpUq9ctOGHi8s5MUliG8KxYP4OLDLHwzetJaTq6+m8QZV6a5OpAsrVFFY3c ouRrzsuBGNDK+sBt1+0KH5uZSxDJhyZqRk89E= MIME-Version: 1.0 Received: by 10.150.173.17 with SMTP id v17mr3831990ybe.80.1255734554711; Fri, 16 Oct 2009 16:09:14 -0700 (PDT) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A6E7326@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540A636394@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540A6E7326@xmb-sjc-215.amer.cisco.com> Date: Fri, 16 Oct 2009 16:09:14 -0700 Message-ID: <241bc2150910161609u5fb572asfbe4e4ad94357fad@mail.gmail.com> From: =?UTF-8?B?VWxhxZ8gQy4gS296YXQ=?= To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] FW: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 23:09:14 -0000 Ali, I read the draft. Assuming the usage of other SDP lines are correct, I think the draft is clear enough. I have two minor comments that might add further clarity to the document: 1. In Section 1, the sentence "However, not all FEC schemes support the full range of possible scenarios (e.g., when the source streams carry different top-level media types such as audio and video)." is vague. Maybe removing this sentence and combining with the following paragraph can make a better transition. 2. In Section 4.4., you refer to Section 3.1 in two places saying that limitations in that section should be kept in mind. When I look at Section 3.1, it mainly describes the changes from other RFCs rather than listing specific limitations. Ulas On Thu, Oct 15, 2009 at 3:50 PM, Ali C. Begen (abegen) w= rote: > Here is a quick update on the draft based on some comments from MMUSIC. > http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-04 > > Please review this one, if you are planning to do a review. > > -acbegen > >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Be= half Of Ali C. >> Begen (abegen) >> Sent: Wednesday, October 14, 2009 12:19 PM >> To: fecframe@ietf.org >> Subject: [Fecframe] FW: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 >> >> This is the WGLC for the 4756bis draft. >> >> Recall that this is an essential update for the framework and needs to b= e approved before >> we can finalize the SDP draft. So, please review it and send your yeah/n= ah to >> mmusic@ietg.org. >> >> It is a short spec, won't take much time. >> http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03 >> >> Thanks, acbegen. >> >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf= Of Jean-Francois >> Mule >> Sent: Wednesday, October 14, 2009 12:10 PM >> To: mmusic@ietf.org >> Cc: Joerg Ott; draft-ietf-mmusic-rfc4756bis@tools.ietf.org >> Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 >> >> This is to start a 2-week working group last call on draft >> draft-ietf-mmusic-rfc4756bis-03, >> http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03. =A0The comme= nt >> period will end on Wednesday October 28. >> >> Please send your comments to the mmusic list and the authors. >> >> Thank you, >> Jean-Francois. >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From abegen@cisco.com Fri Oct 16 16:44: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 1B3EC3A6947; Fri, 16 Oct 2009 16:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 9K5LmgUq8YI5; Fri, 16 Oct 2009 16:44:40 -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 085CF3A6808; Fri, 16 Oct 2009 16:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=4722; q=dns/txt; s=sjiport05001; t=1255736684; x=1256946284; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Ali=20C.=20Begen=20(abegen)"=20|Subject:=20RE:=20[Fecframe]=20FW:=20[MMUSIC]=20WGLC=20 on=20draft-ietf-mmusic-rfc4756bis-03|Date:=20Fri,=2016=20 Oct=202009=2016:44:42=20-0700|Message-ID:=20<04CAD96D4C5A 3D48B1919248A8FE0D540A6E765F@xmb-sjc-215.amer.cisco.com> |To:=20=3D?UTF-8?B?VWxhxZ8gQy4gS296YXQ=3D?=3D=20|Cc:=20,=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20base 64|In-Reply-To:=20<241bc2150910161609u5fb572asfbe4e4ad943 57fad@mail.gmail.com>|References:=20<04CAD96D4C5A3D48B191 9248A8FE0D540A636394@xmb-sjc-215.amer.cisco.com>=20<04CAD 96D4C5A3D48B1919248A8FE0D540A6E7326@xmb-sjc-215.amer.cisc o.com>=20<241bc2150910161609u5fb572asfbe4e4ad94357fad@mai l.gmail.com>; bh=xqFveWIoRacO9fTbqzjrqmk6VMkpHzn+A+tbaoE8eZM=; b=iKVGkCticE+GtWVf+OIG7AeuQ25/DBkc2Xvm5qUPX5B9syXJId164QPL AmKgH7/Hhd4ZVFPzvsaZvA2jG1dszVgQirO4uEm7LoaExcUqRYkjk5YQk dUCGd8pTzJiP+6kVeWeK/1cOXZ7Am/gRUx2qksXd0pNFYo6AS5AqoFcBV g=; Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAJei2EqrRN+J/2dsb2JhbACZZKZumAyEMQQ X-IronPort-AV: E=Sophos;i="4.44,576,1249257600"; d="scan'208";a="99257945" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 16 Oct 2009 23:44:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n9GNiiB5019378; Fri, 16 Oct 2009 23:44:44 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 16:44:44 -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: Fri, 16 Oct 2009 16:44:42 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A6E765F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <241bc2150910161609u5fb572asfbe4e4ad94357fad@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] FW: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 Thread-Index: AcpOta5M4YqNpOznSkijjk6DShIr9wABLNTg References: <04CAD96D4C5A3D48B1919248A8FE0D540A636394@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540A6E7326@xmb-sjc-215.amer.cisco.com> <241bc2150910161609u5fb572asfbe4e4ad94357fad@mail.gmail.com> From: "Ali C. Begen (abegen)" To: =?UTF-8?B?VWxhxZ8gQy4gS296YXQ=?= X-OriginalArrivalTime: 16 Oct 2009 23:44:44.0637 (UTC) FILETIME=[A36FB0D0:01CA4EBA] Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] FW: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 23:44:41 -0000 VGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJJ2xsIGFkZHJlc3MgdGhlc2UgZWRpdG9yaWFsIGZpeGVz IGluIHRoZSBuZXh0IHJldmlzaW9uIHdpdGggYWxsIG90aGVyIGNvbW1lbnRzIHRoYXQgbWF5IGJl IHJlY2VpdmVkLiBDQydpbmcgbW11c2ljLg0KDQotYWNiZWdlbg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFVsYcWfIEMuIEtvemF0IFttYWlsdG86dWxhcy5rb3phdEBn bWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNiwgMjAwOSA3OjA5IFBNDQo+IFRv OiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCj4gQ2M6IGZlY2ZyYW1lQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbRmVjZnJhbWVdIEZXOiBbTU1VU0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11c2lj LXJmYzQ3NTZiaXMtMDMNCj4gDQo+IEFsaSwNCj4gDQo+IEkgcmVhZCB0aGUgZHJhZnQuIEFzc3Vt aW5nIHRoZSB1c2FnZSBvZiBvdGhlciBTRFAgbGluZXMgYXJlIGNvcnJlY3QsIEkNCj4gdGhpbmsg dGhlIGRyYWZ0IGlzIGNsZWFyIGVub3VnaC4gSSBoYXZlIHR3byBtaW5vciBjb21tZW50cyB0aGF0 IG1pZ2h0DQo+IGFkZCBmdXJ0aGVyIGNsYXJpdHkgdG8gdGhlIGRvY3VtZW50Og0KPiANCj4gMS4g SW4gU2VjdGlvbiAxLCB0aGUgc2VudGVuY2UgIkhvd2V2ZXIsIG5vdCBhbGwgRkVDIHNjaGVtZXMg c3VwcG9ydA0KPiB0aGUgZnVsbCByYW5nZSBvZiBwb3NzaWJsZSBzY2VuYXJpb3MgKGUuZy4sIHdo ZW4gdGhlIHNvdXJjZSBzdHJlYW1zDQo+IGNhcnJ5IGRpZmZlcmVudCB0b3AtbGV2ZWwgbWVkaWEg dHlwZXMgc3VjaCBhcyBhdWRpbyBhbmQgdmlkZW8pLiIgaXMNCj4gdmFndWUuIE1heWJlIHJlbW92 aW5nIHRoaXMgc2VudGVuY2UgYW5kIGNvbWJpbmluZyB3aXRoIHRoZSBmb2xsb3dpbmcNCj4gcGFy YWdyYXBoIGNhbiBtYWtlIGEgYmV0dGVyIHRyYW5zaXRpb24uDQo+IA0KPiAyLiBJbiBTZWN0aW9u IDQuNC4sIHlvdSByZWZlciB0byBTZWN0aW9uIDMuMSBpbiB0d28gcGxhY2VzIHNheWluZyB0aGF0 DQo+IGxpbWl0YXRpb25zIGluIHRoYXQgc2VjdGlvbiBzaG91bGQgYmUga2VwdCBpbiBtaW5kLiBX aGVuIEkgbG9vayBhdA0KPiBTZWN0aW9uIDMuMSwgaXQgbWFpbmx5IGRlc2NyaWJlcyB0aGUgY2hh bmdlcyBmcm9tIG90aGVyIFJGQ3MgcmF0aGVyDQo+IHRoYW4gbGlzdGluZyBzcGVjaWZpYyBsaW1p dGF0aW9ucy4NCj4gDQo+IFVsYXMNCj4gDQo+IE9uIFRodSwgT2N0IDE1LCAyMDA5IGF0IDM6NTAg UE0sIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSA8YWJlZ2VuQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4g SGVyZSBpcyBhIHF1aWNrIHVwZGF0ZSBvbiB0aGUgZHJhZnQgYmFzZWQgb24gc29tZSBjb21tZW50 cyBmcm9tIE1NVVNJQy4NCj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW1tdXNpYy1yZmM0NzU2YmlzLTA0DQo+ID4NCj4gPiBQbGVhc2UgcmV2aWV3IHRoaXMgb25lLCBp ZiB5b3UgYXJlIHBsYW5uaW5nIHRvIGRvIGEgcmV2aWV3Lg0KPiA+DQo+ID4gLWFjYmVnZW4NCj4g Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBmZWNmcmFtZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86ZmVjZnJhbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFsaSBDLg0KPiA+PiBCZWdlbiAoYWJlZ2VuKQ0KPiA+PiBTZW50OiBXZWRuZXNkYXks IE9jdG9iZXIgMTQsIDIwMDkgMTI6MTkgUE0NCj4gPj4gVG86IGZlY2ZyYW1lQGlldGYub3JnDQo+ ID4+IFN1YmplY3Q6IFtGZWNmcmFtZV0gRlc6IFtNTVVTSUNdIFdHTEMgb24gZHJhZnQtaWV0Zi1t bXVzaWMtcmZjNDc1NmJpcy0wMw0KPiA+Pg0KPiA+PiBUaGlzIGlzIHRoZSBXR0xDIGZvciB0aGUg NDc1NmJpcyBkcmFmdC4NCj4gPj4NCj4gPj4gUmVjYWxsIHRoYXQgdGhpcyBpcyBhbiBlc3NlbnRp YWwgdXBkYXRlIGZvciB0aGUgZnJhbWV3b3JrIGFuZCBuZWVkcyB0byBiZSBhcHByb3ZlZA0KPiBi ZWZvcmUNCj4gPj4gd2UgY2FuIGZpbmFsaXplIHRoZSBTRFAgZHJhZnQuIFNvLCBwbGVhc2UgcmV2 aWV3IGl0IGFuZCBzZW5kIHlvdXIgeWVhaC9uYWggdG8NCj4gPj4gbW11c2ljQGlldGcub3JnLg0K PiA+Pg0KPiA+PiBJdCBpcyBhIHNob3J0IHNwZWMsIHdvbid0IHRha2UgbXVjaCB0aW1lLg0KPiA+ PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1yZmM0NzU2Ymlz LTAzDQo+ID4+DQo+ID4+IFRoYW5rcywgYWNiZWdlbi4NCj4gPj4NCj4gPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEplYW4tDQo+IEZyYW5jb2lz DQo+ID4+IE11bGUNCj4gPj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAyMDA5IDEyOjEw IFBNDQo+ID4+IFRvOiBtbXVzaWNAaWV0Zi5vcmcNCj4gPj4gQ2M6IEpvZXJnIE90dDsgZHJhZnQt aWV0Zi1tbXVzaWMtcmZjNDc1NmJpc0B0b29scy5pZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbTU1V U0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11c2ljLXJmYzQ3NTZiaXMtMDMNCj4gPj4NCj4gPj4g VGhpcyBpcyB0byBzdGFydCBhIDItd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFm dA0KPiA+PiBkcmFmdC1pZXRmLW1tdXNpYy1yZmM0NzU2YmlzLTAzLA0KPiA+PiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1yZmM0NzU2YmlzLTAzLiDCoFRoZSBj b21tZW50DQo+ID4+IHBlcmlvZCB3aWxsIGVuZCBvbiBXZWRuZXNkYXkgT2N0b2JlciAyOC4NCj4g Pj4NCj4gPj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbW11c2ljIGxpc3QgYW5k IHRoZSBhdXRob3JzLg0KPiA+Pg0KPiA+PiBUaGFuayB5b3UsDQo+ID4+IEplYW4tRnJhbmNvaXMu DQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gPj4gbW11c2ljQGlldGYub3Jn DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IEZl Y2ZyYW1lIG1haWxpbmcgbGlzdA0KPiA+PiBGZWNmcmFtZUBpZXRmLm9yZw0KPiA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lDQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBGZWNmcmFtZSBtYWlsaW5n IGxpc3QNCj4gPiBGZWNmcmFtZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZmVjZnJhbWUNCj4gPg0K From schierl@hhi.fhg.de Mon Oct 19 05:11: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 2463D3A67D7 for ; Mon, 19 Oct 2009 05:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.072 X-Spam-Level: X-Spam-Status: No, score=-5.072 tagged_above=-999 required=5 tests=[AWL=1.729, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 Wetz-yZOu4RR for ; Mon, 19 Oct 2009 05:11:03 -0700 (PDT) Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id 7F8B33A68BB for ; Mon, 19 Oct 2009 05:11:03 -0700 (PDT) Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 8BC5A1D89030; Mon, 19 Oct 2009 14:11:08 +0200 (CEST) Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C4160150036; Mon, 19 Oct 2009 14:11:08 +0200 (CEST) Received: from [130.149.228.125] (unknown [130.149.228.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Thomas Schierl", Issuer "Fraunhofer-Gesellschaft Root-CA v2" (not verified)) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id 002871D88FCD; Mon, 19 Oct 2009 14:11:07 +0200 (CEST) Message-ID: <4ADC575B.9030504@hhi.fhg.de> Date: Mon, 19 Oct 2009 14:11:07 +0200 From: Thomas Schierl Organization: Fraunhofer HHI User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marshall Eubanks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-alterMIME: Yes Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC on draft-ietf-fecframe-dvb-al-fec-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 12:11:05 -0000 Dear all, Sorry, this is a very late feedback. Reading the draft with all it's ugly requirements and constraints on RFC 3550 is not a funny thing. But removing in version -03 the capital letter SHALLs, ... from section 2.1 seem to make it "less" wrong from the RTP perspective. One special comment I had with respect to the last paragraph in section 2.2: Does it really work to detect the content without signaling? Seems to be dangerous. Anyway, ignoring these issues, I think I am ok with it. Best regards, Thomas -- Thomas Schierl -------------- Fraunhofer HHI Marshall Eubanks wrote: > Hello; > > We would like to start a Working Group Last Call (WGLC) on > > http://www.ietf.org/id/draft-ietf-fecframe-dvb-al-fec-02.txt > > In view of the summer vacations, this will last until 23:59 UTC on > August 31. > > Tools information for this document can be found at > > http://tools.ietf.org/html/draft-ietf-fecframe-dvb-al-fec-02 > > The Intended status for this document is : Informational > > This document will require positive support from WG members (in > addition to the authors !) > to be advanced, so, please, review the draft and send comments and/or > statements of support or > non-support to the WG mailing list. > > Regards > Marshall Eubanks > Greg Shepherd > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > From abegen@cisco.com Mon Oct 19 09:15:47 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 B338828C1DE; Mon, 19 Oct 2009 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.876 X-Spam-Level: X-Spam-Status: No, score=-5.876 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXOJ8aSQOsiz; Mon, 19 Oct 2009 09:15:46 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AB3F628C1D6; Mon, 19 Oct 2009 09:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3574; q=dns/txt; s=sjiport04001; t=1255968953; x=1257178553; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Ali=20C.=20Begen=20(abegen)"=20|Subject:=20RE:=20[MMUSIC]=20WGLC=20on=20draft-ietf-mmu sic-rfc4756bis-03|Date:=20Mon,=2019=20Oct=202009=2009:15: 50=20-0700|Message-ID:=20<04CAD96D4C5A3D48B1919248A8FE0D5 40A6E7817@xmb-sjc-215.amer.cisco.com>|To:=20"Thomas=20Sch ierl"=20|Cc:=20"Jean-Francois=20Mule" =20,=20,=0D=0A=20 =20=20=20=20=20=20=20"Joerg=20Ott"=20, =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4ADC86D7.9030307@hhi.fhg.de>|References: =20<9AAEDF491EF7CA48AB587781B8F5D7C6024FEC0C@srvxchg3.cab lelabs.com>=20<4ADC589D.8000306@hhi.fhg.de>=20<04CAD96D4C 5A3D48B1919248A8FE0D540A6E779B@xmb-sjc-215.amer.cisco.com >=20<4ADC86D7.9030307@hhi.fhg.de>; bh=UjXcWGvqn5vkvf4C7a1PC9d9f90qXgdiBQhYsTY4rUE=; b=NwGNE0+2wx8PZOgeAcYs4JUx9b3oaBBMHCGkf5pVJ9JneckUyyWyDPjU L2nHpn4WK30hWKROv2m2He74dm20D0Rd+xAH1QAAAA82GT8SXbEfHXlc4 P8DPnYjr+si41VPgmsoCp1h0kumL1sCNcDK3AJoOZrmtBV/82UnaDc0Ab A=; Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHMt3EqrR7Ht/2dsb2JhbADEMpZ3hDEE X-IronPort-AV: E=Sophos;i="4.44,586,1249257600"; d="scan'208";a="45816066" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 19 Oct 2009 16:15:53 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9JGFrrI011848; Mon, 19 Oct 2009 16:15:53 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 09:15:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Oct 2009 09:15:50 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A6E7817@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4ADC86D7.9030307@hhi.fhg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 Thread-Index: AcpQ0ZUtBfUYh5EZQmafLgecsm2eSwABbIqA References: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEC0C@srvxchg3.cablelabs.com> <4ADC589D.8000306@hhi.fhg.de> <04CAD96D4C5A3D48B1919248A8FE0D540A6E779B@xmb-sjc-215.amer.cisco.com> <4ADC86D7.9030307@hhi.fhg.de> From: "Ali C. Begen (abegen)" To: "Thomas Schierl" X-OriginalArrivalTime: 19 Oct 2009 16:15:53.0695 (UTC) FILETIME=[6E954EF0:01CA50D7] Cc: Jean-Francois Mule , fecframe@ietf.org, mmusic@ietf.org, Joerg Ott Subject: Re: [Fecframe] [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 16:15:47 -0000 Cool, here is the new version addressing all remaining comments received = so far. http://www.ietf.org/id/draft-ietf-mmusic-rfc4756bis-05.txt Cheers, -acbegen > -----Original Message----- > From: Thomas Schierl [mailto:schierl@hhi.fhg.de] > Sent: Monday, October 19, 2009 11:34 AM > To: Ali C. Begen (abegen) > Cc: Jean-Francois Mule; mmusic@ietf.org; Joerg Ott; draft-ietf-mmusic- > rfc4756bis@tools.ietf.org > Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03 >=20 > Hi Ali, >=20 > Ali C. Begen (abegen) wrote: >=20 > Now, this sounds different than the first scenario you described = above, IMO. And, > this leads to the original SDP you gave: >=20 > a=3Dgroup:FEC-XR SB RB > a=3Dgroup:FEC-XR SB SE RB RB+E >=20 >=20 >=20 >=20 > You are right, RB and RB+E are meant to be additive with respect to = SB+SE. >=20 >=20 >=20 >=20 >=20 > section 4.1: >=20 > "Repair flows that are in different FEC groups are non- > additive.". >=20 >=20 >=20 > Why would it be contrary? Here, RB and RB+E are in the same line and = that is enough > to state their additivity. But, in this scenario, their joint decoding = helps the group of > SB+SE. The above SDP says if the source consists of SB only, then just = use RB only since > RB+E would not help with decoding. >=20 >=20 >=20 > If the signaling in the example above is in line with the intention = of > the draft, I would make the following modifications: >=20 > - You may add an "...exclusively in different FEC groups..." to the > sentence of section 4.1 above. >=20 >=20 >=20 > We can add this to make it stronger. But, I believe if two repair = flows are additive > in a group, it does not mean that they will also be additive in any = other group where one > of the source flows they protect is listed. >=20 >=20 >=20 > I think this makes the text clearer, at least to me. >=20 >=20 >=20 >=20 > Agree? >=20 >=20 >=20 > - Further, I would add the following text to section 4.1 to make it = clearer: >=20 > "In order to express multiple relations between source and repair = flows, > source and repair flows may appear in more than one FEC group." >=20 >=20 >=20 > I believe this was clear, but it is a good suggestion. >=20 >=20 >=20 > Good >=20 >=20 >=20 >=20 >=20 >=20 > I think the same should be valid for the FEC-SSRC grouping. >=20 >=20 >=20 > Sure. >=20 > Thanks for the review. Let me know if you agree with the above. >=20 >=20 >=20 > Thanks for the clarifications. I am ok with the changes and the = resulting draft. >=20 > Thomas >=20 >=20 >=20 >=20 > Cheers, acbegen. >=20 >=20 >=20 >=20 > Best regards, > Thomas >=20 >=20 > -- > Thomas Schierl > -------------- > Fraunhofer HHI >=20 >=20 >=20 > Jean-Francois Mule wrote: >=20 >=20 > This is to start a 2-week working group last call on draft > draft-ietf-mmusic-rfc4756bis-03, > http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03. The = comment > period will end on Wednesday October 28. >=20 > Please send your comments to the mmusic list and the authors. >=20 > Thank you, > Jean-Francois. >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > Thomas Schierl > -------------- > Fraunhofer HHI >=20 >=20 >=20 >=20 From orlyp@radvision.com Mon Oct 19 14:06: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 AFAF13A692F for ; Mon, 19 Oct 2009 14:06:02 -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=[AWL=0.001, 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 8Vf-clCf7dkq for ; Mon, 19 Oct 2009 14:06:02 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 960343A692E for ; Mon, 19 Oct 2009 14:05:58 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n9JL56aV027597 for fecframe@ietf.org; Mon, 19 Oct 2009 23:05:06 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n9JL56xf027591 for ; Mon, 19 Oct 2009 23:05:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA50FF.D3C19B7A" Date: Mon, 19 Oct 2009 23:05:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft: RTP Payload Format for Mulit-Flow FEC Thread-Index: AcpQ/9JxLiSO+7xhR+2rIFyF7JYrLA== From: "Orly Peck" To: Subject: [Fecframe] new draft: RTP Payload Format for Mulit-Flow FEC X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 21:06:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA50FF.D3C19B7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A new draft was posted: "RTP Payload Format for Multi-Flow FEC". This draft is based on the draft-galanos-fecframe-rtp-reedsolomon-mf-00 which was presented at IETF 75 by Einat Yellin.=20 This new draft defines a format for multi-flow FEC (generic for all FEC-schemes) as was agreed in the IETF meeting. This document defines a new RTP payload format for the Forward Error Correction (FEC) that is used to protect multiple source flows. The format defined by this document enables the protection of multiple media sources encapsulated in RTP with one or more repair flows and is based on the FEC framework and the SDP Elements for FEC Framework. ------_=_NextPart_001_01CA50FF.D3C19B7A-- From orlyp@radvision.com Mon Oct 19 14:12: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 AD2743A68FE for ; Mon, 19 Oct 2009 14:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 ia30maTRpvUH for ; Mon, 19 Oct 2009 14:12:17 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id F41A93A6802 for ; Mon, 19 Oct 2009 14:12:16 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n9JLBQCX027667 for fecframe@ietf.org; Mon, 19 Oct 2009 23:11:26 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n9JLBPCC027661 for ; Mon, 19 Oct 2009 23:11:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5100.B5A6C61E" Date: Mon, 19 Oct 2009 23:11:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new draft: RTP Payload Format for Mulit-Flow FEC Thread-Index: AcpRALULM3qNrmy8Rcq/k+WgWTW2eQ== From: "Orly Peck" To: Subject: [Fecframe] new draft: RTP Payload Format for Mulit-Flow FEC X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 21:12:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5100.B5A6C61E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A new draft was posted: "RTP Payload Format for Multi-Flow FEC". This draft is based on the draft-galanos-fecframe-rtp-reedsolomon-mf-00 which was presented at IETF 75 by Einat Yellin.=20 This new draft defines a format for multi-flow FEC (generic for all FEC-schemes) as was agreed in the IETF meeting. This document defines a new RTP payload format for the Forward Error Correction (FEC) that is used to protect multiple source flows. The format defined by this document enables the protection of multiple media sources encapsulated in RTP with one or more repair flows and is based on the FEC framework and the SDP Elements for FEC Framework. =20 Please find the draft under: http://tools.ietf.org/id/draft-peck-fecframe-rtp-mf-00.txt =20 Comments and feedback are appreciated. =20 Thanks, Orly Peck. =20 =20 ------_=_NextPart_001_01CA5100.B5A6C61E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

A new draft was posted: “RTP Payload Format for Multi-Flow = FEC”.

This draft is based on the = draft-galanos-fecframe-rtp-reedsolomon-mf-00 which was presented at IETF 75 by Einat Yellin.
This new draft defines a format for multi-flow FEC (generic for all FEC-schemes) as was agreed in the IETF meeting.

This document defines a new RTP payload format for = the Forward Error Correction (FEC) that is used to protect multiple source flows.  The format defined by this document enables the protection = of multiple media sources encapsulated in RTP with one or more repair flows = and is based on the FEC framework and the SDP Elements for FEC = Framework.

 

Please find the draft under:

http:=
//tools.ietf.org/id/draft-peck-fecframe-rtp-mf-00.txt
 
Comments =
and feedback are =
appreciated.
 
Thanks,
Orly =
Peck.



 



 
------_=_NextPart_001_01CA5100.B5A6C61E-- From gjshep@gmail.com Wed Oct 21 06:43:40 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 260583A696E for ; Wed, 21 Oct 2009 06:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 3TNuMVr67nfS for ; Wed, 21 Oct 2009 06:43:39 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 487C13A6950 for ; Wed, 21 Oct 2009 06:43:39 -0700 (PDT) Received: by iwn16 with SMTP id 16so3765960iwn.29 for ; Wed, 21 Oct 2009 06:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=Q5sZPwzIFrlSpVV1uvRYrDt1Q7jkO3DjkmPahZHdsMY=; b=Us8z/dorCLu3HCe48QSNhWmDSzGEvnaWjEq/ZKm0KueF4KbW3aK9ix4Rjqf3YVBfF5 Xz6UfK5rf1zlVfBHODAxbKRRV6zzqq3KNywu/vJO8kK2romK2VhZaq4T64XezYnTK75q CSJ0O1JwymYdvLx9DsLVGHbdB5XWlOvmrJz/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=inaRfJNKlBc3pothBm8eDf79gGcdBHYo4mJl6g4/8ScdFuRXSFS1RCsuWpHUpH95ST eqJeUycioUP1lyJD2VFIo0WB1sWF8k2e92pQafV6DjX16QCdMRgGTrIF09bUxEBp/ZbY M4fT1xQHaTL+poTbZgpZAH8aMLmu82/b6/b3M= MIME-Version: 1.0 Received: by 10.231.9.33 with SMTP id j33mr5709029ibj.37.1256132625237; Wed, 21 Oct 2009 06:43:45 -0700 (PDT) Date: Wed, 21 Oct 2009 06:43:45 -0700 Message-ID: <38c19b540910210643g4b3f23d9kff215e20ae7ce75e@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] Hiroshima and other bits.. X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 13:43:40 -0000 I'm back from work travel and now onto the WG tasks at hand. There were no objectionable comments on draft-ietf-fecframe-dvb-al-fec-03 so I'll be finishing the writeup today to move it along. Please send all agenda items for the Hiroshima WG meeting to me ASAP. I've gotten a couple already but we need to have the agenda public by next week. Thanks!, Greg From gjshep@gmail.com Thu Oct 22 07: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 8B65C3A688C for ; Thu, 22 Oct 2009 07:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 zPMF17y7iMv4 for ; Thu, 22 Oct 2009 07:23:04 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 5A2DB3A67C1 for ; Thu, 22 Oct 2009 07:23:04 -0700 (PDT) Received: by iwn16 with SMTP id 16so4484626iwn.29 for ; Thu, 22 Oct 2009 07:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type; bh=sMDemiPcOo5l2ovnJMM7pBgQEVK91M5cFhl0vfPrv4w=; b=UhLJr3LYdMlNThW/RQT5Dz4To+504tnLeM7Vx+v9Yr5sYqo+bc3yy6DkvvjO8CihMf ycyoA/pHIjd54GUR4i4Fj60tqbYG9lQfU2SqSYytZLGCEgr88tTD6Lh0T71lhNT1O4C5 PBIHFhZDBd/139CnzIV++d70+dY3/v9Un69Hw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=iAQ6N0J7uvR6Am6iXhD3yPcwgRcEI0cmQQurLx+Du7JPboojctL4yx6pr8z9qxqJG/ GIWrPIa7ZcciTaiiyYf16CBIUzr7sbneWpjnnvNwpCdlRuoO0kxtBS5U6ycQ7aEgwdlL GUOPRcLPgm3oy1j7BrMQtwni2CpmmPiAGrK4U= MIME-Version: 1.0 Received: by 10.231.122.208 with SMTP id m16mr10065316ibr.16.1256221391209; Thu, 22 Oct 2009 07:23:11 -0700 (PDT) Date: Thu, 22 Oct 2009 07:23:11 -0700 Message-ID: <38c19b540910220723q57eb2159s8ad4e976abd75839@mail.gmail.com> From: Greg Shepherd To: Magnus Westerlund , Eggert Lars , iesg-secretary@iesg.org Content-Type: multipart/mixed; boundary=0016e64078f0c84537047686d560 Cc: fecframe@ietf.org Subject: [Fecframe] draft-ietf-fecframe-dvb-al-fec Request for publication X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 14:23:05 -0000 --0016e64078f0c84537047686d560 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable *, The document draft-ietf-fecframe-dvb-al-fec-03 is now ready for publication. Please see the attached Document Shepherd Write-up. Thanks, Greg --- Document Shepherd Write-up for draft-ietf-fecframe-dvb-al-fec-03 1.a) The Document Shepherd is Greg Shepherd. 1.b) The document has had adequate review both from within and from outside the FECFrame working group. 1.c) There are no concerns regarding the need for additional expanded revie= w. 1.d) The only concern in regards to this document involves the interaction and acceptance of this work by DVB 1.e) There is solid WG consensus for this document. 1.f) There is no discontent. 1.g) idnits seems to have a bug where it treats the example SDP values in Section 3. of the draft as a domain name: vnd.dvb.iiptv.alfec. There are no other issues. 1.h) References are split between normative and informative. There are three normative references to drafts from the FECFrame WG that are also in the process of progressing to last-call: draft-ietf-fecframe-interleaved-fec-scheme draft-ietf-fecframe-raptor draft-ietf-fecframe-rtp-raptor There is one other normative reference to a draft in the MMUSIC WG that is also in the process of progressing to last-call: draft-ietf-mmusic-rfc4765bis 1.i) There are no IANA considerations 1.j) The xml code validates correctly 1.k) Technical Summary The Annex E of the DVB-IPTV technical specification defines an optional Application-layer Forward Error Correction (AL-FEC) protocol to protect the streaming media carried over RTP transport. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection: 1-D parity code base layer, and a Raptor code enhancement layer. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers a good protection against both bursty and random packet loss at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and the Raptor code which are specified in separate documents Working Group Summary There were no seriously contentious issues during the WG process. The only controversy stemmed from some individuals who did the work in SMPTE and defied this approach in the DVB spec, who felt the IETF should not be doing this work. But there were industry requests for an IETF definition of the DVB spec and so this work progressed. Document Quality Any DVB-compliant implementation will be compliant with the DVP-IPTV AL-FEC specification as well. Personal Document Shepherd =96 Greg Shepherd Responsible Area Director - TBD --0016e64078f0c84537047686d560 Content-Type: text/plain; name="AL-FEC_Write-up.txt" Content-Disposition: attachment; filename="AL-FEC_Write-up.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g13lrpxi0 RG9jdW1lbnQgU2hlcGhlcmQgV3JpdGUtdXAgZm9yIGRyYWZ0LWlldGYtZmVjZnJhbWUtZHZiLWFs LWZlYy0wMw0KDQoxLmEpIFRoZSBEb2N1bWVudCBTaGVwaGVyZCBpcyBHcmVnIFNoZXBoZXJkLg0K DQoxLmIpIFRoZSBkb2N1bWVudCBoYXMgaGFkIGFkZXF1YXRlIHJldmlldyBib3RoIGZyb20gd2l0 aGluIGFuZCBmcm9tIG91dHNpZGUgdGhlIEZFQ0ZyYW1lIHdvcmtpbmcgZ3JvdXAuDQoNCjEuYykg VGhlcmUgYXJlIG5vIGNvbmNlcm5zIHJlZ2FyZGluZyB0aGUgbmVlZCBmb3IgYWRkaXRpb25hbCBl eHBhbmRlZCByZXZpZXcuDQoNCjEuZCkgVGhlIG9ubHkgY29uY2VybiBpbiByZWdhcmRzIHRvIHRo aXMgZG9jdW1lbnQgaW52b2x2ZXMgdGhlIGludGVyYWN0aW9uIGFuZCBhY2NlcHRhbmNlIG9mIHRo aXMgd29yayBieSBEVkINCg0KMS5lKSBUaGVyZSBpcyBzb2xpZCBXRyBjb25zZW5zdXMgZm9yIHRo aXMgZG9jdW1lbnQuDQoNCjEuZikgVGhlcmUgaXMgbm8gZGlzY29udGVudC4NCg0KMS5nKSBpZG5p dHMgc2VlbXMgdG8gaGF2ZSBhIGJ1ZyB3aGVyZSBpdCB0cmVhdHMgdGhlIGV4YW1wbGUgU0RQIHZh bHVlcyBpbiBTZWN0aW9uIDMuIG9mIHRoZSBkcmFmdCBhcyBhIGRvbWFpbiBuYW1lOiB2bmQuZHZi LmlpcHR2LmFsZmVjLiBUaGVyZSBhcmUgbm8gb3RoZXIgaXNzdWVzLg0KDQoxLmgpIFJlZmVyZW5j ZXMgYXJlIHNwbGl0IGJldHdlZW4gbm9ybWF0aXZlIGFuZCBpbmZvcm1hdGl2ZS4gVGhlcmUgYXJl IHRocmVlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIGRyYWZ0cyBmcm9tIHRoZSBGRUNGcmFtZSBX RyB0aGF0IGFyZSBhbHNvIGluIHRoZSBwcm9jZXNzIG9mIHByb2dyZXNzaW5nIHRvIGxhc3QtY2Fs bDoNCmRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZQ0KZHJhZnQtaWV0 Zi1mZWNmcmFtZS1yYXB0b3INCmRyYWZ0LWlldGYtZmVjZnJhbWUtcnRwLXJhcHRvcg0KVGhlcmUg aXMgb25lIG90aGVyIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYSBkcmFmdCBpbiB0aGUgTU1VU0lD IFdHIHRoYXQgaXMgYWxzbyBpbiB0aGUgcHJvY2VzcyBvZiBwcm9ncmVzc2luZyB0byBsYXN0LWNh bGw6DQpkcmFmdC1pZXRmLW1tdXNpYy1yZmM0NzY1YmlzDQoNCjEuaSkgVGhlcmUgYXJlIG5vIElB TkEgY29uc2lkZXJhdGlvbnMNCg0KMS5qKSBUaGUgeG1sIGNvZGUgdmFsaWRhdGVzIGNvcnJlY3Rs eQ0KDQoxLmspDQoNClRlY2huaWNhbCBTdW1tYXJ5DQoJVGhlIEFubmV4IEUgb2YgdGhlIERWQi1J UFRWIHRlY2huaWNhbCBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYW4gb3B0aW9uYWwgQXBwbGljYXRp b24tbGF5ZXIgRm9yd2FyZCBFcnJvciBDb3JyZWN0aW9uIChBTC1GRUMpIHByb3RvY29sIHRvIHBy b3RlY3QgdGhlIHN0cmVhbWluZyBtZWRpYSBjYXJyaWVkIG92ZXIgUlRQIHRyYW5zcG9ydC4gVGhl IERWQi1JUFRWIEFMLUZFQyBwcm90b2NvbCB1c2VzIHR3byBsYXllcnMgZm9yIEZFQyBwcm90ZWN0 aW9uOiAxLUQgcGFyaXR5IGNvZGUgYmFzZSBsYXllciwgYW5kIGEgUmFwdG9yIGNvZGUgZW5oYW5j ZW1lbnQgbGF5ZXIuIEJ5IG9mZmVyaW5nIGEgbGF5ZXJlZCBhcHByb2FjaCwgdGhlIERWQi1JUFRW IEFMLUZFQyBwcm90b2NvbCBvZmZlcnMgYSBnb29kIHByb3RlY3Rpb24gYWdhaW5zdCBib3RoIGJ1 cnN0eSBhbmQgcmFuZG9tIHBhY2tldCBsb3NzIGF0IGEgY29zdCBvZiBkZWNlbnQgY29tcGxleGl0 eS4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IG9uZSBjYW4gaW1wbGVtZW50IHRoZSBEVkIt SVBUViBBTC1GRUMgcHJvdG9jb2wgYnkgdXNpbmcgdGhlIDEtRCBpbnRlcmxlYXZlZCBwYXJpdHkg Y29kZSBhbmQgdGhlIFJhcHRvciBjb2RlIHdoaWNoIGFyZSBzcGVjaWZpZWQgaW4gc2VwYXJhdGUg ZG9jdW1lbnRzDQoNCldvcmtpbmcgR3JvdXAgU3VtbWFyeQ0KCVRoZXJlIHdlcmUgbm8gc2VyaW91 c2x5IGNvbnRlbnRpb3VzIGlzc3VlcyBkdXJpbmcgdGhlIFdHIHByb2Nlc3MuIFRoZSBvbmx5IGNv bnRyb3ZlcnN5IHN0ZW1tZWQgZnJvbSBzb21lIGluZGl2aWR1YWxzIHdobyBkaWQgdGhlIHdvcmsg aW4gU01QVEUgYW5kIGRlZmllZCB0aGlzIGFwcHJvYWNoIGluIHRoZSBEVkIgc3BlYywgd2hvIGZl bHQgdGhlIElFVEYgc2hvdWxkIG5vdCBiZSBkb2luZyB0aGlzIHdvcmsuIEJ1dCB0aGVyZSB3ZXJl IGluZHVzdHJ5IHJlcXVlc3RzIGZvciBhbiBJRVRGIGRlZmluaXRpb24gb2YgdGhlIERWQiBzcGVj IGFuZCBzbyB0aGlzIHdvcmsgcHJvZ3Jlc3NlZC4NCg0KRG9jdW1lbnQgUXVhbGl0eQ0KCUFueSBE VkItY29tcGxpYW50IGltcGxlbWVudGF0aW9uIHdpbGwgYmUgY29tcGxpYW50IHdpdGggdGhlIERW UC1JUFRWIEFMLUZFQyBzcGVjaWZpY2F0aW9uIGFzIHdlbGwuDQoNClBlcnNvbmFsDQoJRG9jdW1l bnQgU2hlcGhlcmQg0CBHcmVnIFNoZXBoZXJkDQoJUmVzcG9uc2libGUgQXJlYSBEaXJlY3RvciAt IFRCRA0KDQo= --0016e64078f0c84537047686d560-- From gjshep@gmail.com Thu Oct 22 10:42:37 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 4AF2928C0EB for ; Thu, 22 Oct 2009 10:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, MIME_BAD_LINEBREAK=0.5] 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 11I6F8Pdg1I6 for ; Thu, 22 Oct 2009 10:42:36 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 297C228C0E2 for ; Thu, 22 Oct 2009 10:42:36 -0700 (PDT) Received: by iwn16 with SMTP id 16so4626545iwn.29 for ; Thu, 22 Oct 2009 10:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=I5Q+W6fkI7E5np7+2XJKbBU4qqeOzH3vUTEKqfuA5Lg=; b=KxX/Ya3tN2rYn8Zxz1TJRuTHeN3+P1+q8XY1fKNx+bfH9EiisqEr8cELHFW7R+bttp qHIaQwcAJhxOnMmO9x8PBciSqtJhiQ2ke51UAudTQCFiifOYVLWqJnjtUYVWyrBJeXJc F/IBcsU02Gq46/VSNtJZ1kTDpOqxlPu9jXgxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=kGkl3LQ3dIrRPZH/vaEzEDQO0OtpXT1BXuEHx65hG7fkqJWMMYqUJlpQuaYmFyyrv6 PIx6vgM+FZM6P+Z2P9URHydTNevhizwL//ZjO/FEoYysFADqJ01kASzd44nelPEI8lWi CcmCRRy2yl8F5oTFsyVxMCFZlMopbTYTSAC3c= MIME-Version: 1.0 Received: by 10.231.81.148 with SMTP id x20mr5501802ibk.2.1256233363508; Thu, 22 Oct 2009 10:42:43 -0700 (PDT) Date: Thu, 22 Oct 2009 10:42:43 -0700 Message-ID: <38c19b540910221042y6566f58dn1958d25e20171ad8@mail.gmail.com> From: Greg Shepherd To: iesg-secretary@iesg.org, Magnus Westerlund , Eggert Lars , fecframe@ietf.org Content-Type: multipart/mixed; boundary=000e0cd56c32630f7d0476899f5f Subject: [Fecframe] Request for Publication: draft-ietf-fecframe-interleaved-fec-scheme-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 17:42:37 -0000 --000e0cd56c32630f7d0476899f5f Content-Type: text/plain; charset=ISO-8859-1 *, draft-ietf-fecframe-interleaved-fec-scheme-05 is ready for publication. The document shepherd write-up is included here. Thanks, Greg --- Document Shepherd Wriite-up for draft-ietf-fecframe-interleaved-fec-scheme-05 1.a) The Document Shepherd is Greg Shepherd 1.b) The document has had adequate review both from within and from outside the FECFrame working group. 1.c) There are no concerns regarding the need for additional expanded review. 1.d) There are no specific concerns with this document 1.e) There is solid WG consensus for this document. 1.f) There is no discontent. 1.g) The idnits are minor and I don't feel warrant a rev of the document and the associated process. I believe we should handle the edits as publication notes. The relevant nit output being: ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) The normative reference to RFC 3555 should be updated to RFC 4855, RFC 4856 as suggested. There is a reference to draft-ietf-fecframe-dvb-al-fec-01 though the latest rev of that draft is 03. This will be updated before publication with the correct RFC number. The other nit issues regarding informational references to RFC 2733 and RFC 3009 can be ignored as these obsolete references are intentional. 1.h) All references are split between normative and informative. There is one informative reference to a draft in the FECFrame WG that is also in the process of progressing to last-call: draft-ietf-fecframe-dvb-al-fec 1.i) The IANA consideration section exists and is consistent with the body of the document. The required IANA registries are clearly defined in the document. 1.j) The xml code validates correctly 1.k) Technical Summary This document defines a new RTP payload format for the Forward Error Correction 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 new payload format defined in this document is used (with some exceptions) as part of the DVB Application-layer FEC specification. Working Group Summary There were no seriously contentious issues during the WG process. The only controversy stemmed from some individuals who did the work in SMPTE and didn't want the IETF redefining their work. But the problem is that RFC 2733 did not protect some fields in the header and SMPTE was based on RFC 2733. SMTPE spec also made mistakes with SSRC, CSRC and timestamps which are corrected in this document. Additionally, RTP validity checks fail in RPF 2733/SMTPE specs. Document Quality Current implementations follow SMTPE and not yet this specification. Personal Document Shepherd - Greg Shepherd Responsible Area Director - TBD --000e0cd56c32630f7d0476899f5f Content-Type: text/plain; charset=US-ASCII; name="Interleave_Write-up.txt" Content-Disposition: attachment; filename="Interleave_Write-up.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g13swk6c0 RG9jdW1lbnQgU2hlcGhlcmQgV3JpaXRlLXVwIGZvciBkcmFmdC1pZXRmLWZlY2ZyYW1lLWludGVy bGVhdmVkLWZlYy1zY2hlbWUtMDUNDTEuYSkgVGhlIERvY3VtZW50IFNoZXBoZXJkIGlzIEdyZWcg U2hlcGhlcmQNDTEuYikgVGhlIGRvY3VtZW50IGhhcyBoYWQgYWRlcXVhdGUgcmV2aWV3IGJvdGgg ZnJvbSB3aXRoaW4gYW5kIGZyb20gb3V0c2lkZSB0aGUgRkVDRnJhbWUgd29ya2luZyBncm91cC4N DTEuYykgVGhlcmUgYXJlIG5vIGNvbmNlcm5zIHJlZ2FyZGluZyB0aGUgbmVlZCBmb3IgYWRkaXRp b25hbCBleHBhbmRlZCByZXZpZXcuDQ0xLmQpIFRoZXJlIGFyZSBubyBzcGVjaWZpYyBjb25jZXJu cyB3aXRoIHRoaXMgZG9jdW1lbnQNDTEuZSkgVGhlcmUgaXMgc29saWQgV0cgY29uc2Vuc3VzIGZv ciB0aGlzIGRvY3VtZW50Lg0NMS5mKSBUaGVyZSBpcyBubyBkaXNjb250ZW50Lg0NMS5nKSBUaGUg aWRuaXRzIGFyZSBtaW5vciBhbmQgSSBkb24ndCBmZWVsIHdhcnJhbnQgYSByZXYgb2YgdGhlIGRv Y3VtZW50IGFuZCB0aGUgYXNzb2NpYXRlZCBwcm9jZXNzLiBJIGJlbGlldmUgd2Ugc2hvdWxkIGhh bmRsZSB0aGUgZWRpdHMgYXMgcHVibGljYXRpb24gbm90ZXMuIFRoZSByZWxldmFudCBuaXQgb3V0 cHV0IGJlaW5nOg0NKiogT2Jzb2xldGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDM1NTUgKE9i c29sZXRlZCBieSBSRkMgNDg1NSwgUkZDIDQ4NTYpDQ0gVGhlIG5vcm1hdGl2ZSByZWZlcmVuY2Ug dG8gUkZDIDM1NTUgc2hvdWxkIGJlIHVwZGF0ZWQgdG8gUkZDIDQ4NTUsIFJGQyA0ODU2IGFzIHN1 Z2dlc3RlZC4gDQ1UaGVyZSBpcyBhIHJlZmVyZW5jZSB0byBkcmFmdC1pZXRmLWZlY2ZyYW1lLWR2 Yi1hbC1mZWMtMDEgdGhvdWdoIHRoZSBsYXRlc3QgcmV2IG9mIHRoYXQgZHJhZnQgaXMgMDMuIFRo aXMgd2lsbCBiZSB1cGRhdGVkIGJlZm9yZSBwdWJsaWNhdGlvbiB3aXRoIHRoZSBjb3JyZWN0IFJG QyBudW1iZXIuDQ1UaGUgb3RoZXIgbml0IGlzc3VlcyByZWdhcmRpbmcgaW5mb3JtYXRpb25hbCBy ZWZlcmVuY2VzIHRvIFJGQyAyNzMzIGFuZCBSRkMgMzAwOSBjYW4gYmUgaWdub3JlZCBhcyB0aGVz ZSBvYnNvbGV0ZSByZWZlcmVuY2VzIGFyZSBpbnRlbnRpb25hbC4NDQ0xLmgpIEFsbCByZWZlcmVu Y2VzIGFyZSBzcGxpdCBiZXR3ZWVuIG5vcm1hdGl2ZSBhbmQgaW5mb3JtYXRpdmUuIFRoZXJlIGlz IG9uZSBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gYSBkcmFmdCBpbiB0aGUgRkVDRnJhbWUgV0cg dGhhdCBpcyBhbHNvIGluIHRoZSBwcm9jZXNzIG9mIHByb2dyZXNzaW5nIHRvIGxhc3QtY2FsbDoN ZHJhZnQtaWV0Zi1mZWNmcmFtZS1kdmItYWwtZmVjDQ0xLmkpIFRoZSBJQU5BIGNvbnNpZGVyYXRp b24gc2VjdGlvbiBleGlzdHMgYW5kIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgYm9keSBvZiB0aGUg ZG9jdW1lbnQuIFRoZSByZXF1aXJlZCBJQU5BIHJlZ2lzdHJpZXMgYXJlIGNsZWFybHkgZGVmaW5l ZCBpbiB0aGUgZG9jdW1lbnQuDQ0xLmopIFRoZSB4bWwgY29kZSB2YWxpZGF0ZXMgY29ycmVjdGx5 DQ0xLmspDQ1UZWNobmljYWwgU3VtbWFyeQ0JVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IFJU UCBwYXlsb2FkIGZvcm1hdCBmb3IgdGhlIEZvcndhcmQgRXJyb3IgQ29ycmVjdGlvbiB0aGF0IGlz IGdlbmVyYXRlZCBieSB0aGUgMS1EIGludGVybGVhdmVkIHBhcml0eSBjb2RlIGZyb20gYSBzb3Vy Y2UgbWVkaWEgZW5jYXBzdWxhdGVkIGluIFJUUC4gVGhlIDEtRCBpbnRlcmxlYXZlZCBwYXJpdHkg Y29kZSBpcyBhIHN5c3RlbWF0aWMgY29kZSwgd2hlcmUgYSBudW1iZXIgb2YgcmVwYWlyIHN5bWJv bHMgYXJlIGdlbmVyYXRlZCBmcm9tIGEgc2V0IG9mIHNvdXJjZSBzeW1ib2xzIGFuZCBzZW50IGlu IGEgcmVwYWlyIGZsb3cgc2VwYXJhdGUgZnJvbSB0aGUgc291cmNlIGZsb3cgdGhhdCBjYXJyaWVz IHRoZSBzb3VyY2Ugc3ltYm9scy4gVGhlIG5ldyBwYXlsb2FkIGZvcm1hdCBkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnQgaXMgdXNlZCAod2l0aCBzb21lIGV4Y2VwdGlvbnMpIGFzIHBhcnQgb2YgdGhl IERWQiBBcHBsaWNhdGlvbi1sYXllciBGRUMgc3BlY2lmaWNhdGlvbi4NDVdvcmtpbmcgR3JvdXAg U3VtbWFyeQ0JVGhlcmUgd2VyZSBubyBzZXJpb3VzbHkgY29udGVudGlvdXMgaXNzdWVzIGR1cmlu ZyB0aGUgV0cgcHJvY2Vzcy4gVGhlIG9ubHkgY29udHJvdmVyc3kgc3RlbW1lZCBmcm9tIHNvbWUg aW5kaXZpZHVhbHMgd2hvIGRpZCB0aGUgd29yayBpbiBTTVBURSBhbmQgZGlkbid0IHdhbnQgdGhl IElFVEYgcmVkZWZpbmluZyB0aGVpciB3b3JrLiBCdXQgdGhlIHByb2JsZW0gaXMgdGhhdCBSRkMg MjczMyBkaWQgbm90IHByb3RlY3Qgc29tZSBmaWVsZHMgaW4gdGhlIGhlYWRlciBhbmQgU01QVEUg d2FzIGJhc2VkIG9uIFJGQyAyNzMzLiBTTVRQRSBzcGVjIGFsc28gbWFkZSBtaXN0YWtlcyB3aXRo IFNTUkMsIENTUkMgYW5kIHRpbWVzdGFtcHMgd2hpY2ggYXJlIGNvcnJlY3RlZCBpbiB0aGlzIGRv Y3VtZW50LiBBZGRpdGlvbmFsbHksIFJUUCB2YWxpZGl0eSBjaGVja3MgZmFpbCBpbiBSUEYgMjcz My9TTVRQRSBzcGVjcy4NDURvY3VtZW50IFF1YWxpdHkNCUN1cnJlbnQgaW1wbGVtZW50YXRpb25z IGZvbGxvdyBTTVRQRSBhbmQgbm90IHlldCB0aGlzIHNwZWNpZmljYXRpb24uDQ1QZXJzb25hbA0J RG9jdW1lbnQgU2hlcGhlcmQgLSBHcmVnIFNoZXBoZXJkDQlSZXNwb25zaWJsZSBBcmVhIERpcmVj dG9yIC0gVEJEDQ0= --000e0cd56c32630f7d0476899f5f-- From root@core3.amsl.com Fri Oct 23 13:30: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 CE8F13A68E4; Fri, 23 Oct 2009 13:30: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: <20091023203001.CE8F13A68E4@core3.amsl.com> Date: Fri, 23 Oct 2009 13:30:01 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-02.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : RTP Payload Format for Raptor FEC Author(s) : M. Watson Filename : draft-ietf-fecframe-rtp-raptor-02.txt Pages : 20 Date : 2009-10-23 This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-rtp-raptor-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23132009.I-D@ietf.org> --NextPart-- From gjshep@gmail.com Tue Oct 27 06:43:45 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 CFBAC3A688A for ; Tue, 27 Oct 2009 06:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.580, 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 APb9ib1Rn-Ya for ; Tue, 27 Oct 2009 06:43:45 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 151B53A67DF for ; Tue, 27 Oct 2009 06:43:45 -0700 (PDT) Received: by iwn16 with SMTP id 16so98616iwn.29 for ; Tue, 27 Oct 2009 06:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=BnptcrL/6fvzYVoM8eNa26uUFXT9ps0QykFLAeAZufc=; b=rPKyBnGSE1L/KSStZgFwVc84hpVnKvabLRcD2YUCbZ9TXjjXaqAXut/uZ43V3kArPi uCBgRIJUQMl3CcH3B6u3qaDrHpJwOgGtsEVI0L1On/rQ0xpx51hV/QXhHhtKn9Rmij2F UX7v+Z0BhJ1JaGGNJxoUHtSL5EKkaNRac7P40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=oUSC2vF5U34oNP2ycW8Phnp2xlm+zHI/l0KhPfsjp1Vgjl1Ui9OkuwV3gbBLxi6y0Y fehATBKRuztu69lePhlJkpXKVTpG/Exrmp2qqEdCYro6owsGI90OlNPewiXHBElYpLH5 27zms2lI0KQR/yWnVSbP+xmtpMAC1dF7NB/WQ= MIME-Version: 1.0 Received: by 10.231.9.33 with SMTP id j33mr2192944ibj.37.1256651035996; Tue, 27 Oct 2009 06:43:55 -0700 (PDT) Date: Tue, 27 Oct 2009 06:43:55 -0700 Message-ID: <38c19b540910270643v50015edqe18e0b9161ab4772@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WG Last call X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 13:43:45 -0000 *, We are getting very close to wrapping up this group! We have three more drafts which I believe are ready for WG last-call. Please read and provide your feedback by the end of this week, Friday Oct 30. http://tools.ietf.org/html/draft-ietf-fecframe-raptor-01 http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-02.txt http://tools.ietf.org/html/draft-ietf-fecframe-framework-05 If there are no serious objections I will provide the write-ups and move this along to publication request. Thank you all and see you in Hiroshima!, Greg From gjshep@gmail.com Tue Oct 27 06:49:19 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0FB28C0F2 for ; Tue, 27 Oct 2009 06:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 bn3mKxUkmQ3G for ; Tue, 27 Oct 2009 06:49:18 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id B156428C0E7 for ; Tue, 27 Oct 2009 06:49:18 -0700 (PDT) Received: by iwn16 with SMTP id 16so103098iwn.29 for ; Tue, 27 Oct 2009 06:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=lLkLnwPwSivTDH3MHqVYFEBZxL7rU2iK9lu/d1hmdzA=; b=waa8NjGJDUMYaODDG1NNOFEqXRgLRd3jFnLQf39TH+huER7hazbQBjYmtgouLm7vIG zI5GJkonhmKdsFN1FbhCMe1rP3qHahe99xEZE7ShCKHZyY6gCuw0DWoEGihhET6CsXZi xUmG1REGMQDeuVUTvKKS5Z9xtako/LCYg31zY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=IxlTdGYpVnKqznjqWIMfSZh67qkFa+M/6ASqI/DbbhkrCPt9BN1wBxpMUHVARzA3jj xhJjNg1qvSMLwpb7GMPLrgKHmgkYLTuz84XnvjCqhAa9WbEwRo2K9yu4r+GO2DkNKQE4 IatJ/csdcqYZTmbKkfDyU7TS3Ex8lkI5rY41g= MIME-Version: 1.0 Received: by 10.231.83.75 with SMTP id e11mr262734ibl.11.1256651368930; Tue, 27 Oct 2009 06:49:28 -0700 (PDT) Date: Tue, 27 Oct 2009 06:49:28 -0700 Message-ID: <38c19b540910270649t7ed176betdbdd9b6eb13e9592@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WG Agenda, Hiroshima X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 13:49:19 -0000 *, Getting to the end of our milestones, our WG agenda is quite light: ------------ FECFrame WG Agenda IETF 76, Hiroshima, Japan Introductions, Agenda Bashing 10mins Chairs WG Docs Status 15mins Chairs draft-galanos-fecframe-rtp-reedsolomon-00 15mins Orly Peck ------------- Please let me know today if you have something else to present and how much time you need. Thanks, Greg From abegen@cisco.com Tue Oct 27 21:14: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 E0D483A68C6 for ; Tue, 27 Oct 2009 21:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 5lbozwsNhKXB for ; Tue, 27 Oct 2009 21:14:18 -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 B53323A676A for ; Tue, 27 Oct 2009 21:14:16 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG9h50qrR7Hu/2dsb2JhbADBLZhZhD8E X-IronPort-AV: E=Sophos;i="4.44,637,1249257600"; d="scan'208";a="101142149" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2009 04:14:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9S4EVNT018482; Wed, 28 Oct 2009 04:14:31 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 21:14:31 -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, 27 Oct 2009 21:13:52 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A84308A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <38c19b540910270643v50015edqe18e0b9161ab4772@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WG Last call Thread-Index: AcpXC4t5VuS/QSJNSCaUHMrzUmdqUgAeKmYw References: <38c19b540910270643v50015edqe18e0b9161ab4772@mail.gmail.com> From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 28 Oct 2009 04:14:31.0268 (UTC) FILETIME=[25F6D240:01CA5785] Subject: Re: [Fecframe] WG Last call 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, 28 Oct 2009 04:14:19 -0000 I believe draft-ietf-fecframe-rtp-raptor-02 needs to be reviewed by AVT = as well since it is a payload format draft. I'll do my best to review these drafts but I cannot finish them all by = Friday. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Greg > Shepherd > Sent: Tuesday, October 27, 2009 9:44 AM > To: fecframe@ietf.org > Subject: [Fecframe] WG Last call >=20 > *, >=20 > We are getting very close to wrapping up this group! We have three > more drafts which I believe are ready for WG last-call. Please read > and provide your feedback by the end of this week, Friday Oct 30. >=20 > http://tools.ietf.org/html/draft-ietf-fecframe-raptor-01 > http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-02.txt > http://tools.ietf.org/html/draft-ietf-fecframe-framework-05 >=20 > If there are no serious objections I will provide the write-ups and > move this along to publication request. >=20 > Thank you all and see you in Hiroshima!, > Greg > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Tue Oct 27 22:00: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 DF0563A69DF for ; Tue, 27 Oct 2009 22:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 vboePSytqUUA for ; Tue, 27 Oct 2009 22:00:13 -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 4D05C3A6948 for ; Tue, 27 Oct 2009 22:00:12 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHJs50qrR7H+/2dsb2JhbADBMZhchD8E X-IronPort-AV: E=Sophos;i="4.44,637,1249257600"; d="scan'208";a="419468962" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 28 Oct 2009 05:00:26 +0000 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.14.3) with ESMTP id n9S50RRb014280 for ; Wed, 28 Oct 2009 05:00:27 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 22:00:27 -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: Tue, 27 Oct 2009 21:59:51 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A843093@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review for draft-ietf-fecframe-rtp-raptor-02 Thread-Index: AcpXi3s0CQY7ynlsQyqxaZIfFXdzQQ== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 28 Oct 2009 05:00:27.0295 (UTC) FILETIME=[90AF2AF0:01CA578B] Subject: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 05:00:14 -0000 Here is the list of my comments for this draft. As I mentioned earlier, = this draft should be reviewed by AVT as well. - RFC 3550 needs to be cited in the introduction section and in other = relevant places. - Section 3: "... In this case, in the language of the FEC Framework, = there is no explicit FEC Source Payload Id." --> "... there is no (need = for) explicit ..." - Section 4.1, Market bit: I believe "shall" should be "SHALL" in this = sentence. - Section 4.1: What about the other fields in the RTP header? If there = are no specific usage rules, a note saying that RFC 3550 rules shall = apply should be added. - Section 4.2 and 4.3: This is the part that needs some work. I don't = think we can simply refer to the framework and fecframe-raptor drafts = and leave these parts (which are the most critical sections in a payload = draft) empty. First of all, why is there a reference to the framework = draft? Secondly, this section needs to make it clear that the payload = draft is for the last FEC scheme introduced in the fecframe-raptor draft = (Section 8). In the current draft, it says there is no (FEC) payload header. So, I = guess everything goes into the RTP payload. However, IMO it is better to = introduce the Repair FEC Payload ID (section 8.1.3 of the = fecframe-raptor draft) as the FEC payload header, and then put the = repair symbols as the RTP payload. This makes it a better representation = and easier for others to visualize the encoding/decoding ops. - Are there any requirements for max-sbl and symbol-size parameters? If = yes, they must be stated in every subsection of 6.3. - Search for " definedf" and replace it with " defined". - Section 5: Are not there any special considerations for Raptor FEC? = The CC section in the framework is pretty generic IMO. Some specific = guidelines, if any, would be appropriate to put here. And this section = should be moved to the end. - Section 7: The mapping to the SDP parameters should be explained. = There is a boilerplate for it. Just apply it to your document. - Section 8 and 9: I am pretty sure there are some offer/answer model = and declarative SDP considerations. Again, there is a boilerplate for = it, but it must be modified a little bit to fit to the specifics of this = payload format. - Section 10: Before IANA considerations, I was hoping to have a section = describing the "Protection and Recovery Procedures." The protection part = explains how the repair packets are constructed. This can be kept brief = with proper references to the fecframe-raptor draft, but there should = sufficient text that gives a general idea to the readers. For the = recovery procedures, they should be detailed more since even the other = draft does not explain this AFAICT. - An SDP example showing the RTP format parameters is essential. - Section 11: There is a boilerplate for security considerations section = and all RTP payload format drafts use it. That should be included here. HTH, -acbegen From orlyp@radvision.com Tue Oct 27 23:30:00 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2BD3A68AF for ; Tue, 27 Oct 2009 23:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0RIDEgaXGt+z for ; Tue, 27 Oct 2009 23:29:59 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 49AE93A6887 for ; Tue, 27 Oct 2009 23:29:58 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id n9S6TrpI025664 for fecframe@ietf.org; Wed, 28 Oct 2009 08:29:53 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id n9S6TrE1025658; Wed, 28 Oct 2009 08:29:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Oct 2009 08:29:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WG Agenda, Hiroshima Thread-Index: AcpXDFp++HQn1NlXRvWDkldlq/eq+AAH2Y/gABr/TuA= From: "Orly Peck" To: "gjshep@gmail.com" <'gjshep@gmail.com'> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id n9S6TrE1025658 Cc: fecframe@ietf.org Subject: [Fecframe] FW: WG Agenda, Hiroshima 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, 28 Oct 2009 06:30:00 -0000 Hi Greg, Could you please confirm accepting my mail below? I sent it yesterday, but I am not sure you received it. Thanks, Orly Peck. -----Original Message----- From: Orly Peck Sent: Tuesday, October 27, 2009 7:37 PM To: 'gjshep@gmail.com' Subject: RE: [Fecframe] WG Agenda, Hiroshima Hi Greg, I would also like to present draft-peck-fecframe-rtp-mf-00. Thanks, Orly Peck. -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd Sent: Tuesday, October 27, 2009 3:49 PM To: fecframe@ietf.org Subject: [Fecframe] WG Agenda, Hiroshima *, Getting to the end of our milestones, our WG agenda is quite light: ------------ FECFrame WG Agenda IETF 76, Hiroshima, Japan Introductions, Agenda Bashing 10mins Chairs WG Docs Status 15mins Chairs draft-galanos-fecframe-rtp-reedsolomon-00 15mins Orly Peck ------------- Please let me know today if you have something else to present and how much time you need. Thanks, Greg _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From gjshep@gmail.com Wed Oct 28 07:01:37 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 D383D28C10D for ; Wed, 28 Oct 2009 07:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, 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 Z02JNaZ4dCuc for ; Wed, 28 Oct 2009 07:01:37 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id E873328C0F1 for ; Wed, 28 Oct 2009 07:01:36 -0700 (PDT) Received: by iwn40 with SMTP id 40so646307iwn.32 for ; Wed, 28 Oct 2009 07:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+WJjm8XUCFsMVsOjROUa1ETZJh3UcPmYmIKEWJ9Bi3s=; b=DTHLgJZiloXHOcikUbBjwbXPCHS/yepieitci09zKG6DlWeUeHMOKL+AKOS2fHs0kf pfWM6+lxPrhGzYU6BB4dVc7KCuduDdLyUqCCOa9HqPNOpGodl5NhPfuUEx5PZfFLAOvO tY1Wu1x1AvYctuo5Ch8nUDGOylrFggwPLa29I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=Y1zYUPKzFo8QdDZf9ndZag2lf245det2VhlycWVs2ku2djhOP1Lb7AhPx4JZVBapBd +9C2tPTMx2g+Tv2flS2/yT/P/9S3dndxY2JYNdxhf8o2t5VZAuJrF7mg0WJkKJ/meKA+ GFoz9HiPsdG+N8LlCG1aLmaEDqga2vZofcSsM= MIME-Version: 1.0 Received: by 10.231.4.75 with SMTP id 11mr3498816ibq.25.1256738509588; Wed, 28 Oct 2009 07:01:49 -0700 (PDT) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A6358F9@xmb-sjc-215.amer.cisco.com> References: <00c501ca48d5$3cc3a890$b64af9b0$@com> <04CAD96D4C5A3D48B1919248A8FE0D540A6358F9@xmb-sjc-215.amer.cisco.com> Date: Wed, 28 Oct 2009 07:01:49 -0700 Message-ID: <38c19b540910280701r238e30ddy9fcb9a57652b4a6@mail.gmail.com> From: Greg Shepherd To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Einat Yellin \(Lachover\)" , tme@multicasttech.com, fecframe@ietf.org Subject: Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ?? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:01:38 -0000 I believe we have covered all we can on this discussion. The majority opinion is that adding complexity to the framework for the sake of compatibility with non-framework clients is out of scope for the WGs original objectives. So I don't feel the WG should take on this work. Sorry, Greg On Fri, Oct 9, 2009 at 12:22 PM, Ali C. Begen (abegen) w= rote: >> The focus of our draft is on backward-compatibility issue. Separate flow= is just an >> option. Based on the previous discussion on the draft, now we think defi= ning a generic > > What other option(s) do you propose? > > Using a separate flow requires additional support on the clients already = supporting the framework. Rather than wasting that energy on those modifica= tions, I'd rather prefer making the non-framework clients compatible with t= he framework if they indeed want to benefit from the framework features. > > Ow, I suggest the non-compatible clients to stick with the non-complicate= d FEC scenarios. This whole stuff is not worth the effort IMO. > > -acbegen > >> mapping information format for various ways of building source block in = practice should be >> the most important issue for backward compatibility. We suggest to make = this work >> (defining a generic mapping information format) to be a work item. We ca= n update our draft >> to be the basis of this work. > From gjshep@gmail.com Wed Oct 28 09:30: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 1864F3A6977 for ; Wed, 28 Oct 2009 09:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 jTZOKEB2zfwn for ; Wed, 28 Oct 2009 09:30:23 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id E359B3A6A09 for ; Wed, 28 Oct 2009 09:29:45 -0700 (PDT) Received: by iwn40 with SMTP id 40so779973iwn.32 for ; Wed, 28 Oct 2009 09:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZCPeCt4RWyJwlTPRgdBvhGVH5YmjQL6Xj4P3mz+wpdE=; b=jmLyOKSnzvFI45MhqqOlPqb4dkrH/laYXH3jaWHT8sFfW7e3qfrx8oQ7g+S5n3/vfX Fy/JGgofj9l2WuBXvfQ5Yye/mVTUwSHqGalNaVgv2ygaNBN2tzGMwQagAhutm8EZtklv G04w/UaZkoGo6Cm9I/dPS0AJLCTWXVv/2Ika4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=bnz/kwPj7ajVqRTT1Yepc0PGym29byj2JMVRJHOz6s8ixOFJ7Zq4rbrsTMCP1f0ai+ njJYetfd+bsFB3eUxDUXE5YFCoGMHwe85L4XRAxAwNe8YifCLYI6hhGrE0jiyjZ6qDjM GwTh78NrTVYSci/cK6xRUlEp1mTcKyfn5ml3U= MIME-Version: 1.0 Received: by 10.231.9.33 with SMTP id j33mr7172274ibj.37.1256747398480; Wed, 28 Oct 2009 09:29:58 -0700 (PDT) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A84308A@xmb-sjc-215.amer.cisco.com> References: <38c19b540910270643v50015edqe18e0b9161ab4772@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540A84308A@xmb-sjc-215.amer.cisco.com> Date: Wed, 28 Oct 2009 09:29:58 -0700 Message-ID: <38c19b540910280929s578e2906he29ad39b96edf7a0@mail.gmail.com> From: Greg Shepherd To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 Cc: fecframe@ietf.org Subject: Re: [Fecframe] WG Last call X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:30:24 -0000 I'll extend the time, thanks. On Tue, Oct 27, 2009 at 9:13 PM, Ali C. Begen (abegen) wrote: > I believe draft-ietf-fecframe-rtp-raptor-02 needs to be reviewed by AVT as well since it is a payload format draft. > > I'll do my best to review these drafts but I cannot finish them all by Friday. > > -acbegen > >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg >> Shepherd >> Sent: Tuesday, October 27, 2009 9:44 AM >> To: fecframe@ietf.org >> Subject: [Fecframe] WG Last call >> >> *, >> >> We are getting very close to wrapping up this group! We have three >> more drafts which I believe are ready for WG last-call. Please read >> and provide your feedback by the end of this week, Friday Oct 30. >> >> http://tools.ietf.org/html/draft-ietf-fecframe-raptor-01 >> http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-02.txt >> http://tools.ietf.org/html/draft-ietf-fecframe-framework-05 >> >> If there are no serious objections I will provide the write-ups and >> move this along to publication request. >> >> Thank you all and see you in Hiroshima!, >> Greg >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > From csp@csperkins.org Thu Oct 29 11:25:47 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 E44D73A683C for ; Thu, 29 Oct 2009 11:25:47 -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 Hbmjo-n4SC3C for ; Thu, 29 Oct 2009 11:25:46 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by core3.amsl.com (Postfix) with ESMTP id 5979E3A67A8 for ; Thu, 29 Oct 2009 11:25:46 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1N3ZhC-0001Zy-nD for fecframe@ietf.org; Thu, 29 Oct 2009 18:26:02 +0000 Message-Id: From: Colin Perkins To: fecframe@ietf.org In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A843093@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 18:26:02 +0000 References: <04CAD96D4C5A3D48B1919248A8FE0D540A843093@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.936) Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:25:48 -0000 Hi, I have some comments, in addition to those made by Ali. This looks like a decent initial draft, but does not appear to be ready for working group last call. Section 4.1: what timestamp rate is used? Section 4.3 is empty? This seems to be missing the important content that describes how the payload format works. Section 6.x: - The change controller is listed as the AVT working group, but AVT has never seen this draft. This draft should be presented in AVT and the WG last call should be copied to the AVT list. - The "rate" is a required parameter for RTP payload formats, but isn't listed here. The offer/answer considerations in Section 8 cannot be "None." if this is to be used with SDP offer/answer, such as with SIP. This section needs to specify how the parameters are to be negotiated. Section 9: again, this cannot be "None", and needs to specify how the media parameters are to be used with declarative SDP. Section 11 (Security Considerations) is insufficient. At minimum, the security considerations from the Raptor FECFRAME draft, RFC 3550 and any applicable RTP profiles apply. See also draft-ietf-avt-rtp-howto-06 Colin On 28 Oct 2009, at 04:59, Ali C. Begen (abegen) wrote: > Here is the list of my comments for this draft. As I mentioned > earlier, this draft should be reviewed by AVT as well. > > - RFC 3550 needs to be cited in the introduction section and in > other relevant places. > > - Section 3: "... In this case, in the language of the FEC > Framework, there is no explicit FEC Source Payload Id." --> "... > there is no (need for) explicit ..." > > - Section 4.1, Market bit: I believe "shall" should be "SHALL" in > this sentence. > > - Section 4.1: What about the other fields in the RTP header? If > there are no specific usage rules, a note saying that RFC 3550 rules > shall apply should be added. > > - Section 4.2 and 4.3: This is the part that needs some work. I > don't think we can simply refer to the framework and fecframe-raptor > drafts and leave these parts (which are the most critical sections > in a payload draft) empty. First of all, why is there a reference to > the framework draft? Secondly, this section needs to make it clear > that the payload draft is for the last FEC scheme introduced in the > fecframe-raptor draft (Section 8). > > In the current draft, it says there is no (FEC) payload header. So, > I guess everything goes into the RTP payload. However, IMO it is > better to introduce the Repair FEC Payload ID (section 8.1.3 of the > fecframe-raptor draft) as the FEC payload header, and then put the > repair symbols as the RTP payload. This makes it a better > representation and easier for others to visualize the encoding/ > decoding ops. > > - Are there any requirements for max-sbl and symbol-size parameters? > If yes, they must be stated in every subsection of 6.3. > > - Search for " definedf" and replace it with " defined". > > - Section 5: Are not there any special considerations for Raptor > FEC? The CC section in the framework is pretty generic IMO. Some > specific guidelines, if any, would be appropriate to put here. And > this section should be moved to the end. > > - Section 7: The mapping to the SDP parameters should be explained. > There is a boilerplate for it. Just apply it to your document. > > - Section 8 and 9: I am pretty sure there are some offer/answer > model and declarative SDP considerations. Again, there is a > boilerplate for it, but it must be modified a little bit to fit to > the specifics of this payload format. > > - Section 10: Before IANA considerations, I was hoping to have a > section describing the "Protection and Recovery Procedures." The > protection part explains how the repair packets are constructed. > This can be kept brief with proper references to the fecframe-raptor > draft, but there should sufficient text that gives a general idea to > the readers. For the recovery procedures, they should be detailed > more since even the other draft does not explain this AFAICT. > > - An SDP example showing the RTP format parameters is essential. > > - Section 11: There is a boilerplate for security considerations > section and all RTP payload format drafts use it. That should be > included here. > > HTH, > -acbegen -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Thu Oct 29 12:06:23 2009 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597BD3A6A16 for ; Thu, 29 Oct 2009 12:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4gq7ag8YDkZ for ; Thu, 29 Oct 2009 12:06:22 -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 609273A68D5 for ; Thu, 29 Oct 2009 12:06:22 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACuF6UqrR7Hu/2dsb2JhbADHVJgehD0E X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="420687226" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 19:06:38 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9TJ6cjP016768 for ; Thu, 29 Oct 2009 19:06:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 12:06:35 -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: Thu, 29 Oct 2009 12:05:45 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A84366F@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review for draft-ietf-fecframe-raptor-01 Thread-Index: AcpYytE8kvmuKdUwTmCg6CvJecOy4g== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 29 Oct 2009 19:06:35.0988 (UTC) FILETIME=[EF98B140:01CA58CA] Subject: [Fecframe] Review for draft-ietf-fecframe-raptor-01 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 19:06:23 -0000 - Abstract says " An RTP Payload Type is defined for this latter case. " = I'd suggest to remove this sentence as this draft does not provide the = payload format. - Also in the abstract and introduction, it says two FEC schemes are = defined. In the Raptor RTP draft, it said three. You might wanna fix it = for consistency. - Introduction: Per the FEC Framework requirements, the sender MUST transmit the source and repair packets in different source and repair flows, respectively. In case of RTP transport, source and repair data can be in different RTP = streams, where they are SSRC multiplexed in the same RTP session. From = outside, they look like a single UDP flow. The sentence above = contradicts with this. I suggest to change it as follows: Per the FEC Framework requirements, the sender MUST transmit the source and repair packets in different source and repair streams, respectively. Accordingly, the definitions (source and repair flow) will need to be = changed as well in section 4. - I admit that I did not check all the definitions/formulas in sections = 6-8 in detail.=20 - Section 8.2.4. What about the length of the RTP header extensions? - Section 9: No specific security considerations? - Section 10: I suggest to reference 4756bis instead of 4756 and update = the semantics accordingly. Also "a=3Drepair-window: 200" should be = "a=3Drepair-window:200" (remove the space).=20 - As agreed in the last meeting, the current SDP elements draft says:=20 The variable-length SS-FSSI and FSSI containers transmit the information in textual representation and MAY contain multiple distinct elements. For the fully-specified FEC schemes, a full description of these elements for both containers MUST be provided. This will require some changes in the SDP example. The draft also needs = to explain the elements that will be used in this textual = representation. HTH, -acbegen From vincent.roca@inrialpes.fr Fri Oct 30 07:50: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 96BC93A6883 for ; Fri, 30 Oct 2009 07:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjT45UJ4Et6N for ; Fri, 30 Oct 2009 07:50:45 -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 025343A67AB for ; Fri, 30 Oct 2009 07:50:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,653,1249250400"; d="scan'208";a="49524376" 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; 30 Oct 2009 15:51:00 +0100 Message-ID: <4AEAFD53.2050607@inrialpes.fr> Date: Fri, 30 Oct 2009 15:50:59 +0100 From: Vincent Roca User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "fecframe@ietf.org" X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Fecframe] review of draft-ietf-fecframe-framework-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: Fri, 30 Oct 2009 14:50:46 -0000 Hello Mark, I have some comments WRT the fecframe framework 05 document. However I didn't have time to read the I-D thoroughly (too short time). Here is the first part, the rest next week hopefully. Cheers, Vincent ---- * Abstract, typo: "This document describes for a framework" -> remove "for" ** Concerning Section 2 "Definitions/Abbreviations" - 'Transport protocol' is defined as the protocol used for transport of the source data flow. This is misleading since it is also used to transport the *repair* data flow. - 'Application Data Unit' is defined WRT the transport layer. IMHO, the ADU should be defined WRT to the application. For instance in draft-roca-fecframe-rs-01.txt, we use the following definition: Application Data Unit (ADU): a unit of data coming from (sender) or given to (receiver) the media delivery application. Depending on the use-case, an ADU can use an RTP encapsulation. I also suggest you add a sentence like: "The Source data flow consist of ADUs" (either here or in the definition of 'Source data flow'). - 'FEC Code' mentions it can be used to be resilient to *corruptions*. I understand that this definition is for the general case. However it has been clearly stated in Introduction that we are only considering the case of erasures. This definition is therefore misleading. - 'Source Block' is defined as "the group of source data packets which are to be FEC protected as a single block". I have several comments here: 1- Nowhere the notion of "source data packets" has been defined. I suggest ADU instead to highlight the fact it comes from the application. 2- This is in any case wrong since several FEC schemes also include additional pieces of information (ADUI + padding) that are not part of the source data flow, during encoding. In fact, the "source block" is defined WRT the FEC Code (rather than the Scheme). The scheme considers an ADU block, which is then used by the FEC Scheme to define one (sometimes several) Source blocks. So I'd rather define the notion of ADU block here. - FEC Payload ID and the Source|Repair definitions: These three definitions refer to packet|source packet|repair packet. The notion of packet is misleading (overloaded) and has not been defined previously in any case. In draft-roca-fecframe-rs-01.txt we define: FEC Source Packet: a data packet submitted to (sender) or received from (receiver) the Transport protocol. It contains an ADU along with its optional Source FEC Payload ID, if any. FEC Repair Packet: a repair packet submitted to (sender) or received from (receiver) the Transport protocol. It contains a repair symbol along with its Repair FEC Payload ID. - I think you should add a few definitions directly coming from [RFC5052] for clarity (even if the reader of this I-D is supposed to have read RFC 5052 before). The definition of a 'Source block' should appear here. There's an example in draft-roca-fecframe-rs-01.txt (sorry, the same reference once again ;-)) ** Section 4: - it is said: "the FEC Framework passes groups of transport packet payloads to the FEC Scheme for FEC Encoding." What does "transport packet payloads" mean? I suggest instead 'ADUs'. Moreover: Encoding -> encoding. - I don't like sentence: "The FEC Scheme returns FEC repair packet payloads, encoded FEC Payload ID information for each of the repair packets and, in some cases, encoded FEC Payload ID information for each of the source packets." I find the wording strange. Additionally use repair rather than encoded in "encoded FEC Payload ID". I'd say simply: The FEC Scheme returns FEC repair packets (that include the associated Repair FEC Payload ID) and FEC source packets (that sometimes include the Source FEC Payload ID, depending on the FEC Scheme). - p.11 and fig 1: The notion of "transport flow" has not been defined. Use "Source data flow" or (better IMHO) "ADU flow" instead. And there are many other instances of "transport flow(s)" in the document... - p.11: It is said: "From the FEC Framework point of view, RTP source flows are sequences of UDP packet payloads like any other protocol over UDP." It might be another protocol than UDP, right? I know RTP/DCCP has been discussed at IETF in the past. I don't know the status. - p.11, typo: "the the repair payload" -> "the repair payload" - Fig 1: I suggest you (1) add "example" in the figure caption to highlight the fact RTP is not a mandatory part of the architecture and (2) add the "optional" keyword in the top RTP box. Change "Transport flows" by either Source data flow(s) or ADU flow(s). ** Section 7. - typos: "recieved", "inaccuate". - It is said: New applications which require such feedback SHOULD use RTP/RTCP [RFC3550]. Isn't "SHOULD" a little bit too strong here? I agree it's a convenient, on the shelf, solution, but that's not a sufficient reason I think. * To finish: the FECFRAME group should probably be thanked too in section 12 ;-)