Subject: Re: [ppsp] problem statement of ppsp(new version)

From: Jun Lei <[email-masked]>
Date: Mon, 10 Nov 2008 11:32:09 +0100

Yunfei, all:

please see comments inline.
> Jun,
>   Thanks so much for your comments.Please check the inline comments.
>
>           Yunfei   
>
>
>
> =======您在来信中写到：=======
> Hi,Yunfei,
>
> First of all, I think it is a quite interesting and right-timing to
> consider PPSP.
>
> Towards your problem statement, I have a couple of questions except for
> the ones that I already mentioned in the previous emails.
>
> 1. We really need to consider carefully whether we should concentrate on
> P2P real-time streaming or inclusive with VoD support. However, just to
> my opinion, in the future VoD services might be more promising if we
> imagine that IPTV can be really competitive to the current DTV system.
>
> Reply:I agreww with you about the VoD part.
>   
Great! For this part, our group would really like to give a hand on
exploring/investigating important issues.
> 2. You mentioned that "it is the time to draw up an open P2P streaming
> protocol". I suppose that you suggest to have a general P2P streaming
> protocol for supporting different services, right?
>
> As far as I know, there is some paper about an open P2P streaming
> protocol, such as "Substream Trading: Towards an
> Open P2P Live Streaming System". Therefore, I would suggest that we
> should rather be careful and more specific about the aim of the BOF.
>
> Reply:Thanks.I will read the paper carefully and make the aim more clear.
>
> 3. For "Problem Statement of PPSP app."
>
> a. startup delay and switching delay are usually long. I totally agree
> to get a further investigations on how to reduce the delay, especially
> in a P2P circumstance
>
> b. "it is still question if current P2P streaming mechanism work to
> support high quality streaming because of different wireless network
> environment". I am afraid that I have a different opinion here. Firstly,
> wireless network does not necessarily equal to "bad bandwidth support"
> but "instable environment". Therefore, instead of providing high quality
> streaming I would prefer looking into "stability" and "resiliency".
> Secondly, for some wireless users who can only have low bandwidth
> support, even we can provide high-quality video transmission it will not
> help the service but harm it. Because in that case, the network will be
> more congested.
>
> Reply:Thanks for your comments.Maybe "high quality video"is not accurate to describle the LTE+ envrinment.
> "High QoS video" maybe better to describe a requirement of "stable,resilient high quality Video"?
>   
If you consider high QoS (IMO, low latency/jitter, high bandwidth
support, etc) video, the definition of it could be extended to consider
how to smoothly support large-scale P2P video distribution to users in a
stable, resilient, efficient way.
> c. with the help of CDN for support VoD could be interesting. I would
> suggest to consider caching techniques in parallel. What about the
> others' opinions?
>  Reply:Great.In the first version of PPSP problem statement I listed some existing IETF drafts on cache.
> 1.D. Wessels and K. Claffy, Internet Cache Protocol (ICP), Version 2, Internet Engineering Task Force RFC 2186, September 1997. www.ietf.org/rfc/rfc2186.txt 
> 2.D. Wessels and K. Claffy, Application of Internet Cache Protocol (ICP), Version 2, Internet Engineering Task Force RFC 2187, September 1997. www.ietf.org/rfc/rfc2187.txt 
> 3.I. Cooper, I. Melve and G. Tomlinson, Internet Web Replication and Caching Taxonomy, January 2001. www.ietf.org/rfc/rfc3040.txt 
>
> We need to identify which part the previous protocols have discussed and which part not discussed yet.
>   
Agree. I will look into above specs and discuss with you further.
>
> 4. For "P2P Streaming Protocol Definition and Scope"
>
> a. "the key of PPSP is to find the concrete data (which are piece by
> piece) and reassemble them". I suddenly think of "layered video" coding
> techniques. It would be helpful in this scenario.
>
> Reply:It's related technique.In the inital phase we are suggested to shrink the scope.If PPSP basic infrastructure were built,such techniques are useful to make PPSP mature.
>   
However, it might be very relevant in the first place. Take an example
of using layered video coding techniques, the peer A requires first to
find the basic layer from other peers or CDN servers in assistance of
the tracker. If A has more capacity and the time is enough, it can get
enhanced layers from other peers. With such a mechanism, for some
low-capacity nodes it is easy to avoid overwhelming their capacities of
receiving unnecessary enhanced layers while getting acceptable quality.

The important thing here is how to design the architecture more
extensible. However, it is just my opinion.
> b. for the process of PPSP applications, I have more questions: 1)
> sending metrics to the tracker; => how?which kind of?where? 2) tracker
> answers with peer list; => if we consider above metrics, how to select
> peers? according to its QoS requirements or location-based distribution?
> Actually, timing condition is more important here!!!!
> Reply:There are really many problems to further discuss.
>
> .......c. 6) to reassemble chunks in cache for playback; => it is more
> complicated for just reassembiling. Besides, it is also relevant to the
> underlying transport protocol, whether it is TCP or UDP.
>  
> Reply:Right.Fluent playback depends on many factors besides PPSP scope.
>   
Maybe a high level summary of the scope can be very helpful!

Cheers

Jun
> So far, I would keep on tracking the other sections and let you know if
> there are any further interesting issues.
> Thanks so much for your comments.
>
>
> Best Regards from Goettingen
>
> Jun
>
>
>
>   
>> Dear all,
>>    Attached is the updated problem statement of ppsp.Comments and suggestions are highly welcome.
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> ppsp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ppsp
>>     
>
>
> --
>
> ===========================
> Dr. Jun Lei
> Research Associate
>
> Computer Networks Group
> University of Goettingen
> Goldschmidtstr. 7
> 37077, Goettingen
> Germany
>
>
>   

-- 

===========================
Dr. Jun Lei
Research Associate

Computer Networks Group
University of Goettingen
Goldschmidtstr. 7
37077, Goettingen
Germany

_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp