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

Qin Wu <sunseawq@huawei.com> Thu, 09 December 2010 07:41 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 D7F943A6A48 for <avt@core3.amsl.com>; Wed, 8 Dec 2010 23:41:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.052
X-Spam-Level:
X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 Q1pGFFV846RB for <avt@core3.amsl.com>; Wed, 8 Dec 2010 23:41:02 -0800 (PST)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id EAC933A6851 for <avt@ietf.org>; Wed, 8 Dec 2010 23:41:01 -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 <0LD500J45HEKZP@szxga05-in.huawei.com> for avt@ietf.org; Thu, 09 Dec 2010 15:42:20 +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 <0LD5003PDHEJKH@szxga05-in.huawei.com> for avt@ietf.org; Thu, 09 Dec 2010 15:42:20 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LD500DIKHEJW7@szxml04-in.huawei.com> for avt@ietf.org; Thu, 09 Dec 2010 15:42:19 +0800 (CST)
Date: Thu, 09 Dec 2010 15:42:19 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Glen Zorn <gwz@net-zen.net>
Message-id: <033001cb9774$9bda5a10$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_cEwPhJXGuy0bo5tsvCiYUg)"
X-Priority: 3
X-MSMail-priority: Normal
References: <02a701cb8d24$d50450c0$30298a0a@china.huawei.com> <000001cb96b1$34ab9930$9e02cb90$@net>
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: Thu, 09 Dec 2010 07:41:04 -0000

Hi,
  ----- Original Message ----- 
  From: Glen Zorn 
  To: 'Qin Wu' 
  Cc: avt@ietf.org 
  Sent: Wednesday, December 08, 2010 4:23 PM
  Subject: RE: Review of draft-ietf-avt-rtp-g718-03


  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. 

   

  [Qin]: Looks good to me.



  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.

   

  [Qin]: I believe they are same.



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



  [Qin]: Okay. Maybe this section 3.5 is also duplicated and can be removed.



  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? 



  [Qin]: Suggest to put a reference RFC6051 behind the first sentence of section 3.6.

  Suggest to put a reference RFC3550 following the last sentence of section 3.6.



  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. 



  [Qin]: Agree. It is better to rephrase text a little bit to reflect this difference. 



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

  Don't know.



  [Qin]: We are on the same page. It depends on how EDU is organized in the payload or transport block.

  Discarding an entire payload along with all associated EDUs means discarding all the highest layer EDUs encapsulated in each transport block carried by payload.

  Their difference is

  one is discarding one transport block containing highest layer data while the other is discarding all the transport block containing highest layer EDUs.

   

  Regards!

  -Qin