If this application takes off, I have to presume that everyone's baseline network usage metrics can be tossed out the window...
Thomas
Interesting. Why does it send so much data? Is it a peer to peer type of system where it redistributes a portion of the stream as you are viewing it to other users?
R
Tellurian Networks - Global Hosting Solutions Since 1995
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin
Howdy,
>If this application takes off, I have to presume that everyone's
>baseline network usage metrics can be tossed out the window...Interesting. Why does it send so much data? Is it a peer to peer type
of system where it redistributes a portion of the stream as you are
viewing it to other users?
"The Venice Project is the new system being developed by Janus Friis
and Niklas Zennstr?m, the Scandinavian entrepreneurs behind the
revolutionary services Kazaa and Skype."
That's probably a safe assumption. 
Cheers,
Trent
There’s also Democracy - http://www.getdemocracy.org
Open source TV-over-IP suite including edit tools, server, and client. For these purposes, more interesting is that the transport layer is BitTorrent, so yup, if you’re receiving you’re also sending.
Hello;
If this application takes off, I have to presume that everyone's baseline network usage metrics can be tossed out the window...
Thomas
You should probably do that anyway, if you are worried about Venice, because Venice is just a video service.
320 megabytes (MB) / hour is 711 Kbps, which is comparable to pretty much any high quality video streaming
service. My AmericaFree.TV streaming service offers right now, for example, 500 Kbps and 250 Kbps simulcast video
streaming, with trials of 1 Mbps HD, and users consistently pick the higher bit rate by a 3:1 to 4:1 margin.
(See http://www.americafree.tv/audience/QTSS_statistics.video1.total.png for an example of how stable this user choice is.)
P2P is a bandwidth sharing mechanism, not a audience generation mechanism. As streaming video takes off, it will
use more or less the same amounts of bandwidth, P2P or no, as long as the underlying transport is unicast, not multicast, because the bandwidth usage is ultimately determined by the audience. (At least we offer multicast simulcasts. If you don't like our bandwidth usage, enable multicast.)
Regards
Marshall
>If this application takes off, I have to presume that everyone's
>baseline network usage metrics can be tossed out the window...
That's a strong possibility
I'm currently the network person for The Venice Project, and busy
building out our network, but also involved in the design and planning
work and a bunch of other things.
I'll try and answer any questions I can, I may be a little restricted in
revealing details of forthcoming developments and so on, so please
forgive me if there's later something I can't answer, but for now I'll
try and answer any of the technicalities. Our philosophy is to pretty
open about how we work and what we do.
We're actually working on more general purpose explanations of all this,
which we'll be putting on-line soon. I'm not from our PR dept, or a
spokesperson, just a long-time NANOG reader and ocasional poster
answering technical stuff here, so please don't just post the archive
link to digg/slashdot or whatever.
The Venice Project will affect network operators and we're working on a
range of different things which may help out there. We've designed our
traffic to be easily categorisable (I wish we could mark a DSCP, but the
levels of access needed on some platforms are just too restrictive) and
we know how the real internet works. Already we have aggregate per-AS
usage statistics, and have some primitive network proximity clustering.
AS-level clustering is planned.
This will reduce transit costs, but there's not much we can do for other
infrastructural, L2 or last-mile costs. We're L3 and above only.
Additionally, we predict a healthy chunk of usage will go to our "Long
tail servers", which are explained a bit here;
vipeers.com - Diese Website steht zum Verkauf! - Informationen zum Thema vipeers.
and in the next 6 months or so, we hope to turn up at IX's and arrange
private peerings to defray the transit cost of that traffic too.
Right now, our main transit provider is BT (AS5400) who are at some
well-known IX's.
Interesting. Why does it send so much data?
It's full-screen TV-quality video After adding all the overhead for
p2p protocol and stream resilience we still only use a maximum of 320MB
per viewing hour.
The more popular the content is, the more sources it can be pulled from
and the less redundant data we send, and that number can be as low as
220MB per hour viewed. (Actually, I find this a tough thing to explain
to people in general; it's really counterintuitive to see that more
peers == less bandwidth - I'm still searching for a useful user-facing
metaphor, anyone got any ideas?).
To put that in context; a 45 minute episode grabbed from a file-sharing
network will generally eat 350MB on-disk, obviously slightly more is
used after you account for even the 2% TCP/IP overhead and p2p protocol
headers. And it will usually take longer than 45 minutes to get there.
Compressed digital telivision works out at between 900MB and 3GB an hour
viewed (raw is in the tens of gigabytes). DVD is of the same order.
YouTube works out at about 80MB to 230MB per-hour, for a mini-screen
(though I'm open to correction on that, I've just multiplied the
bitrates out).
Is it a peer to peer type of system where it redistributes a portion
of the stream as you are viewing it to other users?
Yes, though not neccessarily as you are viewing it. A proportion of what
you have viewed previously is cached and can be made available to other
peers.
Note that 220 MB per hour (ugly units) is 489 Kbps, slightly less than our current usage.
The more popular the content is, the more sources it can be pulled from
and the less redundant data we send, and that number can be as low as
220MB per hour viewed. (Actually, I find this a tough thing to explain
to people in general; it's really counterintuitive to see that more
peers == less bandwidth - I'm still searching for a useful user-facing
metaphor, anyone got any ideas?).
Why not just say, the more peers, the more efficient it becomes as it approaches the
bandwidth floor set by the chosen streaming ?
Regards
Marshall
Oh I should be clear too. We use SI powers of 10, just like for
bandwidth, not powers of two like for storage. We quote in Megabytes
because caps are usually in gigabytes, so it's more clear for users.
Note that 220 MB per hour (ugly units) is 489 Kbps, slightly less
than our current usage.Oh I should be clear too. We use SI powers of 10, just like for
bandwidth, not powers of two like for storage.
A man after my own heart...
This is a really weird service. It sends out semi-live streams (as opposed to downloads) but it can be cached and made available later, it's also peer-to-peer but needs a massive network or at least massive amounts of peering.
With Bittorrent, it's typical for people to download faster than they upload, and then continue to upload for some time after they've finished downloading. This works very well as long as not everyone starts downloading at the same time. However, for something with time constraints this doesn't work so well. Either you're limited by the maximum up speed, which generally isn't enough to support decent video, or the peer-to-peer aspect can only take care of part of the required total upload capacity so there must be additional servers to take care of the rest.
I'm guessing the latter is the case here, and this new service works much the same way as Skype in the sense that it will plunder people's upload capacity for the benefit of the people running the network, rather than being a real peer-to-peer service.
ISPs should of course welcome this, because when people start craving their daily 2 GB fix you got them exactly where you want them, especially in markets with little or no broadband competition.
Colm:
What does the Venice project see in terms of the number of upstreams
required to feed one view, and how much does the size of upstream pipe
affect this all? 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? 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?
Regards,
Frank
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.
Dear Colm;
What does the Venice project see in terms of the number of upstreams
required to feed one view,
<snip>
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.
As is frequently pointed out, here and elsewhere, network topology != geography.
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.
Do you actually inject any BGP information into Venice ? How do you determine otherwise
that two nodes are in the same AS (do you, for example, assume that if they are in the same /24
then they are close in network topology) ?
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Regards
Marshall
yes and no, there is topology information there, but it's based on
snapshots. Dyanamic is the next step.
You know, when it’s all said and done, streaming video may be the motivator for migrating the large scale Internet to IPv6. I do not see unicast streaming as a long term solution for video service. In the short term, unicast streaming and PushVoD models may prevail, but the ultimate solution is Internet-wide multicasting.
I want my m6bone. 
Gian Anthony Constantine
Senior Network Design Engineer
Earthlink, Inc.
Dear Gian;
You know, when it's all said and done, streaming video may be the motivator for migrating the large scale Internet to IPv6. I do not see unicast streaming as a long term solution for video service. In the short term, unicast streaming and PushVoD models may prevail, but the ultimate solution is Internet-wide multicasting.
I want my m6bone.
Well, help make it possible. Join the MboneD WG list. Help us recharter. Come to Prague, even, if you can.
BTW, have you taken the multicast survey :
http://www.multicasttech.com/survey/MBoneD_Survey_v_1_5.txt
http://www.multicasttech.com/survey/MBoneD_Survey_v_1_5.pdf ?
Regards
Marshall
Colm, a few random questions as they came to mind: [;>]
Will your downloads be encrypted/obfuscated? Will your application be port-agile? Is it HTTP, or Something Else?
If it's not encrypted, will you be cache-friendly?
Will you be supporting/enforcing some form of DRM?
Will you be multi-platform? If so, which ones?
When you say 'TV', do you mean HDTV? If so, 1080i/1080p?
Will you have Skype-like 'supernode' functionality? If so, will it be user-configurable?
Will you insert ads into the content? If so, will you offer a revenue-sharing model for SPs who wish to participate?
Many thanks!
Two more questions:
Do you plan to offer the Venice Project for mobile devices? If so, which ones?
Will you support offline storage/playback?
Thanks again!
Now comes the "please forgive me" part, but most of your questions arn't
relevant to the NANOG charter, so you're going to have to mail our PR
dept for answers (see: http://www.theveniceproject.com/contact.html).
Answers to nearly all of them will be online soon anyway on our website,
we're not trying to hide anything, but this isn't the place
I'll try to answer the questions which are relevant to Network
Operations, and I have not already answered, anyway;
We use a very small set of ports, currently;
TCP ports 80 and 443 - for various http requests
TCP/UDP port 33333 - for p2p control traffic and
streaming
TCP port port 5223 - for our jabber-powered
channel-chat.
UDP port 10000 - for error reporting and
usage tracking. This port
is short term.
Port 33333 is not fixed, and we should be making an IANA
request soonish and then we'll change it, but again to
just one port. So I guess we're not port-agile
We use HTTP(s) requests for making content searches,
fetching thumbnails and so on. Right now, these
requests are not cacheable, but are pretty small.
Every peer is a cache, so in that sense we are cache friendly,
but our protocol is not cacheable/proxyable by a man in the
middle.
I believe that's open to interpretation - for example, the question about mobile devices is relevant to mobile SPs, the question about offline viewing has an impact on perceived network usage patterns, the 'supernode' questions same, the TV vs. HDTV question, same (size/length), the DRM question same (help desk/supportability), platforms same (help desk/supportability). The ad question is is actually out-of-charter, though I suspect of great interest to many of the list subscribers
Now, if you don't *want* to answer the above questions, that's perfectly fine; but they're certainly within the list charter, and entirely relevant to network operations, heh.