From jean-marc.valin@octasic.com Wed Oct 7 10:14:15 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8029D3A67FC for ; Wed, 7 Oct 2009 10:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_20=-0.74] 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 juVcaK2fbiEp for ; Wed, 7 Oct 2009 10:14:14 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 8F9CB3A69DB for ; Wed, 7 Oct 2009 10:13:52 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 13:15:32 -0400 Message-ID: <4ACCCCB3.8080100@octasic.com> Date: Wed, 07 Oct 2009 13:15:31 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2009 17:15:32.0197 (UTC) FILETIME=[C6946150:01CA4771] Subject: [codec] Updated codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:14:15 -0000 Hi everyone, We just updated the guidelines and requirements drafts to take into account the feedback received so far. The updated drafts are at: http://tools.ietf.org/html/draft-valin-codec-guidelines-01 http://tools.ietf.org/html/draft-valin-codec-requirements-01 Please sent comments on these drafts to the codec at ietf.org list and let us know if we missed anything. Let's try to get these drafts as complete as possible before the BoF. Cheers, Jean-Marc From alexander.chemeris@gmail.com Wed Oct 7 11:29:34 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB233A6839 for ; Wed, 7 Oct 2009 11:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ffK7DlxirlIJ for ; Wed, 7 Oct 2009 11:29:33 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 7E68F3A6804 for ; Wed, 7 Oct 2009 11:29:33 -0700 (PDT) Received: by fxm28 with SMTP id 28so4626612fxm.42 for ; Wed, 07 Oct 2009 11:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=0tyevENR2ho5FjpH2NcvyBIbM/fmk6DBmpyiezjVQVQ=; b=ApXA+tHZfR5s5goLKOLvKXeDU5L2R+uU9k7Rjf/G2D7RwTpU5CULHZjj/bSZusPFJu o6yOgCsCBQC9538fz5aY79aAots+ZXmgq0bfE9y5GBVOVr0l786wEXE0Z1qSDanuP+eS KfumJvDqoBtRqSiUJtzrH+zjdsz0Gthcez7RI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=R1yT1ScbkY70GDxzoMwV+JCgo2JbuUgtxIvAm5hGF5qDBX0Z9SDS57rgAt3W+j9s9r iT/U4lZ+Z6iJ2x1GfVuelviyRy3froV27TeSZI76Fys7VDkG/zzLuay8CulWUEhL/mtJ 5QSadb25e8IKa/RKvVIWZoFKijHml9qtQS1+k= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.102.248.11 with SMTP id v11mr90035muh.91.1254940272064; Wed, 07 Oct 2009 11:31:12 -0700 (PDT) In-Reply-To: <4ACCCCB3.8080100@octasic.com> References: <4ACCCCB3.8080100@octasic.com> From: Alexander Chemeris Date: Wed, 7 Oct 2009 22:30:52 +0400 X-Google-Sender-Auth: 279463351fdb135f Message-ID: <3d032e5d0910071130w470d46d1n6b80a87013090be4@mail.gmail.com> To: Jean-Marc Valin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] Updated codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 18:29:34 -0000 Hi Jean-Marc, Is there any IETF web-based tool for seeing differences between draft versions? On Wed, Oct 7, 2009 at 21:15, Jean-Marc Valin wrote: > Hi everyone, > > We just updated the guidelines and requirements drafts to take into accou= nt > the feedback received so far. The updated drafts are at: > > http://tools.ietf.org/html/draft-valin-codec-guidelines-01 > http://tools.ietf.org/html/draft-valin-codec-requirements-01 > > Please sent comments on these drafts to the codec at ietf.org list and le= t > us know if we missed anything. Let's try to get these drafts as complete = as > possible before the BoF. > > Cheers, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From stpeter@stpeter.im Wed Oct 7 11:36:11 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989D23A69AF for ; Wed, 7 Oct 2009 11:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 C5MtjTZ5JI67 for ; Wed, 7 Oct 2009 11:36:10 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A88903A6976 for ; Wed, 7 Oct 2009 11:36:10 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9FB8240D37; Wed, 7 Oct 2009 12:37:50 -0600 (MDT) Message-ID: <4ACCDFFD.1030904@stpeter.im> Date: Wed, 07 Oct 2009 12:37:49 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexander Chemeris References: <4ACCCCB3.8080100@octasic.com> <3d032e5d0910071130w470d46d1n6b80a87013090be4@mail.gmail.com> In-Reply-To: <3d032e5d0910071130w470d46d1n6b80a87013090be4@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] Updated codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 18:36:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/7/09 12:30 PM, Alexander Chemeris wrote: > Is there any IETF web-based tool for seeing differences between draft > versions? You can click the "Diff" links at the top of those pages. So for instance: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-valin-codec-guidelines-01.txt http://tools.ietf.org/rfcdiff?url2=draft-valin-codec-guidelines-01.txt http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-valin-codec-requirements-01.txt http://tools.ietf.org/rfcdiff?url2=draft-valin-codec-requirements-01.txt /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrM3/0ACgkQNL8k5A2w/vyR1gCgnqtv3uHkHIqijYpNo26i/KLb Fd4AoMBc+JUWg7yJQ0vNasBuiCQhEQ61 =YWhv -----END PGP SIGNATURE----- From alexander.chemeris@gmail.com Wed Oct 7 12:20:48 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C633A6A04 for ; Wed, 7 Oct 2009 12:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 MdlIIcJpjdpA for ; Wed, 7 Oct 2009 12:20:47 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 3457A3A69FD for ; Wed, 7 Oct 2009 12:20:46 -0700 (PDT) Received: by bwz6 with SMTP id 6so229444bwz.37 for ; Wed, 07 Oct 2009 12:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=CCKXZ37hBdx6TGX+TjnvxIf6m4LLQSmg+qQLvbWPS4k=; b=poKU0aRINnv4L2nCEivT6QkgIyTNcBQVkH2R3hzdmaoJidBD/PQlVoMyFa1HyidftN olboq+uP7t1QEc2Qgif7XPG2I6Xx3Rra1o6Qo1nsktBeCNRO6sp/qbF6NrssC8eUDk7R FlHQNtg6JtCzkCJrpc4ybcJdfMVShLHG8FU0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=gs9SGbZS/3pMl9w/qoKnJ/MpBbOI0KOQ2mH/M/g7Xr+oJEREmCZrwUSFFvKC8zPyVn YjWb52DlNUjCbyNRSvb2h4YINPAG78QdEDG6GLMYGPylRHRj5HYKJaBFHPGJQhdNh3po Bk1UGh8IvCKcqIJlr15bqSxjxguNyAHCYILTg= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.122.5 with SMTP id z5mr129589mum.11.1254943343119; Wed, 07 Oct 2009 12:22:23 -0700 (PDT) In-Reply-To: <4ACCDFFD.1030904@stpeter.im> References: <4ACCCCB3.8080100@octasic.com> <3d032e5d0910071130w470d46d1n6b80a87013090be4@mail.gmail.com> <4ACCDFFD.1030904@stpeter.im> From: Alexander Chemeris Date: Wed, 7 Oct 2009 23:22:03 +0400 X-Google-Sender-Auth: 418b7346bc718e56 Message-ID: <3d032e5d0910071222yc718eaeye2574e301894f9ae@mail.gmail.com> To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: "codec@ietf.org" Subject: Re: [codec] Updated codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 19:20:48 -0000 Thanks! On Wed, Oct 7, 2009 at 22:37, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/7/09 12:30 PM, Alexander Chemeris wrote: > >> Is there any IETF web-based tool for seeing differences between draft >> versions? > > You can click the "Diff" links at the top of those pages. So for instance: > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-valin-codec-guidelines-01.txt > http://tools.ietf.org/rfcdiff?url2=draft-valin-codec-guidelines-01.txt > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-valin-codec-requirements-01.txt > http://tools.ietf.org/rfcdiff?url2=draft-valin-codec-requirements-01.txt > > /psa > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrM3/0ACgkQNL8k5A2w/vyR1gCgnqtv3uHkHIqijYpNo26i/KLb > Fd4AoMBc+JUWg7yJQ0vNasBuiCQhEQ61 > =YWhv > -----END PGP SIGNATURE----- > -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From stpeter@stpeter.im Wed Oct 7 13:58:21 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFA528C0F4 for ; Wed, 7 Oct 2009 13:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=-0.139, 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 H7Sb+ru1Qbpn for ; Wed, 7 Oct 2009 13:58:19 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 694CA3A68D3 for ; Wed, 7 Oct 2009 13:58:19 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9103440D37; Wed, 7 Oct 2009 14:59:59 -0600 (MDT) Message-ID: <4ACD014E.3010502@stpeter.im> Date: Wed, 07 Oct 2009 14:59:58 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 20:58:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My apologies for the delayed reply. On 9/4/09 7:41 PM, Stephan Wenger wrote: > Folks, > I read through this draft and found it, all in all, a well written document > covering a lot of (to me) agreeable aspects. Thanks. We have tried to incorporate most of your feedback into the document. > However, as you may expect, I > have a number of comments, mostly on certain language aspects :-) If this > were a working group effort, I would phrase some of my suggestion below in > stronger terms. As things stand, you are, of course, free to ignore them... > Regards, > Stephan > > > 1. Section 1 speaks in several places of "freely available". I would > recommend to be more precise. There are just too many definitions, some of > which contradicting, of what constitutes "freedom" in our business. For consistency, we have changed all instances of "free" or "freely available" (etc.) to "easily distributable" throughout the text. > 2. Section 1: the above remark also goes for the definition of "open". A > very large part of the standardization people (perhaps a majority) > associates "open" exclusively with "open process in the SDO" and not with > what the draft implicitly assumes ("open" use, whatever that, in turn, may > be). We clarified the wording about this a bit. > 3. Section 1, first bullet, "has inhibited": really? I don't believe this > claim is true---certainly not in the form as made. At least, I have not > seen a prove for this rather assertive statement. Suggest softening the > language. I disagree. Certainly we received quite a bit of feedback before IETF 75 and at the Stockholm meeting about this topic, so I don't think it's appropriate to remove it. > 4. Section 1, final bullet: suggest replacing "will be freely available" > with "may be available without royalties or other undue burden", as none of > us has the means to guaranty something like "freely available". In fact, here we really are talking about free distribution of software, so we've left it the way it was, with a slight wording clarification. > 5. Section 2.2, "preferably in the form of I-Ds". I'm not aware of any > other form of input but I-Ds on which a WG or a group of people without WG > status in the IETF could act on (and that would allow documenting the > complexity undoubtly involved). Therefore, I would suggest to remove > "preferably". Also, publishing an I-D undoubtly triggers the BCP79 > disclosure requirements---unspecified input may not. We've clarified this. There is input that is subject to BCP79 other than I-Ds, such as mailing list posts and presentations at WG sessions. > 6. Section 2.3: I read this section as a license to re-tune the requirements > document based on results obtained by tests (or even theoretical analysis) > of input proposals. It may be necessary to do this. However, you are > certainly aware of that such a procedure can lead to gaming and other evil > things (including unfair exclusion of proposals with IPR properties that are > within the scope of the IETF's IPR policy). If this were a working group > charter, I would voice strong concerns over this vagueness. For an informal > activity outside a WG, I only appeal to you to be careful in what you are > doing. That is most definitely not the intent of Section 2.3. We've clarified this. > 7. Section 2.6: to add something positive, I'm thrilled that people will at > least attempt to work cooperatively on codecs from very early on: this is > IMHO one of the really weak spots traditional codec standardization has had > in most of its instances. I'm also very happy to see the "no > rubberstamping" sentence. Great. > 8. Section 2.7: developments of RTP payload formats happen in AVT. No need > to word around that. Clarified to specify explicitly that this work will happen in the AVT WG. > 9. Section 3: I'm missing a statement on what happens if it turns out that > the requirements are NOT met. I think there should be an end criteria of > some sort. I don't think we need a statement about this -- it is covered quite well by existing IETF practices such as RFC 2418. > 10: I can see value in a strategy of not requiring a bit-exact encoder (as I > see a value in having such a requirement---in classic telco applications, > for example). However, I fail to see a value in not requiring bit-exact > decoding. Is this a fixed/floating point issue? > The can of worms one the IPR side one is opening by not strictly defining > conformance cannot be overestimated. Almost every IPR statement in the IETF > (and elsewhere) promises or grants licenses (or makes a non-assert covenant) > only for conformant implementations. I would strongly recommend to require > bit-exact decoding, for that reason alone. If you truly think that a soft > definition of conformance is necessary from a technical viewpoint, then I > would strongly recommend to at least define your version of conformance in a > normative, permanent document (standard's track RFC) which includes the > source code of the testing tool, and the test vectors against which soft > conformance is tested. We modified the text slightly here to clarify things, but retained the preference against bit-exact encoders and decoders. > 11: Section 5, first bullet, "open", see remark #2 Changed to "easily distributable". > 12: Section 5, first bullet, "conspicuous gap", see remark #3 Unchanged, see above. > 13: Section 5, second bullet "freely", see remark #1 Unchanged, because this really does refer to giving away software without charging for it. > 14: Section 5, fourth bullet, "free" , see remark #1 Changed to "easily distributable". > 15: Section 5, "BSD license": it's not a BSD license. It's *currently* a > BSD-style license. However, the IETF trust currently has control over this > thing and could, in theory, change it. Recommend to read the relevant > documents and come up with a precise and future-proof formulation. At this > time of writing I do not have access to the documents in question (writing > on a plane), but I can help in this. Changed to: the BSD license or whatever license is defined as acceptable by the IETF Trust when the relevant Internet-Drafts are published. > 16: Section 5, "royalty-free". Finally, this reasonably precise term is > used. Why not earlier? Because royalty-free is one method for achieving the goal of easily distributable. It is not, however, the only method. > However, just before that, the subject of open > source compatibility is mentioned as well (though not in this formulation). > Please note that it is very easy to draft a patent license that is > royalty-free and NOT open source compatible. Similarly, I would argue that > a good percentage of the RF licensing covenants in IETF IPR disclosures (in > contrast to most non-assert covenants) are not compatible with the majority > of the open source licenses in practical use. If you wish to express a > desire for compatibility with open source models, then you may want to > express this early on, in precise terms, and not with ambiguous language > such as "free" and "open". This might need to be tightened up further. > 17: Section 5, "20 years": as I have mentioned a number of times before: a > novel combination of 20year+ old tools may be patentable in its own right. > You may wish to add a sentence in this regard. This text was tightened up a bit. > 18: "infringing": it is in most cases unwise to use the term "infringement" > unless you truly know what you are doing---even in combination with > "unknowingly". Suggest to replace "infringe" with "incur encumbrance" or > something like this. Done. > 19: Section 6: I would suggest to remove this section in its entirety. Some > information presented may be seen differently in the cited SDOs. For > example, arguably, the low delay AAC effort is intended towards interactive > work, and not storage. Also, there may be SDOs not mentioned here which > have (or have had) viable speech/audio coding efforts that may feel insulted > by not being mentioned (3GPP2 come to mind, and some others). As the very > minimum, I would strongly suggest to "characterize" the other SDOs efforts > using only their own (liaison-)statements or publications as a basis, and > not your interpretation. The authors think this section is very important, because it clarifies the intent of the WG with respect to efforts at other SDOs and many questions have been raised about this topic on the list and at the Stockholm BoF. Those questions need to be addressed somewhere, and this I-D seems to be the best place for them, especially to clarify the use of existing liaison relationships. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrNAU4ACgkQNL8k5A2w/vxnhQCgr6CkWBFgb66+4JH/cGytmZsU ZgcAoPwT22sH7KGcPsBmAhF+tzQks6No =E6pm -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Oct 7 14:02:27 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF3A3A6914 for ; Wed, 7 Oct 2009 14:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.737 X-Spam-Level: X-Spam-Status: No, score=-2.737 tagged_above=-999 required=5 tests=[AWL=-0.138, 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 S1vUeCE1-+2K for ; Wed, 7 Oct 2009 14:02:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7F27828C105 for ; Wed, 7 Oct 2009 14:02:26 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D21F540D37; Wed, 7 Oct 2009 15:04:06 -0600 (MDT) Message-ID: <4ACD0245.2010004@stpeter.im> Date: Wed, 07 Oct 2009 15:04:05 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Marshall Eubanks References: <49613A2C-4736-4FA4-8B5B-93AF8391958D@americafree.tv> In-Reply-To: <49613A2C-4736-4FA4-8B5B-93AF8391958D@americafree.tv> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 21:02:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Again, my apologies for the delayed reply. On 9/5/09 5:05 AM, Marshall Eubanks wrote: > > On Sep 4, 2009, at 9:41 PM, Stephan Wenger wrote: >> 5. Section 2.2, "preferably in the form of I-Ds". I'm not aware of any >> other form of input but I-Ds on which a WG or a group of people >> without WG >> status in the IETF could act on (and that would allow documenting the >> complexity undoubtly involved). Therefore, I would suggest to remove >> "preferably". Also, publishing an I-D undoubtly triggers the BCP79 >> disclosure requirements---unspecified input may not. > > There is no way to publish an IETF stream RFC without beginning as an > Internet-draft and > without the contributors agreeing to the IETF IPR rules. This is true of > AD sponsored drafts > as well as WG sponsored drafts. The disclosure rules definitely apply to > all IETF contributions. See the updated text. This was meant to include mailing list posts, presentations at WG sessions, and the like. >> 15: Section 5, "BSD license": it's not a BSD license. It's *currently* a >> BSD-style license. However, the IETF trust currently has control over >> this >> thing and could, in theory, change it. > > That is correct. Of course, licenses are granted to published text. I am > not a lawyer, but my understanding is that these licenses, once granted, > could not be made more restrictive retroactively. > >> Recommend to read the relevant >> documents and come up with a precise and future-proof formulation. At >> this >> time of writing I do not have access to the documents in question >> (writing >> on a plane), but I can help in this. > > BCP 78 and 79 apply to IETF contributions and IETF publications. Note > that IETF licenses > explicitly and only refer to copyright, not patent - RFC5378 : The topic of the referenced text pertains to things that can be copyrighted, not things that can be patented. > 5.5. No Patent License The licenses granted in Section 5.3 shall not be > deemed to grant any right under any patent, patent application, or other > similar intellectual property right disclosed by the Contributor under > BCP 79 [RFC3979] or otherwise. > --- > So, in the statement : > In accordance with BCP 78 [RFC5378], the source code for the reference > implementation should be available under the BSD license. > I would take out "In accordance with BCP 78 [RFC5378],". If the > reference implementation is published in an RFC, then IETF IPR rules > will apply. If it is not, they will not. Fixed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrNAkUACgkQNL8k5A2w/vw6WwCgquVvvXpTDsEtmGm27zdv1cic OdMAoJNksioyY1ORtldnbjt9Db0ye8Qx =0Ns7 -----END PGP SIGNATURE----- From stewe@stewe.org Wed Oct 7 15:26:27 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81F23A6985 for ; Wed, 7 Oct 2009 15:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 vDVOULAk9wiV for ; Wed, 7 Oct 2009 15:26:26 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 501253A693D for ; Wed, 7 Oct 2009 15:26:24 -0700 (PDT) Received: from [192.168.1.105] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 456509-1743317 for multiple; Thu, 08 Oct 2009 00:28:04 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 07 Oct 2009 15:27:58 -0700 From: Stephan Wenger To: Peter Saint-Andre Message-ID: Thread-Topic: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] Thread-Index: AcpHnWvyuF0IO/VBpkGPs5N8/TNy0Q== In-Reply-To: <4ACD014E.3010502@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: "codec@ietf.org" Subject: Re: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:26:27 -0000 Thanks, Peter. I find most of my comments adequately addressed, and in some other cases we can agree to disagree without another discussion at this point in time. The one thing I want to comment on, hopefully constructively, is this: >> 16: Section 5, "royalty-free". Finally, this reasonably precise term is >> used. Why not earlier? > > Because royalty-free is one method for achieving the goal of easily > distributable. It is not, however, the only method. > >> However, just before that, the subject of open >> source compatibility is mentioned as well (though not in this formulation). >> Please note that it is very easy to draft a patent license that is >> royalty-free and NOT open source compatible. Similarly, I would argue that >> a good percentage of the RF licensing covenants in IETF IPR disclosures (in >> contrast to most non-assert covenants) are not compatible with the majority >> of the open source licenses in practical use. If you wish to express a >> desire for compatibility with open source models, then you may want to >> express this early on, in precise terms, and not with ambiguous language >> such as "free" and "open". > > This might need to be tightened up further. > Let me give it a try. Replace the original paragraph > In accordance with BCP 78 [TRUST], the source code for the reference > implementation should be available under the BSD license or whatever > license is defined as acceptable by the IETF Trust when the relevant > Internet-Drafts are published. Also, in accordance with BCP 79 > [IPR], the codecs should preferably use technologies with no known > IPR claims or technologies with an offer of royalty-free (RF) > licensing. Compatibility with the licensing of typical open source > applications requires the avoidance of restrictive IPR claims. With " In accordance with BCP 78 [TRUST], the source code for the reference implementation should be available under the BSD-style license or whatever license is defined as acceptable by the IETF Trust when the relevant Internet-Drafts are published. In accordance with the spirit of BCP 79 [IPR], the codecs should preferably use technologies with no known IPR claims, technologies available under patent non-assert covenants, or technologies with an offer of royalty-free (RF) licensing (in this order of preference). Among other goals, adhering to these preferences should help achieving compatibility with the patent licensing requirements of most open source licenses, thereby allowing for open source applications of the specified codec(s). " Motivation: 1. BCP78 compliance of the reference software has nothing to do with avoidance of patents of the algorithm, so the two should not be placed in the same paragraph. 2. I added non-assert covenants. As I mentioned before, non-assert covenants are typically better for open source license compatibility than mere RF licensing covenants, unless those RF licensing covenants are intentionally worded to be friendly/compatible to open source. Few of the RF licensing covenants posted in the IETF's IPR database are open source compatible at the time of writing (yes, I have reviewed all of them :-) 3. Expressing a preference of unencumbered-by-known-patents -> non-assert -> RF-licensing-commitment makes sense as it increases the chances of a "legal" open source implementation. Regards, Stephan P.s.: Please note that I'm sending this in order to help you guys to express what I believe are your intentions. I haven't changed my mind on viability of the exercise proposed, nor on my preference of the choice of venue for codec development. On 10/7/09 1:59 PM, "Peter Saint-Andre" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My apologies for the delayed reply. > > On 9/4/09 7:41 PM, Stephan Wenger wrote: >> Folks, >> I read through this draft and found it, all in all, a well written document >> covering a lot of (to me) agreeable aspects. > > Thanks. We have tried to incorporate most of your feedback into the > document. > >> However, as you may expect, I >> have a number of comments, mostly on certain language aspects :-) If this >> were a working group effort, I would phrase some of my suggestion below in >> stronger terms. As things stand, you are, of course, free to ignore them... >> Regards, >> Stephan >> >> >> 1. Section 1 speaks in several places of "freely available". I would >> recommend to be more precise. There are just too many definitions, some of >> which contradicting, of what constitutes "freedom" in our business. > > For consistency, we have changed all instances of "free" or "freely > available" (etc.) to "easily distributable" throughout the text. > >> 2. Section 1: the above remark also goes for the definition of "open". A >> very large part of the standardization people (perhaps a majority) >> associates "open" exclusively with "open process in the SDO" and not with >> what the draft implicitly assumes ("open" use, whatever that, in turn, may >> be). > > We clarified the wording about this a bit. > >> 3. Section 1, first bullet, "has inhibited": really? I don't believe this >> claim is true---certainly not in the form as made. At least, I have not >> seen a prove for this rather assertive statement. Suggest softening the >> language. > > I disagree. Certainly we received quite a bit of feedback before IETF 75 > and at the Stockholm meeting about this topic, so I don't think it's > appropriate to remove it. > >> 4. Section 1, final bullet: suggest replacing "will be freely available" >> with "may be available without royalties or other undue burden", as none of >> us has the means to guaranty something like "freely available". > > In fact, here we really are talking about free distribution of software, > so we've left it the way it was, with a slight wording clarification. > >> 5. Section 2.2, "preferably in the form of I-Ds". I'm not aware of any >> other form of input but I-Ds on which a WG or a group of people without WG >> status in the IETF could act on (and that would allow documenting the >> complexity undoubtly involved). Therefore, I would suggest to remove >> "preferably". Also, publishing an I-D undoubtly triggers the BCP79 >> disclosure requirements---unspecified input may not. > > We've clarified this. There is input that is subject to BCP79 other than > I-Ds, such as mailing list posts and presentations at WG sessions. > >> 6. Section 2.3: I read this section as a license to re-tune the requirements >> document based on results obtained by tests (or even theoretical analysis) >> of input proposals. It may be necessary to do this. However, you are >> certainly aware of that such a procedure can lead to gaming and other evil >> things (including unfair exclusion of proposals with IPR properties that are >> within the scope of the IETF's IPR policy). If this were a working group >> charter, I would voice strong concerns over this vagueness. For an informal >> activity outside a WG, I only appeal to you to be careful in what you are >> doing. > > That is most definitely not the intent of Section 2.3. We've clarified this. > >> 7. Section 2.6: to add something positive, I'm thrilled that people will at >> least attempt to work cooperatively on codecs from very early on: this is >> IMHO one of the really weak spots traditional codec standardization has had >> in most of its instances. I'm also very happy to see the "no >> rubberstamping" sentence. > > Great. > >> 8. Section 2.7: developments of RTP payload formats happen in AVT. No need >> to word around that. > > Clarified to specify explicitly that this work will happen in the AVT WG. > >> 9. Section 3: I'm missing a statement on what happens if it turns out that >> the requirements are NOT met. I think there should be an end criteria of >> some sort. > > I don't think we need a statement about this -- it is covered quite well > by existing IETF practices such as RFC 2418. > >> 10: I can see value in a strategy of not requiring a bit-exact encoder (as I >> see a value in having such a requirement---in classic telco applications, >> for example). However, I fail to see a value in not requiring bit-exact >> decoding. Is this a fixed/floating point issue? >> The can of worms one the IPR side one is opening by not strictly defining >> conformance cannot be overestimated. Almost every IPR statement in the IETF >> (and elsewhere) promises or grants licenses (or makes a non-assert covenant) >> only for conformant implementations. I would strongly recommend to require >> bit-exact decoding, for that reason alone. If you truly think that a soft >> definition of conformance is necessary from a technical viewpoint, then I >> would strongly recommend to at least define your version of conformance in a >> normative, permanent document (standard's track RFC) which includes the >> source code of the testing tool, and the test vectors against which soft >> conformance is tested. > > We modified the text slightly here to clarify things, but retained the > preference against bit-exact encoders and decoders. > >> 11: Section 5, first bullet, "open", see remark #2 > > Changed to "easily distributable". > >> 12: Section 5, first bullet, "conspicuous gap", see remark #3 > > Unchanged, see above. > >> 13: Section 5, second bullet "freely", see remark #1 > > Unchanged, because this really does refer to giving away software > without charging for it. > >> 14: Section 5, fourth bullet, "free" , see remark #1 > > Changed to "easily distributable". > >> 15: Section 5, "BSD license": it's not a BSD license. It's *currently* a >> BSD-style license. However, the IETF trust currently has control over this >> thing and could, in theory, change it. Recommend to read the relevant >> documents and come up with a precise and future-proof formulation. At this >> time of writing I do not have access to the documents in question (writing >> on a plane), but I can help in this. > > Changed to: > > the BSD license or whatever > license is defined as acceptable by the IETF Trust when the relevant > Internet-Drafts are published. > >> 16: Section 5, "royalty-free". Finally, this reasonably precise term is >> used. Why not earlier? > > Because royalty-free is one method for achieving the goal of easily > distributable. It is not, however, the only method. > >> However, just before that, the subject of open >> source compatibility is mentioned as well (though not in this formulation). >> Please note that it is very easy to draft a patent license that is >> royalty-free and NOT open source compatible. Similarly, I would argue that >> a good percentage of the RF licensing covenants in IETF IPR disclosures (in >> contrast to most non-assert covenants) are not compatible with the majority >> of the open source licenses in practical use. If you wish to express a >> desire for compatibility with open source models, then you may want to >> express this early on, in precise terms, and not with ambiguous language >> such as "free" and "open". > > This might need to be tightened up further. > >> 17: Section 5, "20 years": as I have mentioned a number of times before: a >> novel combination of 20year+ old tools may be patentable in its own right. >> You may wish to add a sentence in this regard. > > This text was tightened up a bit. > >> 18: "infringing": it is in most cases unwise to use the term "infringement" >> unless you truly know what you are doing---even in combination with >> "unknowingly". Suggest to replace "infringe" with "incur encumbrance" or >> something like this. > > Done. > >> 19: Section 6: I would suggest to remove this section in its entirety. Some >> information presented may be seen differently in the cited SDOs. For >> example, arguably, the low delay AAC effort is intended towards interactive >> work, and not storage. Also, there may be SDOs not mentioned here which >> have (or have had) viable speech/audio coding efforts that may feel insulted >> by not being mentioned (3GPP2 come to mind, and some others). As the very >> minimum, I would strongly suggest to "characterize" the other SDOs efforts >> using only their own (liaison-)statements or publications as a basis, and >> not your interpretation. > > The authors think this section is very important, because it clarifies > the intent of the WG with respect to efforts at other SDOs and many > questions have been raised about this topic on the list and at the > Stockholm BoF. Those questions need to be addressed somewhere, and this > I-D seems to be the best place for them, especially to clarify the use > of existing liaison relationships. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrNAU4ACgkQNL8k5A2w/vxnhQCgr6CkWBFgb66+4JH/cGytmZsU > ZgcAoPwT22sH7KGcPsBmAhF+tzQks6No > =E6pm > -----END PGP SIGNATURE----- From jean-marc.valin@usherbrooke.ca Wed Oct 7 20:32:55 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507B928C14E for ; Wed, 7 Oct 2009 20:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 ChOakcQTAx0w for ; Wed, 7 Oct 2009 20:32:54 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id E95BF3A67C2 for ; Wed, 7 Oct 2009 20:32:53 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KR600DJAF9LIQI1@VL-MH-MR001.ip.videotron.ca> for codec@ietf.org; Wed, 07 Oct 2009 23:34:34 -0400 (EDT) Message-id: <4ACD5DC8.9030203@usherbrooke.ca> Date: Wed, 07 Oct 2009 23:34:32 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: David Rowe References: <4ACCCCB3.8080100@octasic.com> <3d032e5d0910071130w470d46d1n6b80a87013090be4@mail.gmail.com> <4ACCDFFD.1030904@stpeter.im> <3d032e5d0910071222yc718eaeye2574e301894f9ae@mail.gmail.com> In-reply-to: <3d032e5d0910071222yc718eaeye2574e301894f9ae@mail.gmail.com> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Updated codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 03:32:55 -0000 Hi David, > Having implemented many codecs, I really like the idea of 16 bit, fixed > point, bit exact reference implementation. Bit exact implementations > just make life so much easier for implementation. I agree that being bit-exact with the reference implementation is probably the easiest way to port the codec and the intent wasn't to prevent anyone from doing that. > I can't think of any > architectures where 16 bit/fixed point won't implement cleanly. In many > cases you would just need to cross-compile and you are done with a > port. Probably the best example of architectures where you wouldn't want to be bit-exact is when you want floating point code (which is faster than fixed-point on many machines). Another example is for fractional 32x16 multiplications, for which the ITU-T has funny operators (based on older DSPs that didn't have a signed-unsigned multiplier). I'm sure there are other examples where you could gain performance by not being "bit-exact" with the reference implementation. > In other words I can't see any risk in a "bias" towards a 16 bit fixed > point architecture. I can however see a lot of risk allowing a "close > enough" implementation. Making the codec easy to implement will mean > faster acceptance. Get two vendors arguing over whose implementation is > correct and the opposite will be true. > > One option would be to specify the algorithm is a bit exact form, then > allow implementers to do a "close enough" implementation if they wish. This is exactly the intent of the drafts. In saying that close enough is OK, it's implied that "exact" is also OK. We can probably make that clearer. Please feel free to suggest some changes here. > 2/ In Section 6 what does this mean > > * Purely wireless applications will not be considered > > Does it exclude Wifi? Maybe an example would clarify..... Wifi is definitely within the scope here. I agree that "purely wireless" is not a great description. My personal view (we haven't discussed this in great details) is that we would rule out applications such as ham radio and cell phones (unless you're doing VoIP on that mobile), but include "IP over wireless links". Again, a better wording would be welcome if anyone can suggest one. > 3/ Section 2.1: > > Also, the codec should be robust to noise (produce intelligible > speech) even at lower bit-rates. > > I suggest tightening this a bit to something similar to the requirement > for music "the codec should be robust to noise (produce intelligible > speech and no annoying artifacts) even at lower bit-rates." You mean you would like to add "and no annoying artifacts" to the text? > We will > also need a way to measure this, e.g. samples corrupted by various noise > sources. Samples with periodic background noise (like a vehicle engine) > can be challenging. Agreed. > 4/ Section 2.2: > > Some great ideas in this section, but I suggest changing: > To make it easier to determine which streams have to be mixed > (and which are noise/silence), it must be possible to measure > (or estimate) the level of the audio in a packet > to: > To make it easier to determine which streams have to be mixed (and > which are noise/silence), it must be possible to measure (or estimate) > voice activity > > By voice activity I mean a bit or test that says "this packet is not just > background noise". Agreed that we can be more precise here. VAD without decode was really the intent, though I'm thinking that the information could be useful for other purposes as well. > 5/ Section 2.2: > > I challenge the need for special low-delay requirements, e.g. 10ms. My > ping time to the US west coast is 300ms, so any Internet codec delays > will be trivial compared to the propagation time of the packet. I guess > it could make a difference if you are having a teleconference between > two east-coast US cities, but the Internet is a big place...... The Internet is indeed a big place and the dalays can vary a lot. That being said, there are many cases where you are communicating either in the same city, or to a nearby city. I have standard cable connection and my ping time (that I just measured non-scientifically) is around 10 ms within the city and 12 ms to Sherbrooke (200 km away). In thoses cases, a low-delay codec *can* make a difference on the perceptibility of acoustic echo. That being said, the intent is to make sure not to penalise the people who do not need this (e.g. making calls from AU to US). > 6/ Section 2.6, these are interesting apps but how much special effort > (e.g. a very tight delay requirement) do we want to put in for such a > rare use of the codec? I guess if we get the low delay "for free" it's > OK. Or am I missing something and live music etc are likely to be a > major future use of the codec? Well, the intend is to get this mostly for free. This could either be through defining a low-delay mode for the codec (if possible), or by creating a separate codec. All these requirements do not have to be fulfilled by a single codec (though of course we don't want one codec per application). > Most (>99%?) of today's music apps are delay insensitive, e.g. > streaming. Keep in mind that a codec that we are developing now would (if successful) likely still be in use in 10 years, so we need to look into the future. > Perhaps I am suggesting that requirements be weighted in proportion to > projected use, for example applications 2.1, 2,2, and 2.5 would probably > cover 99% of all instances of the codec. See above. Let me restate that the intent is not to penalise the "high" delay case at all. > 7/ Section 3 (e.g. discussion of prediction etc) reads like suggestions > for implementation rather than a requirements document. They are good > suggestions BTW, but a requirement is more like (x % degradation under a > y % packet error rate, or x ms to resynchronise). If some one achieves > that in an unexpected way we don't really care. Section 3 is mostly meant to explain how the Internet impacts the requirements of the next section. > 8/ Section 3.1. Paragraph 1: The worst case CPU should be specified as > a number. This part of the complexity discussion is only about security (i.e. making sure we don't get exposed to DoS). I'm not sure what's the best way to quantify this. Obviously, if the worst case is 100x more complex than the average, it's not good, but where exactly would you put the limit? > 8/ Section 4.2. g729 should be one of the reference codecs as it is > ubiquitous on today's Internet. This new codec will be it's likely > successor. We should aim for a codec that is >= g729 and IPR free. I don't actually think g729 is really what we want to target. We are mostly looking at a wideband codec, with narrowband being mostly useful for "legacy compatibility". Even the 8 kbps bit-rate isn't that useful considering that we're usually sending 16 kbps worth of headers (RTP with 20 ms packetization time). Also, G.729 is not exactly what I would describe as an easily distributable audio codec. Cheers, Jean-Marc From stpeter@stpeter.im Thu Oct 8 11:31:20 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AE23A6AC1 for ; Thu, 8 Oct 2009 11:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[AWL=-0.135, 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 JKoaQPuyFMPe for ; Thu, 8 Oct 2009 11:31:19 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 16D2B3A6ABB for ; Thu, 8 Oct 2009 11:31:19 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9F49C40D1F for ; Thu, 8 Oct 2009 12:33:01 -0600 (MDT) Message-ID: <4ACE305C.4020403@stpeter.im> Date: Thu, 08 Oct 2009 12:33:00 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 18:31:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the Codec BoF request that I submitted to agenda@ietf.org, I provided an updated charter proposal. It seems that I neglected to send that to the list. I do so now, with a request for feedback so that we can work toward consensus regarding the problem statement, objectives, scope, deliverables, and milestones of the proposed Codec WG. /psa *** PROPOSED CHARTER Problem Statement There are no standardized, high-quality audio codecs that are optimized for use in interactive Internet applications and that can be widely implemented and easily distributed among application developers, service operators, and end users. This gap in the Internet protocol stack has hindered protocol designers from being able to specify mandatory-to-implement codecs in their protocols for the sake of interoperability, developers from building innovative, interactive applications, service operators from deploying affordable, high-quality services, and end users from enjoying an optimal user experience. Because the Internet Standards Process defines an open, transparent process for technology standardization, a wide range of codec experts have committed to actively working on such codecs within the IETF. The Codec WG provides a structured forum for these efforts. Objectives The goal of this group is to develop one or more high-quality, widely-distributable audio codecs that is optimized for use over the Internet. Core considerations include the following: 1. Use in interactive applications (examples include but are not limited to point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet, especially packet loss 3. Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signalling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP) Codecs optimized for very low bit rates and codecs for non-interactive audio are out of scope. Although the codec(s) produced by the group might be used as mandatory-to-implement technologies by designers of particular Internet protocols, it is explicitly not a goal of the group to produce a codec that will be mandated for use across the entire IETF or Internet community. The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor not to function as a "codec factory" that produces a large number of codecs. Work processes and technical requirements for achieving the foregoing objectives are outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these will be further refined by the group in accordance with the usual IETF procedures for arriving at rough consensus. Intellectual property rights (IPR) issues will be handled in accordance with BCP 78 and BCP 79. Many existing codecs with the technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use across the Internet community difficult. The group will try to standardize codecs that can be relatively freely and easily distributed, and employed as much as possible. In doing so, it will adhere closely to these BCPs. More specifically, "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Note that in accordance with BCP 79, the group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; such decisions will be made in accordance with the rough consensus of the group. Deliverables 1. Guidelines that define the work process of the group, using draft-valin-codec-guidelines as the basis for achieving consensus. This document shall be Informational. 2. Detailed technical requirements, using draft-valin-codec-requirements as the basis for achieving consensus. This document shall be Informational. 3. Specification of one or more codecs that meet the agreed-upon requirements, in the form of Internet-Drafts that define the codec algorithm and source code for a reference implementation. The text description of each codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that each such specification shall be a Proposed Standard document. Milestones Mar-2010: WGLC on Codec Standardization Guidelines Mar-2010: WGLC on Requirements May-2010: Codec Standardization Guidelines to IESG (Informational) May-2010: Requirements to IESG (Infomational) Oct-2010: WGLC on codec specification(s) Jan-2011: Submit codec specification(s) to IESG (Standards Track) *** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrOMFwACgkQNL8k5A2w/vyYdgCgkPq/L9sj2x8hx6SE8UGS7aE6 HN0AoPxQRKcPXPWOdJmnNjiAAS2wTG1F =eQ5m -----END PGP SIGNATURE----- From tme@americafree.tv Thu Oct 8 12:10:18 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B19128C1A2 for ; Thu, 8 Oct 2009 12:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Vw+oHemb7Q+V for ; Thu, 8 Oct 2009 12:10:17 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id DD64328C15F for ; Thu, 8 Oct 2009 12:10:16 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id D54BC4EBC0EF; Thu, 8 Oct 2009 15:11:58 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Peter Saint-Andre In-Reply-To: <4ACE305C.4020403@stpeter.im> 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, 8 Oct 2009 15:11:57 -0400 References: <4ACE305C.4020403@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 19:10:18 -0000 This charter is not on the general BOF page for IETF 76 http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 Can it be added there ? Or is it in transit ? (I would like to send the link to some people.) Regards Marshall On Oct 8, 2009, at 2:33 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In the Codec BoF request that I submitted to agenda@ietf.org, I > provided > an updated charter proposal. It seems that I neglected to send that to > the list. I do so now, with a request for feedback so that we can work > toward consensus regarding the problem statement, objectives, scope, > deliverables, and milestones of the proposed Codec WG. > > /psa > > *** > > PROPOSED CHARTER > > Problem Statement > > There are no standardized, high-quality audio codecs that are > optimized > for use in interactive Internet applications and that can be widely > implemented and easily distributed among application developers, > service operators, and end users. This gap in the Internet protocol > stack has hindered protocol designers from being able to specify > mandatory-to-implement codecs in their protocols for the sake of > interoperability, developers from building innovative, interactive > applications, service operators from deploying affordable, high- > quality > services, and end users from enjoying an optimal user experience. > Because the Internet Standards Process defines an open, transparent > process for technology standardization, a wide range of codec experts > have committed to actively working on such codecs within the IETF. > The > Codec WG provides a structured forum for these efforts. > > Objectives > > The goal of this group is to develop one or more high-quality, > widely-distributable audio codecs that is optimized for use over the > Internet. Core considerations include the following: > > 1. Use in interactive applications (examples include but are not > limited > to point-to-point voice calls, multi-party voice conferencing, > telepresence, teleoperation, in-game voice chat, and live music > performance) > > 2. Addressing the real transport conditions of the Internet, > especially > packet loss > > 3. Ensuring interoperability with the Real-time Transport Protocol > (RTP), including secure transport via SRTP > > 4. Ensuring interoperability with Internet signalling technologies > such > as Session Initiation Protocol (SIP), Session Description Protocol > (SDP), and Extensible Messaging and Presence Protocol (XMPP) > > Codecs optimized for very low bit rates and codecs for non-interactive > audio are out of scope. > > Although the codec(s) produced by the group might be used as > mandatory-to-implement technologies by designers of particular > Internet > protocols, it is explicitly not a goal of the group to produce a codec > that will be mandated for use across the entire IETF or Internet > community. > > The group might produce only one codec or it might produce multiple > codecs; however, to reduce confusion in the marketplace it shall > endeavor not to function as a "codec factory" that produces a large > number of codecs. > > Work processes and technical requirements for achieving the foregoing > objectives are outlined in draft-valin-codec-guidelines and > draft-valin-codec-requirements respectively; these will be further > refined by the group in accordance with the usual IETF procedures for > arriving at rough consensus. > > Intellectual property rights (IPR) issues will be handled in > accordance > with BCP 78 and BCP 79. Many existing codecs with the technical > attributes listed above are encumbered with licensing fees and other > IPR > claims that make royalty-free and wide distribution and use across the > Internet community difficult. The group will try to standardize > codecs > that can be relatively freely and easily distributed, and employed as > much as possible. In doing so, it will adhere closely to these BCPs. > More specifically, "In general, IETF working groups prefer > technologies > with no known IPR claims or, for technologies with claims against > them, > an offer of royalty-free licensing." Note that in accordance with BCP > 79, the group will not explicitly rule out the possibility of adopting > technology that does not meet these IPR requirements; such decisions > will be made in accordance with the rough consensus of the group. > > Deliverables > > 1. Guidelines that define the work process of the group, using > draft-valin-codec-guidelines as the basis for achieving consensus. > This > document shall be Informational. > > 2. Detailed technical requirements, using draft-valin-codec- > requirements > as the basis for achieving consensus. This document shall be > Informational. > > 3. Specification of one or more codecs that meet the agreed-upon > requirements, in the form of Internet-Drafts that define the codec > algorithm and source code for a reference implementation. The text > description of each codec shall indicate which components of the > encoder > and decoder are mandatory, recommended, and optional. It is > envisioned > that each such specification shall be a Proposed Standard document. > > Milestones > > Mar-2010: WGLC on Codec Standardization Guidelines > Mar-2010: WGLC on Requirements > May-2010: Codec Standardization Guidelines to IESG (Informational) > May-2010: Requirements to IESG (Infomational) > Oct-2010: WGLC on codec specification(s) > Jan-2011: Submit codec specification(s) to IESG (Standards Track) > > *** > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrOMFwACgkQNL8k5A2w/vyYdgCgkPq/L9sj2x8hx6SE8UGS7aE6 > HN0AoPxQRKcPXPWOdJmnNjiAAS2wTG1F > =eQ5m > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From stpeter@stpeter.im Thu Oct 8 12:26:23 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E303A69D0 for ; Thu, 8 Oct 2009 12:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 HmJurT0VrYts for ; Thu, 8 Oct 2009 12:26:22 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3F6503A69BE for ; Thu, 8 Oct 2009 12:26:22 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AD67740D1F; Thu, 8 Oct 2009 13:28:04 -0600 (MDT) Message-ID: <4ACE3D43.2040104@stpeter.im> Date: Thu, 08 Oct 2009 13:28:03 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Marshall Eubanks References: <4ACE305C.4020403@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 19:26:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/8/09 1:11 PM, Marshall Eubanks wrote: > This charter is not on the general BOF page for IETF 76 > > http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 Updated, with link to: http://trac.tools.ietf.org/bof/trac/attachment/wiki/BifIETF76/codec-charter.txt /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrOPUMACgkQNL8k5A2w/vyhIACg19tPLWaQKGsoN+C+0aeq10uy lEIAnjz+nZvyAa57B/bFIJsGx76fU370 =IhI+ -----END PGP SIGNATURE----- From hsinnrei@adobe.com Thu Oct 8 15:01:48 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37C23A68BA for ; Thu, 8 Oct 2009 15:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.001 X-Spam-Level: X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ni9EIgXHOPz for ; Thu, 8 Oct 2009 15:01:38 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by core3.amsl.com (Postfix) with ESMTP id C7B003A6835 for ; Thu, 8 Oct 2009 15:01:36 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKSs5hp6NPayOPvQROhEAspYcWTHNV2mbz@postini.com; Thu, 08 Oct 2009 15:03:21 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n98M3HX3021642; Thu, 8 Oct 2009 15:03:17 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n98M3DY3018811; Thu, 8 Oct 2009 15:03:15 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Oct 2009 15:03:13 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Thu, 8 Oct 2009 15:03:12 -0700 From: Henry Sinnreich To: Peter Saint-Andre , "codec@ietf.org" Date: Thu, 8 Oct 2009 15:03:09 -0700 Thread-Topic: [codec] proposed charter Thread-Index: AcpIRdIwtMUlpM9DS5exTbP1Jeg8VQAHUyrb Message-ID: In-Reply-To: <4ACE305C.4020403@stpeter.im> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6F3CBCD62DBhsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 22:01:48 -0000 --_000_C6F3CBCD62DBhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem statement and objective number 1 are admirably stated. I would suggest however the codec has no dependency on the signaling protoc= ol, whatever that may be. It is up to the signaling protocol to inform about the codec and not vice v= ersa. Last but not least, there are other, non-IETF signaling protocols in wide u= se on the Internet. Also the reference to packet loss in the Internet opens a can of worms, sin= ce broadband networks don't really suffer from sizable random packet loss, = but may suffer from packet burst loss (such as producing voice clipping) du= e to congestion or route flapping for which no codec can expected to be tol= erant or immune. The can of worms is even bigger for wireless access networks and for mobile= devices, but again, for whatever cause, voice clipping is beyond the codec= s to fix. If people still want to mention packet loss, what are the correct metrics (= random and burst statistics) and the values for Internet voice codecs to de= al with? What is the role of the transport protocols and the role of the co= decs in dealing with packet loss? For example, how is packet loss dealt wit= h in streaming HTTP (Example: ), just to illustrate the point= about transport, since streaming HTTP may not be suitable for interactive = voice . In summary, IMO there should be no codec dependency on specific signaling p= rotocols and no mention of packet loss. Henry On 10/8/09 1:33 PM, "Peter Saint-Andre" wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the Codec BoF request that I submitted to agenda@ietf.org, I provided an updated charter proposal. It seems that I neglected to send that to the list. I do so now, with a request for feedback so that we can work toward consensus regarding the problem statement, objectives, scope, deliverables, and milestones of the proposed Codec WG. /psa *** PROPOSED CHARTER Problem Statement There are no standardized, high-quality audio codecs that are optimized for use in interactive Internet applications and that can be widely implemented and easily distributed among application developers, service operators, and end users. This gap in the Internet protocol stack has hindered protocol designers from being able to specify mandatory-to-implement codecs in their protocols for the sake of interoperability, developers from building innovative, interactive applications, service operators from deploying affordable, high-quality services, and end users from enjoying an optimal user experience. Because the Internet Standards Process defines an open, transparent process for technology standardization, a wide range of codec experts have committed to actively working on such codecs within the IETF. The Codec WG provides a structured forum for these efforts. Objectives The goal of this group is to develop one or more high-quality, widely-distributable audio codecs that is optimized for use over the Internet. Core considerations include the following: 1. Use in interactive applications (examples include but are not limited to point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance= ) 2. Addressing the real transport conditions of the Internet, especially packet loss 3. Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signalling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP) Codecs optimized for very low bit rates and codecs for non-interactive audio are out of scope. Although the codec(s) produced by the group might be used as mandatory-to-implement technologies by designers of particular Internet protocols, it is explicitly not a goal of the group to produce a codec that will be mandated for use across the entire IETF or Internet community. The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor not to function as a "codec factory" that produces a large number of codecs. Work processes and technical requirements for achieving the foregoing objectives are outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these will be further refined by the group in accordance with the usual IETF procedures for arriving at rough consensus. Intellectual property rights (IPR) issues will be handled in accordance with BCP 78 and BCP 79. Many existing codecs with the technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use across the Internet community difficult. The group will try to standardize codecs that can be relatively freely and easily distributed, and employed as much as possible. In doing so, it will adhere closely to these BCPs. More specifically, "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Note that in accordance with BCP 79, the group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; such decisions will be made in accordance with the rough consensus of the group. Deliverables 1. Guidelines that define the work process of the group, using draft-valin-codec-guidelines as the basis for achieving consensus. This document shall be Informational. 2. Detailed technical requirements, using draft-valin-codec-requirements as the basis for achieving consensus. This document shall be Informational= . 3. Specification of one or more codecs that meet the agreed-upon requirements, in the form of Internet-Drafts that define the codec algorithm and source code for a reference implementation. The text description of each codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that each such specification shall be a Proposed Standard document. Milestones Mar-2010: WGLC on Codec Standardization Guidelines Mar-2010: WGLC on Requirements May-2010: Codec Standardization Guidelines to IESG (Informational) May-2010: Requirements to IESG (Infomational) Oct-2010: WGLC on codec specification(s) Jan-2011: Submit codec specification(s) to IESG (Standards Track) *** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrOMFwACgkQNL8k5A2w/vyYdgCgkPq/L9sj2x8hx6SE8UGS7aE6 HN0AoPxQRKcPXPWOdJmnNjiAAS2wTG1F =3DeQ5m -----END PGP SIGNATURE----- _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C6F3CBCD62DBhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] proposed charter The problem statement and objective number 1 are admirably stated.
I would suggest however the codec has no dependency on the signaling protoc= ol, whatever that may be.
It is up to the signaling protocol to inform about the codec and not vice v= ersa.
Last but not least, there are other, non-IETF signaling protocols in wide u= se on the Internet.

Also the reference to packet loss in the Internet opens a can of worms, sin= ce broadband networks don’t really suffer from sizable random packet = loss, but may suffer from packet burst loss (such as producing voice clippi= ng) due to congestion or route flapping for which no codec can expected to = be tolerant or immune.

The can of worms is even bigger for wireless access networks and for mobile= devices, but again, for whatever cause, voice clipping is beyond the codec= s to fix.

If people still want to mention packet loss, what are the correct metrics (= random and burst statistics) and the values for Internet voice codecs to de= al with? What is the role of the transport protocols and the role of the co= decs in dealing with packet loss? For example, how is packet loss dealt wit= h in streaming HTTP
(Example: <draft-pantos-http-live-streaming>), just to illustrate the= point about transport, since streaming HTTP may not be suitable for intera= ctive voice .

In summary, IMO there should be no codec dependency on specific signaling p= rotocols and no mention of packet loss.

Henry


On 10/8/09 1:33 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the Codec BoF request that I submitted to ag= enda@ietf.org, I provided
an updated charter proposal. It seems that I neglected to send that to
the list. I do so now, with a request for feedback so that we can work
toward consensus regarding the problem statement, objectives, scope,
deliverables, and milestones of the proposed Codec WG.

/psa

***

PROPOSED CHARTER

Problem Statement

There are no standardized, high-quality audio codecs that are optimized
for use in interactive Internet applications and that can be widely
implemented and easily distributed among  application developers,
service operators, and end users.  This gap in the Internet protocol stack has hindered protocol designers from being able to specify
mandatory-to-implement codecs in their protocols for the sake of
interoperability, developers from building innovative, interactive
applications, service operators from deploying affordable, high-quality
services, and end users from enjoying an optimal user experience.
Because the Internet Standards Process defines an open, transparent
process for technology standardization, a wide range of codec experts
have committed to actively working on such codecs within the IETF.  Th= e
Codec WG provides a structured forum for these efforts.

Objectives

The goal of this group is to develop one or more high-quality,
widely-distributable audio codecs that is optimized for use over the
Internet. Core considerations include the following:

1. Use in interactive applications (examples include but are not limited to point-to-point voice calls, multi-party voice conferencing,
telepresence, teleoperation, in-game voice chat, and live music performance= )

2. Addressing the real transport conditions of the Internet, especially
packet loss

3. Ensuring interoperability with the Real-time Transport Protocol
(RTP), including secure transport via SRTP

4. Ensuring interoperability with Internet signalling technologies such
as Session Initiation Protocol (SIP), Session Description Protocol
(SDP), and Extensible Messaging and Presence Protocol (XMPP)

Codecs optimized for very low bit rates and codecs for non-interactive
audio are out of scope.

Although the codec(s) produced by the group might be used as
mandatory-to-implement technologies by designers of particular Internet
protocols, it is explicitly not a goal of the group to produce a codec
that will be mandated for use across the entire IETF or Internet community.=

The group might produce only one codec or it might produce multiple
codecs; however, to reduce confusion in the marketplace it shall
endeavor not to function as a "codec factory" that produces a lar= ge
number of codecs.

Work processes and technical requirements for achieving the foregoing
objectives are outlined in draft-valin-codec-guidelines and
draft-valin-codec-requirements respectively; these will be further
refined by the group in accordance with the usual IETF procedures for
arriving at rough consensus.

Intellectual property rights (IPR) issues will be handled in accordance
with BCP 78 and BCP 79. Many existing codecs with the technical
attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use across the
Internet community difficult.  The group will try to standardize codec= s
that can be relatively freely and easily distributed, and employed as
much as possible. In doing so, it will adhere closely to these BCPs.
More specifically, "In general, IETF working groups prefer technologie= s
with no known IPR claims or, for technologies with claims against them,
an offer of royalty-free licensing."  Note that in accordance wit= h BCP
79, the group will not explicitly rule out the possibility of adopting
technology that does not meet these IPR requirements; such decisions
will be made in accordance with the rough consensus of the group.

Deliverables

1. Guidelines that define the work process of the group, using
draft-valin-codec-guidelines as the basis for achieving consensus. This
document shall be Informational.

2. Detailed technical requirements, using draft-valin-codec-requirements as the basis for achieving consensus.  This document shall be Informat= ional.

3. Specification of one or more codecs that meet the agreed-upon
requirements, in the form of Internet-Drafts that define the codec
algorithm and source code for a reference implementation. The text
description of each codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional.  It is envisione= d
that each such specification shall be a Proposed Standard document.

Milestones

Mar-2010: WGLC on Codec Standardization Guidelines
Mar-2010: WGLC on Requirements
May-2010: Codec Standardization Guidelines to IESG (Informational)
May-2010: Requirements to IESG (Infomational)
Oct-2010: WGLC on codec specification(s)
Jan-2011: Submit codec specification(s) to IESG (Standards Track)

***


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrOMFwACgkQNL8k5A2w/vyYdgCgkPq/L9sj2x8hx6SE8UGS7aE6
HN0AoPxQRKcPXPWOdJmnNjiAAS2wTG1F
=3DeQ5m
-----END PGP SIGNATURE-----
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C6F3CBCD62DBhsinnreiadobecom_-- From swmike@swm.pp.se Thu Oct 8 23:50:22 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BF528C19E for ; Thu, 8 Oct 2009 23:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 WjpLqOlgt3CA for ; Thu, 8 Oct 2009 23:50:21 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 3D4FF28C175 for ; Thu, 8 Oct 2009 23:50:20 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 01DBD9F; Fri, 9 Oct 2009 08:52:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 00E179C; Fri, 9 Oct 2009 08:52:01 +0200 (CEST) Date: Fri, 9 Oct 2009 08:52:01 +0200 (CEST) From: Mikael Abrahamsson To: Henry Sinnreich In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 06:50:22 -0000 On Thu, 8 Oct 2009, Henry Sinnreich wrote: > If people still want to mention packet loss, what are the correct > metrics (random and burst statistics) and the values for Internet voice > codecs to deal with? What is the role of the transport protocols and the > role of the codecs in dealing with packet loss? For example, how is > packet loss dealt with in streaming HTTP (Example: > ), just to illustrate the point about > transport, since streaming HTTP may not be suitable for interactive > voice . > > In summary, IMO there should be no codec dependency on specific > signaling protocols and no mention of packet loss. I have earlier proposed that the full solution should be able to cope with 10% packet loss and 1.5-2 seconds of jitter. Of course there would be impact on quality, and continous loss (a full second of loss) is of course impossible to handle. But the two major types I see that needs to be handled are: Wireless networks with ARQ such as 802.11, 3GPP and alike. These typically can induce 1-2 seconds of jitter, but with low or no packet loss. Routers/switches that do buffering and which use either FIFO/taildrop or some kind of more intelligent buffer management such as (W)RED or alike. These might drop a few percent of packets (usually never more as TCP backs off a lot at these packet drop rates and thus the links are usually not loaded more than what causes a few percent packet loss) plus induce jitter as other traffic affects this. Routers typically never buffer packets more than 600ms, often much lower, thus jitter is less unless there are multiple congested links in a row. I'm a firm believer that for the whole solution to work, this can't be seen as a layered problem in which the layers can ignore each other, but to work well, they need to be tightly integrated. -- Mikael Abrahamsson email: swmike@swm.pp.se From koen.vos@skype.net Fri Oct 9 01:59:18 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E7F28C1ED for ; Fri, 9 Oct 2009 01:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 QlRr01zbCYLw for ; Fri, 9 Oct 2009 01:59:16 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 62DAB28C1E8 for ; Fri, 9 Oct 2009 01:59:06 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 291266065CD22; Fri, 9 Oct 2009 10:00:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=8kSSXX2OkAHv XbYbUUr5d/fqyoo=; b=eb47Jc4GFrYIjLARolZRw+e2z0f/lCxHGd3ATLbSleF/ wRWibZ+51l+F6XOWjH3uH7fFe+hnmN/xeCghqbj8AS2KWlrOg+eut4ny91YTRgG3 n2KbVKKUg3wP2hQmqoygaVy7EUpEvtkY8WH6dOBlTOwHcpOywCxoA/cmNb5/uHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=GVfBYn918cH43vOIFGJw ECtl1kQH1LWzu+vLfL9bK3Buc2dLKOgZIHt3pCtK4Mkf3VO3TESB4a7WU+mACBgY 8azogtagqX8JJU0bBJ7CPdMLjud8FUDhIQDb+NUDhxpPwcQ1RWekV5ZY+TbuUNrh 7rUBHZmk1JHotk43S+GjVo4= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 2793C6064CBAA; Fri, 9 Oct 2009 10:00:49 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsftmX6K5jpG; Fri, 9 Oct 2009 10:00:49 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 146596065CCDD; Fri, 9 Oct 2009 10:00:49 +0100 (IST) Received: from 71.141.142.127 ([71.141.142.127]) by mail.skype.net (Horde Framework) with HTTP; Fri, 09 Oct 2009 02:00:49 -0700 Message-ID: <20091009020049.91404eej4de6p0ap@mail.skype.net> Date: Fri, 09 Oct 2009 02:00:49 -0700 From: Koen Vos To: Mikael Abrahamsson References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 08:59:18 -0000 Mikael, My view on integrating jitter buffer and codec: The integration is best done through an interface that lets the decoder indicate to the jitter buffer what state the audio signal is in, and lets the jitter buffer tell the decoder what action to take. For example, if the jitter buffer wants to accelerate the decoding of packets, it should (try to) wait until the decoder signals a silent period, or at least a stationary part in the signal, and then tell the decoder to compress the audio signal. The interface needs to pass just a few parameters in both directions for a tight integration between decoder and jitter buffer. The jitter buffer should however not be part of the decoder, because: 1. The jitter buffer, just like other parts of the voice stack, is not essential for interoperability. 2. Voice stacks that contain multiple codecs typically share a common jitter buffer. 3. A jitter buffer is tuned towards the network and platform. As you point out, a wireless 3G network has rather different packet loss and jitter behavior than a DSL modem. 4. Even if we would define a jitter buffer that works great for any network today, it may not work well with tomorrow's networks. I also don't see a use in defining how much jitter a codec can handle. It's easy to handle 10 seconds of jitter by having a fixed 10 second jitter buffer, but depending on the network characteristics that may or may not be a good solution. In short: for any VoIP application to work well, all of its layers and components need to be tightly integrated. But the role of a codec is merely to provide the interfaces to allow that to happen - not to define the complete VoIP application. best, koen. Quoting Mikael Abrahamsson: > On Thu, 8 Oct 2009, Henry Sinnreich wrote: > >> If people still want to mention packet loss, what are the correct >> metrics (random and burst statistics) and the values for Internet >> voice codecs to deal with? What is the role of the transport >> protocols and the role of the codecs in dealing with packet loss? >> For example, how is packet loss dealt with in streaming HTTP >> (Example: ), just to illustrate >> the point about transport, since streaming HTTP may not be suitable >> for interactive voice . >> >> In summary, IMO there should be no codec dependency on specific >> signaling protocols and no mention of packet loss. > > I have earlier proposed that the full solution should be able to > cope with 10% packet loss and 1.5-2 seconds of jitter. Of course > there would be impact on quality, and continous loss (a full second > of loss) is of course impossible to handle. > > But the two major types I see that needs to be handled are: > > Wireless networks with ARQ such as 802.11, 3GPP and alike. These > typically can induce 1-2 seconds of jitter, but with low or no > packet loss. > > Routers/switches that do buffering and which use either > FIFO/taildrop or some kind of more intelligent buffer management > such as (W)RED or alike. These might drop a few percent of packets > (usually never more as TCP backs off a lot at these packet drop > rates and thus the links are usually not loaded more than what > causes a few percent packet loss) plus induce jitter as other > traffic affects this. Routers typically never buffer packets more > than 600ms, often much lower, thus jitter is less unless there are > multiple congested links in a row. > > I'm a firm believer that for the whole solution to work, this can't > be seen as a layered problem in which the layers can ignore each > other, but to work well, they need to be tightly integrated. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From ron@debian.org Fri Oct 9 02:47:04 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70053A67B8 for ; Fri, 9 Oct 2009 02:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 PcZQaNqkND-D for ; Fri, 9 Oct 2009 02:47:04 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by core3.amsl.com (Postfix) with ESMTP id ACBC23A67AA for ; Fri, 9 Oct 2009 02:47:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAGKkzkp5LYVw/2dsb2JhbACBUdkMhCoE X-IronPort-AV: E=Sophos;i="4.44,531,1249223400"; d="scan'208";a="426343906" Received: from ppp121-45-133-112.lns11.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.133.112]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Oct 2009 20:18:23 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id D17E94F8F3 for ; Fri, 9 Oct 2009 20:18:22 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1C-1SV4sxmTz for ; Fri, 9 Oct 2009 20:18:22 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id EA9174F8FD; Fri, 9 Oct 2009 20:18:21 +1030 (CST) Date: Fri, 9 Oct 2009 20:18:21 +1030 From: Ron To: codec@ietf.org Message-ID: <20091009094821.GG24163@audi.shelbyville.oz> References: <20091009020049.91404eej4de6p0ap@mail.skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091009020049.91404eej4de6p0ap@mail.skype.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 09:47:04 -0000 Hi, On Fri, Oct 09, 2009 at 02:00:49AM -0700, Koen Vos wrote: > Mikael, > > My view on integrating jitter buffer and codec: > > The integration is best done through an interface that lets the > decoder indicate to the jitter buffer what state the audio signal is > in, and lets the jitter buffer tell the decoder what action to take. > For example, if the jitter buffer wants to accelerate the decoding > of packets, it should (try to) wait until the decoder signals a > silent period, or at least a stationary part in the signal, and then > tell the decoder to compress the audio signal. The interface needs > to pass just a few parameters in both directions for a tight > integration between decoder and jitter buffer. Why should the jitter buffer presuppose to know when it would be a good time for the codec to compress? Shouldn't the jitter buffer just be giving the codec stats on dataflow that it can parameterise how it sees best? I agree both parties need to be talking about what those stats and parameters need to be though. Cheers, Ron From lars.eggert@nokia.com Fri Oct 9 04:34:17 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792F93A68BE for ; Fri, 9 Oct 2009 04:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 wL2YR3UiVi+j for ; Fri, 9 Oct 2009 04:34:16 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 2D4823A6A5F for ; Fri, 9 Oct 2009 04:34:08 -0700 (PDT) Received: from [10.180.41.32] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n99BZdMm051624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Oct 2009 14:35:40 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Lars Eggert In-Reply-To: Date: Fri, 9 Oct 2009 14:35:29 +0300 Content-Transfer-Encoding: 7bit Message-Id: <613AC137-AD55-4B7B-8861-220B6E549B0B@nokia.com> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [212.213.221.39]); Fri, 09 Oct 2009 14:35:40 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 11:34:17 -0000 Hi, On 2009-10-9, at 9:52, Mikael Abrahamsson wrote: > I have earlier proposed that the full solution should be able to > cope with > 10% packet loss and 1.5-2 seconds of jitter. I'm not aware of any Internet paths where such conditions would be considered normal. As such I question why such cases should be supported as a requirement. (Obviously, if a solution happened to work under such conditions *while also* having negligible overhead under normal conditions, that'd be fine - but I'm simply not sure this can be done.) Lars From swmike@swm.pp.se Fri Oct 9 05:21:06 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4029328C111 for ; Fri, 9 Oct 2009 05:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.211, 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 U8Epew8QrNTr for ; Fri, 9 Oct 2009 05:21:05 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 6214B28C0F9 for ; Fri, 9 Oct 2009 05:21:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6263A9F; Fri, 9 Oct 2009 14:22:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6108B9C for ; Fri, 9 Oct 2009 14:22:47 +0200 (CEST) Date: Fri, 9 Oct 2009 14:22:47 +0200 (CEST) From: Mikael Abrahamsson To: "codec@ietf.org" In-Reply-To: <613AC137-AD55-4B7B-8861-220B6E549B0B@nokia.com> Message-ID: References: <613AC137-AD55-4B7B-8861-220B6E549B0B@nokia.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 12:21:06 -0000 On Fri, 9 Oct 2009, Lars Eggert wrote: > I'm not aware of any Internet paths where such conditions would be considered > normal. During weeks of operation after the tsunami, I saw 7% listed as average packet loss for certain networks in the far east. Couple this with some wireless network and you have prolonged situations of these conditions. Of course this is not good or normal, but it's not very uncommon to see these adverse conditions. > As such I question why such cases should be supported as a requirement. > (Obviously, if a solution happened to work under such conditions *while > also* having negligible overhead under normal conditions, that'd be fine > - but I'm simply not sure this can be done.) It's my strong belief that if this is not something that is aimed for, then we'll end up with network requirements shown to be unrealistic in real life. 20ms jitter buffer and 0.1% packet loss as some implementations require, ie make the application dictate what the network should do instead of trying to adapt the application to real world network characteristics. -- Mikael Abrahamsson email: swmike@swm.pp.se From hsinnrei@adobe.com Fri Oct 9 06:38:04 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FD828C11B for ; Fri, 9 Oct 2009 06:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.15 X-Spam-Level: X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLzDUt6bN1ME for ; Fri, 9 Oct 2009 06:38:03 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by core3.amsl.com (Postfix) with ESMTP id 77C6A28C0DD for ; Fri, 9 Oct 2009 06:38:02 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKSs89H3jT8zsbvhmcl8u4mlFXaeirmVpO@postini.com; Fri, 09 Oct 2009 06:39:48 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n99DdfX3022437; Fri, 9 Oct 2009 06:39:42 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n99DddY2029082; Fri, 9 Oct 2009 06:39:40 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Fri, 9 Oct 2009 06:39:39 -0700 From: Henry Sinnreich To: Mikael Abrahamsson , "codec@ietf.org" Date: Fri, 9 Oct 2009 06:39:36 -0700 Thread-Topic: [codec] proposed charter Thread-Index: AcpI2zt2cznh31chSFmO8XL+9OF6yAACrVwx Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6F4A7486302hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 13:38:04 -0000 --_000_C6F4A7486302hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is fortunate this point was discussed. Designing for 7% packet loss seems to be clearly a non-objective for a high= performance voice codec. Over such networks, IM is much more adequate. My personal two cents, Henry On 10/9/09 7:22 AM, "Mikael Abrahamsson" wrote: On Fri, 9 Oct 2009, Lars Eggert wrote: > I'm not aware of any Internet paths where such conditions would be consid= ered > normal. During weeks of operation after the tsunami, I saw 7% listed as average packet loss for certain networks in the far east. Couple this with some wireless network and you have prolonged situations of these conditions. Of course this is not good or normal, but it's not very uncommon to see these adverse conditions. > As such I question why such cases should be supported as a requirement. > (Obviously, if a solution happened to work under such conditions *while > also* having negligible overhead under normal conditions, that'd be fine > - but I'm simply not sure this can be done.) It's my strong belief that if this is not something that is aimed for, then we'll end up with network requirements shown to be unrealistic in real life. 20ms jitter buffer and 0.1% packet loss as some implementations require, ie make the application dictate what the network should do instead of trying to adapt the application to real world network characteristics. -- Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C6F4A7486302hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] proposed charter It is fortunate this point was discussed.

Designing for 7% packet loss seems to be clearly a non-objective for a high= performance voice codec.
Over such networks, IM is much more adequate.

My personal two cents,

Henry


On 10/9/09 7:22 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:

On Fri, 9 Oct 2009, Lars Eggert wrote:

> I'm not aware of any Internet paths where such conditions would be con= sidered
> normal.

During weeks of operation after the tsunami, I saw 7% listed as average
packet loss for certain networks in the far east. Couple this with some
wireless network and you have prolonged situations of these conditions. Of<= BR> course this is not good or normal, but it's not very uncommon to see these<= BR> adverse conditions.

> As such I question why such cases should be supported as a requirement= .
> (Obviously, if a solution happened to work under such conditions *whil= e
> also* having negligible overhead under normal conditions, that'd be fi= ne
> - but I'm simply not sure this can be done.)

It's my strong belief that if this is not something that is aimed for,
then we'll end up with network requirements shown to be unrealistic in
real life. 20ms jitter buffer and 0.1% packet loss as some implementations<= BR> require, ie make the application dictate what the network should do
instead of trying to adapt the application to real world network
characteristics.

--
Mikael Abrahamsson    email: sw= mike@swm.pp.se
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C6F4A7486302hsinnreiadobecom_-- From swmike@swm.pp.se Fri Oct 9 07:17:29 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC183A6961 for ; Fri, 9 Oct 2009 07:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 8P150U9pamTp for ; Fri, 9 Oct 2009 07:17:28 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 409F73A690E for ; Fri, 9 Oct 2009 07:17:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 991219F; Fri, 9 Oct 2009 16:19:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 971ED9C; Fri, 9 Oct 2009 16:19:10 +0200 (CEST) Date: Fri, 9 Oct 2009 16:19:10 +0200 (CEST) From: Mikael Abrahamsson To: Henry Sinnreich In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 14:17:29 -0000 On Fri, 9 Oct 2009, Henry Sinnreich wrote: > It is fortunate this point was discussed. Yes. > Designing for 7% packet loss seems to be clearly a non-objective for a high performance voice codec. Why? Is there a concrete technical reason why it can't be done? Over these kinds of networks you'll see lots of jitter anyhow, is there a concrete technical reason why one can't make sound good enough for the other end to understand what is being said even at 10% packet loss with 200ms buffert? If you send one packet every 20ms, 10% packet loss means you're losing one packet every 200ms (on average). > Over such networks, IM is much more adequate. I think people want to have the option to speak to each other if they can, otherwise they might as well use morse code with long wave radios, it's also an "adequate" means of communication, very resiliant. -- Mikael Abrahamsson email: swmike@swm.pp.se From dbogdanovic@counterpath.com Fri Oct 9 07:49:15 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEA63A67B1 for ; Fri, 9 Oct 2009 07:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMt0kuiMtZpa for ; Fri, 9 Oct 2009 07:49:14 -0700 (PDT) Received: from relay.ihostexchange.net (relay.ihostexchange.net [66.46.182.54]) by core3.amsl.com (Postfix) with ESMTP id 3EA0128C16C for ; Fri, 9 Oct 2009 07:48:48 -0700 (PDT) Received: from VMBX106.ihostexchange.net ([192.168.3.6]) by HUB104.ihostexchange.net ([66.46.182.54]) with mapi; Fri, 9 Oct 2009 10:50:32 -0400 From: Dean Bogdanovic To: Mikael Abrahamsson Date: Fri, 9 Oct 2009 10:50:31 -0400 Thread-Topic: [codec] proposed charter Thread-Index: AcpI79nDL9wMIVeaQQehY+28h8NLcA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 09 Oct 2009 07:55:13 -0700 Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 14:49:15 -0000 I don't think that IM as always much more adequate. In emergency =20 situations, where time is essential, voice is most efficient =20 communication method and unfortunately in such situations networks =20 have high packetloss and jitter. Dean On Oct 9, 2009, at 10:19 AM, Mikael Abrahamsson wrote: > On Fri, 9 Oct 2009, Henry Sinnreich wrote: > >> It is fortunate this point was discussed. > > Yes. > >> Designing for 7% packet loss seems to be clearly a non-objective =20 >> for a high performance voice codec. > > Why? Is there a concrete technical reason why it can't be done? Over =20 > these > kinds of networks you'll see lots of jitter anyhow, is there a =20 > concrete > technical reason why one can't make sound good enough for the other =20 > end to > understand what is being said even at 10% packet loss with 200ms =20 > buffert? > If you send one packet every 20ms, 10% packet loss means you're =20 > losing one > packet every 200ms (on average). > >> Over such networks, IM is much more adequate. > > I think people want to have the option to speak to each other if =20 > they can, > otherwise they might as well use morse code with long wave radios, =20 > it's > also an "adequate" means of communication, very resiliant. > > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From lars.eggert@nokia.com Fri Oct 9 09:00:57 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FAA28C112 for ; Fri, 9 Oct 2009 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 7KjA--u8aWdV for ; Fri, 9 Oct 2009 09:00:57 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id A3AA228C15D for ; Fri, 9 Oct 2009 09:00:56 -0700 (PDT) Received: from [IPv6:2001:14b8:18f::225:ff:fe45:eccf] ([IPv6:2001:14b8:18f:0:225:ff:fe45:eccf]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n99G2SQ1067460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 9 Oct 2009 19:02:29 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-61--228446904; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Fri, 9 Oct 2009 19:02:23 +0300 Message-Id: <93CEE951-B755-48D4-8BC5-27E4395EA3B8@nokia.com> References: To: Dean Bogdanovic X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Fri, 09 Oct 2009 19:02:29 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 16:00:57 -0000 --Apple-Mail-61--228446904 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 2009-10-9, at 17:50, Dean Bogdanovic wrote: > I don't think that IM as always much more adequate. In emergency > situations, where time is essential, voice is most efficient > communication method and unfortunately in such situations networks > have high packetloss and jitter. My personal contribution to RFC1925bis, should it ever be published, will be Eggert's law: any IETF effort can be derailed by putting it into an emergency services context. :-) Lars --Apple-Mail-61--228446904 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAwOTE2MDIyNFowIwYJKoZIhvcNAQkEMRYEFCf6lGbRBH3KJ+rasx9qgvKNoA5bMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQB5zrUCHrrx9oy+ss8UC85eA4typ2cMtNSIDpMZ6CMUZFwzmPUIpxt3WJ2Nri8mEwWWEtWl Wa39bXLb01nyZ+Hjux0ucRW2lxaWPhdkMCbqx45MZAq+Vi2HkAr5yOQfAYKPcJipfG95pCjUmcJ2 xw+Lb8VoaCK2wCyLl3JRb7T35qrA7rRpcjrVFrv7ntmUDxWujItQeqn5KVKXwfc6+sS5mj6tYjVB qD66BOhmpeXY4QNiYoDssk8iEARQ+fuBqH5cSR908nlmmRaNUNeF8s7G/E9QvSW+m9m9fvAKXHQa t4wcnHxXls1xocvImu4hfhRYUKtAJtrqZ7rXMT8Fz9XvAAAAAAAA --Apple-Mail-61--228446904-- From jean-marc.valin@octasic.com Fri Oct 9 10:42:11 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653AA28C1DB for ; Fri, 9 Oct 2009 10:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 whpqiwwF9FPk for ; Fri, 9 Oct 2009 10:42:09 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 0957128C1E0 for ; Fri, 9 Oct 2009 10:42:08 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 13:43:52 -0400 Message-ID: <4ACF7658.2000304@octasic.com> Date: Fri, 09 Oct 2009 13:43:52 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mikael Abrahamsson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Oct 2009 17:43:52.0814 (UTC) FILETIME=[110D70E0:01CA4908] Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 17:42:11 -0000 I think it's important here to distinguish between the charter and the precise requirements. The intent of the charter is to define the kind of problem we're trying to solve, whereas the requirements I-D should have all the details. Regarding the charter, the intent of objectives 2, 3 and 4 was to specify the operating environment we were primarily targeting, which is the Internet. Also, the main reason for mentioning RTP/SIP/SDP/SRTP/XMPP was to acknowledge that these protocols are important for the IETF and thus that the codec designers should ensure that the codec fits well with these protocols and not to do anything that would create interoperability issues. As Henry pointed out, this can be interpreted as implying that we would not consider other protocols on the Internet, but this was not the intent here. We should probably make that clearer. About packet loss, it's obviously not possible to make a codec that produces intelligible speech when you have gaps of 1 second in the transmission. I personally believe that it's not even necessary to target a particular loss rate (as many pointed out, it varies a lot), but that it's more about what to prioritize. For a codec that operates on the Internet, I believe it is for example more useful to improve the loss robustness than to squeeze a few more bits out of the bit-stream, especially considering all the header overhead. On other networks (especially the ones where bandwidth is very expensive), the trade-offs could be different. Jean-Marc Mikael Abrahamsson wrote: > On Fri, 9 Oct 2009, Henry Sinnreich wrote: > >> It is fortunate this point was discussed. > > Yes. > >> Designing for 7% packet loss seems to be clearly a non-objective for a >> high performance voice codec. > > Why? Is there a concrete technical reason why it can't be done? Over > these kinds of networks you'll see lots of jitter anyhow, is there a > concrete technical reason why one can't make sound good enough for the > other end to understand what is being said even at 10% packet loss with > 200ms buffert? If you send one packet every 20ms, 10% packet loss means > you're losing one packet every 200ms (on average). > >> Over such networks, IM is much more adequate. > > I think people want to have the option to speak to each other if they > can, otherwise they might as well use morse code with long wave radios, > it's also an "adequate" means of communication, very resiliant. > From koen.vos@skype.net Fri Oct 9 15:32:10 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6E028C17E for ; Fri, 9 Oct 2009 15:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 AYck0wQzc3x9 for ; Fri, 9 Oct 2009 15:32:10 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 9304E3A699C for ; Fri, 9 Oct 2009 15:32:09 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E20C16064E489; Fri, 9 Oct 2009 23:33:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=KsZ33Hluq2bc aZalBi+SqINhpig=; b=XX2xTAGyvv+K8Rk8SiU5XaUlpfzVR3ye5P6XcciknVkO LIaLwjpyNgtOulopgKsZE9NvHeUvC8Grbogq4wJcPte6mHFw0lKrCV2NNzp7R83J 6r0SXVdJmsSzHpIJ5kPpi/2FJD4oim23TB00U8azSGp2aGDHd6fVNM71v3pZtjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=aiaULsF56AbEAv1TYvuE 4iiG53dx6OOmwvRZn2LNInItXRg0OOPvGETPHmlgwl5bEdZNU9UZR61ge9xH5S/O SMI8Gv7B8QfzctAf+WG1T+3OUgOL2L1wTnb5pxWbMbBvnW8f8Lhx/E9+7J2qZ5aJ nBPrCpjLLEX9ZEP1Kpiz6qU= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E04F76064E3A6; Fri, 9 Oct 2009 23:33:53 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-ockZjKy3lh; Fri, 9 Oct 2009 23:33:53 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id CE3896064E3BC; Fri, 9 Oct 2009 23:33:53 +0100 (IST) Received: from 71.141.142.127 ([71.141.142.127]) by mail.skype.net (Horde Framework) with HTTP; Fri, 09 Oct 2009 15:33:53 -0700 Message-ID: <20091009153353.150068gcyfgwjmtt@mail.skype.net> Date: Fri, 09 Oct 2009 15:33:53 -0700 From: Koen Vos To: Ron References: <20091009020049.91404eej4de6p0ap@mail.skype.net> <20091009094821.GG24163@audi.shelbyville.oz> In-Reply-To: <20091009094821.GG24163@audi.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:32:11 -0000 Quoting Ron : > Why should the jitter buffer presuppose to know when it would be a > good time for the codec to compress? State-of-the-art jitter buffers adaptively vary the speed of decoding packets to balance delay and packet loss when jitter changes. Accelerating or slowing down the decode speed can lead to audible artifacts however, and the jitter buffer should therefore be careful when to trigger such operations. To do this, the decoder should pass a measure of "perceptual sensitivity to time-scale modification" to the jitter buffer (a voice activity measure could be a first approximation). The jitter buffer then returns one of these commands to the decoder: 1. decode 2. conceal 3. decode + stretch 4. decode + compress All this is relevant and important. For example, 3G networks exhibit delay spikes of several seconds. Every few minutes the network just stops delivering packets, and then releases them in short order. Same for WiFi with delay spikes of up to a second (caused by the radio scanning for available access points). Quickly-adapting jitter buffering greatly helps with such non-stationary jitter. > Shouldn't the jitter buffer just be giving the codec stats on > dataflow that it can parameterise how it sees best? What kind of stats are you thinking of? The jitter buffer only needs the sensitivity measure from the decoder, and the codec developers are probably best at defining this. koen. From hoene@uni-tuebingen.de Fri Oct 9 16:10:04 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C503A68FF for ; Fri, 9 Oct 2009 16:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.116 X-Spam-Level: X-Spam-Status: No, score=-4.116 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIqh4Dm8jD+i for ; Fri, 9 Oct 2009 16:10:03 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id D4ECB28C1B4 for ; Fri, 9 Oct 2009 16:10:02 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-092-074-171-079.pools.arcor-ip.net [92.74.171.79]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n99NBbhn006672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Oct 2009 01:11:43 +0200 From: "Christian Hoene" To: "'Koen Vos'" , "'Ron'" References: <20091009020049.91404eej4de6p0ap@mail.skype.net> <20091009094821.GG24163@audi.shelbyville.oz> <20091009153353.150068gcyfgwjmtt@mail.skype.net> In-Reply-To: <20091009153353.150068gcyfgwjmtt@mail.skype.net> Date: Sat, 10 Oct 2009 01:11:36 +0200 Message-ID: <000401ca4935$deaec350$9c0c49f0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpJMJ+yD089PaEcTPeUL3Y0t5cjgwABEb5Q Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.35; VDF: 7.1.6.95; host: mx05); id=24545-gf3Nkj Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 23:10:04 -0000 > > Why should the jitter buffer presuppose to know when it would be a > > good time for the codec to compress? > > State-of-the-art jitter buffers adaptively vary the speed of decoding > packets to balance delay and packet loss when jitter changes. > Accelerating or slowing down the decode speed can lead to audible > artifacts however, and the jitter buffer should therefore be careful > when to trigger such operations. > > To do this, the decoder should pass a measure of "perceptual > sensitivity to time-scale modification" to the jitter buffer (a voice > activity measure could be a first approximation). The jitter buffer > then returns one of these commands to the decoder: > 1. decode > 2. conceal > 3. decode + stretch > 4. decode + compress Allow me to point out our recent report addressing the interface and those PLC and strech/compress commands. http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/hoene_sb c2009.pdf Chapter 3 contains the speech receiver and dejittering part that might be relevant for this discussion. Christian From hoene@uni-tuebingen.de Sat Oct 10 01:14:28 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0916728C0F5 for ; Sat, 10 Oct 2009 01:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hY11ok0axL9S for ; Sat, 10 Oct 2009 01:14:26 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 8B57428C0D8 for ; Sat, 10 Oct 2009 01:14:25 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-218-212-013.pools.arcor-ip.net [94.218.212.13]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9A8G04m016512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Oct 2009 10:16:06 +0200 From: "Christian Hoene" To: "'Lars Eggert'" , "'Dean Bogdanovic'" , "'Mikael Abrahamsson'" References: <93CEE951-B755-48D4-8BC5-27E4395EA3B8@nokia.com> In-Reply-To: <93CEE951-B755-48D4-8BC5-27E4395EA3B8@nokia.com> Date: Sat, 10 Oct 2009 10:16:02 +0200 Message-ID: <000301ca4981$ecdc7480$c6955d80$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpI+fgapo1H5wUiQhaJRJLRepr/bgAhCI6Q Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 08:14:28 -0000 Dear Lars Eggert, Dean Bogdanovic and Mikael Abrahamsson, allow me to raise my voice on the issues of supporting a good voice transmission even under harsh conditions. > > I have earlier proposed that the full solution should be able to > > cope with > > 10% packet loss and 1.5-2 seconds of jitter. >=20 > I'm not aware of any Internet paths where such conditions would be > considered normal. As such I question why such cases should be > supported as a requirement. (Obviously, if a solution happened to work > under such conditions *while also* having negligible overhead under > normal conditions, that'd be fine - but I'm simply not sure this can > be done.) Probably there are about a billion phone calls each days world-wide. If = the phone systems works well only on for normal conditions (e.g. 99,9% of = them), this would result in about one million unhappy users each day. In = addition, service centers would kept busy. Thus, if possible one should = concentrate on providing a well working solution even for most of remaining 0,099...% percentage of conditions---as long as the technical overhead is not too high. Let me point out a recent research project by Prof. Dr. J=F6rg Ott, HKK Helsinki called DT Talkie. = http://www.netlab.tkk.fi/tutkimus/dtn/dttalkie/ It is a phone application for delay tolerant networks and J=F6rg told me = that it was the job of a student during a seminar.=20 Knowing these results, I described the requirements for a reliable = system and sketched a rough technical solution in http://www.ietf.org/id/draft-hoene-avt-acs-requirements-00.txt=20 Please read Section 2.4 and 3.2. Having such as Push-To-Talk like solution would also help to address = other problems described by Mikael and Koes, Mikael: > But the two major types I see that needs to be handled are: >=20 > Wireless networks with ARQ such as 802.11, 3GPP and alike. These = typically > can induce 1-2 seconds of jitter, but with low or no packet loss. >=20 > Routers/switches that do buffering and which use either FIFO/taildrop = or > some kind of more intelligent buffer management such as (W)RED or = alike. > These might drop a few percent of packets (usually never more as TCP = backs > off a lot at these packet drop rates and thus the links are usually = not > loaded more than what causes a few percent packet loss) plus induce = jitter > as other traffic affects this. Routers typically never buffer packets = more > than 600ms, often much lower, thus jitter is less unless there are > multiple congested links in a row. Koen: > All this is relevant and important. For example, 3G networks exhibit > delay spikes of several seconds. Every few minutes the network just > stops delivering packets, and then releases them in short order. Same > for WiFi with delay spikes of up to a second (caused by the radio > scanning for available access points). Quickly-adapting jitter > buffering greatly helps with such non-stationary jitter. Of course, providing a DT-Talkie or Push-To-Talk application is not the = task of a codec. Rather, it should be standardized in the AVT/transport = group. However, a codec could support those applications with two features: 1. A highly bandwidth-efficient transmission of speech (while taking advantage of high algorithmic delays and very large frame sizes) 2. Support of discontinues transmission modes to detect voice activity = and compress silence and background noise. With best regards, Christian Hoene From ron@debian.org Sat Oct 10 06:24:07 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A24E28C0E9 for ; Sat, 10 Oct 2009 06:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 98MxizRvzdPb for ; Sat, 10 Oct 2009 06:24:06 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by core3.amsl.com (Postfix) with ESMTP id 4D09A28C0DC for ; Sat, 10 Oct 2009 06:24:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EABon0Ep5LYVw/2dsb2JhbACBUtcCgiYXgXAE X-IronPort-AV: E=Sophos;i="4.44,537,1249223400"; d="scan'208";a="426715255" Received: from ppp121-45-133-112.lns11.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.133.112]) by ipmail01.adl6.internode.on.net with ESMTP; 10 Oct 2009 23:55:49 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 0C3A44F8F3 for ; Sat, 10 Oct 2009 23:55:48 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uOQkXt9psPFh for ; Sat, 10 Oct 2009 23:55:47 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 147B64F8FD; Sat, 10 Oct 2009 23:55:47 +1030 (CST) Date: Sat, 10 Oct 2009 23:55:47 +1030 From: Ron To: codec@ietf.org Message-ID: <20091010132547.GH24163@audi.shelbyville.oz> References: <20091009020049.91404eej4de6p0ap@mail.skype.net> <20091009094821.GG24163@audi.shelbyville.oz> <20091009153353.150068gcyfgwjmtt@mail.skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091009153353.150068gcyfgwjmtt@mail.skype.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 13:24:07 -0000 On Fri, Oct 09, 2009 at 03:33:53PM -0700, Koen Vos wrote: > Quoting Ron : > > >Why should the jitter buffer presuppose to know when it would be a > >good time for the codec to compress? > > State-of-the-art jitter buffers adaptively vary the speed of > decoding packets to balance delay and packet loss when jitter > changes. Fundamentally, elastic buffers are pretty simple and it's probably best to try to keep them that way. They need enough tension to stay as small as possible when they aren't under stress, and enough elasticity to quickly stretch without ever 'snapping'. Where 'snapping' in our case is a 'lost' packet that we've given up on ever receiving. That's pretty much all they really need to do to fulfil their role in these systems. At least for the purpose of examining how they interact with codecs. > Accelerating or slowing down the decode speed can lead to > audible artifacts however, That's the bit where this is a problem in many current codecs, indeed. > and the jitter buffer should therefore be careful when to trigger > such operations. and that's I think where you and I first disagree. And where Christian and I see a bit more eye to eye. But it may just be a choice of words and polarities :) I don't think the jitter buffer should be 'trigerring' these things based on input from the codec -- I think the jitter buffer should just provide rate information to the codec, and leave it to the codec to decide when and how to act to meet the longer term goals that we set for it. As gradually as it needs to, to avoid abrupt artifacts. > To do this, the decoder should pass a measure of "perceptual > sensitivity to time-scale modification" to the jitter buffer (a > voice activity measure could be a first approximation). The jitter > buffer then returns one of these commands to the decoder: > 1. decode > 2. conceal > 3. decode + stretch > 4. decode + compress > > All this is relevant and important. Yes, but I think that saying it is _all_ that is relevant and important, supposes too much that new codecs will be just like the old ones in all the ways that this group is forming to solve :) 'conceal' is a rather rough approximation for many different actions that could be taken in many different sets of circumstances. I think I'd rather see the elastic buffer make available to the codec (and other parts of the system) some simple information along the lines of: 1. is it stretching or contracting. (but codec need not not care) 2. does it want the codec to stretch or contract (more/faster/slower)? 3. how far away from 'snapping' are we at present, (ie. how long until the first MIA packet, or the end of the buffer) and how big will the hole be when we do. Then the clever codec people can work their best magic armed with some small foreknowledge of 'the future', that the delay in the buffer can make available to them. Trying to tell the codec which frames it should drop samples in, based on information it gave you as an abstract hint, seems like too many round trips and too much information loss. Letting it know when it is going too fast, or too slow, or when it should just hum to itself for a while seems like a much more flexible way to achieve the same goals. It surely knows better than any outside agent where and when it can fudge a few samples that most people won't notice. It may be able to catch up more aggressively on some frames than the elastic buffer requested, and amortise that on other frames it can't adjust so far, for the same or better average rate of change to the buffer size. Regions of "perceptual sensitivity to time-scale modification" don't seem like something that would always neatly respect packet boundaries, so that seems like too coarse a sieve to be optimal, yet the packet buffer can act upon nothing finer. > For example, 3G networks exhibit > delay spikes of several seconds. Every few minutes the network just > stops delivering packets, and then releases them in short order. > Same for WiFi with delay spikes of up to a second (caused by the > radio scanning for available access points). Quickly-adapting jitter > buffering greatly helps with such non-stationary jitter. Ok. That's reality, so we can't argue with that, and we all agree that when delays are that long most interactive applications are doomed anyhow. So the interesting question is how do we deal with that and give the user as much of what they want as we can anyway. I see two sides to it: 1. The elastic buffer must stretch to fit the expected maximum latency. You know you'll 'never' lose packets if you just wait long enough for them, but some of them may be very, very, late. But you also know that once the next load arrives, you probably won't need to wait that long again for a while -- so you can apply a lot of tension to contracting it toward 'realtime' again as quickly as possible. 2. Sometimes you will really lose packets. And at some point you just have to give up on those. No amount of further stretching is likely to help you. But if you gave the codec early warning about the probability of it not arriving, it will have had time to plan its best action for if it really doesn't come, and help you to wait for it as long as possible in case it still does, by stretching out the data you do have for as long as is reasonably can. > What kind of stats are you thinking of? The jitter buffer only needs > the sensitivity measure from the decoder, and the codec developers > are probably best at defining this. If the elastic buffer simply tells the codec when it needs to stretch or shrink, then that covers the first case above. As soon as the first late packets are observed you tell the codec to start slowing down, then more and more urgently as you realise you're really going to underflow very soon. Eventually you fade to noise. Once the burst comes in, you tell the codec to hurry things up for a while, because reality is back and it's not going to wait. In the case of speech, the user experience is that words simply started slowing down [then stopped for a while] then_came_more_ quickly_for_a_bit before it was all normal again. But the really important bit is that you never actually mi d anything which was said. Which is mu h m e annoy g, and hard to comprehend when it happens. In the case of a truly lost individual packet, an intelligent elastic buffer could warn the codec this was to be expected N frames from now, and give it time to prepare a synthesis if it thought it could mumble its way through, or fade to silence gracefully if there will be too many missing to fake it. Again early stretching of the buffer and the codec play rate can buy you a little more time for it to arrive than would be expected from the "normal rate" of what you currently have backed up in the buffer. So to bring it back to what is really relevant here, what does an elastic buffer need from the codec? Probably not much. A way to smoothly stretch or shrink time by some variable proportion, to balance the tension in the buffer. A way to gracefully fade to comfort noise and back again when the signal is interrupted. That's about it. What does the codec need from the elastic buffer? Forewarning of when the buffer is about to 'snap' seems like the main information that it could make some use of. Anything else? I'm not really sure the relationship between these two components actually needs to be much more complicated or formal than that. What can't we do with just those simple controls? We get a "double-ended" elastic buffer that can stretch in both directions, and require nothing more than that the codec give us finer control over the average output sample rate than the traditional quantum leaps from one rate to the next. If the interactive music use case, or large crowd conferences, become viable, the idea of only being able to make these sort of adjustments during 'silence periods' must be steered well clear of, we need to be able to steal or pad every sample that we can when necessary, since there is no silence on the scale of a "normal" 1-to-1 phone conversation. Am I missing something here? Otherwise I think what we need for this will mostly be covered by the time-stretching considerations of the codec, no? Ron From hoene@uni-tuebingen.de Tue Oct 13 02:13:30 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789E628C2B1 for ; Tue, 13 Oct 2009 02:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfbn8NvJ8bBU for ; Tue, 13 Oct 2009 02:13:29 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id E6E3C28C2C1 for ; Tue, 13 Oct 2009 02:13:27 -0700 (PDT) Received: from hoeneLenovoT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9D9DQpu012144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Oct 2009 11:13:27 +0200 From: "Christian Hoene" To: "'Jean-Marc Valin'" References: <20091009020049.91404eej4de6p0ap@mail.skype.net> <20091009094821.GG24163@audi.shelbyville.oz> <20091009153353.150068gcyfgwjmtt@mail.skype.net> <000401ca4935$deaec350$9c0c49f0$@de> <4AD3E4CC.4080100@usherbrooke.ca> In-Reply-To: <4AD3E4CC.4080100@usherbrooke.ca> Date: Tue, 13 Oct 2009 11:13:27 +0200 Message-ID: <007501ca4be5$6cefa880$46cef980$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpLrEW9l3guo5FQTNyM8/Okvt5iRAANSVuQ Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 09:13:30 -0000 HI Jean-Marc Valin, > Had a quick look at the results section of your document (sorry, = didn't > read any of the details). From what I read, I have the following = comments: > 1) The mono results appear a bit low compared to what I usually obtain > with my own testset and PQevalaudio (-0.5 at 64 kb/s), but that could = be > explained by a different testset and evaluation tool. I would recommend to use the original PEAQ version from Opticom.=20 > 2) The stereo results are mostly consistent with the mono results > because of a bug in the 0.6.0 and 0.6.1 versions (which is now fixed = in > git). I'm hoping that 0.7.0 will be the first version to have usable stereo. Then, I will start the scripts again.=20 > 3) The SBC results in stereo look a bit suspicious to me. It seems = like > the bit-rate only increases by ~10 kb/s for the same quality, which is = a > bit surprising. Is it possible that your test samples are almost mono? = Most of the sample item contain single instruments. Only the = =93refryc=94 (jazz music by Ry Cooder) and =93refsop01=94 (opera) sample items contain more = complex content. I checked for all used items whether left and right channel = differ (they did) but still better sample items could be used for stereo (e.g. = old Beatles songs). > I > also heard that PEAQ didn't evaluate the stereo image at all. Yesterday, I got the PEMO-Q audio assessment software from = www.hoertest.de. I will check whether it outperforms PEAQ.=20 Christian >=20 > Jean-Marc >=20 > Christian Hoene a =E9crit : > >>> Why should the jitter buffer presuppose to know when it would be a > >>> good time for the codec to compress? > >> State-of-the-art jitter buffers adaptively vary the speed of = decoding > >> packets to balance delay and packet loss when jitter changes. > >> Accelerating or slowing down the decode speed can lead to audible > >> artifacts however, and the jitter buffer should therefore be = careful > >> when to trigger such operations. > >> > >> To do this, the decoder should pass a measure of "perceptual > >> sensitivity to time-scale modification" to the jitter buffer (a = voice > >> activity measure could be a first approximation). The jitter buffer > >> then returns one of these commands to the decoder: > >> 1. decode > >> 2. conceal > >> 3. decode + stretch > >> 4. decode + compress > > > > Allow me to point out our recent report addressing the interface and those > > PLC and strech/compress commands. > > http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/hoene= _sb > > c2009.pdf > > Chapter 3 contains the speech receiver and dejittering part that = might be > > relevant for this discussion. > > > > Christian > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > From stefan.sayer@iptego.com Tue Oct 13 04:50:11 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CFE83A67E5 for ; Tue, 13 Oct 2009 04:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cB6frNlmLdv for ; Tue, 13 Oct 2009 04:50:08 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 167CC28C15E for ; Tue, 13 Oct 2009 04:50:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id C725D1154093; Tue, 13 Oct 2009 13:50:07 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpVlnacpu8VS; Tue, 13 Oct 2009 13:50:07 +0200 (CEST) Received: from [192.168.5.106] (g230190101.adsl.alicedsl.de [92.230.190.101]) by mail.iptego.net (Postfix) with ESMTPSA id 4C9EB1154092; Tue, 13 Oct 2009 13:50:07 +0200 (CEST) Message-ID: <4AD4696E.5060407@iptego.com> Date: Tue, 13 Oct 2009 13:50:06 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Christian Hoene References: <20091009020049.91404eej4de6p0ap@mail.skype.net> <20091009094821.GG24163@audi.shelbyville.oz> <20091009153353.150068gcyfgwjmtt@mail.skype.net> <000401ca4935$deaec350$9c0c49f0$@de> In-Reply-To: <000401ca4935$deaec350$9c0c49f0$@de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 11:50:11 -0000 o Christian Hoene [10/10/09 01:11]: >>> Why should the jitter buffer presuppose to know when it would be a >>> good time for the codec to compress? >> State-of-the-art jitter buffers adaptively vary the speed of decoding >> packets to balance delay and packet loss when jitter changes. >> Accelerating or slowing down the decode speed can lead to audible >> artifacts however, and the jitter buffer should therefore be careful >> when to trigger such operations. >> >> To do this, the decoder should pass a measure of "perceptual >> sensitivity to time-scale modification" to the jitter buffer (a voice >> activity measure could be a first approximation). The jitter buffer >> then returns one of these commands to the decoder: >> 1. decode >> 2. conceal >> 3. decode + stretch >> 4. decode + compress > > Allow me to point out our recent report addressing the interface and those > PLC and strech/compress commands. > http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/hoene_sb > c2009.pdf > Chapter 3 contains the speech receiver and dejittering part that might be > relevant for this discussion. I had a look on that chapter, and I think it gives interesting implementation simplification if the whole design is "pull based" (i.e. thought completely from the sink side). Specifically about the method and interface you describe in 3.2 i have a few comments: 1. It makes sense that a PLC in the codec would be employed not only for extrapolation, but also for interpolation (when packets after a gap are already received). 2. In order to not have excessive late loss, you have to start the audio sink with a time offset (timestamp offset relative to the receiver). Methods like the one you referenced from Liang et al [27] intend to minimize exactly this offset (which contributes to total latency, or mouth-to-ear delay), while keeping the expected late loss bounded (e.g. in [27] using L filter to estimate). Missing in your description is exactly this - how do you setup the offset to the sink in the first place, and how do you adapt it, e.g. if you notice changes in jitter, or notice clock skew ? 3. It appears that, if there is the need to (e.g. next audio not available), the time scale modification in your CDCD needs to slow down voice immediately, and do all on one audio block. A buffer based approach makes it possible, to *slowly* adapt the playout speed (and in both directions) this way this operation is less intrusive, because the amount of speed modification does not need to be that high; instead, a "longer-term goal" of playout buffer length can be set. Back to the topic on codec PLC and time scale interface, if the codec can optimize those two for the case of interpolation (which I don't know whether this is true, being not deeply into codec internals), I think it makes sense to consider this as requirement for the codec. About the question where the actual decision happens whether to stretch/compress or not, I think what your paper illustrates is that there are so many possibilities to design a dejitter/playout/plc buffer, and there are many factors that such a buffer might take into account, that it will be simpler to signal relevant voice characteristics parameters from the codec to the buffer, than the reverse. Best Regards Stefan Sayer [27] Y. J. Liang, N. Foerber, and B. Girod, Adaptive playout scheduling and loss concealment for voice communication over IP networks, IEEE Transactions on Multimedia, vol. 5, no. 4, pp. 532543, Dec. 2003. a version of this, optimized for high concurrent call count by predicting when to employ TD-WSOLA best, is implemented in SEMS (http://iptel.org/sems), see AmAdaptivePlayout in http://svn.berlios.de/wsvn/sems/trunk/core/AmPlayoutBuffer.cpp . > > Christian > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec -- Stefan Sayer VoIP Services stefan.sayer@iptego.com www.iptego.com IPTEGO GmbH Wittenbergplatz 1 10789 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann From Borilin@spiritdsp.com Wed Oct 14 02:09:05 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8788128C112 for ; Wed, 14 Oct 2009 02:09:05 -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 y37pKo1ALXsP for ; Wed, 14 Oct 2009 02:09:04 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 985B83A6903 for ; Wed, 14 Oct 2009 02:09:04 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9E995U9010027 for ; Wed, 14 Oct 2009 13:09:06 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) 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_01CA4CAD.F7B90570" Date: Wed, 14 Oct 2009 13:08:57 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP-MR I-D published Thread-Index: AcpMrfYmnytmA7wBTTSMZ2mSeErdNQ== From: "Slava Borilin" To: X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: [codec] IP-MR I-D published X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 09:09:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4CAD.F7B90570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, =20 This is to inform you that the new I-D is available, so now IP-MR codec as the IWAC candidate is also described - http://tools.ietf.org/search/draft-spiritdsp-ipmr-00=20 =20 best regards, Slava Borilin =20 ------_=_NextPart_001_01CA4CAD.F7B90570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

This is to inform you that the new I-D is = available, so now IP-MR codec as the IWAC candidate is also described - http://tool= s.ietf.org/search/draft-spiritdsp-ipmr-00

 

best regards,

Slava Borilin

 

------_=_NextPart_001_01CA4CAD.F7B90570-- From fluffy@cisco.com Wed Oct 14 23:28:41 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DC93A67A6 for ; Wed, 14 Oct 2009 23:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onotW6psR4Vk for ; Wed, 14 Oct 2009 23:28:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B888D3A6889 for ; Wed, 14 Oct 2009 23:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=334; q=dns/txt; s=sjiport06001; t=1255588124; x=1256797724; 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:=20Cullen=20Jennings=20|Subject: =20Question=20about=20scheduling=20CODEC=20BOF|Date:=20Th u,=2015=20Oct=202009=2000:28:42=20-0600|Message-Id:=20<2D 01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com>|To:=20codec @ietf.org|Mime-Version:=201.0=20(Apple=20Message=20framew ork=20v936)|Content-Transfer-Encoding:=207bit; bh=h2vD0emMohuwsCMZHNbz+Bmch3eZy6QJDJvbnCiD/9g=; b=C7UXXzI/yP8ZlB4rI2iuUIe9PAhH3SuEV67J1jc9XDzhVYxYFQoFeItC nsOYO2Sjtc1pShudh0tUmfPxyiX7uqh8QPleJowpKUbdzzw2q91BSQjxX OBnwHcZQlTcmALhlztZJnYIlfD5dWhN+QutPKbXgq4cMfTbDQZe+9tTHh U=; 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: ApoEAJNd1kqrRN+J/2dsb2JhbADAWphphDAEgVs X-IronPort-AV: E=Sophos;i="4.44,564,1249257600"; d="scan'208";a="409712507" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2009 06:28:43 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n9F6ShFI028992 for ; Thu, 15 Oct 2009 06:28:43 GMT Message-Id: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> From: Cullen Jennings To: codec@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 00:28:42 -0600 X-Mailer: Apple Mail (2.936) Subject: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 06:28:41 -0000 Andrew Malis wants to come to the CODEC BOF and he is an author of a PWE3 document. Currently PWE3 is scheduled at the same time the CODEC BOF. To resolve this the secretariat is considering moving the CODEC BOF to Friday Nov 13 from 13:00 to 15:15. If this is a problem for anyone, speak up quickly! Thanks, Cullen From koen.vos@skype.net Thu Oct 15 02:43:49 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5B23A6896 for ; Thu, 15 Oct 2009 02:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 nBIm+OYrngmp for ; Thu, 15 Oct 2009 02:43:49 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id D8BFB3A6879 for ; Thu, 15 Oct 2009 02:43:48 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 0E8826066551F; Thu, 15 Oct 2009 10:43:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=5fBu25XkyMVx 2+A+TX7Mu35PFrs=; b=fMwKGNY3SgUrrGPRcB8ZXCoOaD4+RqASchJ4JNFdOT4r VlCH9l5lG+IQZ/Y5kxkUCwjHDXwJFdN+Vz87OWJDY+Ih2x56azDis+pSseTbCMW+ iuOCyVOWIPkjW4Fa/1TwHcNe+v81lBUyucyQA+BV4p1CUPCZc5SBJbQecBG3Vjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=W4a7wcifa08tDb26rZ4j X3O/zVsPwKcO/lhrBVRFJsxNs1amxc+CwvVhELAo7qzV1UA32B7jbO6v30idyYgc JA9xWtBoG62L8Vauq0Yd9NSwaZmGffRyqUFxZ4ebPzN6qmjyLGIakygV7nXXfl4P hfYQ6PURM857epxyJv4TxBU= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 0B0046065CF78; Thu, 15 Oct 2009 10:43:51 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w77FsJz2LUg; Thu, 15 Oct 2009 10:43:50 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id EC8FD6065CFAC; Thu, 15 Oct 2009 10:43:50 +0100 (IST) Received: from 71.141.142.127 ([71.141.142.127]) by mail.skype.net (Horde Framework) with HTTP; Thu, 15 Oct 2009 02:43:50 -0700 Message-ID: <20091015024350.1183769j65waadw6@mail.skype.net> Date: Thu, 15 Oct 2009 02:43:50 -0700 From: Koen Vos To: Cullen Jennings References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> In-Reply-To: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:43:49 -0000 Five people from Skype, including myself, were planning to attend on Thursday and have made detailed arrangements that would be hard (or at least costly) to modify.. koen. Quoting Cullen Jennings : > > Andrew Malis wants to come to the CODEC BOF and he is an author of a > PWE3 document. Currently PWE3 is scheduled at the same time the > CODEC BOF. To resolve this the secretariat is considering moving the > CODEC BOF to Friday Nov 13 from 13:00 to 15:15. > > If this is a problem for anyone, speak up quickly! > > Thanks, Cullen > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From ron.even.tlv@gmail.com Thu Oct 15 03:39:31 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18B43A6824 for ; Thu, 15 Oct 2009 03:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.556, 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 FVCmPacvRw2J for ; Thu, 15 Oct 2009 03:39:30 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 9541C3A67E4 for ; Thu, 15 Oct 2009 03:39:30 -0700 (PDT) Received: by yxe30 with SMTP id 30so1110699yxe.29 for ; Thu, 15 Oct 2009 03:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=TCHATJGiII3tcH6AInEGtwXjN3CxBClStscYxnNj55c=; b=gfScCr+0PKTHAwlEf6suHSNGQrXV3QbayiYHYnC6kJxIwRfPO25X7sXz62TjthIbS0 HteG/Vdk2+3+Sr5cXrGwtKCfCSOr5VS+rfCtwyC8k42VBOmmNgRB/D+b4h3JRmPAdd4f qUc/M0Ah6W9HURXsjWKs8UCzIMM5osR80wYL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=TbioZIlHynYbdi6mQe+XPiNEBeMnXRaNZbezPnCKN1fQpv5gNP2q8XEwlLWOfDdIay SBoXwMba1lx0PBR1Bj4I4Uh1Ea1/ZaJ/sGpJVVMQptJi/svU7ZqA7O8NQDpJMryW58JM dSXK/rLpRqMPBg6Z9Ny3TC6Uu3aO92+diseaQ= Received: by 10.150.44.2 with SMTP id r2mr26865ybr.77.1255603170983; Thu, 15 Oct 2009 03:39:30 -0700 (PDT) Received: from YOUR6108 ([200.50.252.184]) by mx.google.com with ESMTPS id 20sm11665ywh.2.2009.10.15.03.39.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 03:39:29 -0700 (PDT) From: "rontlv" To: "'Cullen Jennings'" , References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> In-Reply-To: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> Date: Thu, 15 Oct 2009 12:39:31 +0200 Message-ID: <4ad6fbe1.1408c00a.427c.0055@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpNYMdWCNSZvtWtTz2Zm+7NvRkQCwAImGgg Content-Language: he Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 10:39:31 -0000 Hi, My view that it should whenever there are fewer other sessions. Apparently there is a big interest in this BOF. Last session on Friday looks good to me. It will show real interest. BTW: In Stockholm, at the Friday AVT session we had a good number of people since there was a real interest in the ECN work. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Thursday, October 15, 2009 8:29 AM > To: codec@ietf.org > Subject: [codec] Question about scheduling CODEC BOF > > > Andrew Malis wants to come to the CODEC BOF and he is an author of a > PWE3 document. Currently PWE3 is scheduled at the same time the CODEC > BOF. To resolve this the secretariat is considering moving the CODEC > BOF to Friday Nov 13 from 13:00 to 15:15. > > If this is a problem for anyone, speak up quickly! > > Thanks, Cullen > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4509 (20091015) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4509 (20091015) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From hsinnrei@adobe.com Thu Oct 15 06:24:45 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28DA28C0F3 for ; Thu, 15 Oct 2009 06:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaDghEn37X7i for ; Thu, 15 Oct 2009 06:24:45 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by core3.amsl.com (Postfix) with ESMTP id B874E28C0EE for ; Thu, 15 Oct 2009 06:24:43 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKStcintuPKYgEulIZvXuZ+nAmK7Bsf6Mv@postini.com; Thu, 15 Oct 2009 06:24:48 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9FDOhX3021808; Thu, 15 Oct 2009 06:24:44 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9FDOgiq014103; Thu, 15 Oct 2009 06:24:42 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 15 Oct 2009 06:24:42 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Thu, 15 Oct 2009 06:24:42 -0700 From: Henry Sinnreich To: Cullen Jennings , "codec@ietf.org" Date: Thu, 15 Oct 2009 06:24:40 -0700 Thread-Topic: [codec] Question about scheduling CODEC BOF Thread-Index: AcpNYOJqxPKJYcc3TrueZVnzULCTTQAOfbpK Message-ID: In-Reply-To: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6FC8CC8646Chsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 13:24:46 -0000 --_000_C6FC8CC8646Chsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Moving the BOF to Friday is a problem for me. Such last minute changes are very costly for intercontinental travel. Thanks, Henry On 10/15/09 1:28 AM, "Cullen Jennings" wrote: Andrew Malis wants to come to the CODEC BOF and he is an author of a PWE3 document. Currently PWE3 is scheduled at the same time the CODEC BOF. To resolve this the secretariat is considering moving the CODEC BOF to Friday Nov 13 from 13:00 to 15:15. If this is a problem for anyone, speak up quickly! Thanks, Cullen _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C6FC8CC8646Chsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Question about scheduling CODEC BOF Moving the BOF to Friday is a problem for me.
Such last minute changes are very costly for intercontinental travel.

Thanks, Henry


On 10/15/09 1:28 AM, "Cullen Jennings" <fluffy@cisco.com> wrote:



Andrew Malis wants to come to the CODEC BOF and he is an author of a
PWE3 document. Currently PWE3 is scheduled at the same time the CODEC
BOF. To resolve this the secretariat is considering moving the CODEC
BOF to Friday Nov 13 from 13:00 to 15:15.

If this is a problem for anyone, speak up quickly!

Thanks, Cullen

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C6FC8CC8646Chsinnreiadobecom_-- From hoene@uni-tuebingen.de Thu Oct 15 06:52:30 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A0D3A68AE for ; Thu, 15 Oct 2009 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUSM5YV6LSub for ; Thu, 15 Oct 2009 06:52:29 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 5B95B3A689F for ; Thu, 15 Oct 2009 06:52:29 -0700 (PDT) Received: from hoeneLenovoT60 (eap111082.extern.uni-tuebingen.de [134.2.111.82]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9FDqUpe003252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 15 Oct 2009 15:52:30 +0200 From: "Christian Hoene" To: References: <4ACE305C.4020403@stpeter.im> In-Reply-To: <4ACE305C.4020403@stpeter.im> Date: Thu, 15 Oct 2009 15:52:28 +0200 Message-ID: <001101ca4d9e$bc240850$346c18f0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpIRdqLY+3g8LvCSv6EMZwHxBmmigDs84LQ Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 13:52:31 -0000 Dear Peter Saint-Andre and all, inline you will find my personal comments to the proposed charter. > PROPOSED CHARTER > > Problem Statement > > There are no standardized, high-quality audio codecs that are optimized > for use in interactive Internet applications and that can be widely > implemented and easily distributed among application developers, > service operators, and end users. This gap in the Internet protocol > stack has hindered protocol designers from being able to specify > mandatory-to-implement codecs in their protocols for the sake of > interoperability, developers from building innovative, interactive > applications, service operators from deploying affordable, high-quality > services, and end users from enjoying an optimal user experience. > Because the Internet Standards Process defines an open, transparent > process for technology standardization, a wide range of codec experts > have committed to actively working on such codecs within the IETF. The > Codec WG provides a structured forum for these efforts. Sounds good! > > Objectives > > The goal of this group is to develop one or more high-quality, > widely-distributable audio codecs that is optimized for use over the > Internet. Core considerations include the following: > > 1. Use in interactive applications (examples include but are not limited > to point-to-point voice calls, multi-party voice conferencing, > telepresence, teleoperation, in-game voice chat, and live music performance) > > 2. Addressing the real transport conditions of the Internet, especially > packet loss I do not understand this last consideration. What do you mean with this statement? Are packet losses the only attribute of transmissions over the Internet? At least it has been agreed upon that jitter compensation is also relevant. I would suggest to rephrase this requirement to "Addressing the real transport conditions of the Internet. Important attributes of packet transmissions over the Internet are identified in cooperation with other IETF working groups such as AVT and DCCP." > 3. Ensuring interoperability with the Real-time Transport Protocol > (RTP), including secure transport via SRTP > > 4. Ensuring interoperability with Internet signalling technologies such > as Session Initiation Protocol (SIP), Session Description Protocol > (SDP), and Extensible Messaging and Presence Protocol (XMPP) > > Codecs optimized for very low bit rates Traditionally, very low bit codecs are operating below 2.4 kbps. It might not be known to the Internet guys. > and codecs for non-interactive > audio are out of scope. Maybe you can add "because they require other kind of optimizations". BTW: Do you address multicast, too? If not, mention it here. > Although the codec(s) produced by the group might be used as > mandatory-to-implement technologies by designers of particular Internet > protocols, it is explicitly not a goal of the group to produce a codec > that will be mandated for use across the entire IETF or Internet community. > > The group might produce only one codec or it might produce multiple > codecs; however, to reduce confusion in the marketplace it shall > endeavor not to function as a "codec factory" that produces a large > number of codecs. I would suggest to remove the part after the semicolon. Instead, maybe add something like "The codec(s) shall be address a large range of typical transmission conditions on the Internet." > Work processes and technical requirements for achieving the foregoing > objectives are outlined in draft-valin-codec-guidelines and > draft-valin-codec-requirements respectively; these will be further > refined by the group in accordance with the usual IETF procedures for > arriving at rough consensus. I think it is problematic to predefine a draft that must be chosen. A critical minded person might think that this standardization process is a put-up affair. Instead, it is in good tradition of the IETF that the best technical approach should win. Just imagine that you codec experts cannot agree on a common requirements document or that other codec guys make a better proposal. We should allow competition because this leads to better technical solutions. Thus, I suggest to change it in "... outlined in a codec-guidelines draft such as the draft-valin-codec-guidelines-01 and in a codec-requirements draft such as draft-valin-codec-requirements-01 respectively; ..."? > Intellectual property rights (IPR) issues will be handled in accordance > with BCP 78 and BCP 79. Many existing codecs with the technical > attributes listed above are encumbered with licensing fees and other IPR > claims that make royalty-free and wide distribution and use across the > Internet community difficult. The group will try to standardize codecs > that can be relatively freely and easily distributed, and employed as > much as possible. In doing so, it will adhere closely to these BCPs. > More specifically, "In general, IETF working groups prefer technologies > with no known IPR claims or, for technologies with claims against them, > an offer of royalty-free licensing." Note that in accordance with BCP > 79, the group will not explicitly rule out the possibility of adopting > technology that does not meet these IPR requirements; such decisions > will be made in accordance with the rough consensus of the group. > > Deliverables > > 1. Guidelines that define the work process of the group, using > draft-valin-codec-guidelines as the basis for achieving consensus. This > document shall be Informational. > > 2. Detailed technical requirements, using draft-valin-codec-requirements > as the basis for achieving consensus. This document shall be Informational. Again, I would suggest to change it to "Guidelines that defined the work process of the group define in a common codec-guidelines document." and "Detailed technical requirements defined in a common codec-guidelines document." due to the same reasons. > 3. Specification of one or more codecs that meet the agreed-upon > requirements, in the form of Internet-Drafts that define the codec > algorithm and source code for a reference implementation. The text > description of each codec shall indicate which components of the encoder > and decoder are mandatory, recommended, and optional. It is envisioned > that each such specification shall be a Proposed Standard document. > > Milestones > > Mar-2010: WGLC on Codec Standardization Guidelines > Mar-2010: WGLC on Requirements > May-2010: Codec Standardization Guidelines to IESG (Informational) > May-2010: Requirements to IESG (Infomational) +r > Oct-2010: WGLC on codec specification(s) > Jan-2011: Submit codec specification(s) to IESG (Standards Track) This is an ambitious schedule. In my opinion the danger of not keeping this schedule is high. But then again, who cares... All other parts are fine for me. With best regards, Christian From stpeter@stpeter.im Thu Oct 15 14:08:43 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06C93A68C0 for ; Thu, 15 Oct 2009 14:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOOMjitnxZ0y for ; Thu, 15 Oct 2009 14:08:43 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1E7713A687C for ; Thu, 15 Oct 2009 14:08:43 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 79A124038E; Thu, 15 Oct 2009 15:08:46 -0600 (MDT) Message-ID: <4AD78F5D.1010500@stpeter.im> Date: Thu, 15 Oct 2009 15:08:45 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> In-Reply-To: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 21:08:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/15/09 12:28 AM, Cullen Jennings wrote: > > Andrew Malis wants to come to the CODEC BOF and he is an author of a > PWE3 document. Currently PWE3 is scheduled at the same time the CODEC > BOF. To resolve this the secretariat is considering moving the CODEC BOF > to Friday Nov 13 from 13:00 to 15:15. > > If this is a problem for anyone, speak up quickly! My flight from Osaka leaves at 6:35 PM so this won't work for me. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrXj10ACgkQNL8k5A2w/vwzCQCgwJD4ZkR284TEn1TCnrcqaHBx FaUAoKRp4n/pQu0vA8fnTWJp4U/3BFHY =E8O8 -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Thu Oct 15 17:34:00 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DC23A6801 for ; Thu, 15 Oct 2009 17:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lacqjpMcmvUH for ; Thu, 15 Oct 2009 17:33:59 -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 2BB3C3A6765 for ; Thu, 15 Oct 2009 17:33:59 -0700 (PDT) Received: by ywh13 with SMTP id 13so2233192ywh.29 for ; Thu, 15 Oct 2009 17:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=xvckpHYmf0LnX0IbTQfCoqAEDR/iA/uUtWsHM8ESXzs=; b=Gcr+rscJw3D4sXETdnVHppw0WXAZnFZgk8JT+oaT+AAbBaTJY8p+S6aIV4Bh31tQIG UYBamn1/XMTdvFYtG0FxjD1oCvoTVjJTRYyuIbwSy9Z6huOJEAm8Iw8gqodO5IxLceL1 0XyrJVrzyUOrbK1CS0izlD/xI7qDVXn+6CWkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:content-language :thread-index; b=cRnP28ZNIrYxzVrn8gdCVuOzO3C2EmdqNYuD9ejAsbv2QkwA50AprMKup82kDp4YOh AaNmYFYZdXPm+3vsGUGK/+2y9d+RRzNVlYyxgXERcfwOTISFikSTeBHI5SuQVsXKBAkA W3tscUHL3CWnBwBMEYb/ITZQIYtJJOdlF5Uv8= Received: by 10.150.36.1 with SMTP id j1mr1468745ybj.321.1255653239984; Thu, 15 Oct 2009 17:33:59 -0700 (PDT) Received: from YOUR6108 ([200.2.228.18]) by mx.google.com with ESMTPS id 16sm336725gxk.11.2009.10.15.17.33.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 17:33:58 -0700 (PDT) From: "rontlv" To: "'Cullen Jennings'" , References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> In-Reply-To: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> Date: Fri, 16 Oct 2009 02:33:50 +0200 Message-ID: <4ad7bf76.100bca0a.5cc8.1a03@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: he Thread-index: AcpNYMdWCNSZvtWtTz2Zm+7NvRkQCwAluKMg Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 00:34:00 -0000 Cullen, This question goes back to the point made by David on P2PSIP about scheduling sessions on Friday. I feel frustrated that I take seriously the point that initial agenda is not final and that that the IETF meeting is from Monday morning to Friday afternoon and plan accordingly. Friday should be treated like other meeting day!!!! Unless there is a different view from the IETF Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Thursday, October 15, 2009 8:29 AM > To: codec@ietf.org > Subject: [codec] Question about scheduling CODEC BOF > > > Andrew Malis wants to come to the CODEC BOF and he is an author of a > PWE3 document. Currently PWE3 is scheduled at the same time the CODEC > BOF. To resolve this the secretariat is considering moving the CODEC > BOF to Friday Nov 13 from 13:00 to 15:15. > > If this is a problem for anyone, speak up quickly! > > Thanks, Cullen > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4509 (20091015) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4509 (20091015) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From koen.vos@skype.net Thu Oct 15 19:05:49 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BD3328C12C for ; Thu, 15 Oct 2009 19:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 0Tac0c9YULRh for ; Thu, 15 Oct 2009 19:05:48 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 0FE7C28C0E0 for ; Thu, 15 Oct 2009 19:05:47 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 82A9A6064EF43; Fri, 16 Oct 2009 03:05:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=UFXEc28p151e F7fNJG2fPOcYP9c=; b=C3T0nf3RG4R2vu4HgwnMKXWaDd3tbEPwDC/VHfY9bG/8 Kumik1jxAB02kHp5eQpRn7RhXmVVfe37sMpkBsYzN6Rm4qkJhV4LaCjSFuFQA7El 5aRaTv2rg7sBoljGha09sRJYpJBOOpYKraeesbEZ7H/7pIMJLqiIyeXUJnWsiPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=RBb8fpA/Uk3Km0PW8yci XVC8oax3hrLtrupysrf+d62lkSs5ZDKwKgW7ZL1/uftxNcIy/XpX7yrt7NfJLCaP h7r1TmGdXVFZkf0p1b6gTtGM1rSlJ6FZdEpjjhXGXTqH+3P+vqyXERMJLuVfdg7s Yv3bD/UnFtOt3ExPXNBla6Y= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 80E666064EDA4; Fri, 16 Oct 2009 03:05:50 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoOyiMpulFgM; Fri, 16 Oct 2009 03:05:50 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 6DC896064EF3E; Fri, 16 Oct 2009 03:05:50 +0100 (IST) Received: from 71.141.142.127 ([71.141.142.127]) by mail.skype.net (Horde Framework) with HTTP; Thu, 15 Oct 2009 19:05:50 -0700 Message-ID: <20091015190550.213735b0oqb292wu@mail.skype.net> Date: Thu, 15 Oct 2009 19:05:50 -0700 From: Koen Vos To: rontlv References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> <4ad7bf76.100bca0a.5cc8.1a03@mx.google.com> In-Reply-To: <4ad7bf76.100bca0a.5cc8.1a03@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 02:05:49 -0000 So to participate in a 2-hour meeting we all should reserve a whole week on our agenda? And that 3x a year...? Maybe no problem for people attending many meetings, but it sure seems like discrimination against outsiders only interested in a narrow area. koen. Quoting rontlv : > Cullen, > This question goes back to the point made by David on P2PSIP about > scheduling sessions on Friday. > I feel frustrated that I take seriously the point that initial agenda is not > final and that that the IETF meeting is from Monday morning to Friday > afternoon and plan accordingly. > Friday should be treated like other meeting day!!!! Unless there is a > different view from the IETF > > Roni Even > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Cullen Jennings >> Sent: Thursday, October 15, 2009 8:29 AM >> To: codec@ietf.org >> Subject: [codec] Question about scheduling CODEC BOF >> >> >> Andrew Malis wants to come to the CODEC BOF and he is an author of a >> PWE3 document. Currently PWE3 is scheduled at the same time the CODEC >> BOF. To resolve this the secretariat is considering moving the CODEC >> BOF to Friday Nov 13 from 13:00 to 15:15. >> >> If this is a problem for anyone, speak up quickly! >> >> Thanks, Cullen >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 4509 (20091015) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 4509 (20091015) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From fluffy@cisco.com Fri Oct 16 10:20:50 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E519028C0FF for ; Fri, 16 Oct 2009 10:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue14xSrpOR98 for ; Fri, 16 Oct 2009 10:20:49 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1029028C0F4 for ; Fri, 16 Oct 2009 10:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=685; q=dns/txt; s=sjiport02001; t=1255713653; x=1256923253; 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:=20Cullen=20Jennings=20|Subject: =20Re:=20[codec]=20Question=20about=20scheduling=20CODEC =20BOF|Date:=20Fri,=2016=20Oct=202009=2011:20:52=20-0600 |Message-Id:=20<6161C53A-5D9F-41CE-AAD3-D70AF68E25C5@cisc o.com>|To:=20Cullen=20Jennings=20|Cc: =20codec@ietf.org|Mime-Version:=201.0=20(Apple=20Message =20framework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<2D01AA05-0931-4516-B06B-D4FE97B5F73C@cis co.com>|References:=20<2D01AA05-0931-4516-B06B-D4FE97B5F7 3C@cisco.com>; bh=v87KOfMHp/2WjAzS0QDeaxc4ZpiEZJN3oYfR+DOwuE8=; b=O0cbJrF0/TPXFTkZc1zBpFmcYyuuM/cXTwgNXJBSgRfQKBdCmEDvmDqW R3BCaBdlf0dgIyt/NXw4sCbFqj8BFkhh6IqVe/d6Ceq3itiGTsL+YR6Bf CvT0RVWz+s1bJGtBl+zEvphWpDnXXmC2N4msb6uO+JluyMToPcm3jvvwi I=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,574,1249257600"; d="scan'208";a="215322199" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2009 17:20:53 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9GHKqOw023882; Fri, 16 Oct 2009 17:20:53 GMT From: Cullen Jennings To: Cullen Jennings In-Reply-To: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> Message-Id: <6161C53A-5D9F-41CE-AAD3-D70AF68E25C5@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: Fri, 16 Oct 2009 11:20:52 -0600 X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 17:20:51 -0000 Ok, clearly moving this to Friday is not an optimal trade off. We come up with an alternative plan. Thanks for the quick feedback. On Oct 15, 2009, at 12:28 AM, Cullen Jennings wrote: > > Andrew Malis wants to come to the CODEC BOF and he is an author of a > PWE3 document. Currently PWE3 is scheduled at the same time the > CODEC BOF. To resolve this the secretariat is considering moving the > CODEC BOF to Friday Nov 13 from 13:00 to 15:15. > > If this is a problem for anyone, speak up quickly! > > Thanks, Cullen > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stpeter@stpeter.im Fri Oct 16 13:39:10 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E183A67B6 for ; Fri, 16 Oct 2009 13:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R6MVEn0eKwd for ; Fri, 16 Oct 2009 13:39:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 77D333A67A2 for ; Fri, 16 Oct 2009 13:39:09 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7D9544038E; Fri, 16 Oct 2009 14:39:13 -0600 (MDT) Message-ID: <4AD8D9F0.6040205@stpeter.im> Date: Fri, 16 Oct 2009 14:39:12 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jean-Marc Valin References: <4ACCCCB3.8080100@octasic.com> <3d032e5d0910071130w470d46d1n6b80a87013090be4@mail.gmail.com> <4ACCDFFD.1030904@stpeter.im> <3d032e5d0910071222yc718eaeye2574e301894f9ae@mail.gmail.com> <4ACD5DC8.9030203@usherbrooke.ca> In-Reply-To: <4ACD5DC8.9030203@usherbrooke.ca> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] Updated codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 20:39:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/7/09 9:34 PM, Jean-Marc Valin wrote: >> 2/ In Section 6 what does this mean >> >> * Purely wireless applications will not be considered >> >> Does it exclude Wifi? Maybe an example would clarify..... > > Wifi is definitely within the scope here. I agree that "purely wireless" > is not a great description. My personal view (we haven't discussed this > in great details) is that we would rule out applications such as ham > radio and cell phones (unless you're doing VoIP on that mobile), but > include "IP over wireless links". Again, a better wording would be > welcome if anyone can suggest one. How about this? "Wireless applications that do not communicate over the Internet Protocol (e.g., radio) will not be considered" Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrY2fAACgkQNL8k5A2w/vxHwQCeKjlWrCwbLelGJIrDbKO0LuyA 3LkAni5z618wVa+dUD0b550yllRkh4eh =bOfH -----END PGP SIGNATURE----- From jean-marc.valin@octasic.com Fri Oct 16 13:41:46 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6769F3A67B6 for ; Fri, 16 Oct 2009 13:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PD2qr2jAsf5 for ; Fri, 16 Oct 2009 13:41:45 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 500433A67A2 for ; Fri, 16 Oct 2009 13:41:40 -0700 (PDT) Received: from [142.138.24.13] ([142.138.24.13]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 16:41:44 -0400 Message-ID: <4AD8DB31.6030506@octasic.com> Date: Fri, 16 Oct 2009 16:44:33 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Peter Saint-Andre References: <4ACCCCB3.8080100@octasic.com> <3d032e5d0910071130w470d46d1n6b80a87013090be4@mail.gmail.com> <4ACCDFFD.1030904@stpeter.im> <3d032e5d0910071222yc718eaeye2574e301894f9ae@mail.gmail.com> <4ACD5DC8.9030203@usherbrooke.ca> <4AD8D9F0.6040205@stpeter.im> In-Reply-To: <4AD8D9F0.6040205@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2009 20:41:44.0888 (UTC) FILETIME=[12FEF380:01CA4EA1] Cc: "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Updated codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 20:41:46 -0000 Peter Saint-Andre wrote: > How about this? > > "Wireless applications that do not communicate over the Internet > Protocol (e.g., radio) will not be considered" I think that's a very good way to put it. Jean-Marc From stpeter@stpeter.im Fri Oct 16 13:45:59 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0313A6847 for ; Fri, 16 Oct 2009 13:45:59 -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 otiA8xiquM5G for ; Fri, 16 Oct 2009 13:45:58 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 62EBF3A67B6 for ; Fri, 16 Oct 2009 13:45:58 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6D2B4038E; Fri, 16 Oct 2009 14:46:02 -0600 (MDT) Message-ID: <4AD8DB89.30300@stpeter.im> Date: Fri, 16 Oct 2009 14:46:01 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jean-Marc Valin References: <4ACF7658.2000304@octasic.com> In-Reply-To: <4ACF7658.2000304@octasic.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 20:45:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/9/09 11:43 AM, Jean-Marc Valin wrote: > Regarding the charter, the intent of objectives 2, 3 and 4 was to > specify the operating environment we were primarily targeting, which is > the Internet. Also, the main reason for mentioning RTP/SIP/SDP/SRTP/XMPP > was to acknowledge that these protocols are important for the IETF and > thus that the codec designers should ensure that the codec fits well > with these protocols and not to do anything that would create > interoperability issues. As Henry pointed out, this can be interpreted > as implying that we would not consider other protocols on the Internet, > but this was not the intent here. We should probably make that clearer. Correct. Ensuring interoperability with those parts of the IETF protocol stack doesn't imply that the WG will ignore interoperability with any other protocols. IMHO the text "Core considerations *include the following*..." and "Ensuring interoperability with Internet signalling technologies *such as*..." shows that these considerations are by no means exclusive. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrY24kACgkQNL8k5A2w/vxDbACeKMwX7f/JXzda2U4T4uI4uFyi yZIAni8GCDJVHJDtipx3Y7oWMJ2qRP2l =xl9n -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Oct 16 14:12:44 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1303B3A67DB for ; Fri, 16 Oct 2009 14:12:44 -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 nyxmABP9p333 for ; Fri, 16 Oct 2009 14:12:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6B3D53A67A2 for ; Fri, 16 Oct 2009 14:12:42 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 71F2B4038E; Fri, 16 Oct 2009 15:12:46 -0600 (MDT) Message-ID: <4AD8E1CD.7090709@stpeter.im> Date: Fri, 16 Oct 2009 15:12:45 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Hoene References: <4ACE305C.4020403@stpeter.im> <001101ca4d9e$bc240850$346c18f0$@de> In-Reply-To: <001101ca4d9e$bc240850$346c18f0$@de> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:12:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/15/09 7:52 AM, Christian Hoene wrote: > Dear Peter Saint-Andre and all, > > inline you will find my personal comments to the proposed charter. Thank you for your feedback. >> PROPOSED CHARTER >> >> Problem Statement >> >> There are no standardized, high-quality audio codecs that are optimized >> for use in interactive Internet applications and that can be widely >> implemented and easily distributed among application developers, >> service operators, and end users. This gap in the Internet protocol >> stack has hindered protocol designers from being able to specify >> mandatory-to-implement codecs in their protocols for the sake of >> interoperability, developers from building innovative, interactive >> applications, service operators from deploying affordable, high-quality >> services, and end users from enjoying an optimal user experience. >> Because the Internet Standards Process defines an open, transparent >> process for technology standardization, a wide range of codec experts >> have committed to actively working on such codecs within the IETF. The >> Codec WG provides a structured forum for these efforts. > > Sounds good! > >> Objectives >> >> The goal of this group is to develop one or more high-quality, >> widely-distributable audio codecs that is optimized for use over the >> Internet. Core considerations include the following: >> >> 1. Use in interactive applications (examples include but are not limited >> to point-to-point voice calls, multi-party voice conferencing, >> telepresence, teleoperation, in-game voice chat, and live music > performance) >> 2. Addressing the real transport conditions of the Internet, especially >> packet loss > > I do not understand this last consideration. What do you mean with this > statement? Are packet losses the only attribute of transmissions over the > Internet? By no means. The word "especially" does not exclude other conditions that might be important to consider. > At least it has been agreed upon that jitter compensation is also > relevant. I would suggest to rephrase this requirement to "Addressing the > real transport conditions of the Internet. Important attributes of packet > transmissions over the Internet are identified in cooperation with other > IETF working groups such as AVT and DCCP." I think it might be more productive to say this: *** 2. Addressing the real transport conditions of the Internet as identified and prioritized by the group *** It's not really the task of the charter to define the real transport conditions of the Internet, but if we include this is an objective of the group then they should certainly keep those conditions in mind as they complete their work. >> 3. Ensuring interoperability with the Real-time Transport Protocol >> (RTP), including secure transport via SRTP >> >> 4. Ensuring interoperability with Internet signalling technologies such >> as Session Initiation Protocol (SIP), Session Description Protocol >> (SDP), and Extensible Messaging and Presence Protocol (XMPP) >> >> Codecs optimized for very low bit rates > > Traditionally, very low bit codecs are operating below 2.4 kbps. It might > not be known to the Internet guys. Added. >> and codecs for non-interactive >> audio are out of scope. > > Maybe you can add "because they require other kind of optimizations". In my working copy I have changed this to: *** Codecs optimized for very low bit rates (typically below 2.4 kbps) and codecs for non-interactive audio are out of scope because they might necessitate specialized optimizations. *** > BTW: > Do you address multicast, too? If not, mention it here. By "multicast" do you mean many-to-many or one-to-many? We talk a bit about that in the requirements draft. >> Although the codec(s) produced by the group might be used as >> mandatory-to-implement technologies by designers of particular Internet >> protocols, it is explicitly not a goal of the group to produce a codec >> that will be mandated for use across the entire IETF or Internet > community. >> The group might produce only one codec or it might produce multiple >> codecs; however, to reduce confusion in the marketplace it shall >> endeavor not to function as a "codec factory" that produces a large >> number of codecs. > > I would suggest to remove the part after the semicolon. Instead, maybe add > something like "The codec(s) shall be address a large range of typical > transmission conditions on the Internet." Your proposed addition does not talk about the point you propose to remove (i.e., we are not going to produce dozens of codecs) and the point you add here is discussed elsewhere in the charter. Therefore I'm not in favor of this change. >> Work processes and technical requirements for achieving the foregoing >> objectives are outlined in draft-valin-codec-guidelines and >> draft-valin-codec-requirements respectively; these will be further >> refined by the group in accordance with the usual IETF procedures for >> arriving at rough consensus. > > I think it is problematic to predefine a draft that must be chosen. I think it is problematic to mention no Internet-Drafts in the charter. The existing I-Ds will form the starting point for work within the group. Whether those I-Ds will remain as they are today (I doubt that they will) is up to the group. > A > critical minded person might think that this standardization process is a > put-up affair. Instead, it is in good tradition of the IETF that the best > technical approach should win. Just imagine that you codec experts cannot > agree on a common requirements document or that other codec guys make a > better proposal. We should allow competition because this leads to better > technical solutions. Thus, I suggest to change it in "... outlined in a > codec-guidelines draft such as the draft-valin-codec-guidelines-01 and in a > codec-requirements draft such as draft-valin-codec-requirements-01 > respectively; ..."? The "such as" here is not especially helpful as guidance to the group or as part of our contract with the IESG. Given that no one else on this list has even mentioned the possibility of working on Internet-Drafts for the procedural guidelines or technical requirements, I think it is best to show the IESG that the published I-Ds are available for inspection and will form the starting point of the group's efforts. Those I-Ds are not final by any means, but at least they are something that the group can refine over time. Which is exactly what the current charter text says. However, I'm sure we can improve things slightly. How about this? *** Work processes and technical requirements for achieving the foregoing objectives are outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and will be refined by the group in accordance with the usual IETF procedures. *** >> Intellectual property rights (IPR) issues will be handled in accordance >> with BCP 78 and BCP 79. Many existing codecs with the technical >> attributes listed above are encumbered with licensing fees and other IPR >> claims that make royalty-free and wide distribution and use across the >> Internet community difficult. The group will try to standardize codecs >> that can be relatively freely and easily distributed, and employed as >> much as possible. In doing so, it will adhere closely to these BCPs. >> More specifically, "In general, IETF working groups prefer technologies >> with no known IPR claims or, for technologies with claims against them, >> an offer of royalty-free licensing." Note that in accordance with BCP >> 79, the group will not explicitly rule out the possibility of adopting >> technology that does not meet these IPR requirements; such decisions >> will be made in accordance with the rough consensus of the group. >> >> Deliverables >> >> 1. Guidelines that define the work process of the group, using >> draft-valin-codec-guidelines as the basis for achieving consensus. This >> document shall be Informational. >> >> 2. Detailed technical requirements, using draft-valin-codec-requirements >> as the basis for achieving consensus. This document shall be > Informational. > > Again, I would suggest to change it to "Guidelines that defined the work > process of the group define in a common codec-guidelines document." and > "Detailed technical requirements defined in a common codec-guidelines > document." due to the same reasons. In my working copy I have changed these to: *** 1. Guidelines that define the work process of the group, using draft-valin-codec-guidelines as the starting point for working toward consensus. This document shall be Informational. 2. Detailed technical requirements, using draft-valin-codec-requirementsas the starting point for working toward consensus. This document shall be Informational. *** Does that text address your concerns? >> 3. Specification of one or more codecs that meet the agreed-upon >> requirements, in the form of Internet-Drafts that define the codec >> algorithm and source code for a reference implementation. The text >> description of each codec shall indicate which components of the encoder >> and decoder are mandatory, recommended, and optional. It is envisioned >> that each such specification shall be a Proposed Standard document. >> >> Milestones >> >> Mar-2010: WGLC on Codec Standardization Guidelines >> Mar-2010: WGLC on Requirements >> May-2010: Codec Standardization Guidelines to IESG (Informational) >> May-2010: Requirements to IESG (Infomational) > +r >> Oct-2010: WGLC on codec specification(s) >> Jan-2011: Submit codec specification(s) to IESG (Standards Track) > > This is an ambitious schedule. In my opinion the danger of not keeping this > schedule is high. But then again, who cares... You're right that it is aggressive. But it seems that we have a core group of energetic contributors and that we might be able to make fast progress if the WG is approved. But perhaps giving ourselves a few more months here and there would be appropriate. So perhaps this is slightly more realistic yet still ambitious: *** Mar-2010: WGLC on Codec Standardization Guidelines May-2010: Codec Standardization Guidelines to IESG (Informational) May-2010: WGLC on Requirements Jul-2010: Requirements to IESG (Infomational) Feb-2011: WGLC on codec specification(s) Apr-2011: Submit codec specification(s) to IESG (Standards Track) *** > All other parts are fine for me. Thanks again for your feedback. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrY4c0ACgkQNL8k5A2w/vzmNgCgy4XHU9FgFCdomRzFGftFoKrx unMAn0f6r7zkfLVjUCPdWJtazfgy5kAa =n0pQ -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Fri Oct 16 16:53:31 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D09D3A683B for ; Fri, 16 Oct 2009 16:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZIAd26Ehizj for ; Fri, 16 Oct 2009 16:53:30 -0700 (PDT) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 387EE3A67AE for ; Fri, 16 Oct 2009 16:53:30 -0700 (PDT) Received: by gxk28 with SMTP id 28so2262815gxk.9 for ; Fri, 16 Oct 2009 16:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=BbiB7jWUQema8Ckxcak/c8XikjEoIK+c0FZ+4KNMFng=; b=PKdmSrAdR1QWdnWME7dFylGgHF1LL3y8Te0qanDEJACo0ENFyWOH6EI0U+SbJHJ1PE RdGOf9u1Tt759dYixJtcXCE1P4/FD1m3Trj45Y32OCeOZnD/BPiT08OsPJehSHmQl7nc 4O+b+Tql4lKRVJVypFksK5VKtrBAQaqfMkJ0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=YCYmThhD2vuoKRgGOBHXjTCW2pRHw/Cis+5xTB2yH3Y3d5oE88ti626SW9oSw3Pc2a ap88luYg6G+LLIrt/b/rKANC+ndmkSfKZJJg5JltHv20qhCyTfN4zXIwZ8CjzpkppCJP TG8fmQ4vk17yD2FILG9rWU9kRhqL5vMl/DHEM= Received: by 10.150.176.15 with SMTP id y15mr3833453ybe.242.1255737211992; Fri, 16 Oct 2009 16:53:31 -0700 (PDT) Received: from YOUR6108 ([200.2.228.18]) by mx.google.com with ESMTPS id 13sm192090gxk.5.2009.10.16.16.53.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Oct 2009 16:53:30 -0700 (PDT) From: "rontlv" To: "'Koen Vos'" References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> <4ad7bf76.100bca0a.5cc8.1a03@mx.google.com> <20091015190550.213735b0oqb292wu@mail.skype.net> In-Reply-To: <20091015190550.213735b0oqb292wu@mail.skype.net> Date: Sat, 17 Oct 2009 01:53:18 +0200 Message-ID: <4ad9077a.0d0bca0a.2406.10c6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpOBTCPW9fK9P3WTp+9y6iDoz0cHQAtiIAg Content-Language: he Cc: codec@ietf.org Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 23:53:31 -0000 Koen, The first comment is that the first agenda published is not final and may be subject to changes. So I do not think that someone who plans his travel based on the first agenda can complain if it changes later. For example in the last IETD meeting the second ACT session was moved to Friday on the final agenda, yet people who had interest attended the session. I still think that reducing conflicts with other group would be the best on Friday Roni Even > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Friday, October 16, 2009 4:06 AM > To: rontlv > Cc: 'Cullen Jennings'; codec@ietf.org > Subject: Re: [codec] Question about scheduling CODEC BOF > > So to participate in a 2-hour meeting we all should reserve a whole > week on our agenda? And that 3x a year...? > > Maybe no problem for people attending many meetings, but it sure seems > like discrimination against outsiders only interested in a narrow area. > > koen. > > > > Quoting rontlv : > > > Cullen, > > This question goes back to the point made by David on P2PSIP about > > scheduling sessions on Friday. > > I feel frustrated that I take seriously the point that initial agenda > is not > > final and that that the IETF meeting is from Monday morning to Friday > > afternoon and plan accordingly. > > Friday should be treated like other meeting day!!!! Unless there is a > > different view from the IETF > > > > Roni Even > > > >> -----Original Message----- > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf > >> Of Cullen Jennings > >> Sent: Thursday, October 15, 2009 8:29 AM > >> To: codec@ietf.org > >> Subject: [codec] Question about scheduling CODEC BOF > >> > >> > >> Andrew Malis wants to come to the CODEC BOF and he is an author of a > >> PWE3 document. Currently PWE3 is scheduled at the same time the > CODEC > >> BOF. To resolve this the secretariat is considering moving the CODEC > >> BOF to Friday Nov 13 from 13:00 to 15:15. > >> > >> If this is a problem for anyone, speak up quickly! > >> > >> Thanks, Cullen > >> > >> _______________________________________________ > >> codec mailing list > >> codec@ietf.org > >> https://www.ietf.org/mailman/listinfo/codec > >> > >> > >> __________ Information from ESET NOD32 Antivirus, version of virus > >> signature database 4509 (20091015) __________ > >> > >> The message was checked by ESET NOD32 Antivirus. > >> > >> http://www.eset.com > >> > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > > database 4509 (20091015) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4516 (20091016) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4516 (20091016) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From ron.even.tlv@gmail.com Fri Oct 16 16:57:17 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767E53A688B for ; Fri, 16 Oct 2009 16:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3Bb-m8gHfZO for ; Fri, 16 Oct 2009 16:57:16 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 5DFDD3A6811 for ; Fri, 16 Oct 2009 16:57:16 -0700 (PDT) Received: by yxe30 with SMTP id 30so3245405yxe.29 for ; Fri, 16 Oct 2009 16:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=i5nGzziUonppFjk16Is6UoVVOmZVh5ovyNb0aJ9rQzw=; b=MZxaaSp134Xq9Q/tsPIjkVRPFFcaxMmusx+hq72/6FsfFVyIyqhNsLJiasnPcY8+zv lHHUBauwwYTs7y2+RiAmu6b6y09tqAgGod4uTliaIandaLn0mJY1E5WLz3ezkpxYLMw1 MSb+LX90jiHua0d1qoz2EcX55JL315uPWQygg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=YPPSDjs1geoUQ0+ejWmBi8tIZhKPSKwXMfwJyPLwqvx8jmHYaQF3+5CL2KIpG5djIH 5sDC0yR+Vm6KLfIoERZ38IyQ290bmQfzuMT60O5TxqXS5UhuqjIAsuyncIrufXrPRwga g3jRiMBkcpF0ETvrLif3uGhHByNDnxzzB6D2Q= Received: by 10.150.115.8 with SMTP id n8mr3878631ybc.64.1255737435623; Fri, 16 Oct 2009 16:57:15 -0700 (PDT) Received: from YOUR6108 ([200.2.228.18]) by mx.google.com with ESMTPS id 13sm961619gxk.1.2009.10.16.16.57.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Oct 2009 16:57:14 -0700 (PDT) From: "rontlv" To: "'Cullen Jennings'" References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> <6161C53A-5D9F-41CE-AAD3-D70AF68E25C5@cisco.com> In-Reply-To: <6161C53A-5D9F-41CE-AAD3-D70AF68E25C5@cisco.com> Date: Sat, 17 Oct 2009 01:57:07 +0200 Message-ID: <4ad9085a.0d0bca0a.7103.48ab@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpOhQl4awMuzjUPR8KffIWEF1OJgQANtExA Content-Language: he Cc: codec@ietf.org Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 23:57:17 -0000 Cullen, This is a pity since currently there was a conflict also with ppsp and Friday would work better. Since the first agenda published is not final and changes may occur I am not sure why we need to ask about moving to Friday. In the last IETF AVT was moved on the final agenda to Friday without asking on the list and still people who had interest attended Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Friday, October 16, 2009 7:21 PM > To: Cullen Jennings > Cc: codec@ietf.org > Subject: Re: [codec] Question about scheduling CODEC BOF > > > Ok, clearly moving this to Friday is not an optimal trade off. We come > up with an alternative plan. Thanks for the quick feedback. > > On Oct 15, 2009, at 12:28 AM, Cullen Jennings wrote: > > > > > Andrew Malis wants to come to the CODEC BOF and he is an author of a > > PWE3 document. Currently PWE3 is scheduled at the same time the > > CODEC BOF. To resolve this the secretariat is considering moving the > > CODEC BOF to Friday Nov 13 from 13:00 to 15:15. > > > > If this is a problem for anyone, speak up quickly! > > > > Thanks, Cullen > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4516 (20091016) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4516 (20091016) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From hoene@uni-tuebingen.de Sat Oct 17 00:04:25 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2418A3A6809 for ; Sat, 17 Oct 2009 00:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwKXXB0GVcPr for ; Sat, 17 Oct 2009 00:04:24 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id BD5C53A67DF for ; Sat, 17 Oct 2009 00:04:22 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-218-217-140.pools.arcor-ip.net [94.218.217.140]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9H74IsJ009071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Oct 2009 09:04:24 +0200 From: "Christian Hoene" To: "'rontlv'" References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> <4ad7bf76.100bca0a.5cc8.1a03@mx.google.com> <20091015190550.213735b0oqb292wu@mail.skype.net> <4ad9077a.0d0bca0a.2406.10c6@mx.google.com> In-Reply-To: <4ad9077a.0d0bca0a.2406.10c6@mx.google.com> Date: Sat, 17 Oct 2009 09:04:16 +0200 Message-ID: <000601ca4ef8$0e27dd70$2a779850$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpOBTCPW9fK9P3WTp+9y6iDoz0cHQAtiIAgAA6rO9A= Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.35; VDF: 7.1.6.118; host: mx05); id=2022-k7rIKz Cc: codec@ietf.org Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 07:04:25 -0000 Hi Roni Even, I have to admit that I made the same mistake at Stockholm and missed both AVT meetings. I think it is a typical beginners mistake to plan only for a few days. Having this said, I have to agree that it make sense to join the IETF meetings in full in future. Not only because of short time schedule changes but also because this time can be used for making progress on own drafts. Also, one might can go to other WG groups to get a broader picture beyond the own field of work. Later might be beneficial even for the own WG. Christian > Koen, > The first comment is that the first agenda published is not final and may be > subject to changes. So I do not think that someone who plans his travel > based on the first agenda can complain if it changes later. For example in > the last IETD meeting the second AVT session was moved to Friday on the > final agenda, yet people who had interest attended the session. > I still think that reducing conflicts with other group would be the best on > Friday > Roni Even > > > -----Original Message----- > > From: Koen Vos [mailto:koen.vos@skype.net] > > Sent: Friday, October 16, 2009 4:06 AM > > To: rontlv > > Cc: 'Cullen Jennings'; codec@ietf.org > > Subject: Re: [codec] Question about scheduling CODEC BOF > > > > So to participate in a 2-hour meeting we all should reserve a whole > > week on our agenda? And that 3x a year...? > > > > Maybe no problem for people attending many meetings, but it sure seems > > like discrimination against outsiders only interested in a narrow area. > > > > koen. > > > > > > > > Quoting rontlv : > > > > > Cullen, > > > This question goes back to the point made by David on P2PSIP about > > > scheduling sessions on Friday. > > > I feel frustrated that I take seriously the point that initial agenda > > is not > > > final and that that the IETF meeting is from Monday morning to Friday > > > afternoon and plan accordingly. > > > Friday should be treated like other meeting day!!!! Unless there is a > > > different view from the IETF > > > > > > Roni Even > > > > > >> -----Original Message----- > > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf > > >> Of Cullen Jennings > > >> Sent: Thursday, October 15, 2009 8:29 AM > > >> To: codec@ietf.org > > >> Subject: [codec] Question about scheduling CODEC BOF > > >> > > >> > > >> Andrew Malis wants to come to the CODEC BOF and he is an author of a > > >> PWE3 document. Currently PWE3 is scheduled at the same time the > > CODEC > > >> BOF. To resolve this the secretariat is considering moving the CODEC > > >> BOF to Friday Nov 13 from 13:00 to 15:15. > > >> > > >> If this is a problem for anyone, speak up quickly! > > >> > > >> Thanks, Cullen > > >> > > >> _______________________________________________ > > >> codec mailing list > > >> codec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/codec > > >> > > >> > > >> __________ Information from ESET NOD32 Antivirus, version of virus > > >> signature database 4509 (20091015) __________ > > >> > > >> The message was checked by ESET NOD32 Antivirus. > > >> > > >> http://www.eset.com > > >> > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature > > > database 4509 (20091015) __________ > > > > > > The message was checked by ESET NOD32 Antivirus. > > > > > > http://www.eset.com > > > > > > > > > _______________________________________________ > > > codec mailing list > > > codec@ietf.org > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 4516 (20091016) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 4516 (20091016) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From gregory.ietf@gmail.com Sat Oct 17 12:21:06 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F259D3A685E for ; Sat, 17 Oct 2009 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC4DWD6u3zxG for ; Sat, 17 Oct 2009 12:21:05 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 022FF3A67F2 for ; Sat, 17 Oct 2009 12:21:04 -0700 (PDT) Received: by ewy4 with SMTP id 4so358644ewy.37 for ; Sat, 17 Oct 2009 12:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=5o1/iUu+0QT6XazWu6cQH2myANrwVb1ehWKowHKx2sg=; b=ODnRE3Uf/M31AU+19EKKTe2/99pd8ldUWh2lnh0n7fjBLXpyZ/qsUo72CVSiJ/76Em ImjJYkDR2SjnfvJvZqS/aqF5UrcG8t7q7ElfP6Uti0gtGbLUxC3v7SHmrbE+sxmoSPMl 8WI8QUHOY5/rKFusco9vWji90X0G5Gsx1I0qg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=dMa5MIpB1lLal0jgXgjmzr7kSOqChLkhOVsEzyy1nn7TtMe7byfXi9LmeQGzauy9fT BAvVFdK8WjVTvHUQiqY9BcNXFHl2UDS8ksM71IOX3UNg2rCdqf6cowOCyt9gOZxP2XdL pyGtNY5SIdmaqqyDObS48pihUXAoDek2ScfTc= Received: by 10.216.85.5 with SMTP id t5mr1011600wee.142.1255807266702; Sat, 17 Oct 2009 12:21:06 -0700 (PDT) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id q9sm6847797gve.15.2009.10.17.12.21.04 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Oct 2009 12:21:06 -0700 (PDT) Message-ID: <4ada1922.09a8100a.2afb.611f@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 17 Oct 2009 12:21:01 -0700 To: Cullen Jennings ,codec@ietf.org From: "Gregory M. Lebovitz" In-Reply-To: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> References: <2D01AA05-0931-4516-B06B-D4FE97B5F73C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [codec] Question about scheduling CODEC BOF X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 19:21:06 -0000 I am flying out Friday morning, right after the IESG + IAB meeting, due to a one-time family obligation on Saturday that I cannot miss. I would have to miss the BOF it was re-scheduled to Friday. Gregory. At 11:28 PM 10/14/2009, Cullen Jennings wrote: >Andrew Malis wants to come to the CODEC BOF and he is an author of a >PWE3 document. Currently PWE3 is scheduled at the same time the CODEC >BOF. To resolve this the secretariat is considering moving the CODEC >BOF to Friday Nov 13 from 13:00 to 15:15. > >If this is a problem for anyone, speak up quickly! > >Thanks, Cullen > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From henry@sinnreich.net Sun Oct 18 06:51:46 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03023A68C2 for ; Sun, 18 Oct 2009 06:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv44KMd7Pxja for ; Sun, 18 Oct 2009 06:51:44 -0700 (PDT) Received: from outbound-mail-129.bluehost.com (outbound-mail-129.bluehost.com [67.222.38.29]) by core3.amsl.com (Postfix) with SMTP id 88F2F3A67FB for ; Sun, 18 Oct 2009 06:51:44 -0700 (PDT) Received: (qmail 21654 invoked by uid 0); 18 Oct 2009 13:51:50 -0000 Received: from unknown (HELO box522.bluehost.com) (74.220.219.122) by outboundproxy4.bluehost.com with SMTP; 18 Oct 2009 13:51:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sinnreich.net; h=Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version:Content-type:X-Identified-User; b=QJIGidjzm6efaXS2C+eQfIMHiEx8CUP0CoDJ1YyY49h/FRcV3D1OEtAqK1v7B7L+33JKlXtbMGZuKQwXwqSL56RtGofAG8x8sLuMcLcSHRuO1qH3zop3Peh6wD3PVbpK; Received: from ool-457670fb.dyn.optonline.net ([69.118.112.251] helo=[10.0.1.17]) by box522.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MzWAn-0005WF-IM; Sun, 18 Oct 2009 07:51:50 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 18 Oct 2009 08:51:47 -0500 From: "henry@sinnreich.net" To: Peter Saint-Andre , Christian Hoene Message-ID: Thread-Topic: [codec] proposed charter Thread-Index: AcpOpWuhRT1iOdyoTrSwUkcBtkz9GQBVLa2H In-Reply-To: <4AD8E1CD.7090709@stpeter.im> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3338700709_17878" X-Identified-User: {35212:box522.bluehost.com:sinnreic:sinnreich.net} {sentby:smtp auth 69.118.112.251 authed with henry@sinnreich.net} X-Mailman-Approved-At: Sun, 18 Oct 2009 06:56:28 -0700 Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 13:51:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3338700709_17878 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Codecs optimized for very low bit rates (typically below 2.4 kbps) and codecs for non-interactive audio are out of scope because they might necessitate specialized optimizations. This is an excellent formulation IMO. Thanks, Henry On 10/16/09 4:12 PM, "Peter Saint-Andre" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/15/09 7:52 AM, Christian Hoene wrote: >> > Dear Peter Saint-Andre and all, >> > >> > inline you will find my personal comments to the proposed charter. > > Thank you for your feedback. > >>> >> PROPOSED CHARTER >>> >> >>> >> Problem Statement >>> >> >>> >> There are no standardized, high-quality audio codecs that are optimized >>> >> for use in interactive Internet applications and that can be widely >>> >> implemented and easily distributed among application developers, >>> >> service operators, and end users. This gap in the Internet protocol >>> >> stack has hindered protocol designers from being able to specify >>> >> mandatory-to-implement codecs in their protocols for the sake of >>> >> interoperability, developers from building innovative, interactive >>> >> applications, service operators from deploying affordable, high-quality >>> >> services, and end users from enjoying an optimal user experience. >>> >> Because the Internet Standards Process defines an open, transparent >>> >> process for technology standardization, a wide range of codec experts >>> >> have committed to actively working on such codecs within the IETF. The >>> >> Codec WG provides a structured forum for these efforts. >> > >> > Sounds good! >> > >>> >> Objectives >>> >> >>> >> The goal of this group is to develop one or more high-quality, >>> >> widely-distributable audio codecs that is optimized for use over the >>> >> Internet. Core considerations include the following: >>> >> >>> >> 1. Use in interactive applications (examples include but are not limited >>> >> to point-to-point voice calls, multi-party voice conferencing, >>> >> telepresence, teleoperation, in-game voice chat, and live music >> > performance) >>> >> 2. Addressing the real transport conditions of the Internet, especially >>> >> packet loss >> > >> > I do not understand this last consideration. What do you mean with this >> > statement? Are packet losses the only attribute of transmissions over the >> > Internet? > > By no means. The word "especially" does not exclude other conditions > that might be important to consider. > >> > At least it has been agreed upon that jitter compensation is also >> > relevant. I would suggest to rephrase this requirement to "Addressing the >> > real transport conditions of the Internet. Important attributes of packet >> > transmissions over the Internet are identified in cooperation with other >> > IETF working groups such as AVT and DCCP." > > I think it might be more productive to say this: > > *** > > 2. Addressing the real transport conditions of the Internet as > identified and prioritized by the group > > *** > > It's not really the task of the charter to define the real transport > conditions of the Internet, but if we include this is an objective of > the group then they should certainly keep those conditions in mind as > they complete their work. > >>> >> 3. Ensuring interoperability with the Real-time Transport Protocol >>> >> (RTP), including secure transport via SRTP >>> >> >>> >> 4. Ensuring interoperability with Internet signalling technologies such >>> >> as Session Initiation Protocol (SIP), Session Description Protocol >>> >> (SDP), and Extensible Messaging and Presence Protocol (XMPP) >>> >> >>> >> Codecs optimized for very low bit rates >> > >> > Traditionally, very low bit codecs are operating below 2.4 kbps. It might >> > not be known to the Internet guys. > > Added. > >>> >> and codecs for non-interactive >>> >> audio are out of scope. >> > >> > Maybe you can add "because they require other kind of optimizations". > > In my working copy I have changed this to: > > *** > > Codecs optimized for very low bit rates (typically below 2.4 kbps) and > codecs for non-interactive audio are out of scope because they might > necessitate specialized optimizations. > > *** > >> > BTW: >> > Do you address multicast, too? If not, mention it here. > > By "multicast" do you mean many-to-many or one-to-many? We talk a bit > about that in the requirements draft. > >>> >> Although the codec(s) produced by the group might be used as >>> >> mandatory-to-implement technologies by designers of particular Internet >>> >> protocols, it is explicitly not a goal of the group to produce a codec >>> >> that will be mandated for use across the entire IETF or Internet >> > community. >>> >> The group might produce only one codec or it might produce multiple >>> >> codecs; however, to reduce confusion in the marketplace it shall >>> >> endeavor not to function as a "codec factory" that produces a large >>> >> number of codecs. >> > >> > I would suggest to remove the part after the semicolon. Instead, maybe add >> > something like "The codec(s) shall be address a large range of typical >> > transmission conditions on the Internet." > > Your proposed addition does not talk about the point you propose to > remove (i.e., we are not going to produce dozens of codecs) and the > point you add here is discussed elsewhere in the charter. Therefore I'm > not in favor of this change. > >>> >> Work processes and technical requirements for achieving the foregoing >>> >> objectives are outlined in draft-valin-codec-guidelines and >>> >> draft-valin-codec-requirements respectively; these will be further >>> >> refined by the group in accordance with the usual IETF procedures for >>> >> arriving at rough consensus. >> > >> > I think it is problematic to predefine a draft that must be chosen. > > I think it is problematic to mention no Internet-Drafts in the charter. > The existing I-Ds will form the starting point for work within the > group. Whether those I-Ds will remain as they are today (I doubt that > they will) is up to the group. > >> > A >> > critical minded person might think that this standardization process is a >> > put-up affair. Instead, it is in good tradition of the IETF that the best >> > technical approach should win. Just imagine that you codec experts cannot >> > agree on a common requirements document or that other codec guys make a >> > better proposal. We should allow competition because this leads to better >> > technical solutions. Thus, I suggest to change it in "... outlined in a >> > codec-guidelines draft such as the draft-valin-codec-guidelines-01 and in a >> > codec-requirements draft such as draft-valin-codec-requirements-01 >> > respectively; ..."? > > The "such as" here is not especially helpful as guidance to the group or > as part of our contract with the IESG. Given that no one else on this > list has even mentioned the possibility of working on Internet-Drafts > for the procedural guidelines or technical requirements, I think it is > best to show the IESG that the published I-Ds are available for > inspection and will form the starting point of the group's efforts. > Those I-Ds are not final by any means, but at least they are something > that the group can refine over time. Which is exactly what the current > charter text says. However, I'm sure we can improve things slightly. > > How about this? > > *** > > Work processes and technical requirements for achieving the foregoing > objectives are outlined in draft-valin-codec-guidelines and > draft-valin-codec-requirements respectively; these documents will form > the starting point for working toward consensus and will be refined by > the group in accordance with the usual IETF procedures. > > *** > >>> >> Intellectual property rights (IPR) issues will be handled in accordance >>> >> with BCP 78 and BCP 79. Many existing codecs with the technical >>> >> attributes listed above are encumbered with licensing fees and other IPR >>> >> claims that make royalty-free and wide distribution and use across the >>> >> Internet community difficult. The group will try to standardize codecs >>> >> that can be relatively freely and easily distributed, and employed as >>> >> much as possible. In doing so, it will adhere closely to these BCPs. >>> >> More specifically, "In general, IETF working groups prefer technologies >>> >> with no known IPR claims or, for technologies with claims against them, >>> >> an offer of royalty-free licensing." Note that in accordance with BCP >>> >> 79, the group will not explicitly rule out the possibility of adopting >>> >> technology that does not meet these IPR requirements; such decisions >>> >> will be made in accordance with the rough consensus of the group. >>> >> >>> >> Deliverables >>> >> >>> >> 1. Guidelines that define the work process of the group, using >>> >> draft-valin-codec-guidelines as the basis for achieving consensus. This >>> >> document shall be Informational. >>> >> >>> >> 2. Detailed technical requirements, using draft-valin-codec-requirements >>> >> as the basis for achieving consensus. This document shall be >> > Informational. >> > >> > Again, I would suggest to change it to "Guidelines that defined the work >> > process of the group define in a common codec-guidelines document." and >> > "Detailed technical requirements defined in a common codec-guidelines >> > document." due to the same reasons. > > In my working copy I have changed these to: > > *** > > 1. Guidelines that define the work process of the group, using > draft-valin-codec-guidelines as the starting point for working > toward consensus. This document shall be Informational. > > 2. Detailed technical requirements, using > draft-valin-codec-requirementsas the starting point for working > toward consensus. This document shall be Informational. > > *** > > Does that text address your concerns? > >>> >> 3. Specification of one or more codecs that meet the agreed-upon >>> >> requirements, in the form of Internet-Drafts that define the codec >>> >> algorithm and source code for a reference implementation. The text >>> >> description of each codec shall indicate which components of the encoder >>> >> and decoder are mandatory, recommended, and optional. It is envisioned >>> >> that each such specification shall be a Proposed Standard document. >>> >> >>> >> Milestones >>> >> >>> >> Mar-2010: WGLC on Codec Standardization Guidelines >>> >> Mar-2010: WGLC on Requirements >>> >> May-2010: Codec Standardization Guidelines to IESG (Informational) >>> >> May-2010: Requirements to IESG (Infomational) >> > +r >>> >> Oct-2010: WGLC on codec specification(s) >>> >> Jan-2011: Submit codec specification(s) to IESG (Standards Track) >> > >> > This is an ambitious schedule. In my opinion the danger of not keeping this >> > schedule is high. But then again, who cares... > > You're right that it is aggressive. But it seems that we have a core > group of energetic contributors and that we might be able to make fast > progress if the WG is approved. But perhaps giving ourselves a few more > months here and there would be appropriate. > > So perhaps this is slightly more realistic yet still ambitious: > > *** > > Mar-2010: WGLC on Codec Standardization Guidelines > May-2010: Codec Standardization Guidelines to IESG (Informational) > May-2010: WGLC on Requirements > Jul-2010: Requirements to IESG (Infomational) > Feb-2011: WGLC on codec specification(s) > Apr-2011: Submit codec specification(s) to IESG (Standards Track) > > *** > >> > All other parts are fine for me. > > Thanks again for your feedback. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrY4c0ACgkQNL8k5A2w/vzmNgCgy4XHU9FgFCdomRzFGftFoKrx > unMAn0f6r7zkfLVjUCPdWJtazfgy5kAa > =n0pQ > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --B_3338700709_17878 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [codec] proposed charter Codecs optimized for very low bit rates (typically below 2.4 kbps) and
codecs for non-interactive audio are out of scope because they might
necessitate specialized optimizations.

This is an excellent formulation IMO.

Thanks, Henry


On 10/16/09 4:12 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:

<= SPAN STYLE=3D'font-size:14pt'>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/09 7:52 AM, Christian Hoene wrote:
> Dear Peter Saint-Andre and all,
>
> inline you will find my personal comments to the proposed charter.

Thank you for your feedback.

>> PROPOSED CHARTER
>>
>> Problem Statement
>>
>> There are no standardized, high-quality audio codecs that are opti= mized
>> for use in interactive Internet applications and that can be widel= y
>> implemented and easily distributed among  application develop= ers,
>> service operators, and end users.  This gap in the Internet p= rotocol
>> stack has hindered protocol designers from being able to specify >> mandatory-to-implement codecs in their protocols for the sake of >> interoperability, developers from building innovative, interactive=
>> applications, service operators from deploying affordable, high-qu= ality
>> services, and end users from enjoying an optimal user experience.<= BR> >> Because the Internet Standards Process defines an open, transparen= t
>> process for technology standardization, a wide range of codec expe= rts
>> have committed to actively working on such codecs within the IETF.=  The
>> Codec WG provides a structured forum for these efforts.
>
> Sounds good!
>
>> Objectives
>>
>> The goal of this group is to develop one or more high-quality,
>> widely-distributable audio codecs that is optimized for use over t= he
>> Internet. Core considerations include the following:
>>
>> 1. Use in interactive applications (examples include but are not l= imited
>> to point-to-point voice calls, multi-party voice conferencing,
>> telepresence, teleoperation, in-game voice chat, and live music > performance)
>> 2. Addressing the real transport conditions of the Internet, espec= ially
>> packet loss
>
> I do not understand this last consideration. What do you mean with thi= s
> statement? Are packet losses the only attribute of transmissions over = the
> Internet?

By no means. The word "especially" does not exclude other conditi= ons
that might be important to consider.

> At least it has been agreed upon that jitter compensation is also
> relevant. I would suggest to rephrase this requirement to "Addres= sing the
> real transport conditions of the Internet. Important attributes of pac= ket
> transmissions over the Internet are identified in cooperation with oth= er
> IETF working groups such as AVT and DCCP."

I think it might be more productive to say this:

***

2. Addressing the real transport conditions of the Internet as
identified and prioritized by the group

***

It's not really the task of the charter to define the real transport
conditions of the Internet, but if we include this is an objective of
the group then they should certainly keep those conditions in mind as
they complete their work.

>> 3. Ensuring interoperability with the Real-time Transport Protocol=
>> (RTP), including secure transport via SRTP
>>
>> 4. Ensuring interoperability with Internet signalling technologies= such
>> as Session Initiation Protocol (SIP), Session Description Protocol=
>> (SDP), and Extensible Messaging and Presence Protocol (XMPP)
>>
>> Codecs optimized for very low bit rates
>
> Traditionally, very low bit codecs are operating below 2.4 kbps. It mi= ght
> not be known to the Internet guys.

Added.

>> and codecs for non-interactive
>> audio are out of scope.
>
> Maybe you can add "because they require other kind of optimizatio= ns".

In my working copy I have changed this to:

***

Codecs optimized for very low bit rates (typically below 2.4 kbps) and
codecs for non-interactive audio are out of scope because they might
necessitate specialized optimizations.

***

> BTW:
> Do you address multicast, too? If not, mention it here.

By "multicast" do you mean many-to-many or one-to-many? We talk a= bit
about that in the requirements draft.

>> Although the codec(s) produced by the group might be used as
>> mandatory-to-implement technologies by designers of particular Int= ernet
>> protocols, it is explicitly not a goal of the group to produce a c= odec
>> that will be mandated for use across the entire IETF or Internet > community.
>> The group might produce only one codec or it might produce multipl= e
>> codecs; however, to reduce confusion in the marketplace it shall >> endeavor not to function as a "codec factory" that produ= ces a large
>> number of codecs.
>
> I would suggest to remove the part after the semicolon. Instead, maybe= add
> something like "The codec(s) shall be address a large range of ty= pical
> transmission conditions on the Internet."

Your proposed addition does not talk about the point you propose to
remove (i.e., we are not going to produce dozens of codecs) and the
point you add here is discussed elsewhere in the charter. Therefore I'm
not in favor of this change.

>> Work processes and technical requirements for achieving the forego= ing
>> objectives are outlined in draft-valin-codec-guidelines and
>> draft-valin-codec-requirements respectively; these will be further=
>> refined by the group in accordance with the usual IETF procedures = for
>> arriving at rough consensus.
>
> I think it is problematic to predefine a draft that must be chosen.
I think it is problematic to mention no Internet-Drafts in the charter.
The existing I-Ds will form the starting point for work within the
group. Whether those I-Ds will remain as they are today (I doubt that
they will) is up to the group.

> A
> critical minded person might think that this standardization process i= s a
> put-up affair. Instead, it is in good tradition of the IETF that the b= est
> technical approach should win. Just imagine that you codec experts can= not
> agree on a common requirements document or that other codec guys make = a
> better proposal. We should allow competition because this leads to bet= ter
> technical solutions. Thus, I suggest to change it in "... outline= d in a
> codec-guidelines draft such as the draft-valin-codec-guidelines-01 and= in a
> codec-requirements draft such as draft-valin-codec-requirements-01
> respectively; ..."?

The "such as" here is not especially helpful as guidance to the g= roup or
as part of our contract with the IESG. Given that no one else on this
list has even mentioned the possibility of working on Internet-Drafts
for the procedural guidelines or technical requirements, I think it is
best to show the IESG that the published I-Ds are available for
inspection and will form the starting point of the group's efforts.
Those I-Ds are not final by any means, but at least they are something
that the group can refine over time. Which is exactly what the current
charter text says. However, I'm sure we can improve things slightly.

How about this?

***

Work processes and technical requirements for achieving the foregoing
objectives are outlined in draft-valin-codec-guidelines and
draft-valin-codec-requirements respectively; these documents will form
the starting point for working toward consensus and will be refined by
the group in accordance with the usual IETF procedures.

***

>> Intellectual property rights (IPR) issues will be handled in accor= dance
>> with BCP 78 and BCP 79. Many existing codecs with the technical >> attributes listed above are encumbered with licensing fees and oth= er IPR
>> claims that make royalty-free and wide distribution and use across= the
>> Internet community difficult.  The group will try to standard= ize codecs
>> that can be relatively freely and easily distributed, and employed= as
>> much as possible. In doing so, it will adhere closely to these BCP= s.
>> More specifically, "In general, IETF working groups prefer te= chnologies
>> with no known IPR claims or, for technologies with claims against = them,
>> an offer of royalty-free licensing."  Note that in accor= dance with BCP
>> 79, the group will not explicitly rule out the possibility of adop= ting
>> technology that does not meet these IPR requirements; such decisio= ns
>> will be made in accordance with the rough consensus of the group.<= BR> >>
>> Deliverables
>>
>> 1. Guidelines that define the work process of the group, using
>> draft-valin-codec-guidelines as the basis for achieving consensus.= This
>> document shall be Informational.
>>
>> 2. Detailed technical requirements, using draft-valin-codec-requir= ements
>> as the basis for achieving consensus.  This document shall be=
> Informational.
>
> Again, I would suggest to change it to "Guidelines that defined t= he work
> process of the group define in a common codec-guidelines document.&quo= t; and
> "Detailed technical requirements defined in a common codec-guidel= ines
> document." due to the same reasons.

In my working copy I have changed these to:

***

1. Guidelines that define the work process of the group, using
draft-valin-codec-guidelines as the starting point for working
toward consensus. This document shall be Informational.

2. Detailed technical requirements, using
draft-valin-codec-requirementsas the starting point for working
toward consensus.  This document shall be Informational.

***

Does that text address your concerns?

>> 3. Specification of one or more codecs that meet the agreed-upon >> requirements, in the form of Internet-Drafts that define the codec=
>> algorithm and source code for a reference implementation. The text=
>> description of each codec shall indicate which components of the e= ncoder
>> and decoder are mandatory, recommended, and optional.  It is = envisioned
>> that each such specification shall be a Proposed Standard document= .
>>
>> Milestones
>>
>> Mar-2010: WGLC on Codec Standardization Guidelines
>> Mar-2010: WGLC on Requirements
>> May-2010: Codec Standardization Guidelines to IESG (Informational)=
>> May-2010: Requirements to IESG (Infomational)
> +r
>> Oct-2010: WGLC on codec specification(s)
>> Jan-2011: Submit codec specification(s) to IESG (Standards Track)<= BR> >
> This is an ambitious schedule. In my opinion the danger of not keeping= this
> schedule is high. But then again, who cares...

You're right that it is aggressive. But it seems that we have a core
group of energetic contributors and that we might be able to make fast
progress if the WG is approved. But perhaps giving ourselves a few more
months here and there would be appropriate.

So perhaps this is slightly more realistic yet still ambitious:

***

Mar-2010: WGLC on Codec Standardization Guidelines
May-2010: Codec Standardization Guidelines to IESG (Informational)
May-2010: WGLC on Requirements
Jul-2010: Requirements to IESG (Infomational)
Feb-2011: WGLC on codec specification(s)
Apr-2011: Submit codec specification(s) to IESG (Standards Track)

***

> All other parts are fine for me.

Thanks again for your feedback.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - h= ttp://enigmail.mozdev.org/

iEYEARECAAYFAkrY4c0ACgkQNL8k5A2w/vzmNgCgy4XHU9FgFCdomRzFGftFoKrx
unMAn0f6r7zkfLVjUCPdWJtazfgy5kAa
=3Dn0pQ
-----END PGP SIGNATURE-----
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec

--B_3338700709_17878-- From henry@sinnreich.net Sun Oct 18 06:53:50 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD2B3A6832 for ; Sun, 18 Oct 2009 06:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLaIcRjOxJ7D for ; Sun, 18 Oct 2009 06:53:46 -0700 (PDT) Received: from outbound-mail-110.bluehost.com (outbound-mail-110.bluehost.com [69.89.22.10]) by core3.amsl.com (Postfix) with SMTP id EBF4B3A67FB for ; Sun, 18 Oct 2009 06:53:45 -0700 (PDT) Received: (qmail 8945 invoked by uid 0); 18 Oct 2009 13:53:52 -0000 Received: from unknown (HELO box522.bluehost.com) (74.220.219.122) by outboundproxy3.bluehost.com with SMTP; 18 Oct 2009 13:53:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=sinnreich.net; h=Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:Thread-Index:In-Reply-To:Mime-version:Content-type:X-Identified-User; b=Ar+m2WHme7exPYK+BHpmYLTv36Q+OFNpk+hLE8LjJqGSRSuZLPetRV2B7zIp3UNPT+FZQUry5LvesLE+P4/x/iscsUBKwSAVOBMSUkVVAULXAZW2du9OeG8Y1tdrq01b; Received: from ool-457670fb.dyn.optonline.net ([69.118.112.251] helo=[10.0.1.17]) by box522.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MzWCl-0008Il-FP; Sun, 18 Oct 2009 07:53:51 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 18 Oct 2009 08:53:49 -0500 From: "henry@sinnreich.net" To: Peter Saint-Andre , Jean-Marc Valin Message-ID: Thread-Topic: [codec] proposed charter Thread-Index: AcpOobCSDH84jFkNQN+uBeNpyARSdgBWLp8/ In-Reply-To: <4AD8DB89.30300@stpeter.im> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3338700831_52095" X-Identified-User: {35212:box522.bluehost.com:sinnreic:sinnreich.net} {sentby:smtp auth 69.118.112.251 authed with henry@sinnreich.net} X-Mailman-Approved-At: Sun, 18 Oct 2009 06:56:28 -0700 Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 13:53:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3338700831_52095 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >IMHO the text "Core considerations *include the following*... >" and "Ensuring interoperability with Internet signalling >technologies *such as*..." shows that these considerations are by no >means exclusive. This seems to me a good formulation. Maybe it is useful to clarify the generic idea that signaling dependent codecs are out of scope =AD naturally. Thanks, Henry On 10/16/09 3:46 PM, "Peter Saint-Andre" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 10/9/09 11:43 AM, Jean-Marc Valin wrote: >=20 >> > Regarding the charter, the intent of objectives 2, 3 and 4 was to >> > specify the operating environment we were primarily targeting, which i= s >> > the Internet. Also, the main reason for mentioning RTP/SIP/SDP/SRTP/XM= PP >> > was to acknowledge that these protocols are important for the IETF and >> > thus that the codec designers should ensure that the codec fits well >> > with these protocols and not to do anything that would create >> > interoperability issues. As Henry pointed out, this can be interpreted >> > as implying that we would not consider other protocols on the Internet= , >> > but this was not the intent here. We should probably make that clearer= . >=20 > Correct. Ensuring interoperability with those parts of the IETF protocol > stack doesn't imply that the WG will ignore interoperability with any > other protocols. IMHO the text "Core considerations *include the > following*..." and "Ensuring interoperability with Internet signalling > technologies *such as*..." shows that these considerations are by no > means exclusive. >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkrY24kACgkQNL8k5A2w/vxDbACeKMwX7f/JXzda2U4T4uI4uFyi > yZIAni8GCDJVHJDtipx3Y7oWMJ2qRP2l > =3Dxl9n > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 --B_3338700831_52095 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] proposed charter >IMHO the text "Core considerations *include the following*...
>" and "Ensuring interoperability with Internet signalling
>technologies *such as*..." shows that these considerations are by = no
>means exclusive.

This seems to me a good formulation.
Maybe it is useful to clarify the generic idea that signaling dependent cod= ecs are out of scope – naturally.

Thanks, Henry


On 10/16/09 3:46 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:

<= SPAN STYLE=3D'font-size:14pt'>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/9/09 11:43 AM, Jean-Marc Valin wrote:

> Regarding the charter, the intent of objectives 2, 3 and 4 was to
> specify the operating environment we were primarily targeting, which i= s
> the Internet. Also, the main reason for mentioning RTP/SIP/SDP/SRTP/XM= PP
> was to acknowledge that these protocols are important for the IETF and=
> thus that the codec designers should ensure that the codec fits well > with these protocols and not to do anything that would create
> interoperability issues. As Henry pointed out, this can be interpreted=
> as implying that we would not consider other protocols on the Internet= ,
> but this was not the intent here. We should probably make that clearer= .

Correct. Ensuring interoperability with those parts of the IETF protocol stack doesn't imply that the WG will ignore interoperability with any
other protocols. IMHO the text "Core considerations *include the
following*..." and "Ensuring interoperability with Internet signa= lling
technologies *such as*..." shows that these considerations are by no means exclusive.

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - h= ttp://enigmail.mozdev.org/

iEYEARECAAYFAkrY24kACgkQNL8k5A2w/vxDbACeKMwX7f/JXzda2U4T4uI4uFyi
yZIAni8GCDJVHJDtipx3Y7oWMJ2qRP2l
=3Dxl9n
-----END PGP SIGNATURE-----
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec

--B_3338700831_52095-- From stpeter@stpeter.im Mon Oct 19 11:38:11 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977A33A68B9 for ; Mon, 19 Oct 2009 11:38:11 -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 vhnKPFlpvHOs for ; Mon, 19 Oct 2009 11:38:10 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C385E3A6781 for ; Mon, 19 Oct 2009 11:38:07 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BC41440D12; Mon, 19 Oct 2009 12:38:14 -0600 (MDT) Message-ID: <4ADCB216.8000501@stpeter.im> Date: Mon, 19 Oct 2009 12:38:14 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "henry@sinnreich.net" References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 18:38:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/18/09 7:53 AM, henry@sinnreich.net wrote: >>IMHO the text "Core considerations *include the following*... >>" and "Ensuring interoperability with Internet signalling >>technologies *such as*..." shows that these considerations are by no >>means exclusive. > > This seems to me a good formulation. > Maybe it is useful to clarify the generic idea that signaling dependent > codecs are out of scope – naturally. Yes, that seems reasonable. Thanks for the suggestion. I shall post a revised version of the proposed charter soon. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrcshUACgkQNL8k5A2w/vz1xgCfY4DYWksRHU88NHiEMLMRlNJW 428AoJzu1a/XTUBp7XCjL63E1kUkbxD6 =dzhl -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Oct 19 15:57:48 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1747B3A695C for ; Mon, 19 Oct 2009 15:57:48 -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 AHvXLmgWyRYy for ; Mon, 19 Oct 2009 15:57:47 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E6ABF3A6914 for ; Mon, 19 Oct 2009 15:57:43 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C6FA440D0B; Mon, 19 Oct 2009 16:57:50 -0600 (MDT) Message-ID: <4ADCEEED.8060300@stpeter.im> Date: Mon, 19 Oct 2009 16:57:49 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 22:57:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/7/09 4:27 PM, Stephan Wenger wrote: > Thanks, Peter. > > I find most of my comments adequately addressed, and in some other cases we > can agree to disagree without another discussion at this point in time. OK, that seems reasonable. > The > one thing I want to comment on, hopefully constructively, is this: > >>> 16: Section 5, "royalty-free". Finally, this reasonably precise term is >>> used. Why not earlier? >> Because royalty-free is one method for achieving the goal of easily >> distributable. It is not, however, the only method. >> >>> However, just before that, the subject of open >>> source compatibility is mentioned as well (though not in this formulation). >>> Please note that it is very easy to draft a patent license that is >>> royalty-free and NOT open source compatible. Similarly, I would argue that >>> a good percentage of the RF licensing covenants in IETF IPR disclosures (in >>> contrast to most non-assert covenants) are not compatible with the majority >>> of the open source licenses in practical use. If you wish to express a >>> desire for compatibility with open source models, then you may want to >>> express this early on, in precise terms, and not with ambiguous language >>> such as "free" and "open". >> This might need to be tightened up further. >> > > > Let me give it a try. Replace the original paragraph > >> In accordance with BCP 78 [TRUST], the source code for the reference >> implementation should be available under the BSD license or whatever >> license is defined as acceptable by the IETF Trust when the relevant >> Internet-Drafts are published. Also, in accordance with BCP 79 >> [IPR], the codecs should preferably use technologies with no known >> IPR claims or technologies with an offer of royalty-free (RF) >> licensing. Compatibility with the licensing of typical open source >> applications requires the avoidance of restrictive IPR claims. > > With > > " > In accordance with BCP 78 [TRUST], the source code for the reference > implementation should be available under the BSD-style license or whatever > license is defined as acceptable by the IETF Trust when the relevant > Internet-Drafts are published. > > In accordance with the spirit of BCP 79 [IPR], the codecs should preferably > use technologies with no known IPR claims, technologies available under > patent non-assert covenants, or technologies with an offer of royalty-free > (RF) licensing (in this order of preference). Among other goals, adhering > to these preferences should help achieving compatibility with the patent > licensing requirements of most open source licenses, thereby allowing for > open source applications of the specified codec(s). > " > > Motivation: > 1. BCP78 compliance of the reference software has nothing to do with > avoidance of patents of the algorithm, so the two should not be placed in > the same paragraph. > 2. I added non-assert covenants. As I mentioned before, non-assert > covenants are typically better for open source license compatibility than > mere RF licensing covenants, unless those RF licensing covenants are > intentionally worded to be friendly/compatible to open source. Few of the > RF licensing covenants posted in the IETF's IPR database are open source > compatible at the time of writing (yes, I have reviewed all of them :-) > 3. Expressing a preference of unencumbered-by-known-patents -> non-assert -> > RF-licensing-commitment makes sense as it increases the chances of a "legal" > open source implementation. Thank you for your suggested text. I am not a lawyer and even when I think about "IPR" issues it is in relation to copyrights, not patents, so I will need to do a bit of research and thinking before I am comfortable adding the text you have provided. On the face of it, your text does seem to capture the intent behind the current text, but I just want to give it a bit more thought before I make any changes to the I-D. > P.s.: Please note that I'm sending this in order to help you guys to express > what I believe are your intentions. I haven't changed my mind on viability > of the exercise proposed, nor on my preference of the choice of venue for > codec development. Fair enough. I appreciate your generosity. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrc7u0ACgkQNL8k5A2w/vwqFQCfTSHU+cfQ1aMiX8IzdzAPb0rl cAoAoJ4UbLuFowsQdEWT0TRhjdhRruOr =27vH -----END PGP SIGNATURE----- From eburger@standardstrack.com Tue Oct 20 13:15:09 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E323A6964 for ; Tue, 20 Oct 2009 13:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 q1cDu76NIwx4 for ; Tue, 20 Oct 2009 13:15:09 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 463193A68B9 for ; Tue, 20 Oct 2009 13:15:06 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.32.49]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1N0L6r-0004Lv-48 for codec@ietf.org; Tue, 20 Oct 2009 13:15:09 -0700 Message-Id: <483774E9-7374-4459-BD85-C79D8AA96AE8@standardstrack.com> From: Eric Burger To: codec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Oct 2009 16:15:11 -0400 X-Mailer: Apple Mail (2.936) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [codec] Interesting IEEE Comm Mag Section on ITU-T Standards X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 20:15:10 -0000 The most recent issue (October 2009, V. 47 n. 10) of IEEE Communications Magazine has a special section of interest to us here on Speech Coding. Ask a friend if you do not have access to the IEEE Xplore library or a hard copy. From stpeter@stpeter.im Tue Oct 20 14:42:46 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E76A3A6857 for ; Tue, 20 Oct 2009 14:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 OtRBetXVlWhD for ; Tue, 20 Oct 2009 14:42:45 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 251323A6784 for ; Tue, 20 Oct 2009 14:42:45 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0E01540D0B for ; Tue, 20 Oct 2009 15:42:50 -0600 (MDT) Message-ID: <4ADE2ED9.2030101@stpeter.im> Date: Tue, 20 Oct 2009 15:42:49 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 21:42:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Per recent list discussion... ###### Proposed Charter for Codec WG Last Updated: 2009-10-20 Problem Statement There are no standardized, high-quality audio codecs that are optimized for use in interactive Internet applications and that can be widely implemented and easily distributed among application developers, service operators, and end users. This gap in the Internet protocol stack has hindered protocol designers from being able to specify mandatory-to-implement codecs in their protocols for the sake of interoperability, developers from building innovative, interactive applications, service operators from deploying affordable, high-quality services, and end users from enjoying an optimal user experience. Because the Internet Standards Process defines an open, transparent process for technology standardization, a wide range of codec experts have committed to actively working on such codecs within the IETF. The Codec WG provides a structured forum for these efforts. Objectives The goal of this group is to develop one or more high-quality, widely-distributable audio codecs that is optimized for use over the Internet. Core considerations include but are not necessarily limited to the following: 1. Use in interactive applications (examples include but are not limited to point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the group 3. Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signalling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, signalling-dependent codecs are out of scope Codecs optimized for very low bit rates (typically below 2.4 kbps) and codecs for non-interactive audio are out of scope because they might necessitate specialized optimizations. Although the codec(s) produced by the group might be used as mandatory-to-implement technologies by designers of particular Internet protocols, it is explicitly not a goal of the group to produce a codec that will be mandated for use across the entire IETF or Internet community. The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor not to function as a "codec factory" that produces a large number of codecs. Work processes and technical requirements for achieving the foregoing objectives are outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and will be refined by the group in accordance with the usual IETF procedures. Intellectual property rights (IPR) issues will be handled in accordance with BCP 78 and BCP 79. Many existing codecs with the technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use across the Internet community difficult. The group will try to standardize codecs that can be relatively freely and easily distributed, and employed as much as possible. In doing so, it will adhere closely to these BCPs. More specifically, "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Note that in accordance with BCP 79, the group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; such decisions will be made in accordance with the rough consensus of the group. Deliverables 1. Guidelines that define the work process of the group, using draft-valin-codec-guidelines as the starting point for working toward consensus. This document shall be Informational. 2. Detailed technical requirements, using draft-valin-codec-requirements as the starting point for working toward consensus. This document shall be Informational. 3. Specification of one or more codecs that meet the agreed-upon requirements, in the form of Internet-Drafts that define the codec algorithm and source code for a reference implementation. The text description of each codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that each such specification shall be a Proposed Standard document. Milestones Mar-2010: WGLC on Codec Standardization Guidelines May-2010: Codec Standardization Guidelines to IESG (Informational) May-2010: WGLC on Requirements Jul-2010: Requirements to IESG (Infomational) Mar-2011: WGLC on codec specification(s) Jun-2011: Submit codec specification(s) to IESG (Standards Track) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkreLtkACgkQNL8k5A2w/vwxcACeOQvIqWty+cUynAc3d3h8XbMA /eoAoNomjEgkTahDyFLfIFH+zTxYSWGI =MT0M -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Oct 20 14:52:11 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9DD3A698C for ; Tue, 20 Oct 2009 14:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 EVFtbINIeX35 for ; Tue, 20 Oct 2009 14:52:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 600BA3A69EA for ; Tue, 20 Oct 2009 14:51:39 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8BF4540D0B for ; Tue, 20 Oct 2009 15:51:47 -0600 (MDT) Message-ID: <4ADE30F2.6080800@stpeter.im> Date: Tue, 20 Oct 2009 15:51:46 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] BoF chairs X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 21:52:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce that Eric Burger has volunteered to co-chair the Codec BoF with me in Hiroshima. It's doubtful that either of us would co-chair the WG (if approved), but the two of us are working hard to ensure that we'll have a productive session at IETF 76. Thanks, Eric! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkreMPIACgkQNL8k5A2w/vxvOgCgwEi57ejYKoQZDlFHJ1sFgw34 Us8AoK707HUZ9Sn40EDwEQjdXmidHBGq =STzD -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Tue Oct 20 16:03:13 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8433A681A for ; Tue, 20 Oct 2009 16:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uptGvSV8L8-j for ; Tue, 20 Oct 2009 16:03:12 -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 114F63A67B6 for ; Tue, 20 Oct 2009 16:03:11 -0700 (PDT) Received: by ywh13 with SMTP id 13so8386478ywh.29 for ; Tue, 20 Oct 2009 16:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=E0zf2ZeVhSLJ3d6IwsPXC8MRB6JdSJ9yth2xHYoPi+c=; b=pGnMZk7/6FMiyChydx6Iz/7IhSgJtkxGpgZ5XYZIhZzMiVvJgrpJ8vDOLYIgwkDFsO bsYI+f8B4b/jvAI5oVhexSqDZ72kBwF7MOHVHt8M/t0CHOk3uTy2z5mbWpNFfGTvzBD2 7DCRvNLlxinKYeR5OEhm1AAV4sZb+ajLbWbP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=vp2E3UHAQbVIj1j9+hcN84+BDHI5IiWTE9wOecxoGqacjF63afOeDfS1D5AvUzGcKo cHnq7bSD6VBwPROkCi0X0zGfu7BsQTNEeSZqML5YOkFDtGb2PHpRiZSG6TYOZdVkT9y7 RAK6T9c2mZJ1/TFLa3IdDVukcT9bFeIzvz7ec= Received: by 10.150.243.5 with SMTP id q5mr11761986ybh.13.1256079796304; Tue, 20 Oct 2009 16:03:16 -0700 (PDT) Received: from YOUR6108 ([190.178.65.144]) by mx.google.com with ESMTPS id 13sm239491gxk.1.2009.10.20.16.03.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Oct 2009 16:03:14 -0700 (PDT) From: "rontlv" To: "'Peter Saint-Andre'" , References: <4ADE2ED9.2030101@stpeter.im> In-Reply-To: <4ADE2ED9.2030101@stpeter.im> Date: Wed, 21 Oct 2009 01:03:29 +0200 Message-ID: <4ade41b2.0d0bca0a.1063.1a56@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpRzkxgisJIkfBcQnmH5xCaWrYhpwACRW5A Content-Language: he Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:03:13 -0000 Hi, I did not have time to review the charter proposal being on vacation. I would like to bring my major concern about " The goal of this group is to develop one or more codecs" . My view is that the one of the major reason for lack of deployment of wideband is that there are too many wideband codecs. For example in high quality video conferencing you may need to support G.719 and flavors of AAC full band codecs to interoperate at full band with all the current products. I also find it strange that the timeline has one date for all codecs that will be developed since I do not see any synchronization process between all the codecs that will be approved if a WG is formed. I think that having the right to do multiple codecs as part of the charter will cause the group to approve all proposed codecs probably rubberstamping them instead of going to collaboration on one good codec. I think that the initial charter should have one codec and if later there will be a need there should be a re-charter. A minor comment is on "Because the Internet Standards Process defines an open, transparent process for technology standardization, a wide range of codec experts have committed to actively working on such codecs within the IETF. The Codec WG provides a structured forum for these efforts." I am not sure why this text is part of the charter. Being a little sarcastic about the commitment, I did not see the flexibility of the experts when they needed to devote time for the IETF meeting. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Tuesday, October 20, 2009 11:43 PM > To: codec@ietf.org > Subject: [codec] updated charter proposal > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Per recent list discussion... > > ###### > > Proposed Charter for Codec WG > Last Updated: 2009-10-20 > > Problem Statement > > There are no standardized, high-quality audio codecs that are optimized > for use in interactive Internet applications and that can be widely > implemented and easily distributed among application developers, > service operators, and end users. This gap in the Internet protocol > stack has hindered protocol designers from being able to specify > mandatory-to-implement codecs in their protocols for the sake of > interoperability, developers from building innovative, interactive > applications, service operators from deploying affordable, high-quality > services, and end users from enjoying an optimal user experience. > Because the Internet Standards Process defines an open, transparent > process for technology standardization, a wide range of codec experts > have committed to actively working on such codecs within the IETF. > The Codec WG provides a structured forum for these efforts. > > Objectives > > The goal of this group is to develop one or more high-quality, > widely-distributable audio codecs that is optimized for use over the > Internet. Core considerations include but are not necessarily limited > to the following: > > 1. Use in interactive applications (examples include but are not > limited to point-to-point voice calls, multi-party voice conferencing, > telepresence, teleoperation, in-game voice chat, and live music > performance) > > 2. Addressing the real transport conditions of the Internet as > identified and prioritized by the group > > 3. Ensuring interoperability with the Real-time Transport Protocol > (RTP), including secure transport via SRTP > > 4. Ensuring interoperability with Internet signalling technologies such > as Session Initiation Protocol (SIP), Session Description Protocol > (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, > signalling-dependent codecs are out of scope > > Codecs optimized for very low bit rates (typically below 2.4 kbps) and > codecs for non-interactive audio are out of scope because they might > necessitate specialized optimizations. > > Although the codec(s) produced by the group might be used as > mandatory-to-implement technologies by designers of particular Internet > protocols, it is explicitly not a goal of the group to produce a codec > that will be mandated for use across the entire IETF or Internet > community. > > The group might produce only one codec or it might produce multiple > codecs; however, to reduce confusion in the marketplace it shall > endeavor not to function as a "codec factory" that produces a large > number of codecs. > > Work processes and technical requirements for achieving the foregoing > objectives are outlined in draft-valin-codec-guidelines and > draft-valin-codec-requirements respectively; these documents will form > the starting point for working toward consensus and will be refined by > the group in accordance with the usual IETF procedures. > > Intellectual property rights (IPR) issues will be handled in accordance > with BCP 78 and BCP 79. Many existing codecs with the technical > attributes listed above are encumbered with licensing fees and other > IPR > claims that make royalty-free and wide distribution and use across the > Internet community difficult. The group will try to standardize codecs > that can be relatively freely and easily distributed, and employed as > much as possible. In doing so, it will adhere closely to these BCPs. > More specifically, "In general, IETF working groups prefer technologies > with no known IPR claims or, for technologies with claims against them, > an offer of royalty-free licensing." Note that in accordance with BCP > 79, the group will not explicitly rule out the possibility of adopting > technology that does not meet these IPR requirements; such decisions > will be made in accordance with the rough consensus of the group. > > Deliverables > > 1. Guidelines that define the work process of the group, using > draft-valin-codec-guidelines as the starting point for working toward > consensus. This document shall be Informational. > > 2. Detailed technical requirements, using draft-valin-codec- > requirements > as the starting point for working toward consensus. This document > shall be Informational. > > 3. Specification of one or more codecs that meet the agreed-upon > requirements, in the form of Internet-Drafts that define the codec > algorithm and source code for a reference implementation. The text > description of each codec shall indicate which components of the > encoder > and decoder are mandatory, recommended, and optional. It is envisioned > that each such specification shall be a Proposed Standard document. > > Milestones > > Mar-2010: WGLC on Codec Standardization Guidelines > May-2010: Codec Standardization Guidelines to IESG (Informational) > May-2010: WGLC on Requirements > Jul-2010: Requirements to IESG (Infomational) > Mar-2011: WGLC on codec specification(s) > Jun-2011: Submit codec specification(s) to IESG (Standards Track) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkreLtkACgkQNL8k5A2w/vwxcACeOQvIqWty+cUynAc3d3h8XbMA > /eoAoNomjEgkTahDyFLfIFH+zTxYSWGI > =MT0M > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4527 (20091020) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4527 (20091020) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From brian@freeswitch.org Tue Oct 20 16:34:07 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D6B28C10F for ; Tue, 20 Oct 2009 16:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32keCT5I2jRS for ; Tue, 20 Oct 2009 16:34:06 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 9B6D93A681A for ; Tue, 20 Oct 2009 16:34:06 -0700 (PDT) Received: by ewy28 with SMTP id 28so7016751ewy.42 for ; Tue, 20 Oct 2009 16:34:11 -0700 (PDT) Received: by 10.216.89.82 with SMTP id b60mr187440wef.170.1256081651284; Tue, 20 Oct 2009 16:34:11 -0700 (PDT) Received: from ?192.168.1.39? ([99.184.96.129]) by mx.google.com with ESMTPS id m5sm984090gve.26.2009.10.20.16.34.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Oct 2009 16:34:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Brian West In-Reply-To: <4ade41b2.0d0bca0a.1063.1a56@mx.google.com> Date: Tue, 20 Oct 2009 18:34:07 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4ADE2ED9.2030101@stpeter.im> <4ade41b2.0d0bca0a.1063.1a56@mx.google.com> To: rontlv X-Mailer: Apple Mail (2.1075.2) Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:34:07 -0000 G.719 will never take off unless Ericsson gets off their part of the IP and actually will disclose the licensing details without having to sign an NDA. /b On Oct 20, 2009, at 6:03 PM, rontlv wrote: > For example in high quality video conferencing you may need to > support G.719 > and flavors of AAC full band codecs to interoperate at full band > with all > the current products. From hoene@uni-tuebingen.de Wed Oct 21 01:22:44 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F8B3A6768 for ; Wed, 21 Oct 2009 01:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wUXPfeM4Izb for ; Wed, 21 Oct 2009 01:22:41 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 46DC53A67EB for ; Wed, 21 Oct 2009 01:22:40 -0700 (PDT) Received: from hoeneLenovoT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9L8MkLo003125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2009 10:22:46 +0200 From: "Christian Hoene" To: "'rontlv'" , "'Peter Saint-Andre'" , References: <4ADE2ED9.2030101@stpeter.im> <4ade41b2.0d0bca0a.1063.1a56@mx.google.com> In-Reply-To: <4ade41b2.0d0bca0a.1063.1a56@mx.google.com> Date: Wed, 21 Oct 2009 10:22:46 +0200 Message-ID: <00b901ca5227$abf9afb0$03ed0f10$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpRzkxgisJIkfBcQnmH5xCaWrYhpwACRW5AABNHzFA= Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.42; VDF: 7.1.6.129; host: mx05); id=26784-wXtDjY Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:22:44 -0000 Hello, > I would like to bring my major concern about > " The goal of this group is to develop one or more codecs" . My view is that > the one of the major reason for lack of deployment of wideband is that there > are too many wideband codecs. > For example in high quality video conferencing you may need to support G.719 > and flavors of AAC full band codecs to interoperate at full band with all > the current products. ... > I think that having the right to do multiple codecs as part of the charter > will cause the group to approve all proposed codecs probably rubberstamping > them instead of going to collaboration on one good codec. I think that the > initial charter should have one codec and if later there will be a need > there should be a re-charter. I have to agree to Roni Even. This sentence and also the entire paragraph remain unclear. I have understood that the questions on how many codecs and on which to select are going to be solved by rough consensus. However, till now I do not see in the charter any consensus nor statements on high level selection or merging criteria. How could you decide on a codec in short time, when you cannot agree on general selection statements? In my previous email on the charter I try to address this point with the statement that "The codec(s) shall address a large range of typical transmission conditions on the Internet." However, maybe there is a consensus on the statement: "Every offered codec is selected" following the old Roman saying "Don't look a gift horse in the mouth". Or on some beauty contest... Whatsoever, the paragraph remains too vague for me. Christian > Roni Even > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > > Of Peter Saint-Andre > > Sent: Tuesday, October 20, 2009 11:43 PM > > To: codec@ietf.org > > Subject: [codec] updated charter proposal > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Per recent list discussion... > > > > ###### > > > > Proposed Charter for Codec WG > > Last Updated: 2009-10-20 > > > > Problem Statement > > > > There are no standardized, high-quality audio codecs that are optimized > > for use in interactive Internet applications and that can be widely > > implemented and easily distributed among application developers, > > service operators, and end users. This gap in the Internet protocol > > stack has hindered protocol designers from being able to specify > > mandatory-to-implement codecs in their protocols for the sake of > > interoperability, developers from building innovative, interactive > > applications, service operators from deploying affordable, high-quality > > services, and end users from enjoying an optimal user experience. > > Because the Internet Standards Process defines an open, transparent > > process for technology standardization, a wide range of codec experts > > have committed to actively working on such codecs within the IETF. > > The Codec WG provides a structured forum for these efforts. > > > > Objectives > > > > The goal of this group is to develop one or more high-quality, > > widely-distributable audio codecs that is optimized for use over the > > Internet. Core considerations include but are not necessarily limited > > to the following: > > > > 1. Use in interactive applications (examples include but are not > > limited to point-to-point voice calls, multi-party voice conferencing, > > telepresence, teleoperation, in-game voice chat, and live music > > performance) > > > > 2. Addressing the real transport conditions of the Internet as > > identified and prioritized by the group > > > > 3. Ensuring interoperability with the Real-time Transport Protocol > > (RTP), including secure transport via SRTP > > > > 4. Ensuring interoperability with Internet signalling technologies such > > as Session Initiation Protocol (SIP), Session Description Protocol > > (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, > > signalling-dependent codecs are out of scope > > > > Codecs optimized for very low bit rates (typically below 2.4 kbps) and > > codecs for non-interactive audio are out of scope because they might > > necessitate specialized optimizations. > > > > Although the codec(s) produced by the group might be used as > > mandatory-to-implement technologies by designers of particular Internet > > protocols, it is explicitly not a goal of the group to produce a codec > > that will be mandated for use across the entire IETF or Internet > > community. > > > > The group might produce only one codec or it might produce multiple > > codecs; however, to reduce confusion in the marketplace it shall > > endeavor not to function as a "codec factory" that produces a large > > number of codecs. > > > > Work processes and technical requirements for achieving the foregoing > > objectives are outlined in draft-valin-codec-guidelines and > > draft-valin-codec-requirements respectively; these documents will form > > the starting point for working toward consensus and will be refined by > > the group in accordance with the usual IETF procedures. > > > > Intellectual property rights (IPR) issues will be handled in accordance > > with BCP 78 and BCP 79. Many existing codecs with the technical > > attributes listed above are encumbered with licensing fees and other > > IPR > > claims that make royalty-free and wide distribution and use across the > > Internet community difficult. The group will try to standardize codecs > > that can be relatively freely and easily distributed, and employed as > > much as possible. In doing so, it will adhere closely to these BCPs. > > More specifically, "In general, IETF working groups prefer technologies > > with no known IPR claims or, for technologies with claims against them, > > an offer of royalty-free licensing." Note that in accordance with BCP > > 79, the group will not explicitly rule out the possibility of adopting > > technology that does not meet these IPR requirements; such decisions > > will be made in accordance with the rough consensus of the group. > > > > Deliverables > > > > 1. Guidelines that define the work process of the group, using > > draft-valin-codec-guidelines as the starting point for working toward > > consensus. This document shall be Informational. > > > > 2. Detailed technical requirements, using draft-valin-codec- > > requirements > > as the starting point for working toward consensus. This document > > shall be Informational. > > > > 3. Specification of one or more codecs that meet the agreed-upon > > requirements, in the form of Internet-Drafts that define the codec > > algorithm and source code for a reference implementation. The text > > description of each codec shall indicate which components of the > > encoder > > and decoder are mandatory, recommended, and optional. It is envisioned > > that each such specification shall be a Proposed Standard document. > > > > Milestones > > > > Mar-2010: WGLC on Codec Standardization Guidelines > > May-2010: Codec Standardization Guidelines to IESG (Informational) > > May-2010: WGLC on Requirements > > Jul-2010: Requirements to IESG (Infomational) > > Mar-2011: WGLC on codec specification(s) > > Jun-2011: Submit codec specification(s) to IESG (Standards Track) > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.8 (Darwin) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAkreLtkACgkQNL8k5A2w/vwxcACeOQvIqWty+cUynAc3d3h8XbMA > > /eoAoNomjEgkTahDyFLfIFH+zTxYSWGI > > =MT0M > > -----END PGP SIGNATURE----- > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 4527 (20091020) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 4527 (20091020) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From lars.eggert@nokia.com Wed Oct 21 03:07:10 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF183A67F8 for ; Wed, 21 Oct 2009 03:07:10 -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 eUq4sLAcIFX0 for ; Wed, 21 Oct 2009 03:07:09 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 5A6623A67DF for ; Wed, 21 Oct 2009 03:07:09 -0700 (PDT) Received: from wlan-226.fit.nokia.com (wlan-226.fit.nokia.com [195.148.124.226]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9LA7AuT094202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Oct 2009 13:07:10 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-1-787039418; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4ADE2ED9.2030101@stpeter.im> Date: Wed, 21 Oct 2009 13:07:09 +0300 Message-Id: References: <4ADE2ED9.2030101@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Wed, 21 Oct 2009 13:07:10 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 10:07:10 -0000 --Apple-Mail-1-787039418 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, the current charter text is starting to look OK. I'd like to raise one point below where I think we're missing a requirement. To put this in perspective: I'm still not convinced that the IETF should actually start this work until we've clarified with the ITU-T/ 3GPP/MPEG/etc. how this intersects with their work. But that's an orthogonal issue. If we were to start work, the current charter is looking reasonable. Maybe modulo what I'm going to say next... On 2009-10-21, at 0:42, Peter Saint-Andre wrote: > The goal of this group is to develop one or more high-quality, > widely-distributable audio codecs that is optimized for use over the > Internet. Core considerations include but are not necessarily limited > to the following: > > 1. Use in interactive applications (examples include but are not > limited to point-to-point voice calls, multi-party voice conferencing, > telepresence, teleoperation, in-game voice chat, and live music > performance) > > 2. Addressing the real transport conditions of the Internet as > identified and prioritized by the group > > 3. Ensuring interoperability with the Real-time Transport Protocol > (RTP), including secure transport via SRTP > > 4. Ensuring interoperability with Internet signalling technologies > such > as Session Initiation Protocol (SIP), Session Description Protocol > (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, > signalling-dependent codecs are out of scope The Internet uses a distributed congestion control mechanism built around the notion that when a flow observes packet loss, it is suppose to reduce its sending rate in some form over some time, in order to take load off a congested path. This behavior is something that I (as a transport guy) would see as a key differentiator between an "Internet codec" and a "telco codec", and I'd like to suggest that we reflect this in the charter in some form. We can certainly argue about how useful this behavior would be in a low-bitrate voice codec. But it's my understanding that this effort isn't really targeting those, but is instead looking at wideband codecs - maybe ones using substantial levels of redundancy in the encoding - that can consume some noticeable amount of bandwidth. For those sorts of voice codecs, and even more so for video codecs, which have been brought up as the next logical thing for a potential CODEC WG to target, some sort of congestion-responsiveness is important when they are sharing path capacity over the Internet. See for example http://tools.ietf.org/html/draft-westerlund-avt-ecn-for-rtp for ongoing work related to exposing congestion information to media streams earlier than through packet loss (i.e., using ECN). To be perfectly clear: This is NOT about enforcing TCP-friendliness or forcing the resulting codecs to conform to some other strict behavior under congestion. Due to the complexities of each coding scheme, how soon and by how much it can react to path congestion will be extremely codec-specific. But the idea is to recommend (or maybe even require) for "Internet codecs" to react appropriately to path congestion when they can. Thoughts? Lars --Apple-Mail-1-787039418 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyMTEwMDcxMFowIwYJKoZIhvcNAQkEMRYEFIDAGTLqRMtaBzWgnKUqw7DgXfTqMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC+80ck+b93PA2J6DnzAhAsWqiFNxytBntalnl/hYTxFwV/knsizq7peEtxOfsKwOXjwu9W UzGmzopz/SpvU5KyDDd58rWKI5mgD68KzQYEXERxMf+4DFZe5nFd+t++/pWPIwgqDSgi11U6obzp 9zDBOU1wQAQqutJ6FX7jKF1kSniUEFHNQCMEF1xNbRQtT05XR+h4Ce2vX/OxC+gYE/LgO3G5lkfE uUYDmta0Vdo4j0FbgHYAdHC6n48F4LNw/trOcOgHrVgnwvhQmkyZB+/JzdAb79J1SUUA2HbM8dzF PrxynlFIw3nVQ470bKJmN2oHKJDKLjynmmDHsMY4su3sAAAAAAAA --Apple-Mail-1-787039418-- From stewe@stewe.org Wed Oct 21 04:40:21 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C8D3A6A05 for ; Wed, 21 Oct 2009 04:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd9IBGEX7w9n for ; Wed, 21 Oct 2009 04:40:20 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 24C0B3A68F1 for ; Wed, 21 Oct 2009 04:40:17 -0700 (PDT) Received: from [192.168.1.104] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 467051-1743317 for multiple; Wed, 21 Oct 2009 13:40:25 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 21 Oct 2009 04:40:13 -0700 From: Stephan Wenger To: Lars Eggert , Peter Saint-Andre Message-ID: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpSQ0BjhhJRGCI2fkG6KfSdDKG1hw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:40:21 -0000 Hi Lars, On 10/21/09 3:07 AM, "Lars Eggert" wrote: > [...] > To be perfectly clear: This is NOT about enforcing TCP-friendliness or > forcing the resulting codecs to conform to some other strict behavior > under congestion. Due to the complexities of each coding scheme, how > soon and by how much it can react to path congestion will be extremely > codec-specific. But the idea is to recommend (or maybe even require) > for "Internet codecs" to react appropriately to path congestion when > they can. > > Thoughts? The traditional solution to achieve network-dictated (or suggested) bitrate adaptivity is a scalable bitstream. G.729.1 would be one example in the audio space, and the SVC profiles of H.264 one in the video space. The result of dropping layers in a scalable codec is reduced fidelity. Whether users accept such a reduced fidelity depends IMHO mostly on the application. To make one audio-centric example, in cheap/free desktop (video) conferencing, dropping from wideband audio to telephony band speech in case of congestion seems entirely reasonably, and is implemented in several products I'm aware of. For a music streaming/distribution service, the story would be very different. That is, in part, why those services put heavy FEC on their unelastic media streams (quite to the contrary of the intention of congestion control), or fall back to TCP transport with multisecond buffers. Adding scalability support to the requirements (perhaps at "SHOULD" level) may make sense. Or, at least, other ways of supporting network-dictated variable bitrates, for example in the way the quantizer in MPEG'solder audio codecs work (not that a lot of people use those mechanisms for bandwidth adaptivity...). Both ways lead into patent minefields, though. In video, in contrast to audio, a real-time encoder has an ample number of parameters to vary the outgoing bandwidth. Most encoders operating under real-time constraints play with those parameters constantly in a mechanism that is commonly known as rate control. They have to, because without rate control the outgoing bitrate is variable over several orders of magnitude, depending on content complexity. Adding a network-dictated, pseudo-variable target bitrate to the list of input parameters a rate control has to obey is almost trivial. Implementing something along these lines is common for point-to-point video with real-time encoders. Still, if that bitrate is too low, your quality goes down into an unacceptable range. But then, if you get excessive losses due to congestion, your quality sucks, too. When operating with non real-time encoders, or in multipoint scenarios without transcoding, scalability is the technology of choice for bandwidth adaptation. All modern standardized video codecs offer scalability in one form or another. The SVC payload format draft contains quite a few words on this subject. Regards, Stephan From hoene@uni-tuebingen.de Wed Oct 21 04:45:49 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DECD83A68C4 for ; Wed, 21 Oct 2009 04:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PixOSiNT9vLZ for ; Wed, 21 Oct 2009 04:45:49 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 9702B3A68EC for ; Wed, 21 Oct 2009 04:45:48 -0700 (PDT) Received: from hoeneLenovoT60 (eap111024.extern.uni-tuebingen.de [134.2.111.24]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9LBjsWL008861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2009 13:45:54 +0200 From: "Christian Hoene" To: "'Lars Eggert'" , References: <4ADE2ED9.2030101@stpeter.im> In-Reply-To: Date: Wed, 21 Oct 2009 13:45:55 +0200 Message-ID: <00da01ca5244$0d0b0440$27210cc0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpSNlAoFq4QMuLqRKaA3UFtmiG5TQAB7ozQ Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.42; VDF: 7.1.6.131; host: mx05); id=26784-eIeH4m Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:45:50 -0000 Dear Lars Eggert, > The Internet uses a distributed congestion control mechanism built > around the notion that when a flow observes packet loss, it is suppose > to reduce its sending rate in some form over some time, in order to > take load off a congested path. This behavior is something that I (as > a transport guy) would see as a key differentiator between an > "Internet codec" and a "telco codec", and I'd like to suggest that we > reflect this in the charter in some form. > > We can certainly argue about how useful this behavior would be in a > low-bitrate voice codec. But it's my understanding that this effort > isn't really targeting those, but is instead looking at wideband > codecs - maybe ones using substantial levels of redundancy in the > encoding - that can consume some noticeable amount of bandwidth. For > those sorts of voice codecs, and even more so for video codecs, which > have been brought up as the next logical thing for a potential CODEC > WG to target, some sort of congestion-responsiveness is important when > they are sharing path capacity over the Internet. > > See for example http://tools.ietf.org/html/draft-westerlund-avt-ecn-for-rtp > for ongoing work related to exposing congestion information to media > streams earlier than through packet loss (i.e., using ECN). > > To be perfectly clear: This is NOT about enforcing TCP-friendliness or > forcing the resulting codecs to conform to some other strict behavior > under congestion. Due to the complexities of each coding scheme, how > soon and by how much it can react to path congestion will be extremely > codec-specific. But the idea is to recommend (or maybe even require) > for "Internet codecs" to react appropriately to path congestion when > they can. Since months I am raising this point on this mailing list. I suggested to establish a procedure on how transport and codec expert should work together to address these issues. However, based on the comments on this mailing list, I have the impression that this is not wanted. I just remember some statements such as that we are "only interested in a narrow area." I do have the impression that it is not intended to address the fundamental problems of frequently bad VoIP quality or to enhance the Quality of Experience - which would require to consider transport issues - but only in making codecs. Hopefully, my observation is wrong. With best regards, Christian Hoene From lars.eggert@nokia.com Wed Oct 21 04:56:59 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4873A681B for ; Wed, 21 Oct 2009 04:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRxk43DsYm8Q for ; Wed, 21 Oct 2009 04:56:58 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 5F9FB3A6858 for ; Wed, 21 Oct 2009 04:56:58 -0700 (PDT) Received: from wlan-226.fit.nokia.com (wlan-226.fit.nokia.com [195.148.124.226]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9LBuxKx001118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Oct 2009 14:56:59 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-12-793629122; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <00da01ca5244$0d0b0440$27210cc0$@de> Date: Wed, 21 Oct 2009 14:56:59 +0300 Message-Id: References: <4ADE2ED9.2030101@stpeter.im> <00da01ca5244$0d0b0440$27210cc0$@de> To: Christian Hoene X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Wed, 21 Oct 2009 14:56:59 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:56:59 -0000 --Apple-Mail-12-793629122 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-21, at 14:45, Christian Hoene wrote: > Since months I am raising this point on this mailing list. I > suggested to > establish a procedure on how transport and codec expert should work > together > to address these issues. I'm sorry if I missed this - I cannot follow this email list very regularly. Lars --Apple-Mail-12-793629122 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyMTExNTY2MFowIwYJKoZIhvcNAQkEMRYEFKo3vp9JDtXSuFqOB82wYu49jhz5MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQB4+5dax0FBlcu/KZ1lq1MOchsXwBMw99Tph71+5QTars36+u0/449XKigFQbXZZ/EHHY08 CQT+w030UMHYz7O+XrqESLlks5nbJjUTPlnAQuQwJOFLKhpcQ7YOR1VhMPtXw4mQXr+6Ycz9eswp oWHQrNtYRSSWoR+RvuGVHU2jTnyBiQWrqQyMjRZHEJYHCye6OncK74Effi3Qnl9DOxPVAU64b7jw Fre942UF4dFgOLOkLPqH8k+Ak5tiTct/b9EXEfWrv58nWS66RdVtKBgQ5UzZDGUWf3RBjac8wsb9 XG+B5wK9otBoqMVHK6eSKQ3oVRDSCSB+ABTlw4z57xgSAAAAAAAA --Apple-Mail-12-793629122-- From Borilin@spiritdsp.com Wed Oct 21 04:57:18 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1903A691D for ; Wed, 21 Oct 2009 04:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEfOGwCAr1OO for ; Wed, 21 Oct 2009 04:57:18 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id B737E3A68B1 for ; Wed, 21 Oct 2009 04:57:17 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9LBvOsR058305; Wed, 21 Oct 2009 15:57:24 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 15:57:18 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpSQ0BjhhJRGCI2fkG6KfSdDKG1hwAAimMg References: From: "Slava Borilin" To: "Stephan Wenger" , "Lars Eggert" , "Peter Saint-Andre" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:57:18 -0000 Stephan, You are absolutely right on scalability and its benefits - that's what we are doing in SPIRIT IP-MR codec (http://tools.ietf.org/search/draft-spiritdsp-ipmr-00) for many years already. best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Wednesday, October 21, 2009 3:40 PM To: Lars Eggert; Peter Saint-Andre Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Hi Lars, On 10/21/09 3:07 AM, "Lars Eggert" wrote: > [...] > To be perfectly clear: This is NOT about enforcing TCP-friendliness or > forcing the resulting codecs to conform to some other strict behavior > under congestion. Due to the complexities of each coding scheme, how > soon and by how much it can react to path congestion will be extremely > codec-specific. But the idea is to recommend (or maybe even require) > for "Internet codecs" to react appropriately to path congestion when > they can. >=20 > Thoughts? The traditional solution to achieve network-dictated (or suggested) bitrate adaptivity is a scalable bitstream. G.729.1 would be one example in the audio space, and the SVC profiles of H.264 one in the video space. The result of dropping layers in a scalable codec is reduced fidelity. Whether users accept such a reduced fidelity depends IMHO mostly on the application. =20 To make one audio-centric example, in cheap/free desktop (video) conferencing, dropping from wideband audio to telephony band speech in case of congestion seems entirely reasonably, and is implemented in several products I'm aware of. For a music streaming/distribution service, the story would be very different. That is, in part, why those services put heavy FEC on their unelastic media streams (quite to the contrary of the intention of congestion control), or fall back to TCP transport with multisecond buffers. Adding scalability support to the requirements (perhaps at "SHOULD" level) may make sense. Or, at least, other ways of supporting network-dictated variable bitrates, for example in the way the quantizer in MPEG'solder audio codecs work (not that a lot of people use those mechanisms for bandwidth adaptivity...). Both ways lead into patent minefields, though. In video, in contrast to audio, a real-time encoder has an ample number of parameters to vary the outgoing bandwidth. Most encoders operating under real-time constraints play with those parameters constantly in a mechanism that is commonly known as rate control. They have to, because without rate control the outgoing bitrate is variable over several orders of magnitude, depending on content complexity. Adding a network-dictated, pseudo-variable target bitrate to the list of input parameters a rate control has to obey is almost trivial. Implementing something along these lines is common for point-to-point video with real-time encoders. Still, if that bitrate is too low, your quality goes down into an unacceptable range. But then, if you get excessive losses due to congestion, your quality sucks, too. When operating with non real-time encoders, or in multipoint scenarios without transcoding, scalability is the technology of choice for bandwidth adaptation. All modern standardized video codecs offer scalability in one form or another. The SVC payload format draft contains quite a few words on this subject. Regards, Stephan _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hsinnrei@adobe.com Wed Oct 21 06:13:23 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7813A6823 for ; Wed, 21 Oct 2009 06:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2AH9pb-UMz9 for ; Wed, 21 Oct 2009 06:13:13 -0700 (PDT) Received: from psmtp.com (exprod6ob117.obsmtp.com [64.18.1.38]) by core3.amsl.com (Postfix) with ESMTP id 5E5E73A63EB for ; Wed, 21 Oct 2009 06:13:12 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKSt8I78AHIjxO4ZbmecS9H53YaT/SWgZO@postini.com; Wed, 21 Oct 2009 06:13:22 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9LD6Dao003985; Wed, 21 Oct 2009 06:06:13 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9LDDJlT020449; Wed, 21 Oct 2009 06:13:19 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 21 Oct 2009 06:13:19 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Wed, 21 Oct 2009 06:13:18 -0700 From: Henry Sinnreich To: Peter Saint-Andre , "codec@ietf.org" Date: Wed, 21 Oct 2009 06:13:15 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpRzn6GnMwqx/IdT1quuZdfK9Es/wAgcD9O Message-ID: In-Reply-To: <4ADE2ED9.2030101@stpeter.im> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C704731B67C7hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 13:13:23 -0000 --_000_C704731B67C7hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This proposed charter for the Codec WG is indeed fine tuned to the needs of= the Internet and its users. IMO it should be left as it is. No doubt, the opposition to the Internet codecs concept will continue, so l= et's insure not to allow it being a distraction from moving on with the act= ual work on the codec architecture, hopefully one or more reference impleme= ntations and reports on test results - far more productive than endless mai= l discussions. So can we now please move on to the actual design documents? Design proposals and reference code enhancements instead of objections? Are any of the codec designers willing to set up a web site as is usual for= OS projects? Should an Internet codec development web site (or more than one) be sponsor= ed by the proposed WG? Conceptual precedent: SIP Forum and its SIPit interoperability testing even= ts - the codec web sites will obviously be different, but the intent can be= similar. My strict personal 2 cents, including the na=EFve questions, Henry On 10/20/09 4:42 PM, "Peter Saint-Andre" wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Per recent list discussion... ###### Proposed Charter for Codec WG Last Updated: 2009-10-20 Problem Statement There are no standardized, high-quality audio codecs that are optimized for use in interactive Internet applications and that can be widely implemented and easily distributed among application developers, service operators, and end users. This gap in the Internet protocol stack has hindered protocol designers from being able to specify mandatory-to-implement codecs in their protocols for the sake of interoperability, developers from building innovative, interactive applications, service operators from deploying affordable, high-quality services, and end users from enjoying an optimal user experience. Because the Internet Standards Process defines an open, transparent process for technology standardization, a wide range of codec experts have committed to actively working on such codecs within the IETF. The Codec WG provides a structured forum for these efforts. Objectives The goal of this group is to develop one or more high-quality, widely-distributable audio codecs that is optimized for use over the Internet. Core considerations include but are not necessarily limited to the following: 1. Use in interactive applications (examples include but are not limited to point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the group 3. Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signalling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, signalling-dependent codecs are out of scope Codecs optimized for very low bit rates (typically below 2.4 kbps) and codecs for non-interactive audio are out of scope because they might necessitate specialized optimizations. Although the codec(s) produced by the group might be used as mandatory-to-implement technologies by designers of particular Internet protocols, it is explicitly not a goal of the group to produce a codec that will be mandated for use across the entire IETF or Internet community. The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor not to function as a "codec factory" that produces a large number of codecs. Work processes and technical requirements for achieving the foregoing objectives are outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and will be refined by the group in accordance with the usual IETF procedures. Intellectual property rights (IPR) issues will be handled in accordance with BCP 78 and BCP 79. Many existing codecs with the technical attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use across the Internet community difficult. The group will try to standardize codecs that can be relatively freely and easily distributed, and employed as much as possible. In doing so, it will adhere closely to these BCPs. More specifically, "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Note that in accordance with BCP 79, the group will not explicitly rule out the possibility of adopting technology that does not meet these IPR requirements; such decisions will be made in accordance with the rough consensus of the group. Deliverables 1. Guidelines that define the work process of the group, using draft-valin-codec-guidelines as the starting point for working toward consensus. This document shall be Informational. 2. Detailed technical requirements, using draft-valin-codec-requirements as the starting point for working toward consensus. This document shall be Informational. 3. Specification of one or more codecs that meet the agreed-upon requirements, in the form of Internet-Drafts that define the codec algorithm and source code for a reference implementation. The text description of each codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that each such specification shall be a Proposed Standard document. Milestones Mar-2010: WGLC on Codec Standardization Guidelines May-2010: Codec Standardization Guidelines to IESG (Informational) May-2010: WGLC on Requirements Jul-2010: Requirements to IESG (Infomational) Mar-2011: WGLC on codec specification(s) Jun-2011: Submit codec specification(s) to IESG (Standards Track) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkreLtkACgkQNL8k5A2w/vwxcACeOQvIqWty+cUynAc3d3h8XbMA /eoAoNomjEgkTahDyFLfIFH+zTxYSWGI =3DMT0M -----END PGP SIGNATURE----- _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C704731B67C7hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal This proposed charter for the Codec WG is indeed fine tuned to the ne= eds of the Internet and its users.
IMO it should be left as it is.

No doubt, the opposition to the Internet codecs concept will continue, so l= et’s insure not to allow it being a distraction from moving on with t= he actual work on the codec architecture, hopefully one or more reference i= mplementations and reports on test results – far more productive than= endless mail discussions.

So can we now please move on to the actual design documents?
Design proposals and reference code enhancements instead of objections?

Are any of the codec designers willing to set up a web site as is usual for= OS projects?
Should an Internet codec development web site (or more than one) be sponsor= ed by the proposed WG?
Conceptual precedent: SIP Forum and its SIPit interoperability testing even= ts – the codec web sites will obviously be different, but the intent = can be similar.

My strict personal 2 cents, including the naïve questions,

Henry


On 10/20/09 4:42 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Per recent list discussion...

######

Proposed Charter for Codec WG
Last Updated: 2009-10-20

Problem Statement

There are no standardized, high-quality audio codecs that are optimized
for use in interactive Internet applications and that can be widely
implemented and easily distributed among  application developers,
service operators, and end users.  This gap in the Internet protocol stack has hindered protocol designers from being able to specify
mandatory-to-implement codecs in their protocols for the sake of
interoperability, developers from building innovative, interactive
applications, service operators from deploying affordable, high-quality
services, and end users from enjoying an optimal user experience.
Because the Internet Standards Process defines an open, transparent
process for technology standardization, a wide range of codec experts
have committed to actively working on such codecs within the IETF.
The Codec WG provides a structured forum for these efforts.

Objectives

The goal of this group is to develop one or more high-quality,
widely-distributable audio codecs that is optimized for use over the
Internet. Core considerations include but are not necessarily limited
to the following:

1. Use in interactive applications (examples include but are not
limited to point-to-point voice calls, multi-party voice conferencing,
telepresence, teleoperation, in-game voice chat, and live music
performance)

2. Addressing the real transport conditions of the Internet as
identified and prioritized by the group

3. Ensuring interoperability with the Real-time Transport Protocol
(RTP), including secure transport via SRTP

4. Ensuring interoperability with Internet signalling technologies such
as Session Initiation Protocol (SIP), Session Description Protocol
(SDP), and Extensible Messaging and Presence Protocol (XMPP); however,
signalling-dependent codecs are out of scope

Codecs optimized for very low bit rates (typically below 2.4 kbps) and
codecs for non-interactive audio are out of scope because they might
necessitate specialized optimizations.

Although the codec(s) produced by the group might be used as
mandatory-to-implement technologies by designers of particular Internet
protocols, it is explicitly not a goal of the group to produce a codec
that will be mandated for use across the entire IETF or Internet community.=

The group might produce only one codec or it might produce multiple
codecs; however, to reduce confusion in the marketplace it shall
endeavor not to function as a "codec factory" that produces a lar= ge
number of codecs.

Work processes and technical requirements for achieving the foregoing
objectives are outlined in draft-valin-codec-guidelines and
draft-valin-codec-requirements respectively; these documents will form
the starting point for working toward consensus and will be refined by
the group in accordance with the usual IETF procedures.

Intellectual property rights (IPR) issues will be handled in accordance
with BCP 78 and BCP 79. Many existing codecs with the technical
attributes listed above are encumbered with licensing fees and other IPR claims that make royalty-free and wide distribution and use across the
Internet community difficult.  The group will try to standardize codec= s
that can be relatively freely and easily distributed, and employed as
much as possible. In doing so, it will adhere closely to these BCPs.
More specifically, "In general, IETF working groups prefer technologie= s
with no known IPR claims or, for technologies with claims against them,
an offer of royalty-free licensing."  Note that in accordance wit= h BCP
79, the group will not explicitly rule out the possibility of adopting
technology that does not meet these IPR requirements; such decisions
will be made in accordance with the rough consensus of the group.

Deliverables

1. Guidelines that define the work process of the group, using
draft-valin-codec-guidelines as the starting point for working toward
consensus. This document shall be Informational.

2. Detailed technical requirements, using draft-valin-codec-requirements as the starting point for working toward consensus.  This document
shall be Informational.

3. Specification of one or more codecs that meet the agreed-upon
requirements, in the form of Internet-Drafts that define the codec
algorithm and source code for a reference implementation. The text
description of each codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional.  It is envisione= d
that each such specification shall be a Proposed Standard document.

Milestones

Mar-2010: WGLC on Codec Standardization Guidelines
May-2010: Codec Standardization Guidelines to IESG (Informational)
May-2010: WGLC on Requirements
Jul-2010: Requirements to IESG (Infomational)
Mar-2011: WGLC on codec specification(s)
Jun-2011: Submit codec specification(s) to IESG (Standards Track)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkreLtkACgkQNL8k5A2w/vwxcACeOQvIqWty+cUynAc3d3h8XbMA
/eoAoNomjEgkTahDyFLfIFH+zTxYSWGI
=3DMT0M
-----END PGP SIGNATURE-----
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C704731B67C7hsinnreiadobecom_-- From jean-marc.valin@octasic.com Wed Oct 21 06:27:23 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3803A687A for ; Wed, 21 Oct 2009 06:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xhVnsLtRR7A for ; Wed, 21 Oct 2009 06:27:22 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id E13973A6811 for ; Wed, 21 Oct 2009 06:27:21 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:27:29 -0400 Message-ID: <4ADF0C41.3010808@octasic.com> Date: Wed, 21 Oct 2009 09:27:29 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Lars Eggert References: <4ADE2ED9.2030101@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 13:27:29.0524 (UTC) FILETIME=[3CDAAB40:01CA5252] Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 13:27:23 -0000 Hi, Lars Eggert wrote: > The Internet uses a distributed congestion control mechanism built > around the notion that when a flow observes packet loss, it is suppose > to reduce its sending rate in some form over some time, in order to take > load off a congested path. This behavior is something that I (as a > transport guy) would see as a key differentiator between an "Internet > codec" and a "telco codec", and I'd like to suggest that we reflect this > in the charter in some form. I totally agree that the bit-rate should adapt to network congestion. This is why the requirements draft includes "Having the possibility to use smooth bit-rate changes with one byte/frame resolution". This means that the codec can produce any rate that is needed to avoid congestion (not just a few pre-selected ones). Now, we must be careful to assign issues to the correct "layer" in the VoIP stack. I do not believe it is the codec's job to *decide* which bit-rate to select. This should be left to another component of the application (the RTP stack?), which can then tell the codec what bit-rate to use. If there are more features that the codec can add to help with congestion, this is certainly something we can add to the drafts. Scalable codecs have also been discussed. I don't like the word because people seem to use it for different meanings. In one meaning it is simply the ability to use any rate, which is addressed above. In the other meaning, it means having layers that can be stripped off. I believe this can be a useful feature (which *is* listed in the current drafts), but mostly for conferencing, rather than congestion. The point of layered codec for congestion in particular is that a router in the middle can reduce the bit-rate to adjust to congestion. However, I see two problems here: 1) most routers does not (and should not have) knowledge of the codec and thus cannot change the rate; and 2) layers are usually larger than a single byte per frame so relying only on a layered approach might compromise the idea of having small bit-rate increments. But as I said earlier, I'm not opposed to layered codecs because they have other uses. This is something that would have to be carefully analysed during development. > To be perfectly clear: This is NOT about enforcing TCP-friendliness or > forcing the resulting codecs to conform to some other strict behavior > under congestion. Due to the complexities of each coding scheme, how > soon and by how much it can react to path congestion will be extremely > codec-specific. But the idea is to recommend (or maybe even require) for > "Internet codecs" to react appropriately to path congestion when they can. OK, I may be wrong here, but my understanding is that how much the rate should change depending on congestion is actually not that codec-specific. I get the impression that the tough part is figuring out what rate you can use without causing packets to be dropped. Once you figure this out, you can just tell the codec to use that rate. On top of that, the codec may be able to do a bit better by providing a "service" to the other layers. On example here (also included in the draft) is VBR, which means that the application specifies an average rate and the codec decides how to vary the rate to achieve that (subject to some rate control constraints). Would other such mechanisms be useful to deal with congestion? Cheers, Jean-Marc From mramalho@cisco.com Wed Oct 21 06:57:09 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B153A694D for ; Wed, 21 Oct 2009 06:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EirElcT8Bbl5 for ; Wed, 21 Oct 2009 06:57:08 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A07313A6934 for ; Wed, 21 Oct 2009 06:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=6389; q=dns/txt; s=sjiport02001; t=1256133437; x=1257343037; 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"Michael=20Ramalho=20(mramalho)"=20|Subject:=20RE:=20[codec]=20updated=20charter=20pr oposal|Date:=20Wed,=2021=20Oct=202009=2009:57:15=20-0400 |Message-ID:=20|To:=20"Jean-Marc=20Valin"=20< jean-marc.valin@octasic.com>,=0D=0A=20=20=20=20=20=20=20 =20"Lars=20Eggert"=20|Cc:=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|In-Reply-To:=20<4ADF0C41.3010808@octa sic.com>|References:=20<4ADE2ED9.2030101@stpeter.im>=20<4ADF0C41.3 010808@octasic.com>; bh=ZsWggYTtRrfTH/PB/uDQoUls78OLtoPiZWdswj39R2Q=; b=ZOB6BfLMxKGgeB3sCJjFSjfLWT3fXUzVzBMZqPU08Siob1wskfFSrbGQ ITv9ILKtATVOlvrgRooZHItNjxEtXYUiVGd2Px+Y/K9RPd0jdmygdUOBy PfrIDvF5ipHA1tAWiwvxGuWyhY3hA5DtVLTLMXK49vNa6+ko5DwGEwHUH A=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAqw3kqrR7Ht/2dsb2JhbADCfJhYhDEE X-IronPort-AV: E=Sophos;i="4.44,597,1249257600"; d="scan'208";a="216495225" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2009 13:57:17 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LDvHJh006273; Wed, 21 Oct 2009 13:57:17 GMT Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:57:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 09:57:15 -0400 Message-ID: In-Reply-To: <4ADF0C41.3010808@octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpSUkAEgP7Xu+xXSeKhN4ux2hD4hQAAPGeA References: <4ADE2ED9.2030101@stpeter.im> <4ADF0C41.3010808@octasic.com> From: "Michael Ramalho (mramalho)" To: "Jean-Marc Valin" , "Lars Eggert" X-OriginalArrivalTime: 21 Oct 2009 13:57:15.0437 (UTC) FILETIME=[65575DD0:01CA5256] Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 13:57:10 -0000 All, Just a thought for everyone. Prior to the last BoF I posted email that suggested that the codec should have an ability to change encoding rate as a function of some form of congestion intelligence (perhaps through an API, perhaps a hint at the RTP layer, perhaps on a congestion indication, etc.). That "should" was not necessarily a "must" because a given application may tell the codec to go full steam ahead anyway because what it knows about the transport environment. And I think that wording has been accommodated. Consider Jean-Marc's words: "I get the impression that the tough part is figuring out what rate you can use without causing packets to be dropped." Indeed. Consider the case where the bottleneck link for your end-to-end codec application (where most of your packets are being dropped) is such that all the UDP traffic (e.g., your VoIP and other UDP applications) is a minority traffic. That is, the majority of traffic is TCP-friendly (TCP, SCTP, etc.). And that the bandwidth of this link is large relative to your VoIP stream. Now suppose that this link is someplace in one of the middle hops of your end-to-end flow. That link is being "filled up" (and causing drops for your flow) according to the TCP dynamics of the other TCP traffic. Virtually NOTHING YOU DO ON YOUR FLOW will have a significant impact on your packet drop performance! Any bandwidth you "vacate" by reducing your rate becomes "absorbed" (in a sense) by the TCP flows sharing the remainder of the bandwidth. If your application somehow (magically) knew this was the case, perhaps it would NOT reduce rate. Now that isn't TCP friendly. And some codec designs actually increase rate in those cases (by reducing rate all they can - but then adding FEC bandwidth to the lowest rate). I think the best we can do here is to design in the knobs to have the codec change rate (or add FEC if that is a codec capability) to accommodate scenarios such as the above. Michael Ramalho PS - As a side note, if the bottleneck link had majority traffic consisting of similar VoIP flows - the correct behavior would be to reduce rate as TCP does. That is why the answer for a link dominated by ITSP traffic would be to reduce rate. And this is why the VoIP application ideally would benefit from "other intelligence" regarding congestion properties. -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Wednesday, October 21, 2009 9:27 AM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Hi, Lars Eggert wrote: > The Internet uses a distributed congestion control mechanism built=20 > around the notion that when a flow observes packet loss, it is suppose > to reduce its sending rate in some form over some time, in order to take=20 > load off a congested path. This behavior is something that I (as a=20 > transport guy) would see as a key differentiator between an "Internet=20 > codec" and a "telco codec", and I'd like to suggest that we reflect this=20 > in the charter in some form. I totally agree that the bit-rate should adapt to network congestion. This=20 is why the requirements draft includes "Having the possibility to use=20 smooth bit-rate changes with one byte/frame resolution". This means that the codec can produce any rate that is needed to avoid congestion (not just=20 a few pre-selected ones). Now, we must be careful to assign issues to the=20 correct "layer" in the VoIP stack. I do not believe it is the codec's job=20 to *decide* which bit-rate to select. This should be left to another=20 component of the application (the RTP stack?), which can then tell the=20 codec what bit-rate to use. If there are more features that the codec can add to help with congestion,=20 this is certainly something we can add to the drafts. Scalable codecs have=20 also been discussed. I don't like the word because people seem to use it for different meanings. In one meaning it is simply the ability to use any=20 rate, which is addressed above. In the other meaning, it means having=20 layers that can be stripped off. I believe this can be a useful feature=20 (which *is* listed in the current drafts), but mostly for conferencing,=20 rather than congestion. The point of layered codec for congestion in=20 particular is that a router in the middle can reduce the bit-rate to adjust=20 to congestion. However, I see two problems here: 1) most routers does not=20 (and should not have) knowledge of the codec and thus cannot change the=20 rate; and 2) layers are usually larger than a single byte per frame so=20 relying only on a layered approach might compromise the idea of having=20 small bit-rate increments. But as I said earlier, I'm not opposed to=20 layered codecs because they have other uses. This is something that would=20 have to be carefully analysed during development. > To be perfectly clear: This is NOT about enforcing TCP-friendliness or > forcing the resulting codecs to conform to some other strict behavior=20 > under congestion. Due to the complexities of each coding scheme, how=20 > soon and by how much it can react to path congestion will be extremely > codec-specific. But the idea is to recommend (or maybe even require) for=20 > "Internet codecs" to react appropriately to path congestion when they can. OK, I may be wrong here, but my understanding is that how much the rate=20 should change depending on congestion is actually not that codec-specific.=20 I get the impression that the tough part is figuring out what rate you can=20 use without causing packets to be dropped. Once you figure this out, you can just tell the codec to use that rate. On top of that, the codec may be=20 able to do a bit better by providing a "service" to the other layers. On example here (also included in the draft) is VBR, which means that the=20 application specifies an average rate and the codec decides how to vary the=20 rate to achieve that (subject to some rate control constraints). Would=20 other such mechanisms be useful to deal with congestion? Cheers, Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From br@brianrosen.net Wed Oct 21 07:04:56 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0453A6A58 for ; Wed, 21 Oct 2009 07:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.775, 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 4EbhBFTpArx9 for ; Wed, 21 Oct 2009 07:04:55 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id E15853A6993 for ; Wed, 21 Oct 2009 07:04:54 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N0bo1-0001MA-UF; Wed, 21 Oct 2009 09:04:50 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 21 Oct 2009 10:04:50 -0400 From: Brian Rosen To: "Michael Ramalho (mramalho)" , Jean-Marc Valin , Lars Eggert Message-ID: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpSUkAEgP7Xu+xXSeKhN4ux2hD4hQAAPGeAAAEQqhY= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:04:56 -0000 Please keep in mind that depending on the characteristics of the codec, you don't want a lot of rate changes because it annoys the user. I've had one codec designer claim users weren't annoyed with relatively frequent changes in rate (and thus audio quality), but I've never tested one that didn't. Usually, if you encounter congestion, you can ratchet down, and then you roughly never go back up. When in doubt, run usability tests. Easy to run, and gets you a solid answer of what the codec ought to do. Brian On 10/21/09 9:57 AM, "Michael Ramalho (mramalho)" wrote: > All, > > Just a thought for everyone. Prior to the last BoF I posted email that > suggested that the codec should have an ability to change encoding rate > as a function of some form of congestion intelligence (perhaps through > an API, perhaps a hint at the RTP layer, perhaps on a congestion > indication, etc.). That "should" was not necessarily a "must" because a > given application may tell the codec to go full steam ahead anyway > because what it knows about the transport environment. And I think that > wording has been accommodated. > > Consider Jean-Marc's words: "I get the impression that the tough part is > figuring out what rate you can use without causing packets to be > dropped." > > Indeed. > > Consider the case where the bottleneck link for your end-to-end codec > application (where most of your packets are being dropped) is such that > all the UDP traffic (e.g., your VoIP and other UDP applications) is a > minority traffic. That is, the majority of traffic is TCP-friendly (TCP, > SCTP, etc.). And that the bandwidth of this link is large relative to > your VoIP stream. Now suppose that this link is someplace in one of the > middle hops of your end-to-end flow. > > That link is being "filled up" (and causing drops for your flow) > according to the TCP dynamics of the other TCP traffic. Virtually > NOTHING YOU DO ON YOUR FLOW will have a significant impact on your > packet drop performance! Any bandwidth you "vacate" by reducing your > rate becomes "absorbed" (in a sense) by the TCP flows sharing the > remainder of the bandwidth. > > If your application somehow (magically) knew this was the case, perhaps > it would NOT reduce rate. Now that isn't TCP friendly. And some codec > designs actually increase rate in those cases (by reducing rate all they > can - but then adding FEC bandwidth to the lowest rate). > > I think the best we can do here is to design in the knobs to have the > codec change rate (or add FEC if that is a codec capability) to > accommodate scenarios such as the above. > > Michael Ramalho > > PS - As a side note, if the bottleneck link had majority traffic > consisting of similar VoIP flows - the correct behavior would be to > reduce rate as TCP does. That is why the answer for a link dominated by > ITSP traffic would be to reduce rate. And this is why the VoIP > application ideally would benefit from "other intelligence" regarding > congestion properties. > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Wednesday, October 21, 2009 9:27 AM > To: Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > Hi, > > Lars Eggert wrote: >> The Internet uses a distributed congestion control mechanism built >> around the notion that when a flow observes packet loss, it is suppose > >> to reduce its sending rate in some form over some time, in order to > take >> load off a congested path. This behavior is something that I (as a >> transport guy) would see as a key differentiator between an "Internet >> codec" and a "telco codec", and I'd like to suggest that we reflect > this >> in the charter in some form. > > I totally agree that the bit-rate should adapt to network congestion. > This > is why the requirements draft includes "Having the possibility to use > smooth bit-rate changes with one byte/frame resolution". This means that > > the codec can produce any rate that is needed to avoid congestion (not > just > a few pre-selected ones). Now, we must be careful to assign issues to > the > correct "layer" in the VoIP stack. I do not believe it is the codec's > job > to *decide* which bit-rate to select. This should be left to another > component of the application (the RTP stack?), which can then tell the > codec what bit-rate to use. > > If there are more features that the codec can add to help with > congestion, > this is certainly something we can add to the drafts. Scalable codecs > have > also been discussed. I don't like the word because people seem to use it > > for different meanings. In one meaning it is simply the ability to use > any > rate, which is addressed above. In the other meaning, it means having > layers that can be stripped off. I believe this can be a useful feature > (which *is* listed in the current drafts), but mostly for conferencing, > rather than congestion. The point of layered codec for congestion in > particular is that a router in the middle can reduce the bit-rate to > adjust > to congestion. However, I see two problems here: 1) most routers does > not > (and should not have) knowledge of the codec and thus cannot change the > rate; and 2) layers are usually larger than a single byte per frame so > relying only on a layered approach might compromise the idea of having > small bit-rate increments. But as I said earlier, I'm not opposed to > layered codecs because they have other uses. This is something that > would > have to be carefully analysed during development. > >> To be perfectly clear: This is NOT about enforcing TCP-friendliness or > >> forcing the resulting codecs to conform to some other strict behavior >> under congestion. Due to the complexities of each coding scheme, how >> soon and by how much it can react to path congestion will be extremely > >> codec-specific. But the idea is to recommend (or maybe even require) > for >> "Internet codecs" to react appropriately to path congestion when they > can. > > OK, I may be wrong here, but my understanding is that how much the rate > should change depending on congestion is actually not that > codec-specific. > I get the impression that the tough part is figuring out what rate you > can > use without causing packets to be dropped. Once you figure this out, you > > can just tell the codec to use that rate. On top of that, the codec may > be > able to do a bit better by providing a "service" to the other layers. On > > example here (also included in the draft) is VBR, which means that the > application specifies an average rate and the codec decides how to vary > the > rate to achieve that (subject to some rate control constraints). Would > other such mechanisms be useful to deal with congestion? > > Cheers, > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Wed Oct 21 08:05:23 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FBE23A6818 for ; Wed, 21 Oct 2009 08:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j49SyAK-eDK for ; Wed, 21 Oct 2009 08:05:22 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 56DD13A67F0 for ; Wed, 21 Oct 2009 08:05:22 -0700 (PDT) Received: from [134.2.172.132] (u-172-c132.cs.uni-tuebingen.de [134.2.172.132]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9LF5NPC031714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Oct 2009 17:05:24 +0200 From: Christian Hoene To: Jean-Marc Valin In-Reply-To: <4ADF0C41.3010808@octasic.com> References: <4ADE2ED9.2030101@stpeter.im> <4ADF0C41.3010808@octasic.com> Content-Type: text/plain Organization: =?ISO-8859-1?Q?Universit=E4t?= =?ISO-8859-1?Q?_T=FCbingen?= Date: Wed, 21 Oct 2009 17:05:22 +0200 Message-Id: <1256137522.19581.4.camel@hoene-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.42; VDF: 7.1.6.133; host: mx05); id=26784-c9BIqE Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 15:05:23 -0000 > I totally agree that the bit-rate should adapt to network congestion. This > is why the requirements draft includes "Having the possibility to use > smooth bit-rate changes with one byte/frame resolution". This means that > the codec can produce any rate that is needed to avoid congestion (not just > a few pre-selected ones). Now, we must be careful to assign issues to the > correct "layer" in the VoIP stack. I do not believe it is the codec's job > to *decide* which bit-rate to select. This should be left to another > component of the application (the RTP stack?), which can then tell the > codec what bit-rate to use. Reading these statements, I would recommend to read the DCCP charter http://www.ietf.org/dyn/wg/charter/dccp-charter.html and especially the document http://www.ietf.org/rfc/rfc4828.txt Christian From hoene@uni-tuebingen.de Wed Oct 21 10:13:08 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421283A68DE for ; Wed, 21 Oct 2009 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm+vRNwGt5gA for ; Wed, 21 Oct 2009 10:13:07 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id DCD6A3A682A for ; Wed, 21 Oct 2009 10:13:03 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-218-222-121.pools.arcor-ip.net [94.218.222.121]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9LHCr7G018772 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2009 19:12:59 +0200 From: "Christian Hoene" To: "'Brian Rosen'" References: In-Reply-To: Date: Wed, 21 Oct 2009 19:12:53 +0200 Message-ID: <002401ca5271$bde53e20$39afba60$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpSUkAEgP7Xu+xXSeKhN4ux2hD4hQAAPGeAAAEQqhYABb/+UA== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.42; VDF: 7.1.6.134; host: mx05); id=26784-ajncGu Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 17:13:08 -0000 Hello Brian, > Please keep in mind that depending on the characteristics of the codec, you > don't want a lot of rate changes because it annoys the user. I've had one > codec designer claim users weren't annoyed with relatively frequent changes > in rate (and thus audio quality), but I've never tested one that didn't. Some years ago, we have done some tests with AMR. The distortion caused by a change of the coding rate is roughly as large as the distortion caused by a frame loss (http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/hoene_paper21 b.pdf). Consequently, frequent (multiple per second) mode switches are not possible with AMR. However, frequent mode changes may be triggered by transport protocols, which change their frame rates typically after a round trip time. The ITU-T G.718 codec was designed to allow frequent mode switched without causing annoying artifacts. A similar requirement is missing in the current draft-valin-codec-requirements document. I did not read any argument on why it was not included. > Usually, if you encounter congestion, you can ratchet down, and then you > roughly never go back up. TCP does increase linearly after an ECN notification or a frame loss event. Depending on the selected algorithm, DCCP does behave similar. Christian From jean-marc.valin@octasic.com Wed Oct 21 11:04:07 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725783A69DB for ; Wed, 21 Oct 2009 11:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js9sQiIM4ugD for ; Wed, 21 Oct 2009 11:04:06 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 602963A67FA for ; Wed, 21 Oct 2009 11:04:06 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 14:04:15 -0400 Message-ID: <4ADF4D1E.1000403@octasic.com> Date: Wed, 21 Oct 2009 14:04:14 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christian Hoene References: <002401ca5271$bde53e20$39afba60$@de> In-Reply-To: <002401ca5271$bde53e20$39afba60$@de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 18:04:15.0009 (UTC) FILETIME=[E67E9910:01CA5278] Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:04:07 -0000 Christian Hoene wrote: > Some years ago, we have done some tests with AMR. The distortion caused by a > change of the coding rate is roughly as large as the distortion caused by a > frame loss > (http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/hoene_paper21 > b.pdf). Consequently, frequent (multiple per second) mode switches are not > possible with AMR. However, frequent mode changes may be triggered by > transport protocols, which change their frame rates typically after a round > trip time. From what I've been told (haven't verified myself), the AMR-NB modes are more like a set of independent codecs put together with duct tape, rather than one codec with 8 rates. This is probably what explains the switching artefacts. > The ITU-T G.718 codec was designed to allow frequent mode switched without > causing annoying artifacts. A similar requirement is missing in the current > draft-valin-codec-requirements document. I did not read any argument on why > it was not included. The requirements draft (both versions) currently includes the following text: "This means that the codecs have to be able to vary their output bit-rate dynamically (in real-time), without requiring an out-of-band signaling mechanism, and without causing audible artifacts at the bit-rate change boundaries." I think "without causing audible artifacts" is a good description of what we want here. Or do you have something else to suggest? Jean-Marc From gmaxwell@juniper.net Wed Oct 21 11:38:28 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035A03A6A12 for ; Wed, 21 Oct 2009 11:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khMdFCTnOyzq for ; Wed, 21 Oct 2009 11:38:26 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 874FF3A67F7 for ; Wed, 21 Oct 2009 11:38:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSt9VItJyCPYmiWLbiM4j+CPG0oha6Oqs@postini.com; Wed, 21 Oct 2009 11:38:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 21 Oct 2009 11:36:06 -0700 From: Gregory Maxwell To: Christian Hoene , 'Brian Rosen' Date: Wed, 21 Oct 2009 11:36:05 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpSUkAEgP7Xu+xXSeKhN4ux2hD4hQAAPGeAAAEQqhYABb/+UAADBWk7 Message-ID: References: , <002401ca5271$bde53e20$39afba60$@de> In-Reply-To: <002401ca5271$bde53e20$39afba60$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:38:28 -0000 So=97 I think this is really just an argument for codecs designed for the i= nternet=85 Consider these examples: CBR CELT (git) running at 48000, 256 sample frames, 21 bytes/frame (31500 b= its per second which is a bit too low for good music quality with this smal= l framesize) http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21bytes.wav CBR CELT (git) running at 48000, 256 sample frames, 43 bytes/frame (64500 b= its per second) http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/43bytes.wav=20 CELT (git) 48000,256 ramping with from 43-21-43 in one byte per frame incre= ments: http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21-ramp1-43bytes= .wav (i.e. the frame sizes sizes are 43,42,41,40...22,21,22,23,24...) Same ramping pattern, but sending 8 frames at each size: i.e. 43,43,43,43,= 43,43,43,43,42,42,42.... or roughly 42ms per rate change and one second p= er complete cycle:=20 http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21-ramp8-43bytes= .wav Also, Hard switching every other frame: 43,21,43,21,43,21.... http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21-mod2-43bytes.= wav And every 4th frame: (43,43,43,43,21,21,21,21,43...) http://myrandomnode.dyndns.org:8080/~gmaxwell/celt_congest/21-mod4-43bytes.= wav While it would be very interesting to use a blind listening test to objecti= vely characterize the impact of changing rates, I believe that a casual li= sten shows conclusively that for CELT a change in rates is nothing at all l= ike a packet loss (or, perhaps you have very high expectations of what 50% = loss sounds like!). I would I expect reasonable rate control implementations to have some degre= e of filtering to limit rate oscillations and using the codec in VBR mode a= nd simply slewing the target is likely to be far less harmful, but I think = that these simple examples show that aggressive adaptation is possible with= out a ruinous effect to quality. If anyone has profiles of what kind of rate adaptation patterns I could exp= ect (i.e. from DCCP) I'll gladly generate test cases and can probably arran= ge for a small/casual blind listening test. ________________________________________ From: codec-bounces@ietf.org [codec-bounces@ietf.org] On Behalf Of Christia= n Hoene [hoene@uni-tuebingen.de] Sent: Wednesday, October 21, 2009 6:12 PM To: 'Brian Rosen' Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Hello Brian, > Please keep in mind that depending on the characteristics of the codec, you > don't want a lot of rate changes because it annoys the user. I've had on= e > codec designer claim users weren't annoyed with relatively frequent changes > in rate (and thus audio quality), but I've never tested one that didn't. Some years ago, we have done some tests with AMR. The distortion caused by = a change of the coding rate is roughly as large as the distortion caused by a frame loss (http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/hoene_paper2= 1 b.pdf). Consequently, frequent (multiple per second) mode switches are not possible with AMR. However, frequent mode changes may be triggered by transport protocols, which change their frame rates typically after a round trip time. The ITU-T G.718 codec was designed to allow frequent mode switched without causing annoying artifacts. A similar requirement is missing in the current draft-valin-codec-requirements document. I did not read any argument on why it was not included. > Usually, if you encounter congestion, you can ratchet down, and then you > roughly never go back up. TCP does increase linearly after an ECN notification or a frame loss event. Depending on the selected algorithm, DCCP does behave similar. Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Wed Oct 21 12:04:18 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5CF3A69D3 for ; Wed, 21 Oct 2009 12:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1zmf0+YgG9e for ; Wed, 21 Oct 2009 12:04:17 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id E420F3A695A for ; Wed, 21 Oct 2009 12:04:12 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-218-222-121.pools.arcor-ip.net [94.218.222.121]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9LJ3wG6029006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2009 21:04:12 +0200 From: "Christian Hoene" To: "'Jean-Marc Valin'" References: <002401ca5271$bde53e20$39afba60$@de> <4ADF4D1E.1000403@octasic.com> In-Reply-To: <4ADF4D1E.1000403@octasic.com> Date: Wed, 21 Oct 2009 21:03:59 +0200 Message-ID: <002901ca5281$47e72570$d7b57050$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpSeOxzSIPtdKgxSKKOYFB3/qEpDAABpskg Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.42; VDF: 7.1.6.134; host: mx05); id=26784-JAPvGz Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:04:18 -0000 Hello Jean-Marc, > > Some years ago, we have done some tests with AMR. The distortion caused by a > > change of the coding rate is roughly as large as the distortion caused by a > > frame loss > > (http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/hoene_paper21 > > b.pdf). Consequently, frequent (multiple per second) mode switches are not > > possible with AMR. However, frequent mode changes may be triggered by > > transport protocols, which change their frame rates typically after a round > > trip time. > > From what I've been told (haven't verified myself), the AMR-NB modes are > more like a set of independent codecs put together with duct tape, rather > than one codec with 8 rates. This is probably what explains the switching > artefacts. Yes. This might be the reason for this. The AMR standards were stating that state switching is seamlessly. I never tested CELT. > > > The ITU-T G.718 codec was designed to allow frequent mode switched without > > causing annoying artifacts. A similar requirement is missing in the current > > draft-valin-codec-requirements document. I did not read any argument on why > > it was not included. > > The requirements draft (both versions) currently includes the following text: > > "This means that the codecs have to be able to vary their output > bit-rate dynamically (in real-time), without requiring an > out-of-band signaling mechanism, and without causing audible > artifacts at the bit-rate change boundaries." > > I think "without causing audible artifacts" is a good description of what > we want here. Or do you have something else to suggest? No, you are right. I missed it. Sorry. Christian From hoene@uni-tuebingen.de Wed Oct 21 12:06:39 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00663A685C for ; Wed, 21 Oct 2009 12:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63u2XEjPgq59 for ; Wed, 21 Oct 2009 12:06:38 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 9C1C63A69DA for ; Wed, 21 Oct 2009 12:06:24 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-094-218-222-121.pools.arcor-ip.net [94.218.222.121]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9LJ6KpU029142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2009 21:06:30 +0200 From: "Christian Hoene" To: "'Gregory Maxwell'" References: , <002401ca5271$bde53e20$39afba60$@de> In-Reply-To: Date: Wed, 21 Oct 2009 21:06:20 +0200 Message-ID: <002e01ca5281$99cc1cb0$cd645610$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpSUkAEgP7Xu+xXSeKhN4ux2hD4hQAAPGeAAAEQqhYABb/+UAADBWk7AAFodkA= Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.42; VDF: 7.1.6.134; host: mx05); id=26784-1GD3gQ Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:06:39 -0000 Hello Gregory, > While it would be very interesting to use a blind listening test to > objectively characterize the impact of changing rates, I believe that a > casual listen shows conclusively that for CELT a change in rates is nothing at > all like a packet loss (or, perhaps you have very high expectations of what > 50% loss sounds like!). Fine! Well done! May I ask another question? What does happen if you switched between CELT and SILK or any of the other codecs? > I would I expect reasonable rate control implementations to have some degree > of filtering to limit rate oscillations Yes, they have. The DCCP algorithms change less frequent and less severe than TCP. > and using the codec in VBR mode and > simply slewing the target is likely to be far less harmful, but I think that > these simple examples show that aggressive adaptation is possible without a > ruinous effect to quality. > > If anyone has profiles of what kind of rate adaptation patterns I could expect > (i.e. from DCCP) I'll gladly generate test cases and can probably arrange for > a small/casual blind listening test. Allow me address another issue. The RFC4828 document discusses the tradeoff between bit rate and frame rate. To what extend is this tradeoff currently considered in the requirements draft? With best regards, Christian > > > > ________________________________________ > From: codec-bounces@ietf.org [codec-bounces@ietf.org] On Behalf Of Christian > Hoene [hoene@uni-tuebingen.de] > Sent: Wednesday, October 21, 2009 6:12 PM > To: 'Brian Rosen' > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > Hello Brian, > > > Please keep in mind that depending on the characteristics of the codec, > you > > don't want a lot of rate changes because it annoys the user. I've had one > > codec designer claim users weren't annoyed with relatively frequent > changes > > in rate (and thus audio quality), but I've never tested one that didn't. > > Some years ago, we have done some tests with AMR. The distortion caused by a > change of the coding rate is roughly as large as the distortion caused by a > frame loss > (http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/hoene_paper21 > b.pdf). Consequently, frequent (multiple per second) mode switches are not > possible with AMR. However, frequent mode changes may be triggered by > transport protocols, which change their frame rates typically after a round > trip time. > > The ITU-T G.718 codec was designed to allow frequent mode switched without > causing annoying artifacts. A similar requirement is missing in the current > draft-valin-codec-requirements document. I did not read any argument on why > it was not included. > > > Usually, if you encounter congestion, you can ratchet down, and then you > > roughly never go back up. > > TCP does increase linearly after an ECN notification or a frame loss event. > Depending on the selected algorithm, DCCP does behave similar. > > Christian > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stpeter@stpeter.im Wed Oct 21 12:33:56 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D453A67F5 for ; Wed, 21 Oct 2009 12:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 h0ExPxZ0o3Zn for ; Wed, 21 Oct 2009 12:33:55 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 249893A690D for ; Wed, 21 Oct 2009 12:33:55 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E3F644011B; Wed, 21 Oct 2009 13:34:01 -0600 (MDT) Message-ID: <4ADF6228.6020502@stpeter.im> Date: Wed, 21 Oct 2009 13:34:00 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: rontlv References: <4ADE2ED9.2030101@stpeter.im> <4ade41b2.0d0bca0a.1063.1a56@mx.google.com> In-Reply-To: <4ade41b2.0d0bca0a.1063.1a56@mx.google.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:33:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/09 5:03 PM, rontlv wrote: > Hi, > I did not have time to review the charter proposal being on vacation. > > I would like to bring my major concern about > " The goal of this group is to develop one or more codecs" . My view is that > the one of the major reason for lack of deployment of wideband is that there > are too many wideband codecs. > For example in high quality video conferencing you may need to support G.719 > and flavors of AAC full band codecs to interoperate at full band with all > the current products. At the Stockholm BoF, people raised concerns about saying that the WG would limit itself beforehand to defining one and only one codec ("too restrictive!"). They also raised concerns about the WG becoming a codec factory that would produce lots of codecs ("too permissive!"). The current text attemps to address both concerns by expressing a preference for one codec while recognizing that it is possible the WG would produce more than one codec (albeit a very small number of codecs). > I also find it strange that the timeline has one date for all codecs that > will be developed since I do not see any synchronization process between all > the codecs that will be approved if a WG is formed. > > I think that having the right to do multiple codecs as part of the charter > will cause the group to approve all proposed codecs probably rubberstamping > them instead of going to collaboration on one good codec. I think that the > initial charter should have one codec and if later there will be a need > there should be a re-charter. That seems acceptable. > A minor comment is on > "Because the Internet Standards Process defines an open, transparent process > for technology standardization, a wide range of codec experts have committed > to actively working on such codecs within the IETF. > The Codec WG provides a structured forum for these efforts." > I am not sure why this text is part of the charter. That text is true, but you are right that it is not properly part of the problem statement. > Being a little sarcastic about the commitment, I did not see the flexibility > of the experts when they needed to devote time for the IETF meeting. Your sarcasm is appreciated. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrfYigACgkQNL8k5A2w/vxXPwCgqUrcKbGGHP6uVqrvRC0i6B32 vZEAoMkNbUxXJpcDcSifh3wPs3qc0mEC =pIMm -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Oct 21 12:53:16 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04643A693E for ; Wed, 21 Oct 2009 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 FmtBaFDEWqBd for ; Wed, 21 Oct 2009 12:53:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E5DBC3A69E7 for ; Wed, 21 Oct 2009 12:53:15 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9F7AE4011B; Wed, 21 Oct 2009 13:53:24 -0600 (MDT) Message-ID: <4ADF66B3.5090100@stpeter.im> Date: Wed, 21 Oct 2009 13:53:23 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: rontlv , "codec@ietf.org" References: <4ADE2ED9.2030101@stpeter.im> <4ade41b2.0d0bca0a.1063.1a56@mx.google.com> <4ADF6228.6020502@stpeter.im> In-Reply-To: <4ADF6228.6020502@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:53:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/21/09 1:34 PM, Peter Saint-Andre wrote: > On 10/20/09 5:03 PM, rontlv wrote: >> Hi, >> I did not have time to review the charter proposal being on vacation. > >> I would like to bring my major concern about >> " The goal of this group is to develop one or more codecs" . My view is that >> the one of the major reason for lack of deployment of wideband is that there >> are too many wideband codecs. >> For example in high quality video conferencing you may need to support G.719 >> and flavors of AAC full band codecs to interoperate at full band with all >> the current products. > > At the Stockholm BoF, people raised concerns about saying that the WG > would limit itself beforehand to defining one and only one codec ("too > restrictive!"). They also raised concerns about the WG becoming a codec > factory that would produce lots of codecs ("too permissive!"). The > current text attemps to address both concerns by expressing a preference > for one codec while recognizing that it is possible the WG would produce > more than one codec (albeit a very small number of codecs). > >> I also find it strange that the timeline has one date for all codecs that >> will be developed since I do not see any synchronization process between all >> the codecs that will be approved if a WG is formed. > >> I think that having the right to do multiple codecs as part of the charter >> will cause the group to approve all proposed codecs probably rubberstamping >> them instead of going to collaboration on one good codec. I think that the >> initial charter should have one codec and if later there will be a need >> there should be a re-charter. > > That seems acceptable. Well, the charter currently includes the following text: The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor not to function as a "codec factory" that produces a large number of codecs. Perhaps that could be modified to more clearly express a strong preference for producing one codec: The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor to produce only one codec if possible, and in any case shall not function as a "codec factory" that produces a large number of codecs. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrfZrMACgkQNL8k5A2w/vxzVwCglyLKAGEQx4UEM0+o0cDr2uQv uHwAoIqjAIFTZSPemrODRhUEK0bEqfF7 =Uooq -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Oct 21 13:00:47 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAF93A687D for ; Wed, 21 Oct 2009 13:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 8Yrk3jTlDLqS for ; Wed, 21 Oct 2009 13:00:46 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DDEA23A681E for ; Wed, 21 Oct 2009 13:00:45 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BBE074011B; Wed, 21 Oct 2009 14:00:54 -0600 (MDT) Message-ID: <4ADF6875.6020604@stpeter.im> Date: Wed, 21 Oct 2009 14:00:53 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Christian Hoene References: <4ADE2ED9.2030101@stpeter.im> <00da01ca5244$0d0b0440$27210cc0$@de> In-Reply-To: <00da01ca5244$0d0b0440$27210cc0$@de> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:00:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/21/09 5:45 AM, Christian Hoene wrote: > Dear Lars Eggert, > >> The Internet uses a distributed congestion control mechanism built >> around the notion that when a flow observes packet loss, it is suppose >> to reduce its sending rate in some form over some time, in order to >> take load off a congested path. This behavior is something that I (as >> a transport guy) would see as a key differentiator between an >> "Internet codec" and a "telco codec", and I'd like to suggest that we >> reflect this in the charter in some form. >> >> We can certainly argue about how useful this behavior would be in a >> low-bitrate voice codec. But it's my understanding that this effort >> isn't really targeting those, but is instead looking at wideband >> codecs - maybe ones using substantial levels of redundancy in the >> encoding - that can consume some noticeable amount of bandwidth. For >> those sorts of voice codecs, and even more so for video codecs, which >> have been brought up as the next logical thing for a potential CODEC >> WG to target, some sort of congestion-responsiveness is important when >> they are sharing path capacity over the Internet. >> >> See for example > http://tools.ietf.org/html/draft-westerlund-avt-ecn-for-rtp >> for ongoing work related to exposing congestion information to media >> streams earlier than through packet loss (i.e., using ECN). >> >> To be perfectly clear: This is NOT about enforcing TCP-friendliness or >> forcing the resulting codecs to conform to some other strict behavior >> under congestion. Due to the complexities of each coding scheme, how >> soon and by how much it can react to path congestion will be extremely >> codec-specific. But the idea is to recommend (or maybe even require) >> for "Internet codecs" to react appropriately to path congestion when >> they can. > > Since months I am raising this point on this mailing list. I suggested to > establish a procedure on how transport and codec expert should work together > to address these issues. > > However, based on the comments on this mailing list, I have the impression > that this is not wanted. I just remember some statements such as that we are > "only interested in a narrow area." > > I do have the impression that it is not intended to address the fundamental > problems of frequently bad VoIP quality or to enhance the Quality of > Experience - which would require to consider transport issues - but only in > making codecs. Hopefully, my observation is wrong. It's not clear to me why the Codec WG would focus on transport issues. Certainly it should coordinate with transport WGs (AVT, DCCP, etc.), just as it should coordinate with WGs and experts from RAI, Apps, Security, architecture (IAB), etc. Do you think that the charter text needs to be updated to express the fact that the Codec WG would need to coordinate with other groups within the IETF? Typically that is part of normal cross-area review, but perhaps the extraordinary impact on the Codec WG of considerations that are properly the focus of other groups necessitates more intensive interaction here. I'm not convinced of that yet, but adding some text about this in the charter might be appropriate if we think it is needed. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrfaHUACgkQNL8k5A2w/vx7KQCeNsEGdLBjCC7IJYXHCu0zVC+z Q9AAn10nKjcDH82lcqOP+Mh6pep6AKPI =r4U8 -----END PGP SIGNATURE----- From jean-marc.valin@octasic.com Wed Oct 21 13:16:59 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86BAA28C149 for ; Wed, 21 Oct 2009 13:16:59 -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 7SgNGo3Hj77G for ; Wed, 21 Oct 2009 13:16:58 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id A827C28C143 for ; Wed, 21 Oct 2009 13:16:58 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:17:07 -0400 Message-ID: <4ADF6C43.2090805@octasic.com> Date: Wed, 21 Oct 2009 16:17:07 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christian Hoene References: , <002401ca5271$bde53e20$39afba60$@de> <002e01ca5281$99cc1cb0$cd645610$@de> In-Reply-To: <002e01ca5281$99cc1cb0$cd645610$@de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 20:17:07.0406 (UTC) FILETIME=[7669D6E0:01CA528B] Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:16:59 -0000 Christian Hoene wrote: > May I ask another question? What does happen if you switched between CELT > and SILK or any of the other codecs? (my answer is based on CELT and SILK but it would be about the same for any two codecs that are sufficiently different) If done in a simple (dumb) way, it would insert a glitch that would be comparable to a lost packet. If done a bit smarter, it would merely require a slight increase in bitrate at the boundary frame along with a careful overlap of the audio. If the codecs were designed jointly, then it *may* also be possible make the bit-rate increase pretty small (or zero). Jean-Marc From Borilin@spiritdsp.com Wed Oct 21 13:20:43 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7AB3A68D0 for ; Wed, 21 Oct 2009 13:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] 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 P+amkD45NSAK for ; Wed, 21 Oct 2009 13:20:42 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 62DB33A687D for ; Wed, 21 Oct 2009 13:20:42 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9LKKnnL067900; Thu, 22 Oct 2009 00:20:50 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 00:18:50 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpSi3mxBp2I0Wk8R8CZLErCVPZwkAAADoK3 References: , <002401ca5271$bde53e20$39afba60$@de> <002e01ca5281$99cc1cb0$cd645610$@de> <4ADF6C43.2090805@octasic.com> From: "Slava Borilin" To: "Jean-Marc Valin" , "Christian Hoene" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: [codec] HA: updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:20:43 -0000 sorry i am not getting the idea WHY you should switch codecs during the = call? i understand the idea os changing bitrate on-the-fly, but why = renegotiate and change codec on the fly? only in a rare case of call = transfeerring to a different device- but in this case you have a delay = of switching which makes such change unnoticable anyway. am i wrong? =20 ________________________________ =EF=D4: codec-bounces@ietf.org =CF=D4 =C9=CD=C5=CE=C9 Jean-Marc Valin =EF=D4=D0=D2=C1=D7=CC=C5=CE=CF: =FE=D4, 22.10.2009 0:17 =EB=CF=CD=D5: Christian Hoene =EB=CF=D0=C9=D1: codec@ietf.org =F4=C5=CD=C1: Re: [codec] updated charter proposal Christian Hoene wrote: > May I ask another question? What does happen if you switched between = CELT > and SILK or any of the other codecs? (my answer is based on CELT and SILK but it would be about the same for = any two codecs that are sufficiently different) If done in a simple (dumb) way, it would insert a glitch that would be comparable to a lost packet. If done a bit smarter, it would merely = require a slight increase in bitrate at the boundary frame along with a = careful overlap of the audio. If the codecs were designed jointly, then it *may* also be possible make the bit-rate increase pretty small (or zero). Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From Jean-Marc.Valin@USherbrooke.ca Wed Oct 21 13:29:02 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A266528C14C for ; Wed, 21 Oct 2009 13:29: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=[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 BHFqZAtDX3Ac for ; Wed, 21 Oct 2009 13:29:01 -0700 (PDT) Received: from smtpi6.usherbrooke.ca (smtpi6.USherbrooke.ca [132.210.236.2]) by core3.amsl.com (Postfix) with ESMTP id AB72E28C141 for ; Wed, 21 Oct 2009 13:29:01 -0700 (PDT) Received: from localhost (www05.USherbrooke.ca [132.210.244.140]) by smtpi6.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n9LKT20a027122; Wed, 21 Oct 2009 16:29:02 -0400 Received: from mail.octasic.com (mail.octasic.com [70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Wed, 21 Oct 2009 16:29:02 -0400 Message-ID: <1256156942.4adf6f0ea583a@www.usherbrooke.ca> Date: Wed, 21 Oct 2009 16:29:02 -0400 From: Jean-Marc Valin To: Slava Borilin References: , <002401ca5271$bde53e20$39afba60$@de> <002e01ca5281$99cc1cb0$cd645610$@de> <4ADF6C43.2090805@octasic.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n9LKT20a027122 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU03 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: codec@ietf.org Subject: Re: [codec] HA: updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:29:02 -0000 Quoting Slava Borilin : > sorry i am not getting the idea WHY you should switch codecs during the call? > i understand the idea os changing bitrate on-the-fly, but why renegotiate and > change codec on the fly? only in a rare case of call transfeerring to a > different device- but in this case you have a delay of switching which makes > such change unnoticable anyway. > am i wrong? You are perfectly right here, I was just answering the question from a theoretical perspective. At this point, I do not see a reason for changing codec on the fly, or at least not without some kind of exceptional event happening (e.g. call transfer) -- in which case a single glitch wouldn't be a problem. Cheers, Jean-Marc > > ________________________________ > > : codec-bounces@ietf.org Jean-Marc Valin > : , 22.10.2009 0:17 > : Christian Hoene > : codec@ietf.org > : Re: [codec] updated charter proposal > > > > Christian Hoene wrote: > > May I ask another question? What does happen if you switched between CELT > > and SILK or any of the other codecs? > > (my answer is based on CELT and SILK but it would be about the same for any > two codecs that are sufficiently different) > If done in a simple (dumb) way, it would insert a glitch that would be > comparable to a lost packet. If done a bit smarter, it would merely require > a slight increase in bitrate at the boundary frame along with a careful > overlap of the audio. If the codecs were designed jointly, then it *may* > also be possible make the bit-rate increase pretty small (or zero). > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From csp@csperkins.org Wed Oct 21 13:50:29 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D039528C14B for ; Wed, 21 Oct 2009 13:50:29 -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 6BESoMuG1Urk for ; Wed, 21 Oct 2009 13:50:27 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 6225C28C137 for ; Wed, 21 Oct 2009 13:50:27 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.12]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1N0i8i-0007SZ-Zo; Wed, 21 Oct 2009 20:50:36 +0000 Message-Id: <2B9A183D-063E-4AA9-9BF7-13B631939B64@csperkins.org> From: Colin Perkins To: Peter Saint-Andre In-Reply-To: <4ADE2ED9.2030101@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 21:50:34 +0100 References: <4ADE2ED9.2030101@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:50:29 -0000 On 20 Oct 2009, at 22:42, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Per recent list discussion... > > ###### > > Proposed Charter for Codec WG > Last Updated: 2009-10-20 ... > 4. Ensuring interoperability with Internet signalling technologies > such > as Session Initiation Protocol (SIP), Session Description Protocol > (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, > signalling-dependent codecs are out of scope Most recent codecs are dependent on some form of out-of-band signalling to negotiate various options and parameters. Prohibiting any dependence on the signalling seems extreme. You might wish to say something like: 4. Ensuring interoperability with Internet signalling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP) by defining the parameters that must be negotiated to support the codec; the result should not, however, depend on the details of any particular signalling protocol -- Colin Perkins http://csperkins.org/ From jean-marc.valin@octasic.com Wed Oct 21 13:58:11 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BF028C125 for ; Wed, 21 Oct 2009 13:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw7xFQeg35DQ for ; Wed, 21 Oct 2009 13:58:10 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 5FD2D28C119 for ; Wed, 21 Oct 2009 13:58:10 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:58:19 -0400 Message-ID: <4ADF75EA.1040502@octasic.com> Date: Wed, 21 Oct 2009 16:58:18 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Colin Perkins References: <4ADE2ED9.2030101@stpeter.im> <2B9A183D-063E-4AA9-9BF7-13B631939B64@csperkins.org> In-Reply-To: <2B9A183D-063E-4AA9-9BF7-13B631939B64@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 20:58:19.0027 (UTC) FILETIME=[379D4630:01CA5291] Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:58:11 -0000 >> 4. Ensuring interoperability with Internet signalling technologies such >> as Session Initiation Protocol (SIP), Session Description Protocol >> (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, >> signalling-dependent codecs are out of scope > > Most recent codecs are dependent on some form of out-of-band signalling > to negotiate various options and parameters. Prohibiting any dependence > on the signalling seems extreme. You might wish to say something like: IIRC, the intent was just to clarify that the codec wouldn't be tied to SIP or XMPP for example. However, your point about out-of-band signalling is actually a valid one. We will probably need some amount of out-of-band signalling, but I think it should be simple enough and it should fit well within SDP (this should probably go in the requirements draft). > 4. Ensuring interoperability with Internet signalling technologies such > as Session Initiation Protocol (SIP), Session Description Protocol > (SDP), and Extensible Messaging and Presence Protocol (XMPP) by defining > the parameters that must be negotiated to support the codec; the result > should not, however, depend on the details of any particular signalling > protocol Sounds good. Jean-Marc From stewe@stewe.org Wed Oct 21 14:03:43 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA6928C156 for ; Wed, 21 Oct 2009 14:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04SjqAzPsl3K for ; Wed, 21 Oct 2009 14:03:43 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id A675C28C155 for ; Wed, 21 Oct 2009 14:03:40 -0700 (PDT) Received: from [192.168.1.107] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 467433-1743317 for multiple; Wed, 21 Oct 2009 23:03:49 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 21 Oct 2009 14:03:43 -0700 From: Stephan Wenger To: Jean-Marc Valin , Slava Borilin Message-ID: Thread-Topic: [codec] HA: updated charter proposal Thread-Index: AcpSkfi3VtCs3nm0NUeYyvcv8Chtgg== In-Reply-To: <1256156942.4adf6f0ea583a@www.usherbrooke.ca> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org Subject: Re: [codec] HA: updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 21:03:43 -0000 You could change codecs "on the fly" using in-band signaling, the same way as (some have argued) AMR-WB does. This is mostly a question of terminology: when you switch between two distinct coding technologies that are a) specified in the same standard, b) mandatory to implement, and c) in-band signaled, do you then switch codecs or modes of the same codec? (Whether a specification like this makes a lot of sense in our environment, is, IMHO, very questionable. A lot of codec standards of this type exist, but they are often at least in part the result of a political process and not necessarily only motivated by objectively justifiable technical design choices.) (OTOH, I personally prefer a clean single-mechanism spec, over a monster spec with everything mandatory, over a pick-and-choose spec---and the latte= r over lots of individual specs. That is, of course, on the grounds of interoperability.) Stephan On 10/21/09 1:29 PM, "Jean-Marc Valin" wrote: > Quoting Slava Borilin : >=20 >> sorry i am not getting the idea WHY you should switch codecs during the = call? >> i understand the idea os changing bitrate on-the-fly, but why renegotiat= e and >> change codec on the fly? only in a rare case of call transfeerring to a >> different device- but in this case you have a delay of switching which m= akes >> such change unnoticable anyway. >> am i wrong? >=20 > You are perfectly right here, I was just answering the question from a > theoretical perspective. At this point, I do not see a reason for changin= g > codec on the fly, or at least not without some kind of exceptional event > happening (e.g. call transfer) -- in which case a single glitch wouldn't = be a > problem. >=20 > Cheers, >=20 > Jean-Marc >=20 >>=20 >> ________________________________ >>=20 >> =C3=AF=C3=94: codec-bounces@ietf.org =C3=8F=C3=94 =C3=89=C3=8D=C3=85=C3=8E=C3=89 Jean-Marc Valin >> =C3=AF=C3=94=C3=90=C3=92=C3=81=C3=97=C3=8C=C3=85=C3=8E=C3=8F: =C3=BE=C3=94, 22.10.2009 0:17 >> =C3=AB=C3=8F=C3=8D=C3=95: Christian Hoene >> =C3=AB=C3=8F=C3=90=C3=89=C3=91: codec@ietf.org >> =C3=B4=C3=85=C3=8D=C3=81: Re: [codec] updated charter proposal >>=20 >>=20 >>=20 >> Christian Hoene wrote: >>> May I ask another question? What does happen if you switched between CE= LT >>> and SILK or any of the other codecs? >>=20 >> (my answer is based on CELT and SILK but it would be about the same for = any >> two codecs that are sufficiently different) >> If done in a simple (dumb) way, it would insert a glitch that would be >> comparable to a lost packet. If done a bit smarter, it would merely requ= ire >> a slight increase in bitrate at the boundary frame along with a carefu= l >> overlap of the audio. If the codecs were designed jointly, then it *may* >> also be possible make the bit-rate increase pretty small (or zero). >>=20 >> Jean-Marc >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From csp@csperkins.org Wed Oct 21 14:04:12 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B091128C158 for ; Wed, 21 Oct 2009 14:04:12 -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 dxemef9Y9Aa9 for ; Wed, 21 Oct 2009 14:04:12 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id D223A28C125 for ; Wed, 21 Oct 2009 14:04:11 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.12]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1N0iM0-0003Ah-Xx; Wed, 21 Oct 2009 21:04:20 +0000 Message-Id: From: Colin Perkins To: Peter Saint-Andre In-Reply-To: <4ADF6875.6020604@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 22:04:19 +0100 References: <4ADE2ED9.2030101@stpeter.im> <00da01ca5244$0d0b0440$27210cc0$@de> <4ADF6875.6020604@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 21:04:12 -0000 On 21 Oct 2009, at 21:00, Peter Saint-Andre wrote: ... > It's not clear to me why the Codec WG would focus on transport > issues. Certainly it should coordinate with transport WGs (AVT, > DCCP, etc.), just as it should coordinate with WGs and experts from > RAI, Apps, Security, architecture (IAB), etc. > > Do you think that the charter text needs to be updated to express > the fact that the Codec WG would need to coordinate with other > groups within the IETF? Typically that is part of normal cross-area > review, but perhaps the extraordinary impact on the Codec WG of > considerations that are properly the focus of other groups > necessitates more intensive interaction here. I'm not convinced of > that yet, but adding some text about this in the charter might be > appropriate if we think it is needed. That sort of text is relatively common in charters (for example, the AVT charter says "in collaboration with the MPLS and ROHC WGs, to develop a solution for header compression of RTP across MPLS networks that avoid decompression and compression at each MPLS node."), and would seem to be appropriate here. The key points would seem to be to work with AVT and TSVWG to understand the degree of rate adaptation desirable, and to attempt to reflect that in the design of a codec that can adjust its transmission in a way that minimises disruption to the audio. The technical details of how that might be done - in terms of the congestion control or the codec - are likely out of scope for the charter. -- Colin Perkins http://csperkins.org/ From stpeter@stpeter.im Wed Oct 21 15:09:21 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778E63A68EA for ; Wed, 21 Oct 2009 15:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 TPyWDA17Ds10 for ; Wed, 21 Oct 2009 15:09:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8BD2B3A6825 for ; Wed, 21 Oct 2009 15:09:20 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5F4C64011B; Wed, 21 Oct 2009 16:09:29 -0600 (MDT) Message-ID: <4ADF8698.5080407@stpeter.im> Date: Wed, 21 Oct 2009 16:09:28 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Jean-Marc Valin References: <4ADE2ED9.2030101@stpeter.im> <2B9A183D-063E-4AA9-9BF7-13B631939B64@csperkins.org> <4ADF75EA.1040502@octasic.com> In-Reply-To: <4ADF75EA.1040502@octasic.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 22:09:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/21/09 2:58 PM, Jean-Marc Valin wrote: >>> 4. Ensuring interoperability with Internet signalling technologies such >>> as Session Initiation Protocol (SIP), Session Description Protocol >>> (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, >>> signalling-dependent codecs are out of scope >> >> Most recent codecs are dependent on some form of out-of-band >> signalling to negotiate various options and parameters. Prohibiting >> any dependence on the signalling seems extreme. You might wish to say >> something like: > > IIRC, the intent was just to clarify that the codec wouldn't be tied to > SIP or XMPP for example. However, your point about out-of-band > signalling is actually a valid one. We will probably need some amount of > out-of-band signalling, but I think it should be simple enough and it > should fit well within SDP (this should probably go in the requirements > draft). > >> 4. Ensuring interoperability with Internet signalling technologies such >> as Session Initiation Protocol (SIP), Session Description Protocol >> (SDP), and Extensible Messaging and Presence Protocol (XMPP) by >> defining the parameters that must be negotiated to support the codec; >> the result should not, however, depend on the details of any >> particular signalling protocol > > Sounds good. Yes, that's better, thanks. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrfhpgACgkQNL8k5A2w/vwCBACfWwYInelt7l3FP4516oVStEXE RR4An0LurEuAiRSrzSrWuCbFEYV7Qjit =+73x -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Oct 21 15:31:41 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8A83A6911 for ; Wed, 21 Oct 2009 15:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 McsC5JvWY7r0 for ; Wed, 21 Oct 2009 15:31:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B28EB3A68C2 for ; Wed, 21 Oct 2009 15:31:40 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 348E74011B; Wed, 21 Oct 2009 16:31:48 -0600 (MDT) Message-ID: <4ADF8BD2.8050601@stpeter.im> Date: Wed, 21 Oct 2009 16:31:46 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Colin Perkins References: <4ADE2ED9.2030101@stpeter.im> <00da01ca5244$0d0b0440$27210cc0$@de> <4ADF6875.6020604@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 22:31:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/21/09 3:04 PM, Colin Perkins wrote: > On 21 Oct 2009, at 21:00, Peter Saint-Andre wrote: > ... >> It's not clear to me why the Codec WG would focus on transport issues. >> Certainly it should coordinate with transport WGs (AVT, DCCP, etc.), >> just as it should coordinate with WGs and experts from RAI, Apps, >> Security, architecture (IAB), etc. >> >> Do you think that the charter text needs to be updated to express the >> fact that the Codec WG would need to coordinate with other groups >> within the IETF? Typically that is part of normal cross-area review, >> but perhaps the extraordinary impact on the Codec WG of considerations >> that are properly the focus of other groups necessitates more >> intensive interaction here. I'm not convinced of that yet, but adding >> some text about this in the charter might be appropriate if we think >> it is needed. > > > That sort of text is relatively common in charters (for example, the AVT > charter says "in collaboration with the MPLS and ROHC WGs, to develop a > solution for header compression of RTP across MPLS networks that avoid > decompression and compression at each MPLS node."), and would seem to be > appropriate here. The key points would seem to be to work with AVT and > TSVWG to understand the degree of rate adaptation desirable, and to > attempt to reflect that in the design of a codec that can adjust its > transmission in a way that minimises disruption to the audio. The > technical details of how that might be done - in terms of the congestion > control or the codec - are likely out of scope for the charter. That seems reasonable. To capture all the integration points that have been mentioned on the list, we could include in the charter text such as this: *** In completing its work, the group should collaborate with other IETF working groups to complete particular tasks. These might include but would not be limited to the following: - - Within the AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP). - - Collaborate with the AVT WG and TSV WG to understand the degree of rate adaptation desirable, and to reflect that understanding in the design of a codec that can adjust its transmission in a way that minimizes disruption to the audio. - - Collaborate with the SIPCORE WG and XMPP WG to ensure that information about the codec can be easily represented at the signalling layer. - - Collaborate with the AVT WG and DCCP WG to identify important aspects of packet transmission over the Internet. *** Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrfi9IACgkQNL8k5A2w/vyohACg64BPog898BH7GN1e3OTL6Xjh 2nYAn1+kJPoJ+ahX5WnHb5QTW+4veTvU =wGun -----END PGP SIGNATURE----- From eburger@alum.mit.edu Wed Oct 21 15:58:59 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F073A67EF for ; Wed, 21 Oct 2009 15:58:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char 9C hex): Received: ...s eburger@ALUM.MIT.EDU)\n\t\234by outgoing-alu[...] 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, UNPARSEABLE_RELAY=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 MEg8AMQGofE2 for ; Wed, 21 Oct 2009 15:58:57 -0700 (PDT) Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by core3.amsl.com (Postfix) with ESMTP id A88B03A67B3 for ; Wed, 21 Oct 2009 15:58:57 -0700 (PDT) Received: from [192.168.15.199] (ip68-100-199-8.dc.dc.cox.net [68.100.199.8]) (authenticated bits=0) (User authenticated as eburger@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id n9LMx326024438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 21 Oct 2009 18:59:04 -0400 Message-Id: <2C42BF8A-E243-4E06-AF93-46FAB9501E8F@alum.mit.edu> From: Eric Burger To: codec@ietf.org In-Reply-To: <483774E9-7374-4459-BD85-C79D8AA96AE8@standardstrack.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: Wed, 21 Oct 2009 18:59:03 -0400 References: <483774E9-7374-4459-BD85-C79D8AA96AE8@standardstrack.com> X-Mailer: Apple Mail (2.936) Subject: Re: [codec] Interesting IEEE Comm Mag Section on ITU-T Standards X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 22:58:59 -0000 Here is a start: http://www.comsoc.org/livepubs/ci1/public/2009/oct/index.html Still need to log in. I'll see if I can get it freed. In the mean time, if anyone wants to join... On Oct 20, 2009, at 4:15 PM, Eric Burger wrote: > The most recent issue (October 2009, V. 47 n. 10) of IEEE > Communications Magazine has a special section of interest to us here > on Speech Coding. Ask a friend if you do not have access to the IEEE > Xplore library or a hard copy. From ingemar.s.johansson@ericsson.com Thu Oct 22 00:22:00 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5115D3A68E8 for ; Thu, 22 Oct 2009 00:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5dEaBSLVqdj for ; Thu, 22 Oct 2009 00:21:59 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D2E0B3A68A2 for ; Thu, 22 Oct 2009 00:21:58 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-95-4ae0077e2fe5 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2B.5B.24026.E7700EA4; Thu, 22 Oct 2009 09:19:26 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:18:54 +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" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 09:18:43 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C0214AD7A@esealmw109.eemea.ericsson.se> In-Reply-To: <002401ca5271$bde53e20$39afba60$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpS5+NGhdXrv3RASDeUQhu8pI5//w== References: <002401ca5271$bde53e20$39afba60$@de> From: "Ingemar Johansson S" To: "Christian Hoene" , "Jean-Marc Valin" X-OriginalArrivalTime: 22 Oct 2009 07:18:54.0320 (UTC) FILETIME=[E9941700:01CA52E7] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:22:00 -0000 Hi Cristian, Jean-Marc Some comments to the comments on AMR I have not had time to read the report in full but I reacted on he comment below (figure 5 in the report).=20 AMR rate swithing _is_ seamless. As far as I can recall rate switching was part of the codec characterization in 3GPP, in addition, rate control in circuit switched networks (which is faster than the rate control in packet switched networks will ever be) would be impossible without seamless switching. So I am a bit surprised that you get these results.=20 Did you do a listening test as well ?, I wonder if there is a flaw in the PESQ model.. What kind of input stimuli did you use ?. I actually had to make a testrun where I switched between AMR102 and AMR122 every 20ms and I did not hear any swithing artifacts. I even asked another listener at the office (with better ears than mine) to listen and he wasn't able to hear any switching artifacts either. And finally=20 AMR is _one_ codec, not a selection of 8 codecs. The modes share the same framework but of course the quanitizer resolution (LSP, adaptive CB, fixed CB) depends on the bitrate + that there are a few extra features added for a few modes. =20 Some of the AMR modes are compatible with fixed rate codecs, AMR122 is compatible with the EFR codec, AMR67 is used in a Japanese cellular system, still AMR is one codec. Regards /Ingemar > -----Original Message----- > From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 > Sent: den 21 oktober 2009 19:13 > To: 'Brian Rosen' > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal >=20 > Hello Brian, >=20 > > Please keep in mind that depending on the characteristics of the=20 > > codec, > you > > don't want a lot of rate changes because it annoys the=20 > user. I've had=20 > > one codec designer claim users weren't annoyed with relatively=20 > > frequent > changes > > in rate (and thus audio quality), but I've never tested one=20 > that didn't. >=20 > Some years ago, we have done some tests with AMR. The=20 > distortion caused by a change of the coding rate is roughly=20 > as large as the distortion caused by a frame loss > (http://www.net.in.tum.de/fileadmin/bibtex/publications/papers > /hoene_paper21 > b.pdf). Consequently, frequent (multiple per second) mode=20 > switches are not possible with AMR. However, frequent mode=20 > changes may be triggered by transport protocols, which change=20 > their frame rates typically after a round trip time. >=20 > The ITU-T G.718 codec was designed to allow frequent mode=20 > switched without causing annoying artifacts. A similar=20 > requirement is missing in the current=20 > draft-valin-codec-requirements document. I did not read any=20 > argument on why it was not included. >=20 > > Usually, if you encounter congestion, you can ratchet down,=20 > and then=20 > > you roughly never go back up. >=20 > TCP does increase linearly after an ECN notification or a=20 > frame loss event. > Depending on the selected algorithm, DCCP does behave similar. >=20 > Christian >=20 >=20 >=20 >=20 From lars.eggert@nokia.com Thu Oct 22 00:44:18 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBA93A672E for ; Thu, 22 Oct 2009 00:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 eiGcdEJbfDaD for ; Thu, 22 Oct 2009 00:44:08 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id ABF7B3A68A2 for ; Thu, 22 Oct 2009 00:44:04 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9M7i6jn080931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Oct 2009 10:44:06 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-38-864855850; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4ADF0C41.3010808@octasic.com> Date: Thu, 22 Oct 2009 10:44:06 +0300 Message-Id: <030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> References: <4ADE2ED9.2030101@stpeter.im> <4ADF0C41.3010808@octasic.com> To: Jean-Marc Valin X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Thu, 22 Oct 2009 10:44:07 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:44:18 -0000 --Apple-Mail-38-864855850 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-21, at 16:27, Jean-Marc Valin wrote: > I totally agree that the bit-rate should adapt to network > congestion. This > is why the requirements draft includes "Having the possibility to use > smooth bit-rate changes with one byte/frame resolution". This means > that > the codec can produce any rate that is needed to avoid congestion > (not just > a few pre-selected ones). Now, we must be careful to assign issues > to the > correct "layer" in the VoIP stack. I do not believe it is the > codec's job > to *decide* which bit-rate to select. This should be left to another > component of the application (the RTP stack?), which can then tell the > codec what bit-rate to use. RTP doesn't do congestion control either. DCCP would, but nobody's using it currently, mostly due to NAT traversal issues and lack of implementations. Also, what we've learned from media over DCCP is that if you don't involve the codec in some form, performance/quality will be bad. Some codecs need time to adjust the rate. Some can only adjust it in pretty coarse steps. Etc. If you let DCCP adjust the rate blindly, without involving the codec in some form, you might get very good TCP friendliness, but maybe quality will suffer. (And there is always the ramping up part - congestion control will never attempt to probe for more capacity unless the codec generates more data, and why would the codec do that if it's converged to transmit at some lower rate.) > The point of layered codec for congestion in > particular is that a router in the middle can reduce the bit-rate to > adjust > to congestion. However, I see two problems here: 1) most routers > does not > (and should not have) knowledge of the codec and thus cannot change > the > rate; and 2) layers are usually larger than a single byte per frame so > relying only on a layered approach might compromise the idea of having > small bit-rate increments. By no means should routers have to understand codec formats! Routers drop or mark IP packets. It is up to the application sending those IP packets to react appropriately to the marks or losses. In other words, a layered codec will see losses/marks to packets sent on all layers, and will then need to figure out whether to strip off a layer or not in response to whatever congestion level those losses/marks indicate. >> To be perfectly clear: This is NOT about enforcing TCP-friendliness >> or >> forcing the resulting codecs to conform to some other strict behavior >> under congestion. Due to the complexities of each coding scheme, how >> soon and by how much it can react to path congestion will be >> extremely >> codec-specific. But the idea is to recommend (or maybe even >> require) for >> "Internet codecs" to react appropriately to path congestion when >> they can. > > OK, I may be wrong here, but my understanding is that how much the > rate > should change depending on congestion is actually not that codec- > specific. It *can* be non-codec-specific, see DCCP for example. But quality will suffer IMO. > I get the impression that the tough part is figuring out what rate > you can > use without causing packets to be dropped. Most Internet congestion control is based on *creating* losses/marks to determine capacity. People have tried to create congestion control schemes that avoid causing losses (delay-based schemed, for example), but they are perceived to be more fragile. > Once you figure this out, you > can just tell the codec to use that rate. It's not that easy, because rates in the Internet are never stable - the rate computation is usually clocked by the RTT. You can obviously dampen this somehow, but you can never say "now I have found a rate that I can safely use forever." > On top of that, the codec may be > able to do a bit better by providing a "service" to the other > layers. On > example here (also included in the draft) is VBR, which means that the > application specifies an average rate and the codec decides how to > vary the > rate to achieve that (subject to some rate control constraints). Would > other such mechanisms be useful to deal with congestion? I'm not sure this would work, because congestion control will basically change the VBR input parameter continuously. Lars --Apple-Mail-38-864855850 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyMjA3NDQwNlowIwYJKoZIhvcNAQkEMRYEFIGXgGohmE3kxKNpBjxSFnQ/K7vzMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDQME2HecOouWuZCEfGenK3E8YWd6eNlNJJ034W9Der4QyKLyQm7aT0jfDd/ew6KfKLmWTY HXw69ko4ol0MgiS10DsFiTf2uru4MY7myZkzj3CiTuJti+To7bpRHTu7DRUeVbhQ1GRDl69KNY/2 B7yDsgsgcJQwvRsnyfyP3vgzTOAwSTwL7y7gfe9eRq6bKJQw00aNXe2/aKyGBKl4mizWqCQcl8O6 o4jzaOphs9DMVIqPlSfmvKDTq9CzbHZbePlV/h0cD68b3pLV5sBEnv3v/rKJ5YzqWLFZgpLlTfM8 X4WnHukfp522msMUhZm6Z60b8i0KXZ0Y7fhQFJiXTTl9AAAAAAAA --Apple-Mail-38-864855850-- From hoene@uni-tuebingen.de Thu Oct 22 00:44:24 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166A23A6893 for ; Thu, 22 Oct 2009 00:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUKAWGQkUCpi for ; Thu, 22 Oct 2009 00:44:22 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 0A6413A672E for ; Thu, 22 Oct 2009 00:44:21 -0700 (PDT) Received: from hoeneLenovoT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9M7iTt1009980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Oct 2009 09:44:29 +0200 From: "Christian Hoene" To: "'Ingemar Johansson S'" References: <002401ca5271$bde53e20$39afba60$@de> <130EBB38279E9847BAAAE0B8F9905F8C0214AD7A@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C0214AD7A@esealmw109.eemea.ericsson.se> Date: Thu, 22 Oct 2009 09:44:30 +0200 Message-ID: <001301ca52eb$7d99bce0$78cd36a0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpS5+NGhdXrv3RASDeUQhu8pI5//wAA0oBA Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.42; VDF: 7.1.6.134; host: mx05); id=18728-0lNkJ5 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:44:24 -0000 Hello Ingemar, I made the tests some years ago. The raw data and the measurement = scripts are already on backup CDs. I will revive it. Please allow me some time before I can send it to you.=20 With best regards, Christian -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: Thursday, October 22, 2009 9:19 AM > To: Christian Hoene; Jean-Marc Valin > Cc: codec@ietf.org; Brian Rosen; Ingemar Johansson S > Subject: RE: [codec] updated charter proposal >=20 > Hi Cristian, Jean-Marc >=20 >=20 > Some comments to the comments on AMR >=20 > I have not had time to read the report in full but I reacted on he > comment below (figure 5 in the report). >=20 > AMR rate swithing _is_ seamless. As far as I can recall rate switching > was part of the codec characterization in 3GPP, in addition, rate > control in circuit switched networks (which is faster than the rate > control in packet switched networks will ever be) would be impossible > without seamless switching. So I am a bit surprised that you get these > results. > Did you do a listening test as well ?, I wonder if there is a flaw in > the PESQ model.. What kind of input stimuli did you use ?. I actually > had to make a testrun where I switched between AMR102 and AMR122 every > 20ms and I did not hear any swithing artifacts. I even asked another > listener at the office (with better ears than mine) to listen and he > wasn't able to hear any switching artifacts either. >=20 > And finally > AMR is _one_ codec, not a selection of 8 codecs. The modes share the > same framework but of course the quanitizer resolution (LSP, adaptive > CB, fixed CB) depends on the bitrate + that there are a few extra > features added for a few modes. > Some of the AMR modes are compatible with fixed rate codecs, AMR122 is > compatible with the EFR codec, AMR67 is used in a Japanese cellular > system, still AMR is one codec. >=20 > Regards > /Ingemar >=20 > > -----Original Message----- > > From: Christian Hoene [mailto:hoene@uni-tuebingen.de] > > Sent: den 21 oktober 2009 19:13 > > To: 'Brian Rosen' > > Cc: codec@ietf.org > > Subject: Re: [codec] updated charter proposal > > > > Hello Brian, > > > > > Please keep in mind that depending on the characteristics of the > > > codec, > > you > > > don't want a lot of rate changes because it annoys the > > user. I've had > > > one codec designer claim users weren't annoyed with relatively > > > frequent > > changes > > > in rate (and thus audio quality), but I've never tested one > > that didn't. > > > > Some years ago, we have done some tests with AMR. The > > distortion caused by a change of the coding rate is roughly > > as large as the distortion caused by a frame loss > > (http://www.net.in.tum.de/fileadmin/bibtex/publications/papers > > /hoene_paper21 > > b.pdf). Consequently, frequent (multiple per second) mode > > switches are not possible with AMR. However, frequent mode > > changes may be triggered by transport protocols, which change > > their frame rates typically after a round trip time. > > > > The ITU-T G.718 codec was designed to allow frequent mode > > switched without causing annoying artifacts. A similar > > requirement is missing in the current > > draft-valin-codec-requirements document. I did not read any > > argument on why it was not included. > > > > > Usually, if you encounter congestion, you can ratchet down, > > and then > > > you roughly never go back up. > > > > TCP does increase linearly after an ECN notification or a > > frame loss event. > > Depending on the selected algorithm, DCCP does behave similar. > > > > Christian > > > > > > > > From lars.eggert@nokia.com Thu Oct 22 00:52:51 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262363A681D for ; Thu, 22 Oct 2009 00:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 VdUW9-H1Jrxx for ; Thu, 22 Oct 2009 00:52:50 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 1DAF93A6817 for ; Thu, 22 Oct 2009 00:52:49 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9M7qphK081451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Oct 2009 10:52:52 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-39-865381220; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4ADF6875.6020604@stpeter.im> Date: Thu, 22 Oct 2009 10:52:51 +0300 Message-Id: <08EEBDB6-D3CC-4BC9-AE20-592C722CA65D@nokia.com> References: <4ADE2ED9.2030101@stpeter.im> <00da01ca5244$0d0b0440$27210cc0$@de> <4ADF6875.6020604@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Thu, 22 Oct 2009 10:52:52 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:52:51 -0000 --Apple-Mail-39-865381220 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-21, at 23:00, Peter Saint-Andre wrote: > It's not clear to me why the Codec WG would focus on transport issues. > Certainly it should coordinate with transport WGs (AVT, DCCP, etc.), > just as it should coordinate with WGs and experts from RAI, Apps, > Security, architecture (IAB), etc. I'm not saying it should focus on transport issues. I'm saying that because this effort is trying to spec "Internet codecs", these codecs should be better integrated with Internet transports than those done elsewhere, esp. when it comes to congestion response. The idea is that through that integration (or at least awareness) it should be possible to arrive at better quality under loss while still doing an appropriate congestion response. Lars --Apple-Mail-39-865381220 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyMjA3NTI1MlowIwYJKoZIhvcNAQkEMRYEFCP/zBWxhQqyJfJB0yeKZaEO3NTaMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBe+zF/TL25y9U9j+Gv5FtvJ+eoFPiTmxeW488qWdSHkyrakKzyT2XjHSZohJB7TmAu0u7T aaOSI9S8iy++2KUmAqoZEne0bEoTTpAdxWPPs6CkFDSSk1CvAwZfdoiWjl8R4aa85FTlVVz3M2X1 rW256BAMgWa/ej6P3bl/2+64+JeEnruRwjCcF6siY8nUsuVWOa18nikr8MlBJ60OzNkX+yq0VPUm QpbgWioou4earrU1e6zh9KoQYjFN3ssX+WoVLgyf4Rd7TtjEQXLL6sB5v1P/HvECu94/UUHa2lyq 2iUttOg0EXnr4Jg00P5pAWToMMsAwmrXJ1lrj9zThj9vAAAAAAAA --Apple-Mail-39-865381220-- From lars.eggert@nokia.com Thu Oct 22 00:56:32 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA6D3A6940 for ; Thu, 22 Oct 2009 00:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 eY05xLcZnOWd for ; Thu, 22 Oct 2009 00:56:31 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 54BCB3A67F3 for ; Thu, 22 Oct 2009 00:56:31 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9M7uCfo081683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 22 Oct 2009 10:56:13 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-40-865582242; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4ADF8BD2.8050601@stpeter.im> Date: Thu, 22 Oct 2009 10:56:12 +0300 Message-Id: References: <4ADE2ED9.2030101@stpeter.im> <00da01ca5244$0d0b0440$27210cc0$@de> <4ADF6875.6020604@stpeter.im> <4ADF8BD2.8050601@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Thu, 22 Oct 2009 10:56:13 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:56:32 -0000 --Apple-Mail-40-865582242 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-22, at 1:31, Peter Saint-Andre wrote: > - - Collaborate with the AVT WG and TSV WG to understand the degree of > rate adaptation desirable, and to reflect that understanding in the > design of a codec that can adjust its transmission in a way that > minimizes disruption to the audio. ... > - - Collaborate with the AVT WG and DCCP WG to identify important > aspects of packet transmission over the Internet. Minor nit. I'd change both TSV WG and DCCP to TSV area, since it's not clear which WG this would land in (and there is a chance that DCCP will close soon). Lars --Apple-Mail-40-865582242 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyMjA3NTYxM1owIwYJKoZIhvcNAQkEMRYEFPvw1Ft1+/buGVM5yhTTfKNOMh2rMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQB+Om9FFJR7c3ECX0x6yVDWUx4G0OdmHGdF0fhOEoCwQ1VA+ZVMNOUp2fSNajyXoWNZQE9Z VRf4+tjlu+uugOZFcg0032SvJ3ePzntW++0UrPnKE3rBxYZh6dWQu3j6nN0V3Xm3xT63uMnF7V2d 0ZdqPzgx2wJLsO0W8T/n/sxfPgt2VSgOIsmE6hD30TSM6mnacYbuu3/ktiB518N0NA1ly1szPw4e +9ft8Lfr81TA4PNRytY+uBls+ZNsePE8m4YwDVRawwkG8PGFe3D+3QG2HZGIIwLwBj/yi3v3ixd7 CfMYJUdfR1slWmz85xJ17Jt+b7FGz5QrqBUWcRZRblsJAAAAAAAA --Apple-Mail-40-865582242-- From swmike@swm.pp.se Thu Oct 22 01:01:06 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E893A681D for ; Thu, 22 Oct 2009 01:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RDpaahAK05L for ; Thu, 22 Oct 2009 01:01:05 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id B41C63A67F3 for ; Thu, 22 Oct 2009 01:01:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0E1109F; Thu, 22 Oct 2009 10:01:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0A3649E for ; Thu, 22 Oct 2009 10:01:13 +0200 (CEST) Date: Thu, 22 Oct 2009 10:01:13 +0200 (CEST) From: Mikael Abrahamsson To: "codec@ietf.org" In-Reply-To: <030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> Message-ID: References: <4ADE2ED9.2030101@stpeter.im> <4ADF0C41.3010808@octasic.com> <030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 08:01:06 -0000 On Thu, 22 Oct 2009, Lars Eggert wrote: > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. I don't know exactly how the information should be handled at each layer, but taking into account jitter, delay, packet loss, ECN-bits set etc, the congestion signals seen by TCP should be available via similar mechanisms to a sound transport solution. I initially thought that the near constant rate over time nature of a sound transport stream (compared to the often bursty nature of TCP) would mean that it should "stand its ground", but I have now changed my opinion and I do think that the bitrate should be lowered when adverse network conditions are seen, even if it's only done in a few steps (low/mid/high or something like that). This would mean that when links are filled with just sound streams, they can adapt when this link goes full by adapting the rate, and in case of congestion where there is a lot of TCP streams, at least we can play a little friendly by lowering the bitrate, even though it wont make much of a difference overall. Also, it might make a big difference for a link that has a lot of voice traffic, if the packet per second rate could be decreased, so if the default is one packet per 20ms, going to one packet per 40ms halves the pps and lowers the bandwidth used because of less packet overhead (on a DSL link where it might be VoiceinRTPinIPinEthernetinATM, the overhead might well be hundreds of percent). So if the initial 50pps meant 16 bytes of voice per packet (which might in worst case conditions mean 3 ATM cells per packet), increasing this to 32 bytes at 25pps will decrease the bandwidth seen on the ATM layer from 63 kilobits/s to 32 kilobits/s (if the new packet still fits in 3 cells, otherwise it'll be 42 kilobit/s (4 cells per packet)). -- Mikael Abrahamsson email: swmike@swm.pp.se From hoene@uni-tuebingen.de Thu Oct 22 04:37:12 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4515B28C107 for ; Thu, 22 Oct 2009 04:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44mK2BsVgVVm for ; Thu, 22 Oct 2009 04:37:11 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 0A3FB3A67F2 for ; Thu, 22 Oct 2009 04:37:10 -0700 (PDT) Received: from hoeneLenovoT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9MBbH2K020803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Oct 2009 13:37:17 +0200 From: "Christian Hoene" To: "'Colin Perkins'" References: <4ADE2ED9.2030101@stpeter.im> <2B9A183D-063E-4AA9-9BF7-13B631939B64@csperkins.org> In-Reply-To: <2B9A183D-063E-4AA9-9BF7-13B631939B64@csperkins.org> Date: Thu, 22 Oct 2009 13:37:19 +0200 Message-ID: <008101ca530c$03a8d670$0afa8350$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpSkC5bsnJEhVEYT4milDrAHPzQfwAeY0VQ Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.42; VDF: 7.1.6.136; host: mx05); id=18728-IzISBN Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 11:37:12 -0000 Dear Mr. Colin Perkins, > > 4. Ensuring interoperability with Internet signalling technologies > > such > > as Session Initiation Protocol (SIP), Session Description Protocol > > (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, > > signalling-dependent codecs are out of scope > > > Most recent codecs are dependent on some form of out-of-band > signalling to negotiate various options and parameters. Prohibiting > any dependence on the signalling seems extreme. Some time ago, Alexander Chemeris was raising this issue. http://www.ietf.org/mail-archive/web/codec/current/msg00508.html He was complaining that there is a violation between transport and signaling "layer" (or better plane) for some modern codecs - especially if the signaling protocol has to store states about the negotiated coding mode. This might causes problems if the signaling engine must renegotiate transmission connections or if connections are to be forwarded. He was telling me that the signaling part of a call forwarding engine must include codec specific extension and that this should be avoided. I have to admit that I did not fully understood his use-case but having a clear split between signaling and transport states seems to be a good approach to reduce system complexity. With best regards, Christian > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From csp@csperkins.org Thu Oct 22 05:26:45 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330C33A6920 for ; Thu, 22 Oct 2009 05:26:45 -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 8KlNIJBpRKNX for ; Thu, 22 Oct 2009 05:26:44 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id 1DA723A6900 for ; Thu, 22 Oct 2009 05:26:44 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1N0wkn-0004Nn-XG; Thu, 22 Oct 2009 12:26:53 +0000 Message-Id: <4AFDDD14-6C31-4926-BC21-026090BF49D5@csperkins.org> From: Colin Perkins To: "Christian Hoene" In-Reply-To: <008101ca530c$03a8d670$0afa8350$@de> 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, 22 Oct 2009 13:26:51 +0100 References: <4ADE2ED9.2030101@stpeter.im> <2B9A183D-063E-4AA9-9BF7-13B631939B64@csperkins.org> <008101ca530c$03a8d670$0afa8350$@de> X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 12:26:45 -0000 On 22 Oct 2009, at 12:37, Christian Hoene wrote: >>> 4. Ensuring interoperability with Internet signalling technologies >>> such as Session Initiation Protocol (SIP), Session Description >>> Protocol (SDP), and Extensible Messaging and Presence Protocol >>> (XMPP); however, signalling-dependent codecs are out of scope >> >> Most recent codecs are dependent on some form of out-of-band >> signalling to negotiate various options and parameters. Prohibiting >> any dependence on the signalling seems extreme. > > Some time ago, Alexander Chemeris was raising this issue. > http://www.ietf.org/mail-archive/web/codec/current/msg00508.html > He was complaining that there is a violation between transport and > signaling "layer" (or better plane) for some modern codecs - > especially if the signaling protocol has to store states about the > negotiated coding mode. This might causes problems if the signaling > engine must renegotiate transmission connections or if connections > are to be forwarded. He was telling me that the signaling part of a > call forwarding engine must include codec specific extension and > that this should be avoided. RTP transport fundamentally relies on out-of-band signalling for some codec parameters. That's unavoidable, but doesn't need to be a great source of complexity. In the message you reference, Alexander's main concern seems to be that the RTP payload formats for AMR and AMR-WB rely on complex out-of- band signalling, while he would prefer in-band signalling with fewer options. It's true that those payload formats do make extensive use of out-of-band signalling, and suffer some complexity as a result, but this was very much an intentional design choice: - There was a desire to support several different modes of operation, optimised for different use cases, which required incompatible packet formats, where the overhead of in-band signalling was considered too high. - There was a desire to allow some end-points to not implement certain features and options of the payload format, and this required out-of- band signalling to determine end-point capabilities. You may disagree with those design choices, but the working group was aware of the issues and the complexity of the out-of-band signalling at the time, and didn't believe that in-band signalling was appropriate. Some other payload formats have made different choices, and chosen a different trade-off; it depends on the codec, and the design of the RTP payload format. -- Colin Perkins http://csperkins.org/ From jean-marc.valin@octasic.com Thu Oct 22 06:45:17 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8A03A688C for ; Thu, 22 Oct 2009 06:45:17 -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 fagEFLLLCbpX for ; Thu, 22 Oct 2009 06:45:16 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 657973A6855 for ; Thu, 22 Oct 2009 06:45:16 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:45:25 -0400 Message-ID: <4AE061F5.7080301@octasic.com> Date: Thu, 22 Oct 2009 09:45:25 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Lars Eggert References: <4ADE2ED9.2030101@stpeter.im> <4ADF0C41.3010808@octasic.com> <030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> In-Reply-To: <030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 13:45:25.0326 (UTC) FILETIME=[E87EC6E0:01CA531D] Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 13:45:17 -0000 Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc From stpeter@stpeter.im Thu Oct 22 08:02:10 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E9128C14D for ; Thu, 22 Oct 2009 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 feI9go1CevEW for ; Thu, 22 Oct 2009 08:02:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CF83528C11C for ; Thu, 22 Oct 2009 08:02:09 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0CD04011B; Thu, 22 Oct 2009 09:02:18 -0600 (MDT) Message-ID: <4AE071F2.1080506@stpeter.im> Date: Thu, 22 Oct 2009 08:53:38 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Lars Eggert References: <4ADE2ED9.2030101@stpeter.im> <00da01ca5244$0d0b0440$27210cc0$@de> <4ADF6875.6020604@stpeter.im> <4ADF8BD2.8050601@stpeter.im> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" , Colin Perkins Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 15:02:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/22/09 1:56 AM, Lars Eggert wrote: > Hi, > > On 2009-10-22, at 1:31, Peter Saint-Andre wrote: >> - - Collaborate with the AVT WG and TSV WG to understand the degree of >> rate adaptation desirable, and to reflect that understanding in the >> design of a codec that can adjust its transmission in a way that >> minimizes disruption to the audio. > ... >> - - Collaborate with the AVT WG and DCCP WG to identify important >> aspects of packet transmission over the Internet. > > Minor nit. I'd change both TSV WG and DCCP to TSV area, since it's not > clear which WG this would land in (and there is a chance that DCCP will > close soon). Done in my working copy. I'll post a revised version later today. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrgcfIACgkQNL8k5A2w/vyIZgCfbOtkx3jnzRsPQnxeTZw68fiM liwAoNUKHNns6hH5X9cAkurwQ2xflTbl =eYeY -----END PGP SIGNATURE----- From mknappe@juniper.net Thu Oct 22 11:03:21 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC43E3A696C for ; Thu, 22 Oct 2009 11:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14J9diIqEZsO for ; Thu, 22 Oct 2009 11:03:21 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id B95923A68F8 for ; Thu, 22 Oct 2009 11:03:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSuCeO3qGYGjkZ20wlKMmQ7MeFWdYAnfR@postini.com; Thu, 22 Oct 2009 11:03:31 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 22 Oct 2009 10:56:40 -0700 From: Michael Knappe To: "jean-marc.valin@octasic.com" , "koen.vos@skype.net" , "borilin@spiritdsp.net" , "xiphmont@xiph.org" , "rchen@broadcom.com" Date: Thu, 22 Oct 2009 10:56:59 -0700 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpTQQ0GVCpuFyb1DUumK8cQUm7Xlg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 18:03:21 -0000 One thing we might want to add to 'draft-valin-codec-requirements' is a bri= ef discussion of quality expectations in a tandemed codec transmission path= . For example, a potential scenario for the proposed codec, at least early = on, may have the proposed codec tandemed between potentially two disparate = cell codecs: Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to = cell phone 2 codec type 'B' As we develop a quality methodology, it will be worthwhile to specify some = typical tandem scenarios to evaluate voice quality in mixed codec environme= nts, including tandeming of the proposed codec with itself (e.g. Two IP PBX= 's that get connected to each other over via TDM). Evaluations of different= LBR codecs in the past have shown that under the same tandem scenario, two= candidate codecs may get markedly different tandem MOS scores even though = the two might have very similar single encode/decode scores. Thoughts on that? Michael Knappe Juniper Networks From Borilin@spiritdsp.com Thu Oct 22 11:23:19 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92993A69D0 for ; Thu, 22 Oct 2009 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.509, 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 R28HgOqSaiGU for ; Thu, 22 Oct 2009 11:23:18 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 61C843A69E4 for ; Thu, 22 Oct 2009 11:23:18 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9MINPqe089353; Thu, 22 Oct 2009 22:23:25 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 22:23:19 +0400 Message-ID: In-Reply-To: <4AE061F5.7080301@octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTHe3dr1LmmxksSEe/qHKFfkdd4AAHFjHw References: <4ADE2ED9.2030101@stpeter.im><4ADF0C41.3010808@octasic.com><030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> <4AE061F5.7080301@octasic.com> From: "Slava Borilin" To: "Jean-Marc Valin" , "Lars Eggert" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 18:23:20 -0000 I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery?=20 Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't=20 > involve the codec in some form, performance/quality will be bad. Some=20 > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without=20 > involving the codec in some form, you might get very good TCP=20 > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be=20 careful not to include in the codec things that don't belong there (e.g. a=20 DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never=20 > attempt to probe for more capacity unless the codec generates more data,=20 > and why would the codec do that if it's converged to transmit at some=20 > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to=20 probe for more capacity, then you tell the codec that it can use a higher=20 rate. Now, if there's a special way in which you want to ask the codec,=20 then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers=20 > drop or mark IP packets. It is up to the application sending those IP=20 > packets to react appropriately to the marks or losses. In other words, a=20 > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in=20 > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is=20 why I was saying that IMO layered codecs aren't too useful for congestion=20 control (though they have other uses). If there's nothing in the middle of=20 the network to strip off the layers, then you might as well not have layers=20 at all. All you need is to ask the sender to reduce the rate. You don't=20 need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that=20 >> codec-specific. >=20 > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and=20 implement just those. Does anyone have a list of the issues codecs should=20 be aware of? > Most Internet congestion control is based on *creating* losses/marks to=20 > determine capacity. People have tried to create congestion control=20 > schemes that avoid causing losses (delay-based schemed, for example),=20 > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. >=20 > It's not that easy, because rates in the Internet are never stable - the=20 > rate computation is usually clocked by the RTT. You can obviously dampen=20 > this somehow, but you can never say "now I have found a rate that I can=20 > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you=20 can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from=20 the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to=20 >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? >=20 > I'm not sure this would work, because congestion control will basically=20 > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means=20 that you'd like to have an average of N kb/s for now, but you're OK if=20 there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From gmaxwell@juniper.net Thu Oct 22 11:54:59 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAFD3A68E4 for ; Thu, 22 Oct 2009 11:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ppo9aiDPlpD2 for ; Thu, 22 Oct 2009 11:54:58 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 8E52D28C0F5 for ; Thu, 22 Oct 2009 11:54:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSuCqVd5luZnN4jFT3UpbnEprWPnBGYQq@postini.com; Thu, 22 Oct 2009 11:55:08 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 22 Oct 2009 11:53:56 -0700 From: Gregory Maxwell To: Michael Knappe , "jean-marc.valin@octasic.com" , "koen.vos@skype.net" , "borilin@spiritdsp.net" , "xiphmont@xiph.org" , "rchen@broadcom.com" Date: Thu, 22 Oct 2009 11:53:55 -0700 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpTQQ0GVCpuFyb1DUumK8cQUm7XlgABA314 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 18:54:59 -0000 Michael Knappe wrote: > One thing we might want to add to 'draft-valin-codec-requirements' is a b= rief discussion of quality expectations in a tandemed codec transmission pa= th. [snip] > two candidate codecs may get markedly different tandem MOS scores even th= ough the two might have very similar single encode/decode scores. In the single codec case it can also be important to distinguish 'synchrono= us' and 'asynchronous' tandeming: I.e. is the sample the same position in a= frame in all cases or has there been some uncompensated offset. This can = make a fairly large difference (for example, tandeming is currently almost = nearly in CELT (in terms of PQevalaudio ODG loss[1], at least) if you're ca= reful to retain alignment=97 but the quality degrades with tandeming cycles= if you do not). I expect that since frame alignment can't always be easil= y preserved (i.e. an TDM stage in between) that both cases are worth profil= ing.=20 I'm not sure that this could easily be converted into a clear requirement= =97 but I think no one would consider it acceptable for a single stage to c= ause an enormous quality drop.=20 [1] On a 64kbit/sec CBR encode of a random music clip I get a PEAQ ODG of -= 0.346 for one pass through the codec; -0.362 for 1000 passes. This is somew= hat less than the loss from a 3kbit reduction in bitrate at -0.369) From hsinnrei@adobe.com Thu Oct 22 12:09:56 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC333A67F7 for ; Thu, 22 Oct 2009 12:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zjwXG1g5eaT for ; Thu, 22 Oct 2009 12:09:54 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by core3.amsl.com (Postfix) with ESMTP id 5873E3A659B for ; Thu, 22 Oct 2009 12:09:50 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKSuCuBAPnygMVik69RHrnqk78sW6V1n1A@postini.com; Thu, 22 Oct 2009 12:10:04 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9MJ2nao002344; Thu, 22 Oct 2009 12:02:49 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9MJ9tiq013822; Thu, 22 Oct 2009 12:09:55 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 22 Oct 2009 12:09:55 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Thu, 22 Oct 2009 12:09:55 -0700 From: Henry Sinnreich To: Slava Borilin , Jean-Marc Valin , Lars Eggert Date: Thu, 22 Oct 2009 12:09:51 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTHe3dr1LmmxksSEe/qHKFfkdd4AAHFjHwAAQ9E9Y= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C706182F68A0hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:09:56 -0000 --_000_C706182F68A0hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it knows= nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its only = one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C706182F68A0hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal Slava,

>I am not that sure that routers should not be aware of the codecs. Why?=
>If we are building MPLS and other systems that is content-dependent, wh= y
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it knows= nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its only = one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

I am not that sure that routers should not = be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain= order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you don't
> involve the codec in some form, performance/quality will be bad. Some<= BR> > codecs need time to adjust the rate. Some can only adjust it in pretty=

> coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just wa= nt to
be
careful not to include in the codec things that don't belong there (e.g. a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never
> attempt to probe for more capacity unless the codec generates more
data,
> and why would the codec do that if it's converged to transmit at some<= BR> > lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP<= BR> > packets to react appropriately to the marks or losses. In other words,=
a
> layered codec will see losses/marks to packets sent on all layers, and=

> will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You don't
need layers to have a multi-rate codec. Layering just means that you can
strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much the=
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality will=

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* losses/marks to
> determine capacity. People have tried to create congestion control
> schemes that avoid causing losses (delay-based schemed, for example),<= BR> > but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable - the
> rate computation is usually clocked by the RTT. You can obviously
dampen
> this somehow, but you can never say "now I have found a rate that= I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that
you
can have one module that determines in real-time the best rate to use at
that moment and then it tells the codec what to use. If it needs help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to the = other layers.
On
>> example here (also included in the draft) is VBR, which means that=
the
>> application specifies an average rate and the codec decides how to=
>> vary the
>> rate to achieve that (subject to some rate control constraints). Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C706182F68A0hsinnreiadobecom_-- From Borilin@spiritdsp.com Thu Oct 22 12:13:13 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE9828C191 for ; Thu, 22 Oct 2009 12:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 e+mvdJdDMjEA for ; Thu, 22 Oct 2009 12:13:03 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id AA7F628C192 for ; Thu, 22 Oct 2009 12:13:02 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9MJD3pF090061; Thu, 22 Oct 2009 23:13:04 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) 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_01CA534B.AA4FA350" Date: Thu, 22 Oct 2009 23:12:57 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTHe3dr1LmmxksSEe/qHKFfkdd4AAHFjHwAAQ9E9YAABPfIA== References: From: "Slava Borilin" To: "Henry Sinnreich" , "Jean-Marc Valin" , "Lars Eggert" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:13:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA534B.AA4FA350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Henry, With all of my respect (you know) - this is too high-level consideration and too generic statement which doesn't answer MPLS issue for example. =20 best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it knows nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its only one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA534B.AA4FA350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

Henry,=

With all of my = respect (you know) – this is too high-level consideration and too generic statement which doesn’t answer MPLS issue for = example.

 =

best = regards,

Slava = Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October = 22, 2009 11:10 PM
To: Slava Borilin; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

 

Slava,

>I am not that sure that routers should not be aware of the codecs. = Why?
>If we are building MPLS and other systems that is content-dependent, = why
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its = only one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> = wrote:

I am not that sure that = routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, = why
not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it = can
be too hard and too long to tell each sender to reduce the rate - = why
not to leave this freedom to router as this may be more efficient = for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router = do
not need to understand anything except that it is LAYERED streams = (even
don't know whether its voice, video or audio or anything else of = layered
nature, and router "has the right" to strip out layers in = certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you = don't
> involve the codec in some form, performance/quality will be bad. = Some
> codecs need time to adjust the rate. Some can only adjust it in = pretty

> coarse steps. Etc. If you let DCCP adjust the rate blindly, = without
> involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just = want to
be
careful not to include in the codec things that don't belong there = (e.g.
a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control = will
never
> attempt to probe for more capacity unless the codec generates = more
data,
> and why would the codec do that if it's converged to transmit at = some
> lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want = to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the = codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! = Routers
> drop or mark IP packets. It is up to the application sending those = IP
> packets to react appropriately to the marks or losses. In other = words,
a
> layered codec will see losses/marks to packets sent on all layers, = and

> will then need to figure out whether to strip off a layer or not = in
> response to whatever congestion level those losses/marks = indicate.

I definitely agree that the routers shouldn't know about codecs and = this
is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the = middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You = don't
need layers to have a multi-rate codec. Layering just means that you = can

strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much = the
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality = will

> suffer IMO.

Well, we need to figure out the aspects that should be = codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* = losses/marks
to
> determine capacity. People have tried to create congestion = control
> schemes that avoid causing losses (delay-based schemed, for = example),
> but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable = -
the
> rate computation is usually clocked by the RTT. You can = obviously
dampen
> this somehow, but you can never say "now I have found a rate = that I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying = that
you
can have one module that determines in real-time the best rate to use = at

that moment and then it tells the codec what to use. If it needs = help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to = the other layers.
On
>> example here (also included in the draft) is VBR, which means = that
the
>> application specifies an average rate and the codec decides how = to
>> vary the
>> rate to achieve that (subject to some rate control = constraints).
Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK = if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

------_=_NextPart_001_01CA534B.AA4FA350-- From gmaxwell@juniper.net Thu Oct 22 12:14:57 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D238C3A69D6 for ; Thu, 22 Oct 2009 12:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 9BZQiSnVwfT2 for ; Thu, 22 Oct 2009 12:14:57 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id D87093A69D0 for ; Thu, 22 Oct 2009 12:14:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSuCvM2ntUegrcnU7CbsFWMxs/eBRTvhI@postini.com; Thu, 22 Oct 2009 12:15:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 22 Oct 2009 12:13:43 -0700 From: Gregory Maxwell To: Slava Borilin , Jean-Marc Valin , Lars Eggert Date: Thu, 22 Oct 2009 12:13:42 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTHe3dr1LmmxksSEe/qHKFfkdd4AAHFjHwAAO2Ijg= Message-ID: References: <4ADE2ED9.2030101@stpeter.im><4ADF0C41.3010808@octasic.com><030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> <4AE061F5.7080301@octasic.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:14:57 -0000 Slava Borilin [Borilin@spiritdsp.com] wrote: > I am not that sure that routers should not be aware of the codecs. Why? > If we are building MPLS and other systems that is content-dependent, why > not let router understand the codec? > Especially if we have hordes of voice channels going thru router, it can > be too hard and too long to tell each sender to reduce the rate - why > not to leave this freedom to router as this may be more efficient for > congestion recovery? The most obvious internet friendly way of accomplishing this would be to pl= ace separate layers in separate packets with distinct TOS markings so that = they may be differentially dropped. This would work on already deployed ne= tworks and networking equipment.=20 However, even ignoring the problems created by the effect of independent ji= tter on these distinct flows, the typical ratio of bitrates to packet rate= s for acceptable latency means that even with a single 'layer' the packets = already have a lot of overhead (25% for 48kbit/sec into 20ms for IPv4). I w= ould not expect doubling the packet rate (and overhead) just to achieve dif= ferential dropping to be a much of a win, compared to an alternative like s= ending every packet twice by including the previous packet in each frame. = =20 Client protocol RFCs which have expected widespread changes to infrastructu= re packet processing have not had a recent history of good success (I.e. m= y ECN enabled client still hits problems accessing websites). Expecting the general packet forwarding infrastructure to gain the ability = to twiddle the codec bits is pretty much the opposite of what I would expec= t to do in a codec intended for the internet. From hsinnrei@adobe.com Thu Oct 22 12:18:47 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D8428C198 for ; Thu, 22 Oct 2009 12:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI0qwb+E7fcY for ; Thu, 22 Oct 2009 12:18:37 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by core3.amsl.com (Postfix) with ESMTP id B63A428C185 for ; Thu, 22 Oct 2009 12:18:22 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKSuCwBdyFG5rmSaO1a0FW5rca3wTq22+u@postini.com; Thu, 22 Oct 2009 12:18:47 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9MJBLao003440; Thu, 22 Oct 2009 12:11:22 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n9MJINY4007647; Thu, 22 Oct 2009 12:18:26 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 22 Oct 2009 12:18:24 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Thu, 22 Oct 2009 12:18:24 -0700 From: Henry Sinnreich To: Slava Borilin , Jean-Marc Valin , Lars Eggert Date: Thu, 22 Oct 2009 12:18:22 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTHe3dr1LmmxksSEe/qHKFfkdd4AAHFjHwAAQ9E9YAABPfIAAAOEdu Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7061A2E68A9hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:18:47 -0000 --_000_C7061A2E68A9hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are there standards showing the linkage between MPLS and specific applicati= on components, such as codecs? Henry On 10/22/09 2:12 PM, "Slava Borilin" wrote: Henry, With all of my respect (you know) - this is too high-level consideration an= d too generic statement which doesn't answer MPLS issue for example. best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it knows= nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its only = one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C7061A2E68A9hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal Are there standards showing the linkage between MPLS and specific app= lication components, such as codecs?

Henry

On 10/22/09 2:12 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

Henry,
With all of my respect (you know) – this is too high-level considerat= ion and too generic statement which doesn’t answer MPLS issue for exa= mple.
 

best regards,
Slava Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October 22, 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal
Slava,

>I am not that sure that routers should not be aware of the codecs. Why?=
>If we are building MPLS and other systems that is content-dependent, wh= y
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it knows= nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its only = one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain= order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you don't
> involve the codec in some form, performance/quality will be bad. Some<= BR> > codecs need time to adjust the rate. Some can only adjust it in pretty=

> coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just wa= nt to
be
careful not to include in the codec things that don't belong there (e.g. a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never
> attempt to probe for more capacity unless the codec generates more
data,
> and why would the codec do that if it's converged to transmit at some<= BR> > lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP<= BR> > packets to react appropriately to the marks or losses. In other words,=
a
> layered codec will see losses/marks to packets sent on all layers, and=

> will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You don't
need layers to have a multi-rate codec. Layering just means that you can
strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much the=
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality will=

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* losses/marks to
> determine capacity. People have tried to create congestion control
> schemes that avoid causing losses (delay-based schemed, for example),<= BR> > but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable - the
> rate computation is usually clocked by the RTT. You can obviously
dampen
> this somehow, but you can never say "now I have found a rate that= I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that
you
can have one module that determines in real-time the best rate to use at
that moment and then it tells the codec what to use. If it needs help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to the = other layers.
On
>> example here (also included in the draft) is VBR, which means that=
the
>> application specifies an average rate and the codec decides how to=
>> vary the
>> rate to achieve that (subject to some rate control constraints). Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C7061A2E68A9hsinnreiadobecom_-- From Borilin@spiritdsp.com Thu Oct 22 12:23:03 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF8A28C126 for ; Thu, 22 Oct 2009 12:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 Vcoe0pZMlzVe for ; Thu, 22 Oct 2009 12:22:52 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id BA33028C19A for ; Thu, 22 Oct 2009 12:22:51 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9MJMpk5090205; Thu, 22 Oct 2009 23:22:51 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) 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_01CA534D.085F4430" Date: Thu, 22 Oct 2009 23:22:44 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTHe3dr1LmmxksSEe/qHKFfkdd4AAHFjHwAAQ9E9YAABPfIAAAHdUA References: From: "Slava Borilin" To: "Slava Borilin" , "Henry Sinnreich" , "Jean-Marc Valin" , "Lars Eggert" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:23:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA534D.085F4430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Again - my point is that router does NOT have to know that something = specifically is the codec, or specific codec- the only goal is to let = router aware that the stream (and every packet) is LAYERED, and that it = is legitimate to strip out some layers if necessary due to congestion. The content of such "layered" can be any - voice codec, video codec, = audio codec, any type of content. =20 And I agree with Gregory - that having current infrastructure using = layers in separate streams will require too much overhead (packets) = which does not make sense as well - and I am thinking about one stream = of packets comtaining all the layers, which, however, can be modified on = the fly "in the middle". So we may think about more generic concept of "declared layered content" = which does NOT loose the information (well, most of it) by stripping out = portions of the packet and reducing the traffic, so router can strip out = any type of layered content, without going deep into specific codec. =20 Again- this is "na=EFve" suggestions from me (very limited engineer) - = and definitely I am looking for objections even more then for agreement = - for the sake of either finding the idea useful or making judged deny = of it, and I agree that this concept is only one possible way of working = with congestion. =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Slava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 Henry, With all of my respect (you know) - this is too high-level consideration = and too generic statement which doesn't answer MPLS issue for example. =20 best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, = why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its = only one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA534D.085F4430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

Again - my point = is that router does NOT have to know that something specifically is the codec, = or specific codec- the only goal is to let router aware that the stream = (and every packet) is LAYERED, and that it is legitimate to strip out some layers = if necessary due to congestion.

The content of = such “layered” can be any – voice codec, video codec, audio codec, any type of = content.

 =

And I agree with = Gregory – that having current infrastructure using layers in separate streams will = require too much overhead (packets) which does not make sense as well – = and I am thinking about one stream of packets comtaining all the layers, which, = however, can be modified on the fly “in the = middle”.

So we may think = about more generic concept of “declared layered content” which does NOT = loose the information (well, most of it) by stripping out portions of the = packet and reducing the traffic, so router can strip out any type of layered content, = without going deep into specific codec.

 =

Again- this is = “naïve” suggestions from me (very limited engineer) – and definitely I am = looking for objections even more then for agreement – for the sake of = either finding the idea useful or making judged deny of it, and I agree that = this concept is only one possible way of working with = congestion.

 =

best = regards,

Slava = Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Slava Borilin
Sent: Thursday, October = 22, 2009 11:13 PM
To: Henry Sinnreich; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

 

Henry,=

With all of my = respect (you know) – this is too high-level consideration and too generic statement which doesn’t answer MPLS issue for = example.

 =

best = regards,

Slava = Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October = 22, 2009 11:10 PM
To: Slava Borilin; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

 

Slava,

>I am not that sure that routers should not be aware of the codecs. = Why?
>If we are building MPLS and other systems that is content-dependent, = why
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its = only one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> = wrote:

I am not that sure that = routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, = why
not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it = can
be too hard and too long to tell each sender to reduce the rate - = why
not to leave this freedom to router as this may be more efficient = for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router = do
not need to understand anything except that it is LAYERED streams = (even
don't know whether its voice, video or audio or anything else of = layered
nature, and router "has the right" to strip out layers in = certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you = don't
> involve the codec in some form, performance/quality will be bad. = Some
> codecs need time to adjust the rate. Some can only adjust it in = pretty

> coarse steps. Etc. If you let DCCP adjust the rate blindly, = without
> involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just = want to
be
careful not to include in the codec things that don't belong there = (e.g.
a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control = will
never
> attempt to probe for more capacity unless the codec generates = more
data,
> and why would the codec do that if it's converged to transmit at = some
> lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want = to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the = codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! = Routers
> drop or mark IP packets. It is up to the application sending those = IP
> packets to react appropriately to the marks or losses. In other = words,
a
> layered codec will see losses/marks to packets sent on all layers, = and

> will then need to figure out whether to strip off a layer or not = in
> response to whatever congestion level those losses/marks = indicate.

I definitely agree that the routers shouldn't know about codecs and = this
is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the = middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You = don't
need layers to have a multi-rate codec. Layering just means that you = can

strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much = the
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality = will

> suffer IMO.

Well, we need to figure out the aspects that should be = codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* = losses/marks
to
> determine capacity. People have tried to create congestion = control
> schemes that avoid causing losses (delay-based schemed, for = example),
> but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable = -
the
> rate computation is usually clocked by the RTT. You can = obviously
dampen
> this somehow, but you can never say "now I have found a rate = that I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying = that
you
can have one module that determines in real-time the best rate to use = at

that moment and then it tells the codec what to use. If it needs = help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to = the other layers.
On
>> example here (also included in the draft) is VBR, which means = that
the
>> application specifies an average rate and the codec decides how = to
>> vary the
>> rate to achieve that (subject to some rate control = constraints).
Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK = if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

------_=_NextPart_001_01CA534D.085F4430-- From hoene@uni-tuebingen.de Thu Oct 22 12:32:50 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5B328C135 for ; Thu, 22 Oct 2009 12:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGftyWQ8U6kn for ; Thu, 22 Oct 2009 12:32:50 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id C76EA3A6884 for ; Thu, 22 Oct 2009 12:32:49 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-188-099-175-210.pools.arcor-ip.net [188.99.175.210]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n9MJWl1a029414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Oct 2009 21:32:55 +0200 From: "Christian Hoene" To: "'Michael Knappe'" References: In-Reply-To: Date: Thu, 22 Oct 2009 21:32:46 +0200 Message-ID: <00cc01ca534e$75f8e200$61eaa600$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpTQQ0GVCpuFyb1DUumK8cQUm7XlgACenkg Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:32:50 -0000 Dear Michael Knappe, > Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to > cell phone 2 codec type 'B' Honestly, in this case I would recommend you to use ITU codecs because they have been designed for these use cases. With best regards, Christian From Borilin@spiritdsp.com Thu Oct 22 12:40:09 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CE83A6884 for ; Thu, 22 Oct 2009 12:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.664, 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 MbkqvGS43wMo for ; Thu, 22 Oct 2009 12:40:08 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 7006E3A685C for ; Thu, 22 Oct 2009 12:40:08 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9MJeGU4090454; Thu, 22 Oct 2009 23:40:17 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 23:40:10 +0400 Message-ID: In-Reply-To: <00cc01ca534e$75f8e200$61eaa600$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpTQQ0GVCpuFyb1DUumK8cQUm7XlgACenkgAAD1Y7A= References: <00cc01ca534e$75f8e200$61eaa600$@de> From: "Slava Borilin" To: "Christian Hoene" , "Michael Knappe" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:40:10 -0000 Michael, If you are thinking about core network to carry voice in IP between BSCs - why should you care about any of internet codecs- as this is managed network normally? Or I misunderstand you goal? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene Sent: Thursday, October 22, 2009 11:33 PM To: 'Michael Knappe' Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements Dear Michael Knappe, > Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to > cell phone 2 codec type 'B' Honestly, in this case I would recommend you to use ITU codecs because they have been designed for these use cases.=20 With best regards, Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Thu Oct 22 12:43:46 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F023A68E4 for ; Thu, 22 Oct 2009 12:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nea38CuCOUSX for ; Thu, 22 Oct 2009 12:43:46 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id D199D3A68C0 for ; Thu, 22 Oct 2009 12:43:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSuC19ZV+QaOFKBACVYp0rJqlFssZM7zB@postini.com; Thu, 22 Oct 2009 12:43:56 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 22 Oct 2009 12:42:21 -0700 From: Michael Knappe To: "hoene@uni-tuebingen.de" Date: Thu, 22 Oct 2009 12:42:19 -0700 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpTQQ0GVCpuFyb1DUumK8cQUm7XlgACenkgAAEzKMo= Message-ID: <05542EC42316164383B5180707A489EE1CFEC3274B@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:43:46 -0000 Christian,=20 I am not looking for a particular codec type, only pointing out that any pr= oposed codec may end up receiving traffic that at some point has already be= en compressed/uncompressed and lost some speech information redundancy in t= he uncompressed speech as it hits the internet codec. We should at least un= derstand how the proposed codec will perform when receiving that previously= compressed traffic. Mike ----- Original Message ----- From: Christian Hoene To: Michael Knappe Cc: codec@ietf.org Sent: Thu Oct 22 15:32:46 2009=0A= Subject: RE: [codec] codec tandeming/codec-requirements Dear Michael Knappe, > Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode t= o > cell phone 2 codec type 'B' Honestly, in this case I would recommend you to use ITU codecs because they have been designed for these use cases.=20 With best regards, Christian From jean-marc.valin@octasic.com Thu Oct 22 12:45:07 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3F563A68C3 for ; Thu, 22 Oct 2009 12:45:07 -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 Yqz6NDOA0QqE for ; Thu, 22 Oct 2009 12:45:07 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id DC4F23A67E3 for ; Thu, 22 Oct 2009 12:45:06 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 15:45:16 -0400 Message-ID: <4AE0B64C.9020402@octasic.com> Date: Thu, 22 Oct 2009 15:45:16 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Slava Borilin References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Oct 2009 19:45:16.0545 (UTC) FILETIME=[2DDD5710:01CA5350] Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:45:08 -0000 Hi Slava, Slava Borilin wrote: > Again - my point is that router does NOT have to know that something > specifically is the codec, or specific codec- the only goal is to let > router aware that the stream (and every packet) is LAYERED, and that it > is legitimate to strip out some layers if necessary due to congestion. > > The content of such layered can be any voice codec, video codec, > audio codec, any type of content. One of the issues here is that not only does the router not know about the codec, but most (all?) routers don't even know about anything other than layer 3 (IP). It doesn't even know whether the packet transports UDP or TCP, much less whether there any media or anything. Routers are several orders of magnitude too dumb to strip some bits off a codec payload. Cheers, Jean-Marc From Borilin@spiritdsp.com Thu Oct 22 12:49:08 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DED53A69B4 for ; Thu, 22 Oct 2009 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.569, 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 xXW55dPBY5-o for ; Thu, 22 Oct 2009 12:49:07 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 844513A6994 for ; Thu, 22 Oct 2009 12:49:07 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9MJnGQt090592; Thu, 22 Oct 2009 23:49:16 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 23:49:10 +0400 Message-ID: In-Reply-To: <4AE0B64C.9020402@octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTUDGRp+zQOyjOQ8yqbBpOVkNuYwAAHEZA References: <4AE0B64C.9020402@octasic.com> From: "Slava Borilin" To: "Jean-Marc Valin" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:49:08 -0000 Sure this is what we have now. Question is when it comes to congestion - it is worth "teaching routers", or this does not make sense from overall economy. best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 11:45 PM To: Slava Borilin Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Hi Slava, Slava Borilin wrote: > Again - my point is that router does NOT have to know that something=20 > specifically is the codec, or specific codec- the only goal is to let=20 > router aware that the stream (and every packet) is LAYERED, and that it=20 > is legitimate to strip out some layers if necessary due to congestion. >=20 > The content of such "layered" can be any - voice codec, video codec,=20 > audio codec, any type of content. One of the issues here is that not only does the router not know about the=20 codec, but most (all?) routers don't even know about anything other than layer 3 (IP). It doesn't even know whether the packet transports UDP or=20 TCP, much less whether there any media or anything. Routers are several=20 orders of magnitude too dumb to strip some bits off a codec payload. Cheers, Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From petithug@acm.org Thu Oct 22 12:52:43 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF043A69E5 for ; Thu, 22 Oct 2009 12:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.152 X-Spam-Level: X-Spam-Status: No, score=-102.152 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MzbSr8hN4uB for ; Thu, 22 Oct 2009 12:52:43 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 49C3B3A69DA for ; Thu, 22 Oct 2009 12:52:43 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 87E316C9852C; Thu, 22 Oct 2009 19:52:52 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id EEA516C98524; Thu, 22 Oct 2009 19:52:50 +0000 (UTC) Message-ID: <4AE0B812.6080702@acm.org> Date: Thu, 22 Oct 2009 12:52:50 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Jean-Marc Valin References: <4AE0B64C.9020402@octasic.com> In-Reply-To: <4AE0B64C.9020402@octasic.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:52:44 -0000 Jean-Marc Valin wrote: > Hi Slava, > > Slava Borilin wrote: >> Again - my point is that router does NOT have to know that something >> specifically is the codec, or specific codec- the only goal is to let >> router aware that the stream (and every packet) is LAYERED, and that >> it is legitimate to strip out some layers if necessary due to congestion. >> >> The content of such layered can be any voice codec, video codec, >> audio codec, any type of content. > > One of the issues here is that not only does the router not know about > the codec, but most (all?) routers don't even know about anything other > than layer 3 (IP). It doesn't even know whether the packet transports > UDP or TCP, much less whether there any media or anything. Routers are > several orders of magnitude too dumb to strip some bits off a codec > payload. Right, but one can imagine an IPv6 header that contains one or more offsets related to the payload that would let a router aware of this extension that it can shorten the packet to one of this offset if needed. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From stefan.sayer@iptego.com Thu Oct 22 13:08:26 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C773A69D3 for ; Thu, 22 Oct 2009 13:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 c7rgzkwnq6zG for ; Thu, 22 Oct 2009 13:08:25 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 7529A3A6801 for ; Thu, 22 Oct 2009 13:08:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 24D3A1154090; Thu, 22 Oct 2009 22:08:34 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LitH4E2hQfsP; Thu, 22 Oct 2009 22:08:34 +0200 (CEST) Received: from [192.168.5.106] (g230191161.adsl.alicedsl.de [92.230.191.161]) by mail.iptego.net (Postfix) with ESMTPSA id BCB13115407E; Thu, 22 Oct 2009 22:08:33 +0200 (CEST) Message-ID: <4AE0BBC1.9050402@iptego.com> Date: Thu, 22 Oct 2009 22:08:33 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Christian Hoene References: <00cc01ca534e$75f8e200$61eaa600$@de> In-Reply-To: <00cc01ca534e$75f8e200$61eaa600$@de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 20:08:26 -0000 o Christian Hoene [10/22/09 21:32]: > Dear Michael Knappe, > >> Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to >> cell phone 2 codec type 'B' > > Honestly, in this case I would recommend you to use ITU codecs because they > have been designed for these use cases. I don't think so. IMO bringing applications to cellular networks by good quality tandeming with wideband from cellular networks will be one of the major application areas for IWAC. Things like Cell phone 1 codec type 'A' -> transcode to IWAC -> media/application server in the internet. Cell phone 2 codec type 'B' -> transcode to IWAC -> same media/application server in the internet. VoIP phone 3 on IWAC/internet -> same media/application server in the internet. etc. Stefan > > With best regards, > > Christian > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec -- Stefan Sayer VoIP Services stefan.sayer@iptego.com www.iptego.com IPTEGO GmbH Wittenbergplatz 1 10789 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann From csp@csperkins.org Thu Oct 22 13:15:38 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6E93A68EE for ; Thu, 22 Oct 2009 13:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, 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 V8QbRtTD3p-6 for ; Thu, 22 Oct 2009 13:15:36 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 1C1D63A6861 for ; Thu, 22 Oct 2009 13:15:36 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.12]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1N144X-00051K-ad; Thu, 22 Oct 2009 20:15:45 +0000 Message-Id: <962FBCE7-6D39-42CD-88DA-747A335641E9@csperkins.org> From: Colin Perkins To: Slava Borilin In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5-909952088 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Oct 2009 21:15:42 +0100 References: X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 20:15:38 -0000 --Apple-Mail-5-909952088 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Slava, RTP has the concept of a translator, which performs the functions =20 you're looking for in an application-layer middlebox, where it can be =20= part of the signalling and/or security context. This is not something =20= a router should do. Colin On 22 Oct 2009, at 20:22, Slava Borilin wrote: > Again - my point is that router does NOT have to know that something =20= > specifically is the codec, or specific codec- the only goal is to =20 > let router aware that the stream (and every packet) is LAYERED, and =20= > that it is legitimate to strip out some layers if necessary due to =20 > congestion. > The content of such =93layered=94 can be any =96 voice codec, video = codec, =20 > audio codec, any type of content. > > And I agree with Gregory =96 that having current infrastructure using =20= > layers in separate streams will require too much overhead (packets) =20= > which does not make sense as well =96 and I am thinking about one =20 > stream of packets comtaining all the layers, which, however, can be =20= > modified on the fly =93in the middle=94. > So we may think about more generic concept of =93declared layered =20 > content=94 which does NOT loose the information (well, most of it) by =20= > stripping out portions of the packet and reducing the traffic, so =20 > router can strip out any type of layered content, without going deep =20= > into specific codec. > > Again- this is =93na=EFve=94 suggestions from me (very limited = engineer) =96 =20 > and definitely I am looking for objections even more then for =20 > agreement =96 for the sake of either finding the idea useful or making = =20 > judged deny of it, and I agree that this concept is only one =20 > possible way of working with congestion. > > best regards, > Slava Borilin > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf OfSlava Borilin > Sent: Thursday, October 22, 2009 11:13 PM > To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > Henry, > With all of my respect (you know) =96 this is too high-level =20 > consideration and too generic statement which doesn=92t answer MPLS =20= > issue for example. > > best regards, > Slava Borilin > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, October 22, 2009 11:10 PM > To: Slava Borilin; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > Slava, > > >I am not that sure that routers should not be aware of the codecs. =20= > Why? > >If we are building MPLS and other systems that is content-=20 > dependent, why > >not let router understand the codec? > > The essence of the Dumb Network (Internet) and its routers is that =20 > it knows nothing about the applications. > All applications that nobody planned for can run over it. > The tragedy of the telephone network was is knew everything about =20 > its only one application. > > Henry > > > On 10/22/09 1:23 PM, "Slava Borilin" wrote: > > I am not that sure that routers should not be aware of the codecs. =20 > Why? > If we are building MPLS and other systems that is content-dependent, =20= > why > not let router understand the codec? > > Especially if we have hordes of voice channels going thru router, it =20= > can > be too hard and too long to tell each sender to reduce the rate - why > not to leave this freedom to router as this may be more efficient for > congestion recovery? > > Same applies to H.264SVC for example - at the end of the day, router =20= > do > not need to understand anything except that it is LAYERED streams =20 > (even > don't know whether its voice, video or audio or anything else of =20 > layered > nature, and router "has the right" to strip out layers in certain =20 > order > to prevent congestion? > > best regards, > Slava Borilin > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Thursday, October 22, 2009 5:45 PM > To: Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > Lars Eggert wrote: > > Also, what we've learned from media over DCCP is that if you don't > > involve the codec in some form, performance/quality will be bad. =20 > Some > > codecs need time to adjust the rate. Some can only adjust it in =20 > pretty > > > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > > involving the codec in some form, you might get very good TCP > > friendliness, but maybe quality will suffer. > > I'm totally in favour of "involving the codec" in here. I just want to > be > careful not to include in the codec things that don't belong there =20 > (e.g. > a > DCCP implementation or a whole jitter buffer). > > > (And there is always the ramping up part - congestion control will > never > > attempt to probe for more capacity unless the codec generates more > data, > > and why would the codec do that if it's converged to transmit at =20 > some > > lower rate.) > > Well, the codec transmits at the rate you ask it to use. If you want =20= > to > probe for more capacity, then you tell the codec that it can use a > higher > rate. Now, if there's a special way in which you want to ask the =20 > codec, > then maybe that can become an additional feature for the codec. > > > By no means should routers have to understand codec formats! Routers > > drop or mark IP packets. It is up to the application sending those =20= > IP > > packets to react appropriately to the marks or losses. In other =20 > words, > a > > layered codec will see losses/marks to packets sent on all layers, =20= > and > > > will then need to figure out whether to strip off a layer or not in > > response to whatever congestion level those losses/marks indicate. > > I definitely agree that the routers shouldn't know about codecs and =20= > this > is > why I was saying that IMO layered codecs aren't too useful for > congestion > control (though they have other uses). If there's nothing in the =20 > middle > of > the network to strip off the layers, then you might as well not have > layers > at all. All you need is to ask the sender to reduce the rate. You =20 > don't > need layers to have a multi-rate codec. Layering just means that you =20= > can > > strip off bits and still have the result sound OK. > > >> OK, I may be wrong here, but my understanding is that how much the > rate > >> should change depending on congestion is actually not that > >> codec-specific. > > > > It *can* be non-codec-specific, see DCCP for example. But quality =20= > will > > > suffer IMO. > > Well, we need to figure out the aspects that should be codec-specific > and > implement just those. Does anyone have a list of the issues codecs > should > be aware of? > > > Most Internet congestion control is based on *creating* losses/marks > to > > determine capacity. People have tried to create congestion control > > schemes that avoid causing losses (delay-based schemed, for =20 > example), > > but they are perceived to be more fragile. > > Yes, I can imagine the problem not being trivial at all. > > >> Once you figure this out, you > >> can just tell the codec to use that rate. > > > > It's not that easy, because rates in the Internet are never stable - > the > > rate computation is usually clocked by the RTT. You can obviously > dampen > > this somehow, but you can never say "now I have found a rate that I > can > > safely use forever." > > Oh, I never said we should set a rate forever. I was just saying that > you > can have one module that determines in real-time the best rate to =20 > use at > > that moment and then it tells the codec what to use. If it needs help > from > the codec, then we can define special functionality. > > >> On top of that, the codec may be > >> able to do a bit better by providing a "service" to the other =20 > layers. > On > >> example here (also included in the draft) is VBR, which means that > the > >> application specifies an average rate and the codec decides how to > >> vary the > >> rate to achieve that (subject to some rate control constraints). > Would > >> other such mechanisms be useful to deal with congestion? > > > > I'm not sure this would work, because congestion control will > basically > > change the VBR input parameter continuously. > > Changing the VBR parameters continuously is not a problem. VBR just > means > that you'd like to have an average of N kb/s for now, but you're OK if > there are variations from frame to frame. > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-5-909952088 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Slava,

RTP = has the concept of a translator, which performs the functions you're = looking for in an application-layer middlebox, where it can be part of = the signalling and/or security context. This is not something a router = should = do. 

Colin




On 22 Oct 2009, at 20:22, Slava = Borilin wrote:
Again - my point is that router does = NOT have to know that something specifically is the codec, or specific = codec- the only goal is to let router aware that the stream (and every = packet) is LAYERED, and that it is legitimate to strip out some layers = if necessary due to congestion.
The content = of such =93layered=94 can be any =96 voice codec, video codec, audio = codec, any type of content.
And I agree with Gregory =96 that = having current infrastructure using layers in separate streams will = require too much overhead (packets) which does not make sense as well =96 = and I am thinking about one stream of packets comtaining all the layers, = which, however, can be modified on the fly =93in the = middle=94.
So we may think about more generic = concept of =93declared layered content=94 which does NOT loose the = information (well, most of it) by stripping out portions of the packet = and reducing the traffic, so router can strip out any type of layered = content, without going deep into specific = codec.
Again- this is =93na=EFve=94 = suggestions from me (very limited engineer) =96 and definitely I am = looking for objections even more then for agreement =96 for the sake of = either finding the idea useful or making judged deny of it, and I agree = that this concept is only one possible way of working with = congestion.
best = regards,
Slava = Borilin
 codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf OfSlava = Borilin
Sent: Thursday, October 22, 2009 = 11:13 PM
To: Henry Sinnreich; Jean-Marc = Valin; Lars Eggert
 codec@ietf.org
 Re: [codec] updated charter = proposal
With all of my respect (you know) =96 = this is too high-level consideration and too generic statement which = doesn=92t answer MPLS issue for = example.
best = regards,
Slava = Borilin
 Henry Sinnreich [mailto:hsinnrei@adobe.com] 
Sent: Thursday, October 22, 2009 = 11:10 PM
To: Slava Borilin; Jean-Marc = Valin; Lars Eggert
 codec@ietf.org
 Re: [codec] updated charter = proposal
Slava,

>I am not that sure that = routers should not be aware of the codecs. Why?
>If we are = building MPLS and other systems that is content-dependent, = why
>not let router understand the codec?

The essence of = the Dumb Network (Internet) and its routers is that it knows nothing = about the applications.
All applications that nobody planned for can = run over it.
The tragedy of the telephone network was is knew = everything about its only one application.

Henry


On = 10/22/09 1:23 PM, "Slava Borilin" <I am not that sure = that routers should not be aware of the codecs. Why?
If we are = building MPLS and other systems that is content-dependent, why
not = let router understand the codec?

Especially if we have hordes of = voice channels going thru router, it can
be too hard and too long to = tell each sender to reduce the rate - why
not to leave this freedom = to router as this may be more efficient for
congestion = recovery?

Same applies to H.264SVC for example - at the end of = the day, router do
not need to understand anything except that it is = LAYERED streams (even
don't know whether its voice, video or audio or = anything else of layered
nature, and router "has the right" to strip = out layers in certain order
to prevent congestion?

best = regards,
Slava Borilin

-----Original = Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 = PM
To: Lars Eggert
Cc: be
careful = not to include in the codec things that don't belong there = (e.g.
a
DCCP implementation or a whole jitter buffer).

> = (And there is always the ramping up part - congestion control = will
never
> attempt to probe for more capacity unless the = codec generates more
data,
> and why would the codec do that if = it's converged to transmit at some
> lower rate.)

Well, the = codec transmits at the rate you ask it to use. If you want to
probe = for more capacity, then you tell the codec that it can use = a
higher
rate. Now, if there's a special way in which you want to = ask the codec,
then maybe that can become an additional feature for = the codec.

> By no means should routers have to understand = codec formats! Routers
> drop or mark IP packets. It is up to the = application sending those IP
> packets to react appropriately to = the marks or losses. In other words,
a
> layered codec will see = losses/marks to packets sent on all layers, and

> will then = need to figure out whether to strip off a layer or not in
> = response to whatever congestion level those losses/marks = indicate.

I definitely agree that the routers shouldn't know = about codecs and this
is
why I was saying that IMO layered codecs = aren't too useful for
congestion
control (though they have other = uses). If there's nothing in the middle
of
the network to strip = off the layers, then you might as well not have
layers
at all. All = you need is to ask the sender to reduce the rate. You don't
need = layers to have a multi-rate codec. Layering just means that you = can

strip off bits and still have the result sound = OK.

>> OK, I may be wrong here, but my understanding is = that how much the
rate
>> should change depending on = congestion is actually not that
>> = codec-specific.
>
> It *can* be non-codec-specific, see DCCP = for example. But quality will

> suffer IMO.

Well, we = need to figure out the aspects that should be = codec-specific
and
implement just those. Does anyone have a list = of the issues codecs
should
be aware of?

> Most Internet = congestion control is based on *creating* losses/marks
to
> = determine capacity. People have tried to create congestion = control
> schemes that avoid causing losses (delay-based schemed, = for example),
> but they are perceived to be more = fragile.

Yes, I can imagine the problem not being trivial at = all.

>> Once you figure this out, you
>> can just = tell the codec to use that rate.
>
> It's not that easy, = because rates in the Internet are never stable -
the
> rate = computation is usually clocked by the RTT. You can = obviously
dampen
> this somehow, but you can never say "now I = have found a rate that I
can
> safely use forever."

Oh, = I never said we should set a rate forever. I was just saying = that
you
can have one module that determines in real-time the best = rate to use at

that moment and then it tells the codec what to = use. If it needs help
from
the codec, then we can define special = functionality.

>> On top of that, the codec may = be
>> able to do a bit better by providing a "service" to the = other layers.
On
>> example here (also included in the = draft) is VBR, which means that
the
>> application specifies = an average rate and the codec decides how to
>> vary = the
>> rate to achieve that (subject to some rate control = constraints).
Would
>> other such mechanisms be useful to = deal with congestion?
>
> I'm not sure this would work, = because congestion control will
basically
> change the VBR = input parameter continuously.

Changing the VBR parameters = continuously is not a problem. VBR just
means
that you'd like to = have an average of N kb/s for now, but you're OK if
there are = variations from frame to = frame.

        Jean-Marc_______________________________________________
codec mailing = list
codec@ietf.org
codec@ietf.org
codec@ietf.org


-- 
Colin Perkins


 =

= --Apple-Mail-5-909952088-- From thorvald@natvig.com Thu Oct 22 13:25:25 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF373A677E for ; Thu, 22 Oct 2009 13:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8ydrMWLD-9M for ; Thu, 22 Oct 2009 13:25:25 -0700 (PDT) Received: from mix.hive.no (unknown [IPv6:2001:700:2300:1e:211:43ff:fe31:48fe]) by core3.amsl.com (Postfix) with ESMTP id AF1D73A659B for ; Thu, 22 Oct 2009 13:25:24 -0700 (PDT) Received: from [172.20.1.15] (86.80-202-219.nextgentel.com [80.202.219.86]) (authenticated bits=0) by mix.hive.no (8.13.8/8.13.8) with ESMTP id n9MKPVJG001927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Oct 2009 22:25:32 +0200 Message-ID: <4AE0BFA7.1040106@natvig.com> Date: Thu, 22 Oct 2009 22:25:11 +0200 From: Thorvald Natvig User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "codec@ietf.org" References: <4ADE2ED9.2030101@stpeter.im><4ADF0C41.3010808@octasic.com><030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> <4AE061F5.7080301@octasic.com>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/9929/Thu Oct 22 21:50:58 2009 on mix.hive.no X-Virus-Status: Clean Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 20:25:25 -0000 Hi, The problem with congestion control protocols is that they have limited implementation on consumer level hardware. We've tried something as simple as setting the IP TOS byte to try to prioritize voice packets, and in practice very few home routers honor it, and there are quite a few wireless routers which silently discard frames with the TOS byte set. The reason we even tried this is that there is nothing we can do about our own stream to help the latency or congestion; the problem is usually that the user is also uploading quite a few torrents, so their uplink is completely full. For most networks, the bottleneck is that first/last hop; it's the home users DSL/Cable connection, or a WiFi connection that has to compete with other networks on the same channel, or it could be the mobile users's connection to the tower. Beyond that point there is usually sufficient bandwidth that congestion doesn't occur. I don't think this problem is going to improve; I can't think of any congestion control which can make my neighbour's WiFi network back off when I want to transmit high priority packets. So, while interfacing with congestion protocols and teaching routers about codecs may be something we'd like in an ideal world, it's more important to create a codec that will work in real world networks, which are congested and buggy, and are configured and used by non-technical people. Best Regards, Thorvald From mknappe@juniper.net Thu Oct 22 14:54:51 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E3C28C1A3 for ; Thu, 22 Oct 2009 14:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIudrWDiuRdd for ; Thu, 22 Oct 2009 14:54:50 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id C524128C180 for ; Thu, 22 Oct 2009 14:54:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSuDUqh5W5G7PlC7Kum/H9jCmqH3NEFjx@postini.com; Thu, 22 Oct 2009 14:55:00 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 22 Oct 2009 14:54:02 -0700 From: Michael Knappe To: Slava Borilin , Christian Hoene Date: Thu, 22 Oct 2009 14:54:20 -0700 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpTQQ0GVCpuFyb1DUumK8cQUm7XlgACenkgAAD1Y7AABNo36A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:54:51 -0000 The rather extreme example I was thinking was a cell phone coming in via TD= M to an IP PBX based branch office, then, being forwarded via SIP trunk usi= ng the proposed internet codec to another IP PBX branch where it happens to= get routed off the PBX via TDM and the PSTN to another cell network and ph= one. This is a particularly problematic multiple tandem scenario with sever= al passes through G.711, but even a double tandem scenario of a cell phone = codec transcoded through G.711 and TDM then transcoded again to reach an IP= network endpoint on a fabric using the proposed codec would be relatively = common in the near term. >From a 40,000 ft level, this all becomes a multi-variate quality balance of= the different non-linear human perception impact thresholds (one-way delay= , distortion, noise, residual echo, etc). It's difficult from the quality p= erspective to separate a single codec out of the end-to-end quality equatio= n due to the non-linearity of the human perception curves. For example, the= perceived quality impact of one-way network delay stays relatively low and= constant below 150 ms, but rises dramatically by the time you hit 250 ms).= In the case of one-way delay, you can have two codecs that by themselves e= asily meet the 150 ms quality criteria on their own, but once in-situ and t= andemed, they cross the knee of the non-linear quality impact curve with a = noticeable impact on quality. This can easily be heard on many cell-phone t= o cell-phone calls across disparate cell networks. That said, we most definitely should have specific quality goals and measur= ement methodologies specified for the codec on its own. Just recommending f= rom my own experience that we define a few more complex topologies where we= look at end-to-end quality with the new codec in-situ. Mike On 10/22/09 12:40 PM, "Slava Borilin" wrote: Michael, If you are thinking about core network to carry voice in IP between BSCs - why should you care about any of internet codecs- as this is managed network normally? Or I misunderstand you goal? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene Sent: Thursday, October 22, 2009 11:33 PM To: 'Michael Knappe' Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements Dear Michael Knappe, > Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to > cell phone 2 codec type 'B' Honestly, in this case I would recommend you to use ITU codecs because they have been designed for these use cases. With best regards, Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hsinnrei@adobe.com Thu Oct 22 17:07:12 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F523A68A9 for ; Thu, 22 Oct 2009 17:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Giqz2L4LkyMv for ; Thu, 22 Oct 2009 17:07:10 -0700 (PDT) Received: from psmtp.com (exprod6ob114.obsmtp.com [64.18.1.32]) by core3.amsl.com (Postfix) with ESMTP id 2E5453A6863 for ; Thu, 22 Oct 2009 17:07:08 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKSuDzr4nRw8xMMTA5JRy1viDanLhH6oaa@postini.com; Thu, 22 Oct 2009 17:07:21 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9N004ao007314; Thu, 22 Oct 2009 17:00:04 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9N077iq013101; Thu, 22 Oct 2009 17:07:07 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 22 Oct 2009 17:07:07 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Thu, 22 Oct 2009 17:07:07 -0700 From: Henry Sinnreich To: Michael Knappe , Slava Borilin , Christian Hoene Date: Thu, 22 Oct 2009 17:07:03 -0700 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpTQQ0GVCpuFyb1DUumK8cQUm7XlgACenkgAAD1Y7AABNo36AAEopQV Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7065DD768D5hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 00:07:12 -0000 --_000_C7065DD768D5hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mike, >The rather extreme example I was thinking was a cell phone coming in via T= DM to an IP PBX based branch >office, then, being forwarded via SIP trunk u= sing the proposed internet codec to another IP PBX branch where >it happens= to get routed off the PBX via TDM and the PSTN to another cell network and= phone. This is a >particularly problematic multiple tandem scenario with s= everal passes through G.711, but even a double >tandem scenario of a cell p= hone codec transcoded through G.711 and TDM then transcoded again to reach = an >IP network endpoint on a fabric using the proposed codec would be relative= ly common in the near term. How about using the Internet e2e topology? Henry On 10/22/09 4:54 PM, "Michael Knappe" wrote: The rather extreme example I was thinking was a cell phone coming in via TD= M to an IP PBX based branch office, then, being forwarded via SIP trunk usi= ng the proposed internet codec to another IP PBX branch where it happens to= get routed off the PBX via TDM and the PSTN to another cell network and ph= one. This is a particularly problematic multiple tandem scenario with sever= al passes through G.711, but even a double tandem scenario of a cell phone = codec transcoded through G.711 and TDM then transcoded again to reach an IP= network endpoint on a fabric using the proposed codec would be relatively = common in the near term. >From a 40,000 ft level, this all becomes a multi-variate quality balance of= the different non-linear human perception impact thresholds (one-way delay= , distortion, noise, residual echo, etc). It's difficult from the quality p= erspective to separate a single codec out of the end-to-end quality equatio= n due to the non-linearity of the human perception curves. For example, the= perceived quality impact of one-way network delay stays relatively low and= constant below 150 ms, but rises dramatically by the time you hit 250 ms).= In the case of one-way delay, you can have two codecs that by themselves e= asily meet the 150 ms quality criteria on their own, but once in-situ and t= andemed, they cross the knee of the non-linear quality impact curve with a = noticeable impact on quality. This can easily be heard on many cell-phone t= o cell-phone calls across disparate cell networks. That said, we most definitely should have specific quality goals and measur= ement methodologies specified for the codec on its own. Just recommending f= rom my own experience that we define a few more complex topologies where we= look at end-to-end quality with the new codec in-situ. Mike On 10/22/09 12:40 PM, "Slava Borilin" wrote: Michael, If you are thinking about core network to carry voice in IP between BSCs - why should you care about any of internet codecs- as this is managed network normally? Or I misunderstand you goal? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene Sent: Thursday, October 22, 2009 11:33 PM To: 'Michael Knappe' Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements Dear Michael Knappe, > Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to > cell phone 2 codec type 'B' Honestly, in this case I would recommend you to use ITU codecs because they have been designed for these use cases. With best regards, Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C7065DD768D5hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] codec tandeming/codec-requirements Mike,

>The rather extreme example I was thinking was a cell phone coming in vi= a TDM to an IP PBX based branch >office, then, being forwarded via SIP t= runk using the proposed internet codec to another IP PBX branch where >i= t happens to get routed off the PBX via TDM and the PSTN to another cell ne= twork and phone. This is a >particularly problematic multiple tandem sce= nario with several passes through G.711, but even a double >tandem scena= rio of a cell phone codec transcoded through G.711 and TDM then transcoded = again to reach an
>IP network endpoint on a fabric using the proposed codec would be relat= ively common in the near term.

How about using the Internet e2e topology?

Henry


On 10/22/09 4:54 PM, "Michael Knappe" <mknappe@juniper.net> wrote:

The rather extreme example I was thinking w= as a cell phone coming in via TDM to an IP PBX based branch office, then, b= eing forwarded via SIP trunk using the proposed internet codec to another I= P PBX branch where it happens to get routed off the PBX via TDM and the PST= N to another cell network and phone. This is a particularly problematic mul= tiple tandem scenario with several passes through G.711, but even a double = tandem scenario of a cell phone codec transcoded through G.711 and TDM then= transcoded again to reach an IP network endpoint on a fabric using the pro= posed codec would be relatively common in the near term.

>From a 40,000 ft level, this all becomes a multi-variate quality balance of= the different non-linear human perception impact thresholds (one-way delay= , distortion, noise, residual echo, etc). It's difficult from the quality p= erspective to separate a single codec out of the end-to-end quality equatio= n due to the non-linearity of the human perception curves. For example, the= perceived quality impact of one-way network delay stays relatively low and= constant below 150 ms, but rises dramatically by the time you hit 250 ms).= In the case of one-way delay, you can have two codecs that by themselves e= asily meet the 150 ms quality criteria on their own, but once in-situ and t= andemed, they cross the knee of the non-linear quality impact curve with a = noticeable impact on quality. This can easily be heard on many cell-phone t= o cell-phone calls across disparate cell networks.

That said, we most definitely should have specific quality goals and measur= ement methodologies specified for the codec on its own. Just recommending f= rom my own experience that we define a few more complex topologies where we= look at end-to-end quality with the new codec in-situ.

Mike


On 10/22/09 12:40 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

Michael,

If you are thinking about core network to carry voice in IP between BSCs - why should you care about any of internet codecs- as this is managed
network normally?

Or I misunderstand you goal?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf
Of Christian Hoene
Sent: Thursday, October 22, 2009 11:33 PM
To: 'Michael Knappe'
Cc: codec@ietf.org
Subject: Re: [codec] codec tandeming/codec-requirements

Dear Michael Knappe,

> Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to
> cell phone 2 codec type 'B'

Honestly, in this case I would recommend you to use ITU codecs because
they
have been designed for these use cases.

With best regards,

 Christian




_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C7065DD768D5hsinnreiadobecom_-- From swmike@swm.pp.se Thu Oct 22 22:49:31 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8193A69B2 for ; Thu, 22 Oct 2009 22:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLFyDh3g8BIX for ; Thu, 22 Oct 2009 22:49:31 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 10D873A67CF for ; Thu, 22 Oct 2009 22:49:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 296599C; Fri, 23 Oct 2009 07:49:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 264709A; Fri, 23 Oct 2009 07:49:39 +0200 (CEST) Date: Fri, 23 Oct 2009 07:49:39 +0200 (CEST) From: Mikael Abrahamsson To: Slava Borilin In-Reply-To: Message-ID: References: <4AE0B64C.9020402@octasic.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 05:49:32 -0000 On Thu, 22 Oct 2009, Slava Borilin wrote: > Question is when it comes to congestion - it is worth "teaching > routers", or this does not make sense from overall economy. IP was successful because the "network" didn't need to handle applications. Getting application specific tech into routers is a 5+ year waiting period (ECN still isn't there, and that's quite simple) and the direction routers are taking right now is bigger, faster and simpler, not the other way around. So any proposal that relies on "the Internet" doing something special to your packets outside of what it already can do and what's in the pipe, will delay deployment for a long time. Relying on ECN (optionally) for congestion signals might work though, that's been in the pipe for 5+ years and some adoption might happen. -- Mikael Abrahamsson email: swmike@swm.pp.se From Borilin@spiritdsp.com Fri Oct 23 00:24:24 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C15C28C0F3 for ; Fri, 23 Oct 2009 00:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 tqsLTAj4P8BD for ; Fri, 23 Oct 2009 00:24:21 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id B69013A6897 for ; Fri, 23 Oct 2009 00:24:18 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9N7OL09099689; Fri, 23 Oct 2009 11:24:22 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) 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_01CA53B1.D3EA64E8" Date: Fri, 23 Oct 2009 11:24:16 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpTQQ0GVCpuFyb1DUumK8cQUm7XlgACenkgAAD1Y7AABNo36AAEopQVAAx4shA= References: From: "Slava Borilin" To: "Henry Sinnreich" , "Michael Knappe" , "Christian Hoene" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 07:24:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA53B1.D3EA64E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Henry, e2e (or p2p) is cool but what about Legal interception for example in this case, which every cellco has to implemenet? =20 best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Friday, October 23, 2009 4:07 AM To: Michael Knappe; Slava Borilin; Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements =20 Mike, >The rather extreme example I was thinking was a cell phone coming in via TDM to an IP PBX based branch >office, then, being forwarded via SIP trunk using the proposed internet codec to another IP PBX branch where >it happens to get routed off the PBX via TDM and the PSTN to another cell network and phone. This is a >particularly problematic multiple tandem scenario with several passes through G.711, but even a double >tandem scenario of a cell phone codec transcoded through G.711 and TDM then transcoded again to reach an=20 >IP network endpoint on a fabric using the proposed codec would be relatively common in the near term. How about using the Internet e2e topology? Henry On 10/22/09 4:54 PM, "Michael Knappe" wrote: The rather extreme example I was thinking was a cell phone coming in via TDM to an IP PBX based branch office, then, being forwarded via SIP trunk using the proposed internet codec to another IP PBX branch where it happens to get routed off the PBX via TDM and the PSTN to another cell network and phone. This is a particularly problematic multiple tandem scenario with several passes through G.711, but even a double tandem scenario of a cell phone codec transcoded through G.711 and TDM then transcoded again to reach an IP network endpoint on a fabric using the proposed codec would be relatively common in the near term. >From a 40,000 ft level, this all becomes a multi-variate quality balance of the different non-linear human perception impact thresholds (one-way delay, distortion, noise, residual echo, etc). It's difficult from the quality perspective to separate a single codec out of the end-to-end quality equation due to the non-linearity of the human perception curves. For example, the perceived quality impact of one-way network delay stays relatively low and constant below 150 ms, but rises dramatically by the time you hit 250 ms). In the case of one-way delay, you can have two codecs that by themselves easily meet the 150 ms quality criteria on their own, but once in-situ and tandemed, they cross the knee of the non-linear quality impact curve with a noticeable impact on quality. This can easily be heard on many cell-phone to cell-phone calls across disparate cell networks. That said, we most definitely should have specific quality goals and measurement methodologies specified for the codec on its own. Just recommending from my own experience that we define a few more complex topologies where we look at end-to-end quality with the new codec in-situ. Mike On 10/22/09 12:40 PM, "Slava Borilin" wrote: Michael, If you are thinking about core network to carry voice in IP between BSCs - why should you care about any of internet codecs- as this is managed network normally? Or I misunderstand you goal? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene Sent: Thursday, October 22, 2009 11:33 PM To: 'Michael Knappe' Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements Dear Michael Knappe, > Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to > cell phone 2 codec type 'B' Honestly, in this case I would recommend you to use ITU codecs because they have been designed for these use cases. With best regards, Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA53B1.D3EA64E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [codec] codec tandeming/codec-requirements

Henry, e2e (or = p2p) is cool but what about Legal interception for example in this case, which = every cellco has to implemenet?

 =

best regards,

Slava = Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Friday, October 23, = 2009 4:07 AM
To: Michael Knappe; Slava = Borilin; Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] = codec tandeming/codec-requirements

 

Mike,

>The rather extreme example I was thinking was a cell phone coming in = via TDM to an IP PBX based branch >office, then, being forwarded via SIP = trunk using the proposed internet codec to another IP PBX branch where >it = happens to get routed off the PBX via TDM and the PSTN to another cell network = and phone. This is a >particularly problematic multiple tandem scenario = with several passes through G.711, but even a double >tandem scenario of a = cell phone codec transcoded through G.711 and TDM then transcoded again to = reach an
>IP network endpoint on a fabric using the proposed codec would be relatively common in the near term.

How about using the Internet e2e topology?

Henry


On 10/22/09 4:54 PM, "Michael Knappe" <mknappe@juniper.net> = wrote:

The rather extreme = example I was thinking was a cell phone coming in via TDM to an IP PBX based branch = office, then, being forwarded via SIP trunk using the proposed internet codec to another IP PBX branch where it happens to get routed off the PBX via TDM = and the PSTN to another cell network and phone. This is a particularly = problematic multiple tandem scenario with several passes through G.711, but even a = double tandem scenario of a cell phone codec transcoded through G.711 and TDM = then transcoded again to reach an IP network endpoint on a fabric using the = proposed codec would be relatively common in the near term.

>From a 40,000 ft level, this all becomes a multi-variate quality balance = of the different non-linear human perception impact thresholds (one-way delay, distortion, noise, residual echo, etc). It's difficult from the quality perspective to separate a single codec out of the end-to-end quality = equation due to the non-linearity of the human perception curves. For example, = the perceived quality impact of one-way network delay stays relatively low = and constant below 150 ms, but rises dramatically by the time you hit 250 = ms). In the case of one-way delay, you can have two codecs that by themselves = easily meet the 150 ms quality criteria on their own, but once in-situ and = tandemed, they cross the knee of the non-linear quality impact curve with a = noticeable impact on quality. This can easily be heard on many cell-phone to = cell-phone calls across disparate cell networks.

That said, we most definitely should have specific quality goals and measurement methodologies specified for the codec on its own. Just = recommending from my own experience that we define a few more complex topologies = where we look at end-to-end quality with the new codec in-situ.

Mike


On 10/22/09 12:40 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

Michael,

If you are thinking about core network to carry voice in IP between = BSCs
- why should you care about any of internet codecs- as this is = managed
network normally?

Or I misunderstand you goal?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf
Of Christian Hoene
Sent: Thursday, October 22, 2009 11:33 PM
To: 'Michael Knappe'
Cc: codec@ietf.org
Subject: Re: [codec] codec tandeming/codec-requirements

Dear Michael Knappe,

> Cell phone 1 codec type 'A' -> transcode to internet codec = ->
transcode to
> cell phone 2 codec type 'B'

Honestly, in this case I would recommend you to use ITU codecs = because
they
have been designed for these use cases.

With best regards,

 Christian




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

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

------_=_NextPart_001_01CA53B1.D3EA64E8-- From lars.eggert@nokia.com Fri Oct 23 00:34:17 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643813A67D1 for ; Fri, 23 Oct 2009 00:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 bLRVOdW44DnC for ; Fri, 23 Oct 2009 00:34:16 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 353F33A67AF for ; Fri, 23 Oct 2009 00:34:16 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9N7YJf3082506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Oct 2009 10:34:19 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-73-950668453; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AE0BFA7.1040106@natvig.com> Date: Fri, 23 Oct 2009 10:34:18 +0300 Message-Id: <1151836F-F070-4243-BB2F-BA3EF4FEF7EC@nokia.com> References: <4ADE2ED9.2030101@stpeter.im><4ADF0C41.3010808@octasic.com><030726E0-55AC-4828-B6D9-926550CF70A9@nokia.com> <4AE061F5.7080301@octasic.com>, <4AE0BFA7.1040106@natvig.com> To: Thorvald Natvig X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Fri, 23 Oct 2009 10:34:19 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 07:34:17 -0000 --Apple-Mail-73-950668453 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-22, at 23:25, Thorvald Natvig wrote: > The problem with congestion control protocols is that they have > limited > implementation on consumer level hardware. > > We've tried something as simple as setting the IP TOS byte to try to > prioritize voice packets please understand that setting or honoring DSCPs is *not* congestion control. Congestion control requires a sender to lower the rate of a flow when that flow experiences packet loss (or ECN marks). Lars --Apple-Mail-73-950668453 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyMzA3MzQxOVowIwYJKoZIhvcNAQkEMRYEFAHTUd1KVpLv9ZapJebGh71gxbTgMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCDzjT1PruNq9azWv7vRPg1Pa/3RTZLt4rvDaUOC+TfSpDbLK8hfJ/1JS0TTq+nscALxajy 6PKfRl0bvU3rE/ays+D11jsXIAmj9WJ8vGXPajXfrLRmOYOkecQWX0YRjuPu1EdTN4maLoImEcl5 9fLkwTU/u5wCfSUTTUnG9udcit2n96PM400BkauwzD6e+X3vr7gRjlLMJ8L8PzKX81dRxCzf8OAm Hlq6hATBzYoRFNS1idZk7zqU0C6iv+dYt5m+TPpccUAM0KNPj7IDK2WubDSLtcZJerUwwnazicDz rDdBbkWwytuFHsXNgSal9N0/1YUmSOrROvOe21G6FFSrAAAAAAAA --Apple-Mail-73-950668453-- From ron@debian.org Fri Oct 23 02:48:30 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF76C3A6767 for ; Fri, 23 Oct 2009 02:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] 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 nIW16-tbLMZ2 for ; Fri, 23 Oct 2009 02:48:30 -0700 (PDT) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [203.16.214.141]) by core3.amsl.com (Postfix) with ESMTP id 8E48328C0D0 for ; Fri, 23 Oct 2009 02:48:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAM8W4Up20iqP/2dsb2JhbACBUNcgAoQ9BA Received: from ppp118-210-42-143.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.42.143]) by ipmail03.adl6.internode.on.net with ESMTP; 23 Oct 2009 20:18:38 +1030 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id D11AC4F8F3 for ; Fri, 23 Oct 2009 20:18:36 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rQTW+dXuauR4 for ; Fri, 23 Oct 2009 20:18:36 +1030 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 7F9414F8FE; Fri, 23 Oct 2009 20:18:36 +1030 (CST) Date: Fri, 23 Oct 2009 20:18:36 +1030 From: Ron To: codec@ietf.org Message-ID: <20091023094836.GC17159@audi.shelbyville.oz> References: <00cc01ca534e$75f8e200$61eaa600$@de> <4AE0BBC1.9050402@iptego.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AE0BBC1.9050402@iptego.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 09:48:30 -0000 On Thu, Oct 22, 2009 at 10:08:33PM +0200, Stefan Sayer wrote: > o Christian Hoene [10/22/09 21:32]: > >Dear Michael Knappe, > > > >>Cell phone 1 codec type 'A' -> transcode to internet codec -> transcode to > >>cell phone 2 codec type 'B' > > > >Honestly, in this case I would recommend you to use ITU codecs because they > >have been designed for these use cases. > > I don't think so. IMO bringing applications to cellular networks by > good quality tandeming with wideband from cellular networks will be > one of the major application areas for IWAC. Things like > > Cell phone 1 codec type 'A' -> transcode to IWAC -> > media/application server in the internet. > > Cell phone 2 codec type 'B' -> transcode to IWAC -> same > media/application server in the internet. > > VoIP phone 3 on IWAC/internet -> same media/application server in > the internet. By the time this codec is widely deployed will there be (m)any mobile devices without technology to do IP directly? If "codec type 'A'" is a terrible codec for this purpose, how far should we compromise to get acceptable results with things that are "off the internet"? I agree this raises interesting issues to consider, but requiring compatibility with particular legacy codecs seems more like a SHOULD than a MUST. I think I'd rather change the string between my tin cans than have this codec constrained to its current best passband. Ron From bmschwar@fas.harvard.edu Fri Oct 23 06:29:24 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339F23A67A8 for ; Fri, 23 Oct 2009 06:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR9AFHWwapgU for ; Fri, 23 Oct 2009 06:29:23 -0700 (PDT) Received: from us25.unix.fas.harvard.edu (us25.unix.fas.harvard.edu [140.247.35.201]) by core3.amsl.com (Postfix) with ESMTP id 4C9AA3A68D7 for ; Fri, 23 Oct 2009 06:29:23 -0700 (PDT) Received: from [192.168.1.100] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us25.unix.fas.harvard.edu (Postfix) with ESMTPSA id 4AE341D75E0; Fri, 23 Oct 2009 09:29:32 -0400 (EDT) Message-ID: <4AE1AFBB.2030206@fas.harvard.edu> Date: Fri, 23 Oct 2009 09:29:31 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 To: Slava Borilin References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF2EDE27818B10CB82FE57C03" Cc: codec@ietf.org Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:29:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2EDE27818B10CB82FE57C03 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Slava Borilin wrote: > Henry, e2e (or p2p) is cool but what about Legal interception for > example in this case, which every cellco has to implemenet? Whether or not we want to encourage it, interception of VoIP traffic does= not require a re-encode. The encoded packets can just be copied to the additional receiver. To address the "tandeming" issue, I think the following text should be added to the "Basic Requirements" or "Additional Considerations": """ Audio Corruption Robustness The systems providing input to the encoder and output from the decoder ar= e likely to be far from ideal in actual use. Input and output audio stream= s may be corrupted by artifacts from analog hardware and digital processing= =2E The codecs to be developed should be tested to ensure that they degrade gracefully under adverse audio conditions. Types of digital corruption that may be tested include tandem encoding with similar and different codecs, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. """ --------------enigF2EDE27818B10CB82FE57C03 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkrhr7wACgkQUJT6e6HFtqT4MQCcDKcll6RSbkhjz5yrCHvuafKi LIEAni9z19XdVaMbT60NmmJpdLpDuUOg =/g8R -----END PGP SIGNATURE----- --------------enigF2EDE27818B10CB82FE57C03-- From hsinnrei@adobe.com Fri Oct 23 07:18:22 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657C63A6910 for ; Fri, 23 Oct 2009 07:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sujaA4Auv0bj for ; Fri, 23 Oct 2009 07:18:17 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by core3.amsl.com (Postfix) with ESMTP id 3B9873A67D9 for ; Fri, 23 Oct 2009 07:18:17 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKSuG7MK8N0y37Dn43nl7R5yivPRpH2pCm@postini.com; Fri, 23 Oct 2009 07:18:28 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9NEILX3015496; Fri, 23 Oct 2009 07:18:21 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9NEIKiq016169; Fri, 23 Oct 2009 07:18:20 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Fri, 23 Oct 2009 07:18:20 -0700 From: Henry Sinnreich To: "bens@alum.mit.edu" , Slava Borilin Date: Fri, 23 Oct 2009 07:18:17 -0700 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpT5OB+5KLCTKqPSzuhvDpUYsBVXgABsmir Message-ID: In-Reply-To: <4AE1AFBB.2030206@fas.harvard.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C70725596920hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 14:18:22 -0000 --_000_C70725596920hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Whether or not we want to encourage it, interception of VoIP traffic does = not require a re-encode. >The encoded packets can just be copied to the additional receiver. This is correct IMO. There is also traffic analysis and many other tools - not the right topic f= or this list. Henry On 10/23/09 8:29 AM, "Benjamin M. Schwartz" wrot= e: Slava Borilin wrote: > Henry, e2e (or p2p) is cool but what about Legal interception for > example in this case, which every cellco has to implemenet? Whether or not we want to encourage it, interception of VoIP traffic does not require a re-encode. The encoded packets can just be copied to the additional receiver. To address the "tandeming" issue, I think the following text should be added to the "Basic Requirements" or "Additional Considerations": """ Audio Corruption Robustness The systems providing input to the encoder and output from the decoder are likely to be far from ideal in actual use. Input and output audio streams may be corrupted by artifacts from analog hardware and digital processing. The codecs to be developed should be tested to ensure that they degrade gracefully under adverse audio conditions. Types of digital corruption that may be tested include tandem encoding with similar and different codecs, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. """ --_000_C70725596920hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] codec tandeming/codec-requirements >Whether or not we want to encourage it, interception of VoIP traf= fic does not require a re-encode.  
>The encoded packets can just be copied to the additional receiver.

This is correct IMO.
There is also traffic analysis and many other tools – not the right t= opic for this list.
Henry


On 10/23/09 8:29 AM, "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> wrote:

Slava Borilin wrote:
> Henry, e2e (or p2p) is cool but what about Legal interception for
> example in this case, which every cellco has to implemenet?

Whether or not we want to encourage it, interception of VoIP traffic does not require a re-encode.  The encoded packets can just be copied to th= e
additional receiver.

To address the "tandeming" issue, I think the following text shou= ld be
added to the "Basic Requirements" or "Additional Considerati= ons":

"""
Audio Corruption Robustness

The systems providing input to the encoder and output from the decoder are<= BR> likely to be far from ideal in actual use.  Input and output audio str= eams
may be corrupted by artifacts from analog hardware and digital processing.<= BR>  The codecs to be developed should be tested to ensure that they degra= de
gracefully under adverse audio conditions.  Types of digital corruptio= n
that may be tested include tandem encoding with similar and different
codecs, low-quality resampling, and digital clipping.  Types of analog=
corruption that may be tested include microphones with substantial
background noise, analog clipping, and loudspeaker distortion.
"""


--_000_C70725596920hsinnreiadobecom_-- From hsinnrei@adobe.com Fri Oct 23 07:22:19 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893F13A683E for ; Fri, 23 Oct 2009 07:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R1zP1RgTHlP for ; Fri, 23 Oct 2009 07:22:18 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by core3.amsl.com (Postfix) with ESMTP id 9AE8D3A67D9 for ; Fri, 23 Oct 2009 07:22:17 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKSuG8HjxfgFVY3pvKL7OMT9aA5U7+o8ti@postini.com; Fri, 23 Oct 2009 07:22:29 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9NEMFX3016149; Fri, 23 Oct 2009 07:22:15 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9NEMEiq017132; Fri, 23 Oct 2009 07:22:14 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Fri, 23 Oct 2009 07:22:14 -0700 From: Henry Sinnreich To: Mikael Abrahamsson , Slava Borilin Date: Fri, 23 Oct 2009 07:22:13 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTpKPnMylWCzziTquxBg/E371W/wAR5LjM Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C70726456924hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 14:22:19 -0000 --_000_C70726456924hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >So any proposal that relies on "the Internet" doing something special to y= our packets >outside of what it already can do and what's in the pipe, will delay deplo= yment for a long time. Actually for ever. See the Internet stats and the link to the NANOG present= ed slides: http://www.telco2.net/blog/2009/10/perhaps_the_most_important_cha_1.html Henry On 10/23/09 12:49 AM, "Mikael Abrahamsson" wrote: On Thu, 22 Oct 2009, Slava Borilin wrote: > Question is when it comes to congestion - it is worth "teaching > routers", or this does not make sense from overall economy. IP was successful because the "network" didn't need to handle applications. Getting application specific tech into routers is a 5+ year waiting period (ECN still isn't there, and that's quite simple) and the direction routers are taking right now is bigger, faster and simpler, not the other way around. So any proposal that relies on "the Internet" doing something special to your packets outside of what it already can do and what's in the pipe, will delay deployment for a long time. Relying on ECN (optionally) for congestion signals might work though, that's been in the pipe for 5+ years and some adoption might happen. -- Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C70726456924hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal >So any proposal that relies on "the Internet" doing som= ething special to your packets
>outside of what it already can do and what's in the pipe, will delay de= ployment for a long time.

Actually for ever. See the Internet stats and the link to the NANOG present= ed slides:

http://www.telco2.net/blog/2009/10/perhaps_the_most_important_cha= _1.html

Henry


On 10/23/09 12:49 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:

On Thu, 22 Oct 2009, Slava Borilin wrote:
> Question is when it comes to congestion - it is worth "teaching > routers", or this does not make sense from overall economy.

IP was successful because the "network" didn't need to handle
applications. Getting application specific tech into routers is a 5+ year waiting period (ECN still isn't there, and that's quite simple) and the
direction routers are taking right now is bigger, faster and simpler, not the other way around.

So any proposal that relies on "the Internet" doing something spe= cial to
your packets outside of what it already can do and what's in the pipe,
will delay deployment for a long time.

Relying on ECN (optionally) for congestion signals might work though,
that's been in the pipe for 5+ years and some adoption might happen.

--
Mikael Abrahamsson    email: sw= mike@swm.pp.se
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C70726456924hsinnreiadobecom_-- From ron.even.tlv@gmail.com Sat Oct 24 02:58:26 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCCAD28C0E6 for ; Sat, 24 Oct 2009 02:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.346 X-Spam-Level: * X-Spam-Status: No, score=1.346 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FRT_ADOBE2=2.455, 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 6EDi9e9-Qj85 for ; Sat, 24 Oct 2009 02:58:14 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id CB51128C0F3 for ; Sat, 24 Oct 2009 02:58:13 -0700 (PDT) Received: by fxm18 with SMTP id 18so10921282fxm.37 for ; Sat, 24 Oct 2009 02:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=ZSHqj5X9cMzZyJ404G95DPtSFjwreMTAhfegaIGAgfo=; b=mNTBs8NqZDVMsICpebUvJDN/NflWqXVxETBtR5jdLiIVycZG4Est3Gpf5R5ZArxnX6 NdE7rl1+dyzqwOtkAT3lxb2g4uqUqjnMX5mMcVIoWO+i7iMh2myJiKRQN+7E8wmQ8v+X 1yQEeVJyeH+qv4NxsC9r7QlkefCTWM0NZvhEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=UBfDyhAEd3nmYGK64v2GHaOjUi6VmFsD6uZ8+yz2Yphr1dOB8WdBiHrFzWdPyN9Fpt m9npfw/HrPVPR9KdxF0FpVCydANviCrMxEjnaagBU0kFnpe2rxJMSz7s1zkQYaI/vHB1 YosWLRBog2D7E1U6Tvp8ANNyLNHKhfbtCW0tM= Received: by 10.103.84.10 with SMTP id m10mr5037807mul.60.1256378301132; Sat, 24 Oct 2009 02:58:21 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-139-93.red.bezeqint.net [79.181.139.93]) by mx.google.com with ESMTPS id y2sm7403418mug.49.2009.10.24.02.58.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Oct 2009 02:58:18 -0700 (PDT) From: "Roni Even" To: "'Slava Borilin'" , "'Henry Sinnreich'" , "'Jean-Marc Valin'" , "'Lars Eggert'" References: In-Reply-To: Date: Sat, 24 Oct 2009 11:54:08 +0200 Message-ID: <4ae2cfba.02e2660a.2f48.39e0@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CA54A0.B513E180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpTHe3dr1LmmxksSEe/qHKFfkdd4AAHFjHwAAQ9E9YAABPfIAAAHdUAAFDjDNA= Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 09:58:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01CA54A0.B513E180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Slava, In SVC the terms for it is media-aware network elements (MANEs) so = adaption can be done by the source, destination or by MANEs. Note that they need = to understand the structure of the payload and relations between the layers = to strip the right ones. Roni Even =20 =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Slava Borilin Sent: Thursday, October 22, 2009 9:23 PM To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 Again - my point is that router does NOT have to know that something specifically is the codec, or specific codec- the only goal is to let = router aware that the stream (and every packet) is LAYERED, and that it is legitimate to strip out some layers if necessary due to congestion. The content of such =93layered=94 can be any =96 voice codec, video = codec, audio codec, any type of content. =20 And I agree with Gregory =96 that having current infrastructure using = layers in separate streams will require too much overhead (packets) which does = not make sense as well =96 and I am thinking about one stream of packets comtaining all the layers, which, however, can be modified on the fly = =93in the middle=94. So we may think about more generic concept of =93declared layered = content=94 which does NOT loose the information (well, most of it) by stripping out portions of the packet and reducing the traffic, so router can strip out = any type of layered content, without going deep into specific codec. =20 Again- this is =93na=EFve=94 suggestions from me (very limited engineer) = =96 and definitely I am looking for objections even more then for agreement =96 = for the sake of either finding the idea useful or making judged deny of it, = and I agree that this concept is only one possible way of working with congestion. =20 best regards, Slava Borilin _____ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Slava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 Henry, With all of my respect (you know) =96 this is too high-level = consideration and too generic statement which doesn=92t answer MPLS issue for example. =20 best regards, Slava Borilin _____ =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, = why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its = only one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec __________ Information from ESET NOD32 Antivirus, version of virus = signature database 4532 (20091022) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ------=_NextPart_000_000B_01CA54A0.B513E180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

Slava,

In SVC the terms for it is media-aware network = elements=A0 (MANEs) so adaption can be done by the source, destination or by MANEs. Note = that they need to understand the structure of the payload and relations between = the layers to strip the right ones.

Roni Even

 

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Slava Borilin
Sent: Thursday, October 22, 2009 9:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars = Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter = proposal

 

Again - my point is that router does NOT have to know that something specifically is the codec, or specific codec- the only goal is = to let router aware that the stream (and every packet) is LAYERED, and that it = is legitimate to strip out some layers if necessary due to = congestion.

The content of such “layered” can be any – = voice codec, video codec, audio codec, any type of content.

 

And I agree with Gregory – that having current = infrastructure using layers in separate streams will require too much overhead (packets) = which does not make sense as well – and I am thinking about one stream of = packets comtaining all the layers, which, however, can be modified on the fly = “in the middle”.

So we may think about more generic concept of = “declared layered content” which does NOT loose the information (well, most of it) = by stripping out portions of the packet and reducing the traffic, so router can strip = out any type of layered content, without going deep into specific = codec.

 

Again- this is “na=EFve” suggestions from me = (very limited engineer) – and definitely I am looking for objections even more then for = agreement – for the sake of either finding the idea useful or making judged deny of it, = and I agree that this concept is only one possible way of working with = congestion.

 

best regards,

Slava Borilin

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Slava Borilin
Sent: Thursday, October 22, 2009 11:13 PM
To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter = proposal

 

Henry,

With all of my respect (you know) – this is too = high-level consideration and too generic statement which doesn’t answer MPLS = issue for example.

 

best regards,

Slava Borilin

From:= Henry = Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October 22, 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter = proposal

 

Slava,

>I am not that sure that routers should not be aware of the codecs. = Why?
>If we are building MPLS and other systems that is content-dependent, = why
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its = only one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> = wrote:

I am not that sure that = routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, = why
not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it = can
be too hard and too long to tell each sender to reduce the rate - = why
not to leave this freedom to router as this may be more efficient = for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router = do
not need to understand anything except that it is LAYERED streams = (even
don't know whether its voice, video or audio or anything else of = layered
nature, and router "has the right" to strip out layers in = certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you = don't
> involve the codec in some form, performance/quality will be bad. = Some
> codecs need time to adjust the rate. Some can only adjust it in = pretty

> coarse steps. Etc. If you let DCCP adjust the rate blindly, = without
> involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just = want to
be
careful not to include in the codec things that don't belong there = (e.g.
a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control = will
never
> attempt to probe for more capacity unless the codec generates = more
data,
> and why would the codec do that if it's converged to transmit at = some
> lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want = to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the = codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! = Routers
> drop or mark IP packets. It is up to the application sending those = IP
> packets to react appropriately to the marks or losses. In other = words,
a
> layered codec will see losses/marks to packets sent on all layers, = and

> will then need to figure out whether to strip off a layer or not = in
> response to whatever congestion level those losses/marks = indicate.

I definitely agree that the routers shouldn't know about codecs and = this
is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the = middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You = don't
need layers to have a multi-rate codec. Layering just means that you = can

strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much = the
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality = will

> suffer IMO.

Well, we need to figure out the aspects that should be = codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* = losses/marks
to
> determine capacity. People have tried to create congestion = control
> schemes that avoid causing losses (delay-based schemed, for = example),
> but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable = -
the
> rate computation is usually clocked by the RTT. You can = obviously
dampen
> this somehow, but you can never say "now I have found a rate = that I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying = that
you
can have one module that determines in real-time the best rate to use = at

that moment and then it tells the codec what to use. If it needs = help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to = the other layers.
On
>> example here (also included in the draft) is VBR, which means = that
the
>> application specifies an average rate and the codec decides how = to
>> vary the
>> rate to achieve that (subject to some rate control = constraints).
Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK = if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec



__________ Information from ESET NOD32 Antivirus, version of virus = signature database 4532 (20091022) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

------=_NextPart_000_000B_01CA54A0.B513E180-- From koen.vos@skype.net Sun Oct 25 06:38:46 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB953A682B for ; Sun, 25 Oct 2009 06:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.345 X-Spam-Level: * X-Spam-Status: No, score=1.345 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FRT_ADOBE2=2.455] 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 SGswvHMBXgmH for ; Sun, 25 Oct 2009 06:38:45 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 9FCF13A677C for ; Sun, 25 Oct 2009 06:38:44 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id AC627605D6380; Sun, 25 Oct 2009 13:38:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=3x388Vg3ySRc SRYUvpZwX7JXfSw=; b=pmH2F5DM1jz8rHypwrpArBhWCAiFeziwwu7OUseDeAOc NwDlCFu2IJDiALMUQYxanAU5kU8+Q8vUIc/iZDQG/pGhRpi528fc0d67sIQJm7qa rSye1luA31iY12fHrSX85WhJbEa5ADjjeDTcHFh1eSN2BJKJJGuuuCZ6zredsf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=iZ93KJVigPW7vly0eJZn O6SWUVFnR+GqF3YaaezTFpQcjQaQE9GspXmVEljIqzpE99C2HdRFzGAszSu9pdCZ yNROs0/pkAw0G6oWNXh4UbxEIr/T1Y/zh4SnPY4Jd0dOBPFsy82oCYtzbbHmbWMW 7hIGNMGqbnMt+nTc21Yxl+A= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id AA37A605D44C2; Sun, 25 Oct 2009 13:38:56 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgGCVhUGKneB; Sun, 25 Oct 2009 13:38:46 +0000 (GMT) Received: by mail.skype.net (Postfix, from userid 33) id EFE1E605D63BA; Sun, 25 Oct 2009 13:38:46 +0000 (GMT) Received: from 84-55-127-131.customers.ownit.se (84-55-127-131.customers.ownit.se [84.55.127.131]) by mail.skype.net (Horde Framework) with HTTP; Sun, 25 Oct 2009 06:38:46 -0700 Message-ID: <20091025063846.320772u2gsti73s6@mail.skype.net> Date: Sun, 25 Oct 2009 06:38:46 -0700 From: Koen Vos To: Slava Borilin References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 13:38:46 -0000 At a given quality level, the bitrate for encoding speech/audio with =20 layers is typically 10~50% higher than without layers. So layered =20 coding may in fact cause congestion, and reducing the bitrate at the =20 encoder is probably better. koen. Quoting Slava Borilin: > Again - my point is that router does NOT have to know that something =20 > specifically is the codec, or specific codec- the only goal is to =20 > let router aware that the stream (and every packet) is LAYERED, and =20 > that it is legitimate to strip out some layers if necessary due to =20 > congestion. > > The content of such "layered" can be any - voice codec, video codec, =20 > audio codec, any type of content. > > > > And I agree with Gregory - that having current infrastructure using =20 > layers in separate streams will require too much overhead (packets) =20 > which does not make sense as well - and I am thinking about one =20 > stream of packets comtaining all the layers, which, however, can be =20 > modified on the fly "in the middle". > > So we may think about more generic concept of "declared layered =20 > content" which does NOT loose the information (well, most of it) by =20 > stripping out portions of the packet and reducing the traffic, so =20 > router can strip out any type of layered content, without going deep =20 > into specific codec. > > > > Again- this is "na=EFve" suggestions from me (very limited engineer) - =20 > and definitely I am looking for objections even more then for =20 > agreement - for the sake of either finding the idea useful or making =20 > judged deny of it, and I agree that this concept is only one =20 > possible way of working with congestion. > > > > best regards, > > Slava Borilin > > ________________________________ > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Slava Borilin > Sent: Thursday, October 22, 2009 11:13 PM > To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > > > Henry, > > With all of my respect (you know) - this is too high-level =20 > consideration and too generic statement which doesn't answer MPLS =20 > issue for example. > > > > best regards, > > Slava Borilin > > ________________________________ > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, October 22, 2009 11:10 PM > To: Slava Borilin; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > > > Slava, > >> I am not that sure that routers should not be aware of the codecs. Why? >> If we are building MPLS and other systems that is content-dependent, why >> not let router understand the codec? > > The essence of the Dumb Network (Internet) and its routers is that =20 > it knows nothing about the applications. > All applications that nobody planned for can run over it. > The tragedy of the telephone network was is knew everything about =20 > its only one application. > > Henry > > > On 10/22/09 1:23 PM, "Slava Borilin" wrote: > > I am not that sure that routers should not be aware of the codecs. Why? > If we are building MPLS and other systems that is content-dependent, why > not let router understand the codec? > > Especially if we have hordes of voice channels going thru router, it can > be too hard and too long to tell each sender to reduce the rate - why > not to leave this freedom to router as this may be more efficient for > congestion recovery? > > Same applies to H.264SVC for example - at the end of the day, router do > not need to understand anything except that it is LAYERED streams (even > don't know whether its voice, video or audio or anything else of layered > nature, and router "has the right" to strip out layers in certain order > to prevent congestion? > > best regards, > Slava Borilin > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Thursday, October 22, 2009 5:45 PM > To: Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > Lars Eggert wrote: >> Also, what we've learned from media over DCCP is that if you don't >> involve the codec in some form, performance/quality will be bad. Some >> codecs need time to adjust the rate. Some can only adjust it in pretty > >> coarse steps. Etc. If you let DCCP adjust the rate blindly, without >> involving the codec in some form, you might get very good TCP >> friendliness, but maybe quality will suffer. > > I'm totally in favour of "involving the codec" in here. I just want to > be > careful not to include in the codec things that don't belong there (e.g. > a > DCCP implementation or a whole jitter buffer). > >> (And there is always the ramping up part - congestion control will > never >> attempt to probe for more capacity unless the codec generates more > data, >> and why would the codec do that if it's converged to transmit at some >> lower rate.) > > Well, the codec transmits at the rate you ask it to use. If you want to > probe for more capacity, then you tell the codec that it can use a > higher > rate. Now, if there's a special way in which you want to ask the codec, > then maybe that can become an additional feature for the codec. > >> By no means should routers have to understand codec formats! Routers >> drop or mark IP packets. It is up to the application sending those IP >> packets to react appropriately to the marks or losses. In other words, > a >> layered codec will see losses/marks to packets sent on all layers, and > >> will then need to figure out whether to strip off a layer or not in >> response to whatever congestion level those losses/marks indicate. > > I definitely agree that the routers shouldn't know about codecs and this > is > why I was saying that IMO layered codecs aren't too useful for > congestion > control (though they have other uses). If there's nothing in the middle > of > the network to strip off the layers, then you might as well not have > layers > at all. All you need is to ask the sender to reduce the rate. You don't > need layers to have a multi-rate codec. Layering just means that you can > > strip off bits and still have the result sound OK. > >>> OK, I may be wrong here, but my understanding is that how much the > rate >>> should change depending on congestion is actually not that >>> codec-specific. >> >> It *can* be non-codec-specific, see DCCP for example. But quality will > >> suffer IMO. > > Well, we need to figure out the aspects that should be codec-specific > and > implement just those. Does anyone have a list of the issues codecs > should > be aware of? > >> Most Internet congestion control is based on *creating* losses/marks > to >> determine capacity. People have tried to create congestion control >> schemes that avoid causing losses (delay-based schemed, for example), >> but they are perceived to be more fragile. > > Yes, I can imagine the problem not being trivial at all. > >>> Once you figure this out, you >>> can just tell the codec to use that rate. >> >> It's not that easy, because rates in the Internet are never stable - > the >> rate computation is usually clocked by the RTT. You can obviously > dampen >> this somehow, but you can never say "now I have found a rate that I > can >> safely use forever." > > Oh, I never said we should set a rate forever. I was just saying that > you > can have one module that determines in real-time the best rate to use at > > that moment and then it tells the codec what to use. If it needs help > from > the codec, then we can define special functionality. > >>> On top of that, the codec may be >>> able to do a bit better by providing a "service" to the other layers. > On >>> example here (also included in the draft) is VBR, which means that > the >>> application specifies an average rate and the codec decides how to >>> vary the >>> rate to achieve that (subject to some rate control constraints). > Would >>> other such mechanisms be useful to deal with congestion? >> >> I'm not sure this would work, because congestion control will > basically >> change the VBR input parameter continuously. > > Changing the VBR parameters continuously is not a problem. VBR just > means > that you'd like to have an average of N kb/s for now, but you're OK if > there are variations from frame to frame. > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From jovass@adobe.com Mon Oct 26 10:55:58 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D263A6994 for ; Mon, 26 Oct 2009 10:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKtF50UTnH0F for ; Mon, 26 Oct 2009 10:55:46 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by core3.amsl.com (Postfix) with ESMTP id 8110528C123 for ; Mon, 26 Oct 2009 10:55:42 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKSuXiqCrVGXRHOtFdlZXkNpLuDGE+A/Z8@postini.com; Mon, 26 Oct 2009 10:56:00 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9QHmfao020789; Mon, 26 Oct 2009 10:48:41 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9QHtnlT018104; Mon, 26 Oct 2009 10:55:49 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 10:55:48 -0700 Received: from nambx03.corp.adobe.com ([10.8.189.93]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Mon, 26 Oct 2009 10:55:48 -0700 From: Jozsef Vass To: Slava Borilin , Henry Sinnreich , Jean-Marc Valin , Lars Eggert Date: Mon, 26 Oct 2009 10:55:47 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdA Message-ID: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0FEA137C08A9DF4781EEF745038C9694146B2D6CD8nambx03corpad_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:55:58 -0000 --_000_0FEA137C08A9DF4781EEF745038C9694146B2D6CD8nambx03corpad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I do not like the idea of sending multiple layers in a packet either. I fee= l very uncomfortable of routers modifying packets. It is OK not to deliver,= but delivering semantically modified packet is not expected. Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets. Jozsef ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Thursday, October 22, 2009 12:23 PM To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Again - my point is that router does NOT have to know that something specif= ically is the codec, or specific codec- the only goal is to let router awar= e that the stream (and every packet) is LAYERED, and that it is legitimate = to strip out some layers if necessary due to congestion. The content of such "layered" can be any - voice codec, video codec, audio = codec, any type of content. And I agree with Gregory - that having current infrastructure using layers = in separate streams will require too much overhead (packets) which does not= make sense as well - and I am thinking about one stream of packets comtain= ing all the layers, which, however, can be modified on the fly "in the midd= le". So we may think about more generic concept of "declared layered content" wh= ich does NOT loose the information (well, most of it) by stripping out port= ions of the packet and reducing the traffic, so router can strip out any ty= pe of layered content, without going deep into specific codec. Again- this is "na=EFve" suggestions from me (very limited engineer) - and = definitely I am looking for objections even more then for agreement - for t= he sake of either finding the idea useful or making judged deny of it, and = I agree that this concept is only one possible way of working with congesti= on. best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of S= lava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Henry, With all of my respect (you know) - this is too high-level consideration an= d too generic statement which doesn't answer MPLS issue for example. best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it knows= nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its only = one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_0FEA137C08A9DF4781EEF745038C9694146B2D6CD8nambx03corpad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

I do not like the idea of sending mult= iple layers in a packet either. I feel very uncomfortable of routers modifying packets. It is OK not to deliver, but delivering semantically modified pack= et is not expected.

 

Using layers for video totally makes s= ense where the rates are much higher and layers can be transported in separate packets.

 

Jozsef

 

From: Slava Bo= rilin [mailto:Borilin@spiritdsp.com]
Sent: Thursday, October 22, = 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

 

Again - my point is that router does N= OT have to know that something specifically is the codec, or specific codec- t= he only goal is to let router aware that the stream (and every packet) is LAYE= RED, and that it is legitimate to strip out some layers if necessary due to congestion.

The content of such “layeredR= 21; can be any – voice codec, video codec, audio codec, any type of content.

 

And I agree with Gregory – that = having current infrastructure using layers in separate streams will require too mu= ch overhead (packets) which does not make sense as well – and I am think= ing about one stream of packets comtaining all the layers, which, however, can be modified on the fly “in the middle”.

So we may think about more generic con= cept of “declared layered content” which does NOT loose the informat= ion (well, most of it) by stripping out portions of the packet and reducing the traffic, so router can strip out any type of layered content, without going deep into specific codec.

 

Again- this is “na=EFve” s= uggestions from me (very limited engineer) – and definitely I am looking for objections = even more then for agreement – for the sake of either finding the idea useful o= r making judged deny of it, and I agree that this concept is only one possible way o= f working with congestion.

 

best regards,

Slava Borilin=

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Slava Borilin
Sent: Thursday, October 22, = 2009 11:13 PM
To: Henry Sinnreich; Jean-Ma= rc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

 

Henry,

With all of my respect (you know) R= 11; this is too high-level consideration and too generic statement which doesn’= ;t answer MPLS issue for example.

 

best regards,

Slava Borilin=

From: Henry Si= nnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October 22, = 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

 

Slava,

>I am not that sure that routers should not be aware of the codecs. Why?=
>If we are building MPLS and other systems that is content-dependent, wh= y
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its only = one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:<= /font>

I am not that sure= that routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] O= n Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you don't
> involve the codec in some form, performance/quality will be bad. Some<= br> > codecs need time to adjust the rate. Some can only adjust it in pretty=

> coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just wa= nt to
be
careful not to include in the codec things that don't belong there (e.g. a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never
> attempt to probe for more capacity unless the codec generates more
data,
> and why would the codec do that if it's converged to transmit at some<= br> > lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP<= br> > packets to react appropriately to the marks or losses. In other words,=
a
> layered codec will see losses/marks to packets sent on all layers, and=

> will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You don't
need layers to have a multi-rate codec. Layering just means that you can
strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much the=
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality will=

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* losses/marks to
> determine capacity. People have tried to create congestion control
> schemes that avoid causing losses (delay-based schemed, for example),<= br> > but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable - the
> rate computation is usually clocked by the RTT. You can obviously
dampen
> this somehow, but you can never say "now I have found a rate that= I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that
you
can have one module that determines in real-time the best rate to use at
that moment and then it tells the codec what to use. If it needs help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to the other layers.
On
>> example here (also included in the draft) is VBR, which means that=
the
>> application specifies an average rate and the codec decides how to=
>> vary the
>> rate to achieve that (subject to some rate control constraints). Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_0FEA137C08A9DF4781EEF745038C9694146B2D6CD8nambx03corpad_-- From stewe@stewe.org Mon Oct 26 11:15:12 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB4028C13D for ; Mon, 26 Oct 2009 11:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id subUEZmKbsdv for ; Mon, 26 Oct 2009 11:15:00 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id E7E6228C0F5 for ; Mon, 26 Oct 2009 11:14:56 -0700 (PDT) Received: from [192.168.1.111] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 470787-1743317 for multiple; Mon, 26 Oct 2009 19:15:09 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 11:15:00 -0700 From: Stephan Wenger To: Jozsef Vass , Slava Borilin , Henry Sinnreich , Jean-Marc Valin , Lars Eggert Message-ID: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdAAADCvbs= In-Reply-To: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339400508_2129852" X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:15:12 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339400508_2129852 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I think that we have a terminology problem here. Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is they don=B9t modify IP packets. Boxes that look deep into the IP packets, an= d (potentially) modify them, are higher layer devices. After long discussion= s in AVT at the time, RFC 3984 and its successors call those boxes =B3Media Aware Network Elements=B2, MANEs. MANEs modify packets at the application layer, for example to remove layers, re-package H.264 NAL units to adapt to different MTU sizes, and do all kinds of other things that violate the end-to-end principle. A MANE has business in looking into, and potentially modifying, IP/UDP/RTP packets, a router has not. When MANEs are in the picture, it=B9s IMO totally acceptable (from both an abstract layering theory viewpoint and in practice) that packets are being opened and the content is repackaged. It=B9s actually common practice. Stephan On 10/26/09 10:55 AM, "Jozsef Vass" wrote: > I do not like the idea of sending multiple layers in a packet either. I f= eel > very uncomfortable of routers modifying packets. It is OK not to deliver,= but > delivering semantically modified packet is not expected. > =20 > Using layers for video totally makes sense where the rates are much highe= r and > layers can be transported in separate packets. > =20 > Jozsef > =20 >=20 >=20 > From: Slava Borilin [mailto:Borilin@spiritdsp.com] > Sent: Thursday, October 22, 2009 12:23 PM > To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > =20 > Again - my point is that router does NOT have to know that something > specifically is the codec, or specific codec- the only goal is to let rou= ter > aware that the stream (and every packet) is LAYERED, and that it is legit= imate > to strip out some layers if necessary due to congestion. > The content of such =B3layered=B2 can be any =AD voice codec, video codec, audi= o > codec, any type of content. > =20 > And I agree with Gregory =AD that having current infrastructure using layer= s in > separate streams will require too much overhead (packets) which does not = make > sense as well =AD and I am thinking about one stream of packets comtaining = all > the layers, which, however, can be modified on the fly =B3in the middle=B2. > So we may think about more generic concept of =B3declared layered content=B2 = which > does NOT loose the information (well, most of it) by stripping out portio= ns of > the packet and reducing the traffic, so router can strip out any type of > layered content, without going deep into specific codec. > =20 > Again- this is =B3na=EFve=B2 suggestions from me (very limited engineer) =AD and > definitely I am looking for objections even more then for agreement =AD for= the > sake of either finding the idea useful or making judged deny of it, and I > agree that this concept is only one possible way of working with congesti= on. > =20 >=20 > best regards, > Slava Borilin >=20 >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Slava Borilin > Sent: Thursday, October 22, 2009 11:13 PM > To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > =20 > Henry, > With all of my respect (you know) =AD this is too high-level consideration = and > too generic statement which doesn=B9t answer MPLS issue for example. > =20 >=20 > best regards, > Slava Borilin >=20 >=20 > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, October 22, 2009 11:10 PM > To: Slava Borilin; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > =20 > Slava, >=20 >> >I am not that sure that routers should not be aware of the codecs. Why? >> >If we are building MPLS and other systems that is content-dependent, wh= y >> >not let router understand the codec? >=20 > The essence of the Dumb Network (Internet) and its routers is that it kno= ws > nothing about the applications. > All applications that nobody planned for can run over it. > The tragedy of the telephone network was is knew everything about its onl= y one > application. >=20 > Henry >=20 >=20 > On 10/22/09 1:23 PM, "Slava Borilin" wrote: > I am not that sure that routers should not be aware of the codecs. Why? > If we are building MPLS and other systems that is content-dependent, why > not let router understand the codec? >=20 > Especially if we have hordes of voice channels going thru router, it can > be too hard and too long to tell each sender to reduce the rate - why > not to leave this freedom to router as this may be more efficient for > congestion recovery? >=20 > Same applies to H.264SVC for example - at the end of the day, router do > not need to understand anything except that it is LAYERED streams (even > don't know whether its voice, video or audio or anything else of layered > nature, and router "has the right" to strip out layers in certain order > to prevent congestion? >=20 > best regards, > Slava Borilin >=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Thursday, October 22, 2009 5:45 PM > To: Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal >=20 > Lars Eggert wrote: >> > Also, what we've learned from media over DCCP is that if you don't >> > involve the codec in some form, performance/quality will be bad. Some >> > codecs need time to adjust the rate. Some can only adjust it in pretty >=20 >> > coarse steps. Etc. If you let DCCP adjust the rate blindly, without >> > involving the codec in some form, you might get very good TCP >> > friendliness, but maybe quality will suffer. >=20 > I'm totally in favour of "involving the codec" in here. I just want to > be > careful not to include in the codec things that don't belong there (e.g. > a > DCCP implementation or a whole jitter buffer). >=20 >> > (And there is always the ramping up part - congestion control will > never >> > attempt to probe for more capacity unless the codec generates more > data, >> > and why would the codec do that if it's converged to transmit at some >> > lower rate.) >=20 > Well, the codec transmits at the rate you ask it to use. If you want to > probe for more capacity, then you tell the codec that it can use a > higher > rate. Now, if there's a special way in which you want to ask the codec, > then maybe that can become an additional feature for the codec. >=20 >> > By no means should routers have to understand codec formats! Routers >> > drop or mark IP packets. It is up to the application sending those IP >> > packets to react appropriately to the marks or losses. In other words, > a >> > layered codec will see losses/marks to packets sent on all layers, and >=20 >> > will then need to figure out whether to strip off a layer or not in >> > response to whatever congestion level those losses/marks indicate. >=20 > I definitely agree that the routers shouldn't know about codecs and this > is > why I was saying that IMO layered codecs aren't too useful for > congestion > control (though they have other uses). If there's nothing in the middle > of > the network to strip off the layers, then you might as well not have > layers > at all. All you need is to ask the sender to reduce the rate. You don't > need layers to have a multi-rate codec. Layering just means that you can >=20 > strip off bits and still have the result sound OK. >=20 >>> >> OK, I may be wrong here, but my understanding is that how much the > rate >>> >> should change depending on congestion is actually not that >>> >> codec-specific. >> > >> > It *can* be non-codec-specific, see DCCP for example. But quality will >=20 >> > suffer IMO. >=20 > Well, we need to figure out the aspects that should be codec-specific > and > implement just those. Does anyone have a list of the issues codecs > should > be aware of? >=20 >> > Most Internet congestion control is based on *creating* losses/marks > to >> > determine capacity. People have tried to create congestion control >> > schemes that avoid causing losses (delay-based schemed, for example), >> > but they are perceived to be more fragile. >=20 > Yes, I can imagine the problem not being trivial at all. >=20 >>> >> Once you figure this out, you >>> >> can just tell the codec to use that rate. >> > >> > It's not that easy, because rates in the Internet are never stable - > the >> > rate computation is usually clocked by the RTT. You can obviously > dampen >> > this somehow, but you can never say "now I have found a rate that I > can >> > safely use forever." >=20 > Oh, I never said we should set a rate forever. I was just saying that > you > can have one module that determines in real-time the best rate to use at >=20 > that moment and then it tells the codec what to use. If it needs help > from > the codec, then we can define special functionality. >=20 >>> >> On top of that, the codec may be >>> >> able to do a bit better by providing a "service" to the other layers= . > On >>> >> example here (also included in the draft) is VBR, which means that > the >>> >> application specifies an average rate and the codec decides how to >>> >> vary the >>> >> rate to achieve that (subject to some rate control constraints). > Would >>> >> other such mechanisms be useful to deal with congestion? >> > >> > I'm not sure this would work, because congestion control will > basically >> > change the VBR input parameter continuously. >=20 > Changing the VBR parameters continuously is not a problem. VBR just > means > that you'd like to have an average of N kb/s for now, but you're OK if > there are variations from frame to frame. >=20 > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3339400508_2129852 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] updated charter proposal I think that we have a terminology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is th= ey don’t modify IP packets.  Boxes that look deep into the IP pac= kets, and (potentially) modify them, are higher layer devices.  After l= ong discussions in AVT at the time, RFC 3984 and its successors call those b= oxes “Media Aware Network Elements”, MANEs.  MANEs modify p= ackets at the application layer, for example to remove layers, re-package H.= 264 NAL units to adapt to different MTU sizes, and do all kinds of other thi= ngs that violate the end-to-end principle.  A MANE has business in look= ing into, and potentially modifying, IP/UDP/RTP packets, a router has not.
When MANEs are in the picture, it’s IMO totally acceptable (from both= an abstract layering theory viewpoint and in practice) that packets are bei= ng opened and the content is repackaged.  It’s actually common pr= actice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <jovass@adobe.com> wrote:

I do not like the idea of sending multip= le layers in a packet either. I feel very uncomfortable of routers modifying= packets. It is OK not to deliver, but delivering semantically modified pack= et is not expected.
 
Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets.
 
Jozsef
 

From: Slava Borilin [mailto:Borilin@spiritdsp.com]
Sent: Thursday, October 22, 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal
Again - my point is that router does NOT have to kno= w that something specifically is the codec, or specific codec- the only goal= is to let router aware that the stream (and every packet) is LAYERED, and t= hat it is legitimate to strip out some layers if necessary due to congestion= .
The content of such “layered” can be any – voice codec, v= ideo codec, audio codec, any type of content.
 
And I agree with Gregory – that having current infrastructure using l= ayers in separate streams will require too much overhead (packets) which doe= s not make sense as well – and I am thinking about one stream of packe= ts comtaining all the layers, which, however, can be modified on the fly = 220;in the middle”.
So we may think about more generic concept of “declared layered conte= nt” which does NOT loose the information (well, most of it) by strippi= ng out portions of the packet and reducing the traffic, so router can strip = out any type of layered content, without going deep into specific codec.
 
Again- this is “naïve” suggestions from me (very limited e= ngineer) – and definitely I am looking for objections even more then f= or agreement – for the sake of either finding the idea useful or makin= g judged deny of it, and I agree that this concept is only one possible way = of working with congestion.
 

best regards,
Slava Borilin

From: codec-bounces@= ietf.org [mailto:codec-bounces@i= etf.org] On Behalf Of Slava Borilin
Sent: Thursday, October 22, 2009 11:13 PM
To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal
Henry,
With all of my respect (you know) – this is too high-level considerat= ion and too generic statement which doesn’t answer MPLS issue for exam= ple.
 

best regards,
Slava Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October 22, 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal
Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain= order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf=
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you don't
> involve the codec in some form, performance/quality will be bad. Some<= BR> > codecs need time to adjust the rate. Some can only adjust it in pretty=

> coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just wa= nt to
be
careful not to include in the codec things that don't belong there (e.g. a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never
> attempt to probe for more capacity unless the codec generates more
data,
> and why would the codec do that if it's converged to transmit at some<= BR> > lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP<= BR> > packets to react appropriately to the marks or losses. In other words,=
a
> layered codec will see losses/marks to packets sent on all layers, and=

> will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You don't
need layers to have a multi-rate codec. Layering just means that you can
strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much the=
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality will=

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* losses/marks to
> determine capacity. People have tried to create congestion control
> schemes that avoid causing losses (delay-based schemed, for example),<= BR> > but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable - the
> rate computation is usually clocked by the RTT. You can obviously
dampen
> this somehow, but you can never say "now I have found a rate that= I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that
you
can have one module that determines in real-time the best rate to use at
that moment and then it tells the codec what to use. If it needs help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to the = other layers.
On
>> example here (also included in the draft) is VBR, which means that=
the
>> application specifies an average rate and the codec decides how to=
>> vary the
>> rate to achieve that (subject to some rate control constraints). Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec

___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3339400508_2129852-- From mknappe@juniper.net Mon Oct 26 13:46:38 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0285B28C368 for ; Mon, 26 Oct 2009 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogIYIDpQHbl1 for ; Mon, 26 Oct 2009 13:46:37 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id EBFAE28C354 for ; Mon, 26 Oct 2009 13:46:36 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSuYKtpLXsCxbhvEKJypPEF2plA47r3fZ@postini.com; Mon, 26 Oct 2009 13:46:51 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 26 Oct 2009 13:46:46 -0700 From: Michael Knappe To: "bens@alum.mit.edu" , Slava Borilin Date: Mon, 26 Oct 2009 13:47:12 -0700 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpT5N/tS2brQjYASqibRoJifZxwKACmJ4tU Message-ID: In-Reply-To: <4AE1AFBB.2030206@fas.harvard.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:46:38 -0000 Benjamin, Well worded paragraph, thanks. I would add just some minor edits and a scop= ing sentence at the end. My proposed changes are in italics. Cheers, Mike Audio Corruption Robustness The systems providing input to the encoder and s//receiving/ output from th= e decoder s/are likely to/may/ be far from ideal in actual use. Input and output audio str= eams may be corrupted by s//compounding non-linear/ artifacts from analog hardwa= re and digital processing. The codecs to be developed should be tested to e= nsure that they degrade gracefully under adverse audio conditions. Types of digital corruption that may be tested include tandem encoding with similar and different codecs, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. s//No specif= ic end-to-end quality requirements are mandated for use with the proposed c= odec. It is advisable, however, that several typical in-situ environments/p= rocessing chains be specified for the purpose of benchmarking end-to-end qu= ality with the proposed codec./ """ " On 10/23/09 6:29 AM, "Benjamin M. Schwartz" wrot= e: Slava Borilin wrote: > Henry, e2e (or p2p) is cool but what about Legal interception for > example in this case, which every cellco has to implemenet? Whether or not we want to encourage it, interception of VoIP traffic does not require a re-encode. The encoded packets can just be copied to the additional receiver. To address the "tandeming" issue, I think the following text should be added to the "Basic Requirements" or "Additional Considerations": """ Audio Corruption Robustness The systems providing input to the encoder and output from the decoder are likely to be far from ideal in actual use. Input and output audio streams may be corrupted by artifacts from analog hardware and digital processing. The codecs to be developed should be tested to ensure that they degrade gracefully under adverse audio conditions. Types of digital corruption that may be tested include tandem encoding with similar and different codecs, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. """ From Borilin@spiritdsp.com Mon Oct 26 13:59:19 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA3428C253 for ; Mon, 26 Oct 2009 13:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.792 X-Spam-Level: X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 uD0QxNZHPgdk for ; Mon, 26 Oct 2009 13:59:06 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 9DEC528C34E for ; Mon, 26 Oct 2009 13:59:05 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9QKx7GR055823; Mon, 26 Oct 2009 23:59:07 +0300 (MSK) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA567F.24DBBAC9" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 26 Oct 2009 23:58:58 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdAAADCvbsABbS9UA== References: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> From: "Slava Borilin" To: "Stephan Wenger" , "Jozsef Vass" , "Henry Sinnreich" , "Jean-Marc Valin" , "Lars Eggert" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:59:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA567F.24DBBAC9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, if we change "routers" to MANEs, the whole story of layering start = to make more sense? =20 best regards, Slava Borilin ________________________________ From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: Monday, October 26, 2009 9:15 PM To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars = Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 I think that we have a terminology problem here. Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is = they don't modify IP packets. Boxes that look deep into the IP packets, = and (potentially) modify them, are higher layer devices. After long = discussions in AVT at the time, RFC 3984 and its successors call those = boxes "Media Aware Network Elements", MANEs. MANEs modify packets at = the application layer, for example to remove layers, re-package H.264 = NAL units to adapt to different MTU sizes, and do all kinds of other = things that violate the end-to-end principle. A MANE has business in = looking into, and potentially modifying, IP/UDP/RTP packets, a router = has not. When MANEs are in the picture, it's IMO totally acceptable (from both an = abstract layering theory viewpoint and in practice) that packets are = being opened and the content is repackaged. It's actually common = practice. Stephan On 10/26/09 10:55 AM, "Jozsef Vass" wrote: I do not like the idea of sending multiple layers in a packet either. I = feel very uncomfortable of routers modifying packets. It is OK not to = deliver, but delivering semantically modified packet is not expected. =20 Using layers for video totally makes sense where the rates are much = higher and layers can be transported in separate packets. =20 Jozsef =20 ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com]=20 Sent: Thursday, October 22, 2009 12:23 PM To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Again - my point is that router does NOT have to know that something = specifically is the codec, or specific codec- the only goal is to let = router aware that the stream (and every packet) is LAYERED, and that it = is legitimate to strip out some layers if necessary due to congestion. The content of such "layered" can be any - voice codec, video codec, = audio codec, any type of content. =20 And I agree with Gregory - that having current infrastructure using = layers in separate streams will require too much overhead (packets) = which does not make sense as well - and I am thinking about one stream = of packets comtaining all the layers, which, however, can be modified on = the fly "in the middle". So we may think about more generic concept of "declared layered content" = which does NOT loose the information (well, most of it) by stripping out = portions of the packet and reducing the traffic, so router can strip out = any type of layered content, without going deep into specific codec. =20 Again- this is "na=EFve" suggestions from me (very limited engineer) - = and definitely I am looking for objections even more then for agreement = - for the sake of either finding the idea useful or making judged deny = of it, and I agree that this concept is only one possible way of working = with congestion. =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Slava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Henry, With all of my respect (you know) - this is too high-level consideration = and too generic statement which doesn't answer MPLS issue for example. =20 best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, = why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its = only one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA567F.24DBBAC9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

Well, if we = change “routers” to MANEs, the whole story of layering start to make more = sense?

 =

best = regards,

Slava = Borilin

From: Stephan Wenger [mailto:stewe@stewe.org]
Sent: Monday, October 26, = 2009 9:15 PM
To: Jozsef Vass; Slava = Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

 

I think that we have a = terminology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is = they don’t modify IP packets.  Boxes that look deep into the IP = packets, and (potentially) modify them, are higher layer devices.  After = long discussions in AVT at the time, RFC 3984 and its successors call those = boxes “Media Aware Network Elements”, MANEs.  MANEs modify = packets at the application layer, for example to remove layers, re-package H.264 = NAL units to adapt to different MTU sizes, and do all kinds of other things = that violate the end-to-end principle.  A MANE has business in looking = into, and potentially modifying, IP/UDP/RTP packets, a router has not.

When MANEs are in the picture, it’s IMO totally acceptable (from = both an abstract layering theory viewpoint and in practice) that packets are = being opened and the content is repackaged.  It’s actually common practice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <jovass@adobe.com> wrote:

I do not like the idea of sending = multiple layers in a packet either. I feel very uncomfortable of routers = modifying packets. It is OK not to deliver, but delivering semantically modified = packet is not expected.
 
Using layers for video totally makes sense where the rates are much = higher and layers can be transported in separate packets.
 
Jozsef
 

From: Slava Borilin [mailto:Borilin@spiritdsp.com] =
Sent: Thursday, October = 22, 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Again - my point is that router does NOT have to know = that something specifically is the codec, or specific codec- the only goal is = to let router aware that the stream (and every packet) is LAYERED, and that it = is legitimate to strip out some layers if necessary due to congestion.
The content of such “layered” can be any – voice = codec, video codec, audio codec, any type of content.
 
And I agree with Gregory – that having current infrastructure = using layers in separate streams will require too much overhead (packets) = which does not make sense as well – and I am thinking about one stream of = packets comtaining all the layers, which, however, can be modified on the fly = “in the middle”.
So we may think about more generic concept of “declared layered content” which does NOT loose the information (well, most of it) = by stripping out portions of the packet and reducing the traffic, so router = can strip out any type of layered content, without going deep into specific = codec.
 
Again- this is “na=EFve” suggestions from me (very limited = engineer) – and definitely I am looking for objections even more then for = agreement – for the sake of either finding the idea useful or making judged = deny of it, and I agree that this concept is only one possible way of working = with congestion.
 

best regards,
Slava Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of Slava Borilin
Sent: Thursday, October = 22, 2009 11:13 PM
To: Henry Sinnreich; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Henry,
With all of my respect (you know) – this is too high-level = consideration and too generic statement which doesn’t answer MPLS issue for = example.
 

best regards,
Slava Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October = 22, 2009 11:10 PM
To: Slava Borilin; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Slava,

>I am not that sure that routers should not be aware of the codecs. = Why?
>If we are building MPLS and other systems that is content-dependent, = why
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its = only one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. = Why?
If we are building MPLS and other systems that is content-dependent, = why
not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it = can
be too hard and too long to tell each sender to reduce the rate - = why
not to leave this freedom to router as this may be more efficient = for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router = do
not need to understand anything except that it is LAYERED streams = (even
don't know whether its voice, video or audio or anything else of = layered
nature, and router "has the right" to strip out layers in = certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you = don't
> involve the codec in some form, performance/quality will be bad. = Some
> codecs need time to adjust the rate. Some can only adjust it in = pretty

> coarse steps. Etc. If you let DCCP adjust the rate blindly, = without
> involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just = want to
be
careful not to include in the codec things that don't belong there = (e.g.
a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control = will
never
> attempt to probe for more capacity unless the codec generates = more
data,
> and why would the codec do that if it's converged to transmit at = some
> lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want = to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the = codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! = Routers
> drop or mark IP packets. It is up to the application sending those = IP
> packets to react appropriately to the marks or losses. In other = words,
a
> layered codec will see losses/marks to packets sent on all layers, = and

> will then need to figure out whether to strip off a layer or not = in
> response to whatever congestion level those losses/marks = indicate.

I definitely agree that the routers shouldn't know about codecs and = this
is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the = middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You = don't
need layers to have a multi-rate codec. Layering just means that you = can

strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much = the
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality = will

> suffer IMO.

Well, we need to figure out the aspects that should be = codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* = losses/marks
to
> determine capacity. People have tried to create congestion = control
> schemes that avoid causing losses (delay-based schemed, for = example),
> but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable = -
the
> rate computation is usually clocked by the RTT. You can = obviously
dampen
> this somehow, but you can never say "now I have found a rate = that I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying = that
you
can have one module that determines in real-time the best rate to use = at

that moment and then it tells the codec what to use. If it needs = help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to = the other layers.
On
>> example here (also included in the draft) is VBR, which means = that
the
>> application specifies an average rate and the codec decides how = to
>> vary the
>> rate to achieve that (subject to some rate control = constraints).
Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK = if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec<= /p>

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

------_=_NextPart_001_01CA567F.24DBBAC9-- From mknappe@juniper.net Mon Oct 26 14:00:18 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F34228C12D for ; Mon, 26 Oct 2009 14:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PbBQjmQiKkA for ; Mon, 26 Oct 2009 14:00:17 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 1DD123A6840 for ; Mon, 26 Oct 2009 14:00:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSuYN63QCq8Mh863KZd7hM9HJqx/TQXd2@postini.com; Mon, 26 Oct 2009 14:00:31 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 26 Oct 2009 13:57:56 -0700 From: Michael Knappe To: Michael Knappe , "bens@alum.mit.edu" , Slava Borilin Date: Mon, 26 Oct 2009 13:58:22 -0700 Thread-Topic: [codec] codec tandeming/codec-requirements Thread-Index: AcpT5N/tS2brQjYASqibRoJifZxwKACmJ4tUAABj1kY= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] codec tandeming/codec-requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:00:18 -0000 For ease of reading, incorporating the edits it would read as: The systems providing input to the encoder and receiving output from the de= coder may be far from ideal in actual use. Input and output audio streams = may be corrupted by compounding non-linear artifacts from analog hardware a= nd digital processing. The codecs to be developed should be tested to ensur= e that they degrade gracefully under adverse audio conditions. Types of di= gital corruption that may be tested include tandem encoding with similar an= d different codecs, low-quality resampling, and digital clipping. Types of= analog corruption that may be tested include microphones with substantial = background noise, analog clipping, and loudspeaker distortion. No specific = end-to-end quality requirements are mandated for use with the proposed code= c. It is advisable, however, that several typical in-situ environments/proc= essing chains be specified for the purpose of benchmarking end-to-end quali= ty with the proposed codec. On 10/26/09 1:47 PM, "Michael Knappe" wrote: Benjamin, Well worded paragraph, thanks. I would add just some minor edits and a scop= ing sentence at the end. My proposed changes are in italics. Cheers, Mike Audio Corruption Robustness The systems providing input to the encoder and s//receiving/ output from th= e decoder s/are likely to/may/ be far from ideal in actual use. Input and output audio str= eams may be corrupted by s//compounding non-linear/ artifacts from analog hardwa= re and digital processing. The codecs to be developed should be tested to e= nsure that they degrade gracefully under adverse audio conditions. Types of digital corruption that may be tested include tandem encoding with similar and different codecs, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. s//No specif= ic end-to-end quality requirements are mandated for use with the proposed c= odec. It is advisable, however, that several typical in-situ environments/p= rocessing chains be specified for the purpose of benchmarking end-to-end qu= ality with the proposed codec./ """ " On 10/23/09 6:29 AM, "Benjamin M. Schwartz" wrot= e: Slava Borilin wrote: > Henry, e2e (or p2p) is cool but what about Legal interception for > example in this case, which every cellco has to implemenet? Whether or not we want to encourage it, interception of VoIP traffic does not require a re-encode. The encoded packets can just be copied to the additional receiver. To address the "tandeming" issue, I think the following text should be added to the "Basic Requirements" or "Additional Considerations": """ Audio Corruption Robustness The systems providing input to the encoder and output from the decoder are likely to be far from ideal in actual use. Input and output audio streams may be corrupted by artifacts from analog hardware and digital processing. The codecs to be developed should be tested to ensure that they degrade gracefully under adverse audio conditions. Types of digital corruption that may be tested include tandem encoding with similar and different codecs, low-quality resampling, and digital clipping. Types of analog corruption that may be tested include microphones with substantial background noise, analog clipping, and loudspeaker distortion. """ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jovass@adobe.com Mon Oct 26 14:12:01 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B6128C28B for ; Mon, 26 Oct 2009 14:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6QE915P4I9e for ; Mon, 26 Oct 2009 14:11:47 -0700 (PDT) Received: from psmtp.com (exprod6ob109.obsmtp.com [64.18.1.22]) by core3.amsl.com (Postfix) with ESMTP id 213F428C26F for ; Mon, 26 Oct 2009 14:11:36 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKSuYQj+oTwk1HqUcovf92Cf02g/OKThXA@postini.com; Mon, 26 Oct 2009 14:11:57 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9QL4Uao026644; Mon, 26 Oct 2009 14:04:30 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9QLBVlu008980; Mon, 26 Oct 2009 14:11:38 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 14:09:35 -0700 Received: from nambx03.corp.adobe.com ([10.8.189.93]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Mon, 26 Oct 2009 14:09:03 -0700 From: Jozsef Vass To: Stephan Wenger , Slava Borilin , Henry Sinnreich , Jean-Marc Valin , Lars Eggert Date: Mon, 26 Oct 2009 14:09:01 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdAAADCvbsABaP04A== Message-ID: <0FEA137C08A9DF4781EEF745038C9694146B2D6DE4@nambx03.corp.adobe.com> References: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DE4nambx03corpad_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:12:01 -0000 --_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DE4nambx03corpad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In rfc 3984 processing packets by mane has some clear benefits, e.g., disca= rding packets that the decoder would describe anyways (section 7.3), droppi= ng packets in case of congestion, etc. Here, we mostly talking about reducing packet size, and I am not sure how b= eneficial it is regarding the overall system. Consider speex. Quality level= six, wideband and narrowband encoder produces 52 bytes and 28 bytes of pay= load, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 by= tes. Since packet rate is the same, I do not think it will affect congestio= n too much. Please also consider that processing packets by intermediary, a= dds additional delay. Jozsef ________________________________ From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Monday, October 26, 2009 11:15 AM To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Egge= rt Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal I think that we have a terminology problem here. Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is th= ey don't modify IP packets. Boxes that look deep into the IP packets, and = (potentially) modify them, are higher layer devices. After long discussion= s in AVT at the time, RFC 3984 and its successors call those boxes "Media A= ware Network Elements", MANEs. MANEs modify packets at the application lay= er, for example to remove layers, re-package H.264 NAL units to adapt to di= fferent MTU sizes, and do all kinds of other things that violate the end-to= -end principle. A MANE has business in looking into, and potentially modif= ying, IP/UDP/RTP packets, a router has not. When MANEs are in the picture, it's IMO totally acceptable (from both an ab= stract layering theory viewpoint and in practice) that packets are being op= ened and the content is repackaged. It's actually common practice. Stephan On 10/26/09 10:55 AM, "Jozsef Vass" wrote: I do not like the idea of sending multiple layers in a packet either. I fee= l very uncomfortable of routers modifying packets. It is OK not to deliver,= but delivering semantically modified packet is not expected. Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets. Jozsef ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Thursday, October 22, 2009 12:23 PM To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Again - my point is that router does NOT have to know that something specif= ically is the codec, or specific codec- the only goal is to let router awar= e that the stream (and every packet) is LAYERED, and that it is legitimate = to strip out some layers if necessary due to congestion. The content of such "layered" can be any - voice codec, video codec, audio = codec, any type of content. And I agree with Gregory - that having current infrastructure using layers = in separate streams will require too much overhead (packets) which does not= make sense as well - and I am thinking about one stream of packets comtain= ing all the layers, which, however, can be modified on the fly "in the midd= le". So we may think about more generic concept of "declared layered content" wh= ich does NOT loose the information (well, most of it) by stripping out port= ions of the packet and reducing the traffic, so router can strip out any ty= pe of layered content, without going deep into specific codec. Again- this is "na=EFve" suggestions from me (very limited engineer) - and = definitely I am looking for objections even more then for agreement - for t= he sake of either finding the idea useful or making judged deny of it, and = I agree that this concept is only one possible way of working with congesti= on. best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of S= lava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Henry, With all of my respect (you know) - this is too high-level consideration an= d too generic statement which doesn't answer MPLS issue for example. best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it knows= nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its only = one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DE4nambx03corpad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

In rfc 3984 processing packets by mane= has some clear benefits, e.g., discarding packets that the decoder would descri= be anyways (section 7.3), dropping packets in case of congestion, etc.

 

Here, we mostly talking about reducing packet size, and I am not sure how beneficial it is regarding the overall s= ystem. Consider speex. Quality level six, wideband and narrowband encoder produces= 52 bytes and 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go fro= m 92 bytes to 68 bytes. Since packet rate is the same, I do not think it will af= fect congestion too much. Please also consider that processing packets by interm= ediary, adds additional delay.

 

Jozsef

 

From: Stephan = Wenger [mailto:stewe@stewe.org]
Sent: Monday, October 26, 20= 09 11:15 AM
To: Jozsef Vass; Slava Boril= in; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

 

I think that we have a termi= nology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is th= ey don’t modify IP packets.  Boxes that look deep into the IP packe= ts, and (potentially) modify them, are higher layer devices.  After long discussions in AVT at the time, RFC 3984 and its successors call those boxe= s “Media Aware Network Elements”, MANEs.  MANEs modify packe= ts at the application layer, for example to remove layers, re-package H.264 NA= L units to adapt to different MTU sizes, and do all kinds of other things that viol= ate the end-to-end principle.  A MANE has business in looking into, and potentially modifying, IP/UDP/RTP packets, a router has not.

When MANEs are in the picture, it’s IMO totally acceptable (from both= an abstract layering theory viewpoint and in practice) that packets are being opened and the content is repackaged.  It’s actually common practice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <jovass@adobe.com> wrote:

I do not like the idea of sending mult= iple layers in a packet either. I feel very uncomfortable of routers modifying packets. It is OK not to deliver, but delivering semantically modified pack= et is not expected.
 
Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets.
 
Jozsef
 

From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Thursday, October 22, = 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Again - my point is that router does NOT have to know tha= t something specifically is the codec, or specific codec- the only goal is to= let router aware that the stream (and every packet) is LAYERED, and that it is legitimate to strip out some layers if necessary due to congestion.
The content of such “layered” can be any – voice codec, v= ideo codec, audio codec, any type of content.
 
And I agree with Gregory – that having current infrastructure using layers in separate streams will require too much overhead (packets) which d= oes not make sense as well – and I am thinking about one stream of packet= s comtaining all the layers, which, however, can be modified on the fly ̶= 0;in the middle”.
So we may think about more generic concept of “declared layered content” which does NOT loose the information (well, most of it) by s= tripping out portions of the packet and reducing the traffic, so router can strip ou= t any type of layered content, without going deep into specific codec.
 
Again- this is “na=EFve” suggestions from me (very limited engi= neer) – and definitely I am looking for objections even more then for agree= ment – for the sake of either finding the idea useful or making judged den= y of it, and I agree that this concept is only one possible way of working with congestion.
 

best regards,
Slava Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Slava Borilin
Sent: Thursday, October 22, = 2009 11:13 PM
To: Henry Sinnreich; Jean-Ma= rc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Henry,
With all of my respect (you know) – this is too high-level considerat= ion and too generic statement which doesn’t answer MPLS issue for example= .
 

best regards,
Slava Borilin

From:= = Henry Sinnreich [mailto:hsinnrei@adobe.com<= /a>]
Sent: Thursday, October 22, = 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Slava,

>I am not that sure that routers should not be aware of the codecs. Why?=
>If we are building MPLS and other systems that is content-dependent, wh= y
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its only = one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] O= n Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you don't
> involve the codec in some form, performance/quality will be bad. Some<= br> > codecs need time to adjust the rate. Some can only adjust it in pretty=

> coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just wa= nt to
be
careful not to include in the codec things that don't belong there (e.g. a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never
> attempt to probe for more capacity unless the codec generates more
data,
> and why would the codec do that if it's converged to transmit at some<= br> > lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP<= br> > packets to react appropriately to the marks or losses. In other words,=
a
> layered codec will see losses/marks to packets sent on all layers, and=

> will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You don't
need layers to have a multi-rate codec. Layering just means that you can
strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much the=
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality will=

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* losses/marks to
> determine capacity. People have tried to create congestion control
> schemes that avoid causing losses (delay-based schemed, for example),<= br> > but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable - the
> rate computation is usually clocked by the RTT. You can obviously
dampen
> this somehow, but you can never say "now I have found a rate that= I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that
you
can have one module that determines in real-time the best rate to use at
that moment and then it tells the codec what to use. If it needs help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to the other layers.
On
>> example here (also included in the draft) is VBR, which means that=
the
>> application specifies an average rate and the codec decides how to=
>> vary the
>> rate to achieve that (subject to some rate control constraints). Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DE4nambx03corpad_-- From Borilin@spiritdsp.com Mon Oct 26 14:14:05 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7B328C17F for ; Mon, 26 Oct 2009 14:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 aYoqPHl2Bh0q for ; Mon, 26 Oct 2009 14:13:51 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 7672E28C17C for ; Mon, 26 Oct 2009 14:13:50 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9QLDsFc056055; Tue, 27 Oct 2009 00:13:55 +0300 (MSK) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5681.35A99574" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 27 Oct 2009 00:13:46 +0300 Message-ID: In-Reply-To: <0FEA137C08A9DF4781EEF745038C9694146B2D6DE4@nambx03.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdAAADCvbsABaP04AAAmBgA References: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> <0FEA137C08A9DF4781EEF745038C9694146B2D6DE4@nambx03.corp.adobe.com> From: "Slava Borilin" To: "Jozsef Vass" , "Stephan Wenger" , "Henry Sinnreich" , "Jean-Marc Valin" , "Lars Eggert" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:14:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5681.35A99574 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speex is not layered, isn't it? =20 best regards, Slava Borilin ________________________________ From: Jozsef Vass [mailto:jovass@adobe.com]=20 Sent: Tuesday, October 27, 2009 12:09 AM To: Stephan Wenger; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; = Lars Eggert Cc: codec@ietf.org Subject: RE: [codec] updated charter proposal =20 In rfc 3984 processing packets by mane has some clear benefits, e.g., = discarding packets that the decoder would describe anyways (section = 7.3), dropping packets in case of congestion, etc. =20 Here, we mostly talking about reducing packet size, and I am not sure = how beneficial it is regarding the overall system. Consider speex. = Quality level six, wideband and narrowband encoder produces 52 bytes and = 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from = 92 bytes to 68 bytes. Since packet rate is the same, I do not think it = will affect congestion too much. Please also consider that processing = packets by intermediary, adds additional delay. =20 Jozsef =20 ________________________________ From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: Monday, October 26, 2009 11:15 AM To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars = Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 I think that we have a terminology problem here. Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is = they don't modify IP packets. Boxes that look deep into the IP packets, = and (potentially) modify them, are higher layer devices. After long = discussions in AVT at the time, RFC 3984 and its successors call those = boxes "Media Aware Network Elements", MANEs. MANEs modify packets at = the application layer, for example to remove layers, re-package H.264 = NAL units to adapt to different MTU sizes, and do all kinds of other = things that violate the end-to-end principle. A MANE has business in = looking into, and potentially modifying, IP/UDP/RTP packets, a router = has not. When MANEs are in the picture, it's IMO totally acceptable (from both an = abstract layering theory viewpoint and in practice) that packets are = being opened and the content is repackaged. It's actually common = practice. Stephan On 10/26/09 10:55 AM, "Jozsef Vass" wrote: I do not like the idea of sending multiple layers in a packet either. I = feel very uncomfortable of routers modifying packets. It is OK not to = deliver, but delivering semantically modified packet is not expected. =20 Using layers for video totally makes sense where the rates are much = higher and layers can be transported in separate packets. =20 Jozsef =20 ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com]=20 Sent: Thursday, October 22, 2009 12:23 PM To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Again - my point is that router does NOT have to know that something = specifically is the codec, or specific codec- the only goal is to let = router aware that the stream (and every packet) is LAYERED, and that it = is legitimate to strip out some layers if necessary due to congestion. The content of such "layered" can be any - voice codec, video codec, = audio codec, any type of content. =20 And I agree with Gregory - that having current infrastructure using = layers in separate streams will require too much overhead (packets) = which does not make sense as well - and I am thinking about one stream = of packets comtaining all the layers, which, however, can be modified on = the fly "in the middle". So we may think about more generic concept of "declared layered content" = which does NOT loose the information (well, most of it) by stripping out = portions of the packet and reducing the traffic, so router can strip out = any type of layered content, without going deep into specific codec. =20 Again- this is "na=EFve" suggestions from me (very limited engineer) - = and definitely I am looking for objections even more then for agreement = - for the sake of either finding the idea useful or making judged deny = of it, and I agree that this concept is only one possible way of working = with congestion. =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Slava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Henry, With all of my respect (you know) - this is too high-level consideration = and too generic statement which doesn't answer MPLS issue for example. =20 best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, = why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its = only one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA5681.35A99574 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

Speex is not = layered, isn’t it?

 =

best regards,

Slava = Borilin

From: Jozsef Vass [mailto:jovass@adobe.com]
Sent: Tuesday, October = 27, 2009 12:09 AM
To: Stephan Wenger; Slava = Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: RE: [codec] = updated charter proposal

 

In rfc 3984 = processing packets by mane has some clear benefits, e.g., discarding packets that = the decoder would describe anyways (section 7.3), dropping packets in case = of congestion, etc.

 =

Here, we mostly = talking about reducing packet size, and I am not sure how beneficial it is = regarding the overall system. Consider speex. Quality level six, wideband and = narrowband encoder produces 52 bytes and 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 bytes. Since packet rate = is the same, I do not think it will affect congestion too much. Please also = consider that processing packets by intermediary, adds additional = delay.

 =

Jozsef=

 =

From: Stephan Wenger [mailto:stewe@stewe.org]
Sent: Monday, October 26, = 2009 11:15 AM
To: Jozsef Vass; Slava = Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

 

I think that = we have a terminology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is = they don’t modify IP packets.  Boxes that look deep into the IP = packets, and (potentially) modify them, are higher layer devices.  After = long discussions in AVT at the time, RFC 3984 and its successors call those = boxes “Media Aware Network Elements”, MANEs.  MANEs modify = packets at the application layer, for example to remove layers, re-package H.264 = NAL units to adapt to different MTU sizes, and do all kinds of other things = that violate the end-to-end principle.  A MANE has business in looking = into, and potentially modifying, IP/UDP/RTP packets, a router has not.

When MANEs are in the picture, it’s IMO totally acceptable (from = both an abstract layering theory viewpoint and in practice) that packets are = being opened and the content is repackaged.  It’s actually common practice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <jovass@adobe.com> wrote:

I do not like = the idea of sending multiple layers in a packet either. I feel very uncomfortable of routers modifying packets. It is OK not to deliver, but delivering = semantically modified packet is not expected.
 
Using layers for video totally makes sense where the rates are much = higher and layers can be transported in separate packets.
 
Jozsef
 

From: Slava Borilin [mailto:Borilin@spiritdsp.com]
Sent: Thursday, October = 22, 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Again - my point is that router = does NOT have to know that something specifically is the codec, or specific = codec- the only goal is to let router aware that the stream (and every packet) is = LAYERED, and that it is legitimate to strip out some layers if necessary due to congestion.
The content of such “layered” can be any – voice = codec, video codec, audio codec, any type of content.
 
And I agree with Gregory – that having current infrastructure = using layers in separate streams will require too much overhead (packets) = which does not make sense as well – and I am thinking about one stream of = packets comtaining all the layers, which, however, can be modified on the fly = “in the middle”.
So we may think about more generic concept of “declared layered content” which does NOT loose the information (well, most of it) = by stripping out portions of the packet and reducing the traffic, so router = can strip out any type of layered content, without going deep into specific = codec.
 
Again- this is “na=EFve” suggestions from me (very limited = engineer) – and definitely I am looking for objections even more then for = agreement – for the sake of either finding the idea useful or making judged = deny of it, and I agree that this concept is only one possible way of working = with congestion.
 

best = regards,
Slava Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of Slava Borilin
Sent: Thursday, October = 22, 2009 11:13 PM
To: Henry Sinnreich; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Henry,
With all of my respect (you know) – this is too high-level = consideration and too generic statement which doesn’t answer MPLS issue for = example.
 

best = regards,
Slava Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October = 22, 2009 11:10 PM
To: Slava Borilin; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Slava,

>I am not that sure that routers should not be aware of the codecs. = Why?
>If we are building MPLS and other systems that is content-dependent, = why
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its = only one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. = Why?
If we are building MPLS and other systems that is content-dependent, = why
not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it = can
be too hard and too long to tell each sender to reduce the rate - = why
not to leave this freedom to router as this may be more efficient = for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router = do
not need to understand anything except that it is LAYERED streams = (even
don't know whether its voice, video or audio or anything else of = layered
nature, and router "has the right" to strip out layers in = certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you = don't
> involve the codec in some form, performance/quality will be bad. = Some
> codecs need time to adjust the rate. Some can only adjust it in = pretty

> coarse steps. Etc. If you let DCCP adjust the rate blindly, = without
> involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just = want to
be
careful not to include in the codec things that don't belong there = (e.g.
a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control = will
never
> attempt to probe for more capacity unless the codec generates = more
data,
> and why would the codec do that if it's converged to transmit at = some
> lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want = to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the = codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! = Routers
> drop or mark IP packets. It is up to the application sending those = IP
> packets to react appropriately to the marks or losses. In other = words,
a
> layered codec will see losses/marks to packets sent on all layers, = and

> will then need to figure out whether to strip off a layer or not = in
> response to whatever congestion level those losses/marks = indicate.

I definitely agree that the routers shouldn't know about codecs and = this
is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the = middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You = don't
need layers to have a multi-rate codec. Layering just means that you = can

strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much = the
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality = will

> suffer IMO.

Well, we need to figure out the aspects that should be = codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* = losses/marks
to
> determine capacity. People have tried to create congestion = control
> schemes that avoid causing losses (delay-based schemed, for = example),
> but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable = -
the
> rate computation is usually clocked by the RTT. You can = obviously
dampen
> this somehow, but you can never say "now I have found a rate = that I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying = that
you
can have one module that determines in real-time the best rate to use = at

that moment and then it tells the codec what to use. If it needs = help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to = the other layers.
On
>> example here (also included in the draft) is VBR, which means = that
the
>> application specifies an average rate and the codec decides how = to
>> vary the
>> rate to achieve that (subject to some rate control = constraints).
Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK = if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec<= /p>

_________________________= ______________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

------_=_NextPart_001_01CA5681.35A99574-- From jovass@adobe.com Mon Oct 26 14:24:34 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D01828C0DB for ; Mon, 26 Oct 2009 14:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y62ZWv38+Fnd for ; Mon, 26 Oct 2009 14:24:19 -0700 (PDT) Received: from psmtp.com (exprod6ob114.obsmtp.com [64.18.1.32]) by core3.amsl.com (Postfix) with ESMTP id 5F38028C32B for ; Mon, 26 Oct 2009 14:24:08 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKSuYTgL272CE+Jv53NfavFuDJ1LH2+gFO@postini.com; Mon, 26 Oct 2009 14:24:29 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9QLH7ao028875; Mon, 26 Oct 2009 14:17:07 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9QLODlb012086; Mon, 26 Oct 2009 14:24:15 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 14:24:14 -0700 Received: from nambx03.corp.adobe.com ([10.8.189.93]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Mon, 26 Oct 2009 14:23:32 -0700 From: Jozsef Vass To: Slava Borilin , Stephan Wenger , Henry Sinnreich , Jean-Marc Valin , Lars Eggert Date: Mon, 26 Oct 2009 14:23:31 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdAAADCvbsABaP04AAAmBgAAAA/pdA= Message-ID: <0FEA137C08A9DF4781EEF745038C9694146B2D6DF6@nambx03.corp.adobe.com> References: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> <0FEA137C08A9DF4781EEF745038C9694146B2D6DE4@nambx03.corp.adobe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DF6nambx03corpad_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:24:34 -0000 --_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DF6nambx03corpad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From speex manual (http://www.speex.org/docs/manual/speex-manual/node4.html= #SECTION00410000000000000000): Integration of narrowband and wideband using an embedded bit-stream Jozsef ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Monday, October 26, 2009 2:14 PM To: Jozsef Vass; Stephan Wenger; Henry Sinnreich; Jean-Marc Valin; Lars Egg= ert Cc: codec@ietf.org Subject: RE: [codec] updated charter proposal Speex is not layered, isn't it? best regards, Slava Borilin ________________________________ From: Jozsef Vass [mailto:jovass@adobe.com] Sent: Tuesday, October 27, 2009 12:09 AM To: Stephan Wenger; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars E= ggert Cc: codec@ietf.org Subject: RE: [codec] updated charter proposal In rfc 3984 processing packets by mane has some clear benefits, e.g., disca= rding packets that the decoder would describe anyways (section 7.3), droppi= ng packets in case of congestion, etc. Here, we mostly talking about reducing packet size, and I am not sure how b= eneficial it is regarding the overall system. Consider speex. Quality level= six, wideband and narrowband encoder produces 52 bytes and 28 bytes of pay= load, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 by= tes. Since packet rate is the same, I do not think it will affect congestio= n too much. Please also consider that processing packets by intermediary, a= dds additional delay. Jozsef ________________________________ From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Monday, October 26, 2009 11:15 AM To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Egge= rt Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal I think that we have a terminology problem here. Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is th= ey don't modify IP packets. Boxes that look deep into the IP packets, and = (potentially) modify them, are higher layer devices. After long discussion= s in AVT at the time, RFC 3984 and its successors call those boxes "Media A= ware Network Elements", MANEs. MANEs modify packets at the application lay= er, for example to remove layers, re-package H.264 NAL units to adapt to di= fferent MTU sizes, and do all kinds of other things that violate the end-to= -end principle. A MANE has business in looking into, and potentially modif= ying, IP/UDP/RTP packets, a router has not. When MANEs are in the picture, it's IMO totally acceptable (from both an ab= stract layering theory viewpoint and in practice) that packets are being op= ened and the content is repackaged. It's actually common practice. Stephan On 10/26/09 10:55 AM, "Jozsef Vass" wrote: I do not like the idea of sending multiple layers in a packet either. I fee= l very uncomfortable of routers modifying packets. It is OK not to deliver,= but delivering semantically modified packet is not expected. Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets. Jozsef ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Thursday, October 22, 2009 12:23 PM To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Again - my point is that router does NOT have to know that something specif= ically is the codec, or specific codec- the only goal is to let router awar= e that the stream (and every packet) is LAYERED, and that it is legitimate = to strip out some layers if necessary due to congestion. The content of such "layered" can be any - voice codec, video codec, audio = codec, any type of content. And I agree with Gregory - that having current infrastructure using layers = in separate streams will require too much overhead (packets) which does not= make sense as well - and I am thinking about one stream of packets comtain= ing all the layers, which, however, can be modified on the fly "in the midd= le". So we may think about more generic concept of "declared layered content" wh= ich does NOT loose the information (well, most of it) by stripping out port= ions of the packet and reducing the traffic, so router can strip out any ty= pe of layered content, without going deep into specific codec. Again- this is "na=EFve" suggestions from me (very limited engineer) - and = definitely I am looking for objections even more then for agreement - for t= he sake of either finding the idea useful or making judged deny of it, and = I agree that this concept is only one possible way of working with congesti= on. best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of S= lava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Henry, With all of my respect (you know) - this is too high-level consideration an= d too generic statement which doesn't answer MPLS issue for example. best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it knows= nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its only = one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DF6nambx03corpad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

From speex manual (http://www.speex.org/docs/manual/speex-manual/node4.html= #SECTION00410000000000000000):

Integration of narrowband and wideband using an embedded bit-stream<= /font>

 

Jozsef

 

From: Slava Bo= rilin [mailto:Borilin@spiritdsp.com]
Sent: Monday, October 26, 20= 09 2:14 PM
To: Jozsef Vass; Stephan Wen= ger; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: RE: [codec] updated charter proposal

 

Speex is not layered, isn’t it?<= o:p>

 

best regards,=

Slava Borilin

From: Jozsef V= ass [mailto:jovass@adobe.com]
Sent: Tuesday, October 27, 2= 009 12:09 AM
To: Stephan Wenger; Slava Bo= rilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: RE: [codec] updated charter proposal

 

In rfc 3984 processing packets by mane= has some clear benefits, e.g., discarding packets that the decoder would descri= be anyways (section 7.3), dropping packets in case of congestion, etc.

 

Here, we mostly talking about reducing packet size, and I am not sure how beneficial it is regarding the overall system. Consider speex. Quality level six, wideband and narrowband encoder produces 52 bytes and 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 bytes. Since packet rate is the same, I = do not think it will affect congestion too much. Please also consider that processing packets by intermediary, adds additional delay.

 

Jozsef

 

From: Stephan = Wenger [mailto:stewe@stewe.org]
Sent: Monday, October 26, 20= 09 11:15 AM
To: Jozsef Vass; Slava Boril= in; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

 

I think that we have a termi= nology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is th= ey don’t modify IP packets.  Boxes that look deep into the IP packe= ts, and (potentially) modify them, are higher layer devices.  After long discussions in AVT at the time, RFC 3984 and its successors call those boxe= s “Media Aware Network Elements”, MANEs.  MANEs modify packe= ts at the application layer, for example to remove layers, re-package H.264 NAL units= to adapt to different MTU sizes, and do all kinds of other things that violate= the end-to-end principle.  A MANE has business in looking into, and potentially modifying, IP/UDP/RTP packets, a router has not.

When MANEs are in the picture, it’s IMO totally acceptable (from both= an abstract layering theory viewpoint and in practice) that packets are being opened and the content is repackaged.  It’s actually common prac= tice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <jovass@adobe.com> wrote:

I do not like the idea of sending mult= iple layers in a packet either. I feel very uncomfortable of routers modifying packets. It is OK not to deliver, but delivering semantically modified pack= et is not expected.
 
Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets.
 
Jozsef
 

From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Thursday, October 22, = 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Again - my point is that router does NOT have to know tha= t something specifically is the codec, or specific codec- the only goal is to= let router aware that the stream (and every packet) is LAYERED, and that it is = legitimate to strip out some layers if necessary due to congestion.
The content of such “layered” can be any – voice codec, v= ideo codec, audio codec, any type of content.
 
And I agree with Gregory – that having current infrastructure using l= ayers in separate streams will require too much overhead (packets) which does not ma= ke sense as well – and I am thinking about one stream of packets comtain= ing all the layers, which, however, can be modified on the fly “in the middle= ”.
So we may think about more generic concept of “declared layered conte= nt” which does NOT loose the information (well, most of it) by stripping out portions= of the packet and reducing the traffic, so router can strip out any type of layered content, without going deep into specific codec.
 
Again- this is “na=EFve” suggestions from me (very limited engi= neer) – and definitely I am looking for objections even more then for agreement –= for the sake of either finding the idea useful or making judged deny of it, and I a= gree that this concept is only one possible way of working with congestion.
 

best regards,
Slava Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Slava Borilin
Sent: Thursday, October 22, = 2009 11:13 PM
To: Henry Sinnreich; Jean-Ma= rc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Henry,
With all of my respect (you know) – this is too high-level considerat= ion and too generic statement which doesn’t answer MPLS issue for example.  

best regards,
Slava Borilin

From:= = Henry Sinnreich [mailto:hsinnrei@adobe.com<= /a>]
Sent: Thursday, October 22, = 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Slava,

>I am not that sure that routers should not be aware of the codecs. Why?=
>If we are building MPLS and other systems that is content-dependent, wh= y
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its only = one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] O= n Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you don't
> involve the codec in some form, performance/quality will be bad. Some<= br> > codecs need time to adjust the rate. Some can only adjust it in pretty=

> coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just wa= nt to
be
careful not to include in the codec things that don't belong there (e.g. a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never
> attempt to probe for more capacity unless the codec generates more
data,
> and why would the codec do that if it's converged to transmit at some<= br> > lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP<= br> > packets to react appropriately to the marks or losses. In other words,=
a
> layered codec will see losses/marks to packets sent on all layers, and=

> will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You don't
need layers to have a multi-rate codec. Layering just means that you can
strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much the=
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality will=

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* losses/marks to
> determine capacity. People have tried to create congestion control
> schemes that avoid causing losses (delay-based schemed, for example),<= br> > but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable - the
> rate computation is usually clocked by the RTT. You can obviously
dampen
> this somehow, but you can never say "now I have found a rate that= I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that
you
can have one module that determines in real-time the best rate to use at
that moment and then it tells the codec what to use. If it needs help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to the = other layers.
On
>> example here (also included in the draft) is VBR, which means that=
the
>> application specifies an average rate and the codec decides how to=
>> vary the
>> rate to achieve that (subject to some rate control constraints). Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DF6nambx03corpad_-- From Borilin@spiritdsp.com Mon Oct 26 14:27:12 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B5C28C164 for ; Mon, 26 Oct 2009 14:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.674 X-Spam-Level: X-Spam-Status: No, score=-0.674 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 mVg1+ScbBSGe for ; Mon, 26 Oct 2009 14:26:58 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 60B8C28C16A for ; Mon, 26 Oct 2009 14:26:57 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9QLR4TS056253; Tue, 27 Oct 2009 00:27:05 +0300 (MSK) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5683.0C808CEF" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 27 Oct 2009 00:26:56 +0300 Message-ID: In-Reply-To: <0FEA137C08A9DF4781EEF745038C9694146B2D6DF6@nambx03.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdAAADCvbsABaP04AAAmBgAAAA/pdAAAC8+EA== References: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> <0FEA137C08A9DF4781EEF745038C9694146B2D6DE4@nambx03.corp.adobe.com> <0FEA137C08A9DF4781EEF745038C9694146B2D6DF6@nambx03.corp.adobe.com> From: "Slava Borilin" To: "Jozsef Vass" , "Stephan Wenger" , "Henry Sinnreich" , "Jean-Marc Valin" , "Lars Eggert" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:27:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5683.0C808CEF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also think that we are talking not only about packet size, but only = packet rate as well? =20 best regards, Slava Borilin ________________________________ From: Jozsef Vass [mailto:jovass@adobe.com]=20 Sent: Tuesday, October 27, 2009 12:09 AM To: Stephan Wenger; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; = Lars Eggert Cc: codec@ietf.org Subject: RE: [codec] updated charter proposal =20 In rfc 3984 processing packets by mane has some clear benefits, e.g., = discarding packets that the decoder would describe anyways (section = 7.3), dropping packets in case of congestion, etc. =20 Here, we mostly talking about reducing packet size, and I am not sure = how beneficial it is regarding the overall system. Consider speex. = Quality level six, wideband and narrowband encoder produces 52 bytes and = 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from = 92 bytes to 68 bytes. Since packet rate is the same, I do not think it = will affect congestion too much. Please also consider that processing = packets by intermediary, adds additional delay. =20 Jozsef =20 ________________________________ From: Stephan Wenger [mailto:stewe@stewe.org]=20 Sent: Monday, October 26, 2009 11:15 AM To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars = Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal =20 I think that we have a terminology problem here. Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is = they don't modify IP packets. Boxes that look deep into the IP packets, = and (potentially) modify them, are higher layer devices. After long = discussions in AVT at the time, RFC 3984 and its successors call those = boxes "Media Aware Network Elements", MANEs. MANEs modify packets at = the application layer, for example to remove layers, re-package H.264 = NAL units to adapt to different MTU sizes, and do all kinds of other = things that violate the end-to-end principle. A MANE has business in = looking into, and potentially modifying, IP/UDP/RTP packets, a router = has not. When MANEs are in the picture, it's IMO totally acceptable (from both an = abstract layering theory viewpoint and in practice) that packets are = being opened and the content is repackaged. It's actually common = practice. Stephan On 10/26/09 10:55 AM, "Jozsef Vass" wrote: I do not like the idea of sending multiple layers in a packet either. I = feel very uncomfortable of routers modifying packets. It is OK not to = deliver, but delivering semantically modified packet is not expected. =20 Using layers for video totally makes sense where the rates are much = higher and layers can be transported in separate packets. =20 Jozsef =20 ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com]=20 Sent: Thursday, October 22, 2009 12:23 PM To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Again - my point is that router does NOT have to know that something = specifically is the codec, or specific codec- the only goal is to let = router aware that the stream (and every packet) is LAYERED, and that it = is legitimate to strip out some layers if necessary due to congestion. The content of such "layered" can be any - voice codec, video codec, = audio codec, any type of content. =20 And I agree with Gregory - that having current infrastructure using = layers in separate streams will require too much overhead (packets) = which does not make sense as well - and I am thinking about one stream = of packets comtaining all the layers, which, however, can be modified on = the fly "in the middle". So we may think about more generic concept of "declared layered content" = which does NOT loose the information (well, most of it) by stripping out = portions of the packet and reducing the traffic, so router can strip out = any type of layered content, without going deep into specific codec. =20 Again- this is "na=EFve" suggestions from me (very limited engineer) - = and definitely I am looking for objections even more then for agreement = - for the sake of either finding the idea useful or making judged deny = of it, and I agree that this concept is only one possible way of working = with congestion. =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Slava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Henry, With all of my respect (you know) - this is too high-level consideration = and too generic statement which doesn't answer MPLS issue for example. =20 best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, = why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its = only one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01CA5683.0C808CEF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

I also think = that we are talking not only about packet size, but only packet rate as = well?

 =

best regards,

Slava = Borilin

From: Jozsef Vass [mailto:jovass@adobe.com]
Sent: Tuesday, October = 27, 2009 12:09 AM
To: Stephan Wenger; Slava = Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: RE: [codec] = updated charter proposal

 

In rfc 3984 = processing packets by mane has some clear benefits, e.g., discarding packets that = the decoder would describe anyways (section 7.3), dropping packets in case = of congestion, etc.

 =

Here, we mostly = talking about reducing packet size, and I am not sure how beneficial it is = regarding the overall system. Consider speex. Quality level six, wideband and = narrowband encoder produces 52 bytes and 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 bytes. Since packet rate = is the same, I do not think it will affect congestion too much. Please also = consider that processing packets by intermediary, adds additional = delay.

 =

Jozsef=

 =

From: Stephan Wenger [mailto:stewe@stewe.org]
Sent: Monday, October 26, = 2009 11:15 AM
To: Jozsef Vass; Slava = Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

 

I think that = we have a terminology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is = they don’t modify IP packets.  Boxes that look deep into the IP = packets, and (potentially) modify them, are higher layer devices.  After = long discussions in AVT at the time, RFC 3984 and its successors call those = boxes “Media Aware Network Elements”, MANEs.  MANEs modify = packets at the application layer, for example to remove layers, re-package H.264 = NAL units to adapt to different MTU sizes, and do all kinds of other things = that violate the end-to-end principle.  A MANE has business in looking = into, and potentially modifying, IP/UDP/RTP packets, a router has not.

When MANEs are in the picture, it’s IMO totally acceptable (from = both an abstract layering theory viewpoint and in practice) that packets are = being opened and the content is repackaged.  It’s actually common practice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <jovass@adobe.com> wrote:

I do not like = the idea of sending multiple layers in a packet either. I feel very uncomfortable of routers modifying packets. It is OK not to deliver, but delivering = semantically modified packet is not expected.
 
Using layers for video totally makes sense where the rates are much = higher and layers can be transported in separate packets.
 
Jozsef
 

From: Slava Borilin [mailto:Borilin@spiritdsp.com]
Sent: Thursday, October = 22, 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Again - my point is that router = does NOT have to know that something specifically is the codec, or specific = codec- the only goal is to let router aware that the stream (and every packet) is = LAYERED, and that it is legitimate to strip out some layers if necessary due to congestion.
The content of such “layered” can be any – voice = codec, video codec, audio codec, any type of content.
 
And I agree with Gregory – that having current infrastructure = using layers in separate streams will require too much overhead (packets) = which does not make sense as well – and I am thinking about one stream of = packets comtaining all the layers, which, however, can be modified on the fly = “in the middle”.
So we may think about more generic concept of “declared layered content” which does NOT loose the information (well, most of it) = by stripping out portions of the packet and reducing the traffic, so router = can strip out any type of layered content, without going deep into specific = codec.
 
Again- this is “na=EFve” suggestions from me (very limited = engineer) – and definitely I am looking for objections even more then for = agreement – for the sake of either finding the idea useful or making judged = deny of it, and I agree that this concept is only one possible way of working = with congestion.
 

best = regards,
Slava Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of Slava Borilin
Sent: Thursday, October = 22, 2009 11:13 PM
To: Henry Sinnreich; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Henry,
With all of my respect (you know) – this is too high-level = consideration and too generic statement which doesn’t answer MPLS issue for = example.
 

best = regards,
Slava Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October = 22, 2009 11:10 PM
To: Slava Borilin; = Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] = updated charter proposal

Slava,

>I am not that sure that routers should not be aware of the codecs. = Why?
>If we are building MPLS and other systems that is content-dependent, = why
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it = knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its = only one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. = Why?
If we are building MPLS and other systems that is content-dependent, = why
not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it = can
be too hard and too long to tell each sender to reduce the rate - = why
not to leave this freedom to router as this may be more efficient = for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router = do
not need to understand anything except that it is LAYERED streams = (even
don't know whether its voice, video or audio or anything else of = layered
nature, and router "has the right" to strip out layers in = certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you = don't
> involve the codec in some form, performance/quality will be bad. = Some
> codecs need time to adjust the rate. Some can only adjust it in = pretty

> coarse steps. Etc. If you let DCCP adjust the rate blindly, = without
> involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just = want to
be
careful not to include in the codec things that don't belong there = (e.g.
a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control = will
never
> attempt to probe for more capacity unless the codec generates = more
data,
> and why would the codec do that if it's converged to transmit at = some
> lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want = to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the = codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! = Routers
> drop or mark IP packets. It is up to the application sending those = IP
> packets to react appropriately to the marks or losses. In other = words,
a
> layered codec will see losses/marks to packets sent on all layers, = and

> will then need to figure out whether to strip off a layer or not = in
> response to whatever congestion level those losses/marks = indicate.

I definitely agree that the routers shouldn't know about codecs and = this
is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the = middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You = don't
need layers to have a multi-rate codec. Layering just means that you = can

strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much = the
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality = will

> suffer IMO.

Well, we need to figure out the aspects that should be = codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* = losses/marks
to
> determine capacity. People have tried to create congestion = control
> schemes that avoid causing losses (delay-based schemed, for = example),
> but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable = -
the
> rate computation is usually clocked by the RTT. You can = obviously
dampen
> this somehow, but you can never say "now I have found a rate = that I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying = that
you
can have one module that determines in real-time the best rate to use = at

that moment and then it tells the codec what to use. If it needs = help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to = the other layers.
On
>> example here (also included in the draft) is VBR, which means = that
the
>> application specifies an average rate and the codec decides how = to
>> vary the
>> rate to achieve that (subject to some rate control = constraints).
Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK = if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec<= /p>

_________________________= ______________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

------_=_NextPart_001_01CA5683.0C808CEF-- From stewe@stewe.org Mon Oct 26 14:28:56 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09DF28C16A for ; Mon, 26 Oct 2009 14:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.329 X-Spam-Level: X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315] 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 0JgLqMeOMlDh for ; Mon, 26 Oct 2009 14:28:43 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id DEE3D28C189 for ; Mon, 26 Oct 2009 14:28:39 -0700 (PDT) Received: from [192.168.1.111] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 470915-1743317 for multiple; Mon, 26 Oct 2009 22:28:53 +0100 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 14:28:44 -0700 From: Stephan Wenger To: Jozsef Vass , Slava Borilin , Henry Sinnreich , Jean-Marc Valin , Lars Eggert Message-ID: Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdAAADCvbsABaP04AABIChS In-Reply-To: <0FEA137C08A9DF4781EEF745038C9694146B2D6DE4@nambx03.corp.adobe.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3339412130_2650127" X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:28:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339412130_2650127 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I think that these arguments boil down to the discussion of measurement of congestion in the packet count domain or in the bitrate domain. I don=B9t think there=B9s a verdict yet which of the two are really important. It may very well depend on your viewpoint and on what your company makes money of. When operating in low delay environments (as it is the assumption here), I agree that there is not much point in attempting to reduce the packet count---doing so would increase delay and would presumably be unacceptable to the application. Therefore, congestion friendliness, when congestion is measured in the packet count domain, seems to be independent from the codec characteristics; as long as the codec is optimized for low delay. However, if we start from the assumption that congestion is measured in the bitrate domain, then the ballgame is somewhat different. Yes, when we drop a layer from a hypothetical layered audio codec, we would not safe a lot of bits in absolute numbers, and yes, the percentage would be even more disappointing considering the packetization overhead. But still, we would reduce the overall bitrate. If you have thousands or millions of sessions on the same fiber, dropping layers could be argued to make a difference. Stephan=20 On 10/26/09 2:09 PM, "Jozsef Vass" wrote: > In rfc 3984 processing packets by mane has some clear benefits, e.g., > discarding packets that the decoder would describe anyways (section 7.3), > dropping packets in case of congestion, etc. > =20 > Here, we mostly talking about reducing packet size, and I am not sure how > beneficial it is regarding the overall system. Consider speex. Quality le= vel > six, wideband and narrowband encoder produces 52 bytes and 28 bytes of > payload, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to = 68 > bytes. Since packet rate is the same, I do not think it will affect conge= stion > too much. Please also consider that processing packets by intermediary, a= dds > additional delay. > =20 > Jozsef > =20 >=20 >=20 > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: Monday, October 26, 2009 11:15 AM > To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eg= gert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > =20 > I think that we have a terminology problem here. >=20 > Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is = they > don=B9t modify IP packets. Boxes that look deep into the IP packets, and > (potentially) modify them, are higher layer devices. After long discussi= ons > in AVT at the time, RFC 3984 and its successors call those boxes =B3Media A= ware > Network Elements=B2, MANEs. MANEs modify packets at the application layer,= for > example to remove layers, re-package H.264 NAL units to adapt to differen= t MTU > sizes, and do all kinds of other things that violate the end-to-end princ= iple. > A MANE has business in looking into, and potentially modifying, IP/UDP/RT= P > packets, a router has not. >=20 > When MANEs are in the picture, it=B9s IMO totally acceptable (from both an > abstract layering theory viewpoint and in practice) that packets are bein= g > opened and the content is repackaged. It=B9s actually common practice. >=20 > Stephan >=20 > On 10/26/09 10:55 AM, "Jozsef Vass" wrote: > I do not like the idea of sending multiple layers in a packet either. I f= eel > very uncomfortable of routers modifying packets. It is OK not to deliver,= but > delivering semantically modified packet is not expected. > =20 > Using layers for video totally makes sense where the rates are much highe= r and > layers can be transported in separate packets. > =20 > Jozsef > =20 >=20 >=20 > From: Slava Borilin [mailto:Borilin@spiritdsp.com] > Sent: Thursday, October 22, 2009 12:23 PM > To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal >=20 > Again - my point is that router does NOT have to know that something > specifically is the codec, or specific codec- the only goal is to let rou= ter > aware that the stream (and every packet) is LAYERED, and that it is legit= imate > to strip out some layers if necessary due to congestion. > The content of such =B3layered=B2 can be any =AD voice codec, video codec, audi= o > codec, any type of content. > =20 > And I agree with Gregory =AD that having current infrastructure using layer= s in > separate streams will require too much overhead (packets) which does not = make > sense as well =AD and I am thinking about one stream of packets comtaining = all > the layers, which, however, can be modified on the fly =B3in the middle=B2. > So we may think about more generic concept of =B3declared layered content=B2 = which > does NOT loose the information (well, most of it) by stripping out portio= ns of > the packet and reducing the traffic, so router can strip out any type of > layered content, without going deep into specific codec. > =20 > Again- this is =B3na=EFve=B2 suggestions from me (very limited engineer) =AD and > definitely I am looking for objections even more then for agreement =AD for= the > sake of either finding the idea useful or making judged deny of it, and I > agree that this concept is only one possible way of working with congesti= on. > =20 >=20 > best regards, > Slava Borilin >=20 >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Slava Borilin > Sent: Thursday, October 22, 2009 11:13 PM > To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal >=20 > Henry, > With all of my respect (you know) =AD this is too high-level consideration = and > too generic statement which doesn=B9t answer MPLS issue for example. > =20 >=20 > best regards, > Slava Borilin >=20 >=20 > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, October 22, 2009 11:10 PM > To: Slava Borilin; Jean-Marc Valin; Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal >=20 > Slava, >=20 >> >I am not that sure that routers should not be aware of the codecs. Why? >> >If we are building MPLS and other systems that is content-dependent, wh= y >> >not let router understand the codec? >=20 > The essence of the Dumb Network (Internet) and its routers is that it kno= ws > nothing about the applications. > All applications that nobody planned for can run over it. > The tragedy of the telephone network was is knew everything about its onl= y one > application. >=20 > Henry >=20 >=20 > On 10/22/09 1:23 PM, "Slava Borilin" wrote: > I am not that sure that routers should not be aware of the codecs. Why? > If we are building MPLS and other systems that is content-dependent, why > not let router understand the codec? >=20 > Especially if we have hordes of voice channels going thru router, it can > be too hard and too long to tell each sender to reduce the rate - why > not to leave this freedom to router as this may be more efficient for > congestion recovery? >=20 > Same applies to H.264SVC for example - at the end of the day, router do > not need to understand anything except that it is LAYERED streams (even > don't know whether its voice, video or audio or anything else of layered > nature, and router "has the right" to strip out layers in certain order > to prevent congestion? >=20 > best regards, > Slava Borilin >=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Thursday, October 22, 2009 5:45 PM > To: Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal >=20 > Lars Eggert wrote: >> > Also, what we've learned from media over DCCP is that if you don't >> > involve the codec in some form, performance/quality will be bad. Some >> > codecs need time to adjust the rate. Some can only adjust it in pretty >=20 >> > coarse steps. Etc. If you let DCCP adjust the rate blindly, without >> > involving the codec in some form, you might get very good TCP >> > friendliness, but maybe quality will suffer. >=20 > I'm totally in favour of "involving the codec" in here. I just want to > be > careful not to include in the codec things that don't belong there (e.g. > a > DCCP implementation or a whole jitter buffer). >=20 >> > (And there is always the ramping up part - congestion control will > never >> > attempt to probe for more capacity unless the codec generates more > data, >> > and why would the codec do that if it's converged to transmit at some >> > lower rate.) >=20 > Well, the codec transmits at the rate you ask it to use. If you want to > probe for more capacity, then you tell the codec that it can use a > higher > rate. Now, if there's a special way in which you want to ask the codec, > then maybe that can become an additional feature for the codec. >=20 >> > By no means should routers have to understand codec formats! Routers >> > drop or mark IP packets. It is up to the application sending those IP >> > packets to react appropriately to the marks or losses. In other words, > a >> > layered codec will see losses/marks to packets sent on all layers, and >=20 >> > will then need to figure out whether to strip off a layer or not in >> > response to whatever congestion level those losses/marks indicate. >=20 > I definitely agree that the routers shouldn't know about codecs and this > is > why I was saying that IMO layered codecs aren't too useful for > congestion > control (though they have other uses). If there's nothing in the middle > of > the network to strip off the layers, then you might as well not have > layers > at all. All you need is to ask the sender to reduce the rate. You don't > need layers to have a multi-rate codec. Layering just means that you can >=20 > strip off bits and still have the result sound OK. >=20 >>> >> OK, I may be wrong here, but my understanding is that how much the > rate >>> >> should change depending on congestion is actually not that >>> >> codec-specific. >> > >> > It *can* be non-codec-specific, see DCCP for example. But quality will >=20 >> > suffer IMO. >=20 > Well, we need to figure out the aspects that should be codec-specific > and > implement just those. Does anyone have a list of the issues codecs > should > be aware of? >=20 >> > Most Internet congestion control is based on *creating* losses/marks > to >> > determine capacity. People have tried to create congestion control >> > schemes that avoid causing losses (delay-based schemed, for example), >> > but they are perceived to be more fragile. >=20 > Yes, I can imagine the problem not being trivial at all. >=20 >>> >> Once you figure this out, you >>> >> can just tell the codec to use that rate. >> > >> > It's not that easy, because rates in the Internet are never stable - > the >> > rate computation is usually clocked by the RTT. You can obviously > dampen >> > this somehow, but you can never say "now I have found a rate that I > can >> > safely use forever." >=20 > Oh, I never said we should set a rate forever. I was just saying that > you > can have one module that determines in real-time the best rate to use at >=20 > that moment and then it tells the codec what to use. If it needs help > from > the codec, then we can define special functionality. >=20 >>> >> On top of that, the codec may be >>> >> able to do a bit better by providing a "service" to the other layers= . > On >>> >> example here (also included in the draft) is VBR, which means that > the >>> >> application specifies an average rate and the codec decides how to >>> >> vary the >>> >> rate to achieve that (subject to some rate control constraints). > Would >>> >> other such mechanisms be useful to deal with congestion? >> > >> > I'm not sure this would work, because congestion control will > basically >> > change the VBR input parameter continuously. >=20 > Changing the VBR parameters continuously is not a problem. VBR just > means > that you'd like to have an average of N kb/s for now, but you're OK if > there are variations from frame to frame. >=20 > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 --B_3339412130_2650127 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] updated charter proposal I think that these arguments boil down to the discussion of measurement of= congestion in the packet count domain or in the bitrate domain.  I don= ’t think there’s a verdict yet which of the two are really impor= tant.  It may very well depend on your viewpoint and on what your compa= ny makes money of.

When operating in low delay environments (as it is the assumption here), I = agree that there is not much point in attempting to reduce the packet count-= --doing so would increase delay and would presumably be unacceptable to the = application.  Therefore, congestion friendliness, when congestion is me= asured in the packet count domain, seems to be independent from the codec ch= aracteristics; as long as the codec is optimized for low delay.

However, if we start from the assumption that congestion is measured in the= bitrate domain, then the ballgame is somewhat different.  Yes, when we= drop a layer from a hypothetical layered audio codec, we would not safe a l= ot of bits in absolute numbers, and yes, the percentage would be even more d= isappointing considering the packetization overhead.  But still, we wou= ld reduce the overall bitrate.  If you have thousands or millions of se= ssions on the same fiber, dropping layers could be argued to make a differen= ce.

Stephan


On 10/26/09 2:09 PM, "Jozsef Vass" <jovass@adobe.com> wrote:

In rfc 3984 processing packets by mane h= as some clear benefits, e.g., discarding packets that the decoder would desc= ribe anyways (section 7.3), dropping packets in case of congestion, etc.
 
Here, we mostly talking about reducing packet size, and I am not sure how b= eneficial it is regarding the overall system. Consider speex. Quality level = six, wideband and narrowband encoder produces 52 bytes and 28 bytes of paylo= ad, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 bytes= . Since packet rate is the same, I do not think it will affect congestion to= o much. Please also consider that processing packets by intermediary, adds a= dditional delay.
 
Jozsef
 

From: Stephan Wenger [mailto:stewe@stewe.org]
Sent: Monday, October 26, 2009 11:15 AM
To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; La= rs Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal
I think that we have a terminology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is th= ey don’t modify IP packets.  Boxes that look deep into the IP pac= kets, and (potentially) modify them, are higher layer devices.  After l= ong discussions in AVT at the time, RFC 3984 and its successors call those b= oxes “Media Aware Network Elements”, MANEs.  MANEs modify p= ackets at the application layer, for example to remove layers, re-package H.= 264 NAL units to adapt to different MTU sizes, and do all kinds of other thi= ngs that violate the end-to-end principle.  A MANE has business in look= ing into, and potentially modifying, IP/UDP/RTP packets, a router has not.
When MANEs are in the picture, it’s IMO totally acceptable (from both= an abstract layering theory viewpoint and in practice) that packets are bei= ng opened and the content is repackaged.  It’s actually common pr= actice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <jovass@adobe.com> wrote:
I do not like the idea of sending multiple layers in= a packet either. I feel very uncomfortable of routers modifying packets. It= is OK not to deliver, but delivering semantically modified packet is not ex= pected.
 
Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets.
 
Jozsef
 


From: Slava Borilin [mailto:Borilin@spiritdsp.com]
Sent: Thursday, October 22, 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Again - my point is that router does NOT have to kno= w that something specifically is the codec, or specific codec- the only goal= is to let router aware that the stream (and every packet) is LAYERED, and t= hat it is legitimate to strip out some layers if necessary due to congestion= .
The content of such “layered” can be any – voice codec, v= ideo codec, audio codec, any type of content.
 
And I agree with Gregory – that having current infrastructure using l= ayers in separate streams will require too much overhead (packets) which doe= s not make sense as well – and I am thinking about one stream of packe= ts comtaining all the layers, which, however, can be modified on the fly = 220;in the middle”.
So we may think about more generic concept of “declared layered conte= nt” which does NOT loose the information (well, most of it) by strippi= ng out portions of the packet and reducing the traffic, so router can strip = out any type of layered content, without going deep into specific codec.
 
Again- this is “naïve” suggestions from me (very limited e= ngineer) – and definitely I am looking for objections even more then f= or agreement – for the sake of either finding the idea useful or makin= g judged deny of it, and I agree that this concept is only one possible way = of working with congestion.
 

best regards,
Slava Borilin

From: codec-bounces@= ietf.org [mailto:codec-bounces@i= etf.org] On Behalf Of Slava Borilin
Sent: Thursday, October 22, 2009 11:13 PM
To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Henry,
With all of my respect (you know) – this is too high-level considerat= ion and too generic statement which doesn’t answer MPLS issue for exam= ple.
 

best regards,
Slava Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, October 22, 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain= order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf=
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you don't
> involve the codec in some form, performance/quality will be bad. Some<= BR> > codecs need time to adjust the rate. Some can only adjust it in pretty=

> coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just wa= nt to
be
careful not to include in the codec things that don't belong there (e.g. a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never
> attempt to probe for more capacity unless the codec generates more
data,
> and why would the codec do that if it's converged to transmit at some<= BR> > lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP<= BR> > packets to react appropriately to the marks or losses. In other words,=
a
> layered codec will see losses/marks to packets sent on all layers, and=

> will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You don't
need layers to have a multi-rate codec. Layering just means that you can
strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much the=
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality will=

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* losses/marks to
> determine capacity. People have tried to create congestion control
> schemes that avoid causing losses (delay-based schemed, for example),<= BR> > but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable - the
> rate computation is usually clocked by the RTT. You can obviously
dampen
> this somehow, but you can never say "now I have found a rate that= I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that
you
can have one module that determines in real-time the best rate to use at
that moment and then it tells the codec what to use. If it needs help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to the = other layers.
On
>> example here (also included in the draft) is VBR, which means that=
the
>> application specifies an average rate and the codec decides how to=
>> vary the
>> rate to achieve that (subject to some rate control constraints). Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec

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

--B_3339412130_2650127-- From jean-marc.valin@usherbrooke.ca Mon Oct 26 14:30:16 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2285428C3A7 for ; Mon, 26 Oct 2009 14:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455] 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 pk1nY7g6ngvs for ; Mon, 26 Oct 2009 14:30:13 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id EB51E28C3A3 for ; Mon, 26 Oct 2009 14:30:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MR-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0KS500IP152HT250@VL-MR-MR001.ip.videotron.ca> for codec@ietf.org; Mon, 26 Oct 2009 17:30:24 -0400 (EDT) Message-id: <4AE614E9.3000702@usherbrooke.ca> Date: Mon, 26 Oct 2009 17:30:17 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: Slava Borilin References: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> <0FEA137C08A9DF4781EEF745038C9694146B2D6DE4@nambx03.corp.adobe.com> In-reply-to: X-Enigmail-Version: 0.95.2 Cc: Jozsef Vass , codec@ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:30:16 -0000 Speex has an embedded bit-stream with a narrowband base and a wideband "layer" on top. However, it is not possible to change the rate of the narrowband or wideband "layers" by removing bits. It is only possible to remove the entire wideband layer. This has the advantage of not introducing a large cost in terms of bit-rate, while still making it easy to decode a wideband stream in narrowband mode. That being said, I'm aware that SILK (and probably IP-MR and BV32, but I haven't heard samples) out-perform Speex in terms of quality vs rate. Jean-Marc Slava Borilin a écrit : > Speex is not layered, isn’t it? > > > > best regards, > > Slava Borilin > > ------------------------------------------------------------------------ > > *From:* Jozsef Vass [mailto:jovass@adobe.com] > *Sent:* Tuesday, October 27, 2009 12:09 AM > *To:* Stephan Wenger; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; > Lars Eggert > *Cc:* codec@ietf.org > *Subject:* RE: [codec] updated charter proposal > > > > In rfc 3984 processing packets by mane has some clear benefits, e.g., > discarding packets that the decoder would describe anyways (section > 7.3), dropping packets in case of congestion, etc. > > > > Here, we mostly talking about reducing packet size, and I am not sure > how beneficial it is regarding the overall system. Consider speex. > Quality level six, wideband and narrowband encoder produces 52 bytes and > 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from > 92 bytes to 68 bytes. Since packet rate is the same, I do not think it > will affect congestion too much. Please also consider that processing > packets by intermediary, adds additional delay. > > > > Jozsef > > > > ------------------------------------------------------------------------ > > *From:* Stephan Wenger [mailto:stewe@stewe.org] > *Sent:* Monday, October 26, 2009 11:15 AM > *To:* Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars > Eggert > *Cc:* codec@ietf.org > *Subject:* Re: [codec] updated charter proposal > > > > I think that we have a terminology problem here. > > Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is > they don’t modify IP packets. Boxes that look deep into the IP packets, > and (potentially) modify them, are higher layer devices. After long > discussions in AVT at the time, RFC 3984 and its successors call those > boxes “Media Aware Network Elements”, MANEs. MANEs modify packets at > the application layer, for example to remove layers, re-package H.264 > NAL units to adapt to different MTU sizes, and do all kinds of other > things that violate the end-to-end principle. A MANE has business in > looking into, and potentially modifying, IP/UDP/RTP packets, a router > has not. > > When MANEs are in the picture, it’s IMO totally acceptable (from both an > abstract layering theory viewpoint and in practice) that packets are > being opened and the content is repackaged. It’s actually common practice. > > Stephan > > On 10/26/09 10:55 AM, "Jozsef Vass" wrote: > > I do not like the idea of sending multiple layers in a packet either. I > feel very uncomfortable of routers modifying packets. It is OK not to > deliver, but delivering semantically modified packet is not expected. > > Using layers for video totally makes sense where the rates are much > higher and layers can be transported in separate packets. > > Jozsef > > > ------------------------------------------------------------------------ > > *From:* Slava Borilin [mailto:Borilin@spiritdsp.com] > *Sent:* Thursday, October 22, 2009 12:23 PM > *To:* Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert > *Cc:* codec@ietf.org > *Subject:* Re: [codec] updated charter proposal > > Again - my point is that router does NOT have to know that something > specifically is the codec, or specific codec- the only goal is to let > router aware that the stream (and every packet) is LAYERED, and that it > is legitimate to strip out some layers if necessary due to congestion. > The content of such “layered” can be any – voice codec, video codec, > audio codec, any type of content. > > And I agree with Gregory – that having current infrastructure using > layers in separate streams will require too much overhead (packets) > which does not make sense as well – and I am thinking about one stream > of packets comtaining all the layers, which, however, can be modified on > the fly “in the middle”. > So we may think about more generic concept of “declared layered content” > which does NOT loose the information (well, most of it) by stripping out > portions of the packet and reducing the traffic, so router can strip out > any type of layered content, without going deep into specific codec. > > Again- this is “naïve” suggestions from me (very limited engineer) – and > definitely I am looking for objections even more then for agreement – > for the sake of either finding the idea useful or making judged deny of > it, and I agree that this concept is only one possible way of working > with congestion. > > > best regards, > Slava Borilin > > ------------------------------------------------------------------------ > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On > Behalf Of *Slava Borilin > *Sent:* Thursday, October 22, 2009 11:13 PM > *To:* Henry Sinnreich; Jean-Marc Valin; Lars Eggert > *Cc:* codec@ietf.org > *Subject:* Re: [codec] updated charter proposal > > Henry, > With all of my respect (you know) – this is too high-level consideration > and too generic statement which doesn’t answer MPLS issue for example. > > > best regards, > Slava Borilin > > ------------------------------------------------------------------------ > > *From:* Henry Sinnreich [mailto:hsinnrei@adobe.com] > *Sent:* Thursday, October 22, 2009 11:10 PM > *To:* Slava Borilin; Jean-Marc Valin; Lars Eggert > *Cc:* codec@ietf.org > *Subject:* Re: [codec] updated charter proposal > > Slava, > >>I am not that sure that routers should not be aware of the codecs. Why? >>If we are building MPLS and other systems that is content-dependent, why >>not let router understand the codec? > > The essence of the Dumb Network (Internet) and its routers is that it > knows nothing about the applications. > All applications that nobody planned for can run over it. > The tragedy of the telephone network was is knew everything about its > only one application. > > Henry > > > On 10/22/09 1:23 PM, "Slava Borilin" wrote: > I am not that sure that routers should not be aware of the codecs. Why? > If we are building MPLS and other systems that is content-dependent, why > not let router understand the codec? > > Especially if we have hordes of voice channels going thru router, it can > be too hard and too long to tell each sender to reduce the rate - why > not to leave this freedom to router as this may be more efficient for > congestion recovery? > > Same applies to H.264SVC for example - at the end of the day, router do > not need to understand anything except that it is LAYERED streams (even > don't know whether its voice, video or audio or anything else of layered > nature, and router "has the right" to strip out layers in certain order > to prevent congestion? > > best regards, > Slava Borilin > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Thursday, October 22, 2009 5:45 PM > To: Lars Eggert > Cc: codec@ietf.org > Subject: Re: [codec] updated charter proposal > > Lars Eggert wrote: >> Also, what we've learned from media over DCCP is that if you don't >> involve the codec in some form, performance/quality will be bad. Some >> codecs need time to adjust the rate. Some can only adjust it in pretty > >> coarse steps. Etc. If you let DCCP adjust the rate blindly, without >> involving the codec in some form, you might get very good TCP >> friendliness, but maybe quality will suffer. > > I'm totally in favour of "involving the codec" in here. I just want to > be > careful not to include in the codec things that don't belong there (e.g. > a > DCCP implementation or a whole jitter buffer). > >> (And there is always the ramping up part - congestion control will > never >> attempt to probe for more capacity unless the codec generates more > data, >> and why would the codec do that if it's converged to transmit at some >> lower rate.) > > Well, the codec transmits at the rate you ask it to use. If you want to > probe for more capacity, then you tell the codec that it can use a > higher > rate. Now, if there's a special way in which you want to ask the codec, > then maybe that can become an additional feature for the codec. > >> By no means should routers have to understand codec formats! Routers >> drop or mark IP packets. It is up to the application sending those IP >> packets to react appropriately to the marks or losses. In other words, > a >> layered codec will see losses/marks to packets sent on all layers, and > >> will then need to figure out whether to strip off a layer or not in >> response to whatever congestion level those losses/marks indicate. > > I definitely agree that the routers shouldn't know about codecs and this > is > why I was saying that IMO layered codecs aren't too useful for > congestion > control (though they have other uses). If there's nothing in the middle > of > the network to strip off the layers, then you might as well not have > layers > at all. All you need is to ask the sender to reduce the rate. You don't > need layers to have a multi-rate codec. Layering just means that you can > > strip off bits and still have the result sound OK. > >>> OK, I may be wrong here, but my understanding is that how much the > rate >>> should change depending on congestion is actually not that >>> codec-specific. >> >> It *can* be non-codec-specific, see DCCP for example. But quality will > >> suffer IMO. > > Well, we need to figure out the aspects that should be codec-specific > and > implement just those. Does anyone have a list of the issues codecs > should > be aware of? > >> Most Internet congestion control is based on *creating* losses/marks > to >> determine capacity. People have tried to create congestion control >> schemes that avoid causing losses (delay-based schemed, for example), >> but they are perceived to be more fragile. > > Yes, I can imagine the problem not being trivial at all. > >>> Once you figure this out, you >>> can just tell the codec to use that rate. >> >> It's not that easy, because rates in the Internet are never stable - > the >> rate computation is usually clocked by the RTT. You can obviously > dampen >> this somehow, but you can never say "now I have found a rate that I > can >> safely use forever." > > Oh, I never said we should set a rate forever. I was just saying that > you > can have one module that determines in real-time the best rate to use at > > that moment and then it tells the codec what to use. If it needs help > from > the codec, then we can define special functionality. > >>> On top of that, the codec may be >>> able to do a bit better by providing a "service" to the other layers. > On >>> example here (also included in the draft) is VBR, which means that > the >>> application specifies an average rate and the codec decides how to >>> vary the >>> rate to achieve that (subject to some rate control constraints). > Would >>> other such mechanisms be useful to deal with congestion? >> >> I'm not sure this would work, because congestion control will > basically >> change the VBR input parameter continuously. > > Changing the VBR parameters continuously is not a problem. VBR just > means > that you'd like to have an average of N kb/s for now, but you're OK if > there are variations from frame to frame. > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > ------------------------------------------------------------------------ > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > ------------------------------------------------------------------------ > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From jovass@adobe.com Mon Oct 26 14:32:57 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7628028C189 for ; Mon, 26 Oct 2009 14:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.143 X-Spam-Level: X-Spam-Status: No, score=-4.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1zo1CDH9QhU for ; Mon, 26 Oct 2009 14:32:42 -0700 (PDT) Received: from psmtp.com (exprod6ob113.obsmtp.com [64.18.1.30]) by core3.amsl.com (Postfix) with ESMTP id 3EA3328C2B1 for ; Mon, 26 Oct 2009 14:32:35 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKSuYVfVQI4mIgGjl/QzMOXPbzNvIV6eJq@postini.com; Mon, 26 Oct 2009 14:32:56 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9QLPRao029922; Mon, 26 Oct 2009 14:25:31 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n9QLWRY5017743; Mon, 26 Oct 2009 14:32:31 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Oct 2009 14:28:53 -0700 Received: from nambx03.corp.adobe.com ([10.8.189.93]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Mon, 26 Oct 2009 14:28:03 -0700 From: Jozsef Vass To: Slava Borilin , Stephan Wenger , Henry Sinnreich , Jean-Marc Valin , Lars Eggert Date: Mon, 26 Oct 2009 14:28:02 -0700 Thread-Topic: [codec] updated charter proposal Thread-Index: AcpTTTtwzT3KAN+CT6mRNtyh07YmBgDF/SdAAADCvbsABaP04AAAmBgAAAB6D5A= Message-ID: <0FEA137C08A9DF4781EEF745038C9694146B2D6DFD@nambx03.corp.adobe.com> References: <0FEA137C08A9DF4781EEF745038C9694146B2D6CD8@nambx03.corp.adobe.com> <0FEA137C08A9DF4781EEF745038C9694146B2D6DE4@nambx03.corp.adobe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DFDnambx03corpad_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:32:57 -0000 --_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DFDnambx03corpad_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, my link was stripped. As per speex documentation and my experience, = one of the features of speex is "Integration of narrowband and wideband usi= ng an embedded bit-stream" Jozsef ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Monday, October 26, 2009 2:14 PM To: Jozsef Vass; Stephan Wenger; Henry Sinnreich; Jean-Marc Valin; Lars Egg= ert Cc: codec@ietf.org Subject: RE: [codec] updated charter proposal Speex is not layered, isn't it? best regards, Slava Borilin ________________________________ From: Jozsef Vass [mailto:jovass@adobe.com] Sent: Tuesday, October 27, 2009 12:09 AM To: Stephan Wenger; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars E= ggert Cc: codec@ietf.org Subject: RE: [codec] updated charter proposal In rfc 3984 processing packets by mane has some clear benefits, e.g., disca= rding packets that the decoder would describe anyways (section 7.3), droppi= ng packets in case of congestion, etc. Here, we mostly talking about reducing packet size, and I am not sure how b= eneficial it is regarding the overall system. Consider speex. Quality level= six, wideband and narrowband encoder produces 52 bytes and 28 bytes of pay= load, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 by= tes. Since packet rate is the same, I do not think it will affect congestio= n too much. Please also consider that processing packets by intermediary, a= dds additional delay. Jozsef ________________________________ From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Monday, October 26, 2009 11:15 AM To: Jozsef Vass; Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Egge= rt Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal I think that we have a terminology problem here. Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is th= ey don't modify IP packets. Boxes that look deep into the IP packets, and = (potentially) modify them, are higher layer devices. After long discussion= s in AVT at the time, RFC 3984 and its successors call those boxes "Media A= ware Network Elements", MANEs. MANEs modify packets at the application lay= er, for example to remove layers, re-package H.264 NAL units to adapt to di= fferent MTU sizes, and do all kinds of other things that violate the end-to= -end principle. A MANE has business in looking into, and potentially modif= ying, IP/UDP/RTP packets, a router has not. When MANEs are in the picture, it's IMO totally acceptable (from both an ab= stract layering theory viewpoint and in practice) that packets are being op= ened and the content is repackaged. It's actually common practice. Stephan On 10/26/09 10:55 AM, "Jozsef Vass" wrote: I do not like the idea of sending multiple layers in a packet either. I fee= l very uncomfortable of routers modifying packets. It is OK not to deliver,= but delivering semantically modified packet is not expected. Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets. Jozsef ________________________________ From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Thursday, October 22, 2009 12:23 PM To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Again - my point is that router does NOT have to know that something specif= ically is the codec, or specific codec- the only goal is to let router awar= e that the stream (and every packet) is LAYERED, and that it is legitimate = to strip out some layers if necessary due to congestion. The content of such "layered" can be any - voice codec, video codec, audio = codec, any type of content. And I agree with Gregory - that having current infrastructure using layers = in separate streams will require too much overhead (packets) which does not= make sense as well - and I am thinking about one stream of packets comtain= ing all the layers, which, however, can be modified on the fly "in the midd= le". So we may think about more generic concept of "declared layered content" wh= ich does NOT loose the information (well, most of it) by stripping out port= ions of the packet and reducing the traffic, so router can strip out any ty= pe of layered content, without going deep into specific codec. Again- this is "na=EFve" suggestions from me (very limited engineer) - and = definitely I am looking for objections even more then for agreement - for t= he sake of either finding the idea useful or making judged deny of it, and = I agree that this concept is only one possible way of working with congesti= on. best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of S= lava Borilin Sent: Thursday, October 22, 2009 11:13 PM To: Henry Sinnreich; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Henry, With all of my respect (you know) - this is too high-level consideration an= d too generic statement which doesn't answer MPLS issue for example. best regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Thursday, October 22, 2009 11:10 PM To: Slava Borilin; Jean-Marc Valin; Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Slava, >I am not that sure that routers should not be aware of the codecs. Why? >If we are building MPLS and other systems that is content-dependent, why >not let router understand the codec? The essence of the Dumb Network (Internet) and its routers is that it knows= nothing about the applications. All applications that nobody planned for can run over it. The tragedy of the telephone network was is knew everything about its only = one application. Henry On 10/22/09 1:23 PM, "Slava Borilin" wrote: I am not that sure that routers should not be aware of the codecs. Why? If we are building MPLS and other systems that is content-dependent, why not let router understand the codec? Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why not to leave this freedom to router as this may be more efficient for congestion recovery? Same applies to H.264SVC for example - at the end of the day, router do not need to understand anything except that it is LAYERED streams (even don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order to prevent congestion? best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent: Thursday, October 22, 2009 5:45 PM To: Lars Eggert Cc: codec@ietf.org Subject: Re: [codec] updated charter proposal Lars Eggert wrote: > Also, what we've learned from media over DCCP is that if you don't > involve the codec in some form, performance/quality will be bad. Some > codecs need time to adjust the rate. Some can only adjust it in pretty > coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP > friendliness, but maybe quality will suffer. I'm totally in favour of "involving the codec" in here. I just want to be careful not to include in the codec things that don't belong there (e.g. a DCCP implementation or a whole jitter buffer). > (And there is always the ramping up part - congestion control will never > attempt to probe for more capacity unless the codec generates more data, > and why would the codec do that if it's converged to transmit at some > lower rate.) Well, the codec transmits at the rate you ask it to use. If you want to probe for more capacity, then you tell the codec that it can use a higher rate. Now, if there's a special way in which you want to ask the codec, then maybe that can become an additional feature for the codec. > By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP > packets to react appropriately to the marks or losses. In other words, a > layered codec will see losses/marks to packets sent on all layers, and > will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate. I definitely agree that the routers shouldn't know about codecs and this is why I was saying that IMO layered codecs aren't too useful for congestion control (though they have other uses). If there's nothing in the middle of the network to strip off the layers, then you might as well not have layers at all. All you need is to ask the sender to reduce the rate. You don't need layers to have a multi-rate codec. Layering just means that you can strip off bits and still have the result sound OK. >> OK, I may be wrong here, but my understanding is that how much the rate >> should change depending on congestion is actually not that >> codec-specific. > > It *can* be non-codec-specific, see DCCP for example. But quality will > suffer IMO. Well, we need to figure out the aspects that should be codec-specific and implement just those. Does anyone have a list of the issues codecs should be aware of? > Most Internet congestion control is based on *creating* losses/marks to > determine capacity. People have tried to create congestion control > schemes that avoid causing losses (delay-based schemed, for example), > but they are perceived to be more fragile. Yes, I can imagine the problem not being trivial at all. >> Once you figure this out, you >> can just tell the codec to use that rate. > > It's not that easy, because rates in the Internet are never stable - the > rate computation is usually clocked by the RTT. You can obviously dampen > this somehow, but you can never say "now I have found a rate that I can > safely use forever." Oh, I never said we should set a rate forever. I was just saying that you can have one module that determines in real-time the best rate to use at that moment and then it tells the codec what to use. If it needs help from the codec, then we can define special functionality. >> On top of that, the codec may be >> able to do a bit better by providing a "service" to the other layers. On >> example here (also included in the draft) is VBR, which means that the >> application specifies an average rate and the codec decides how to >> vary the >> rate to achieve that (subject to some rate control constraints). Would >> other such mechanisms be useful to deal with congestion? > > I'm not sure this would work, because congestion control will basically > change the VBR input parameter continuously. Changing the VBR parameters continuously is not a problem. VBR just means that you'd like to have an average of N kb/s for now, but you're OK if there are variations from frame to frame. Jean-Marc _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DFDnambx03corpad_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] updated charter proposal

Sorry, my link was stripped. As per sp= eex documentation and my experience, one of the features of speex is “Integration of narrowband and wideband using an emb= edded bit-stream”

 

Jozsef<= /font>

 

From: Slava Bo= rilin [mailto:Borilin@spiritdsp.com]
Sent: Monday, October 26, 20= 09 2:14 PM
To: Jozsef Vass; Stephan Wen= ger; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: RE: [codec] updated charter proposal

 

Speex is not layered, isn’t it?<= o:p>

 

best regards,=

Slava Borilin

From: Jozsef V= ass [mailto:jovass@adobe.com]
Sent: Tuesday, October 27, 2= 009 12:09 AM
To: Stephan Wenger; Slava Bo= rilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: RE: [codec] updated charter proposal

 

In rfc 3984 processing packets by mane= has some clear benefits, e.g., discarding packets that the decoder would descri= be anyways (section 7.3), dropping packets in case of congestion, etc.

 

Here, we mostly talking about reducing packet size, and I am not sure how beneficial it is regarding the overall system. Consider speex. Quality level six, wideband and narrowband encoder produces 52 bytes and 28 bytes of payload, respectively. Adding IP/UDP/RTP header, you go from 92 bytes to 68 bytes. Since packet rate is the same, I = do not think it will affect congestion too much. Please also consider that processing packets by intermediary, adds additional delay.

 

Jozsef

 

From: Stephan = Wenger [mailto:stewe@stewe.org]
Sent: Monday, October 26, 20= 09 11:15 AM
To: Jozsef Vass; Slava Boril= in; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

 

I think that we have a termi= nology problem here.

Routers are AFAIK devices that route packets at ISO/OSI layer 3; that is th= ey don’t modify IP packets.  Boxes that look deep into the IP packe= ts, and (potentially) modify them, are higher layer devices.  After long discussions in AVT at the time, RFC 3984 and its successors call those boxe= s “Media Aware Network Elements”, MANEs.  MANEs modify packe= ts at the application layer, for example to remove layers, re-package H.264 NAL units= to adapt to different MTU sizes, and do all kinds of other things that violate= the end-to-end principle.  A MANE has business in looking into, and potentially modifying, IP/UDP/RTP packets, a router has not.

When MANEs are in the picture, it’s IMO totally acceptable (from both= an abstract layering theory viewpoint and in practice) that packets are being opened and the content is repackaged.  It’s actually common prac= tice.

Stephan

On 10/26/09 10:55 AM, "Jozsef Vass" <jovass@adobe.com> wrote:

I do not like the idea of sending mult= iple layers in a packet either. I feel very uncomfortable of routers modifying packets. It is OK not to deliver, but delivering semantically modified pack= et is not expected.
 
Using layers for video totally makes sense where the rates are much higher = and layers can be transported in separate packets.
 
Jozsef
 

From: Slava Borilin [mailto:Borilin@spiritdsp.com] Sent: Thursday, October 22, = 2009 12:23 PM
To: Slava Borilin; Henry Sinnreich; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Again - my point is that router does NOT have to know tha= t something specifically is the codec, or specific codec- the only goal is to let route= r aware that the stream (and every packet) is LAYERED, and that it is legitim= ate to strip out some layers if necessary due to congestion.
The content of such “layered” can be any – voice codec, v= ideo codec, audio codec, any type of content.
 
And I agree with Gregory – that having current infrastructure using l= ayers in separate streams will require too much overhead (packets) which does not ma= ke sense as well – and I am thinking about one stream of packets comtain= ing all the layers, which, however, can be modified on the fly “in the middle= ”.
So we may think about more generic concept of “declared layered conte= nt” which does NOT loose the information (well, most of it) by stripping out portions= of the packet and reducing the traffic, so router can strip out any type of layered content, without going deep into specific codec.
 
Again- this is “na=EFve” suggestions from me (very limited engi= neer) – and definitely I am looking for objections even more then for agreement –= for the sake of either finding the idea useful or making judged deny of it, and I a= gree that this concept is only one possible way of working with congestion.
 

best regards,
Slava Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Slava Borilin
Sent: Thursday, October 22, = 2009 11:13 PM
To: Henry Sinnreich; Jean-Ma= rc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Henry,
With all of my respect (you know) – this is too high-level considerat= ion and too generic statement which doesn’t answer MPLS issue for example.  

best regards,
Slava Borilin

From:= = Henry Sinnreich [mailto:hsinnrei@adobe.com<= /a>]
Sent: Thursday, October 22, = 2009 11:10 PM
To: Slava Borilin; Jean-Marc Valin; Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Slava,

>I am not that sure that routers should not be aware of the codecs. Why?=
>If we are building MPLS and other systems that is content-dependent, wh= y
>not let router understand the codec?

The essence of the Dumb Network (Internet) and its routers is that it knows nothing about the applications.
All applications that nobody planned for can run over it.
The tragedy of the telephone network was is knew everything about its only = one application.

Henry


On 10/22/09 1:23 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
I am not that sure that routers should not be aware of the codecs. Why?
If we are building MPLS and other systems that is content-dependent, why not let router understand the codec?

Especially if we have hordes of voice channels going thru router, it can be too hard and too long to tell each sender to reduce the rate - why
not to leave this freedom to router as this may be more efficient for
congestion recovery?

Same applies to H.264SVC for example - at the end of the day, router do
not need to understand anything except that it is LAYERED streams (even
don't know whether its voice, video or audio or anything else of layered nature, and router "has the right" to strip out layers in certain order
to prevent congestion?

best regards,
Slava Borilin

-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] O= n Behalf
Of Jean-Marc Valin
Sent: Thursday, October 22, 2009 5:45 PM
To: Lars Eggert
Cc: codec@ietf.org
Subject: Re: [codec] updated charter proposal

Lars Eggert wrote:
> Also, what we've learned from media over DCCP is that if you don't
> involve the codec in some form, performance/quality will be bad. Some<= br> > codecs need time to adjust the rate. Some can only adjust it in pretty=

> coarse steps. Etc. If you let DCCP adjust the rate blindly, without > involving the codec in some form, you might get very good TCP
> friendliness, but maybe quality will suffer.

I'm totally in favour of "involving the codec" in here. I just wa= nt to
be
careful not to include in the codec things that don't belong there (e.g. a
DCCP implementation or a whole jitter buffer).

> (And there is always the ramping up part - congestion control will
never
> attempt to probe for more capacity unless the codec generates more
data,
> and why would the codec do that if it's converged to transmit at some<= br> > lower rate.)

Well, the codec transmits at the rate you ask it to use. If you want to
probe for more capacity, then you tell the codec that it can use a
higher
rate. Now, if there's a special way in which you want to ask the codec,
then maybe that can become an additional feature for the codec.

> By no means should routers have to understand codec formats! Routers > drop or mark IP packets. It is up to the application sending those IP<= br> > packets to react appropriately to the marks or losses. In other words,=
a
> layered codec will see losses/marks to packets sent on all layers, and=

> will then need to figure out whether to strip off a layer or not in > response to whatever congestion level those losses/marks indicate.

I definitely agree that the routers shouldn't know about codecs and this is
why I was saying that IMO layered codecs aren't too useful for
congestion
control (though they have other uses). If there's nothing in the middle
of
the network to strip off the layers, then you might as well not have
layers
at all. All you need is to ask the sender to reduce the rate. You don't
need layers to have a multi-rate codec. Layering just means that you can
strip off bits and still have the result sound OK.

>> OK, I may be wrong here, but my understanding is that how much the=
rate
>> should change depending on congestion is actually not that
>> codec-specific.
>
> It *can* be non-codec-specific, see DCCP for example. But quality will=

> suffer IMO.

Well, we need to figure out the aspects that should be codec-specific
and
implement just those. Does anyone have a list of the issues codecs
should
be aware of?

> Most Internet congestion control is based on *creating* losses/marks to
> determine capacity. People have tried to create congestion control
> schemes that avoid causing losses (delay-based schemed, for example),<= br> > but they are perceived to be more fragile.

Yes, I can imagine the problem not being trivial at all.

>> Once you figure this out, you
>> can just tell the codec to use that rate.
>
> It's not that easy, because rates in the Internet are never stable - the
> rate computation is usually clocked by the RTT. You can obviously
dampen
> this somehow, but you can never say "now I have found a rate that= I
can
> safely use forever."

Oh, I never said we should set a rate forever. I was just saying that
you
can have one module that determines in real-time the best rate to use at
that moment and then it tells the codec what to use. If it needs help
from
the codec, then we can define special functionality.

>> On top of that, the codec may be
>> able to do a bit better by providing a "service" to the other layers.
On
>> example here (also included in the draft) is VBR, which means that=
the
>> application specifies an average rate and the codec decides how to=
>> vary the
>> rate to achieve that (subject to some rate control constraints). Would
>> other such mechanisms be useful to deal with congestion?
>
> I'm not sure this would work, because congestion control will
basically
> change the VBR input parameter continuously.

Changing the VBR parameters continuously is not a problem. VBR just
means
that you'd like to have an average of N kb/s for now, but you're OK if
there are variations from frame to frame.

        Jean-Marc
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_0FEA137C08A9DF4781EEF745038C9694146B2D6DFDnambx03corpad_-- From bmschwar@fas.harvard.edu Mon Oct 26 14:48:42 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B551128C166 for ; Mon, 26 Oct 2009 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 ETS0iW0WDaTA for ; Mon, 26 Oct 2009 14:48:42 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by core3.amsl.com (Postfix) with ESMTP id 2046E28C19B for ; Mon, 26 Oct 2009 14:48:41 -0700 (PDT) Received: from [172.23.141.73] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 56E514D5B60; Mon, 26 Oct 2009 17:48:54 -0400 (EDT) Message-ID: <4AE61945.7000601@fas.harvard.edu> Date: Mon, 26 Oct 2009 17:48:53 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" Subject: Re: [codec] layered encoding X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:48:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Wenger wrote: > When operating in low delay environments (as it is the assumption here), I > agree that there is not much point in attempting to reduce the packet > count---doing so would increase delay and would presumably be unacceptable > to the application. If decreased packet count is necessary in order for my VoIP session to work on the connection I'm using, then of course I want my client to reduce the packet count. Increased delay is better than no connection. As is usual on the internet, graceful degradation is almost always preferable to terminating a session and throwing up a "WARNING: Latency guarantee could not be satisfied." > If you have thousands or millions of sessions > on the same fiber, dropping layers could be argued to make a difference. Again, you don't seem to be talking about the public internet. Even on a private network, I still don't see much of an argument for layering. The bitrate reduction could more easily be achieved at the encoder. Moreover, layered encoding is typically less efficient than "unlayered" encoding at any particular bitrate. The only sensible argument I'm aware of for layered streams is in heterogeneous multicast networks. We can revisit this issue if multicast ever becomes widely available on the public internet -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkrmGUUACgkQUJT6e6HFtqRhhACfZcf8Mc+wn3rbGSHK2b4wWds2 R7cAn01GMpWAPA7a1rbzqQ1MCJbXW2jR =3Uqa -----END PGP SIGNATURE----- From lars.eggert@nokia.com Tue Oct 27 03:57:44 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65BC3A687C for ; Tue, 27 Oct 2009 03:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 WTlLI9sbhQz1 for ; Tue, 27 Oct 2009 03:57:44 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id CDFD728C102 for ; Tue, 27 Oct 2009 03:57:43 -0700 (PDT) Received: from [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (lars.local [IPv6:2001:708:40:fff2:225:ff:fe45:eccf] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n9RAvohP080770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Oct 2009 12:57:51 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-48--839003450; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Tue, 27 Oct 2009 12:57:50 +0200 Message-Id: <314D5898-AD22-499B-B763-269799501BF9@nokia.com> References: To: codec@ietf.org X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [IPv6:2001:708:40:fff1::1]); Tue, 27 Oct 2009 12:57:51 +0200 (EET) Cc: draft-ietf-tsvwg-byte-pkt-congest@tools.ietf.org Subject: Re: [codec] updated charter proposal X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:57:44 -0000 --Apple-Mail-48--839003450 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Hi, On 2009-10-26, at 23:28, Stephan Wenger wrote: > I think that these arguments boil down to the discussion of =20 > measurement of congestion in the packet count domain or in the =20 > bitrate domain. I don=92t think there=92s a verdict yet which of the =20= > two are really important. It may very well depend on your viewpoint =20= > and on what your company makes money of. FYI, http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest =20 discusses byte vs. packet congestion in more detail. It talks about =20 the generic data transport case and not specifically media traffic =20 though. > When operating in low delay environments (as it is the assumption =20 > here), I agree that there is not much point in attempting to reduce =20= > the packet count---doing so would increase delay and would =20 > presumably be unacceptable to the application. Therefore, =20 > congestion friendliness, when congestion is measured in the packet =20 > count domain, seems to be independent from the codec =20 > characteristics; as long as the codec is optimized for low delay. > > However, if we start from the assumption that congestion is measured =20= > in the bitrate domain, then the ballgame is somewhat different. =20 > Yes, when we drop a layer from a hypothetical layered audio codec, =20 > we would not safe a lot of bits in absolute numbers, and yes, the =20 > percentage would be even more disappointing considering the =20 > packetization overhead. But still, we would reduce the overall =20 > bitrate. If you have thousands or millions of sessions on the same =20= > fiber, dropping layers could be argued to make a difference. Lars= --Apple-Mail-48--839003450 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTAyNzEwNTc1MVowIwYJKoZIhvcNAQkEMRYEFPGjexbFZDdYAGTnQm34byV/l4s3MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQClD8aKI2QLEB0xf9y6h/8eDSaz5neOEcpJHXvQf6C8u6WlJgq1Hd7A0HKXxB4TBsp1latm uQ6fEGDE/OhcdUFkYlTakBEJNn/LhVKA4rZ+7S4aHPqNmfv3Dy8EQw9fRzbrQSZHxLrKSGkr6Oln Y3yKN9xO/XvEv8ZkVs/Vr5NPzmFqgO82zyBhaNfa4t4by5gLTKdWebNRbf3wHc1aCklg+z5WTijL YGKFiRoJHZi2Q84zkEQCtQqKv+uswFZviAm5vpgPWBI5LTM43Q3qnKIkz9F0QRUYq3XaFO+gvIrW WKT4bCi55kYDPSBdwqvTAEHgPSaC4W0DlxI1HTB+CrhLAAAAAAAA --Apple-Mail-48--839003450-- From ron.even.tlv@gmail.com Tue Oct 27 08:18:54 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F095F3A69D1 for ; Tue, 27 Oct 2009 08:18:54 -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 hWiUvbzkpQOE for ; Tue, 27 Oct 2009 08:18:54 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 89F3B3A6986 for ; Tue, 27 Oct 2009 08:18:53 -0700 (PDT) Received: by bwz19 with SMTP id 19so314118bwz.28 for ; Tue, 27 Oct 2009 08:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:content-language :thread-index; bh=43J6S2vOMwSks0IBNwAC2a1+VaBXp4CWqdsUUd3f67Q=; b=wjEjcW/tpMG8fxg8YqvXgCh96migRMwNZet/yDDMPij4H2ztbTHOtazVRQNt0AxCBT Z5UX9sli3sOFxfWTcZ0xnKRT24qPiYo6sMjqdqKslWh2+I+steVj6/vqQ2DvV1CbRJMx BRrIYtFMyzuvTxKgsQ6UKUUGZRlsFXpwvHsI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :content-language:thread-index; b=l7vrJZ31xPvCdSlYr01ENhddBUaqo+e7IAhD3PJGmvsaczrFnDd2CtnuklKb/q4iQM QHlYfs5PDgtvkxGkljhyy7TwQd/DPM9p0F7lTfbzaeeY6USOeJhp7g8WZar9zcunixen N7QZdRrAd5a6Q9inMsMxIL2fVq0vSvE/QJYTo= Received: by 10.204.32.204 with SMTP id e12mr4350487bkd.51.1256656743688; Tue, 27 Oct 2009 08:19:03 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-118-177.red.bezeqint.net [79.183.118.177]) by mx.google.com with ESMTPS id 16sm19533bwz.11.2009.10.27.08.19.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 08:19:03 -0700 (PDT) From: "Roni Even" To: Date: Tue, 27 Oct 2009 17:14:42 +0200 Message-ID: <4ae70f67.101abc0a.415b.0327@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A1_01CA5728.FAA758A0" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcpXGDV/fhbyCSz5T6WwuFY4G6wmdg== Subject: [codec] Review of the proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:18:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01A1_01CA5728.FAA758A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I read the proposed charter and in general is a good start I still have some comments 1. In the deliverable section "Guidelines that define the work process of the group, using draft-valin-codec-guidelines as the basis for achieving consensus. This document shall be Informational." Does this mean that once the charter is approved we are also approving the mentioned ID as a WG document for guideline. Otherwise I think that the text should be "Guidelines that define the work process of the group. This document shall be Informational." 2. The same comment for the next section about requirements. I also think that if the requirement will include some metrics used to test the codec this draft should have Normative context and may be a standard track document 3. The last section of the deliverable "Specification of one or more codecs that meet the agreed-upon requirements," I think that if the proposed working group is going to define more than one codec, each codec should have his own requirement draft giving motivation and the specific requirement for having a different codec from the first proposed one that will be developed based on the requirement document from the previous section. I do not think that one set of requirement merit more than one codec. Thanks Roni Even _____ ------=_NextPart_000_01A1_01CA5728.FAA758A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I read the proposed charter and in general is a = good start I still have some comments

 

1.  In the deliverable section "Guidelines that define = the work process of the group, using draft-valin-codec-guidelines as the basis = for achieving consensus. This document shall be Informational." Does = this mean that once the charter is approved we are also approving the mentioned ID = as a WG document for guideline. Otherwise I think that the text should be =  "Guidelines that define the work process of the group. This document shall be Informational."

2.  The same comment for the next section about = requirements. I also think that if the requirement will include some metrics used to test the = codec this draft should have Normative context and may be a standard track = document

3.  The last section of the deliverable "Specification = of one or more codecs that meet the agreed-upon requirements," I think = that if the proposed working group is going to define more than one codec, each = codec should have his own requirement draft giving motivation and the specific = requirement for having a different codec from the first proposed one that will be = developed based on the requirement document from the previous section. I do not = think that one set of requirement merit more than one codec.

Thanks

Roni Even

 

------=_NextPart_000_01A1_01CA5728.FAA758A0-- From stpeter@stpeter.im Tue Oct 27 13:40:22 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995BA3A6998 for ; Tue, 27 Oct 2009 13:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 MSRaRPWmt5s0 for ; Tue, 27 Oct 2009 13:40:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5E8123A68C3 for ; Tue, 27 Oct 2009 13:40:21 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C4AC54008F; Tue, 27 Oct 2009 14:40:33 -0600 (MDT) Message-ID: <4AE75AC0.1090507@stpeter.im> Date: Tue, 27 Oct 2009 14:40:32 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Roni Even References: <4ae70f67.101abc0a.415b.0327@mx.google.com> In-Reply-To: <4ae70f67.101abc0a.415b.0327@mx.google.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Review of the proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:40:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/09 9:14 AM, Roni Even wrote: > Hi, > > I read the proposed charter and in general is a good start I still have > some comments > > 1. In the deliverable section "Guidelines that define the work process > of the group, using draft-valin-codec-guidelines as the basis for > achieving consensus. This document shall be Informational." Does this > mean that once the charter is approved we are also approving the > mentioned ID as a WG document for guideline. Otherwise I think that the > text should be "Guidelines that define the work process of the group. > This document shall be Informational." > > 2. The same comment for the next section about requirements. The charter is the WG's contract with the IESG. I think it is much better to show the IESG that the group has been actively working on both the guidelines and the requirements by pointing to specific I-Ds, especially because the major issue raised in Stockholm was the lack of clear guidelines and requirements. IMHO draft-valin-codec-guidelines and draft-valin-codec-requirements would form the basis of discussion by the WG (if formed), so yes I think the WG would adopt them as WG items, although I think that a final decision will be up to the WG if and when it is formed. > I also > think that if the requirement will include some metrics used to test the > codec this draft should have Normative context and may be a standard > track document Do you see that as a separate document or as part of the requirements document? > 3. The last section of the deliverable "Specification of one or more > codecs that meet the agreed-upon requirements," I think that if the > proposed working group is going to define more than one codec, each > codec should have his own requirement draft giving motivation and the > specific requirement for having a different codec from the first > proposed one that will be developed based on the requirement document > from the previous section. I do not think that one set of requirement > merit more than one codec. That seems unnecessarily complex. IMHO it would be simpler for the requirements document to define the requirements in as much detail as possible, while leaving some requirements flexible by specifying ranges of acceptable behavior or performance, dimensions that a particular codec could legitimately optimize for, etc. Then each codec spec would state the more particular requirements it has tried to meet, without writing a separate requirements document for each codec spec. That sounds like an awful lot of documents for very little benefit, but I think that these editorial issues aren't something that needs to be in the charter and can be worked out by the WG (if approved). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrnWsAACgkQNL8k5A2w/vzhegCgpZvE8dOdAfvWeERLi/VZY5rC 4/YAnisQQgAQXKrJARwBbufeJt4BioWZ =c5PQ -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Tue Oct 27 14:21:17 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D453A688D for ; Tue, 27 Oct 2009 14:21:17 -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 HlY5iTyVm2AG for ; Tue, 27 Oct 2009 14:21:16 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 182A83A67AA for ; Tue, 27 Oct 2009 14:21:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so111381fga.13 for ; Tue, 27 Oct 2009 14:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=A2r/cE7i7Y/XIhHurii7jJ6bpipKx3wga47Lj9O500s=; b=KKiVqsrdHwVk9gRI6sbA+9DXsoeKsg+BmTArVzov1C3b2lN+z+326JW/i9NMDFfKF7 6ABRdIW2jMA2TXqhSebJX/tR0oEIjUZSe4Rq5IPTebqYHmf/tbuSZSE1cElsKg3q7s4G NN2j/Fj0Zj49Wb9UdnrbRLL2+QtDeCY/2my7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; b=chDTMoJ03OQ9mvNex9/FXcfHKT9dsmFGk5htT2nqTdKjBuj2gCogDl+/SPJGDDJOl6 0bxm9E5pvgi56pxQKTsHrNSpwjeaJMkGyvDCFojBfLw8jmgKMZ8Q4b6pQrSxvvLu0wTJ ELe9o4HHIaD2Dm6lzqHC5LOzwOwAgPnrBq+v8= Received: by 10.87.38.23 with SMTP id q23mr1277494fgj.35.1256678487635; Tue, 27 Oct 2009 14:21:27 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-118-177.red.bezeqint.net [79.183.118.177]) by mx.google.com with ESMTPS id e11sm737764fga.7.2009.10.27.14.21.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 14:21:26 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre'" References: <4ae70f67.101abc0a.415b.0327@mx.google.com> <4AE75AC0.1090507@stpeter.im> In-Reply-To: <4AE75AC0.1090507@stpeter.im> Date: Tue, 27 Oct 2009 23:16:58 +0200 Message-ID: <4ae76456.0b38560a.2f84.ffffe77a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcpXRb0TM5MCYecETTWHY+RVg/uzqwAA57aA Cc: codec@ietf.org Subject: Re: [codec] Review of the proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 21:21:17 -0000 Hi Peter, I think that you can mention the documents to the IESG but they cannot = be part of the deliverable since they are ID that did not go yet through = any consensus. As for you response on multiple codec, it look to me that the group will = be a codec factory where anyone can define a codec based on part of the = requirements and still be inline with the charter. I find it strange = that you suggest that the group will develop requirements that do not = need to be fully answered by one codec and let everybody select part of = them and develop a codec. I am not aware that the IETF does two = competing solutions for the same requirement document. When the discussion on doing a codec in the IETF was started it was = about defining a codec for wideband audio that will be easily available = in order to help with deployment of wideband in Internet applications. = Doing multiple codecs will not answer this basic need of = interoperability. Regards Roni Even > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Tuesday, October 27, 2009 10:41 PM > To: Roni Even > Cc: codec@ietf.org > Subject: Re: [codec] Review of the proposed charter >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 10/27/09 9:14 AM, Roni Even wrote: > > Hi, > > > > I read the proposed charter and in general is a good start I still > have > > some comments > > > > 1. In the deliverable section "Guidelines that define the work > process > > of the group, using draft-valin-codec-guidelines as the basis for > > achieving consensus. This document shall be Informational." Does = this > > mean that once the charter is approved we are also approving the > > mentioned ID as a WG document for guideline. Otherwise I think that > the > > text should be "Guidelines that define the work process of the > group. > > This document shall be Informational." > > > > 2. The same comment for the next section about requirements. >=20 > The charter is the WG's contract with the IESG. I think it is much > better to show the IESG that the group has been actively working on > both > the guidelines and the requirements by pointing to specific I-Ds, > especially because the major issue raised in Stockholm was the lack of > clear guidelines and requirements. IMHO draft-valin-codec-guidelines > and > draft-valin-codec-requirements would form the basis of discussion by > the > WG (if formed), so yes I think the WG would adopt them as WG items, > although I think that a final decision will be up to the WG if and = when > it is formed. >=20 > > I also > > think that if the requirement will include some metrics used to test > the > > codec this draft should have Normative context and may be a standard > > track document >=20 > Do you see that as a separate document or as part of the requirements > document? >=20 > > 3. The last section of the deliverable "Specification of one or = more > > codecs that meet the agreed-upon requirements," I think that if the > > proposed working group is going to define more than one codec, each > > codec should have his own requirement draft giving motivation and = the > > specific requirement for having a different codec from the first > > proposed one that will be developed based on the requirement = document > > from the previous section. I do not think that one set of = requirement > > merit more than one codec. >=20 > That seems unnecessarily complex. IMHO it would be simpler for the > requirements document to define the requirements in as much detail as > possible, while leaving some requirements flexible by specifying = ranges > of acceptable behavior or performance, dimensions that a particular > codec could legitimately optimize for, etc. Then each codec spec would > state the more particular requirements it has tried to meet, without > writing a separate requirements document for each codec spec. That > sounds like an awful lot of documents for very little benefit, but I > think that these editorial issues aren't something that needs to be in > the charter and can be worked out by the WG (if approved). >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkrnWsAACgkQNL8k5A2w/vzhegCgpZvE8dOdAfvWeERLi/VZY5rC > 4/YAnisQQgAQXKrJARwBbufeJt4BioWZ > =3Dc5PQ > -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Oct 27 15:11:44 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78CF53A6A59 for ; Tue, 27 Oct 2009 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 Zs6m9bdPVkgH for ; Tue, 27 Oct 2009 15:11:43 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7BFC83A6A61 for ; Tue, 27 Oct 2009 15:11:43 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A132B4008F; Tue, 27 Oct 2009 16:11:57 -0600 (MDT) Message-ID: <4AE7702C.9020907@stpeter.im> Date: Tue, 27 Oct 2009 16:11:56 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Roni Even References: <4ae70f67.101abc0a.415b.0327@mx.google.com> <4AE75AC0.1090507@stpeter.im> <4ae76456.0b38560a.2f84.ffffe77a@mx.google.com> In-Reply-To: <4ae76456.0b38560a.2f84.ffffe77a@mx.google.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Review of the proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:11:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/09 3:16 PM, Roni Even wrote: > Hi Peter, I think that you can mention the documents to the IESG but > they cannot be part of the deliverable since they are ID that did not > go yet through any consensus. I freely grant that consensus has not yet been reached regarding the guidelines and requirements I-Ds, but to expect consensus before a WG has even been formed is a novel interpretation of the Internet Standards Process! The proposed charter states that these I-Ds will form the basis for discussion within the WG, hopefully leading to eventual consensus, WGLC, and IETF Last Call. That is the normal process for discussion within the IETF. Do you suggest that consensus should be reached (and by whom?) before a charter can even mention an I-D as the basis for further discussion and refinement? And on what basis could such consensus be reached, given that a WG has not even been formed yet? This is a Catch-22 and would prevent the formation of any WG, unless you suggest a process by which IETF LC would be necessary for WG formation. > As for you response on multiple codec, it look to me that the group > will be a codec factory where anyone can define a codec based on part > of the requirements and still be inline with the charter. The proposed charter states: ### The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor to produce as few codecs as possible, and in any case shall not function as a "codec factory" that produces a large number of codecs. ### That clearly states the preference of the group to NOT be a codec factory. > I find it > strange that you suggest that the group will develop requirements > that do not need to be fully answered by one codec and let everybody > select part of them and develop a codec. What I am suggesting is a conceptual approach. Let me provide an example. The requirements document as it stands today states that the operating space includes medium delay (20-30 ms) applications from narrowband (8 kb/s to 16 kb/s) to full band (32 to 80 kb/s) and very low delay (< 10 ms) applications from super wideband (32 to 80 kb/s) to full band (48 to 128 kb/s). The requirements document does not say that we must produce "one codec to bind them all" -- one codec that will work optimally for everything from medium delay + narrowband to very low delay + full band. Yes, that would be great, but perhaps it is not possible. IMHO we might produce two codecs, one that is optimized for certain parts of the operating space and another that is optimized for oher parts of the operating space. To say that the WG must produce one and only codec for all parts of the operating space implies that the WG would need to ignore facts the group might discover as it tries to solve the problem. > I am not aware that the IETF > does two competing solutions for the same requirement document. RFC 2779 defined requirements that have been met by both the XMPP WG and the SIMPLE WG. However, in the codec space the solutions would not be competing, they would be complementary because they would be optimized for different aspects of the operating space. Would it help to add some text to the effect that, if the WG finds that it must produce multiple codecs, it would try to produce codecs that are complementary instead of competing? > When the discussion on doing a codec in the IETF was started it was > about defining a codec for wideband audio that will be easily > available in order to help with deployment of wideband in Internet > applications. Doing multiple codecs will not answer this basic need > of interoperability. The world seems to contain dozens or hundreds of codecs that are optimized for different aspects of media encoding and communication. In fact other SDOs have produced many, many codecs without, it seems, doing permanent damage to the Internet. Yes, ideally an IETF Codec WG would produce one codec to bind them all, but to require that in the charter seems quite unhelpful to me because it would unnecessarily restrict the WG from finding optimal solutions. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrncCwACgkQNL8k5A2w/vxL2ACg8iD4C3BKNzK+kHmzjaeCoyTl yJgAoLOfAXFjssTd0hg6wtj9zfss3KSF =Kmdh -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Oct 28 09:34:11 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796EE28C1DC for ; Wed, 28 Oct 2009 09:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN0EkZ4C1yxy for ; Wed, 28 Oct 2009 09:34:10 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7DC9B3A6977 for ; Wed, 28 Oct 2009 09:34:10 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 60AA14011B; Wed, 28 Oct 2009 10:34:23 -0600 (MDT) Message-ID: <4AE8728E.4070504@stpeter.im> Date: Wed, 28 Oct 2009 10:34:22 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Roni Even References: <4ae70f67.101abc0a.415b.0327@mx.google.com> <4AE75AC0.1090507@stpeter.im> <4ae76456.0b38560a.2f84.ffffe77a@mx.google.com> <4AE7702C.9020907@stpeter.im> In-Reply-To: <4AE7702C.9020907@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Review of the proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:34:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/09 4:11 PM, Peter Saint-Andre wrote: > On 10/27/09 3:16 PM, Roni Even wrote: >> Hi Peter, I think that you can mention the documents to the IESG but >> they cannot be part of the deliverable since they are ID that did not >> go yet through any consensus. > > I freely grant that consensus has not yet been reached regarding the > guidelines and requirements I-Ds, but to expect consensus before a WG > has even been formed is a novel interpretation of the Internet Standards > Process! The proposed charter states that these I-Ds will form the basis > for discussion within the WG, hopefully leading to eventual consensus, > WGLC, and IETF Last Call. That is the normal process for discussion > within the IETF. Do you suggest that consensus should be reached (and by > whom?) before a charter can even mention an I-D as the basis for further > discussion and refinement? And on what basis could such consensus be > reached, given that a WG has not even been formed yet? This is a > Catch-22 and would prevent the formation of any WG, unless you suggest a > process by which IETF LC would be necessary for WG formation. Hi Roni, I'm sorry, I misunderstood your point. We mention the existing I-Ds in two places. In the "Objectives" section we say: ### Work processes and technical requirements for achieving the foregoing objectives are outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and will be refined by the group in accordance with the usual IETF procedures. ### And in the "Deliverables" section we say: ### 1. Guidelines that define the work process of the group, using draft-valin-codec-guidelines as the starting point for working toward consensus. This document shall be Informational. 2. Detailed technical requirements, using draft-valin-codec-requirements as the starting point for working toward consensus. This document shall be Informational. ### I thought you wanted to remove these mentions in both places. I think you're right that the "Deliverables" section would be better without mentioning specific drafts, because the WG needs to officially accept I-Ds as WG items. So I think the "Deliverables" section needs to say: ### 1. Guidelines that define the work process of the group. This document shall be Informational. 2. Detailed technical requirements. This document shall be Informational. ### My apologies for the misunderstanding. Do you think it is acceptable to mention these I-Ds earlier in the charter text? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkroco0ACgkQNL8k5A2w/vyNBwCfemx1ZqexcTkv4JJBMPqiJh4x GaEAnikpDFIYfYudGyvAPOkLwW5vpICd =owS6 -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Oct 28 13:11:34 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414423A6A63 for ; Wed, 28 Oct 2009 13:11:34 -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 4zx5cgHw-Xsc for ; Wed, 28 Oct 2009 13:11:33 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CC1533A6992 for ; Wed, 28 Oct 2009 13:11:32 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9F93E4008F for ; Wed, 28 Oct 2009 14:11:47 -0600 (MDT) Message-ID: <4AE8A582.7000800@stpeter.im> Date: Wed, 28 Oct 2009 14:11:46 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] another charter update X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:11:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following text incorporates all feedback received to date. ### Proposed Charter for Codec WG Last Updated: 2009-10-28 Problem Statement There are no standardized, high-quality audio codecs that are optimized for use in interactive Internet applications and that can be widely implemented and easily distributed among application developers, service operators, and end users. This gap in the Internet protocol stack has hindered protocol designers from being able to specify mandatory-to-implement codecs in their protocols for the sake of interoperability, developers from building innovative, interactive applications, service operators from deploying affordable, high-quality services, and end users from enjoying an optimal user experience. Objectives The goal of this group is to develop one or more high-quality audio codecs that are optimized for use over the Internet and that can be widely implemented and easily distributed among application developers, service operators, and end users. Core technical considerations include but are not necessarily limited to the following: 1. Use in interactive applications (examples include but are not limited to point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the group 3. Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signalling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, the result should not depend on the details of any particular signalling technology Codecs optimized for very low bit rates (typically below 2.4 kbps) and codecs for non-interactive audio are out of scope because they might necessitate specialized optimizations. Although the codec(s) produced by the group might be used as mandatory-to-implement technologies by designers of particular Internet protocols, it is explicitly not a goal of the group to produce a codec that will be mandated for use across the entire IETF or Internet community. The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor to produce as few codecs as possible, and in any case shall not function as a "codec factory" that produces a large number of codecs. In completing its work, the group should collaborate with other IETF working groups to complete particular tasks. These might include but would not be limited to the following: - - Within the AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP). - - Collaborate with working groups in the Transport area to identify important aspects of packet transmission over the Internet. - - Collaborate with working groups in the Transport area to understand the degree of rate adaptation desirable, and to reflect that understanding in the design of a codec that can adjust its transmission in a way that minimizes disruption to the audio. - - Collaborate with working groups in the RAI area to ensure that information about and negotiation of the codec can be easily represented at the signalling layer. Work processes and technical requirements for achieving the foregoing objectives are outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and will be refined by the group in accordance with the usual IETF procedures. The group would prefer to produce a codec that can be widely implemented and easily distributed among application developers, service operators, and end users. This is important because many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality audio codecs across the entire Internet community, the group shall prefer unencumbered technologies in a way that is consistent with BCP 78 and BCP 79. In particular, the group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Although this preference cannot guarantee that the group will produce an unencumbered codec, the group shall attempt to adhere to the spirit of BCP 79. This preference does not explicitly rule out the possibility of adapting encumbered technologies; such decisions will be made in accordance with the rough consensus of the group. Deliverables 1. Guidelines that define the work process of the group. This document shall be Informational. 2. Detailed technical requirements. This document shall be Informational. 3. Specification of one or more codecs that meet the agreed-upon requirements, in the form of Internet-Drafts that define the codec algorithm and source code for a reference implementation, as well as any specific technical requirements for which the codec has been optimized. The text description of each codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that each such specification shall be a Proposed Standard document. Milestones Mar-2010: WGLC on Codec Standardization Guidelines May-2010: Codec Standardization Guidelines to IESG (Informational) May-2010: WGLC on Requirements Jul-2010: Requirements to IESG (Infomational) Mar-2011: WGLC on codec specification(s) Jun-2011: Submit codec specification(s) to IESG (Standards Track) ### -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkropYIACgkQNL8k5A2w/vwEAACg65aCM/Cv+nRFXulVRDNatbHK XwQAoKJd1DbCaH07vNyY4MgXV+J2fNau =1yDw -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Wed Oct 28 14:04:49 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757B028C118 for ; Wed, 28 Oct 2009 14:04:49 -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 HW-tY1mgvMwW for ; Wed, 28 Oct 2009 14:04:48 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 1E0B53A6989 for ; Wed, 28 Oct 2009 14:04:47 -0700 (PDT) Received: by ewy4 with SMTP id 4so1183066ewy.37 for ; Wed, 28 Oct 2009 14:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=xYnQEN/Wt4lgmMbDyFAHgjurAlCu8dAWPm81Y50la0M=; b=br5mKgrvIlBcD7ni5mgpZcp8LX8afUsEjylILtBxFbU0RRw6FxgwGVkiRCbIEMBfYp CAf739rE0MDLiwS0gD8lXUEV5xiG/d+BI8hw8wCbJNfXroNXtdapiuUg1WHc/KqPyOKX UIFoqty+4PnucNgOJhFPWnKeg3oZhR0V9Rc2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; b=RA4HPZ8fGBbIqyXKarJiFMRDWhGrSb38AB6JwaWUCwR8D4gUuDb/SvsbU3+cgnSEXS rTBOiBCzGatFxZ4/6IPgIxv9dVvuT+mI1OoyrZdaIBgPj09nZXGQA6tkK92+30O6SO46 GAwhTEUHU2o3QGUtv42VX5zducogc1azsyuOw= Received: by 10.103.48.19 with SMTP id a19mr4003766muk.136.1256763899725; Wed, 28 Oct 2009 14:04:59 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-118-177.red.bezeqint.net [79.183.118.177]) by mx.google.com with ESMTPS id y2sm1448247mug.49.2009.10.28.14.04.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 28 Oct 2009 14:04:57 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre'" References: <4ae70f67.101abc0a.415b.0327@mx.google.com> <4AE75AC0.1090507@stpeter.im> <4ae76456.0b38560a.2f84.ffffe77a@mx.google.com> <4AE7702C.9020907@stpeter.im> <4AE8728E.4070504@stpeter.im> In-Reply-To: <4AE8728E.4070504@stpeter.im> Date: Wed, 28 Oct 2009 23:00:31 +0200 Message-ID: <4ae8b1f9.02e2660a.0ba8.ffffed89@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcpX7INJEj1uwkj8SnyY7IJCU9kCIgAJBzKQ Cc: codec@ietf.org Subject: Re: [codec] Review of the proposed charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:04:49 -0000 Peter, Thanks, I am trying to be helpful and this was exactly my meaning on the = first two items in the deliverables section. As for the objective I think it is acceptable to mention documents, it = just need to be clear that they are not yet based on full consensus as = can be seen on the mailing list and that there may be other requirement = documents. The only point I still feel is open is about how to decide which = proposed codecs are within the charter of the group. Having it too open = as it is now, will not help you with IESG, but this is my personal view = based on my experience with my WG charter. Roni Even > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Wednesday, October 28, 2009 6:34 PM > To: Roni Even > Cc: codec@ietf.org > Subject: Re: [codec] Review of the proposed charter >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 10/27/09 4:11 PM, Peter Saint-Andre wrote: > > On 10/27/09 3:16 PM, Roni Even wrote: > >> Hi Peter, I think that you can mention the documents to the IESG = but > >> they cannot be part of the deliverable since they are ID that did > not > >> go yet through any consensus. > > > > I freely grant that consensus has not yet been reached regarding the > > guidelines and requirements I-Ds, but to expect consensus before a = WG > > has even been formed is a novel interpretation of the Internet > Standards > > Process! The proposed charter states that these I-Ds will form the > basis > > for discussion within the WG, hopefully leading to eventual > consensus, > > WGLC, and IETF Last Call. That is the normal process for discussion > > within the IETF. Do you suggest that consensus should be reached = (and > by > > whom?) before a charter can even mention an I-D as the basis for > further > > discussion and refinement? And on what basis could such consensus be > > reached, given that a WG has not even been formed yet? This is a > > Catch-22 and would prevent the formation of any WG, unless you > suggest a > > process by which IETF LC would be necessary for WG formation. >=20 > Hi Roni, >=20 > I'm sorry, I misunderstood your point. We mention the existing I-Ds in > two places. In the "Objectives" section we say: >=20 > ### >=20 > Work processes and technical requirements for achieving the foregoing > objectives are outlined in draft-valin-codec-guidelines and > draft-valin-codec-requirements respectively; these documents will form > the starting point for working toward consensus and will be refined by > the group in accordance with the usual IETF procedures. >=20 > ### >=20 > And in the "Deliverables" section we say: >=20 > ### >=20 > 1. Guidelines that define the work process of the group, using > draft-valin-codec-guidelines as the starting point for working toward > consensus. This document shall be Informational. >=20 > 2. Detailed technical requirements, using draft-valin-codec- > requirements > as the starting point for working toward consensus. This document > shall be Informational. >=20 > ### >=20 > I thought you wanted to remove these mentions in both places. I think > you're right that the "Deliverables" section would be better without > mentioning specific drafts, because the WG needs to officially accept > I-Ds as WG items. So I think the "Deliverables" section needs to say: >=20 > ### >=20 > 1. Guidelines that define the work process of the group. This > document shall be Informational. >=20 > 2. Detailed technical requirements. This document shall be > Informational. >=20 > ### >=20 > My apologies for the misunderstanding. >=20 > Do you think it is acceptable to mention these I-Ds earlier in the > charter text? >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkroco0ACgkQNL8k5A2w/vyNBwCfemx1ZqexcTkv4JJBMPqiJh4x > GaEAnikpDFIYfYudGyvAPOkLwW5vpICd > =3DowS6 > -----END PGP SIGNATURE----- From mknappe@juniper.net Thu Oct 29 11:09:06 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B573A6835 for ; Thu, 29 Oct 2009 11:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWDmzUVZZq3K for ; Thu, 29 Oct 2009 11:09:04 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 8FB893A67E2 for ; Thu, 29 Oct 2009 11:09:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSunaT6QYaTNkDG2MirOvMBaQ1cWaoG+I@postini.com; Thu, 29 Oct 2009 11:09:21 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 29 Oct 2009 11:06:29 -0700 From: Michael Knappe To: Peter Saint-Andre , "codec@ietf.org" Date: Thu, 29 Oct 2009 11:06:58 -0700 Thread-Topic: [codec] another charter update Thread-Index: AcpYCuiXmJONniU0Q+uYbKn7MpNpigAt7JdU Message-ID: In-Reply-To: <4AE8A582.7000800@stpeter.im> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] another charter update X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:09:06 -0000 Catching up on the charter discussion, please disregard if content below ha= s already been covered... Scoping for potentially more than one candidate codec is a real strength of= the proposed charter, and will help avoid many potential process pitfalls,= but it does open up challenges. Given the often differing or differently prioritized requirements for each = class of interactive audio application, a one-size-fits-all set of criteria= is most likely intractable. As we move further with this selection process= , it may be helpful to set up selection 'gates' that begin with meeting a c= ommon set of basic and relatively high level criteria, followed by subseque= nt more narrow gates with stricter selection criteria dependent on the clas= s(es) of application targeted by the codec. These subsequent candidate sele= ction paths and gates would run in parallel as resources permit. This shoul= d allow concentration on the true merits of a particular codec, and not on = the relative importance of the application(s) it is best suited for. Thoughts? Mike On 10/28/09 1:11 PM, "Peter Saint-Andre" wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following text incorporates all feedback received to date. ### Proposed Charter for Codec WG Last Updated: 2009-10-28 Problem Statement There are no standardized, high-quality audio codecs that are optimized for use in interactive Internet applications and that can be widely implemented and easily distributed among application developers, service operators, and end users. This gap in the Internet protocol stack has hindered protocol designers from being able to specify mandatory-to-implement codecs in their protocols for the sake of interoperability, developers from building innovative, interactive applications, service operators from deploying affordable, high-quality services, and end users from enjoying an optimal user experience. Objectives The goal of this group is to develop one or more high-quality audio codecs that are optimized for use over the Internet and that can be widely implemented and easily distributed among application developers, service operators, and end users. Core technical considerations include but are not necessarily limited to the following: 1. Use in interactive applications (examples include but are not limited to point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the group 3. Ensuring interoperability with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signalling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, the result should not depend on the details of any particular signalling technology Codecs optimized for very low bit rates (typically below 2.4 kbps) and codecs for non-interactive audio are out of scope because they might necessitate specialized optimizations. Although the codec(s) produced by the group might be used as mandatory-to-implement technologies by designers of particular Internet protocols, it is explicitly not a goal of the group to produce a codec that will be mandated for use across the entire IETF or Internet community. The group might produce only one codec or it might produce multiple codecs; however, to reduce confusion in the marketplace it shall endeavor to produce as few codecs as possible, and in any case shall not function as a "codec factory" that produces a large number of codecs. In completing its work, the group should collaborate with other IETF working groups to complete particular tasks. These might include but would not be limited to the following: - - Within the AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP). - - Collaborate with working groups in the Transport area to identify important aspects of packet transmission over the Internet. - - Collaborate with working groups in the Transport area to understand the degree of rate adaptation desirable, and to reflect that understanding in the design of a codec that can adjust its transmission in a way that minimizes disruption to the audio. - - Collaborate with working groups in the RAI area to ensure that information about and negotiation of the codec can be easily represented at the signalling layer. Work processes and technical requirements for achieving the foregoing objectives are outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and will be refined by the group in accordance with the usual IETF procedures. The group would prefer to produce a codec that can be widely implemented and easily distributed among application developers, service operators, and end users. This is important because many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality audio codecs across the entire Internet community, the group shall prefer unencumbered technologies in a way that is consistent with BCP 78 and BCP 79. In particular, the group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Although this preference cannot guarantee that the group will produce an unencumbered codec, the group shall attempt to adhere to the spirit of BCP 79. This preference does not explicitly rule out the possibility of adapting encumbered technologies; such decisions will be made in accordance with the rough consensus of the group. Deliverables 1. Guidelines that define the work process of the group. This document shall be Informational. 2. Detailed technical requirements. This document shall be Informational. 3. Specification of one or more codecs that meet the agreed-upon requirements, in the form of Internet-Drafts that define the codec algorithm and source code for a reference implementation, as well as any specific technical requirements for which the codec has been optimized. The text description of each codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that each such specification shall be a Proposed Standard document. Milestones Mar-2010: WGLC on Codec Standardization Guidelines May-2010: Codec Standardization Guidelines to IESG (Informational) May-2010: WGLC on Requirements Jul-2010: Requirements to IESG (Infomational) Mar-2011: WGLC on codec specification(s) Jun-2011: Submit codec specification(s) to IESG (Standards Track) ### -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkropYIACgkQNL8k5A2w/vwEAACg65aCM/Cv+nRFXulVRDNatbHK XwQAoKJd1DbCaH07vNyY4MgXV+J2fNau =3D1yDw -----END PGP SIGNATURE----- _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From gregory.ietf@gmail.com Thu Oct 29 18:49:37 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C8A3A6904 for ; Thu, 29 Oct 2009 18:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, 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 y+UcDqba+Y39 for ; Thu, 29 Oct 2009 18:49:37 -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 C58E03A67A2 for ; Thu, 29 Oct 2009 18:49:36 -0700 (PDT) Received: by ywh13 with SMTP id 13so2592207ywh.29 for ; Thu, 29 Oct 2009 18:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:mime-version:content-type; bh=VVO73qMSsIIFBhAvVr/2hsShu6oa6z4+SW5zVCZGDMw=; b=eDxEme2NqNVNdUjf1P2RVZ3BsO+RlmHwrER2Bc/5+Vr1MhHGybh2KeLb8z1oF9jHij 2Ft9u0PjUK1o9vGS+p52EuSbCINj6SkEZ86gHQoASNJBYwkJfK5ccFCpQuHFJzWqH2aS A2WzFRJiKSJQcZQjqYUvla7j5pg/+Nfhe+4Vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:mime-version :content-type; b=XjWI0aYaiReDXGVlwNT+yui2eJCFTW9g6HiSw/mBcOBSwo4PuKEcgvKguE+ctPhSOP VEiQ0ASPepmo06IyfgKj14YG/l3lfcAj5WoZG6wnrW0+w0Zm67jEuey+wS8zMraeuCiJ gxtAmRdkp6C/zeqaznScn1fm1iUUA2dFqWShc= Received: by 10.91.203.1 with SMTP id f1mr2567482agq.55.1256867389162; Thu, 29 Oct 2009 18:49:49 -0700 (PDT) Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id 20sm1144257yxe.38.2009.10.29.18.49.47 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Oct 2009 18:49:48 -0700 (PDT) Message-ID: <4aea463c.1402be0a.1bc7.ffff8f8a@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Oct 2009 18:49:43 -0700 To: Peter Saint-Andre , Eric Burger From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_253476812==.ALT" Cc: codec@ietf.org Subject: [codec] Items to add to BoF page X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 01:49:37 -0000 --=====================_253476812==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Chairs, I believe that adding a few items to the BoF page at http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 would help tremendously for those looking for information on the upcoming CODEC BoF. Namely: - Add a paragraph of description. See as an example the KMART/KARP BoF listed just below the CODEC BoF - add links to the SILK and CELT drafts, and any other helpful reading material, be they drafts or not, that would show the work being done, for those not following the mail list - add a link to the mail list archive message from Cullen and me which summarized the first CODEC BoF at IETF75 - http://www.ietf.org/mail-archive/web/codec/current/msg00540.html I think that would help new-comers a lot, particularly knowing what already occurred, so they know where we will be picking up in Hiroshima. Hope it helps, Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m --=====================_253476812==.ALT Content-Type: text/html; charset="us-ascii" Chairs,
I believe that adding a few items to the BoF page at http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76  would help tremendously for those looking for information on the upcoming CODEC BoF. Namely:

 - Add a paragraph of description. See as an example the KMART/KARP BoF listed just below the CODEC BoF
 - add links to the SILK and CELT drafts, and any other helpful reading material, be they drafts or not, that would show the work being done, for those not following the mail list
 - add a link to the mail list archive message from Cullen and me which summarized the first CODEC BoF at IETF75 - http://www.ietf.org/mail-archive/web/codec/current/msg00540.html

I think that would help new-comers a lot, particularly knowing what already occurred, so they know where we will be picking up in Hiroshima.

Hope it helps,
Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m --=====================_253476812==.ALT-- From stpeter@stpeter.im Thu Oct 29 20:31:02 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4173A69AC for ; Thu, 29 Oct 2009 20:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[AWL=2.770, 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 OKV-Fj5dPBom for ; Thu, 29 Oct 2009 20:31:00 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 09A663A686A for ; Thu, 29 Oct 2009 20:31:00 -0700 (PDT) Received: from squire.local (dsl-228-69.dynamic-dsl.frii.net [216.17.228.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 699BA4008F; Thu, 29 Oct 2009 21:31:16 -0600 (MDT) Message-ID: <4AEA5E02.9030105@stpeter.im> Date: Thu, 29 Oct 2009 21:31:14 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <4aea463c.1402be0a.1bc7.ffff8f8a@mx.google.com> In-Reply-To: <4aea463c.1402be0a.1bc7.ffff8f8a@mx.google.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Items to add to BoF page X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 03:31:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 7:49 PM, Gregory M. Lebovitz wrote: > Chairs, > I believe that adding a few items to the BoF page at > http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 would help > tremendously for those looking for information on the upcoming CODEC > BoF. Namely: > > - Add a paragraph of description. See as an example the KMART/KARP BoF > listed just below the CODEC BoF > - add links to the SILK and CELT drafts, and any other helpful reading > material, be they drafts or not, that would show the work being done, > for those not following the mail list > - add a link to the mail list archive message from Cullen and me which > summarized the first CODEC BoF at IETF75 - > http://www.ietf.org/mail-archive/web/codec/current/msg00540.html > > I think that would help new-comers a lot, particularly knowing what > already occurred, so they know where we will be picking up in Hiroshima. Those are good points. I'll update the page tomorrow. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrqXgIACgkQNL8k5A2w/vy9YwCg+mkEn/luks5K74CmvYPUr7e0 48wAn2swbWIZM17CfWkuOwVmFwzrAk8X =fH35 -----END PGP SIGNATURE----- From Borilin@spiritdsp.com Fri Oct 30 03:41:36 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509563A6819 for ; Fri, 30 Oct 2009 03:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.741, 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 ojN5LvcfQj9M for ; Fri, 30 Oct 2009 03:41:35 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 979043A659B for ; Fri, 30 Oct 2009 03:41:32 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n9UAfhtl038160; Fri, 30 Oct 2009 13:41:44 +0300 (MSK) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA594D.8F0E868D" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 30 Oct 2009 13:41:35 +0300 Message-ID: In-Reply-To: <4aea463c.1402be0a.1bc7.ffff8f8a@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Items to add to BoF page Thread-Index: AcpZA00xFSYoUJ3wRgajNuLRVbdegAASbuIw References: <4aea463c.1402be0a.1bc7.ffff8f8a@mx.google.com> From: "Slava Borilin" To: "Gregory M. Lebovitz" , "Peter Saint-Andre" , "Eric Burger" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] Items to add to BoF page X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 10:41:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA594D.8F0E868D Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Please add link to IPMR draft as well - = http://tools.ietf.org/search/draft-spiritdsp-ipmr-00 =9A =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Gregory M. Lebovitz Sent: Friday, October 30, 2009 4:50 AM To: Peter Saint-Andre; Eric Burger Cc: codec@ietf.org Subject: [codec] Items to add to BoF page =20 Chairs, I believe that adding a few items to the BoF page at = http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 would help = tremendously for those looking for information on the upcoming CODEC = BoF. Namely: - Add a paragraph of description. See as an example the KMART/KARP BoF = listed just below the CODEC BoF - add links to the SILK and CELT drafts, and any other helpful reading = material, be they drafts or not, that would show the work being done, = for those not following the mail list - add a link to the mail list archive message from Cullen and me which = summarized the first CODEC BoF at IETF75 - = http://www.ietf.org/mail-archive/web/codec/current/msg00540.html=20 I think that would help new-comers a lot, particularly knowing what = already occurred, so they know where we will be picking up in Hiroshima. Hope it helps, Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m ------_=_NextPart_001_01CA594D.8F0E868D Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Please add link = to IPMR draft as well - http://tool= s.ietf.org/search/draft-spiritdsp-ipmr-00 =9A

 =

best = regards,

Slava = Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Gregory M. = Lebovitz
Sent: Friday, October 30, = 2009 4:50 AM
To: Peter Saint-Andre; = Eric Burger
Cc: codec@ietf.org
Subject: [codec] Items to = add to BoF page

 

Chairs,
I believe that adding a few items to the BoF page at http://trac.t= ools.ietf.org/bof/trac/wiki/BifIETF76  would help tremendously for those looking for information on the = upcoming CODEC BoF. Namely:

 - Add a paragraph of description. See as an example the KMART/KARP = BoF listed just below the CODEC BoF
 - add links to the SILK and CELT drafts, and any other helpful = reading material, be they drafts or not, that would show the work being done, = for those not following the mail list
 - add a link to the mail list archive message from Cullen and me = which summarized the first CODEC BoF at IETF75 - http://www.ietf.org/mail-archive/web/codec/current/msg00540.html

I think that would help new-comers a lot, particularly knowing what = already occurred, so they know where we will be picking up in Hiroshima.

Hope it helps,
Gregory.

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c = o  m

------_=_NextPart_001_01CA594D.8F0E868D-- From stpeter@stpeter.im Fri Oct 30 04:52:45 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DA0B3A68F0 for ; Fri, 30 Oct 2009 04:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=2.344, 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 W2ifWczkugeI for ; Fri, 30 Oct 2009 04:52:44 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C8D133A68A8 for ; Fri, 30 Oct 2009 04:52:44 -0700 (PDT) Received: from squire.local (dsl-228-69.dynamic-dsl.frii.net [216.17.228.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5EBAC4008F; Fri, 30 Oct 2009 05:53:01 -0600 (MDT) Message-ID: <4AEAD394.9020203@stpeter.im> Date: Fri, 30 Oct 2009 05:52:52 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Slava Borilin References: <4aea463c.1402be0a.1bc7.ffff8f8a@mx.google.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Items to add to BoF page X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 11:52:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/30/09 4:41 AM, Slava Borilin wrote: > Please add link to IPMR draft as well - > http://tools.ietf.org/search/draft-spiritdsp-ipmr-00 Will do. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrq05MACgkQNL8k5A2w/vwO9QCg4ks/ijxbTk2bIEPdbg537ALT +9oAoMs1Wb7s/w+u4XVivRnG7ScV9hue =n1j2 -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Oct 30 09:02:16 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC29328C0FE for ; Fri, 30 Oct 2009 09:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 roooFx9cPAWN for ; Fri, 30 Oct 2009 09:02:15 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DD2653A694C for ; Fri, 30 Oct 2009 09:02:15 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C1124008F; Fri, 30 Oct 2009 10:02:31 -0600 (MDT) Message-ID: <4AEB0E1A.2070901@stpeter.im> Date: Fri, 30 Oct 2009 10:02:34 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Gregory M. Lebovitz" References: <4aea463c.1402be0a.1bc7.ffff8f8a@mx.google.com> In-Reply-To: <4aea463c.1402be0a.1bc7.ffff8f8a@mx.google.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Items to add to BoF page X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:02:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 7:49 PM, Gregory M. Lebovitz wrote: > Chairs, > I believe that adding a few items to the BoF page at > http://trac.tools.ietf.org/bof/trac/wiki/BifIETF76 would help > tremendously for those looking for information on the upcoming CODEC > BoF. Namely: > > - Add a paragraph of description. See as an example the KMART/KARP BoF > listed just below the CODEC BoF > - add links to the SILK and CELT drafts, and any other helpful reading > material, be they drafts or not, that would show the work being done, > for those not following the mail list > - add a link to the mail list archive message from Cullen and me which > summarized the first CODEC BoF at IETF75 - > http://www.ietf.org/mail-archive/web/codec/current/msg00540.html > > I think that would help new-comers a lot, particularly knowing what > already occurred, so they know where we will be picking up in Hiroshima. Done. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrrDhoACgkQNL8k5A2w/vwDVgCgk9LZwO1m8IqNd4yLhzSD7Ifa BEwAmwW2BegA9hoQ1TTuS4b/L69oQtiJ =2GVR -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Oct 30 10:43:43 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84503A6979 for ; Fri, 30 Oct 2009 10:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 WeB6ZpB9gDSh for ; Fri, 30 Oct 2009 10:43:42 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A80283A6937 for ; Fri, 30 Oct 2009 10:43:42 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E98B84008F for ; Fri, 30 Oct 2009 11:43:59 -0600 (MDT) Message-ID: <4AEB25DE.7020602@stpeter.im> Date: Fri, 30 Oct 2009 11:43:58 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 17:43:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Burger and I have created a *draft* agenda for the Codec BoF. Feedback is welcome! ### 1. Note Well & Agenda Bashing (5 minutes) 2. Progress to Date (15 minutes) a. BoF at IETF 75 established constituency and interest b. Open issues: work process, requirements, ITU-T coordination c. Several individual drafts published and discussed on the list d. Coordination has occurred with ITU-T SG 16 e. Consensus converging around draft charter 3. Key Question to Answer: Is IETF the Right Forum? (45 minutes) a. Informational presentation about ITU-T Study Group 16 b. Informational presentation about IETF Codec WG c. Discussion about alternatives d. Determination of consensus 4. If IETF Is or Might Be the Right Forum: Charter Bashing (45 minutes) a. Problem statement b. Objectives c. Deliverables d. Milestones 5. Key WG Formation Hums (10 minutes) a. Is IETF the best place to do this work? b. If a WG is formed, will you write drafts? c. If a WG is formed, will you review drafts? d. If a WG is formed, will you otherwise participate? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrrJd4ACgkQNL8k5A2w/vzbEACfYZZEmxOpuXLqS5L9RvjtoaKA 5Q8AmgLXzYojvvSH3kvsUFQK/VGlvkLn =NoNR -----END PGP SIGNATURE----- From hsinnrei@adobe.com Fri Oct 30 11:12:00 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246873A6847 for ; Fri, 30 Oct 2009 11:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh+hzzFIIzma for ; Fri, 30 Oct 2009 11:11:55 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id 0A9493A6767 for ; Fri, 30 Oct 2009 11:11:53 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSusseufISTASoGrqlF6f9bSHyfiP4d+w@postini.com; Fri, 30 Oct 2009 11:12:13 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9UIC7W0026438; Fri, 30 Oct 2009 11:12:08 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n9UIC6XW013652; Fri, 30 Oct 2009 11:12:06 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Oct 2009 11:12:06 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Fri, 30 Oct 2009 11:12:03 -0700 From: Henry Sinnreich To: Peter Saint-Andre , "codec@ietf.org" Date: Fri, 30 Oct 2009 11:11:47 -0700 Thread-Topic: [codec] *draft* agenda Thread-Index: AcpZiMUb0fCYkcjaRkGkQle+JUoImQAA6yBo Message-ID: In-Reply-To: <4AEB25DE.7020602@stpeter.im> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C71096936CA4hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:12:00 -0000 --_000_C71096936CA4hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This looks like a very reasonable agenda, except the humming process elimin= ates voting for those who cannot travel to the meeting. Is there some better mechanism possible? Online voting by using a suitable = conferencing package? Or counting the votes from the Jabber IM online participants? If not, I suggest NOT use the "hum consensus" but some other criteria, such= as having a credible team to produce the planned deliverables. Incidentally, I believe having the IETF process dominated by folks who have= a travel budget to be a generic problem, since it eliminates many creative= individual experts to the detriment of those companies who (still) can aff= ord the travel budget. From this perspective, humming is just a broken proc= ess. My personal two cents (I plan to attend). Thanks, Henry On 10/30/09 12:43 PM, "Peter Saint-Andre" wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Burger and I have created a *draft* agenda for the Codec BoF. Feedback is welcome! ### 1. Note Well & Agenda Bashing (5 minutes) 2. Progress to Date (15 minutes) a. BoF at IETF 75 established constituency and interest b. Open issues: work process, requirements, ITU-T coordination c. Several individual drafts published and discussed on the list d. Coordination has occurred with ITU-T SG 16 e. Consensus converging around draft charter 3. Key Question to Answer: Is IETF the Right Forum? (45 minutes) a. Informational presentation about ITU-T Study Group 16 b. Informational presentation about IETF Codec WG c. Discussion about alternatives d. Determination of consensus 4. If IETF Is or Might Be the Right Forum: Charter Bashing (45 minutes) a. Problem statement b. Objectives c. Deliverables d. Milestones 5. Key WG Formation Hums (10 minutes) a. Is IETF the best place to do this work? b. If a WG is formed, will you write drafts? c. If a WG is formed, will you review drafts? d. If a WG is formed, will you otherwise participate? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrrJd4ACgkQNL8k5A2w/vzbEACfYZZEmxOpuXLqS5L9RvjtoaKA 5Q8AmgLXzYojvvSH3kvsUFQK/VGlvkLn =3DNoNR -----END PGP SIGNATURE----- _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C71096936CA4hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] *draft* agenda This looks like a very reasonable agenda, except the humming process = eliminates voting for those who cannot travel to the meeting.

Is there some better mechanism possible? Online voting by using a suitable = conferencing package?
Or counting the votes from the Jabber IM  online participants?
If not, I suggest NOT use the “hum consensus” but some other cr= iteria, such as having a credible team to produce the planned deliverables.=

Incidentally, I believe having the IETF process dominated by folks who have= a travel budget to be a generic problem, since it eliminates many creative= individual experts to the detriment of those companies who (still) can aff= ord the travel budget. From this perspective, humming is just a broken proc= ess.

My personal two cents (I plan to attend).
Thanks, Henry



On 10/30/09 12:43 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Burger and I have created a *draft* agenda for the Codec BoF.
Feedback is welcome!

###

1. Note Well & Agenda Bashing (5 minutes)

2. Progress to Date (15 minutes)
   a. BoF at IETF 75 established constituency and interest    b. Open issues: work process, requirements, ITU-T coordin= ation
   c. Several individual drafts published and discussed on t= he list
   d. Coordination has occurred with ITU-T SG 16
   e. Consensus converging around draft charter

3. Key Question to Answer: Is IETF the Right Forum? (45 minutes)
   a. Informational presentation about ITU-T Study Group 16<= BR>    b. Informational presentation about IETF Codec WG
   c. Discussion about alternatives
   d. Determination of consensus

4. If IETF Is or Might Be the Right Forum: Charter Bashing (45 minutes)
   a. Problem statement
   b. Objectives
   c. Deliverables
   d. Milestones

5. Key WG Formation Hums (10 minutes)
   a. Is IETF the best place to do this work?
   b. If a WG is formed, will you write drafts?
   c. If a WG is formed, will you review drafts?
   d. If a WG is formed, will you otherwise participate?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrrJd4ACgkQNL8k5A2w/vzbEACfYZZEmxOpuXLqS5L9RvjtoaKA
5Q8AmgLXzYojvvSH3kvsUFQK/VGlvkLn
=3DNoNR
-----END PGP SIGNATURE-----
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.or= g/mailman/listinfo/codec

--_000_C71096936CA4hsinnreiadobecom_-- From stpeter@stpeter.im Fri Oct 30 11:44:48 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042543A67A8 for ; Fri, 30 Oct 2009 11:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 eJ1-7Gm5Rsbp for ; Fri, 30 Oct 2009 11:44:46 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B9B9F3A6767 for ; Fri, 30 Oct 2009 11:44:46 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 85EBF4008F; Fri, 30 Oct 2009 12:45:03 -0600 (MDT) Message-ID: <4AEB342E.1050708@stpeter.im> Date: Fri, 30 Oct 2009 12:45:02 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "codec@ietf.org" Subject: Re: [codec] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:44:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henry, comments inline. On 10/30/09 12:11 PM, Henry Sinnreich wrote: > This looks like a very reasonable agenda, except the humming process > eliminates voting for those who cannot travel to the meeting. > > Is there some better mechanism possible? Online voting by using a > suitable conferencing package? > Or counting the votes from the Jabber IM online participants? I think that method has been used in the past, yes. > If not, I suggest NOT use the “hum consensus” but some other criteria, > such as having a credible team to produce the planned deliverables. Well, hums are traditional. That said, I do agree with something Adam Roach said at the BoF in Stockholm. Quoting from the minutes... ### Adam Roach @ mic (quoting from XMPP BoF minutes held at IETF 54): "We should be chartering work based on the number of folks who want to do things, not the number opposed." I think we've heard from a number of people here who want to do the work and have competence in this area. ### In Stockholm we established that we have people who want to do the work, and who seem to be capable of doing the work. Coming out of the Stockholm meeting, we also had several open issues, which Cullen Jennings mentioned in his summary of the BoF at IETF 75 : 1. The scope and processes for a Codec WG were not clear. The work on draft-valin-codec-guidelines has been meant to address those concerns, and we've had a fairly comprehensive discussion about them. 2. The technical and business requirements were not clear. The technical requirements have been covered by draft-valin-codec-requirements as discussed on this list, and the business requirements (mainly IPR to help ensure that the resulting codec(s) can be widely implemented and easily distributed) are covered by draft-valin-codec-guidelines. I think those open issues have been addressed about as completely as possible to this point, as reflected in the I-Ds mentioned above, in list discussions, and in the draft charter. Naturally if a WG is formed then further discussion would happen within the group to reach consensus on which I-Ds to accept as WG items, on exact requirements, etc. An additional open issue was coordination with other SDOs in accordance with liaison agreements in place. I know that discussions have occurred with ITU-T regarding Study Group 16, but it is not my place to talk about those conversations because I was not directly involved. I will leave that for others to talk about, either on this list or at the BoF. As far as I know, discussions have not occurred with other SDOs. In any case, the foregoing text provides a bit of what I see as the context for the BoF in Hiroshima. Other people might disagree, but I think we've made good progress since Stockholm but need to reach consensus on a few more topics as input to the IESG's deliberations about whether it is appropriate to form a WG. > Incidentally, I believe having the IETF process dominated by folks who > have a travel budget to be a generic problem, since it eliminates many > creative individual experts to the detriment of those companies who > (still) can afford the travel budget. From this perspective, humming is > just a broken process. Let's take that up on ietf@ietf.org. :) /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrrNC4ACgkQNL8k5A2w/vxqqgCfQveWeOtvOV2M2G7/r/qkghrV qtIAoKfikGWtTsM9R+FtU+24MCLURj2G =COFl -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Fri Oct 30 11:49:05 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91663A67A8 for ; Fri, 30 Oct 2009 11:49:05 -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 KYAQfiR+ldaW for ; Fri, 30 Oct 2009 11:49:02 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id B76F13A6767 for ; Fri, 30 Oct 2009 11:49:01 -0700 (PDT) Received: by bwz23 with SMTP id 23so3926885bwz.29 for ; Fri, 30 Oct 2009 11:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:content-language:thread-index; bh=ArlunabCcppwalVRRVqiWvCauv6CCqtvGzNnfxAaFqw=; b=x/i5jTSJ+RlwJk2hECDMR84rmNJh8HwDCFxFhAyWJK4QbRTXVuVvWAUxLzQGdDIoeE CTDt3ZCkyPMSWgH2xhNtr5mzyI/ZJvqX79r9FSrpahd9ShaqlOReJeCHMww0FoJ1g0sp aoEJpLC/HCmPz/+6Hye0ryr6n4E0eTV5GKQMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:content-language:thread-index; b=xls8k75ojfrylH+6dH8ywOueXseSOsAAIJvaAI2U/I3gDyDo/45wHyjqs6TB4z5Uzf Ls/NN83kWvSBewDiaPrxLUzp7XfY/g5jTNThOhifO6YHHVFQdfiZhm2cQlyGynIdJpmA jUpnmtCWWlX0u8nUZZW1OT1dy9iKDEOJ1FXW4= Received: by 10.103.80.25 with SMTP id h25mr798912mul.15.1256928554687; Fri, 30 Oct 2009 11:49:14 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-72-25.red.bezeqint.net [79.182.72.25]) by mx.google.com with ESMTPS id e10sm957850muf.51.2009.10.30.11.49.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 11:49:13 -0700 (PDT) From: "Roni Even" To: "'Henry Sinnreich'" , "'Peter Saint-Andre'" , References: <4AEB25DE.7020602@stpeter.im> In-Reply-To: Date: Fri, 30 Oct 2009 20:48:32 +0200 Message-ID: <4aeb3529.0ab6660a.4554.5f79@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0418_01CA59A2.59CD4800" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcpZiMUb0fCYkcjaRkGkQle+JUoImQAA6yBoAAEqR3A= Subject: Re: [codec] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:49:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0418_01CA59A2.59CD4800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Henry, I see travel budget and willingness to travel as part of the commitment to participate in the work a working group. Roni Even From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Friday, October 30, 2009 8:12 PM To: Peter Saint-Andre; codec@ietf.org Subject: Re: [codec] *draft* agenda This looks like a very reasonable agenda, except the humming process eliminates voting for those who cannot travel to the meeting. Is there some better mechanism possible? Online voting by using a suitable conferencing package? Or counting the votes from the Jabber IM online participants? If not, I suggest NOT use the "hum consensus" but some other criteria, such as having a credible team to produce the planned deliverables. Incidentally, I believe having the IETF process dominated by folks who have a travel budget to be a generic problem, since it eliminates many creative individual experts to the detriment of those companies who (still) can afford the travel budget. From this perspective, humming is just a broken process. My personal two cents (I plan to attend). Thanks, Henry On 10/30/09 12:43 PM, "Peter Saint-Andre" wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Burger and I have created a *draft* agenda for the Codec BoF. Feedback is welcome! ### 1. Note Well & Agenda Bashing (5 minutes) 2. Progress to Date (15 minutes) a. BoF at IETF 75 established constituency and interest b. Open issues: work process, requirements, ITU-T coordination c. Several individual drafts published and discussed on the list d. Coordination has occurred with ITU-T SG 16 e. Consensus converging around draft charter 3. Key Question to Answer: Is IETF the Right Forum? (45 minutes) a. Informational presentation about ITU-T Study Group 16 b. Informational presentation about IETF Codec WG c. Discussion about alternatives d. Determination of consensus 4. If IETF Is or Might Be the Right Forum: Charter Bashing (45 minutes) a. Problem statement b. Objectives c. Deliverables d. Milestones 5. Key WG Formation Hums (10 minutes) a. Is IETF the best place to do this work? b. If a WG is formed, will you write drafts? c. If a WG is formed, will you review drafts? d. If a WG is formed, will you otherwise participate? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrrJd4ACgkQNL8k5A2w/vzbEACfYZZEmxOpuXLqS5L9RvjtoaKA 5Q8AmgLXzYojvvSH3kvsUFQK/VGlvkLn =NoNR -----END PGP SIGNATURE----- _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------=_NextPart_000_0418_01CA59A2.59CD4800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [codec] *draft* agenda

Henry,

I see travel budget and willingness to travel as part of = the commitment to participate in the work a working group.

 

Roni Even

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Henry Sinnreich
Sent: Friday, October 30, 2009 8:12 PM
To: Peter Saint-Andre; codec@ietf.org
Subject: Re: [codec] *draft* agenda

 

This looks like a very reasonable = agenda, except the humming process eliminates voting for those who cannot travel = to the meeting.

Is there some better mechanism possible? Online voting by using a = suitable conferencing package?
Or counting the votes from the Jabber IM  online participants?
If not, I suggest NOT use the “hum consensus” but some other = criteria, such as having a credible team to produce the planned deliverables.

Incidentally, I believe having the IETF process dominated by folks who = have a travel budget to be a generic problem, since it eliminates many creative individual experts to the detriment of those companies who (still) can = afford the travel budget. From this perspective, humming is just a broken = process.

My personal two cents (I plan to attend).
Thanks, Henry



On 10/30/09 12:43 PM, "Peter Saint-Andre" <stpeter@stpeter.im> = wrote:

-----BEGIN PGP SIGNED = MESSAGE-----
Hash: SHA1

Eric Burger and I have created a *draft* agenda for the Codec BoF.
Feedback is welcome!

###

1. Note Well & Agenda Bashing (5 minutes)

2. Progress to Date (15 minutes)
   a. BoF at IETF 75 established constituency and = interest
   b. Open issues: work process, requirements, ITU-T coordination
   c. Several individual drafts published and discussed = on the list
   d. Coordination has occurred with ITU-T SG 16
   e. Consensus converging around draft charter

3. Key Question to Answer: Is IETF the Right Forum? (45 minutes)
   a. Informational presentation about ITU-T Study Group = 16
   b. Informational presentation about IETF Codec WG
   c. Discussion about alternatives
   d. Determination of consensus

4. If IETF Is or Might Be the Right Forum: Charter Bashing (45 = minutes)
   a. Problem statement
   b. Objectives
   c. Deliverables
   d. Milestones

5. Key WG Formation Hums (10 minutes)
   a. Is IETF the best place to do this work?
   b. If a WG is formed, will you write drafts?
   c. If a WG is formed, will you review drafts?
   d. If a WG is formed, will you otherwise = participate?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrrJd4ACgkQNL8k5A2w/vzbEACfYZZEmxOpuXLqS5L9RvjtoaKA
5Q8AmgLXzYojvvSH3kvsUFQK/VGlvkLn
=3DNoNR
-----END PGP SIGNATURE-----
_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

------=_NextPart_000_0418_01CA59A2.59CD4800-- From mknappe@juniper.net Fri Oct 30 11:56:47 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857233A690B for ; Fri, 30 Oct 2009 11:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.121 X-Spam-Level: X-Spam-Status: No, score=-5.121 tagged_above=-999 required=5 tests=[AWL=-1.478, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 FU4m5LkHa-ep for ; Fri, 30 Oct 2009 11:56:46 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id E2FA83A68FE for ; Fri, 30 Oct 2009 11:56:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSus2/MvKBN9qzxmUrOk83LKgFE8vITjt@postini.com; Fri, 30 Oct 2009 11:57:03 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 30 Oct 2009 11:56:28 -0700 From: Michael Knappe To: "ron.even.tlv@gmail.com" , "hsinnrei@adobe.com" , "stpeter@stpeter.im" , "codec@ietf.org" Date: Fri, 30 Oct 2009 11:56:28 -0700 Thread-Topic: [codec] *draft* agenda Thread-Index: AcpZiMUb0fCYkcjaRkGkQle+JUoImQAA6yBoAAEqR3AAAGS7oA== Message-ID: <05542EC42316164383B5180707A489EE1D031D3CD8@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05542EC42316164383B5180707A489EE1D031D3CD8EMBX02HQjnprn_" MIME-Version: 1.0 Subject: Re: [codec] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 18:56:47 -0000 --_000_05542EC42316164383B5180707A489EE1D031D3CD8EMBX02HQjnprn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBhZ3JlZSB0aGF0IHRoZXJlIGlzIHN0aWxsIG5vIHN1YnN0aXR1dGUgZm9yIGZhY2Ut dG8tZmFjZSBwYXJ0aWNpcGF0aW9uIHdoZW4gZGVhbGluZyB3aXRoIGNvbXBsZXggc3ViamVjdCBt YXR0ZXIuIEl0IG9jY3VycmVkIHRvIHRoYXQgdGhlIGxhY2sgb2Ygd2lkZWx5IGRlcGxveWVkLCBj b3N0IGVmZmVjdGl2ZSwgYW5kIHRydWx5IGltbWVyc2l2ZSBjb2xsYWJvcmF0aXZlIHRvb2xzIGlz IGluIGl0c2VsZiBhIHBvc3Rlci1jaGlsZCBmb3IgdGhlIHdvcmsgd2UgYXJlIHVuZGVydGFraW5n Lg0KDQpNaWtlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBjb2Rl Yy1ib3VuY2VzQGlldGYub3JnIDxjb2RlYy1ib3VuY2VzQGlldGYub3JnPg0KVG86ICdIZW5yeSBT aW5ucmVpY2gnIDxoc2lubnJlaUBhZG9iZS5jb20+OyAnUGV0ZXIgU2FpbnQtQW5kcmUnIDxzdHBl dGVyQHN0cGV0ZXIuaW0+OyBjb2RlY0BpZXRmLm9yZyA8Y29kZWNAaWV0Zi5vcmc+DQpTZW50OiBG cmkgT2N0IDMwIDE0OjQ4OjMyIDIwMDkNClN1YmplY3Q6IFJlOiBbY29kZWNdICpkcmFmdCogYWdl bmRhDQpIZW5yeSwNCkkgc2VlIHRyYXZlbCBidWRnZXQgYW5kIHdpbGxpbmduZXNzIHRvIHRyYXZl bCBhcyBwYXJ0IG9mIHRoZSBjb21taXRtZW50IHRvIHBhcnRpY2lwYXRlIGluIHRoZSB3b3JrIGEg d29ya2luZyBncm91cC4NCg0KUm9uaSBFdmVuDQoNCkZyb206IGNvZGVjLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjb2RlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGVucnkgU2lu bnJlaWNoDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMzAsIDIwMDkgODoxMiBQTQ0KVG86IFBldGVy IFNhaW50LUFuZHJlOyBjb2RlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjb2RlY10gKmRyYWZ0 KiBhZ2VuZGENCg0KVGhpcyBsb29rcyBsaWtlIGEgdmVyeSByZWFzb25hYmxlIGFnZW5kYSwgZXhj ZXB0IHRoZSBodW1taW5nIHByb2Nlc3MgZWxpbWluYXRlcyB2b3RpbmcgZm9yIHRob3NlIHdobyBj YW5ub3QgdHJhdmVsIHRvIHRoZSBtZWV0aW5nLg0KDQpJcyB0aGVyZSBzb21lIGJldHRlciBtZWNo YW5pc20gcG9zc2libGU/IE9ubGluZSB2b3RpbmcgYnkgdXNpbmcgYSBzdWl0YWJsZSBjb25mZXJl bmNpbmcgcGFja2FnZT8NCk9yIGNvdW50aW5nIHRoZSB2b3RlcyBmcm9tIHRoZSBKYWJiZXIgSU0g IG9ubGluZSBwYXJ0aWNpcGFudHM/DQpJZiBub3QsIEkgc3VnZ2VzdCBOT1QgdXNlIHRoZSDigJxo dW0gY29uc2Vuc3Vz4oCdIGJ1dCBzb21lIG90aGVyIGNyaXRlcmlhLCBzdWNoIGFzIGhhdmluZyBh IGNyZWRpYmxlIHRlYW0gdG8gcHJvZHVjZSB0aGUgcGxhbm5lZCBkZWxpdmVyYWJsZXMuDQoNCklu Y2lkZW50YWxseSwgSSBiZWxpZXZlIGhhdmluZyB0aGUgSUVURiBwcm9jZXNzIGRvbWluYXRlZCBi eSBmb2xrcyB3aG8gaGF2ZSBhIHRyYXZlbCBidWRnZXQgdG8gYmUgYSBnZW5lcmljIHByb2JsZW0s IHNpbmNlIGl0IGVsaW1pbmF0ZXMgbWFueSBjcmVhdGl2ZSBpbmRpdmlkdWFsIGV4cGVydHMgdG8g dGhlIGRldHJpbWVudCBvZiB0aG9zZSBjb21wYW5pZXMgd2hvIChzdGlsbCkgY2FuIGFmZm9yZCB0 aGUgdHJhdmVsIGJ1ZGdldC4gRnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBodW1taW5nIGlzIGp1c3Qg YSBicm9rZW4gcHJvY2Vzcy4NCg0KTXkgcGVyc29uYWwgdHdvIGNlbnRzIChJIHBsYW4gdG8gYXR0 ZW5kKS4NClRoYW5rcywgSGVucnkNCg0KDQoNCk9uIDEwLzMwLzA5IDEyOjQzIFBNLCAiUGV0ZXIg U2FpbnQtQW5kcmUiIDxzdHBldGVyQHN0cGV0ZXIuaW0+IHdyb3RlOg0KLS0tLS1CRUdJTiBQR1Ag U0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpFcmljIEJ1cmdlciBhbmQgSSBoYXZl IGNyZWF0ZWQgYSAqZHJhZnQqIGFnZW5kYSBmb3IgdGhlIENvZGVjIEJvRi4NCkZlZWRiYWNrIGlz IHdlbGNvbWUhDQoNCiMjIw0KDQoxLiBOb3RlIFdlbGwgJiBBZ2VuZGEgQmFzaGluZyAoNSBtaW51 dGVzKQ0KDQoyLiBQcm9ncmVzcyB0byBEYXRlICgxNSBtaW51dGVzKQ0KICAgYS4gQm9GIGF0IElF VEYgNzUgZXN0YWJsaXNoZWQgY29uc3RpdHVlbmN5IGFuZCBpbnRlcmVzdA0KICAgYi4gT3BlbiBp c3N1ZXM6IHdvcmsgcHJvY2VzcywgcmVxdWlyZW1lbnRzLCBJVFUtVCBjb29yZGluYXRpb24NCiAg IGMuIFNldmVyYWwgaW5kaXZpZHVhbCBkcmFmdHMgcHVibGlzaGVkIGFuZCBkaXNjdXNzZWQgb24g dGhlIGxpc3QNCiAgIGQuIENvb3JkaW5hdGlvbiBoYXMgb2NjdXJyZWQgd2l0aCBJVFUtVCBTRyAx Ng0KICAgZS4gQ29uc2Vuc3VzIGNvbnZlcmdpbmcgYXJvdW5kIGRyYWZ0IGNoYXJ0ZXINCg0KMy4g S2V5IFF1ZXN0aW9uIHRvIEFuc3dlcjogSXMgSUVURiB0aGUgUmlnaHQgRm9ydW0/ICg0NSBtaW51 dGVzKQ0KICAgYS4gSW5mb3JtYXRpb25hbCBwcmVzZW50YXRpb24gYWJvdXQgSVRVLVQgU3R1ZHkg R3JvdXAgMTYNCiAgIGIuIEluZm9ybWF0aW9uYWwgcHJlc2VudGF0aW9uIGFib3V0IElFVEYgQ29k ZWMgV0cNCiAgIGMuIERpc2N1c3Npb24gYWJvdXQgYWx0ZXJuYXRpdmVzDQogICBkLiBEZXRlcm1p bmF0aW9uIG9mIGNvbnNlbnN1cw0KDQo0LiBJZiBJRVRGIElzIG9yIE1pZ2h0IEJlIHRoZSBSaWdo dCBGb3J1bTogQ2hhcnRlciBCYXNoaW5nICg0NSBtaW51dGVzKQ0KICAgYS4gUHJvYmxlbSBzdGF0 ZW1lbnQNCiAgIGIuIE9iamVjdGl2ZXMNCiAgIGMuIERlbGl2ZXJhYmxlcw0KICAgZC4gTWlsZXN0 b25lcw0KDQo1LiBLZXkgV0cgRm9ybWF0aW9uIEh1bXMgKDEwIG1pbnV0ZXMpDQogICBhLiBJcyBJ RVRGIHRoZSBiZXN0IHBsYWNlIHRvIGRvIHRoaXMgd29yaz8NCiAgIGIuIElmIGEgV0cgaXMgZm9y bWVkLCB3aWxsIHlvdSB3cml0ZSBkcmFmdHM/DQogICBjLiBJZiBhIFdHIGlzIGZvcm1lZCwgd2ls bCB5b3UgcmV2aWV3IGRyYWZ0cz8NCiAgIGQuIElmIGEgV0cgaXMgZm9ybWVkLCB3aWxsIHlvdSBv dGhlcndpc2UgcGFydGljaXBhdGU/DQoNCg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0N ClZlcnNpb246IEdudVBHIHYxLjQuOCAoRGFyd2luKQ0KQ29tbWVudDogVXNpbmcgR251UEcgd2l0 aCBNb3ppbGxhIC0gaHR0cDovL2VuaWdtYWlsLm1vemRldi5vcmcvDQoNCmlFWUVBUkVDQUFZRkFr cnJKZDRBQ2drUU5MOGs1QTJ3L3Z6YkVBQ2ZZWlpFbXhPcHVYTHFTNUw5UnZqdG9hS0ENCjVROEFt Z0xYellvanZ2U0gza3ZzVUZRSy9WR2x2a0xuDQo9Tm9OUg0KLS0tLS1FTkQgUEdQIFNJR05BVFVS RS0tLS0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Y29kZWMgbWFpbGluZyBsaXN0DQpjb2RlY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb2RlYw0K --_000_05542EC42316164383B5180707A489EE1D031D3CD8EMBX02HQjnprn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczpt PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5z OnN0PSImIzE7IiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1XaW5kb3dzLTEyNTIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNy b3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8dGl0bGU+UmU6IFtjb2RlY10gKmRy YWZ0KiBhZ2VuZGE8L3RpdGxlPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMg Ki8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5T ZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPjxwPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+DQpJIHdvdWxkIGFncmVlIHRoYXQgdGhlcmUgaXMgc3RpbGwg bm8gc3Vic3RpdHV0ZSBmb3IgZmFjZS10by1mYWNlIHBhcnRpY2lwYXRpb24gd2hlbiBkZWFsaW5n IHdpdGggY29tcGxleCBzdWJqZWN0IG1hdHRlci4gSXQgb2NjdXJyZWQgdG8gdGhhdCB0aGUgbGFj ayBvZiB3aWRlbHkgZGVwbG95ZWQsIGNvc3QgZWZmZWN0aXZlLCBhbmQgdHJ1bHkgaW1tZXJzaXZl IGNvbGxhYm9yYXRpdmUgdG9vbHMgaXMgaW4gaXRzZWxmIGEgcG9zdGVyLWNoaWxkIGZvciB0aGUg d29yayB3ZSBhcmUgdW5kZXJ0YWtpbmcuPGJyPjxicj5NaWtlPGJyPjwvZm9udD48L3A+DQo8cD48 aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQo8Zm9udCBm YWNlPVRhaG9tYSBzaXplPTI+DQo8Yj5Gcm9tPC9iPjogY29kZWMtYm91bmNlc0BpZXRmLm9yZyAm bHQ7Y29kZWMtYm91bmNlc0BpZXRmLm9yZyZndDsNPGJyPjxiPlRvPC9iPjogJ0hlbnJ5IFNpbm5y ZWljaCcgJmx0O2hzaW5ucmVpQGFkb2JlLmNvbSZndDs7ICdQZXRlciBTYWludC1BbmRyZScgJmx0 O3N0cGV0ZXJAc3RwZXRlci5pbSZndDs7IGNvZGVjQGlldGYub3JnICZsdDtjb2RlY0BpZXRmLm9y ZyZndDsNPGJyPjxiPlNlbnQ8L2I+OiBGcmkgT2N0IDMwIDE0OjQ4OjMyIDIwMDk8YnI+PGI+U3Vi amVjdDwvYj46IFJlOiBbY29kZWNdICpkcmFmdCogYWdlbmRhDTxicj48L2ZvbnQ+PC9wPg0KDQoN CjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SGVucnksPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj5JIHNlZSB0cmF2ZWwgYnVkZ2V0IGFuZCB3aWxsaW5nbmVzcyB0 byB0cmF2ZWwgYXMgcGFydCBvZiB0aGUgY29tbWl0bWVudA0KdG8gcGFydGljaXBhdGUgaW4gdGhl IHdvcmsgYSB3b3JraW5nIGdyb3VwLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Um9uaSBFdmVuPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1yaWdodDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KY29k ZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9u IEJlaGFsZiBPZiA8L2I+SGVucnkNClNpbm5yZWljaDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IE9jdG9iZXIgMzAsIDIwMDkgODoxMiBQTTxicj4NCjxiPlRvOjwvYj4gUGV0ZXIgU2FpbnQtQW5k cmU7IGNvZGVjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY29kZWNdICpkcmFm dCogYWdlbmRhPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5UaGlzIGxvb2tzIGxpa2UgYSB2ZXJ5IHJlYXNvbmFibGUgYWdlbmRhLA0KZXhj ZXB0IHRoZSBodW1taW5nIHByb2Nlc3MgZWxpbWluYXRlcyB2b3RpbmcgZm9yIHRob3NlIHdobyBj YW5ub3QgdHJhdmVsIHRvIHRoZQ0KbWVldGluZy48YnI+DQo8YnI+DQpJcyB0aGVyZSBzb21lIGJl dHRlciBtZWNoYW5pc20gcG9zc2libGU/IE9ubGluZSB2b3RpbmcgYnkgdXNpbmcgYSBzdWl0YWJs ZQ0KY29uZmVyZW5jaW5nIHBhY2thZ2U/PGJyPg0KT3IgY291bnRpbmcgdGhlIHZvdGVzIGZyb20g dGhlIEphYmJlciBJTSAmbmJzcDtvbmxpbmUgcGFydGljaXBhbnRzPzxicj4NCklmIG5vdCwgSSBz dWdnZXN0IE5PVCB1c2UgdGhlIOKAnGh1bSBjb25zZW5zdXPigJ0gYnV0IHNvbWUgb3RoZXIgY3Jp dGVyaWEsIHN1Y2ggYXMNCmhhdmluZyBhIGNyZWRpYmxlIHRlYW0gdG8gcHJvZHVjZSB0aGUgcGxh bm5lZCBkZWxpdmVyYWJsZXMuPGJyPg0KPGJyPg0KSW5jaWRlbnRhbGx5LCBJIGJlbGlldmUgaGF2 aW5nIHRoZSBJRVRGIHByb2Nlc3MgZG9taW5hdGVkIGJ5IGZvbGtzIHdobyBoYXZlIGENCnRyYXZl bCBidWRnZXQgdG8gYmUgYSBnZW5lcmljIHByb2JsZW0sIHNpbmNlIGl0IGVsaW1pbmF0ZXMgbWFu eSBjcmVhdGl2ZQ0KaW5kaXZpZHVhbCBleHBlcnRzIHRvIHRoZSBkZXRyaW1lbnQgb2YgdGhvc2Ug Y29tcGFuaWVzIHdobyAoc3RpbGwpIGNhbiBhZmZvcmQNCnRoZSB0cmF2ZWwgYnVkZ2V0LiBGcm9t IHRoaXMgcGVyc3BlY3RpdmUsIGh1bW1pbmcgaXMganVzdCBhIGJyb2tlbiBwcm9jZXNzLjxicj4N Cjxicj4NCk15IHBlcnNvbmFsIHR3byBjZW50cyAoSSBwbGFuIHRvIGF0dGVuZCkuPGJyPg0KVGhh bmtzLCBIZW5yeTxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIDEwLzMwLzA5IDEyOjQzIFBNLCAm cXVvdDtQZXRlciBTYWludC1BbmRyZSZxdW90OyAmbHQ7PGEgaHJlZj0ic3RwZXRlckBzdHBldGVy LmltIj5zdHBldGVyQHN0cGV0ZXIuaW08L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQ7DQpmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNT QUdFLS0tLS08YnI+DQpIYXNoOiBTSEExPGJyPg0KPGJyPg0KRXJpYyBCdXJnZXIgYW5kIEkgaGF2 ZSBjcmVhdGVkIGEgKmRyYWZ0KiBhZ2VuZGEgZm9yIHRoZSBDb2RlYyBCb0YuPGJyPg0KRmVlZGJh Y2sgaXMgd2VsY29tZSE8YnI+DQo8YnI+DQojIyM8YnI+DQo8YnI+DQoxLiBOb3RlIFdlbGwgJmFt cDsgQWdlbmRhIEJhc2hpbmcgKDUgbWludXRlcyk8YnI+DQo8YnI+DQoyLiBQcm9ncmVzcyB0byBE YXRlICgxNSBtaW51dGVzKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2EuIEJvRiBhdCBJRVRGIDc1 IGVzdGFibGlzaGVkIGNvbnN0aXR1ZW5jeSBhbmQgaW50ZXJlc3Q8YnI+DQombmJzcDsmbmJzcDsm bmJzcDtiLiBPcGVuIGlzc3Vlczogd29yayBwcm9jZXNzLCByZXF1aXJlbWVudHMsIElUVS1UDQpj b29yZGluYXRpb248YnI+DQombmJzcDsmbmJzcDsmbmJzcDtjLiBTZXZlcmFsIGluZGl2aWR1YWwg ZHJhZnRzIHB1Ymxpc2hlZCBhbmQgZGlzY3Vzc2VkIG9uIHRoZQ0KbGlzdDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwO2QuIENvb3JkaW5hdGlvbiBoYXMgb2NjdXJyZWQgd2l0aCBJVFUtVCBTRyAxNjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwO2UuIENvbnNlbnN1cyBjb252ZXJnaW5nIGFyb3VuZCBkcmFm dCBjaGFydGVyPGJyPg0KPGJyPg0KMy4gS2V5IFF1ZXN0aW9uIHRvIEFuc3dlcjogSXMgSUVURiB0 aGUgUmlnaHQgRm9ydW0/ICg0NSBtaW51dGVzKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2EuIElu Zm9ybWF0aW9uYWwgcHJlc2VudGF0aW9uIGFib3V0IElUVS1UIFN0dWR5IEdyb3VwIDE2PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Yi4gSW5mb3JtYXRpb25hbCBwcmVzZW50YXRpb24gYWJvdXQgSUVU RiBDb2RlYyBXRzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2MuIERpc2N1c3Npb24gYWJvdXQgYWx0 ZXJuYXRpdmVzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ZC4gRGV0ZXJtaW5hdGlvbiBvZiBjb25z ZW5zdXM8YnI+DQo8YnI+DQo0LiBJZiBJRVRGIElzIG9yIE1pZ2h0IEJlIHRoZSBSaWdodCBGb3J1 bTogQ2hhcnRlciBCYXNoaW5nICg0NSBtaW51dGVzKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2Eu IFByb2JsZW0gc3RhdGVtZW50PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Yi4gT2JqZWN0aXZlczxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwO2MuIERlbGl2ZXJhYmxlczxicj4NCiZuYnNwOyZuYnNwOyZu YnNwO2QuIE1pbGVzdG9uZXM8YnI+DQo8YnI+DQo1LiBLZXkgV0cgRm9ybWF0aW9uIEh1bXMgKDEw IG1pbnV0ZXMpPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7YS4gSXMgSUVURiB0aGUgYmVzdCBwbGFj ZSB0byBkbyB0aGlzIHdvcms/PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Yi4gSWYgYSBXRyBpcyBm b3JtZWQsIHdpbGwgeW91IHdyaXRlIGRyYWZ0cz88YnI+DQombmJzcDsmbmJzcDsmbmJzcDtjLiBJ ZiBhIFdHIGlzIGZvcm1lZCwgd2lsbCB5b3UgcmV2aWV3IGRyYWZ0cz88YnI+DQombmJzcDsmbmJz cDsmbmJzcDtkLiBJZiBhIFdHIGlzIGZvcm1lZCwgd2lsbCB5b3Ugb3RoZXJ3aXNlIHBhcnRpY2lw YXRlPzxicj4NCjxicj4NCjxicj4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPGJyPg0K VmVyc2lvbjogR251UEcgdjEuNC44IChEYXJ3aW4pPGJyPg0KQ29tbWVudDogVXNpbmcgR251UEcg d2l0aCBNb3ppbGxhIC0gPGEgaHJlZj0iaHR0cDovL2VuaWdtYWlsLm1vemRldi5vcmcvIj5odHRw Oi8vZW5pZ21haWwubW96ZGV2Lm9yZy88L2E+PGJyPg0KPGJyPg0KaUVZRUFSRUNBQVlGQWtyckpk NEFDZ2tRTkw4azVBMncvdnpiRUFDZllaWkVteE9wdVhMcVM1TDlSdmp0b2FLQTxicj4NCjVROEFt Z0xYellvanZ2U0gza3ZzVUZRSy9WR2x2a0xuPGJyPg0KPU5vTlI8YnI+DQotLS0tLUVORCBQR1Ag U0lHTkFUVVJFLS0tLS08YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCmNvZGVjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9ImNvZGVjQGll dGYub3JnIj5jb2RlY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvZGVjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvZGVjPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwv ZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_05542EC42316164383B5180707A489EE1D031D3CD8EMBX02HQjnprn_-- From petithug@acm.org Fri Oct 30 13:01:16 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2259B3A68B0 for ; Fri, 30 Oct 2009 13:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.075 X-Spam-Level: X-Spam-Status: No, score=-102.075 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDeyLO8-EGTU for ; Fri, 30 Oct 2009 13:01:15 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 4F9813A6899 for ; Fri, 30 Oct 2009 13:01:15 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 94D276C984CC; Fri, 30 Oct 2009 20:01:32 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id B86E66C984B2; Fri, 30 Oct 2009 20:01:31 +0000 (UTC) Message-ID: <4AEB461A.9070609@acm.org> Date: Fri, 30 Oct 2009 13:01:30 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Roni Even References: <4AEB25DE.7020602@stpeter.im> <4aeb3529.0ab6660a.4554.5f79@mx.google.com> In-Reply-To: <4aeb3529.0ab6660a.4554.5f79@mx.google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org, 'Drew Dvorshak' Subject: [codec] Sponsorship for FOSS developers [was Re: *draft* agenda] X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:01:16 -0000 Roni Even wrote: > > > Henry, > > I see travel budget and willingness to travel as part of the commitment > to participate in the work a working group. > I will not comment on this, but I wonder if ISOC could not have a Sponsorship program for FOSS developers, similar to the existing sponsorship. After all, FOSS developers are the one writing the really good code for the Internet this days, and the less likely to be able to secure a travel budget to attend the IETF meetings. > > > Roni Even > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On > Behalf Of *Henry Sinnreich > *Sent:* Friday, October 30, 2009 8:12 PM > *To:* Peter Saint-Andre; codec@ietf.org > *Subject:* Re: [codec] *draft* agenda > > > > This looks like a very reasonable agenda, except the humming process > eliminates voting for those who cannot travel to the meeting. > > Is there some better mechanism possible? Online voting by using a > suitable conferencing package? > Or counting the votes from the Jabber IM online participants? > If not, I suggest NOT use the “hum consensus” but some other criteria, > such as having a credible team to produce the planned deliverables. > > Incidentally, I believe having the IETF process dominated by folks who > have a travel budget to be a generic problem, since it eliminates many > creative individual experts to the detriment of those companies who > (still) can afford the travel budget. From this perspective, humming is > just a broken process. > > My personal two cents (I plan to attend). > Thanks, Henry -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From stpeter@stpeter.im Fri Oct 30 13:11:31 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD1A3A6867 for ; Fri, 30 Oct 2009 13:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 7dtuUEHZmw6m for ; Fri, 30 Oct 2009 13:11:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C92FF3A67BD for ; Fri, 30 Oct 2009 13:11:30 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0AD8340D0B for ; Fri, 30 Oct 2009 14:11:47 -0600 (MDT) Message-ID: <4AEB4882.4030004@stpeter.im> Date: Fri, 30 Oct 2009 14:11:46 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:11:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RFC 5434 has a list of questions that need to be answered before a WG is formed, and I think we have fairly clear answers to these questions: 1. Is there a problem that needs solving? (Yes, see problem statement in charter.) 2. Is the scope of the problem well defined and understood? (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) 3. Is there agreement on what the WG needs to deliver? (Yes, see deliverables in charter, guidelines I-D, and requirements I-D.) 4. Are there enough IETF participants to do the work? (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) 5. Does the WG have a reasonable probability of success? (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an emphasis on "reasonable" because we won't know until we try.) 6. Is the IETF is the right place to do the work? (Maybe. I think this is the major item to clarify at the BoF.) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP =9vPK -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Oct 30 13:16:12 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDD43A68FF; Fri, 30 Oct 2009 13:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 QFmat2iksFW7; Fri, 30 Oct 2009 13:16:12 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 386813A68B0; Fri, 30 Oct 2009 13:16:12 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 264CB4008F; Fri, 30 Oct 2009 14:16:29 -0600 (MDT) Message-ID: <4AEB499B.8020300@stpeter.im> Date: Fri, 30 Oct 2009 14:16:27 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4AEB25DE.7020602@stpeter.im> <4aeb3529.0ab6660a.4554.5f79@mx.google.com> <4AEB461A.9070609@acm.org> In-Reply-To: <4AEB461A.9070609@acm.org> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, IETF discussion list , 'Drew Dvorshak' Subject: Re: [codec] Sponsorship for FOSS developers (was: Re: *draft* agenda) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:16:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/30/09 2:01 PM, Marc Petit-Huguenin wrote: > Roni Even wrote: >> >> Henry, >> >> I see travel budget and willingness to travel as part of the commitment >> to participate in the work a working group. >> > > I will not comment on this, but I wonder if ISOC could not have a Sponsorship > program for FOSS developers, similar to the existing sponsorship. After all, > FOSS developers are the one writing the really good code for the Internet this > days, and the less likely to be able to secure a travel budget to attend the > IETF meetings. That's a great idea. It might help us stay closer to running code, too. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrrSZsACgkQNL8k5A2w/vxM1gCfWoX50oblcsodN9RKySArkAm0 K4sAn3IGOYJIh+rBv6FREUT1APREqizm =ZVMU -----END PGP SIGNATURE----- From ron.even.tlv@gmail.com Fri Oct 30 15:34:38 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68943A688C for ; Fri, 30 Oct 2009 15:34:38 -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 FYExEFC7qU74 for ; Fri, 30 Oct 2009 15:34:37 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 8B3043A6800 for ; Fri, 30 Oct 2009 15:34:37 -0700 (PDT) Received: by bwz23 with SMTP id 23so4148080bwz.29 for ; Fri, 30 Oct 2009 15:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=laUsbol7xyxNzw9YEX8QtKaNotC3qIIpxS9/troydvg=; b=U1ZiWwzBaNknGtvfemzF4kp0GUw8MOZUKHd3+IyFa/8URJOcapD9EsUZAkFNk/XPCH qT1DvdCA3jZIa8iyTEM3xa8qjqUyQjKliRLYq883ZJSZFQh/iCzOckM/DBPbrtic/0wQ WhVd0gxrwf9H8eh5CTs8wFo0XupERcukjCt3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:content-language :thread-index; b=Tzsq/C/N8OpAuMqq84RyYyjf6SjWB11u52IaWZ1OtaKy/W7EOyCWqACaY3VHxAbl33 ETPMX/oGafDN5yh9fJXWjroVK5Rz00upABMtvs9b7YFbqucVp+9lF/uPTTXYDexjFq3G R6f9RE9F6zUdmm13pOT3hfz+Yk74H0mzVl6k8= Received: by 10.103.126.32 with SMTP id d32mr880953mun.0.1256942091173; Fri, 30 Oct 2009 15:34:51 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-72-25.red.bezeqint.net [79.182.72.25]) by mx.google.com with ESMTPS id g1sm1249601muf.35.2009.10.30.15.34.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 15:34:49 -0700 (PDT) From: "Roni Even" To: "'Peter Saint-Andre'" , References: <4AEB4882.4030004@stpeter.im> In-Reply-To: <4AEB4882.4030004@stpeter.im> Date: Sat, 31 Oct 2009 00:34:09 +0200 Message-ID: <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbg Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 22:34:38 -0000 Hi Peter, I am not sure that there is a consensus about what the group need to deliver. I do not feel that the issue of the number of codecs and how to decide which codecs are in scope for this working group is agreed. My view that this issue is not addressed since I assume that all the parties that submitted candidate codecs would like their codecs to be approved at the IETF which will make this group a rubber stamping WG. I think that the if the charter describes a list of applications it need to have a separate requirement for each application on which this proposed group is going to develop a separate codec. If there is one requirement document for all apllications there should be one codec to address it. Thanks Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, October 30, 2009 10:12 PM > To: codec@ietf.org > Subject: [codec] questions to be answered > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > RFC 5434 has a list of questions that need to be answered before a WG > is > formed, and I think we have fairly clear answers to these questions: > > 1. Is there a problem that needs solving? > > (Yes, see problem statement in charter.) > > 2. Is the scope of the problem well defined and understood? > > (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) > > 3. Is there agreement on what the WG needs to deliver? > > (Yes, see deliverables in charter, guidelines I-D, and requirements I- > D.) > > 4. Are there enough IETF participants to do the work? > > (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) > > 5. Does the WG have a reasonable probability of success? > > (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an > emphasis on "reasonable" because we won't know until we try.) > > 6. Is the IETF is the right place to do the work? > > (Maybe. I think this is the major item to clarify at the BoF.) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz > lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP > =9vPK > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Fri Oct 30 16:16:32 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457F33A6A21 for ; Fri, 30 Oct 2009 16:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JA3CDwmd7y9 for ; Fri, 30 Oct 2009 16:16:31 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 0D5643A6992 for ; Fri, 30 Oct 2009 16:16:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKSutz3k7LGQmy9xDDgZc1P9ioET91Qgtk@postini.com; Fri, 30 Oct 2009 16:16:48 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 30 Oct 2009 16:15:16 -0700 From: Michael Knappe To: Roni Even , Peter Saint-Andre , "codec@ietf.org" Date: Fri, 30 Oct 2009 16:15:48 -0700 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAAGkr5w= Message-ID: In-Reply-To: <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 23:16:32 -0000 Roni, On your latter points, how about a set of general benchmark requirements th= at all codecs must meet, followed by more stringent or more specific criter= ia to meet narrower requirements of a target application? This could be all= coupled together in a single requirements document. A single doc would mak= e it easier to lay out common test methodologies just once, followed by spe= cific application requirements broken out into separate subsequent sections= . Mike On 10/30/09 3:34 PM, "Roni Even" wrote: Hi Peter, I am not sure that there is a consensus about what the group need to deliver. I do not feel that the issue of the number of codecs and how to decide which codecs are in scope for this working group is agreed. My view that this issue is not addressed since I assume that all the parties that submitted candidate codecs would like their codecs to be approved at the IETF which will make this group a rubber stamping WG. I think that the if the charter describes a list of applications it need to have a separate requirement for each application on which this proposed group is going to develop a separate codec. If there is one requirement document for all apllications there should be one codec to address it. Thanks Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, October 30, 2009 10:12 PM > To: codec@ietf.org > Subject: [codec] questions to be answered > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > RFC 5434 has a list of questions that need to be answered before a WG > is > formed, and I think we have fairly clear answers to these questions: > > 1. Is there a problem that needs solving? > > (Yes, see problem statement in charter.) > > 2. Is the scope of the problem well defined and understood? > > (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) > > 3. Is there agreement on what the WG needs to deliver? > > (Yes, see deliverables in charter, guidelines I-D, and requirements I- > D.) > > 4. Are there enough IETF participants to do the work? > > (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) > > 5. Does the WG have a reasonable probability of success? > > (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an > emphasis on "reasonable" because we won't know until we try.) > > 6. Is the IETF is the right place to do the work? > > (Maybe. I think this is the major item to clarify at the BoF.) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz > lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP > =3D9vPK > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Fri Oct 30 16:32:23 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B013A3A68DE for ; Fri, 30 Oct 2009 16:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 CIl9PwxoshYM for ; Fri, 30 Oct 2009 16:32:22 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 531243A689E for ; Fri, 30 Oct 2009 16:32:22 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSut3ll7TXAK27QjXL1/cU1dSj8eXG5pN@postini.com; Fri, 30 Oct 2009 16:32:40 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 30 Oct 2009 16:31:06 -0700 From: Michael Knappe To: Michael Knappe , Roni Even , Peter Saint-Andre , "codec@ietf.org" Date: Fri, 30 Oct 2009 16:31:38 -0700 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAAGkr5wAAI2QNA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 23:32:23 -0000 Also, I would suggest before Hiroshima we take a stab on email at writing o= ut a short list of both critical and non-critical technical criteria for ea= ch application (gaming, interactive music, voice communication, etc). By go= ing through this exercise it will help us all mentally group requirements a= nd should help simplify the overall problem definition (e.g. a) Which appli= cation's requirements are supersets of another, b) which application's requ= irements would have fundamental technical tradeoffs vs another, etc.). If w= e can narrow down the problem to a couple of fundamental codec 'description= s', that will be a big help, and if a one-size-fits-all codec is at all pos= sible, it should become easier to recognize. Mike On 10/30/09 4:15 PM, "Michael Knappe" wrote: Roni, On your latter points, how about a set of general benchmark requirements th= at all codecs must meet, followed by more stringent or more specific criter= ia to meet narrower requirements of a target application? This could be all= coupled together in a single requirements document. A single doc would mak= e it easier to lay out common test methodologies just once, followed by spe= cific application requirements broken out into separate subsequent sections= . Mike On 10/30/09 3:34 PM, "Roni Even" wrote: Hi Peter, I am not sure that there is a consensus about what the group need to deliver. I do not feel that the issue of the number of codecs and how to decide which codecs are in scope for this working group is agreed. My view that this issue is not addressed since I assume that all the parties that submitted candidate codecs would like their codecs to be approved at the IETF which will make this group a rubber stamping WG. I think that the if the charter describes a list of applications it need to have a separate requirement for each application on which this proposed group is going to develop a separate codec. If there is one requirement document for all apllications there should be one codec to address it. Thanks Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, October 30, 2009 10:12 PM > To: codec@ietf.org > Subject: [codec] questions to be answered > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > RFC 5434 has a list of questions that need to be answered before a WG > is > formed, and I think we have fairly clear answers to these questions: > > 1. Is there a problem that needs solving? > > (Yes, see problem statement in charter.) > > 2. Is the scope of the problem well defined and understood? > > (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) > > 3. Is there agreement on what the WG needs to deliver? > > (Yes, see deliverables in charter, guidelines I-D, and requirements I- > D.) > > 4. Are there enough IETF participants to do the work? > > (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) > > 5. Does the WG have a reasonable probability of success? > > (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an > emphasis on "reasonable" because we won't know until we try.) > > 6. Is the IETF is the right place to do the work? > > (Maybe. I think this is the major item to clarify at the BoF.) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz > lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP > =3D9vPK > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@usherbrooke.ca Fri Oct 30 17:42:34 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886523A688C for ; Fri, 30 Oct 2009 17:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=1.228, 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 XinerI8L7Vid for ; Fri, 30 Oct 2009 17:42:33 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 40DBF3A672E for ; Fri, 30 Oct 2009 17:42:33 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MO-MR005.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KSC00GZ7SN0YQ30@VL-MO-MR005.ip.videotron.ca> for codec@ietf.org; Fri, 30 Oct 2009 20:42:37 -0400 (EDT) Message-id: <4AEB87FC.8090307@usherbrooke.ca> Date: Fri, 30 Oct 2009 20:42:36 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: Roni Even References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> In-reply-to: <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 00:42:34 -0000 Roni, I don't believe anyone here intends the WG to produce more than one codec unless it turns out that doing so is the only way to achieve good coverage of the requirements. Would you like to see such a statement in the charter? Personally, I tend to see this question mostly as a technical issue that will be settled once the technical work gets started. Believe me, there's nothing I would like more than being able to address all the requirements we have with a single, unified codec. I also believe that's what you would also like so see, so we agree on this. Now technically, I am not yet sure that it is feasible to have a single codec that does everything we want to do. So I believe it is a possibility that we would end up with one codec (A) addressing one part of the requirements and another codec (B) addressing a second part of the requirements. Sure, we could decide to take those two codecs, put them in the same proposal and call that one big codec with two "profiles", but I don't think we would be gaining anything. At this point in time, saying that we will have a single codec would be assuming the output of the technical work before it has begun. It is the same issue with separating requirements. I assume that if we end up going with two codecs (which is not my first choice), we may need to split the requirements into two parts. However, at this point not only is it not clear that we will have more than one codec, but it is not clear where the split would be if there were to be more than one codec. I have a few ideas on how the split could be done, but I do not see how we could be choosing that split before actually working on the code. Cheers, Jean-Marc Roni Even a crit : > Hi Peter, > I am not sure that there is a consensus about what the group need to > deliver. I do not feel that the issue of the number of codecs and how to > decide which codecs are in scope for this working group is agreed. My view > that this issue is not addressed since I assume that all the parties that > submitted candidate codecs would like their codecs to be approved at the > IETF which will make this group a rubber stamping WG. > I think that the if the charter describes a list of applications it need to > have a separate requirement for each application on which this proposed > group is going to develop a separate codec. If there is one requirement > document for all apllications there should be one codec to address it. > > Thanks > Roni Even > > > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Peter Saint-Andre >> Sent: Friday, October 30, 2009 10:12 PM >> To: codec@ietf.org >> Subject: [codec] questions to be answered >> > RFC 5434 has a list of questions that need to be answered before a WG > is > formed, and I think we have fairly clear answers to these questions: > > 1. Is there a problem that needs solving? > > (Yes, see problem statement in charter.) > > 2. Is the scope of the problem well defined and understood? > > (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) > > 3. Is there agreement on what the WG needs to deliver? > > (Yes, see deliverables in charter, guidelines I-D, and requirements I- > D.) > > 4. Are there enough IETF participants to do the work? > > (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) > > 5. Does the WG have a reasonable probability of success? > > (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an > emphasis on "reasonable" because we won't know until we try.) > > 6. Is the IETF is the right place to do the work? > > (Maybe. I think this is the major item to clarify at the BoF.) > > Peter > _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From gregory.ietf@gmail.com Sat Oct 31 08:26:07 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1BD3A688A for ; Sat, 31 Oct 2009 08:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 L3Exq-3HTIwm for ; Sat, 31 Oct 2009 08:26:06 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 5CAEA3A67E9 for ; Sat, 31 Oct 2009 08:26:06 -0700 (PDT) Received: by gxk4 with SMTP id 4so2888820gxk.8 for ; Sat, 31 Oct 2009 08:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=x9vInbENXjVYXLWcwcxFI3FikpQrt9WyUcNsWcKOwjE=; b=sLx/MjBHgA4yiCgeIIy2n1jViHzYPSrn/s2YPur2ibpgwh2I/t74/WrNL6GCmS14Lp XwGbKq4q4p5QKUXQTJ+H+8HXwv55z8IsBiyTKS62dsXbc5Hm3pV86pEqhpgtNZy6zlIe eKUqryjNaccpm+oXzomtMQtIgbcOFKLmBkdLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=tOcAOThkuvz+ZSch8z3rMCXCO1FnlcF81Ot/+I6weHx0PvUkmJ5OaTTKImeaNr4+wk BMud3sBJQ37KK/NEl4+4F3s68z/QUOooHwJg8F0DJUl0cb7eOk3Y6mKKMXgqcyov5eWg WnZ6muMVR+MdgEB4Nf0ciP9hhTxFVQMvuWdXE= Received: by 10.91.144.16 with SMTP id w16mr7070410agn.21.1257002780586; Sat, 31 Oct 2009 08:26:20 -0700 (PDT) Received: from Gregory-T60.gmail.com (c-98-248-97-91.hsd1.ca.comcast.net [98.248.97.91]) by mx.google.com with ESMTPS id 15sm669156yxh.40.2009.10.31.08.26.17 (version=SSLv3 cipher=RC4-MD5); Sat, 31 Oct 2009 08:26:19 -0700 (PDT) Message-ID: <4aec571b.cf02be0a.36fb.4699@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 Oct 2009 08:26:14 -0700 To: Peter Saint-Andre ,"codec@ietf.org" From: "Gregory M. Lebovitz" In-Reply-To: <4AEB25DE.7020602@stpeter.im> References: <4AEB25DE.7020602@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [codec] *draft* agenda X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 15:26:07 -0000 At 10:43 AM 10/30/2009, Peter Saint-Andre wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Eric Burger and I have created a *draft* agenda for the Codec BoF. >Feedback is welcome! > >### > >1. Note Well & Agenda Bashing (5 minutes) > >2. Progress to Date (15 minutes) > a. BoF at IETF 75 established constituency and interest > b. Open issues: work process, requirements, ITU-T coordination > c. Several individual drafts published and discussed on the list > d. Coordination has occurred with ITU-T SG 16 s/has occurred/is occurring Justification: We have had a good call between IETF leaders and ITU-T SG 16 and other ITU-T leaders to ensure good coordination around this topic. I and Cullen are drafting a formal Liaison to the ITU-T, which is being reviewed by the IAB and will be sent this weekend. But this effort will entail continued and on-going coordination with ITU-T, as they have much to offer in this process. Gregory. > e. Consensus converging around draft charter > >3. Key Question to Answer: Is IETF the Right Forum? (45 minutes) Possible restatement: "Does IETF have a reasonable chance of success compared to other forums?" Justification: The term "Right" is overloaded. Right based on what criteria? It's not that black and white. But we may or may not have a more reasonable chance of success _meeting the stated goals_ compared to other forums. That's not right or wrong, its more objective. > a. Informational presentation about ITU-T Study Group 16 > b. Informational presentation about IETF Codec WG > c. Discussion about alternatives > d. Determination of consensus > >4. If IETF Is or Might Be the Right Forum: Charter Bashing (45 minutes) > a. Problem statement > b. Objectives > c. Deliverables > d. Milestones > >5. Key WG Formation Hums (10 minutes) > a. Is IETF the best place to do this work? > b. If a WG is formed, will you write drafts? > c. If a WG is formed, will you review drafts? Do we need to add: "If a WG is formed, will you test and characterize candidate code?" ? I think we've made a lot of progress on this agenda, and I look forward to a constructive and interesting BoF. Gregory > d. If a WG is formed, will you otherwise participate? > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.8 (Darwin) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >iEYEARECAAYFAkrrJd4ACgkQNL8k5A2w/vzbEACfYZZEmxOpuXLqS5L9RvjtoaKA >5Q8AmgLXzYojvvSH3kvsUFQK/VGlvkLn >=NoNR >-----END PGP SIGNATURE----- >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From gregory.ietf@gmail.com Sat Oct 31 08:36:46 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437553A68F0 for ; Sat, 31 Oct 2009 08:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdXD0-OmntUk for ; Sat, 31 Oct 2009 08:36:45 -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 2613E3A67E9 for ; Sat, 31 Oct 2009 08:36:44 -0700 (PDT) Received: by ywh13 with SMTP id 13so4010127ywh.29 for ; Sat, 31 Oct 2009 08:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:cc:in-reply-to:references:mime-version:content-type :content-transfer-encoding; bh=owyTBQCikSWqrgL9r3MlxqFb9yyT5JTw5paj58QO7Wg=; b=s5H4hKlX9Zj27lQRObsZWUBIQsNDPLFzhEdn3NVzgqBdEIajgZeidPFiCAlugNaCTe AhhjKRCJl8D0JuzKcWZeTP5xjSpoufIOknnfTJLk8/JXQ1tTKOVEKBvbJFEOhgukL9V9 4JQHQ4ZRz/DsBjNjX1Z3K8cPILVGNba2gFRRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:cc:in-reply-to:references :mime-version:content-type:content-transfer-encoding; b=m1Ccv42Y0pzueznN2sCp+Iyo8ncKvEpdIdB0RXT/QAwtW5UlMi/5lo5iOd7PUYFxKC UsG4L51cNE4NsYSH/xNakFh0lVnsWreItptT6zObILDk9KUcMP4qBCXGjnavO4cH9lOo uQr2nKeLAtKOn8F0YxYQ31rqLVUi5gkyyLUd4= Received: by 10.91.103.17 with SMTP id f17mr6623343agm.114.1257003420412; Sat, 31 Oct 2009 08:37:00 -0700 (PDT) Received: from Gregory-T60.gmail.com (c-98-248-97-91.hsd1.ca.comcast.net [98.248.97.91]) by mx.google.com with ESMTPS id 23sm1808093yxe.36.2009.10.31.08.36.58 (version=SSLv3 cipher=RC4-MD5); Sat, 31 Oct 2009 08:36:59 -0700 (PDT) Message-ID: <4aec599b.1702be0a.69df.ffffc126@mx.google.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 31 Oct 2009 08:36:55 -0700 To: Jean-Marc Valin , Roni Even From: "Gregory M. Lebovitz" In-Reply-To: <4AEB87FC.8090307@usherbrooke.ca> References: <4AEB4882.4030004@stpeter.im> <4aeb6a09.01b7660a.346b.ffffacde@mx.google.com> <4AEB87FC.8090307@usherbrooke.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 15:36:46 -0000 I would be comfortable with chartering for 1 or 2=20 codecs, under the assumption that one-size does=20 not fit all in the world of codecs, and believing=20 that we could define one or two application=20 spaces that cover a very large need and market=20 demand for a application or group of=20 applications. Sure, there are probably a handful=20 or so different applications that in order to=20 cover excellently would require different and=20 specific codec technologies, but I think we need=20 to focus, deploy, evaluate, and then determine next steps here. I would oppose a charter that tries to do more=20 than one or two applications with corresponding codecs. I'm most comfortable with one, but could see the=20 need for two, and would be willing to live with a charter that included two. Gregory At 05:42 PM 10/30/2009, Jean-Marc Valin wrote: >Roni, > >I don't believe anyone here intends the WG to produce more than one >codec unless it turns out that doing so is the only way to achieve good >coverage of the requirements. Would you like to see such a statement in >the charter? Personally, I tend to see this question mostly as a >technical issue that will be settled once the technical work gets >started. Believe me, there's nothing I would like more than being able >to address all the requirements we have with a single, unified codec. I >also believe that's what you would also like so see, so we agree on >this. Now technically, I am not yet sure that it is feasible to have a >single codec that does everything we want to do. So I believe it is a >possibility that we would end up with one codec (A) addressing one part >of the requirements and another codec (B) addressing a second part of >the requirements. Sure, we could decide to take those two codecs, put >them in the same proposal and call that one big codec with two >"profiles", but I don't think we would be gaining anything. At this >point in time, saying that we will have a single codec would be assuming >the output of the technical work before it has begun. > >It is the same issue with separating requirements. I assume that if we >end up going with two codecs (which is not my first choice), we may need >to split the requirements into two parts. However, at this point not >only is it not clear that we will have more than one codec, but it is >not clear where the split would be if there were to be more than one >codec. I have a few ideas on how the split could be done, but I do not >see how we could be choosing that split before actually working on the= code. > >Cheers, > > Jean-Marc > > >Roni Even a =E9crit : > > Hi Peter, > > I am not sure that there is a consensus about what the group need to > > deliver. I do not feel that the issue of the number of codecs and how to > > decide which codecs are in scope for this working group is agreed. My= view > > that this issue is not addressed since I assume that all the parties= that > > submitted candidate codecs would like their codecs to be approved at the > > IETF which will make this group a rubber stamping WG. > > I think that the if the charter describes a list of applications it need= to > > have a separate requirement for each application on which this proposed > > group is going to develop a separate codec. If there is one requirement > > document for all apllications there should be one codec to address it. > > > > Thanks > > Roni Even > > > > > > > >> -----Original Message----- > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > >> Of Peter Saint-Andre > >> Sent: Friday, October 30, 2009 10:12 PM > >> To: codec@ietf.org > >> Subject: [codec] questions to be answered > >> > > RFC 5434 has a list of questions that need to be answered before a WG > > is > > formed, and I think we have fairly clear answers to these questions: > > > > 1. Is there a problem that needs solving? > > > > (Yes, see problem statement in charter.) > > > > 2. Is the scope of the problem well defined and understood? > > > > (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) > > > > 3. Is there agreement on what the WG needs to deliver? > > > > (Yes, see deliverables in charter, guidelines I-D, and requirements I- > > D.) > > > > 4. Are there enough IETF participants to do the work? > > > > (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) > > > > 5. Does the WG have a reasonable probability of success? > > > > (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an > > emphasis on "reasonable" because we won't know until we try.) > > > > 6. Is the IETF is the right place to do the work? > > > > (Maybe. I think this is the major item to clarify at the BoF.) > > > > Peter > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Sat Oct 31 08:44:36 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E143A68C1 for ; Sat, 31 Oct 2009 08:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 QVm5gB2GL0ZD for ; Sat, 31 Oct 2009 08:44:35 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id BF35A3A6883 for ; Sat, 31 Oct 2009 08:44:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSuxbcmx2R/VKwNMuKYOoDG847Ec/C5XW@postini.com; Sat, 31 Oct 2009 08:44:53 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Sat, 31 Oct 2009 08:42:26 -0700 From: Michael Knappe To: Roni Even , Peter Saint-Andre , "codec@ietf.org" Date: Sat, 31 Oct 2009 08:42:59 -0700 Thread-Topic: [codec] questions to be answered Thread-Index: AcpZnTqEV25t1RdeRBS545RyRDvP3QAExzbgAAGkr5wAAI2QNAAh7IsN Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] questions to be answered X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 15:44:36 -0000 I will take a rough first crack at a codec application vs criteria table an= d have it out to the list for discussion on Monday Nov 2nd. Cheers, Mike On 10/30/09 4:31 PM, "Michael Knappe" wrote: Also, I would suggest before Hiroshima we take a stab on email at writing o= ut a short list of both critical and non-critical technical criteria for ea= ch application (gaming, interactive music, voice communication, etc). By go= ing through this exercise it will help us all mentally group requirements a= nd should help simplify the overall problem definition (e.g. a) Which appli= cation's requirements are supersets of another, b) which application's requ= irements would have fundamental technical tradeoffs vs another, etc.). If w= e can narrow down the problem to a couple of fundamental codec 'description= s', that will be a big help, and if a one-size-fits-all codec is at all pos= sible, it should become easier to recognize. Mike On 10/30/09 4:15 PM, "Michael Knappe" wrote: Roni, On your latter points, how about a set of general benchmark requirements th= at all codecs must meet, followed by more stringent or more specific criter= ia to meet narrower requirements of a target application? This could be all= coupled together in a single requirements document. A single doc would mak= e it easier to lay out common test methodologies just once, followed by spe= cific application requirements broken out into separate subsequent sections= . Mike On 10/30/09 3:34 PM, "Roni Even" wrote: Hi Peter, I am not sure that there is a consensus about what the group need to deliver. I do not feel that the issue of the number of codecs and how to decide which codecs are in scope for this working group is agreed. My view that this issue is not addressed since I assume that all the parties that submitted candidate codecs would like their codecs to be approved at the IETF which will make this group a rubber stamping WG. I think that the if the charter describes a list of applications it need to have a separate requirement for each application on which this proposed group is going to develop a separate codec. If there is one requirement document for all apllications there should be one codec to address it. Thanks Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Peter Saint-Andre > Sent: Friday, October 30, 2009 10:12 PM > To: codec@ietf.org > Subject: [codec] questions to be answered > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > RFC 5434 has a list of questions that need to be answered before a WG > is > formed, and I think we have fairly clear answers to these questions: > > 1. Is there a problem that needs solving? > > (Yes, see problem statement in charter.) > > 2. Is the scope of the problem well defined and understood? > > (Yes, see objectives in charter, guidelines I-D, and requirements I-D.) > > 3. Is there agreement on what the WG needs to deliver? > > (Yes, see deliverables in charter, guidelines I-D, and requirements I- > D.) > > 4. Are there enough IETF participants to do the work? > > (Yes, see codec I-Ds, poll at Stockholm BoF, and list discussion.) > > 5. Does the WG have a reasonable probability of success? > > (Yes, see codec I-Ds, guidelines I-D, and list discussion, with an > emphasis on "reasonable" because we won't know until we try.) > > 6. Is the IETF is the right place to do the work? > > (Maybe. I think this is the major item to clarify at the BoF.) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkrrSIIACgkQNL8k5A2w/vxzmQCeINOY/RWKd924HGWH8p4BJmUz > lHIAnAwhO+Htb6Cxne9b9w/1WEnaRlgP > =3D9vPK > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec