Subject: [ppsp] IETF-82 meeting minutes for PPSP

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Nov 2011 14:34:12 +0000

Dear all,

Please find below the meeting minutes of the PPSP session at the IETF-82 meeting in Taipei. 

You can also find the minutes here:
http://www.ietf.org/proceedings/82/minutes/ppsp.txt

Please check the minutes and the let chairs know any change request until December 1st, 5pm PT. 

Thank you,

  Martin

Minutes are here:

IETF82 Taipei, 13.-18.11.2011 
Tuesday 15.11.2011 9:00-11:30: PPSP 
Minutes by Christian Schmidt

Administriva (note takers, blue sheets, note well, agenda) 
Announcement of a PPSP demo (after the PPSP session) 
Current Status and progress

Rui Cruz presented Tracker Protocol (draft-gu-ppsp-tracker-protocol)
Martin Stiemerling (Floor): I am confused about the maturity of the ID, things are missing or put into in a 
rush. The slides do not reflect this status. You should focus on the basic issue for the tracker protocol 
and leave other topics for further versions. Or put these to the appendix, to be considered in a later 
version. 
Rui Cruz: Accepted. 
Martin Stiemerling (Floor): What is the semantically meaning of Disconnect? 
Rui Cruz: Leaving all swarms. 
Martin Stiemerling (Floor): It is not written in the ID. It is perhaps somehow hidden in the text. 
Rui Cruz: Perhaps. Using Leave could be an alternative. 
Martin Stiemerling (Floor): What happen if the peer just vanishes? 
Rui Cruz: On not receiving the tracker report, the tracker can clean up the connection. 
Martin Stiemerling (Floor): This all is not described in the ID in a proper way, e.g. the state engine. It is 
hard to understand the implication. An updated version is needed. 
Rui Cruz: It is already addressed in the draft, how this all works. 
Martin Stiemerling (Floor): I am not sure.
Request Messages 
Arno Bakker: For security layer SASL was chosen, not HTTPS? 
Rui Cruz: HTTPS can be used. SASL is a very lightweight protocol. The session between peer and tracker 
is not kept open. Therefore SASL is better. 
Arno Bakker: Please explain this in the ID, why HTTPS is not taken into account. We have to be very clear, 
how security works in this aspect. It is missing, it is very important.
Yunfei Zhang (Floor): How does a Leech announce that it contributes to other peers? 
Rui Cruz: Announcement at the beginning. Peerlist contains all peers in a swarm. 
Yunfei Zhang (Floor): In live streaming, what is the difference of a peer to be a LEECH or a LIVE SEED? 
Rui Cruz: LIVESEED is Source of live streaming content.
Riccardo Petrocco: Are just helpers for a swarm included? 
Rui Cruz: Not specified in the ID. E.g. superpeers are not included. 
Riccardo Petrocco: A description for this is missing in the ID.  
Martin Stiemerling: Clarify role of SEED and LEECH in live streaming. 
Rui Cruz: There is a specific condition; there is neither start nor end.
Arno Bakker: How to avoid malicious peers to act as LIVESEEDs? 
Rui Cruz: Security aspects for swarms are not easy to achieve. 
Arno Bakker: You have to add information to verify content, that's not in the ID now. How to protect 
LIVESEED label? 
Martin Stiemerling: Take this to the list.
Martin Stiemerling: Privacy issues with ChunkMaps? Contain ChunkMaps for all the streaming contents 
the peer is currently joined? 
Rui Cruz: No, only the info related to a certain tracker.
Arno Bakker: in interim meeting we agreed on a basic tracker with minimal function. Are all of the 
presented features mandatory? 
Rui Cruz: No, most of them are optional.
Riccardo Petrocco: Status messages are not clear, why do you need all this information, e.g. ChunkMap? 
Rui Cruz: The tracker should know, this is the structure and who has what.The protocol does not care 
about the structure. It helps the tracker.
Is this ID ready for WG item? 
Ning Zong: This is in the right direction. Language has to be checked. I support this as WG item. 
Martin Stiemerling (Floor): ID is on the right track, but very important parts are missing, e.g. syntax, 
semantics and how it works. I would feel uneasy to take this as WI now. Another version is needed . 
Arno Bakker: Agreed another round is needed. 
Yunfei Zhang: We should have another round of modifications before taking this as a WI.

Rui Cruz presented Peer Protocol (draft-gu-ppsp-peer-protocol)
Arno Bakker: If you use pull based model for chunk maps, then you may be lacking behind in information. 
You need actual information about content you really can supply. How do you ensure actuality? 
Rui Cruz: Sequential method to fetch chunks. E.g. the rarest can be addressed first. What chunk do I 
need for immediate presentation? 
Arno Bakker: There is an asymmetric situation. You can come into a situation, where nobody has certain 
chunks to provide, due to the delay in information. 
Rui Cruz: This is not part of protocol primitives. 
Arno Bakker: They can have influence. 
Martin Stiemerling (Floor): This information is periodically distributed from the system. I do not 
understand why pull method is used here. 
Rui Cruz: The name of the primitive is misleading here. 
Martin Stiemerling (Floor): There is no GET for chunk map update. 
Arno Bakker: Push Method is urgently needed. 
Rui Cruz: Push mode could cause malicious attacks. 
Yunfei Zhang: PPSP support both push and pull mode. Modify the ID to support both modes. 
Martin Stiemerling (Floor): Very high level, crucial issues are missing. Can we support both push and pull 
in parallel? 
Rui Cruz: Yes. In live streaming push may be more appropriate. 
Martin Stiemerling (Floor): Hybrid mode could be possible. E.g. pull the next hundred chunks. That is 
something we need.

