Subject: [ppsp] ietf ppsp bar bof agenda

From: "yunfei zhang" <[email-masked]>
Date: Thu, 20 Nov 2008 12:36:11 +0800

Dear all,
   The bar bof will be held at Duluth Room from 20:00 to 22:00 on
Thursday(Nov.20).The following is the agenda of this bof:
--------------------------------------------------------------------------------
Introduction of PPSP and its Status                     (5)

Problem statement                                            (30)
      draft-zhang-ppsp-problem-statement-01

Discussions on Problem statement                     (20)

Survey of P2P streaming                                    (20)

Wrap-up                                                            (5)
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: "yunfei zhang" <[email-masked]>
Date: Fri, 21 Nov 2008 04:33:30 +0800

Hi,Zongning,
   I talked with xingfeng about this and we share the same idea that one
problem statement is better. Just as I suggested in the mailing list, we'd
better merge the problem statement documents(I've merged your part into the
slides as well as your name in the athors list),or else it may cause great
confusion for the audience why we have two problem statements because we are
focusing on discussing a clearer problem statement tonight.
                               Yunfei

在08-11-20，zongning 63316 <[email-masked]> 写道：
>
> Hi, Yunfei,
> Presentation from Huawei will include both survey and problem statement.
> Could you please add an item "Problem Statement (from Huawei)" to the
> problem statement session such that we have two items in the problem
> statement session.
> Thank you.
>
> Best Regards
> 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!
>
> *****************************************************************************************
>
> ----- 原邮件 -----
> 发件人: yunfei zhang <[email-masked]>
> 日期: 星期四, 十一月 20日, 2008 下午12:36
> 主题: [ppsp] ietf ppsp bar bof agenda
> 收件人: [email-masked]
>
> > Dear all,

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 20 Nov 2008 21:23:25 -0600

1.1      PPSP Pre-BOF
About 35 attendees…

1.1.1            Problem Statement
Includes both live and video-on-demand streaming in the problem statement. These account for about 50 percent of P2P traffic in China – more than file sharing.

Suggesting two standardized protocols, PPSP signaling protocol and transmission protocol. 

Moving from streaming from one source to streaming from many sources.

Decided on aspects of architecture? Will look at tree-based and data-based approaches, but we haven’t seen commercial offerings using tree-based. 

Lots of problems – can they be separated into small parts? Including security? Security is included in long-term work. 

Need to look at components that might already be available, so you only specify the parts that are missing. 

Need to look at sizes of data being transferred – RTP may not be good for very large amounts of data.

Scheduling and caching strategy may be required as well? Caching is from CDN, not inside peers?

P2PSIP is entirely evaluated from SIP usage – would be great to see if there could be a PPSP usage as well (possibly for the tracker). 

Slides available? Not at this time.

Streaming? Video (live and on-demand). 

How to incorporate ALTO? 

Paper at last year’s SIGCOMM.

Lars – incredibly large and difficult system, need to know what the core pieces are, and what the optional pieces are – focus on the core pieces first. What are the components involved? Does everyone have to use the same codecs? What does everyone need to agree on?

Why P2PSIP tracker-based system with ALTO is not sufficient? This application cannot support streaming well. We want to reuse P2PSIP for the DHT.

1.1.2            Survey of Current P2P Streaming Technologies
Lars – what does survey of current techniques tell us about your proposal? That would be ongoing work. Are people with existing implementations willing to bring them to the IETF?

Focus is on application-level message-based P2P streaming.

Is buffer map service-specific, or chunk-based? Current systems are based on chunks, think we can develop a general mechanism for interoperability. 

Does signaling protocol need to define a chunk? Signaling shouldn’t be limited to chunks, format shouldn’t matter.

1.1.3            Wrap-up
Lars – key questions – what components need to be standardized? What are limits of current trackers? Lots of stake-holders, what’s the incentive for them to deploy this? What are benefits? What are risks? These are questions we need to ask in order to charter new standards-track work in the IETF. Not a research effort, not building an application – building parts that can be used to build a system. 

This is really big – one of largest proposals Lars has seen in recent years at the IETF, much larger than ALTO. 

China is most advanced country for P2P streaming – can characterize this traffic, but much of the information is in Chinese!

Germans are also using PPLive…

Magnus – who is interested in working in this space? About 14 hands, should see traffic on mailing list discussing these problems.

Lars – who has experience with deployment, building, specifying these systems? Does IETF have expertise here? We think so, but there are so many visa issues we can’t tell.

