IETF79 Beijing November 2010 PPSP WG session Friday, November 12th, 9:00-11:30 Notes: Christian Schmidt, Cullen Jennings and Roni Even Editor:Yunfei Zhang Thank you to Roni Even for co-chairing the meeting with Yunfei as Cullen Jennings could not make this meeting. About 80 People in Room. ---------------------------------------------------------------------------------------------------------- Yunfei Zhang presented the Problem Statement Draft Open Item 1: Pull / Push ? David Bryan: Agree having Pull mandatory and push as optional. Need to explain how it affects the peer protocol.What is the protocol difference to support push? ? Jan Seedorf: It is good to have pull as mandatory and push as optimal. And this makes changes in the amount of the signalling. How much signaling is needed depends if using push or pull? ? David Bryan: That I want to hear here. I do not want to disallow to go to push later. ? Roni ¨C need to update the requirements for the peer protocol accordingly. Open Issue #2 - No discussion Open Issue #3 - No answer yet but possible to do both Open Item 4: NAT Traversal ? David Bryan: David- will talk about NAT in the presentation about the protocol itself. ? Li Chun: NAT Traversal is required. Figures show 40% behind Full cone still need NAT traversal. ? Point raised that RELOAD is awfully big just to get NAT traversal. Open Item 5: Peer ID or IP for the identifier in the peer list. ? Jan Seedorf: In case of using Peer ID, You can use hash for generation of a self-certifying key. ? David Bryan: Advantage in peer-id for using Reload for routing as well. ? Spencer Dawkins: When you have 2 identifiers for this, you have to clarify what happens, when they do not match. ? Ron Even: That could happen. ? David Bryan: You can use Peer ID to assert identity and IP for location information. ? Richard Yang: Support the idea to support both peer ID and IP. ---------------------------------------------------------------------------------------------------- Ning Zong presented PPSP Requirements: (start at 9:25 ) Req-4: Tracker request message MAY include parameter of requested number of downloading peers or preferred downloading bandwidth. ? Yingjie: In case of overload, the responsible peer should have the possibility to reject. ? Ron Even: You mean there should be a method to use this, but is should not be mandatory to use. ? Ning Zong: Peer itself can decide, if he wants to accept. I can add some text. ? Yingjie: Another issue, a peer should be able to request the select peers with specific properties. ? Ning Zong: We have another requirement covering this. This Requirement is about the request message only. ? Yingjie: I want to allow a peer to add parameter with some preferences towards the tracker. 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? --------------------------------------------------------------------------------------------------- Akbar Rahman presented P2P Streaming Requirements for mobile nodes: (Start 9:35) Req-1: Change in IP address of a Peer device MUST immediately be reported via the Tracker Protocol and Peer Protocol ? Zing: Why must the change of the IP address be reported to the tracker immediately? we have redundancy. Immediate may be too strong. Even for live streaming there could be 100 peer. Might not need it immediately. ? Akbar Rahman: Main point is the MUST. You want to inform the tracker for subsequent request. ? Xia Lin: If you lost a few peers, this does not matter. Some packet loss is acceptable. I do not think, this is a must request. ? Akbar Rahman: I think it should be a MUST. ? Xiao Lin: You have hundreds of peers out. The failure of a few peers does not matter. ? Akbar Rahman: We can drop immediate, but we should keep MUST: ? David Bryan: think about that there is also a relay address and not only the peer. ? Spencer Dawkins: Coming from DHT background. DHT automatically heal, when IP address changes. but this is not just DHT. ? Akbar Rahman: You have to communicate on both tracker and peers in this case. ? Yunfei Zhang: It does not really matter for the peer protocol. Change of IP address reporting in tracker protocol is a necessary requirement. Req-2: Available uplink and downlink bandwidth of a Peer device MAY be reported via the Tracker Protocol and Peer Protocol ? Nelson: Requirement 2 may not apply to fast changing situations in wireless networks. This could lead to congestions. ? Jan Sedorf: Long discussion in Alto about Privacy. Could infer about the provisioned bandwidth. ? YingJie ¨C can help with peer selection. From peer to tracker should be static information. Between peers need current status. Req4: Location of a Peer device SHOULD be reported via the Tracker Protocol and Peer Protocol ? Akbar Rahman: This is important for content provider: ? Ning Zong: Why this should be supported? ? Akbar Rahman: Content distribution is sometime restricted to a certain country. For example North America and certain hockej games. ? Roni Even: Clarification: Should be possible to report. ? Ning Zong: Should not be part of the mandatory requirements. ? Akbar Rahman: It has to be part of the protocol. ? Xiao Lin: This is a deployment problem, not a protocol problem. I do not think, this is has to be included in the ppsp protocol. It could be reflected via peer ID. ? Ning Zong: Can use other means, not ppsp responsibility. ? Arbar Rahman:Can reword. ? Ove: Point raised there are no requirements on how to identify content. ? Roni conclusion was to take it to the list ---------------------------------------------------------------------------------------------------------- David Bryan: Tracker Protocol issues. (started at 9:54 ) Metafiles: Different slightly for streaming / VoD ? Jan Seedorf: This is still the tracker issue. Is it really necessary to exchange all these metafiles? ? David Bryan: not sure some can be from external application or from the peers. ? Jan Seedorf: E.g. for upload capacity. ? David Bryan: In certain cases, it is not easy to decide, e.g. what upload bandwidth should be reported. ? Jan Seedorf: We have to be sure, that the tracker has not to be contacted every 5 seconds. This could overload the system a lot. ? There is NAT problem in pull case. ? Xxx ¨C pulling the peers from tracker may not be optimal maybe pushed by peer ? David Bryan: We assume the tracker has a permanent connection to the peer. Open Issue: Binary vs. Text encoding: ? We have to make some decision for implementation. ? AD David Harrington as technical provider: 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. ? David Bryan: In a lot of case this is used as companion, we have done in ALTO. It is used more as network management model. But you are right; we will use existing protocols as far as possible. ? AD David Harrington as technical provider: You also should read Yang RFC 3444 for this purpose as well. ---------------------------------------------------------------------------------------------------------------- Distributed Tracker Usage Skipped this presentation --------------------------------------------------------------------------------------------------------------- David: Peer Protocol issues: (Start 10:15) Not only RELOAD for establishing connection since need faster system to connect between peers. Also want to support distributed trackers. Will specified gossip protocol but not how to establish the connection. Will look at how to have a peer to peer connection where both are behind NATs yet simpler than REALOAD. The proposed Architecture is very new. ? Jan Seedorf: Clarify the issue: Are both peers behind NATs? ? David Bryan: Yes, behind certain NATs. ? Jan Seedorf: Is it a fully distributed system? ? David Bryan: Yes, at the cost of additional messages. ? Jan Seedorf: This adds a lot of complexity. I would not like to make reload mandatory. ? David Bryan: Reload is only mandatory to implement, not to deploy. The Tracker located in the public network. ? Jan Seedorf: STUN mandatory? ? David Bryan: NAT problem is not avoidable. Tracker could have STUN service included. ? 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. ? David Bryan: Does this mean, if we make such proposals, it will be refused? ? AD David Harrington as technical provider: No. David Bryan: Early stage of protocol design. Want to see more discussion about this on the list. --------------------------------------------------------------------- Lichun Li presented PPSP NAT traversal (Start 10:35) ? David Bryan: I am Interested in this idea. ? Ron Even: Not too much people have read the document. Please read the ID and comment. ----------------------------------------------------------------------------------- Nin Zong presented a survey of P2P streaming applications. (start 10:44 ) ? Jan Seedorf: Are you sure, that Zattoo is still P2P based. They have change to serve peer recently. ? Nin Zong: Due to technical reasons? We have to check. ? Jan Seedorf: Same valid to Joost. ? Ron Even: We have a milestone about this in the charter. Should we use this document as basis (4 pro, no vote against). We should ask this also on the list. ------------------------------------------------------------------------------------------ Jan Seedorf presented PPSP design considerations for a PPSP Protocol (start at 10:53 ) EU Research Project since 3 years: NAPA-WINE providing Open source SW. Topology Management is important. What protocol elements are needed to exchange topology management information? ALTO for PPSP is not very easy to use: E.g. you have to take into account upload bandwidth. Localization is not easy to be achieved. ? Chen Tian: Peer to allow contacting to alto. Should be too strong for the peers. ? Jan Seedorf: Alto should be used for peer selection level, not on the chunk selection level. ? Chen Tian: You can have other mechanism for this selection. You should change to may. ? Ron Even: This is not a requirement that is a proposal. ? Alto only reflect IP address selection. This has implication to requirements as well. ? Jan Seedorf: Alto is not the only solution. Peer needs to measure himself and combine the results with Alto information. ? Richard Yang: Open source code: Protocol specification? ? Jan Seedorf: Not done in this spec. There is no specific protocol selection done yet. --------------------------------------------------------------------------------------------------------- Kent Wu presented P2P Layer Streaming for Heterogeneous Networks in PPSP. ( start at 11:07 ) ? Ron Even: This is not within the charter yet. will need to see where to address such proposal. --------------------------------------------------------------------------------------------------------- Ove Strandberg presented Securing Naming structure and ppsp interaction. ( start at 11:19 ) ? Ron Even: Swarming and how to retrieve name are not in the charter. ? David Bryan: Information Naming scheme: A lot of problems will disappear, using this. ? Ron Even: We have to look at it. ? David Bryan: It is worth to be read. ? Ove Strandberg: We should introduce some requirements. --------------------------------------------- PPSP Incentive parameters Ran out of time and did not present. --------------------------------------------- P2P-vod system Ran out of time and did not present. _______________________________________________