Re: [ppsp] PPPSP Bar BOF minutes

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