Subject: [ppsp] PPPSP Bar BOF minutes

From: "Carl Williams" <[email-masked]>
Date: Tue, 24 Mar 2009 11:27:47 -0400

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：[email-masked] 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.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 31 Mar 2009 13:14:33 +0300

Hi,

Small comment " Mic:  Someone from IAB"  the someone was Gonzalo Camarillo.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl
Williams
Sent: Tuesday, March 24, 2009 5:28 PM
To: [email-masked]
Subject: [ppsp] PPPSP Bar BOF minutes

Notes by Carl Williams

Agenda

---

From: <[email-masked]>
Date: Tue, 31 Mar 2009 16:37:07 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Roni Even
Sent: 31 March, 2009 03:15
To: [email-masked]; [email-masked]
Subject: Re: [ppsp] PPPSP Bar BOF minutes

Hi,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Williams
Sent: Tuesday, March 24, 2009 5:28 PM
To: [email-masked]
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：[email-masked]<mailto:[email-masked]> 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.

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.

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.

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.

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.

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.

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.

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.

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.

---

From: zongning 63316 <[email-masked]>
Date: Wed, 01 Apr 2009 08:58:01 +0800

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

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

> 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
> 
> Small comment " Mic:  Someone from IAB"  the someone was Gonzalo 
> Camarillo.Roni Even
> 
> 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
> 
> Mailing list：[email-masked]<mailto:[email-masked]> 
> http://www.ietf.org/mailman/listinfo/ppsp
> Agenda
> 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 
> 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.
> 
> 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.
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
>