IETF78 Maastricht

Tuesday, July 27, 2010, 15:20-17:20

Minutes taken by Christian Schmidt and edited by Yunfei Zhang

Yunfei presented PPSP Problem statement draft with update on problem description and use cases.

About 10-20 participants stated, that they have read the draft.

Spencer: No reason not to make it a WG item.

There was strong consensus to adopt it as WG item.

Ning Zong presented PPSP Requirements draft

Lars Eggert was concerned about the following requirement:

q Each peer in PPSP MUST has a unique identifier, i.e. peer ID. How to get peer ID is out-of-scope.

What does this mean? Each application has a unique identifier? One identifier for each application of the client? I am worried about unique identifier between swarms. How stable this identifier has to be between swarms? We should add text to the requirement spec for clarification. If you could change the ID per location would be a good thing to have. But I agree, we need an identifier.

David Byran: Either an IP address or a Peer-ID should be used. Not sure if we need a requirement.

Roni Even: Anyway need some discussion on what kind of information the identifier provides to make the right decision.

Lars suggested to add some sentences on the stability description of the peerID.

Some discussions on using IP address as peerID.

Shengyong: Sometime you (the author) need a user ID, sometime you need a peer ID. You should distinguish.

Lars Eggert: Why would this be useful for having a useID?

Shengyong: For billing and authentication.

Lars Eggert: That is not in scope of the WG charter. Charging is not included.

Audience: Perhaps we could add a sentence about this to the requirement.

Lars Eggert questioned another new requirement:

q The content availability update message MUST be advertised among swarm peers periodically or on-demand.

Lars Eggert: Why periodically and on demand? Why is on demand not enough? Let’s discuss offline.

Martin Stiemerling mentioned that the possibility of a tracker to generate the peer list with help of traffic optimization services is not part of the tracker protocol. It makes no sense to do this here.

Cullen Jennings: We have no better place to describe this here.

Lars Eggert: Martin is nervous about this being normative requirement.

Cullen Jennings: Let’s update the wording to make it clear, that it is only informative information.

About 10-15 participants stated, that they have read the draft.

There was consensus to adopt it as WG item.

David Bryan presented PPSP Protocol Considerations and Tracker Protocol

Richard Alimi: Do you need keep alive message for the tracker?

David Bryan: We have one. Most of the existing protocols use one.

Lars Eggert: LEDBAT is no transport protocol.

David Bryan: Accepted. When is it considered to be used in the transport protocol ?

Lars Eggert: Not clear. In re-chartering phase. Some people want it to apply to TCP.

Richard Alimi: Is n’t the peer asking the tracker to poll the subst of peers?

David: To avoid tracker overload, Tracker protocol makes the intelligent first selection and then peer protocol for real selection and connection.

Lars Eggert: Many connections per peer? I do not say we do not need this, but I would like to have more information about.

David Bryan: You want to have information about a peer dying or going away. Metadata about the peers have to be taken to the tracker here. We need more information from the actual service providers. We need to standardize metadata for interoperability. It is not clear, if this has to be done in this context.

Jan Seedorf: Should we use a DHT based peer protocol?

David Bryan: If we do it per IP address, we have to care about NAT traversal. If we use DHT addresses we have NAT traversal for free. It would just be used for connection management,not using DHT for locating the chunks.

Audience: Should we use RTP or UDP for streaming?

David Bryan: We would not reinvent a protocol. In case of UDP, we would use RTP/RTCP based on UDP. In case of HTTP streaming, we want to reuse it .

Paul Karlson: P2p Streaming paradigm is to exchanging content or streams. Are we looking for content? E.g. for live streaming there are very strict privacy regulations in place. Will the protocol take these restrictions into account?Will the protocol tell me which peer I have right to fetch?

David Bryan: Interesting question. Restrict to information, who can send and receive the content , could be included.

Cullen: Wouldn’t include too much here. Can include some filter for only things you can receive. Regarding the general policy , could violate privacy issues.

LIn: Peer location and connection should not be solved in the ppsp protocol. It is enough to define which protocol can be used.

David Bryan: We need to pick one to provide interoperability.

Lin: We can use another draft to describe, how to use. It is not a fundamental part. Don’t specify here how to connect. It is another issue.

Jan Seedorf: Push / Pull / blind push/ blind pull protocol possible? Should be defined?

David Bryan: We should pick one as mandatory to implement (interoperability) and allow to use other solutions as well.

Dirk Kutscher: Nothing in the draft about congestion?

David Bryan: We have not included anything about transport yet. This has not been in the peer protocol yet.

Daniel de Vera presented an overview of the GoalBit Solutions for peer protocol: More details about the pieces and how peers store them? When a new peer enters the network, how does he know where he should start asking for pieces? Should not be considered by the protocol the existence of different kind of peers in the network? For example broadcaster, super-peers, peers? Should not be recommended some guide about the different strategies applied in the protocol?

Richard Alimi Do you distinguish in protocol between peer types?

Daniel de Vera: We have a peer type parameter.

Jan Seedorf: For Peer selection strategy we use the name chunk selection strategy, which should not be standardized.

Daniel de Vera: Agreed. This could be included as implementing nodes.

Richard Alimi: Should not be standardized.

Cullen: RTP would be sufficient as transport protocol?

Daniel de Vera:I never thought about RTP as transport protocol.

Audience: Do you use TCP or UDP for transport?

Daniel de Vera: TCP

Audience: Why?

Daniel de Vera: Following BitTorrent. We only use TCP for this purpose.

Cullen: Due to time problems, the remaining presentations were cancelled.

Please read the remaining presentations and comment them on the list.