PPSP Session IETF83 Paris
Wednesday, March 28, 2012: 09:00-11:30
Minutes by Christian Schmidt and edited by Yunfei Zhang

Yunfei Zhang thanked Martin Stiemerling for his support of the PPSP WG and welcomed StefanPrevidi as new co-chair.

Problem Statement and Requirements of PPSP (Yunfei Zhang)
- Summary of IESG Review
- New short WGLC ended without comments
- New DISCUSS: Why are existing IETF protocols not enough
- Feedback on the list appreciated, perhaps a new WGLC after IETF83 would be appropriate.

PPSP Peer Protocol (Arno Bakker):
- only 2 people in total responded on one proposal
- Yunfei: Suggestion: Do general accounting mechanism first. Mapping mechanism is needed. (Proposal 10+13)
- Martin: It is questions about SHOULDs. Several have to be changed to MUST.
- Yunfei: For chunk addressing: MUST is ok. Streaming can tolerate chunk losses. Is MUST necessary for integrity protection?
- Arno: Dependent from the environment. If things are important, you need integrity protection.
- Yunfei: Is this expensive?
- Arno: No, you will see this in the demonstration.
- Martin: MUST/SHOULD: You must implement, but you must not use.
- Fabio: Agree with Martin. It should be a MUST implement. If less complex solutions with same integrity protection will evolve, this should become a MUST. In certain scenarios it makes sense, that you do not need integrity protection.
- Sumanth?: We should do a MUST implement, to make sure, what they have to implement. Not must use.Merkle Hash solution is very old. People should come with an alternative. We have a proposal on the mailing list solving the requirements.
- Martin: Ok with the proposal. If one has an alternative, propose on the list.
- Lichun: Have alook at HTTP streaming, perhaps we can learn from them. We can allow both HTTP and p2p streaming (alternative download possible). Have to be part of metadata.
- We have systems with fallback to HTTP download already in the past.
- Yunfei: Please send comments on the mailing list for clarification.
- Fabio: List of interval, check gaps. Works well if system that is not too much fragmented. Add simplicity, overhead to bin numbering should not be very high. Tradeoff among complexity / overhead / efficiency /implementation.
- Yunfei: Agree with Fabio.
- Arno: Have a look at the numbers. Its not a big issue.
- Martin: Lets take this discussion on the list. We have this discussion since the last IETF and we should solve it on the list.
- Arno: Proposal 26: Keep the existing one.
- Martin: Using the first response sending data. Is it really good to wait 200ms for the data
- Arno: My proposal aims to start with data download as soon as possible.
- Martin: Security AD could object sending data before first response. Possible security attack (Martin should provide). I can write up to the mailing list.
- Arno: We think, it is sufficient, not to wait a further round.
- Martin: Not sure, if the security guys would accept.You have to keep status for this purpose.
- Martin: You do not want to keep tons of states.
- Yunfei: Describing another attack about cheating the claim.
- Arno: That’s another type of attack. There is no difference between overloaded and malicious peer in this case.
- Yunfei: Is there a message to prevent this?
- Arno: Very complicated, peers have to report on misbehaving peers. And anybody can make statements.
Proposal 17+20
- Arno: Proposal: Membership certificates. There are several options possible.
- Yunfei: Assuming peerA has a public address?
- Arno: Yes
- Yunfei: What about a peer behind a NAT?
- Arno: The tracker knows what port you are coming from, and this is a public IP/Port.
- Yunfei: What happens if IP/Port change?
- Arno: Membership would break down.
- Fabio: No an expert, but: In case of 16000 streams I would have to keep 16000 memberships. Bandwidth load of different identities.Contact tracker 16000 times and receiving 16000 membership. Sounds like a problem.
- Arno: Secure sampling is very hard.
- Fabio: Lets take it to the list.
- July: No expert in P2P.What is the route of trust?
- Arno: You can have different certification schemes.
- July: Maybe we can have a centric system.
- Arno: In the current design the tracker is a central point of trust.Punishing a peer in a p2p system is hard. You need some proof for this. Very complex to have allegations in a p2p system.
- Arno: There are more open issues to be added to the mailing list. (Lack of time).
- Martin: We have a lot of open issue. Please respond on the list. We should start this today.

