[ppsp] 回复 :RE: PPPSP Bar BOF minutes

[zongning 63316 <[e-mail]>]

Hi, Michael,

The consensus from bar BoF was that the Problem Statement needs to be refined. And we are still far from discussing solutions.
Thank you.

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

----- 原邮件 -----
发件人: [e-mail]
日期: 星期二, 三月 31日, 2009 下午10:37
主题: RE: [ppsp] PPPSP Bar BOF minutes
收件人: [e-mail], [e-mail], [e-mail]
抄送: [e-mail]

> Hi Roni, Carl,
> 
> Sorry to miss this bar BoF. Was there consensus that the problem 
> statement for the transport needs to include mobility? Was there a 
> sense (hinted at by the notes below) that the solution must use 
> MIP, or are other options possible?
> 
> http://www.ietf.org/internet-drafts/draft-zong-ppsp-reqs-00.txt 
> doesn?t seem to discuss if mobility is needed.
> 
> Kind Regards,
> Michael
> 
> ________________________________
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of ext Roni Even
> Sent: 31 March, 2009 03:15
> To: [e-mail]; [e-mail]
> Subject: Re: [ppsp] PPPSP Bar BOF minutes
> 
> Hi,
> Small comment " Mic:  Someone from IAB"  the someone was Gonzalo 
> Camarillo.Roni Even
> 
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Carl Williams
> Sent: Tuesday, March 24, 2009 5:28 PM
> To: [e-mail]
> Subject: [ppsp] PPPSP Bar BOF minutes
> 
> 
> Yunfei asked me to take minutes of the PPSP bar bof last night.  
> Here are those minutes:
> 
> 
> 
> A 2nd PPSP bar bof was held on Monday March 23, 2009 at IETF 74 
> San Francisco meeting.  This is a follow-up to a meeting at IETF 
> 73 Minneapolis.  The primary PPSP (p2p streaming protocol) bar bof 
> agenda is as follows.  Any suggestions and contributions are 
> welcome.  I did an approx count of 110 attendees.
> 
> Notes by Carl Williams
> 
> PPSP Bar BoF-- IETF 74, San Francisco
> 2000-2200 Monday,March 23,Continental 3.
> Mailing list：[e-mail]<mailto:[e-mail]> 
> http://www.ietf.org/mailman/listinfo/ppsp
> Agenda
> - Introduction (Yunfei Zhang, 5 min)
> - Problem Statement  (Yunfei Zhang, 50 min) draft-zhang-ppsp-
> problem statement-01
> <http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-
> statement-01.txt>
> - Protocol Requirements(Ning Zong, 15 min) draft-zong-ppsp-reqs-00
> <http://www.ietf.org/internet-drafts/draft-zong-ppsp-reqs-00.txt>
> - Protocol Analysis of PPlive and PPStream by Interent Measurement 
> (Yunfei Zhang,15 min)
> draft-zhang-ppsp-protocol-comparison-measurement-
> 00<http://www.ietf.org/internet-drafts/draft-zhang-ppsp-protocol-
> comparison-measurement-00.txt>
> 
> - Introduction of Distributed Services Network, a vision of making 
> PPSP and P2PSIP into reality   (Ning Zong, 15')
> 
>  draft-zhang-ppsp-dsn-introduction-
> 00<http://www.ietf.org/internet-drafts/draft-zhang-ppsp-dsn-
> introduction-00.txt>
> 
> 
> 
> Problem Statement ? Yunfei Zhang
> 
> Yunfei presented slides on problem statement.  He noted that a 
> revised draft since Minneapolis IETF73 bar bof.   Some facts he 
> noted were that 10% of backbone traffic at major Chinese ISP is 
> PPLive.  PPLive has 110 million users, 2 million concurrent online 
> peers.20-30% is outside of china with 10-15% in us.  Yunfei noted 
> that other streaming services from PPStream had 70 million users 
> and UUSee had 1 million concurrent online peers during Olympic 
> games.  Finally Yunfei had listed many other P2P streaming vendors 
> each having a proprietary streaming protocol to support.
> 
> Yunfei stated that signal and transport is the focus of PPSP to 
> solve real operational problems.  He raised the question should 
> piracy or content protection be part of work.
> 
> There were many benefits of standardization that can be had by 
> IETF examining this area of work and standardize key pieces.  A 
> key benefit is that a single client can access multiple services.  
> Yunfei also stated that operators are interested in this as it is 
> easier to cache data to optimize traffic ? including mobile 
> Internet.  For Network provider the open standard allows interface 
> with CDN systems.  Content providers developers will be more 
> likely to implement an open standard, applications work and more 
> services.
> Mic:  Someone from IAB says that the Transport Ads weren’t able to 
> make the Monday evening meeting and that he would be covering the 
> meeting for IAB.
> 
> There were some comments made about who would implement PPSP if 
> IETF were to go ahead with standardization.
> 
> Christer Holmberg:  stated that standardize and then 
> interoperable.  In response to other comments if there is a 
> standard, others will switch.  It has happened with other 
> technologies.  He asked the question if Yunfei was in contact with 
> others.  Only PPLive and UUSee for now was the response.
> 
> James Seng:   Personal opinion is that technology is not a key 
> differentiator.promotion and marketing is a key differentiator.  
> It may have been somewhat important early but not so important now.
> 
> David Bryan:  Can say that about any working group.  Sometimes 
> things fail.  But if standardize, people may do it.
> 
> Roni Even: Not just PPlive issue.  Service providers can work in 
> integrated environment.  Will help people implement.
> 
> Comment was also made by someone that he had know of other 
> technologies that had their own proprietary solutions.  Then you 
> find much smaller carriers and enterprises ? can’t roll out their 
> own systems for legal reasons and other reasons.  So standard is 
> useful and eventually others implement it.
> 
> Yunfei continued with his presentation.  He presented the need to 
> cache P2P streaming content between domains.  This will lower the 
> cross-network traffic and provide better user performance.  Very 
> difficult with multiple, proprietary protocols which change quite 
> often.
> Yunfei went over the standardization interactions.
> 
> Question was asked if the talk was about live streaming or static 
> conetn.  What is the concept of a chunks.   The answer was that it 
> is live streaming.
> 
> James Seng:  rest of PPlive streaming is mesh architecture.  Not 
> able to support 1 live session; PPlive session requires multiple 
> chunks.  From 10-20 peers and it does it in form of chunks.
> 
> Simion:  if it takes 20 peers to support 1 peer, how will network 
> work?
> James Seng:  About 20% of peers will support rest of 80%
> 
> When using PPlive; 5-6 minutes no acadmic paper.  Max latency is 
> 90 seconds. Helsinki is big delay.  From injection to peers no 
> matter where in world is 90 seconds.
> 
> James Seng:   metadata; signaling should contain metadata.
> 
> Comment:   standardize transport.  Done in 2nd stage.  No strawman 
> proposal at this moment.
> 
> Response by chair is that this is TODO.  Evaluate existing 
> transport protocols; use UDP for transport.
> 
> Why use UDP and why not rtp?  What is relation to other working 
> groups.  P2PSIP, ALTO, and P2PRG is exploring research problems.  
> ALTO is about providing data to find optimal paths.  P2PSIP 
> specifies how to organize DHT.
> 
> PPSP is a narrow engineering task for an existing problem.  PP2P 
> is for standardizing the exchanging information in a streaming 
> scenario.  May resue work from other groups.  This work may be 
> useful to other groups.
> 
> 
> Question:  why is IETF right place?
> 
> Response by chair:   IETF is right place for standardizing 
> interoperable Internet-wide protocols.  We have a group of 
> interested people who have deployed this and with expertise in 
> P2P.   For example, streaming service operators (PPlive, etc).  
> Top P2P streaming researchers in IETF.  Existing P2P standards 
> contributors.  Operators with P2P streaming implementations and 
> developers of P2P streaming cache implementations.
> 
> Question:  try to transport media.  Audio/video transport working 
> group may come in handy here.   Comment was made that the co-chair 
> of AVT was in the audience ? namely Roni Even.
> 
> Chair:   early to discuss what will be done.  Standardization on 
> signaling and application then this would be the area.
> 
> Comment:  I like module design.  Here things are compacted into a 
> big module ball; things should be in sub-problems that you are 
> trying to solve; little confusing.
> 
> James Seng: Your question is good for open discussion section.
> 
> Yunfei concluded his presentation on problem statement by stating 
> that the goal was to eventually form a working group within IETF 
> to standardize an open P2P streaming protocol.  Need to solve 
> existing operational problem.  There is work already started on 
> PPSP signaling protocol and transport protocol is under 
> discussion.  Yunfei stated that high-level areas of deliverables 
> are: (1) PPSP architectural; (2) PPSP signal protocol; (3) PPSP 
> Transport Protocol.
> 
> Comment:  There is confusion to me on what problem to be solved 
> and what solutions may be.
> 
> Richard Bennett:  Break into component parts; Should deal with P2P 
> transport problem which is being dealt with in LEDBAT WG.)  
> Richard stated that another problem is to deal with bw constrained 
> devices. Separate problem.
> 
> 
> Henning Schulzrinne (Columbia University): It is obvious you have 
> a solution in mind; let's talk about problem rather than a solution.
> 
> James Seng (Chair):  we have no solution in mind.  There is an 
> understanding of streaming protocols in use today.  James asked if 
> we need to standardize P2P streaming at all?
> 
> Henning Schulzrinne (Columbia University):  It is not know yet and 
> we need to define who is taling to who and what info they are 
> exchanging.
> Comment:   should divide things into smaller solutions and then 
> compare with existing solutions (what we can reuse).
> 
> 
> Jame Seng:  Repeated that we are not pushing a solution from 
> PPLive.  PPlive has yet to decide to summit work to IETF on 
> solution.  PPSP may reuse some work like RTSP, some from AVT 
> working group, etc….   He mentioned that different streams are 
> assembled into single stream.
> 
> 
> Presentation was made on PPSP requirements by Ning Zong.
> 
> Ning Zong provided a diagram on the scope of PPSP and what it 
> does.  He stated that the basic role of PPSP is to define a 
> protocol of locating and transmitting real-time data efficiently 
> from multiple sources with different pieces in P2P environment.
> 
> Comment made by attendee that we should have started with this 
> slide in problem statement.  That this diagram is clear and can 
> see things much better on scope of PPSP.
> 
> Comment:  I still don’t see major difference between ppsp and file 
> sharing. There is no information exchanged for specific streams 
> regarding video signals. It looks to me  like a file sharing protocol.
> 
> Comment:  China Mobile wants to solve the problem of controlling 
> p2p traffic as it was stated early that 10% of traffic comes from 
> PPLive.  So, what's the motivation of having p2p here?
> 
> Chair:  China Mobile has launched mobile TV, which may have 
> scalability problems and we look to P2P to solve this.
> 
> Yunfei Zhang presented Protocol analysis of PPlive and PPStream by 
> Internet Measurement.  Yunfei stated there were questions (1) how 
> to evaluate system performance; (2) what the performance 
> limitations are under current systems models; (3) how to decrease 
> the pressure on the network.  Yunfei went over his methodology of 
> his measurements.  He used certain reverse-engineering methods to 
> analyze its working principle.  But they they focused mainly on 
> PPlive and PPStream.
> 
> Here they traced a standard client, captured interactive packets 
> between the local peer and others with packet filtering tools.   
> They traced data and fed it into the dumping tool.  Then they 
> analyzed the time sequences of the protocol messages.
> 
> Yunfei stated that the analysis items were:  (1) official client 
> trace; (2) system topology crawler; (3) long term multi-online 
> peers probe; (4) P2P streaming client measurement in mobile IP; 
> (5) special client accessing to official network in order to 
> evaluate the system robustness and optimize the protocol.
> 
> Messages were described for PPlive Live streaming as well as for 
> PPlive VOD.
> 
> Yunfei presented a summary of his analysis conclusion of what was 
> common ground and what were differences in key areas such as chunk 
> fetch policy as well as buffer aspect.  Such an analysis allows us 
> to have good understanding for moving forward on PPSP scoping work.
> 
> 
> Comments continued on Open discussion:
> 
> Comment:   We need to narrow down the scope and provide an 
> architectural framework and diagram to see the request (who is 
> making it and to whom).  What is the result of this request and 
> what are all the interactions coming forth.
> 
> Comment:  we need to have consensus on the architecture and it 
> must be clarified more.   It must be made into different 
> components.  Also what are the working groups working on the 
> various components today.
> 
> James Seng:  Asked question if we had consensus to create a formal 
> BOF at the next IETF meeting to present the problem statement and 
> a system architecture framework.
> 
> More than half of the room raised their hands.  No official count 
> was done but there was consensus that a formal IETF BOF should be 
> held.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>