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

Qin Wu <sunseawq@huawei.com> Fri, 10 December 2010 07:33 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 E2AA23A6A2B for <avt@core3.amsl.com>; Thu, 9 Dec 2010 23:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.048
X-Spam-Level:
X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-1.211, 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 W36lfy3mnI+L for <avt@core3.amsl.com>; Thu, 9 Dec 2010 23:33:20 -0800 (PST)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 9C2A73A6A17 for <avt@ietf.org>; Thu, 9 Dec 2010 23:33:18 -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 <0LD700M2QBPQZC@szxga05-in.huawei.com> for avt@ietf.org; Fri, 10 Dec 2010 15:34:39 +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 <0LD7000Y1BPQQ5@szxga05-in.huawei.com> for avt@ietf.org; Fri, 10 Dec 2010 15:34:38 +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 <0LD7000QHBPPLG@szxml06-in.huawei.com> for avt@ietf.org; Fri, 10 Dec 2010 15:34:38 +0800 (CST)
Date: Fri, 10 Dec 2010 15:34:37 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Glen Zorn <gwz@net-zen.net>
Message-id: <002501cb983c$b301f220$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_EzueuWjFkqOod7p3zJwD5Q)"
X-Priority: 3
X-MSMail-priority: Normal
References: <02a701cb8d24$d50450c0$30298a0a@china.huawei.com> <000001cb96b1$34ab9930$9e02cb90$@net> <033001cb9774$9bda5a10$30298a0a@china.huawei.com> <003b01cb9782$92d5aa10$b880fe30$@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: Fri, 10 Dec 2010 07:33:22 -0000

Hi,
  ----- Original Message ----- 
  From: Glen Zorn 
  To: 'Qin Wu' 
  Cc: avt@ietf.org 
  Sent: Thursday, December 09, 2010 5:22 PM
  Subject: RE: Review of draft-ietf-avt-rtp-g718-03


    Qin Wu [mailto://sunseawq@huawei.com] writes: 

    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.

    Maybe it's just my ignorance, but I don't see how they are the same outside of the fact that multiple RTP sessions are used to transport data:  

    1.   SVC is video data, but G.718 is an audio codec

    2.   draft-ietf-avt-rtp-svc-24 defines 4 modes of MST, differing in "whether or not they allow interleaving,   i.e., transmitting Network Abstraction Layer (NAL) units in an order  different than the decoding order, and by the technique used to  effect inter-session NAL unit decoding order recovery", but I believe that the NAL construct  is specific to H.264

    Given these differences, it seems more confusing than enlightening to insert a reference to draft-ietf-avt-rtp-svc-24, but I'm hardly an expert.

    .



    [Qin]: Sounds reasonable to me. maybe draft-ietf-avt-rtp-svc-24 should firstly define MST and SST as two generialized acronyms, and then draft-ietf-avt-rtp-g718-03 can refer to such acronym in the draft-ietf-avt-rtp-svc-24.

     

    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.

    I don't think that it can actually be removed, since it's the only place where "G.718 session" is defined; maybe move it somewhere else?  As an aside, it seems like normative and informative  text is kind of all mixed together; maybe it would be worth some effort to restructure the draft for a clearer separation?

     

    [Qin]: Okay.



    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.

    OK.

     

    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. 

    OK, how's this:

       The following means (in no particular order) can be used to assist

       congestion control procedures -- either by the sender or by the

       intermediate node.

     

       o  The payloads carrying the EDUs representing the highest layers in

          an G.718 session can be dropped, along with all associated

          transport blocks

     

       o  The transport blocks carrying the EDUs representing the highest

          layers within the payload can be dropped

     

       o  Transport blocks or payloads carrying EDUs belonging to redundant

          frames included in the payload can be dropped

     

    [Qin]: It is much better than the original text.

     

    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