The Great Internet Deadlock Abhay Parekh. The Decade of Networking Trillions of dollars spent on infrastructure The world changed The scalability of the.

The Great Internet DeadlockThe Great Internet Deadlock

Abhay Parekh

The Decade of NetworkingThe Decade of Networking

Trillions of dollars spent on infrastructure The world changed The scalability of the internet enabled all of this

How did the architecture evolve? More importantly, how did it not evolve? What are the consequences?

The Network in 1998: Content Provider FrustrationThe Network in 1998: Content Provider Frustration

Huge potential of the Internet Delivery obvious World Wide Wait Cloud confusion: no one to ensure end-to-end performance

Conflicting service provider incentives: uneasy equilibrium New functions like multicast had limited traction Streaming audio and video exploding but no support within the

network (Broadcast.com, RealNetworks) Industry held view of the problem:

Application waits for Infrastructure

Infrastructure waits for Application

Router Lock-outRouter Lock-out

Integrating new functions into routers was hard Adding a feature required vendor buy-in Vendor buy-in required service provider buy-in Service provider buy-in required general availability

Federated nature of service providers made things even more difficult

How to satisfy content provider needs with this situation? Prevalent solution in the networking industry: build more

capacity into the network and build faster routers

Edge Networks at Colocation SitesEdge Networks at Colocation Sites

Networking products that could bypass the router by hijacking the addressing infrastructure Caches Firewalls Load Balancers

Level 4 switches

Work better in slow, unreliable networks In-network devices Stacked choke points

Content NetworkingContent Networking

Offer a service to content owners over the existing network based on application performance

Change the currency of the internet service from bits to information

Use co-location facilities at different svc providers to deploy an overlay network that overcomes cloud confusion

Enable new business applications to be deployed over the internet quickly by using the overlay network

Higher Performance allows allow media and other services

Content Internet Value ChainContent Internet Value Chain

Content Producer

Content Distribution

Network

Internet Service Provider

Consumer

$$

$$

$$

Content Producer

Media Clients

The Media Internet: 1999The Media Internet: 1999

Content Distribution Network

FastForward Networks Mission FastForward Networks Mission

To convert the Internet into the “next generation” broadcasting medium, allowing service providers and content distributors to broadcast hundreds of thousands of channels to millions of simultaneous

viewers

Why the Internet for Broadcast?Why the Internet for Broadcast?

Broadcast Today Small number of players control broadcasting Limited by geographical boundaries

Internet

Why the Internet for Broadcast?Why the Internet for Broadcast?

Anyone can be a broadcaster No geographical boundaries

Why the Internet for Broadcast?Why the Internet for Broadcast?

Audience Tracking and Management It’s not just radios and TVs!

Content Producer

Media Clients

The Evolving Broadcast InternetThe Evolving Broadcast Internet

Media Distribution Media Distribution NetworkNetwork

Content Producer

CDN

The Broadcast InternetThe Broadcast Internet

Content Producer

Content Producer

Man

agem

ent

Pla

tfo

rm

redirection management

load balancingsystem availability

network management

monitoring & provisioning

server management

viewer management

subscriptions, PPV,monitoring, Neilson ratings, targeted advertising

content management

injection & real-time control

Redirection

Media DeliverySystem

Broadcast Overlay ArchitectureBroadcast Overlay Architecture

Broadcast ManagementBroadcast Management

Scales to millions Application-level

information for management and tracking

Works across multiple networks

Content Producer event programming with ad-hoc query audience statistics

Broadcast Manager Broadcast Manager

Node Information

Stream Switchover

Policy ManagementPolicy Management

What happened: 1998-2000?What happened: 1998-2000?

Thousands of Content Providers signed up with CDNs

Even mainstream content producers got excited about internet broadcasting

Our stuff worked We did huge broadcasts e.g. Big Brother We improved lossy links and rerouted a lot of video We had Digital Island peering with AOL We made a multi-million dollar sale We merged with Inktomi for about $1.3B

What happened: 2000-2002?What happened: 2000-2002?

Most content distribution networks went bankrupt Those left are busy suing each other

The major caching companies were unable to build businesses

FastForward Products retargeted to the enterprise Many High speed access companies went bankrupt Streaming is still prevalent but has not taken off the

way we expected it to.

What went wrong?What went wrong?

Overlay Networks didn’t work as well as advertised in improving performance Always at the mercy of underlying facilities (bad links) Too Expensive to build a ubiquitous network Local caches are cheap and available Overlay Networks that did not depend on network

performance did fine Underlying access network not engineered to fulfill the Content

Networking vision DSL Access fraught with problems Cable Companies not interested in participating

Bottom Line: Can’t solve QoS problems just with Overlays!! Corollary: Can’t build the Broadcast Internet without quality

enhancing mechanisms in the network

Why is there no Network QoS?Why is there no Network QoS?

Since bandwidth is undifferentiated and is priced per bit: Vendors produce boxes for undifferentiated service

Focus on raw throughput not packet handling Boxes work to reduce the cost of transporting a bit

No reason to take QoS features seriously Standards efforts don’t take hold

Networks are engineered for better “web surfing” This applies to multicast as well…

When presented with a genuine revenue opportunity for a high speed/quality sensitive application: No way to deliver No way to peer: Content Peering is vague and QoS-based

Peering is not possible without network QoS mechanisms No way to charge: E.g.. either video is too expensive or

everything else is free Exercise one or more of the following objections:

“No Business Model” “QoS is harmful” “No congestion problem”– current quality is fine “QoS work is just incomprehensible research”

Why is there no Network QoS?Why is there no Network QoS?

Internet Infrastructure providesundifferentiated service

More capacity is thrown at the undifferentiated network, and emphasis continues on “speeding up the internet”, but this just speeds up existing applications

No future for internet media or other bandwidth intensive applications

No future for significant high speed access penetration These are huge lost opportunities!!

The Great Internet DeadlockThe Great Internet Deadlock

No BusinessModel Cop-out No way to charge, peer or deliver

high speed/quality sensitive applications

What to do?Rethink the nature of QoSWhat to do?Rethink the nature of QoS

Don’t try to come up with a “complete” definition of QoS Sometimes generality dilutes relevance Also causes confusion

Justify the extra mechanisms on the basis of tangible improved performance A “Best Effort” approach to QoS may not be effective Must involve routing

Spell out the tough choices: Carry voice and video as clearly differentiated session types

Would make peering easier Maybe this violates end-to-end arguments

Odlyzko: Have two networks one more expensive than the other. Add more mechanisms to the expensive one over time

What to do?Demonstrate feasibilityWhat to do?Demonstrate feasibility

Simulation and theory aren’t enough Need a software platform that enables a “test network” to be

built and an integrated voice/video network deployed Must not be unrelated to the routing infrastructure Must not try too hard to fit in seamlessly

Router vendors will only adopt once the demonstration is convincing

Applications will not be the bottleneck! Don’t worry too much about hardware scalability Don’t worry too much about “market timing”

User Heterogeneity- Secure and Robust - Application Heterogeneity

Work AheadWork Ahead

Can we really build an integrated services network which can support audio, video and multicast levels comparable to the alternatives? How adversely do new, in-the-network application level

gateways impact our ability to do this? How about non-responsive flows?

How do we tackle the problems of peering and pricing? These problems are hard and a “Re-thinking of The

Fundamentals” approach might work best Isolate the quality sensitive traffic to the largest possible

extent The greatest and most exciting phase of the internet will

begin when audio and video are a true part of it.