[ppsp] International Peer to Peer Streaming Workshop notes(Day2:IETF PPSP related issues.)

[" zhangyunfei " <[e-mail]>]

The workshop notes on 2nd day.Thanks Christian and Spencer for taking the notes.Please take a careful look of it so that we can have the discussion at IETF 78 based on this.

BR
Yunfei
-----------------------------------------------------------------------------------------------------------------------
International Peer to Peer Streaming Industrial and Standards Workshop
June 17-18, 2010 Beijing, China
 
Day 2: IETF PPSP related issues.
Host：Yunfei Zhang and David Byran
Notes:Christian Schmidt and Spencer Dawkins, edited by Yunfei Zhang
 
Lars Eggert (IETF Area Director for Transport):
“This is not an official IETF meeting.”
 
Yunfei: Agenda bashing      
 WS rules:
-          In contrast to Day 1 of the workshop, there will be the possibility for discussions using a microphone within the room.
-          The meeting will be held in IETF manor, questions are possible during the presentation.
-          Will make a transcript from this session for the IETF provided by Christian Schmidt and Spencer Dawkins, so we won’t have to have the same discussions again at IETF 78.
 
Yunfei Zhang presented problem statement of PPSP.
[PPSP Statement @PPSP Workshop1.ppt]
     PPLive broadcast Chinese spring festival for American Chinese using Pando network, but there are few American Chinese using PPLive… need to replace proprietary systems with standardized systems.
We have multiple client implementations (one per proprietary signaling system) in a single client. (And China has experience with clients deleting competing clients in the same terminal)
Proprietary signaling leads to difficult interactions – CDN node can’t identify different private systems. CDN/Cache is updating its protocol using case-by-case negotiations.
CDN doesn’t know how to report to multiple trackers.
Current proprietary protocols don’t address unreliable network connections, battery power life, and different media coding for mobile devices.
We know we can standardize something, because the major systems are so similar (tracker-based, inter-peer communication process). Want to focus on key issues and not reinvent the wheel.
P2PNext thinks broadcasters are anxious to ditch their proprietary protocols in favor of a standardized solution. PPLive seems to be the major P2P service that’s on board.
Still thinking of GGSN as the Supernode in some architectures.
BitTorrent is good reference for open tracker protocol, but has a global view of all peers (need to change this to scale), and has different requirements/user visiting patterns (video quality/delay, channel switching, recruiting additional peers, and supernode/peer role differences).
Would like to use both UDP and TCP to exchange chunk information, but they need ICE for NAT traversal, and TCP-ICE is stalled with no one actively working on it in IETF.
David Bryan presented PPSP protocol considerations
[PPSP Protocol Considerations.ppt]
Two protocols (tracker and peer protocols), but they can’t exist in isolation (peer lists would be common, for example – whether they are peer IDs or IP addresses, for example).
Tracker could be a DHT, but that would be invisible to the peers (client-server interface from tracker).
Doing two tasks (live streaming and offline/timeshifted streaming). BitTorrent is well-suited to offline use case, but BitTorrent provides a random sample of peers – works fine for filesharing, but you might not get a set of peers that contains all the chunks with live streaming.
BitTorrent doesn’t have authentication. HTTP approach is “somewhat heavy”. Could incorporate metadata into tracker, but that’s not in BitTorrent now – we’d need syntax for these files.
BitTorrent peers use a simple gossip protocol – unstructured, not a DHT, no searching.
Regular HTTP is used to obtain the torrent from a web server
The tracker protocol is also HTTP, essentially GET to ask for a list of peers/join swarm
The peer protocol is a TCP wire protocol (binary)
 
01 draft revision “coming soon”. 
For peer protocol:
•          New transport is out of scope. 
•          Not clear whether we can reuse RELOAD from P2PSIP, or whether we need something lighter. RELOAD has been revised to support unstructured overlays, but we don’t have any experience with that yet.
Do you find a peer and stream from it, even for timeshifted? Could use RTP for that.
 
