Subject: [P2PSIP] New IPTV Usage draft-softgear-p2psip-iptv-00

From: "Ko, Seokkap" <[email-masked]>
Date: Sun, 22 Feb 2009 10:33:59 +0900

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-masked]> 
>From Date: 2009-02-21 오후 9:57:04 
To: "[email-masked]" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
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.

---

From: Song Haibin <[email-masked]>
Date: Mon, 23 Feb 2009 13:14:50 +0800

Dear Seokkap,

I have read the draft, and find the paragraph on metadata searching is
interesting. The key words based discovery is also described in some other
academic papers.

However, could you please describe the application scenarios for this kind
of p2psip IPTV?

And further consideration is also needed to given to the efficiency of both
signaling and data path, as well as other performance metrics.

Best Regards,
Haibin
Skype: alexsonghw

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ko,
>Seokkap
>Sent: Sunday, February 22, 2009 9:34 AM
>To: [email-masked]
>Subject: [P2PSIP] New IPTV Usage draft-softgear-p2psip-iptv-00
>
>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.
>
>From Date: 2009-02-21 ?? 9:57:04
>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.
>
>_______________________________________________
>P2PSIP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/p2psip

---

From: zongning 63316 <[email-masked]>
Date: Mon, 23 Feb 2009 16:44:24 +0800

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-masked]>
日期: 星期日, 二月 22日, 2009 上午9:34
主题: [P2PSIP] New IPTV Usage draft-softgear-p2psip-iptv-00
收件人: [email-masked]

> 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. 
> 
> Cc: "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]> 
> successfuly submitted by Seok-Kap Ko and posted to the IETF 
> repository. 
>

---

From: "Softgear Ko" <[email-masked]>
Date: Wed, 25 Feb 2009 17:10:59 +0900

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-masked]] 
Sent: Monday, February 23, 2009 5:44 PM
To: Ko, Seokkap
Cc: [email-masked]
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.

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!
 
****************************************************************************
*************

---

From: "Softgear Ko" <[email-masked]>
Date: Wed, 25 Feb 2009 20:18:21 +0900

Hello, Haibin.

One of application of this can be a world wide UCC channel service. There
are too many channels for several servers to handle them. CAPEX and OPEX is
expensive for a centralized server for too many channel. RELOAD overlay can
handle lots of channels with minimum cost.

Another application is a fault tolerant EPG server (Electronic Program Guide
server or tracker server). If a centralized server is down or network link
to the server is broken or under DDOS attack, it is impossible to perform
IPTV service even if contents providers and relay are alive. But, In P2PSIP
based distributed IPTV, it is possible to perform IPTV service whenever a
content provider is alive. I wonder how strong the existing commercial IPTV
service is for DDOS attack to a centralized server (eg. EPG server)

Current P2PSIP RELOAD uses a modified CHORD which is structured DHT.
Therefore, because RELOAD overlay cannot reflect physical topology, it is
hard to make a optimal data path or signal path. If we use another overlay
topology plugin, RELOAD can reflect physical topology and can help a optimal
data path. Another approach for this is to use other protocol (than RELOAD)
as media path control protocol to optimize signal path or data path. This is
my draft's approach.

- Seokkap Ko

-----Original Message-----
From: Song Haibin [mailto:[email-masked]] 
Sent: Monday, February 23, 2009 2:15 PM
To: 'Ko, Seokkap'; [email-masked]
Subject: RE: [P2PSIP] New IPTV Usage draft-softgear-p2psip-iptv-00

Dear Seokkap,

Best Regards,
Haibin
Skype: alexsonghw

Ko,
IPTV
also
related
successfuly