Tracker protocol
Last time, we have no decision to take this as WG document. In the meantime, no alternative have been published. So we will discuss today again, what to do with this proposal.

Request/Response protocol (Rui Cruz).
- Yunfei: How to differentiate peers disconnected from swarm and tracker in the message.
- Rui:Disconnect has a parameter swarm. If swarm=all, tracker connection stays. If swarm=new the tracker connection is cancelled.This will be included in the next version of the protocol.
- Rui:Peer is not constantly connected to the Tracker.
- Martin: FIND – for specific chunks of media content – I am opposed to this. Peers should not have to have this information.
- Rui:That’s an option. This info could be available from the tracker.
Martin: Chunk info is not available.
-Arno: Agree with Martin. This could be a huge overhead, needing a constant refreshing. This could be optional.
- Fabio: Agree, this granularity is too much. But think about e.g. playback pointers. Another example is bandwidth, slow convergence time. Saving upload bandwidth is important.
- Yunfei: Maybe there is a scenario to use specific chunks. In case of search of more appropriate peers.
- Martin: This was for Video on Demand.
- Yunfei: Yes.
- Rui:Peers may not have the same content, e.g. different quality of streams. This could be an answer for this question.
- Ricardo: Agree on this issue. But it should be mentioned for what it is meant and that it is optional.
It can be useful for other issues as well, depending on the implementation.
- Mark Stuart: I am still amazed by the complexity without proper reasoning. Disconnect, Reconnect..Can you replace them with simple GETPEER message? Classical BitTorrent message? The only state you need. No overhead. Simplify everything. You have all messages you need. A single request/response. Why do you need a rejoin?
- Rui:We are talking about streaming, not file sharing.
- Mark Stuart: Is this for access control? Clarification from chairs, is DRM in scope again?
- Martin: Clarify on DRM. We do not promote the usage of DRM, it is a wide field. It may be used in the protocol, but we do not specify it here.
- Mark Stuart: So we take into account access control, but I do not see this in the requirement. I see not need for this complexity. Reconnect and Rejoin. Why should this accelerate things?
- YingjieGu: One message would have to provide different messages. We need different messages.
- Fabio: Agree with Yingjie, we should keep the Tracker Protocol as simple as possible. We should have more than one request/response message for certain purposes. Let’s discuss concrete use cases of additional messages.
- Rui:These are no new messages, e.g. re-CONNECT just reuse message.
-Rui: We should differentiate between basic solution and optional additional messages for further use cases. Connect and Join can be put together.

Stefano as future co-chair:This session is a burden to the writer of the notes. There have been no activities on the mailing list, but very detailed discussions here.
5 persons were in favor to take it as WG item, nobody was against.

- Yunfei: I am author of survey draft and also an author of tracker protocol. We are lack of contributions from main p2p streaming providers.We have discussed this lot. We have to learn more from the existing protocols and try to integrate existing streaming providers more to the PPSP activities.

- One member working for a p2p streaming provider was in the room.

Mark Stuart (TU Delft): Implementation presentation.
- Yunfei: Is storage enough for cache purpose.
- Mark: Yes, we see not big volume of content here.
- Yunfei: What does it mean 1.5GB file uses 7MB (size of MHT)
- Mark: That the size of the hash tree.
- Yunfei: Can you move forward?
- Mark: Not in the current Swift version.
-Johan: What will be the next level in standardization?
Stefano: After WG consensus, this will go to IESG.The fact, that you have a running implementation is a very good thing. It starts the trigger. It is a good argument for the IESG to consider. A second independent implementation would be very helpful.
- Mark: Is there a related Timeline?
- You first have to find consensus in the WG.
- Mark: The discussions only happen in this room. How long do we have to wait?
- There is no timeline. The chair can decide, there is no more progress and we want to go further. You have to go to the maling-list to find consensus. Can we put mail-stones to the mailing list?
Stefano: Patience is one of the requirements in the IETF.