Lars Eggert: Bothers me to use different transports in case of live streaming and download.
Audience: With RTP you could not do progressive download. You could just fill the buffer.
Lars Eggert: has anyone looked at the research papers on live streaming in BitTorrent? David is aware of these.
Lars Eggert: we’re doing protocols, not defining local behavior. Don’t need to do that for interoperability. We need somebody to tell us, if we have the right and sufficient meta-system for this.
David Bryan: Extensibility is not a critical issue here. Metadata may be a significant part of the protocol.
Martin – P-exchange (not pure gossip). 
David – there are more sophisticated gossip protocols that could deal with DOS attacks.
Omer Luzzatti: Who is responsible for allocating bandwidth that’s needed for a channel? It could only be tracker. Huge difference between file sharing and live streaming. 
 
It has to provide balancing. It has to do peer switching for the benefit for all. This would not work here. Peer could request more resources from super nodes. Tracker must provide more then peer selection.
ALTO has been focused on BitTorrent, now looking at CDN. Are you looking at ALTO yet? Haven’t looked at this much, but really need to hear from people who have implemented these systems (don’t need theory). 
David Bryan: That’s the point, where ALTO fits into, e.g. for load balancing. There are a lot of open questions here. We have to provide flexibility here, e.g. also for different providers.
Lars Eggert: ALTO is more for first peer selection. Do not forget DECADE, providing network internal resources. Problem: Building a complete p2p system is too much for a single Working Group. We should concentrate on basic solutions first. We need to talk with people, running these systems, not to standardize the wrong protocols.
Stefeno: ALTO could be of benefit. Do you see architectural requirements in this case? Difference in ALTO implementation point is not dramatic. We have the same kind of context.
David Bryan: It could be the right tool, but we need feedback from vendors.
 
Lars Eggert: How to find the proper source for live streaming?
David Bryan: That is the piece of information that is currently missing in ALTO.
Spencer: Would you use the same ALTO for live streaming and for filesharing? Not clear – it should be application-agnostic, but not clear that this is realistic. What matters for file-sharing is bandwidth and TTL, what matters for live streaming is whether you have the right chunks and TTL.
Really hard for tracker to know what chunks a peer really has – if you said “I’m at one hour” and then paused for ten minutes, how does the tracker know whether you are now at one hour or at 70 minutes?
Martin Stiemerling: We should keep congestion information out of ALTO?
Does RELOAD support unstructured overlays? Two of the three protocols merged for current RELOAD supported unstructured overlays, but we haven’t verified that current RELOAD still supports unstructured overlays at a sufficiently low level of overhead to make it an appropriate protocol for PPSP. 
David will be working on a RELOAD usage draft in PPSP as a proof of concept (RELOAD usages go to the working group that’s planning to use RELOAD, not to the P2PSIP working group).
Yunfei Zhang: Hope so that we can reuse Reload in PPSP.
 
(Lars says LEDBAT is picking up steam with its new chair, will be working on UDP implementation – this is good).
 
Yishuai Chen presented Open Issues in PPSP
[Open Issue-v2.ppt] Beijing Jiao Tong University
Cited a couple of interesting-looking studies: “A measurement study of a large-scale P2P IPTV System” and “Live streaming performance of the Zattoo Network”.
Basically going through existing protocols and explaining why they aren’t quite appropriate for PPSP…
How PPSP reuse existed protocol?
–         Peer <->Tracker Protocol
•          BitTorrent
•          eMule
–         Peer <-> Peer Protocol
•          RTP
•          RTCP
•          RTSP
•          LEDBAT
 
Martin Stiemerling: What is a sub stream based system?
Yishuai Chen: RTP dividing of streams to sub streams.
Omer Luzzatti: Sub stream enables push protocol, needs request/response protocol.
Yishuai Chen: How about RTP, RTSP? SeqNo and Timestamp are required.
David Bryan: RTCP provides feedback, can image this functionality for PPSP. Do you want to reinvent this in the PPSP protocol?
Yishuai Chen: Yes, I think so.
 
Lars Eggert: As for the number of the connections, you want to download from 50 peers or more simultaneous. Is this the number of peers for the whole time or real simultaneous?
Omer Luzzatti: In our system, we download from up to 50 peers and super-nodes simultaneously and this in no problem.
Lars Eggert: Which system did you measure?
Yishuai Chen: PPLive
 