We want people to have one client instead of five…

Clear from technology is that this type of streaming is becoming more popular – are people looking for a single standard protocol here? Do people have architectures similar enough to agree?

Please make more information available between IETF 73 and IETF 74 about the problem statement – there will be a lot more people interested in coming at IETF 74. Create a PPSP.org website, like P2PSIP.org?

Problems – tried to deploy pure P2P but didn’t scale to large overlays, found some tricks but not sure they were good enough. Terminals have varied capabilities on power, etc. Think about security.

Don’t want more information, want different information – don’t worry about exciting people, worry about interesting them in working on this problem. What do you want to run better in the network? Not sure the IETF should spend effort in reducing the number of proprietary protocols… What’s wrong with having BitTorrent and eDonkey? 

Business models of companies deploying these products rely on smart algorithms, unlikely we can do better and not sure they would use our algorithms if we had better ones – they make money with P2P streaming, we don’t.

We build protocols, not applications – may still end up with multiple protocols. 

Problem statement isn’t clear – live streaming isn’t the same as video on demand, mobile has very different requirements. This will influence your design. You want to narrow things down. You have a strawman framework, what are the components? IETF has protocols for some of the components, identify what’s defined and what’s missing.

Need to look at what the value of PPSP protocol is. Not business model, what can we build in the IETF that people want to use?

Invited PPLive and university but they were not able to come – hope they will be able to come in San Francisco. 

Lars – we do have an interested community on this topic (late on a Thursday night). Keep mailing list active, do another informal session in San Francisco. 
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: "yunfei zhang" <[email-masked]>
Date: Fri, 21 Nov 2008 12:46:55 +0800

Thanks so much for Spencer's hardworking.

                                          Yunfei

2008/11/21, Spencer Dawkins <[email-masked]>:
>
>  *1.1*      *PPSP Pre-BOF*
>
> About 35 attendees…
> 1.1.1            Problem Statement
>
> Includes both live and video-on-demand streaming in the problem statement.
> These account for about 50 percent of P2P traffic in China – more than file
> sharing.
>
> Decided on aspects of architecture? Will look at tree-based and data-based
> approaches, but we haven't seen commercial offerings using tree-based.
>
> Lots of problems – can they be separated into small parts? Including
> security? Security is included in long-term work.
>
> P2PSIP is entirely evaluated from SIP usage – would be great to see if
> there could be a PPSP usage as well (possibly for the tracker).
>
> Paper at last year's SIGCOMM.
>
> Lars – incredibly large and difficult system, need to know what the core
> pieces are, and what the optional pieces are – focus on the core pieces
> first. What are the components involved? Does everyone have to use the same
> codecs? What does everyone need to agree on?
>
> Why P2PSIP tracker-based system with ALTO is not sufficient? This
> application cannot support streaming well. We want to reuse P2PSIP for the
> DHT.
> Lars – what does survey of current techniques tell us about your proposal?
> That would be ongoing work. Are people with existing implementations willing
> to bring them to the IETF?
>
> Is buffer map service-specific, or chunk-based? Current systems are based
> on chunks, think we can develop a general mechanism for interoperability.
>
> Does signaling protocol need to define a chunk? Signaling shouldn't be
> limited to chunks, format shouldn't matter.
> 1.1.3            Wrap-up
>
> Lars – key questions – what components need to be standardized? What are
> limits of current trackers? Lots of stake-holders, what's the incentive for
> them to deploy this? What are benefits? What are risks? These are questions
> we need to ask in order to charter new standards-track work in the IETF. Not
> a research effort, not building an application – building parts that can be
> used to build a system.
>
> China is most advanced country for P2P streaming – can characterize this
> traffic, but much of the information is in Chinese!
>
> Magnus – who is interested in working in this space? About 14 hands, should
> see traffic on mailing list discussing these problems.
>
> Lars – who has experience with deployment, building, specifying these
> systems? Does IETF have expertise here? We think so, but there are so many
> visa issues we can't tell.
>
> Clear from technology is that this type of streaming is becoming more
> popular – are people looking for a single standard protocol here? Do people
> have architectures similar enough to agree?
>
> Please make more information available between IETF 73 and IETF 74 about
> the problem statement – there will be a lot more people interested in coming
> at IETF 74. Create a PPSP.org website, like P2PSIP.org?
>
> Problems – tried to deploy pure P2P but didn't scale to large overlays,
> found some tricks but not sure they were good enough. Terminals have varied
> capabilities on power, etc. Think about security.
>
> Don't want more information, want different information – don't worry about
> exciting people, worry about interesting them in working on this problem.
> What do you want to run better in the network? Not sure the IETF should
> spend effort in reducing the number of proprietary protocols… What's wrong
> with having BitTorrent and eDonkey?
>
> Business models of companies deploying these products rely on smart
> algorithms, unlikely we can do better and not sure they would use our
> algorithms if we had better ones – they make money with P2P streaming, we
> don't.
>
> Problem statement isn't clear – live streaming isn't the same as video on
> demand, mobile has very different requirements. This will influence your
> design. You want to narrow things down. You have a strawman framework, what
> are the components? IETF has protocols for some of the components, identify
> what's defined and what's missing.
>
> Need to look at what the value of PPSP protocol is. Not business model,
> what can we build in the IETF that people want to use?
>
> Lars – we do have an interested community on this topic (late on a Thursday
> night). Keep mailing list active, do another informal session in San
> Francisco.
>

