Hello, Ning Zong. Thank you for your comments.
In churn, a Viewer or a Relay would ask the Channel Manager to re-estabilish media path. But, because the Viewer (or relay) has already connected to the Channel Manager, the Viewer does not use RELOAD overlay. The Viewer ask the Channel Manager using "Media Delivery Network Control protocol". Once a Viewer or a Relay find a Channel Manager from RELOAD overlay, he does not access RELOAD overlay any more for this channel. Therefore, Asking the Channel Manager to reestablish media path does not load RELOAD overlay. The VoD case is also similar. In a centralized server, one VoD server gets stress from all viewer for all channel. However, in this distribution system, only one virtual server gets stress from viewers for one channel. According to "Media Delivery Network Control Protocol", a channel manager in this draft can works as a entry point to join a (non-RELOAD) overlay multicast tree for this channel. Therefore, The role of Channel manager depends on ""Media Delivery Network Control Protocol". In this draft, I focus on the scalability problem when there are too many channels. Now on in the future, there will be lots of IPTV channel (including UCC) in the world. RELOAD will contain them, find them, and connect them. I also know the scalability problem when there are too many viewers for one channel. I think that PPSP can be a good solution for it. Best Regards, Seokkap Ko. -----Original Message----- From: zongning 63316 [mailto:[email protected]] Sent: Monday, February 23, 2009 5:44 PM To: Ko, Seokkap Cc: [email protected] Subject: 回复:[P2PSIP] New IPTV Usage draft-softgear-p2psip-iptv-00 Hi, Ko, I believe that introduing distributed IPTV technique is a quite interesting and challenging work. But I would like to suggest that the use case and characteristic of each distributed service is the first thing to think about before adopting them to RELOAD overlay. IMO, unlike VoIP, distributed (or P2P?) IPTV is often called a "community" who involves many intermediate nodes (or relay in your draft) to share media. These nodes may be subject to highly dynamical behavior (e.g. churn). That means each receiver would contact with Channel Manager on the RELOAD overlay frequently to ask for media path adaptation, which in turn places unexpectable load on RELOAD overlay. Another case is VoD, where each receiver would ask for transmission of any piece of media on any time. So my suggestion is to consider how to use RELOAD overlay properly. Which parts of distributed service can be managed by RELOAD overlay? If scalability is not a critical issue, why not use centralized server? E.g. limited number of channels can be managed by some centralized servers - just like trackers in PPLive system. Would it be better to utilize peers themselves to exchange content information such as which IPTV media pieces is stored in which peers between each other? Just for your information, you can also refer to PPSP mailing list where a lot of P2P streaming use cases have been discussed and standardization requirements will be addressed. Further comments are welcome! Best Regards Ning Zong **************************************************************************** ************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or em ail immediately and delete it! **************************************************************************** ************* ----- 原邮件 ----- 发件人: "Ko, Seokkap" <[email protected]> 日期: 星期日, 二月 22日, 2009 上午9:34 主题: [P2PSIP] New IPTV Usage draft-softgear-p2psip-iptv-00 收件人: [email protected] > Hello folks, I have just submitted a draft which proposes a > distributed IPTV Usage for RELOAD. RELOAD does not only support > SIP based VoIP service but also other services. This IPTV Usage of > RELOAD allows RELOAD to store IPTV related information within the > overlay. A URL for this Internet-Draft > is:http://www.ietf.org/internet-drafts/draft-softgear-p2psip-iptv- > 00.txt any comment is appreciated. Best Regards,Seokkap Ko. > > -----Original Message----- > From: "IETF I-D Submission Tool" <[email protected]> > From Date: 2009-02-21 ?? 9:57:04 > To: "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Subject: New Version Notification for draft-softgear-p2psip-iptv- > 00 > > > > > A new version of I-D, draft-softgear-p2psip-iptv-00.txt has been > successfuly submitted by Seok-Kap Ko and posted to the IETF > repository. > > Filename: draft-softgear-p2psip-iptv > Revision: 00 > Title: An IPTV Usage for RELOAD > Creation_date: 2009-02-21 > WG ID: Independent Submission > Number_of_pages: 15 > > Abstract: > This document defines a distributed IPTV Usage for Resource > Location > And Discovery (RELOAD). The IPTV Usage provides lookup service for > IPTV channel information and IPTV metadata stored in the overlay. > The > Attach method is used to establish a direct connection between a > distributed channel manager and a viewer. IPTV control messages > are > exchanged through this connection. > > > > > The IETF Secretariat. > > > > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
