Re: [AVT] Review of draft-ietf-avt-rtp-g718-03
"Glen Zorn" <gwz@net-zen.net> Wed, 08 December 2010 08:22 UTC
Return-Path: <gwz@net-zen.net>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE37A3A6920 for <avt@core3.amsl.com>; Wed, 8 Dec 2010 00:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.293
X-Spam-Level:
X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMjoBZC7rMR6 for <avt@core3.amsl.com>; Wed, 8 Dec 2010 00:22:16 -0800 (PST)
Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id 101AE3A6919 for <avt@ietf.org>; Wed, 8 Dec 2010 00:22:15 -0800 (PST)
Received: (qmail 26285 invoked from network); 8 Dec 2010 08:23:42 -0000
Received: from unknown (124.120.74.144) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 08 Dec 2010 08:23:40 -0000
From: Glen Zorn <gwz@net-zen.net>
To: 'Qin Wu' <sunseawq@huawei.com>
References: <02a701cb8d24$d50450c0$30298a0a@china.huawei.com>
In-Reply-To: <02a701cb8d24$d50450c0$30298a0a@china.huawei.com>
Date: Wed, 08 Dec 2010 15:23:30 +0700
Organization: Network Zen
Message-ID: <000001cb96b1$34ab9930$9e02cb90$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CB96EB.E10A7130"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuNJNhzeME1PtNFQPOIwHwN0LHWowJhud8g
Content-Language: en-us
Cc: avt@ietf.org
Subject: Re: [AVT] Review of draft-ietf-avt-rtp-g718-03
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2010 08:22:23 -0000
Qin Wu [mailto:sunseawq@huawei.com] writes: Hi, I have read draft-ietf-avt-rtp-g718-03 and have some editorial comments as follows: Section 2.1: It is not clear to me the meaning of "together with L1' , modified L3' is used instead of L3" described in section 2.1, do you mean that enhancement layer 3' depends on L1'? It means that if L1' is used, L3' is used instead of L3. Does this change help? OLD: The G.718 codec also includes an operating mode that is compatible with the Adaptive Multi-Rate Wideband (AMR-WB) codec [AMR-WB], for which the RTP payload format is specified in [RFC4867]. In this AMR- WB interoperable mode, layers L1 and L2 are replaced by L1' consisting of AMR-WB encoded data. Furthermore, together with L1'. modified L3' is used instead of L3. The usage of layers L4 and L5 is not affected by transmitting AMR-WB data in the lower layers. NEW: The G.718 codec also includes an operating mode that is compatible with the Adaptive Multi-Rate Wideband (AMR-WB) codec [AMR-WB], for which the RTP payload format is specified in [RFC4867]. In this AMR- WB interoperable mode, layers L1 and L2 are replaced by L1' consisting of AMR-WB encoded data and L3' is used instead of L3. The usage of layers L4 and L5 is not affected by transmitting AMR-WB data in the lower layers. Section 2.3: It will be useful to add a reference to draft-ietf-avt-rtp-svc-24 in the section 2.3, since draft-ietf-avt-rtp-svc-24 firstly defines two basic modes for transmission of SVC data, single session transmission (SST) and multi-session transmission (MST). True, but it seems to me that the only qualities that the two documents share are the acronym ;-) - it's not clear to me that what MST means in the SVC draft is really similar to what is meant in the G.718 draft. Section 2.4: "Scaling scenarios & rate control" rephrase the following sentence of section 2.4 " 3. An intermediate network element passes forward only a subset of layers it receives " as " 3. An intermediate network element passes through only a subset of layers it receives " OK. It will be useful in the section 2.4 to add anchor points to section 3.3 "G.718 scaling " and section 6 "Congestion Control" Since section 2.4 or merge section 2.4, 3.3 and section 6 together, since section 2.4 talks about who do rate control, section 3.3 and section 6 talks about which way can be used to perform rate control, i.e., payload thinning or dropping. Merging the 3 sections seems reasonable to me; any suggestions for a title? Section 3.5 It will be useful to explain when G.718 session consist of only one session and when G.718 session consists of more than one session. I think the right answer can be found in the section 2.3. Why do we need to repeat it then? Section 3.6 It will be useful to add reference to RFC3550 and RFC6051 since RFC3550 defines sender Report and RFC6051 talks about how to reduce the synchronisation delay for RTP sessions. Where? Section 6 "Congestion Control" It is not clear what's the difference between payload carrying EDUs and Transport Block carrying EDUs since payload consists of a payload header, followed by one or more transport blocks? In this context, I believe that the difference lies in discarding an entire payload along with all associated EDUs and discarding a subset of the associated EDUs. Are you saying in Multiple Session Transmission mode, some payloads are dedicated to carry only high layer data EDU? Don't know. these payload MUST be discarded? No. Regards! -Qin