---

From: "James Seng" <[email-masked]>
Date: Fri, 21 Nov 2008 12:54:05 +0800

Spencer,

Thanks for the update.

Looks like it went well. Sorry I was not able to attend this IETF meeting.

-James Seng

On 11/21/08, Spencer Dawkins <[email-masked]> wrote:
> Decided  on aspects of architecture? Will look at tree-based and data-based approaches,  but we haven't seen commercial offerings using tree-based.
>
> Does  signaling protocol need to define a chunk? Signaling shouldn't be limited to  chunks, format shouldn't matter.
> 1.1.3             Wrap-up
>
> Lars –  key questions – what components need to be standardized? What are limits of  current trackers? Lots of stake-holders, what's the incentive for them to deploy  this? What are benefits? What are risks? These are questions we need to ask in  order to charter new standards-track work in the IETF. Not a research effort,  not building an application – building parts that can be used to build a system.
>
> Lars –  who has experience with deployment, building, specifying these systems? Does  IETF have expertise here? We think so, but there are so many visa issues we  can't tell.
>
> Problems  – tried to deploy pure P2P but didn't scale to large overlays, found some tricks  but not sure they were good enough. Terminals have varied capabilities on power,  etc. Think about security.
>
> Don't  want more information, want different information – don't worry about exciting  people, worry about interesting them in working on this problem. What do you  want to run better in the network? Not sure the IETF should spend effort in  reducing the number of proprietary protocols… What's wrong with having  BitTorrent and eDonkey?
>
> Business  models of companies deploying these products rely on smart algorithms, unlikely  we can do better and not sure they would use our algorithms if we had better  ones – they make money with P2P streaming, we don't.
>
> Problem  statement isn't clear – live streaming isn't the same as video on demand, mobile  has very different requirements. This will influence your design. You want to  narrow things down. You have a strawman framework, what are the components? IETF  has protocols for some of the components, identify what's defined and what's  missing.
>

---

From: "Hui Zhang" <[email-masked]>
Date: Fri, 21 Nov 2008 00:22:07 -0500

Thank you, Spencer!

Clearly people have interests in PPSP, and materializing the protocol
design is the next work item.

Regards,

Hui

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Spencer Dawkins
Sent: Thursday, November 20, 2008 10:23 PM
To: [email-masked]
Subject: [ppsp] My notes from ietf ppsp bar bof

1.1      PPSP Pre-BOF

About 35 attendees...

1.1.1            Problem Statement

Includes both live and video-on-demand streaming in the problem
statement. These account for about 50 percent of P2P traffic in China -
more than file sharing.

Suggesting two standardized protocols, PPSP signaling protocol and
transmission protocol. 

Decided on aspects of architecture? Will look at tree-based and
data-based approaches, but we haven't seen commercial offerings using
tree-based. 

Lots of problems - can they be separated into small parts? Including
security? Security is included in long-term work. 

Need to look at components that might already be available, so you only
specify the parts that are missing. 

Need to look at sizes of data being transferred - RTP may not be good
for very large amounts of data.

Scheduling and caching strategy may be required as well? Caching is from
CDN, not inside peers?

P2PSIP is entirely evaluated from SIP usage - would be great to see if
there could be a PPSP usage as well (possibly for the tracker). 

How to incorporate ALTO? 

Lars - incredibly large and difficult system, need to know what the core
pieces are, and what the optional pieces are - focus on the core pieces
first. What are the components involved? Does everyone have to use the
same codecs? What does everyone need to agree on?

