[ppsp] 答复: Draft-ietf-ppsp-req-01
Ning Zong <zongning@huawei.com> Wed, 16 March 2011 00:48 UTC
Return-Path: <zongning@huawei.com>
X-Original-To: ppsp@core3.amsl.com
Delivered-To: ppsp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7BA3A6BDB for <ppsp@core3.amsl.com>; Tue, 15 Mar 2011 17:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.655
X-Spam-Level:
X-Spam-Status: No, score=-97.655 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, 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 xRMQUpEuPQ9x for <ppsp@core3.amsl.com>; Tue, 15 Mar 2011 17:47:59 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3220E3A6A19 for <ppsp@ietf.org>; Tue, 15 Mar 2011 17:47:59 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI4008FLKXXUX@szxga04-in.huawei.com> for ppsp@ietf.org; Wed, 16 Mar 2011 08:49:09 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI400G28KXXF5@szxga04-in.huawei.com> for ppsp@ietf.org; Wed, 16 Mar 2011 08:49:09 +0800 (CST)
Received: from z63316a ([10.138.41.23]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI4001XXKXTDQ@szxml04-in.huawei.com> for ppsp@ietf.org; Wed, 16 Mar 2011 08:49:09 +0800 (CST)
Date: Wed, 16 Mar 2011 08:49:05 +0800
From: Ning Zong <zongning@huawei.com>
In-reply-to: <C58FFCAAA14F454A85AFB7C1C2F862C401998731@DEMUEXC013.nsn-intra.net>
To: "'Schmidt, Christian 1. (NSN - DE/Munich)'" <christian.1.schmidt@nsn.com>, 'ext zhangyunfei' <zhangyunfei@chinamobile.com>, ppsp@ietf.org
Message-id: <002601cbe373$f3bcec20$db36c460$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_tvKwYosNSOjf7JEsKVEFbQ)"
Content-language: zh-cn
Thread-index: AcvMtEPEmNRn+yPTQ+ClbxGwB3Ot6QHZwv/QAAFhUqAAGE8+0AIKw4DAACDdMFAACoWTEAGGF3MQ
References: <201101180955204217745@chinamobile.com> <C58FFCAAA14F454A85AFB7C1C2F862C40168CE4E@DEMUEXC013.nsn-intra.net> <201101181419275009728@chinamobile.com> <C58FFCAAA14F454A85AFB7C1C2F862C401730366@DEMUEXC013.nsn-intra.net> <201101311644379687165@chinamobile.com> <C58FFCAAA14F454A85AFB7C1C2F862C401799919@DEMUEXC013.nsn-intra.net> <201102151000498905239@chinamobile.com> <C58FFCAAA14F454A85AFB7C1C2F862C401900150@DEMUEXC013.nsn-intra.net> <007801cbd482$d39d9cf0$7ad8d6d0$@com> <C58FFCAAA14F454A85AFB7C1C2F862C4019982FC@DEMUEXC013.nsn-intra.net> <009301cbdd31$b81fd120$285f7360$@com> <C58FFCAAA14F454A85AFB7C1C2F862C401998731@DEMUEXC013.nsn-intra.net>
Subject: [ppsp] 答复: Draft-ietf-ppsp-req-01
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 16 Mar 2011 00:48:01 -0000
Hi Christian Sorry for the late reply. I believe what you have described are good for PPSP QoS. We do have such description that PPSP protocol MAY support including requesting peer¡¯s preference for QoS purpose (see TP.REQ-3). But we don¡¯t make it as formal requirement since the application can handle this ¨C for example, application can try more peers once bad quality is detected. Anyway, we can put this QoS issue in our presentation slides and discuss on the Prague meeting. BR, Ning Zong ·¢¼þÈË: Schmidt, Christian 1. (NSN - DE/Munich) [mailto:christian.1.schmidt@nsn.com] ·¢ËÍʱ¼ä: 2011Äê3ÔÂ8ÈÕ 14:42 ÊÕ¼þÈË: ext Ning Zong; ext zhangyunfei; ppsp@ietf.org Ö÷Ìâ: RE: [ppsp] Draft-ietf-ppsp-req-01 Hi Ning Zong, yes, I can imagine influences to both. In case of bad quality at the receiving side, e.g. temporary low bandwidth ¨C due to mobility, or improved mobile condition the peer protocol could provide related information to the streaming source. In case of bad quality, resulting from an sub-optimal source peer selection (e.g. with insufficient uplink capacity or general too high end-to-end delay) the receiving peer can inform the tracker via the tracker protocol about this situation and request a new peer selection. The tracker can use this information for new source selection requests from other peers. What do you think about this? Best Regards Christian From: ext Ning Zong [mailto:zongning@huawei.com] Sent: Tuesday, March 08, 2011 2:40 AM To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext zhangyunfei'; ppsp@ietf.org Subject: ´ð¸´: [ppsp] Draft-ietf-ppsp-req-01 Hi, Schmidt, I agree that these requirements of QoS are important to P2P streaming system. However, I still don¡¯t see how these QoS requirements impact the design of Tracker & Peer Protocol, bearing in mind that our scope is not developing a P2P streaming system. Instead, IMO, these requirements could be addressed by some video transmission protocols such as those developed in AVT WG. Could you give some examples on how these QoS issue will apply to Tracker & Peer Protocol? Thanks. BR, Ning Zong ·¢¼þÈË: Schmidt, Christian 1. (NSN - DE/Munich) [mailto:christian.1.schmidt@nsn.com] ·¢ËÍʱ¼ä: 2011Äê3ÔÂ7ÈÕ 18:06 ÊÕ¼þÈË: ext Ning Zong; ext zhangyunfei; ppsp@ietf.org Ö÷Ìâ: RE: [ppsp] Draft-ietf-ppsp-req-01 Hi Ning Zong, I do not agree, that basic QoS issues should not be a normative requirement for PPSP system. I think they are essential to this services. what about the proposal to include a section Quality of Service Requirements? QoS.REQ-1: ¡°Setup time to receive a new streaming channel or to switch between channels should be reasonable small. This time mainly depends on the size of the receiving buffer.¡± QoS.REQ-2: ¡°End to end delay (time between content generation, e.g. camera and content consumption, e.g. user side monitor) will become critical in case of live streaming. Especially In provisioning of sports events, end to end delay of 1 minute and more seems to be not acceptable.¡± QoS.REQ-3: ¡°The user should receive an error free copy of the original streaming. This can be done with addition of redundancy and the usage of packet retransmission. But the additional delay has to be taken into account.¡± What do you think about? BR Christian From: ext Ning Zong [mailto:zongning@huawei.com] Sent: Friday, February 25, 2011 1:28 AM To: Schmidt, Christian 1. (NSN - DE/Munich); 'ext zhangyunfei'; ppsp@ietf.org Subject: ´ð¸´: [ppsp] Draft-ietf-ppsp-req-01 Hi, Schmidt, Your suggestion is good, although I think this new text could be in explanatory text rather than in the formal requirement body. BTW, I have post a new revision -02 and forward the message to the list, but it seems that it doesn¡¯t come out. So I attached the link to the new version as below http://tools.ietf.org/html/draft-ietf-ppsp-reqs-02 The main differences between -02 and -01 can be found in: http://tools.ietf.org/rfcdiff?url2=draft-ietf-ppsp-reqs-02.txt BR, Ning Zong ·¢¼þÈË: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] ´ú±í Schmidt, Christian 1. (NSN - DE/Munich) ·¢ËÍʱ¼ä: 2011Äê2ÔÂ24ÈÕ 20:56 ÊÕ¼þÈË: ext zhangyunfei; ppsp@ietf.org Ö÷Ìâ: [ppsp] Draft-ietf-ppsp-req-01 Hi Yunfei, a proposal related to PPSP.REQ-7: ¡°PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable peers to receive streaming data within the time constraints required by specific content items.¡± CS: We should be a little bit more specific here. I think, that delay will be the most critical QoS issues, especially for p2p live streaming. We should add: Proposal: ¡°PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable peers to receive streaming data within the time constraints required by specific content items. End to end delay will become critical in case of live streaming. Especially In provisioning of sports events, end to end delay of 1 minute and more seems to be not acceptable.¡± What do you think about? Best Regards Christian
- [ppsp] Review: draft-ietf-pp2p-problem-statement-… Schmidt, Christian 1. (NSN - DE/Munich)
- Re: [ppsp] Review: draft-ietf-pp2p-problem-statem… zhangyunfei
- Re: [ppsp] Review: draft-ietf-pp2p-problem-statem… Schmidt, Christian 1. (NSN - DE/Munich)
- Re: [ppsp] Review: draft-ietf-pp2p-problem-statem… zhangyunfei
- [ppsp] Review: draft-ietf-pp2p-problem-statement-… Schmidt, Christian 1. (NSN - DE/Munich)
- [ppsp] Draft-ietf-ppsp-req-01 Schmidt, Christian 1. (NSN - DE/Munich)
- [ppsp] 答复: Draft-ietf-ppsp-req-01 Ning Zong
- Re: [ppsp] Review: draft-ietf-pp2p-problem-statem… zhangyunfei
- Re: [ppsp] Review: draft-ietf-pp2p-problem-statem… Schmidt, Christian 1. (NSN - DE/Munich)
- [ppsp] (no subject) zhangyunfei
- [ppsp] (no subject) zhangyunfei
- Re: [ppsp] Draft-ietf-ppsp-req-01 Schmidt, Christian 1. (NSN - DE/Munich)
- [ppsp] Review: draft-ietf-pp2p-problem-statement-… Schmidt, Christian 1. (NSN - DE/Munich)
- [ppsp] (no subject) zhangyunfei
- [ppsp] 答复: Draft-ietf-ppsp-req-01 Ning Zong
- Re: [ppsp] Draft-ietf-ppsp-req-01 Schmidt, Christian 1. (NSN - DE/Munich)
- [ppsp] 答复: Draft-ietf-ppsp-req-01 Ning Zong