Re: [codec] WGLC of draft-ietf-codec-opus-07

"Timothy B. Terriberry" <tterribe@xiph.org> Sun, 24 July 2011 17:04 UTC

Return-Path: <prvs=179da5468=tterribe@xiph.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF9521F85F6 for <codec@ietfa.amsl.com>; Sun, 24 Jul 2011 10:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level:
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBRMohoE7eBY for <codec@ietfa.amsl.com>; Sun, 24 Jul 2011 10:04:56 -0700 (PDT)
Received: from mxip1i.isis.unc.edu (mxip1i.isis.unc.edu [152.2.0.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4F44921F85C0 for <codec@ietf.org>; Sun, 24 Jul 2011 10:04:56 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAL5PLE6sGgRS/2dsb2JhbAA1AQEDAQE4AQVGAQUMDCEiDwkDAgECAQJRFQEOAqZbgWeIfAS8coY/BIdVixuEeA+LeQ
X-IronPort-AV: E=Sophos;i="4.67,257,1309752000"; d="scan'208";a="171696982"
Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip1o.isis.unc.edu with ESMTP; 24 Jul 2011 13:04:55 -0400
X-UNC-Auth-As: tterribe
X-UNC-Auth-IP: 70.25.120.2
Received: from [10.255.255.180] ([70.25.120.2]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p6OH4l3G028111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <codec@ietf.org>; Sun, 24 Jul 2011 13:04:52 -0400 (EDT)
Message-ID: <4E2C50A9.3000804@xiph.org>
Date: Sun, 24 Jul 2011 10:04:41 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10
MIME-Version: 1.0
CC: codec@ietf.org
References: <D0DF9C6A-8344-46CF-A8E3-E2BA90EC2149@cisco.com> <4E26B5E3.8070107@jdrosen.net> <000001cc4920$4a72cb40$df5861c0$@uni-tuebingen.de> <000001cc49a3$328ed4a0$97ac7de0$@uni-tuebingen.de> <CAFgjPJ9svm+UXGEhoc4j=jQ0AGUqLJ_wDpW+mYenS36nZiAg5g@mail.gmail.com>
In-Reply-To: <CAFgjPJ9svm+UXGEhoc4j=jQ0AGUqLJ_wDpW+mYenS36nZiAg5g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [codec] WGLC of draft-ietf-codec-opus-07
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jul 2011 17:04:57 -0000

> I skimmed through the draft, mainly because it is a complicated one

Thanks for the review. Any specific feedback is appreciated.

> * Just below, in the same paragraph:
> «
> The
>     length of the first frame, N1, MUST be no larger than the size of the
>     payload remaining after decoding that length for all code 2 packets.
> »
> =>  I am not sure what it means? Aren't we simply telling that the
> advertised length must not be larger than the actual length (which
> appears logical to be by "definition" of "length")?

Yes, or equivalently, that the implied length of the second frame in 
that packet cannot be negative. The MUST requirement is mainly to ensure 
that packets which describe such a situation are properly rejected (cf. 
"A receiver MUST NOT process packets which violate these rules as normal 
Opus packets," above).

>>> has some (minor) bugs, and the codec supports things that should be done
>> in
>>> the payload such as frame and a feature called "padding".
>>>
>
> Also probably a stupid question for someone new here, but I wondered:
> what is exactly the role of padding? Is there an interest to have a
> fixed size of packets on some platform for instance?

The variation in packet lengths can be used to recover some of the 
information (up to, in low-vocabulary situations, complete spoken 
words), even if the content is encrypted. See the wright08 reference in 
http://tools.ietf.org/html/draft-ietf-codec-requirements-04 or the more 
recent http://www.ieee-security.org/TC/SP2011/PAPERS/2011/paper001.pdf

A padding mechanism ensures that this information leak can be 
eliminated. It is explicitly done at the codec layer because the 
presence and/or size of padding may be visible at the transport layer. 
For example, SRTP does not encrypt the RTP header, meaning that the 
RTP-level padding bit is sent in the clear.

I've addressed your other comments in my local version of the draft. 
I'll make sure those edits make it into the next revision.