On Sat, Jan 06, 2007 at 08:46:41PM -0600, Frank Bulk wrote:
What does the Venice project see in terms of the number of upstreams required to feed one view,
At least 3, but more can participate to improve resilience against partial stream loss.
and how much does the size of upstream pipe affect this all?
If the application doesn't have enough upstream bandwidth to send a proportion of the stream, then it won't. Right now, even if there was infinite upstream bandwidth, there are hard-coded limits, we've been changing these slightly as we put the application through more and more QA. I think right now it's still limited to at most ~220Kbit/sec, that's what I see on our test cluster, but I'll get back to you if I'm wrong. Detecting upstream capacity with UDP streams is always a bit hard, we don't want to flood the link, we have other control traffic (renegotiating peers, grabbing checksums, and so on) which needs to keep working so that video keeps playing smoothly for the user, which is what matters more. If the application is left running long enough with good upstream, it may elect to become a supernode, but that is control traffic only, rather than streaming. Our supernodes are not relays, they act as coordinators of peers. I don't have hard data yet on how much bandwidth these use, because it depends on how often people change channels, fast-forward and that kind of thing but our own supernodes which presently manage the entire network use about 300 Kbit/sec. But once again, the realities of the internet mean that in order to ensure a good user experience, we need to engineer against the lowest common denominator, not the highest. So if the supernode bandwidth creeps up, we may have to look at increasing the proportion of supernodes in the network to bring it back down again, so that packet-loss from supernodes doesn't become an operational problem.
Do you see trends where 10 upstreams can feed one view if they are at 100 kbps each as opposed to 5 upstreams and 200 kbps each, or is it no tight relation?
We do that now, though our numbers are lower :-)
Supposedly FTTH-rich countries contribute much more to P2P networks because they have a symmetrical connection and are more attractive to the P2P clients.
And how much does being in the same AS help compare to being geographically or hopwise apart?
That we don't yet know for sure. I've been reading a lot of research on it, and doing some experimentation, but there is a high degree of correlation between intra-AS routing and lower latency and greater capacity. Certainly a better correlation than geographic proximity. Using AS proximity is definitely a help for resilience though, same-AS sources and adjacent AS sources are more likely to remain reachable in the event of transit problems, general BGP flaps and so on. -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net