Why P2PSIP tracker-based system with ALTO is not sufficient? This
application cannot support streaming well. We want to reuse P2PSIP for
the DHT.

Lars - what does survey of current techniques tell us about your
proposal? That would be ongoing work. Are people with existing
implementations willing to bring them to the IETF?

Is buffer map service-specific, or chunk-based? Current systems are
based on chunks, think we can develop a general mechanism for
interoperability. 

1.1.3            Wrap-up

Lars - key questions - what components need to be standardized? What are
limits of current trackers? Lots of stake-holders, what's the incentive
for them to deploy this? What are benefits? What are risks? These are
questions we need to ask in order to charter new standards-track work in
the IETF. Not a research effort, not building an application - building
parts that can be used to build a system. 

This is really big - one of largest proposals Lars has seen in recent
years at the IETF, much larger than ALTO. 

China is most advanced country for P2P streaming - can characterize this
traffic, but much of the information is in Chinese!

Germans are also using PPLive...

Magnus - who is interested in working in this space? About 14 hands,
should see traffic on mailing list discussing these problems.

Lars - who has experience with deployment, building, specifying these
systems? Does IETF have expertise here? We think so, but there are so
many visa issues we can't tell.

We want people to have one client instead of five...

Clear from technology is that this type of streaming is becoming more
popular - are people looking for a single standard protocol here? Do
people have architectures similar enough to agree?

Please make more information available between IETF 73 and IETF 74 about
the problem statement - there will be a lot more people interested in
coming at IETF 74. Create a PPSP.org website, like P2PSIP.org?

Problems - tried to deploy pure P2P but didn't scale to large overlays,
found some tricks but not sure they were good enough. Terminals have
varied capabilities on power, etc. Think about security.

Don't want more information, want different information - don't worry
about exciting people, worry about interesting them in working on this
problem. What do you want to run better in the network? Not sure the
IETF should spend effort in reducing the number of proprietary
protocols... What's wrong with having BitTorrent and eDonkey? 

Business models of companies deploying these products rely on smart
algorithms, unlikely we can do better and not sure they would use our
algorithms if we had better ones - they make money with P2P streaming,
we don't.

We build protocols, not applications - may still end up with multiple
protocols. 

Problem statement isn't clear - live streaming isn't the same as video
on demand, mobile has very different requirements. This will influence
your design. You want to narrow things down. You have a strawman
framework, what are the components? IETF has protocols for some of the
components, identify what's defined and what's missing.

Invited PPLive and university but they were not able to come - hope they
will be able to come in San Francisco. 

Lars - we do have an interested community on this topic (late on a
Thursday night). Keep mailing list active, do another informal session
in San Francisco.

---

From: "yunfei zhang" <[email-masked]>
Date: Fri, 21 Nov 2008 14:04:34 +0800

Dear all,
     Thanks so much for all of your efforts in the mailing list and
preparation for the bar bof.I agree with Hui that it's clearly shown that
people in IETF are interested in ppsp.And we'd better collect all the
comments,identify the problems and launch some discussions in our mailing
list to push it forward before next IETF meeting.Let's go~!

                               Yunfei

2008/11/21, Hui Zhang <[email-masked]>:
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Spencer Dawkins
> *Sent:* Thursday, November 20, 2008 10:23 PM
> *To:* [email-masked]
> *Subject:* [ppsp] My notes from ietf ppsp bar bof
>
>
>  *1.1*      *PPSP Pre-BOF*
>
> About 35 attendees…
> *1.1.1*            Problem Statement
>
> These account for about 50 percent of P2P traffic in China – more than
> file sharing.
>
> *1.1.2*            Survey of Current P2P Streaming Technologies
>
> *1.1.3*            Wrap-up
> questions we need to ask in order to charter new standards-track work in the
> IETF. Not a research effort, not building an application – building parts
> that can be used to build a system.
>
> This is really big – one of largest proposals Lars has seen in recent
> Magnus – who is interested in working in this space? About 14 hands,
> popular – are people looking for a single standard protocol here? Do
> the problem statement – there will be a lot more people interested in
> Don't want more information, want different information – don't worry
> problem. What do you want to run better in the network? Not sure the IETF
> should spend effort in reducing the number of proprietary protocols… What's
> wrong with having BitTorrent and eDonkey?
>
> Lars – we do have an interested community on this topic (late on a
> Thursday night). Keep mailing list active, do another informal session in
> San Francisco.
>