Arno Bakker presented Peer Protocol (draft-grishchenko-ppsp-swift)
Yunfei Zhang: Normally the checksum is included in message. Checking data integrity with checksum 
after downloading the data is common usage. 
Arno Bakker: Hash message contains all info needed to check the data. Hash info is combined with Data 
message. 
Martin Stiemerling (Floor): Is it only used for VoD or live streaming? 
Arno Bakker: Both. 
Yunfei Zhang: Different peers have different conditions. Perhaps with push you waste bandwidth: 
Arno Bakker: We do not push chunks: 
Yunfei Zhang: That's valid for chunkmaps as well. 
Arno Bakker: I always inform you, what chunks I have. 
Yunfei Zhang: This could be optional. 
Arno Bakker: I do not think this is very expensive. The overhead is small. 
Ming Song: Rarest first policy, maybe push is not the best solution. 
Arno Bakker: If you use other policies, please provide this info to the mailing list. 
Martin Stiemerling: List name and impact of policies to protocol.
Martin Stiemerling (Floor): Is there a reason to go over RTP? 
Arno Bakker: HTTP or RTP to be used in the charter. 
Martin Stiemerling (Floor): I would prefer going over UDP. This needs further discussion. 
Yunfei Zhang: Charter says, we should reuse existing protocols, RTP is just an example. It doesn't  mean 
we have to reuse RTP even it's not suitable. 
Arno Bakker: We have to protect the content against malicious modifications. 
Enrico Marocco: Does HTTP here really make sense? Better explain why HTTP does not make sense. 
Arno Bakker: Agreed. 
Martin Stiemerling (Floor): It was not Arno's idea, we should not do this. 
Enrico Marocco: Do you have scalability numbers? 
Arno Bakker: We tested it with 200 peers. 
Enrico Marocco: Question on hashtree: can roothash be used to validate the complete stream? 
Arno Bakker: In theory yes. 
Enrico Marocco: Why not use individual hashes? 
Arno Bakker: You can optimize the system; you do not have to send the complete hash table. 
Enrico Marocco: More efficient than sending a hash for every chunk. 
Arno Bakker: As said, it can be optimized, included in the ID:
Martin Stiemerling (Floor): ID fairly elaborated. Can you include traditional ways to handle chunks and 
hashtables? 
Arno Bakker: We can extent the ID for this purpose, we can add in a next revision.
Martin Stiemerling: Two peer protocols presented here. It is hard to decide, what the best way forward 
is. What is the opinion of the people? 
Yunfei Zhang: I would like to see a merger of both protocol, both of them have some advantages. Let's 
find consensus on message definition and then how to use these messages. 
Enrico Marocco: I would really like to avoid the merger. Have beauty content and decide. Some features 
can be included into the other proposal. 
Arno Bakker: Go forward with Swift. 
Martin Stiemerling (Floor): Gu - lack of maturity in the ID. Swift looks more as a workable solution. Let's 
take swift as basis, this would make things a lot easier. 
Shawn Shedy: as implementer - swift seems to me mature and complete. I would like to see this as basis 
for the peer protocol. 
Enrico Marocco: Integration would not be a good solution. 
Martin Stiemerling: Here a majority is more in favor of swift. Let's take this on the list to make a final 
decision.

Xiao Lin presented Distribured Tracker (draft-xiao-ppsp-relaod-distributed tracker)
Due to limited time, there has been no discussion on the distributed tracker presentation. It was 
suggested to give comments on the list.

[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Arno Bakker <[email-masked]>
Date: Mon, 28 Nov 2011 10:28:39 +0100

Hi

> Arno Bakker: How to avoid malicious peers to act as LIVESEEDs?

AB: "How to prevent malicious peers claiming to be LIVESEEDs?"

> Arno Bakker: You have to add information to verify content, that's not in the ID now. How to protect

AB: "You somehow need to say 'live source for this swarm has this public 
key'. Need to link swarm to real injector. How you do this should be in 
the draft as well."

 > You need actual information about content you really can supply. How 
do you ensure actuality?

AB: "If you use pull based model for chunk maps, then you may be lagging 
behind on the real situation. You need actual information to be able to 
do rarest first. How do you ensure the peer's upload is utilized as much 
as possible?"

> chunks to provide, due to the delay in information.

AB: "The implication of this design is only people further in playback 
time can provide pieces. If these people leave the swarm because 
download is complete you can come into a situation where nobobdy has the 
last chunks to provide."

> Arno Bakker: They can have influence.

AB: "They do influence how up to date the information is that you have 
to do piece picking with. In pull-based there is delay between what is 
known locally and what is happening in the system."

> Arno Bakker: We have to protect the content against malicious modifications.

AB: "We have to protect the RTP header against malicious modification too."

> Enrico Marocco: Does HTTP here really make sense? Better explain why HTTP does not make sense.

AB: "Yes please, no HTTP. We only discuss it because it is in the charter."

Regards,
      Arno

---

From: zhangyunfei <[email-masked]>
Date: Mon, 28 Nov 2011 18:10:18 +0800

Thanks Arno for the correction.Ｗill check the details and update the minutes.

Yunfei

zhangyunfei

From: Arno Bakker
Date: 2011-11-28 17:28
To: [email-masked]
Subject: Re: [ppsp] IETF-82 meeting minutes for PPSP
Hi

Regards,
      Arno
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp