[AVT] Review of draft-ietf-avt-rtp-g718-03

Qin Wu <sunseawq@huawei.com> Fri, 26 November 2010 04:31 UTC

Return-Path: <sunseawq@huawei.com>
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 0BFC028C125 for <avt@core3.amsl.com>; Thu, 25 Nov 2010 20:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.704
X-Spam-Level:
X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=1.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plrqp4ejPhlS for <avt@core3.amsl.com>; Thu, 25 Nov 2010 20:31:30 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1A7D23A69CD for <avt@ietf.org>; Thu, 25 Nov 2010 20:31:30 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCH00KQ25XYRB@szxga05-in.huawei.com> for avt@ietf.org; Fri, 26 Nov 2010 12:32:22 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCH005135XX44@szxga05-in.huawei.com> for avt@ietf.org; Fri, 26 Nov 2010 12:32:22 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCH007T55XXE4@szxml06-in.huawei.com> for avt@ietf.org; Fri, 26 Nov 2010 12:32:21 +0800 (CST)
Date: Fri, 26 Nov 2010 12:32:21 +0800
From: Qin Wu <sunseawq@huawei.com>
To: avt@ietf.org
Message-id: <025b01cb8d22$eab92dc0$30298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/alternative; boundary="Boundary_(ID_u9RyXddOnE63VhVZYVcT8g)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [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: Fri, 26 Nov 2010 04:31:32 -0000

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'?

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).  

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

"
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.

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.

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.

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?

Are you saying in Multiple Session Transmission mode, some payloads are dedicated to carry only high layer data EDU?
these payload MUST be discarded?

Regards!
-Qin