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

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 28 Jan 2011 11:34:29 +0100

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?

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

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

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. 

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.

3.4 Terminal physical resource starvation

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

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."

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."

Best Regards

Christian Schmidt

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 31 Jan 2011 16:44:38 +0800

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

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