[ppsp] Notes from PPSP meeting at IETF 79

Cullen Jennings <fluffy@cisco.com> Fri, 12 November 2010 03:28 UTC

Return-Path: <fluffy@cisco.com>
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 0F8EE3A698D for <ppsp@core3.amsl.com>; Thu, 11 Nov 2010 19:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.574
X-Spam-Level:
X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 sdTWzte658qj for <ppsp@core3.amsl.com>; Thu, 11 Nov 2010 19:28:24 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 10AB53A6927 for <ppsp@ietf.org>; Thu, 11 Nov 2010 19:28:24 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMJD3EyrR7H+/2dsb2JhbACiTHGkH5sfgnGCWQSEWoV+gws
X-IronPort-AV: E=Sophos;i="4.59,186,1288569600"; d="scan'208";a="618533101"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 12 Nov 2010 03:28:55 +0000
Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAC3SrS6001875 for <ppsp@ietf.org>; Fri, 12 Nov 2010 03:28:53 GMT
From: Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Nov 2010 20:29:17 -0700
Message-Id: <BF3E5099-58EF-4FDC-AAEA-800CBAA8FA0B@cisco.com>
To: ppsp@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [ppsp] Notes from PPSP meeting at IETF 79
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Fri, 12 Nov 2010 03:28:26 -0000

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.