Re: What Does Ravi Think?

[ravi <gadfly@xxxxxxxxxxxx>]

Michael Perelman wrote:
> This is up Ravi's alley.
>
> On Thu, Mar 07, 2002 at 01:54:47PM +0900, Charles Jannuzi wrote:
>
>> The internet might have been the darpa-net, but few people know
>> what darpa really is. It, along with In-Q-Tel, is a way the US
>> gov't funds 'innovation'. Where innovators band, the vultures
>> flock. So it's nice to see things like Carlyle Group can bring the
>> world of VC to darpa projects:
>>
>> http://www.vividon.com/company/
>>
>> Vividon is laser-focused on a single goal. That goal is to
>> economically resolve the challenges of delivering high quality
>> streaming media on the Internet. The company is the leader in
>> creating a new class of Internet infrastructure product -
>> streamers - that specifically address the unique needs and
>> requirements of delivering streaming media. Designed for content
delivery
>> networks, network service providers, ISP's and corporations, these
>> groundbreaking systems radically improve the economics of
>> delivering streaming media. Headquartered in Sudbury, MA, Vividon
>> was founded by MIT Ph.D. candidates who foresaw the commercial
>> potential for their revolutionary DARPA-funded operating systems
>> research.
>


i am not sure where charles is going with this post: most VCs do flock
to projects that have been proven elsewhere using somebody else's money
;-). akamai, one of the biggest players in the content-distribution
space (that vividon is in) came out of MIT/CMU. yahoo came out of
stanford. netscape out of NCSA at uiuc. and so on...

talking about vividon, building a network appliance optimized for
streaming, is getting close to a commodity business now. if i remember
right their product is a tuned-up and trimmed-down linux kernel based
server. there are a bunch of folks who compete with this product:
midstream (http://www.midstream.com/), volera, a division of nortel,
network appliance (http://www.netapp.com/), others. each offers some
benefits over the other. netapp has the advantage of not only yahoo
broadcast (yahoo's $6 billion dollar purchase of broadcast.com, the
leading streaming service) as a customer, but also a strong revenue
stream from their core services of protocol independent dedicated
network file servers.

streaming is about delivering audio/video, both live and on-demand, to
end users much as web pages are served out by servers over the internet
to you, today.

the problems with streaming are many:

storage/bandwidth: an audio/video file takes a huge amount (as much as ~
225MB for a one-hour close to VHS quality video, with maximum
compression, or roughly the equivalent of transferring a graphical web
page a second) of space and therefore uses a lot of network bandwidth to
get from the server to you. brute force solutions, such as akamai's,
attempt to overcome the network bandwidth problem by avoiding the
internet. they attempt to serve the content to you from "edge servers"
(such as vividon's server) located close to you (say at the POP into
which you dial-in). this doesnt help much since: a) most folks are on
dial-up and thats about 30Kbps, which doesnt support anything close to
the 500Kbps needed for VHS quality video! b) its too expensive to deploy
edge servers at POPs. so they are deployed in regional networks, but
regional networks are exactly where the bandwidth restrictions are, so
avoiding the backbones isnt a big win c) managing this large-scale
distributed environment, including distributing the content to
edge-servers, can be quite a nightmare. e) the pricing model just doesnt
match up to the conventional means of distributing content (TV: cable,
satellite, etc).

network congestion: unlike web pages, streaming content has to be
delivered at a steady rate (since it has to be played out in real time),
and the internet (IP protocols) are just not designed for that. again,
the edge server approach is a brute force solution to this problem.

computing: as vividon rightly claims, serving streaming content is much
more CPU intensive than serving web pages and optimized servers can help
significantly in lowering these costs (a simple PC can serve thousands
of web pages, but can at best handle less than 100 broadband streams). i
am not aware of any particular breakthrough that vividon has arrived at,
however, in this space, beyond the usual practices of optimization for
wire-speed network usage, minimized computing at server end, DMA based
disk and network access (alteon if i remember right had a great gigabit
DMA network card), etc etc.

innovation in this space is somewhat stifled by the fact that the two
leading streaming software providers, real and microsoft, do not
entirely use internet standards, but attempt to create customer lock-in
using proprietary protocols.

the problems of streaming are not something new and have been addressed
by the IETF through various efforts, in particular the concept of
"multicasting" implemented in the research multicast backbone or the
MBONE. multicasting is applicable only to live and scheduled serving of
content (not to pure on-demand access), since it takes advantage of the
fact that the same content is being distributed to multiple folks, who
might share a network path. in the unicast model, a separate copy of the
content is sent to each end user, thus multiplying network usage
linearly with number of users. instead, with multicasting, only one copy
of data ("packets" - remember, information is sent on the internet as
discrete packets) is sent on shared paths. when paths diverge, the
router at that point is required to multiply the data to the necessary
number of copies.

the problems with multicasting are that: it is useless for truly
on-demand content (if we watch the same content, but at different times,
it doesnt help that we share a network path), but also because of the
fact that multicasting requires intermediate routers to co-operate (as
detailed above), which is a political issue since ISPs do not see how to
profit from enabling multicast on their routers (solutions such as
"splitting", provided by realnetworks, somewhat overcome this problem,
by imposing a virtual multicast network over the unicast internet, much
as the old MBONE did).

despite these flaws, multicasting is a powerful and appropriate
solution, and layered encoding and multicasting schemes, such as those
envisioned by jennifer rexford at at&t research, can solve a large set
of the problems of streaming.

http://www.research.att.com/~jrex/

another IETF effort to address the issue of network bandwidth, which at
times betrays the out-of-touch with reality of bureacratic
organizations, is bandwidth reservation, in particular protocols like
RSVP (resource reservation protocol) that attempt to reserve the
bandwidth needed (in terms of rate, acceptable delay, etc) from one
end-point to the other. this heavyweight solution requires not only that
the bandwidth is available to be reserved, but that each node along the
way participate in guaranteeing that reservation. other efforts such as
flow-based or labelled switching, service level based switching/routing,
take more pragmatic approaches to privileging flows (while decreasing
the egalitarian nature of the internet).

returning to streaming as it exists today, the space to watch, at least
for technological excitement, is not so much optimized streaming servers
or brute-force edge serving solutions, but the advances in audio/video
codecs that enable much greater levels of compression, use of notions
similar to multicasting to decrease bandwidth usage, and more
interesting approaches to error correction and loss tolerance.

in the last space, a very interesting product/company is digital
fountain: http://www.digitalfountain.com/, see their futuristic
technology papers, reminiscent of holographic encoding schemes and such, at:

http://www.digitalfountain.com/technology/index.htm
http://www.digitalfountain.com/technology/coreTechnology.htm

> Digital Fountain?s technology for data distribution is fundamentally
> different from that of a conventional server. The architecture
> consists of a Digital Fountain server (called a Fountain Server in
> the following), and Digital Fountain client software (called a
> Fountain Client). The key to the architecture?s reliability, high
> performance and scalability is the patented concept of
> Meta-Content?. For each piece of content, the server generates a
potentially
> limitless stream of Meta-Content, which consists of mathematical
> metaphors that describe the original content. Meta-Content has the
> following fundamental properties: ?Meta-Content packets are
> independently generated from content at any specified rate?from
> kilobits per second to megabits per second. ?A bit-for-bit accurate
> copy of the original content is quickly recovered from any received
> portion of Meta-Content that in aggregate is equal to the length of
> the original content. From the second fundamental property, packets
> containing independently generated Meta-Content are completely
> interchangeable. It does not matter which Meta-Content the Fountain
> Client receives and in what order. Only the quantity of
> independently generated Meta-Content received determines when the
> original content can be reconstructed. Thus, if packets containing
> Meta-Content are lost in transit, any equal amount of Meta-Content
> contained in subsequently received packets is just as useful for
> reconstructing the original content.


i guess this post sort of got longer than i expected!

	--ravi