Subject: [ppsp] Notes from PPSP meeting at IETF 79

From: Cullen Jennings <[email-masked]>
Date: Thu, 11 Nov 2010 20:29:17 -0700

Chair introduction and agenda bashing  

Thank you to Roni Even for co-chairing the meeting with Yunfei Zhang as Cullen Jennings could not make this meeting. 

About 30 People in Room.

---------------------------------------------

Protocol requirements

Problem Statement and general questions on PPSP   

Open Issue #1

Suggestion we look (on the mailing list) of what would change in the peer protocol to support push

Point made this changes the amount of signaling

Summary from Roni: This will need to go to the regiments of what we need. 

Open Issue #2 - No discussion

Open Issue #3 - No answer yet but possible to do both

Open Issue #4 -
- point raised that 40% behind a full code still need NAT traversal
- point raised that RELOAD is awfully big just to get NAT traversal 

Open Issue #5

Point main that a peer-id could be a hash of public key which could make the data self certifying 

Point made if you route with a DHT you don’t need an IP but if you don’t, then need the IP address

Question of what happens when they don’t match and what to do 

---------------------------------------------

Second part of requirements   (start at 9:25 ) 

PPSP.PP.REQ-5 

What if a peer wants to choke another peer? So a MUST is not quite right. Should change to say there MUST be a method to do this but not that a give peer MUST provide the information. 

PPSP.TP.REQ-4 

Point made to if we find other properties are needed or can be provided, do we need to add more requirements? 

-------------- 
Additional requirements      Start 9:35 

PPSP.REQ-1 
Why does this need to happen “immediately” and MUST - we have redundancy. Immediate may be too strong. Even for live streaming there could be 100 peer. Might not need ti immediately. 

This could also apply to peer that is acting as a relay.

PPSP.REQ-2: 

This can change 5 seconds later so might now be useful for algorithm. Comment made we needed to report on congestion. There are also privacy issues such as determining the wealth of a person based on the bandwidth provisioned. 

PPSP.REQ-3 

PPSP.REQ-4 

Controversial topic. Question asked why this is? Answer was sometimes the content distribution wants to control which countries this gets distributed to. Another example is how a sports game might be blocked out in the city where the game takes place. 

Some question if the slide meant to say, it SHOULD be possible to report location. Not that the location SHOULD be reported. 

Some proposal this could be learned from IP and not needed in protocol. 

Roni conclusion was to take it to the list 

Point raised there are no requirements on how to identify content. 

---------------------------------------------

Tracker Protocol  (started at 9:54 )

Discussion around how much data we can move out of the tracker to peer. 

David Harrington - provided some comparison of ASN.1 vs XML for a SNMP like task. Suggested we should consider what would make it easier for operator to use not what would compress it down the smallest. Strongly recommend we consider how that statistical information flowing across the wire might be used. READ RFC 1052 by Vint Cert. Also should read the RFC 3444 with difference between data model and information model. 

---------------------------------------------

Distributed Tracker Usage   

Skipped this preso 

---------------------------------------------

Peer Protocol   

David Harrington as an individual - don’t spend too much time designing stuff that works thought too many types of NATs. IESG is pushing back hard on things that keep v4 around longer because want to cause things to move to v6. He said more but go listen to the recording around 10:25

Harald - big fan of removable cruft but what part of we need to ship does the IESG not get.

---------------------------------------------

Peer protocol on NAT traversal    

Concern raised about robustness under churn. 

Very few people had read this. 

---------------------------------------------

Surveys    (start 10:44 )

Question asked on adopting the WG milestone. Will take the question to the list. 

---------------------------------------------

PPSP design considerations  (start at 10:53 ) 

Overview of Napa-Wine project. Cool stuff. 

You would not want to query the Alto server for every chunk - that is too fine grain but it is useful for peer selection. 

---------------------------------------------

Layered P2P streaming  ( start at 11:07 )

No discussion on this draft. 

---------------------------------------------

PPSP Secure naming  ( start at 11:19 )

David brought up the this type of naming made some problems much easier and we should look at this. 

Roni - reed this and see if this can help the architecture

---------------------------------------------

PPSP Incentive parameters  

Ran out of time and did not present. 

---------------------------------------------
P2P-vod system   

Ran out of time and did not present.

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 12 Nov 2010 14:28:18 +0800

Thanks Cullen for your quick notes although you are not present.I'll summarize the notes according to your and Roni's collection on other notes.Thanks again for Roni's co-chairing the session.

Yunfei

zhangyunfei
2010-11-12

发件人： Cullen Jennings
发送时间： 2010-11-12 11:29:08
收件人： [email-masked]
抄送： 
主题： [ppsp] Notes from PPSP meeting at IETF 79

About  30  People  in  Room.

Protocol  requirements

Open  Issue  #1

Open  Issue  #4  -

Open  Issue  #5

PPSP.PP.REQ-5  

PPSP.TP.REQ-4  

--------------  

PPSP.REQ-1  

PPSP.REQ-2:  

PPSP.REQ-3  

PPSP.REQ-4  

Skipped  this  preso  

Peer  Protocol      

Surveys        (start  10:44  )

Ran  out  of  time  and  did  not  present.
_______________________________________________
ppsp  mailing  list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp