Re: [ppsp] WGLC for the survey draft

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Thu, 28 November 2013 06:25 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B3E1AE129 for <ppsp@ietfa.amsl.com>; Wed, 27 Nov 2013 22:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnmDTYZzrYoM for <ppsp@ietfa.amsl.com>; Wed, 27 Nov 2013 22:25:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04B1AE10B for <ppsp@ietf.org>; Wed, 27 Nov 2013 22:25:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAU22288; Thu, 28 Nov 2013 06:25:46 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 06:25:15 +0000
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 28 Nov 2013 06:25:45 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 14:25:39 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: yunfei zhang <hishigh@gmail.com>, "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: [ppsp] WGLC for the survey draft
Thread-Index: AQHO6qgU23QibfvjxUWMjwZIWxFpfJo6LCcw
Date: Thu, 28 Nov 2013 06:25:39 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB459068EB@nkgeml501-mbs.china.huawei.com>
References: <CAHJOc1CQ+sxe1ZbATb2MrNeBUE98GT1x6AQ4_Q=qCKk0+9yGMw@mail.gmail.com>
In-Reply-To: <CAHJOc1CQ+sxe1ZbATb2MrNeBUE98GT1x6AQ4_Q=qCKk0+9yGMw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.94]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB459068EBnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [ppsp] WGLC for the survey draft
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp/>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2013 06:25:52 -0000

Hi,

I have reviewed this drafts, and have following comments:


1.       The description in the last paragraph of Section 1 is inconsistent with the organization of chapters . This should be fixed.

2.       In section 2, some terminologies have already defined in RFC6972. It¡¯s unnecessary to repeat the definition, e.g., chunk, live streaming¡­

3.       Section 1 typo: ¡°we always try to identity tracker and peer protocols¡± should be ¡°we always try to identify tracker and peer protocols¡±

4.       Section 3.1, typo ¡°this may turn at end users into playback quality degradation¡± should be ¡°this may turn end users into playback quality degradation¡±


Best regards,
Rachel

From: ppsp [mailto:ppsp-bounces@ietf.org] On Behalf Of yunfei zhang
Sent: Tuesday, November 26, 2013 9:05 PM
To: ppsp@ietf.org
Subject: [ppsp] WGLC for the survey draft


Hi all,
    According to the consensus of last IETF, we'll start a second round of WGLC for the survey draft:
http://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/
    The WGLC will last for 2 weeks before submitting for next step of standardization.
     Your review are highly appreciated. Please note that your comments and suggestions are very important for the forming of the RFC as well as the development of the WG. Thanks.

BR
Yunfei
---------- Forwarded message ----------
From: Zongning <zongning@huawei.com<mailto:zongning@huawei.com>>
Date: 2013/11/25
Subject: [ppsp] Meeting minutes
To: "ppsp@ietf.org<mailto:ppsp@ietf.org>" <ppsp@ietf.org<mailto:ppsp@ietf.org>>
Hi, Folks,

Sorry for the belated minutes and thanks Roni for taking the notes. Please see below and let us know any corrects needed.

===========================================================
PPSP Session@IETF 88

Plaza C,Tuesday Afternoon Session III, Nov 5, 2013



16:10 Agenda bashing (Chairs, 5 minutes)

No comments



16:15 Status of the WG (Chairs, 10 minutes)

1)  Peer draft ¨C more review needed, especially on security and encoding perspectives.

2)  Tracker base draft ¨C need author team to progress the draft faster, more calls are needed.

3£©Survey draft ¨C need 2nd WGLC before submitting to IESG.



16:25 Peer Protocol (Arno remotely,50 minutes), draft-ietf-ppsp-peer-protocol-08

1)  New revision has addressed all comments from AD review.

2)  Some comments from Roni need to be addressed, e.g. if peer protocol need to define how to do NAT traversal. To be discussed on the list.

3)  Chunk size issue from Yunfei?
4)  Chunk addressing issue ¨C negotiation is better.
Lingli: in the latest version, the part for online translation between communicating peers using different chunk addressing schemes are removed. Why?
A: It is too complicated and not necessary.


17:15 Tracker Protocol (Rui remotely, 50 minutes), draft-ietf-ppsp-base-tracker-protocol-02

1)  In the draft, still XML format in main body. Need to move XML example to appendix with more references.
Yunfei: The new version doesn¡¯t reflect the consensus made in the last meeting, which is to move the encoding issues to the appendix while keep the main body to just define messages. Currently the messages are still text based. Is there any consideration on the situation where different encodings are used? E.g., some peers use text encoding while others use binary.
Lingli: There is different understanding between Rui and the other co-authors. By binary encoding, Rui thinks it¡¯s the binary encoding of the XML, while others think it¡¯s the binary encoding of the tracker protocol. There are standards from ISO for binary encoding of XML, which is EXI.
Yunfei: But EXI can¡¯t do the translation between binary encoding of the messages to XML of the messages.
Lingli: Websocket has similar mechanisms to do this kind of translation. We can reference it. I can help with the new version.



18:05 Efficient Chunk Availability Compression (Lingli,20 minutes), draft-deng-ppsp-bfbitmap-03

Arno: in reality, streaming downloading happens sequentially, hence scope-based schemes works well.

A: in VoD cases, user behavior can interrupt the sequential viewing pattern. And even in live streaming case, because the concurrently peer-to-peer downloading pattern, out-of-order chunk transmission is inevitable.

Dave: what is the objective of introducing BF scheme?

A: the motive is elaborated in the last meeting¡¯s presentation. There is an comparison of the worst case performance of different bitmap compression schemes in terms of various bitmap relevant operations in PPSP.

Arno: in peer protocol, peers don¡¯t share bitmaps, only chunk ranges updates are exchanged. Peer protocol doesn¡¯t need bitmap compression.

A: ranges or updates are special forms of compression. BF scheme can be introduced into peer protocol as a new chunk addressing method.



open issue 1 ¨C looks like the proposed option is better no need to translation

Open issue 2 ¨C looks like it is helpful to include content scope into requests, but not to the responses.

No adoption at the moment. Need more mailing list discussion and offline with the tracker protocol author.



Rachel: in extended tracker protocol, the content scope information is already incorporated in the requests. But if we incorporate the same information into the responses, it would be duplicated with the subsequent peer information handshaking.

Ning: Would it be possible to increase neighborhood establishment by always including SEEDER peers in response?

A: I think it make sense to do so to ensure FIND always hit, as long as the specific content range in need is incorporated in corresponding requests.



18:25 Conclusion and next step (Chairs, 10 minutes)

Peer draft needs more review. Tracker base draft needs call between co-authors to progress the draft faster. 2nd WGLC on survey draft starts soon.



18:35 End

===================================================

Thanks,

-Yunfei & Ning.




_______________________________________________
ppsp mailing list
ppsp@ietf.org<mailto:ppsp@ietf.org>
https://www.ietf.org/mailman/listinfo/ppsp