Martin Stiemerling: Using RTP between peers, what about scalability issues. Usually we are using chunk with bitmaps to keep it short. What size of bitmaps do you use? Bitmaps could be really big.
 
Zhao Youn-xiang presented signal frequency in streaming system
[signal.ppt]
Measurement in p2p streaming networks indicate that there is 30-40% overhead. Seeing 1.3 Tbytes sent, but only 1 Tbytes received – where did the rest go?
Looks like upstream access link buffers can hold 40-50 packets, but drop packets if the burst is bigger than that, so assuming that packet loss is happening in the access links due to large bursts…
Believe that most overhead happens just after a piece is released into the network – only a few peers have the piece, and many peers request it, leading to serious contention.
Lars Eggert: problem is actually that you’re not backing off (in the model, not backing off at all) in the presence of congestion – that gives you high overhead/loss rates because you have no feedback loop. Lars is concerned that this accurately matches what’s really being deployed.
TCP could be used to reduce packet loss due to overload situation with feedback to the sender to reduce the data rate. With this you could reach a reduction of overhead. Your model is too simplistic. You can reduce the number of copies you send out simultaneous.
David Bryan: A lot of systems do this nasty think. It is not good but a lot of them doing this because they’re trying to maximize the global bandwidth being transferred. That’s a huge problem.
Omer Luzzatti: This shows, the current solutions have some serious problems. What is the propagation time releasing data to the users?
Zhao Young-xiang: No measurement made.
Omer Luzzatti: Congestion control has different solutions in p2p systems. Can we add more peers? That is the actual congestion control in p2p networks. Advantage for SCTP. We use push idea.
Zhao Young-xiang: Mixture between push and pull could be the optimal solution.
Spencer Dawkins: We have started to avoid TCP, perhaps we have over-compensated?
The reaction on network losses was adding more and more buffers, simply adding queuing delay .This could be a bigger problem for real-time traffic than for bittorrent usage. 
Lars Eggert: Buffering causes problems, adding about 400msec round delay. IETF did care of congestion control only for a single flow, not a group of flows. We do not know how to handle the aggregate set of connections. 
We tried to avoid congestion collapse. We tried to establish some kind of fairness between the various flows. 
David Bryan: These systems do not use these methods.
Lars Eggert: Congestion between Live Streaming and Real time communication at access seems to be unlikely.
Spencer Dawkins: The IETF once thought all transports should act like TCP. We don’t think that any more, but we may have overcompensated for the earlier restrictions.
 
LEDBAT is chartered to think about advice for multiple flows, but we don’t have an answer in the IETF yet (“research topic”). 
We don’t have a fairness vision for these applications, either. We’re probably not looking at congestive collapse of the Internet, but we could be looking at starvation of well-behaved applications. Lars thinks that MIGHT be OK, but it’s still an open question.
M2M networks assume that core networks are congestion-free – M2M can distribute traffic across the whole networks, and M2M communications can “run away” from a congested link by choosing a different peer to communicate with. If there’s a bottleneck link, it would be at the access link.
What’s being proposed in this presentation will result in sustained congestion collapse if there IS congestion in the core network – peers continue to request the same chunks when the chunks aren’t being received, and the speaker isn’t describing any backoff mechanism at all.
This is a really important discussion topic – maybe work for the IAB…
 
 
David Bryan presented a Tracker Protocol Proposal
[Tracker Protocol.ppt]
Presentations related to encoding/transport, used messages, header examples and open issues.
 
