As
part of the IT Architecture Initiative, the Office of Information Technologies
(OIT) is producing a series of papers outlining directions in information
technology architecture.
In the
spirit of RFCs, the papers are intended to facilitate understanding
of and open dialogue about information technology trends at Cornell,
with the ultimate goal of improving the utilization and interoperability
of information technology services throughout Cornell.
pdf version
Video Distribution
and Network Evolution at Cornell
Prepared by R.
David Vernon
SYNOPSIS
Support
for widespread video distribution is a critical design goal of the data
network service strategy at Cornell. This paper briefly outlines the following
issues related to video distribution:
•
Evolution
of video support networks at Cornell.
•
Three types
of video services required by Cornell.
•Recommended
temporary transition strategies.
•
Final
IP-based data network design issues and directions.
•
Practical
implications.
Evolution
of Video Support Networks (1980’s– Future)
The video
support network at Cornell has undergone an evolution since its original
installation in the 1980’s. As needs and technology have changed,
the network has shifted from the original analog coaxial-based broadband
to the current video fiber network. We are currently looking to the
next stage, an IP-based video network.
From mid-split
broadband to the Video Fiber Network (VFN)
In the
early 1980’s Cornell installed an analog broadband system (a mid-
and sub-split 300Mh coax analog broadband system) to distribute video
services to approximately 35 locations on campus. Aging hardware, the
need to recover conduit space, and a limited technology growth path
led to the decision to retire this system in late 1999. At that time
Cornell Information Technologies (CIT) started a limited deployment
of point-to-point fiber-based video services, now called the Video Fiber
Network (VFN), as a bridge technology to provide services until a unified
data network strategy could be realized.
From VFN
to an IP-based Data Network
While
the VFN provides very high quality video, it is not economical or technologically
viable for the long-term. The cons include limited fiber and conduit
space, limits on the number of supported locations, and the high cost
of configuring esoteric hardware. Video support at Cornell will be best
served by engineering the data network to be a widespread, high quality,
and cost-effective resource to support Cornell’s video service
needs.
The transmission
of video over the IP data network is technically achievable today. However,
the transition from the VFN to an IP-based network requires review and
understanding of the trade-off’s of cost, access, and video quality.
The basic differences are:
- The
VFN, based on dedicated, point-to-point fiber links attached to coding
and decoding software (codecs) provides very high quality video, but
at high cost per transmission and to a limited number of campus locations
and therefore a limited number of patrons.
- IP-based
video services can be scaled to meet the needs of tens of thousands
of Cornell patrons, at lower costs, but initial quality of service
may fail to meet the demands of select transmission requirements.
At this
time it is the belief of the Office of the Vice President of Information
Technology (OIT) that the quality and value of video services achievable
over an IP-based system will meet the vast majority of our patron needs.
Furthermore we believe that investment in the VFN should be minimized
and maintained for only as long its premium video quality is clearly
worth the higher cost to the patron base when compared to ever improving
quality of IP-based video services.
Cornell
Video Service Requirements
- The
IP-based video network solution will have to address three types of
video service needs:
- Video
on demand services based on Unicast.
- One
to many video broadcast services based on Multicast.
- Video
conferencing.
The following
three sections further define these needs.
Unicast
Streaming
For the
purpose of this document, unicast streaming is defined as a single-direction
point-to-point transmission of encoded video that often leverages client
buffering or distributed network caches to improve video display quality.
Caching
a percentage of the video on the local client or network before playing
is a simple and effective way of working around bandwidth limitations
of local, campus, and wide-area data networks. In unicast streaming,
the video is being sent in only one direction so the time delay a buffer
or cache creates does not negatively affect the quality of the service.
However,
using unicast streaming for "broadcast events" has drawbacks.
(A broadcast event is one that is sent to many destinations at the same
time, as opposed to a single destination.) The main issues are:
- Network
use: Unicast streaming requires a dedicated flow of information for
each session. If there are 1,000 people viewing the same video at
the same time, there will need to be one thousand unicasts active.
Each stream would consume some percentage of the available IP data
network.
- License
cost: Many popular commercial streaming servers are licensed based
on the quantity of concurrent unicasts supported. This raises the
total cost of service.
It is
also important to emphasize that caching is not an acceptable tool for
video conferencing, because a "conference" requires real-time
interactive communications. Caching interrupts the interaction.
Despite
these limitations, unicast streaming, enabled with familiar applications
such as Apple’s QuickTime Player, Windows Media Player and RealNetworks,
remains the most widely adopted IP video distribution tool at Cornell
and throughout the world.
Multicast
Multicast
is not a system of video encoding, such as MPEG
or H.261
or a transport protocol such as RTP
but a strategy for engineering an IP data network that efficiently distributes
encoded video. Multicast enabled networks replicate single video streams
to multiple destination clients based on defined router rules. While
unicast streaming works well for one-on-one video services, multicast
enabled networks can broadcast video to one or more destination
clients while minimizing network impact and cost.
Today
limited multicast sessions are used in campus networks throughout the
world, while advanced service development and campus to campus multicast
transmission via support from Internet service providers is still under
active testing and development.
Video
Conferencing
Video
conferencing is the combination of audio, video, and digital communications
technology that enables live, real-time interaction between two or more
locations. Unlike video on demand or video broadcasts, which are usually
used for one-way transmissions, the primary use for video conferencing
is two-way, site-to-site communication.
The nature
of a video conference -- fairly static participants requiring mid-level
image quality -- allows for efficient encoding requiring far less bandwidth
than most high quality video broadcasts. However, video conferencing
places unique quality demands on the network as the perceived worth
of an interactive conference can degrade quickly if network latency
exceeds that which is naturally tolerated by the participants. This
level of service quality is not now achievable with Cornell’s installed
data network despite the moderate bandwidth demands of video conferencing
applications.
Currently
Cornell’s ad hoc packet-based video conferencing strategy is based
on the H.323
standard which is a suite of video/audio codecs and system control protocol
standards for video conferencing. While H.323 does have provisions to
support multicasts, standard implementations require one unicast for
each participant. Multiple participants are linked via additional bridging
hardware and software and a Multipoint Control Unit or MCU. Implementation
of H.323 video conferencing can be achieved with a growing list of software
for desktop computers or via turnkey standalone units, such as those
provided by Polycom Corporation.
Network
Design Issues and Directions
The necessity
to retool the data network infrastructure at Cornell will be driven
by the need to guarantee assured quality links for video conferencing
services and by one to many "multicasts" of high-resolution
real-time video broadcasts. The current network cannot accommodate the
different needs of these two classes of video services. While there
are quality issues for unicast, they alone may not dictate a network
strategy change because the limitations in the current network can be
addressed by the use of local host buffers or distributed network caches.
Additionally, unicast is primarily focused on streaming a stored video
asset to a single recipient, and therefore does not benefit from a multicast
enabled network.
However,
for all three classes of video service, high quality, full motion video
demands much greater network bandwidth than low quality static video.
The data network at Cornell today will not support the total suite of
packet video services outlined. The network falls short in three critical
areas:
- Capacity
- Support
for multicast
- Predictable
quality of service
The best
approach to retooling the network to support video at Cornell will be
defined by:
- Available
funding
- Primary
limitations of the installed wire plant
- Good
network design
Cornell
is currently hobbled by its installed "category 3" building
data wire that limits the maximum data rates to end clients and servers
to dedicated 10-MB connections. 10 MB switched Ethernet, if ubiquitously
deployed, is arguably adequate for the video services outlined above,
but with little additional capacity to support other concurrent demands
on network bandwidth. *
[*10-MB
data link limitations will be problematic for router to switch, switch
to switch, server and multitasking clients supporting concurrent video.]
While pilot
programs are exploring the total cost of rewiring the campus, any strategy
that addresses video service demands within a network supporting a myriad
of concurrent applications, is not likely to succeed based on simple
over-provisioning of data links. By implementing best practice strategies
of engineering data networks to support multicast and "quality
of service" the bandwidth that Cornell can deliver can be optimized
for video support as well. Furthermore, such strategies remain valuable
regardless of the base rates achievable on a new cable plant and are
important tools for future services such as Voice over IP.
More on
Quality of Service
Quality
of service (QoS) is a networking term that specifies a guaranteed throughput
level. It is generally used for systems that can be engineered into
a data network to allow the prioritization of data transmissions. End
to End QoS (e2eQoS) is rubric used for network services that allow prioritized
transmissions across the larger enterprise. Like multicast, QoS refers
not to the video data transmitted, but to a data network design criteria,
in this case to enable predictable video delivery quality.
QoS enabled
network systems can be programmed to allow guaranteed service to specific
applications over a network, which helps assure presentation quality.
This is important because video conferencing and voice services (even
at low bandwidth) are particularly vulnerable to compromised quality
due to congested networks. (Congested networks can create latency or
a lag in the amount of time it takes a packet to travel from source
to destination. This is obviously detrimental to the interactive aspect
of a video conference.)
Strategies
for implementing QoS might include:
- Over
provisioning. For example, installing hardware that has the ability
to handle projected peak demands without degradation of service to
any concurrent user.
- Static
hardware configurations that prioritize aggregate data streams based
on a classification schema. For example, video data is given preference
over e-mail data in all cases. Or, data from a specified list of hardware
always get preferential treatment over other transmitting hardware.
- Dynamic
QoS negation. For example, a process that allows any qualified user,
using any application, to reserve a specified level of bandwidth for
a specific period and duration.
While
over provisioning and static hardware configuration strategies are relatively
simple in concept and deployment, dynamic provisioning of QoS services
requires a rather complex coordination of broader resources. Dynamic
resource reservation implies the real-time exchange and auditing of
relevant policy, security, user, hardware and billing configuration
information, via a suite of developing protocols to all active components
of the campus network infrastructure. Although dynamic provisioning
of assured quality links promises an efficient use of installed hardware,
the complexity of this system implies increased cost and management
overhead.
[Among
other information resources see: http://www.ietf.org/html.charters/rsvp-charter.html,
http://www.ietf.org/html.charters/rap-charter.html,
http://www.ietf.org/html.charters/intserv-charter.html
...]
The implementation
of QoS at Cornell will not be a trivial exercise. An initial easy to
implement strategy combining simple over-provisioning of edge hardware
with aggregate IP stream prioritization tools in core, may progress
over time to a complex system guaranteeing end-to-end service levels
via dynamic QoS negotiation protocols developed with an eye on national
trends. [Among other information resources see: http://www.ietf.org/html.charters/diffserv-charter.html...]
The value at any point in time of a given QoS strategy is affirmed by
reviewing the cost vs. the utility achieved by maintaining a relatively
simple vs. complex QoS network architecture. As there is sure to be
a growing base of demand driven by new QoS aware applications, long-term
success will require the monitoring of demand to allow ample lead-time
for network re-engineering to extend or enable more sophisticated tools.
Possibly
more challenging than building initial QoS enabled networks will be
the resolution of the policy implications implied. Dynamic brokering
of "who" is allowed to encumber a given percentage of the
network infrastructure, in a fashion that campus and national partners
"trust," will require a common and well understood strategy
for bandwidth allocation and cost recovery. In addition, a QoS enabled
network must be seen as a primary "client" of Cornell’s
central directory services, as campus LDAP
servers will be the likely archive of policy information.
As the
diligent implementation of QoS and multicast strategies evolve into
base-line network functions that the Cornell campus will leverage for
video and other data distribution, exploration of enhanced data caching
strategies must also be explored. The cost of transmitting massive amounts
of high-quality video at guaranteed quality levels might be placated
to some degree through preemptive distribution, or caching of video
for unicast applications, in close network proximity to the viewing
client. Distributed File Systems, or cache integration into network
hardware may afford equivalent, or superior unicast service quality
than a system dependent only on QoS and multicast. The economies of
network caching approaches to data distribution are well demonstrated
by Internet caching providers, such as Akamai
or IBeam.
Practical
Considerations
Departments
and individuals with the need to transmit video should be cognizant
of the evolving Cornell data network potential. Until the data network
is retooled, video transmission quality may not be suitable for specific
applications and /or audiences. Users are encouraged to work with CIT
and local video support resources to experiment with video delivery
via the data network in order to gain an understanding of the limitations
balanced against the alternative, though expensive, VFN video transmission
service.
Clearly,
as the data network evolves a greater percentage of Cornell campus-based
video needs will be met cost effectively. However, it is important for
departments and individuals to realize that Cornell based QoS and Multicast
strategies do not imply equivalent services across the larger Internet.
Transmissions of video to off campus locations will always be subject
to the architecture of the larger Internet community - where the quality
of the connection is only as good as the worst network link.
There
are a number of initiatives, most notably those being driven by Internet2,
(I2) to address the issue of e2eQoS across the wide-area Internet. As
wide-area network e2eQoS participation requirements become clear, Cornell’s
QoS strategy must evolove and be able to take part. The most likely
outcome will be a fairly complex QoS architecture based on real-time
reservation protocols used to dynamically coordinate resources and allocate
costs.
Today
departments may find reasonable video transmission for videoconferencing
and limited quality video broadcast to locations connected to I2 even
without participating in I2 QoS pilots, as I2 is currently uncongested
and uniformly deployed. However, departments will be limited in their
ability to deliver quality video over Cornell’s commodity Internet
connections and will need to explore dedicated ground connections or
satellite services for high quality transmission.
Closing
Thoughts
As it
is the intent of OIT to enable video services outlined in this paper,
we recommend traditional support for VFN services while Cornell targets
and coordinates network investments over an extended period with the
following network design goals:
- Reengineering
the campus data network to support multicast.
- Reengineering
the campus data network to support QoS.
- Policy
dialogue.
- Advanced
Network Video caching tools (when appropriate).
The transmission
of video over the IP data network is technically achievable today. However,
the transition from old models of limited very high quality video transmission,
to one supporting thousands of video transmissions at a quality level
acceptable to the patrons of the service requires prudent investment
and studied review. Paramount among the issues is to forge a common
understanding of cost benefit of initial compromise in the quality of
transmission vs. the maintenance of high cost esoteric systems such
as the VFN. This evolution of video and network services has many challenges
and will require timely funding, proactive communication, and world
class technical expertise to succeed.
Over time
the evolving ability to distribute video over the data network to all
users will be but a part of a growing suite of services that embody
the larger video service strategy at Cornell. This strategy will also
encompass video development for broadcast across the Cornell campus
or the world and maintaining massive repositories for video on demand
assets. Creative support and the development of new and enabling resources
are both required to fulfill the grand vision of ubiquitous, high quality,
digital video delivery at Cornell.
Return
to Papers Page
