PPSP WG (Mo 28.3.2011, 9:00-11:30) Yunfei presented the Problem Statement ID Clarification: “ISP has the willing to build an open infrastructure for low-cost unified streaming delivery using P2P tech”. Is this a requirement? Yunfei: Yes Farooq: We have different opion in the Hybrid Case. This will be disallowed by mobile operators. We need to clarify the situation of the mobile operators. Celular Network always uses metering. That is an issue, without makeing a value statement. Eggert: A high level comment: Problem statement and use cases are different. We have to figure out, which use cases do we want to provide first. We have to limit our scope. Mark: We need to use integrity checking for content protection. In a commercial environment, this is absolutely critical. Tanja: Use case 3 confuses. Why do you use different codecs. Yunfei: Different users may belongs to different service providers using different codecs. Jennings: Another revision will appear. Comments on the list to prioritize would be needed. Lin presented the Requirement ID / Schmidt explained an own proposal to add a new section on QoS requirements. Eggert: IP address change should be removed, now it is mentioned optional. Lin: It is an example only. Eggert: Why it is an example, if we do not have it optional. The peer can simple leave and join. It even can keep the same IP address. I see no need for another message for the same operation. We should remove it completely. Lin: Accepted. Eggert: Statement “Peer ID is unique in swarm” need to be consistent. Perhaps I do not want to use one ID for different purposes. Unless there is a reason to be unique, make the scope as small as possible. We should have a discussion, what amount of privacy do we want. In this case, privacy is more important then performance. Stiemerling: Aggreed to Eggerts concerns. Ivanov: Privacy versus security for content. For protecting against malicious modification you need long living unique identifiers. Jennings: Do you need a swarm independent uniqueness? Lin: Corrupt Peers in one swarm would also attack within the other swarm. Eggert: That is a valid statement. We have to figure out a middle way for this purpose. Strand berg: Insteadt of keeping track the id, why not secure the content itself. No further comment. Schmidt presented a motivation slide and some QoS requirements aimed to be included to the requirement document. Eggert: What are the requirements for the protocol, coming from these QoS requirements? Schmidt: Depending on the solution, the transfer of additional parameters for QoS info is needed. Eggert: Requirement 3 should be excluded. Schmidt: Accepted. Jennings: We should continue the discussion on the mailing list. Eggers: We should focus our energy on the protocol. Lei presented Survey ID Lei finished the presentation with the following questions: How to design the QoS for PPSP - Architecture and Protocols? - QoS Related Mechanisms? - Evaluated Metrics? Lars Eggers: These questions do not belong here. Schmidt: Do you have information about the average end-to-end delay of the presented solutions? Lei: No information available. Schmidt: Do you have information, if the presented solutions aim for identical copies, for example in using packet retransmission? Lei: No information available. Cullen Jennings: Defer discussion to the list. Habin presented Tracker Protocol ID Stiemerling: - STAT_QUERY: I do not think we need this. - STAT_REPORT: We should check - Keepalive: Not needed, if you send STAT_REPORTS. - Peer property: Protocol should have a hook to support this. Eggert: - P2P Systems are not centralized. - We want to be robust. - We want to have a way for peer to peer communication. - Optional: We may allow peers to update tracker. P: To base this on HTTP could be a wrong choice. UDP could be a better alternative, e.g. for NAT traversal. Eggert: This is a valid point for data exchange, but not for signalling. Signalling messages are less frequent and keepalives are used. Eggert: The document is a good start. There weher no objections to take this as WG document. Habin presented Peer Protocol ID Lin presented Distributed Tracker Protocol ID Kaufman: - What are the implicatons to the PPSP tracker protocol? - E.g. HTTP is a bad choice for NAT traversal. - How would this work in case of Hotspots? Jennings: - Hotspot problem: A lot of peers requests information simultaneous. Reload do not solve this issue. We define usage how to solve this in a separate ID. This is consistant here and could be used as well. P: With HTTP, it just does not work. Wang presented NAT traversal ID Decision between PPSP and Reload ICE solution will be left to implementation. Habin: Remember the consensus of the last IETF meeting that NAT traversal is out of scope for PPSP. Wang: NAT traversal is necessary in certain scenarious. P: We should do NAT traversal only once. Jennings: Defer discussion to the list. Wang presented DECADE in PPSP ID Alimi: Why is the task to redistribute authentication data via tracker a requirement for DECADE? Wang: Because of the security model of DECADE. Alimi: Please provide more detail, what is needed.