Subject: Re: [ppsp] Review: draft-ietf-pp2p-problem-statement-01 / Section 3

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 3 Feb 2011 10:26:13 +0100

Hi Yunfei,

it looks like that the interworking between different streaming providers will be an  important point in this section.

Lets assume the following possibilities.

Subscriber a of Service Provider A request access to a certain movie M.

In case, Service Provider A can deliver M 

>> no interworking is needed.

In case,  Service Provider A can not deliver M:

·         Service Provider A can refuse request and Subscriber a can contact other Service Providers himself; 
>>no interworking is needed.

·         Service Provider A contact other Service Providers

o    SP A provide Subscriber a the information, that he can get M from Service Provider C 
>>Only Interworking between Service Providers needed.

o    SP A fetch the related content himself and provide it to his subscriber a afterwards.
>>Only Interworking between Service Providers needed.

o    SP A forward the addresses of available peers to his subscriber a. 
>>Interworking between Service Providers and Peers are needed.

·         Service Provider A knows the content of other service providers, e.g. with direct information from Service Providers or related Super Peers.

o    SP A provide Subscriber a the information, that he can get M from Service Provider C 
>>Only Interworking between Service Providers needed.

o    SP A fetch the related content himself and provide it to his subscriber a afterwards.
>>Only Interworking between Service Providers needed.

o    SP A forward the addresses of available peers to his subscriber a. 
>>Interworking between Service Providers and Peers are needed.

What will be a realistic model, taken into account the different interests of the contributing service providers?

Best Regards

Christian Schmidt

 

From: ext zhangyunfei [mailto:[email-masked]] 
Sent: Monday, January 31, 2011 9:45 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); [email-masked]
Subject: Re: Review: draft-ietf-pp2p-problem-statement-01 / Section 3

Hi Christian,

    Thanks for your review.Please see inline for the reply.

BR

Yunfei

________________________________

zhangyunfei

2011-01-31

________________________________

发件人： Schmidt, Christian 1. (NSN - DE/Munich)

发送时间： 2011-01-28 18:34:55

收件人： ext zhangyunfei; [email-masked]

抄送： 

主题： Review: draft-ietf-pp2p-problem-statement-01 / Section 3

Comments on section 3 problem statement

3.1 ISP’s difficulties in deploying P2P caches

- Is it really possible, to decide remotely with deep packet inspection, which stream should be locally cached? And what should be done next to reduce traffic?

In many samll ISPs, P2P cache is widely deployed to reduce traffic. The deep packet inspection may not be executed remotely but locally (in the cache nodes). The next step is just caching the identified frequently visited content in the cache nodes.

- An application controlled caching system is much better for this purpose.

It depends. We see many ISP-unfriendly applications where the application is unaware of the ISP caching systems, let alone the cooperation.

- ISP workload can be reduced as well, using proprietary protocols for remote control.

The argument is not that ISP use proprietary or open protocols for remote control, but that if the applications use proprietary communication protocols, the ISP may add more workload for identifying these P2P streaming applications like many of today's practices.

3.2 Open streaming delivery infrastructure

- Interaction between different streaming providers is an interesting topic.  The level of cooperation will have influence to the importance for  standards in this area. 

I agree with you. 

3.3 Difficulties in mobile and wireless environment

- I do not see, how this is problems are related to proprietary vs. Standardized peer protocols. All this mobile specialities can be taken into account in proprietary protocols as well.

I may don't express my meaning exactly. What I mean is a two step logic. The first one is that since currently existing proprietary protocols don't consider the mobile and wireless issue well, we need to design one protocol suitable for both mobile and fixed environment. The second one is that consider the fact that proprietary protocols have lots of drawbacks as stated above, should we design another proprietary new protocol?Why not an open one?

3.4 Terminal physical resource starvation

- Limited CPU, storage and memory – Is this still a problem today? 

Good question. I can update the argument more clearly.One important thing in P2P applications is that the shared storage and memory size is very great. For example, in P2P live streaming systems, the shared memory is some minutes video length,e.g., !M bps*60*2/8=15M; and in P2P VoD streaming, the shared storage is about GB magnitude. This is even equivalent to many smart phones setting.

When several such daemons are envoked in the system, the resource starvation occurs.

In section 3, a lot of arguments are not fitting under the umbrella of

“ Let’s take a look what problems proprietary signalling brings out for P2P streaming applications.”

Okay.I'll update the expression.

Let’s focus here on the last sentence of this section and provide more input on this:

“Standard protocols reduce the complexity of coexisting multiple closed systems and create possibilities to use one client software accommodating different systems.”

Good suggestion.Thanks.

Best Regards

Christian Schmidt

---

From: "zhangyunfei" <[email-masked]>
Date: Tue, 15 Feb 2011 10:01:05 +0800

