Subject: [ppsp] Slides uploaded

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Nov 2009 08:46:11 +0900

Hi,

we have already uploaded all the slides we will be using in today's 
session at:

https://datatracker.ietf.org/meeting/76/materials.html

Search for 'PPSP'.

Cheers,

Gonzalo

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 13 Nov 2009 12:50:14 +0900

Spencer's minutes for PPSP.Thanks Spencer for the notes.

BR
Yunfei

1.1                PPSP
1.1.1            Introduction and agenda bash
Chairs
Have met informally at several previous IETFs.
1.1.2            Problem Statement
Richard Alimi
draft-zhang-ppsp-problem-statement-05
Planning for 50 percent of Internet traffic to be streaming.
P2P streaming used in many real-world systems with 100s of millions of users today (2M concurrent users for China’s Independence Day event).
Strong similarity among major systems, using tracker-based architectures. 
P2PP scope includes communication with trackers and “gossip” communication between peers.
Out of scope: interacting with the stream, defining a new data transport protocol (reuse existing protocols, although chunking is still in-scope).
UUSee says they will make an open p2p streaming platform. CoolRuc is aiming for standardized efficient streaming system. Goalbit has just published a protocol in the PPSP space. China Mobile is architecting DSN with PPSP in mind.
ITU-T and 3GPP are also working in this space.
Gonzalo – everything except the tracker protocol and peer-peer protocol is out of scope, reduced previous proposed scope significantly.
1.1.3            Survey of existing systems
Ning Zong
draft-gu-ppsp-survey-01
Ning walked through Joost, PeerCast, and PPLive/PPStream/Sopcast/TVants, GoalBit.
Lars – are any of the systems you presented here, input to the standardization? Are vendors interested in opening up and collaborating? Somebody sent an Internet-Draft in – is that a starting point? Will we get proposals if we charter the work?
Gonzalo – will cover that at the last part of the meeting.
1.1.4            Tracker vs. DHT comparison 
draft-hu-ppsp-tracker-dht-performance-comparison-01
Feng Cao
For DHTs – reuse P2PSIP RELOAD? Also an extension method is proposed. 
Performance analysis – there’s a registration delay using DHTs, and a large messaging load updating peer lists. 
draft-chen-ppsp-dht-chunk-discovery-evaluation-00
Jan Seedorf
Comparing DHT performance to tracker performance, for resource discovery and chunk discovery. 
For resource discovery - Tracker lookup is much faster than DHT (to the point of 4-6 seconds to change channels).
Network traffic is probably acceptable in both cases but tracker uses less.
For chunk discovery – advantage to tracker method, similar to resource discovery.
Recommendation is to consider a tracker-based system, which is what providers have deployed.
Lichun Li - Did DHT have supernodes? Not in this study – wasn’t considered. If you use supernodes, you will get better numbers.
Gonzalo – all the deployed systems are tracker-based, that says something.
Lichun  Li – one tracker isn’t big enough to support all the peers you want to support. 
Jorg Ott – decision basis? Probably make this make it more encompassing – the DHT really was penalized in this study, and it’s premature for the BOF unless you’re going to charter explicitly for a tracker-based system.
John Buford – comparison isn’t thorough, don’t agree with parameters. If you were engineering this, you’d use a better model. 
But we were asked to explicitly look at RELOAD, which uses CHORD.
1.1.5            Requirements
Ning Zong 
draft-zong-ppsp-reqs-02
Carry peer list information.
Carry swarm ID.
May carry content availability. May carry streaming status. May carry service status of the tracker.
Carry content availability of peers. May carry additional peer list between peers. May carry streaming status of the peers.
Overload protection – must be able to inform peers and reject messages.
Security considerations – authenticate/authorize users, limit damage by malfunctioning/badly behaving peers, minimize dependency on centralized servers, reuse security mechanisms as much as possible.
Dave Oran – why authenticate/authorize? Is that an agreed-to requirement? Not now.
Lars – “here’s a bunch of information we need to ship around” – timing constraints? Traditional transport considerations – last thing you want to do in an overload situation is send more messages! Does BitTorrent have “limit damage”? Need to discuss this.
Dave Oran – don’t get Security Considerations slide at all.
Spencer – we’re in the right place for transport people to ask questions like Lars asked…
1.1.6            Discussions
Sent charter proposal to the mailing list. Significantly reduced scope (dropped transport, media plane control, etc). Please comment on scope.
Spencer – reduced scope from early Bar BoFs is headed in the right direction.
Martin – is charter order task order? No, we haven’t talked about that. 
We did ask, and people are willing to move to a standardized protocol if we produce one.
Mat Ford – existing protocols list doesn’t include LEDBAT, please don’t forget it. 
Jorg Ott – confused by second paragraph (charter (1)) – just doesn’t parse. 
Two communication paths could be same protocol, haven’t designed that.
Lichun Li – peer protocol is defined as single protocol, but also refers to chunks – confusing. Use PPSP protocol to deliver streaming files? Possible but not in scope now.
Haibin – PPSP can depend on existing protocols for data transfer (RTP, etc). 
Magnus – requests in same path as media transport? Bigger architectural scope question. You may have more NAT traversal problems if you don’t use the same path for both.
Gonzalo – for the working group to discuss, really important question.
Lars – agree with Magnus, would want to say something about solutions being separated logically but combined later for NAT traversal performance. How you describe something isn’t how you build it. Scope is now much reduced, could reduce it a little more. “Optional” could be deferred until we know more. What support documents do we need to help us produce the milestone specifications? What documents can we take off the list? Survey is worth publishing, but could be Independent submission and not distract the working group. And that’s the easy document to write… 
Gonzalo – stressing that we haven’t settled on two separate protocols.
Martin – could we make bullet 4 on “Charter (2)” a little fuzzier?
Dave Oran – something is lost – what are real-time aspects of this? Need to describe dynamic behavior needed for the system. Have learned that RTP instrumentation is more important than actual RTP data transfer (8000 lines of RTCP code vs. 800 lines of RTP code in our implementation). There are real-time constraints in the system – can you buffer and tolerate higher jitter? If it doesn’t have to be streaming, we can all go home.
Spencer – agreeing with Dave, that’s the difference between DECADE and PPSP.
Jorg – need to be careful in asserting numbers. Think in terms of 3-4 years for PS, networks will be completely different then. Don’t look at the past, design for the future.
Jim McEachern – are we defining requirements for extensions, or defining extensions? Defining requirements for extensions.
John Buford – adding metric capability? 
Not in the charter but it’s a good point. 
Dave Oran - “Charter (3)” – objecting to design considering privacy issues – giant rat hole. People have tried to tackle this and run into rocks. Two kinds of privacy and don’t have a success model for addressing either one. Security is OK, privacy has me really worried.
Ning – just considering this.
Gonzalo – Dave’s point is that we should not consider it.
Dave – we disagree – that’s OK (for now).
Ning – we should consider this. Must protect privacy of which movie someone is watching.
Magnus – need an existence proof of privacy before we go there.
Dave – easy to write requirements. Privacy of both peers plus what they are doing is a research problem.
Gonzalo – that’s what we did with HIP (split between research and engineering), and that works fine.
1.1.7            Calling questions
This is the first official BOF, so need to start at the beginning.
Do we understand the proposed problem space? Almost unanimous “yes”.
Do we have the right pieces identified (and know what we have to invent and what we can reuse)? Again almost unanimous “yes”.
Looking at RFC 5434…
Is the charter completely bogus? Crickets.
Is the charter on the right path modulo comments received? Strong “yes” on hums.
Working group should be formed (with comments received)? Almost unanimous “yes”, but quieter than previous hums. Lars is wondering what we’re missing…
Dave – not completely comfortable that this isn’t a small club that will do work with no impact. P2PSIP became a club, not clear it will ever have an impact. Clubs are marginal but never goes anywhere, may not be connected with other things that are going on. Just have reservations.
Lars – scheduled against CODEC, lots of people should be here but they’re there. 
Jim – don’t have personal interest or cycles to do more than observe.
John Buford – have a clue about existing systems, but that’s a moving target – what future-proofing is in the plan?
Spencer – this is sociology – how do you encourage participants to keep bringing their best thoughts forward, instead of giving us a snapshot and working on their own proprietary extensions to what we standardize.
Lars – still haven’t seen the people running deployed systems who have said they’re going to use what we produce. We’ve made progress here, but we’re not there yet.
Gonzalo – did have quotes from large operators (PPLive, etc.).
Lars – it’s growing. Is it enough to charter now? Need to sleep on this. Very useful and successful. Now need to make the right decision.