Is there a reason NOT to use TCP/TLS for transport? 
Lars Eggert: Use TCP for Transport
Martin Stiemerling: Tracker can also poll peers, that requests TCP, e.g. for NAT traversal.
David Bryan: Good point
Spencer Dawkins: Do you want to reinvent ICE?
David Bryan: Reload does not fit into this PPSP solution.
Lars Eggert: Do I need to keep the connection to the tracker open during the streaming or can I close them every time.
David Bryan: Depends on the question, if TLS is appropriate.
Lars Eggert: Cache this or reopen the TLS connection.
David Bryan: Not thought about the question.
Henning Schulzrinne: Perhaps the client does not know that the connection has failed. Be very clear about the relationship between TCP connections and associations – don’t tie these together, that’s why we have cookies. Not worried about massive number of connections until you get to 500K – above that is hard, below that is OK.
Henning Schulzrinne: Binary vs Text encoding: 5-10% optimizing reasonable? Don’t do reinvention of HTTP, either! Is this a symmetric protocol? Then HTTP would be the wrong model. STATS message is the one that breaks the client-server model. Need to know who has to talk to whom, for how long, who initiates, etc. 
Server-originated JOIN request? 
Metafile isn’t quite the same between video on demand and live streaming (don’t do MD5 for live streaming?). This is what we need deployment experience with, to make sure we’re meeting the needs.
If we do unstructured, we probably need to do IP addresses – can’t search meaningfully in an unstructured overlay of millions of peers.
Draft update will have “hard questions” section. David is hoping for agenda time at IETF 78 to discuss these.
 
Akbar Rahman presented P2P Streaming for Mobile Nodes: Scenarios and Related Issues
[P2P Streaming for Mobile Nodes_01.pptx]
·         The scenarios where P2P streaming networks contain mobile nodes require special consideration to deal with issues such as:
–         Change of Peer IP address (possibly rapidly/frequently)
–         Extra latency in data path (due to mobility protocols)
–         Mobile device constraints
–         Etc.
 
Lin Xiao: Assumption on network layer. All can be solved by MIP or PMIP.
Akbar Rahman: That is the next scenario. This scenario assumes no MIP support.
Lars Eggert: Why should the peer update the tracker? How often? This is the old seamless problem. We will never been able to fix.
Spencer Dawnkins: We will never been able to provide seamless mobility. Handover between cellular and WiFi that’s ambiguous.
Audience: My Iphone do this a lot, we have at least to consider it.
Spencer Dawnkins: For this purpose, you should use mobile IP.
Yunfei Zhang: Mobility doesn’t lead to so serious for p2p performance. Most mobility changes can be ignored due to the cache. 
Chunxi Li: Agree.Performance of PPLive Simulation. If mobile devices are in a minority, than a good performance can be reached. Buffer can tolerate certain mobility.
David Bryan: We need to have some level on staleness in the tracker. A more persistent connection could be causing problems. 
Lars Eggert: There’s a line where so many peers are switching IP addresses that the system is no longer useful.
Lars：Seeing more handset vendors talking about multi-homing, so that devices have more than one active interface, and the IP address in the peer-list is still active – limiting to a single active interface is probably a mistake.
Lars：on’t think MIP6/PMIP6 is the likely scenario – need to make sure that whatever we do works without MIP6/PMIP6.
MIP6/PMIP6 may introduce extra latency due to tunneling.
Henning： MIP isn’t widely deployed now, and if it is widely deployed in the future, it’s likely to be MIP6, not MIP4, which is much less likely to experience triangle routing. This isn’t a real problem, don’t worry about unreal problems.
HIP is being considered for mobility support in RELOAD – need to look at PPSP-RELOAD interactions for HIP (and MIP6, and PMIP6, and …)
Henning Schulzrinne: This is not really a P2PSIP WG consensus. You depend on something, not ready and widely deployed.
 
Interaction between geo-targeting and IP mobility：
Lars Eggert: Why do you want to solve this at the data layer? Why do you not try to confirm this during joining. You should not link the decision on IP basis. 
Spencer Dawnkins: This is not a PPSP problem.
Lars Eggert: For client / server based solution this is exactly the same problem.
David Bryan: Rat hole kind of issue, perhaps we should not reinvent this any way. Perhaps it could be done on application level. We should not do this on protocol level. We should add this to the list of things we want to leave out of scope.
Lin Xiao: Basic Mobility Problems are not PPSP specific and should be done e.g. in MIP.
Audience: Is IP address chances on multiple IP address PPSP specific?
Lin Xiao: Not PPSP specific.
Yunfei Zhang: To see if works for IP layer mobility management. If there are big problem, perhaps we need additional application layer information.
Lars Eggert: we should definitely say something about battery-operated devices in P2P streaming systems – maybe not for PPSP, but if not, for P2PRG. May be able to add network infrastructure to avoid having battery-operated devices streaming content to other users and exhausting batteries in a short time.
Audience: If I change IP address, another peer can not continue download from me. We need more super-nodes to download information for others.
 