Thanks Christian for you to provide new hints in elaborating this chapter.Let me try to follow your thoughts(Please see in the inline). If I understand right, I will update this part.Thanks.

BR
Yunfei

zhangyunfei
2011-02-15

发件人： Schmidt, Christian 1. (NSN - DE/Munich)
发送时间： 2011-02-03 17:26:40
收件人： ext zhangyunfei; [email-masked]
抄送： 
主题： RE: Review: draft-ietf-pp2p-problem-statement-01 / Section 3

Hi Yunfei,

 
 
·         Service Provider A contact other Service Providers
        This is a confederacy model with loose coupling between SP A and SP C.
o    SP A provide Subscriber a the information, that he can get M from Service Provider C 
>>Only Interworking between Service Providers needed.
The tracker protocol (between SPA and subscriber a) may take effect in redirecting the service provider C for subscriber a.
o    SP A fetch the related content himself and provide it to his subscriber a afterwards.
>>Only Interworking between Service Providers needed.
We may need the SP A's super Peers to connect with SP C's tracker and super peers.Of course there are still some alternatives to connect with SP C directly without involving distribution.The former solution has advantages in slower latency.
o    SP A forward the addresses of available peers to his subscriber a. 
>>Interworking between Service Providers and Peers are needed.
In this case, tracker protocol needs to negothiate and synchronize peer list between SPA and SPC for requested video/streaming.
·         Service Provider A knows the content of other service providers, e.g. with direct information from Service Providers or related Super Peers.
I                    This is a union model with tight coupling between two providers. In this case, the tracker and super pees in SP A and SP B can totally exchange information.
o    SP A provide Subscriber a the information, that he can get M from Service Provider C 

Best Regards
Christian Schmidt

 
 
Hi Christian,
 
BR
Yunfei

zhangyunfei
2011-01-31

 

 

 
Best Regards
Christian Schmidt

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 24 Feb 2011 13:37:05 +0100

Hi Yunfei,

some more thoughts on the problem statement ID.

Security Considerations

(1)    "PPSP will not attempt to provide a solution on security and
copyright

   issues like malicious content distribution, content pollution and DRM

   for a general P2P streaming system. Instead PPSP security

   considerations involve the security problems related to PPSP

   protocols."

CS: This provides the wrong impression, that the draft do not care about
security issues, caused by the p2p technology, e.g. distributed and
untrusted peers.

Proposal:

   "PPSP will not attempt to provide a solution on security and
copyright

   issues like malicious content distribution, content pollution and DRM

   for a general P2P streaming system. Instead PPSP security

   considerations involve the security problems related to the
introduction 

   of p2p technology (e.g. usage of untrusted peers) and the used PPSP
protocols."

(2)   " Malicious peers may issue denial of service attack to the
trackers by

   sending large amount of requests with tracker protocol. Distributed

   trackers deployment may alleviate the problem."

CS: Can you please explain, why you are in the opinion, that distributed
trackers can alleviate the problem? It even could increase the problem,
because now you can attack the distributed parts of the tracker
simultaneously. Which makes thinks worse.

(3)  "On the other hand, malicious peers may report fake information
(e.g.,

   cheating trackers and other peers by claiming itself owning some

   unexisting data).

CS: Delete the first part of the sentence, it is without information:

Proposal:

   "Malicious peers may report fake information (e.g.,

   cheating trackers and other peers by claiming itself owning some

   unexisting data)."

(4)  "So it may be optional in some cases to realize authentication to
the

   peers before accepting the request for the tracker. But this may add

   up the tracker's workload on authentication."

CS: Proposal for rewording:

   "In some cases peer authentication for tracker contact may be needed.
But this may increase

   the tracker's workload."

(5)  "Similar to the behavior in the tracker-peer interaction, malicious

   peers may also create fake information on chunk availability and

   exchange it with other peers. Some techniques to check the data

   integrity (e.g., using checksum) may be useful for detecting the
data.

   But this part is out of scope of PPSP."

CS: I do not thing, that it is a good idea to declare this out of scope
here, because it is a fundamental question for p2p streaming. We should
provide more information here.

For example, how checksums could be used for this purpose. What level of
security can be achieved and what is the remaining risk.

Best Regards

Christian

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 24 Feb 2011 13:56:05 +0100

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

---

From: Ning Zong <[email-masked]>
Date: Fri, 25 Feb 2011 08:27:46 +0800

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

发件人: [email-masked] [mailto:[email-masked]] 代表 Schmidt,
Christian 1. (NSN - DE/Munich)
发送时间: 2011年2月24日 20:56
收件人: ext zhangyunfei; [email-masked]
主题: [ppsp] Draft-ietf-ppsp-req-01

Hi Yunfei,

   “PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable

   by specific content items.”

CS: We should be a little bit more specific here. I think, that delay will

We should add:

Proposal:

   “PPSP.REQ-7: The Tracker Protocol and Peer Protocol SHOULD enable

   by specific content items. End to end delay will become critical in case

  end to end delay of 1 minute and more seems to be not acceptable.”

What do you think about?

Best Regards

Christian

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 25 Feb 2011 17:37:54 +0800

Hi Chrisitian,
   Thanks for the review.Please see inline for the reply.

BR
Yunfei

zhangyunfei
2011-02-25

发件人： Schmidt, Christian 1. (NSN - DE/Munich)
发送时间： 2011-02-24 20:37:29
收件人： ext zhangyunfei; [email-masked]
抄送： 
主题： Review: draft-ietf-pp2p-problem-statement-01 / Section 5

Hi Yunfei,

Security Considerations
 
(1)    “PPSP will not attempt to provide a solution on security and copyright
   issues like malicious content distribution, content pollution and DRM
   for a general P2P streaming system. Instead PPSP security
   considerations involve the security problems related to PPSP
   protocols.”
 
CS: This provides the wrong impression, that the draft do not care about security issues, caused by the p2p technology, e.g. distributed and untrusted peers.

Proposal:
   “PPSP will not attempt to provide a solution on security and copyright
   issues like malicious content distribution, content pollution and DRM
   for a general P2P streaming system. Instead PPSP security
   considerations involve the security problems related to the introduction 
   of p2p technology (e.g. usage of untrusted peers) and the used PPSP protocols.”

Yunfei:I am fine with this revision.
 
(2)   “ Malicious peers may issue denial of service attack to the trackers by
   sending large amount of requests with tracker protocol. Distributed
   trackers deployment may alleviate the problem.”
 
CS: Can you please explain, why you are in the opinion, that distributed trackers can alleviate the problem? It even could increase the problem, because now you can attack the distributed parts of the tracker simultaneously. Which makes thinks worse.

Yunfei: The rational is that distributed trackers disperse the DoS attack to a specific tracker in centralized tracker senario. Therefore the attack to one certain tracker is alleviated.Does it make sense?
 
(3)  “On the other hand, malicious peers may report fake information (e.g.,
   cheating trackers and other peers by claiming itself owning some
   unexisting data).

Proposal:
   “Malicious peers may report fake information (e.g.,
   cheating trackers and other peers by claiming itself owning some
   unexisting data).”

Yunfei:I am fine with this revision.
 
(4)  “So it may be optional in some cases to realize authentication to the
   peers before accepting the request for the tracker. But this may add
   up the tracker's workload on authentication.”

   “In some cases peer authentication for tracker contact may be needed. But this may increase
   the tracker's workload.”
Yunfei:Good.

(5)  “Similar to the behavior in the tracker-peer interaction, malicious
   peers may also create fake information on chunk availability and
   exchange it with other peers. Some techniques to check the data
   integrity (e.g., using checksum) may be useful for detecting the data.
   But this part is out of scope of PPSP.”
 
CS: I do not thing, that it is a good idea to declare this out of scope here, because it is a fundamental question for p2p streaming. We should provide more information here.
For example, how checksums could be used for this purpose. What level of security can be achieved and what is the remaining risk.
Yunfei: I am okay if PPSP guys believe this is a fundamental task of PPSP. I would like to see more comments on this part. 

Best Regards
Christian

Thanks,
Yunfei

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 25 Feb 2011 13:18:58 +0100

Hi Yunfei

CS: I see, what about the following text proposal:

   sending large amount of requests with tracker protocol. In case of a distributed

   tracker the attack to some of these entities may not interrupt the service.”

Best Regards

Christian

From: ext zhangyunfei [mailto:[email-masked]] 
Sent: Friday, February 25, 2011 10:38 AM
To: Schmidt, Christian 1. (NSN - DE/Munich); [email-masked]
Subject: Re: Review: draft-ietf-pp2p-problem-statement-01 / Section 5

Hi Chrisitian,

BR

Yunfei

zhangyunfei

2011-02-25

抄送： 

Hi Yunfei,

Security Considerations

   protocols.”

 

Proposal:

   unexisting data).

Proposal:

   unexisting data).”

   the tracker's workload.”

Yunfei:Good.

Best Regards

Christian

Thanks,

Yunfei

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 28 Feb 2011 09:38:58 +0800

[email-masked]>
Subject: Re: RE: Review: draft-ietf-pp2p-problem-statement-01 / Section 5
Message-ID: <[email-masked]>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon628402863235_====="

This is a multi-part message in MIME format.

--=====003_Dragon628402863235_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon628402863235_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon628402863235_=====--

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 28 Feb 2011 13:59:44 +0800

[email-masked]>
Subject: Re: RE: Review: draft-ietf-pp2p-problem-statement-01 / Section 5
Message-ID: <[email-masked]>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====003_Dragon328500555346_====="

--=====003_Dragon328500555346_=====
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon328500555346_=====
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

--=====003_Dragon328500555346_=====--