[ppsp] PPPSP Bar BOF minutes

"Carl Williams" <carlw@mcsr-labs.org> Tue, 24 March 2009 18:27 UTC

Return-Path: <carlw@mcsr-labs.org>
X-Original-To: ppsp@core3.amsl.com
Delivered-To: ppsp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6333A69A1 for <ppsp@core3.amsl.com>; Tue, 24 Mar 2009 11:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDFhdvmoLdMr for <ppsp@core3.amsl.com>; Tue, 24 Mar 2009 11:27:09 -0700 (PDT)
Received: from whasmtp-shoe.pas.sa.earthlink.net (whasmtp-shoe.pas.sa.earthlink.net [207.217.120.47]) by core3.amsl.com (Postfix) with ESMTP id 4DE5A28C339 for <ppsp@ietf.org>; Tue, 24 Mar 2009 11:27:09 -0700 (PDT)
Received: from [130.129.21.243] (helo=carlwPC) by whasmtp-shoe.pas.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <carlw@mcsr-labs.org>) id 1LmBLz-0000BL-LN for ppsp@ietf.org; Tue, 24 Mar 2009 11:28:00 -0700
From: Carl Williams <carlw@mcsr-labs.org>
To: ppsp@ietf.org
Date: Tue, 24 Mar 2009 11:27:47 -0400
Organization: MCSR Labs
Message-ID: <00b601c9ac95$168bb910$43a32b30$@org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01C9AC73.8F7A1910"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmslIooG4sgb2uiQp2xGjghBSmtowAAGUmA
Content-Language: en-us
X-ELNK-Trace: 43c6fb6bcad0e12d8fb8d53de325e2576ec97abdf3e40a0d241e6c3e5fc202c9189477d7828d6397350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.129.21.243
Subject: [ppsp] PPPSP Bar BOF minutes
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: carlw@mcsr-labs.org
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2009 18:27:23 -0000


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:ppsp@ietf.org http://www.ietf.org/mailman/listinfo/ppsp



Agenda
- Introduction (Yunfei Zhang, 5 min)
- Problem Statement  (Yunfei Zhang, 50 min) draft-zhang-ppsp-problem
<http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-01.t
xt>  statement-01

- 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-me
asurement-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.tx
t>







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.