Christian Schmidt presented QoS for p2p live streaming
[QoS for PPSP Live Streamingb.ppt]
Main messages:
No quality of service for p2p live streaming is not good enough
Competing technologies are traditional TV broadcast and Client/Server live streaming solution.
QoS for p2p live streaming is different for other p2p services, e.g. file sharing, multimedia communication and p2p video on demand.
QoS Improvement can be reached by additional streaming distribution within the network and usage of streaming quality information from peers for optimal source selection.
Henning：We’ve tried QoS classes before, for a long time, with less than ringing success. We don’t know the user behavior for the user experience. We did research on human response to phone call disconnects 40 years ago – without research like that, all this is arbitrary. We do know that people are more likely to complain about content when they pay for it, for example. 
Lars: this is all about QoS of P2P streaming systems, not PPSP protocols.
Yunfei: May fetch some message in PPSP protocols to show the preference on QoS ensured peer selection or current QoS conditions of the peers.
 
Definition Requirements for PPSP Requirement Spec.
-          Values for QoS Limits very subjective
-          Not clear, what has to be standardized in IETF for this purpose.
A proposal was made to define a framework for QoS p2p live streaming. Authors could be Henning Schulzrinne, Bhumip Khasnabish and Christian Schmidt.
 
 
Tian Chen presented modular design of P2P live streaming
[Not available]
RISE: Robust Internet Streaming Evaluation (ongoing Research Project)
Work on P2P live streaming “improvements” is outpacing our ability to test and evaluate new algorithms before they are deployed at scale (the topic of interest is performance evaluation, not correctness).
This is a modular framework for software implementations that allow P2P overlay operators to quickly extend P2P live streaming networks (and to back those extensions out of the overlay if problems are discovered in operation with real users).
Impacts on PPSP: PPSP would need to provide separate peer lists as Stable and Experimental 
 
Yunfei Zhang: What kind of protocol do you use in the test pad? PPLive
Tian Chen: Yes: PPLive
YUnfei Zhang: is it public?
Tian Chen: We will make it open source in future.
 
Yunfei Zhang presented Goalbit introduction and protocol reference to PPSP
[Goalbit-IETF-20100617.ppt]
•          Project goals
–         Open Source P2P video streaming solution (the first one, released under the GNU General Public License)
–         Open protocol reference implementation
–         Includes a peer tracker protocol and peer peer protocol that’s based on BitTorrent.
 
Kent Kangheng Wu presented P2P layered TCP streaming. 
[draft-wo-ppsp-p2p-layered-streaming-00.ppt]
Lars Eggert: Why are peers on lower layer not helpful?
Kent Kangheng Wu: It has low bandwidth; we assume there is no uplink capacity available.
Lars Eggert:  Peer on a higher layer may make decision to provide higher / middle or lower layer information?
Kent Kangheng Wu: Will be answered later.
 
Lichun Li presented P2p CDN using RELOAD and PPSP
[P2P_CDN_using_PPSP.ppt]
l       CDN
l       Improve QoS
l       Reduce network traffic
l       P2P
l       User node assisting content delivery can reduce server load
l       Using P2P among servers to improve reliability, scalability and reduce deployment/maintenance overhead
 
Omer Luzzatti: Tracker notifying the storage: Discontent now available on the cacher. What is important for this kind of decision?
Lichun Li: Depends on policy. IPTV has high QoS requirements, in relationship to normal TV. 
Lars Eggert: Introduction of new components Cacher / Storer. We should not consider this In PPSP. A lot of more Metadata would be needed. Current protocol should be extensible to add these messages in the future, but it should not be included in the basic solution.
Omer Luzzatti: New type of equipments, really consider this as something important.




zhangyunfei
2010-06-28