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