Internet2: A Tutorial Part 4 of 4

Internet2: A TutorialPart 4 of 4

17th Brazilian Symposiumon

Computer Networks

Paul Love, Internet2Chair, I2 Topology WG

[email protected]

QoS

Internet2 QBone:Building a Testbed for IP Differentiated Services

with thanks toBen Teitelbaum, Internet2

25-28 May 99SBRC99 Salvador, Bahia, Brazil

Generic Internet2 Topology

NGIXs

CC

GigaPoP

C C

GigaPoP

C C

GigaPoP

C C

Abilene

CC

GigaPoP

C C

GigaPoP

C C

GigaPoP

C C

vBNS

L

C

ESNet, NREN, Int’l, ...

L

C


Internet2 QoS WG Membership

• Osama Aboul-Magd (Nortel/Bay)

• Andy Adamson (Michigan)• Grenville Armitage

(Lucent) • Steve Blake (Torrent)• Scott Bradner (Harvard) • Scott Brim (Newbridge)• Larry Conrad (Florida

State)• John Coulter (CA*net2) • Chuck Song / Laura

Cunningham (MCI/vBNS) • Fred Baker / Larry Dunn

(Cisco)

• Rüdiger Geib (Deutsche Telekom)• Terry Gray (U Washington) • Jim Grisham (NYSERNet)• Roch Guerin (Penn)• Susan Hares (Merit) • Joseph Lappa (CMU)• Jay Kistler (FORE)• Klara Narhsteadt (UIC)• Kathleen Nichols (IETF

coordination) • Ken Pierce (3com) • John Sikora (ATT Labs)• Ben Teitelbaum (chair)• John Wroclawski (MIT)


Requirements Goals

Internet2 QoS Mandate

• Enables applications• Scales• Interoperable (interdomains &

multi-vendor)• Administratable• Measurable• Deployable soon• Works with host OSs and

evolving middleware infrastructure

• Cost effective

• Dynamic, per-flow requests• QoS and CoS• Ability to schedule advanced

reservations• Eventually multicast ;-)


Big Problem #1: Understanding Application Requirements

• What services do tomorrow’s applications need?

• Range of poorly-understood needs• Both intolerant apps (e.g. tele-immersion)

and tolerant apps (e.g. large FTPs, desktop video conferencing)

• Many apps need absolute, per-flow QoS assurances

• Adaptive apps may require a minimum level of QoS, but can exploit additional network resources if available

• Some institutions/users want multiple classes of best-efforts service (CoS) with relative precedence levels

Good

Bad

Intolerant

Better

Tolerant

Adaptive

• Need better understanding through experience

Different App Needs


Big Problem #2: Scalability

• Convergence of flows on the core means:• Large numbers of flows through each router• High forwarding rate requirements

• Need to support QoS end-to-end, but keep per-flow state & packet forwarding overhead out of the core

Lots of

flows here!


Big Problem #3: Interoperability

CampusNetworks

GigaPoPs

GigaPoPs

CampusNetworks

… and between multipleimplementations of network elements ...

Backbone Networks(vBNS, Abilene, …)

... between separately administered and designed clouds ...

… is crucial if we are to provide end-to-end QoS.


DiffServ for Internet2

• July 1997 - February 1998• QoS Working Group struggled to understand

needs of advanced applications• Reaction against RSVP complexity gives rise to

Differentiated Services - a scalable, light-weight framework for QoS

• May 1998• WG recommends DiffServ focus for Internet2

QoS• First Internet2 Joint Applications/Engineering

Workshop, Santa Clara, CA (report on web site)

RSVP

RSVP vs DiffServ

BB BB

•Per-flow service state at every hop•Scalability problems•Focus on multicast

•Abstract/manage each cloud’s resources (BBs) •Packets colored with “behavior”•Focus on aggregates not flows•Policing at edge to get services

DiffServ


DiffServ Overview

• Exploits edge/core distinction for scalability• Applications contract for specific QoS profiles

• Policing at network periphery• A few simple, differentiated per-hop forwarding

behaviors (PHBs) • Indicated in packet header• Applied to PHB traffic aggregates

• PHBs + policing rules = range of services

• Clouds contract for aggregate QoS traffic profiles• Policing at cloud-cloud boundary• Supports simple, bilateral business agreements


Leaf Router (police, mark flows)

Ingress Edge Router (classify, police, mark aggregates)

EgressEdge Router

(shape aggregates)

Corerouters

Corerouters

Bandwidth Brokers(perform admissions control, manage network resources,

configure leaf and edge devices)

BB BB

Source

Destination

DiffServ Architecture


Example Service #1: Premium

• Emulates a leased line• Contract: peak rate profile• PHB = “forward me first”

(e.g. priority queuing, WFQ)• Policing rule = drop out-of-profile

packets• On egress, clouds need to shape

Premium aggregates to mask induced burstiness


Example Service #2: Assured

• Emulates a “lightly-loaded” network• Contract: rate and burst profile• PHB = “drop me last” (e.g. WRED, RIO)• Policing rule = mark out-of-profile packets• Assured traffic shares queue with BE• Drop out-of-profile and BE before in-profile

packets• On cloud egress, clouds may need to shape

Assured aggregates to mask induced burstiness


DiffServ & The Three Big QoS Problems

• Applications: Framework supports a broad range of services depending on PHB and configuration of policers

• Scalability: Simplicity of PHBs & pushing “smarts” towards edge, lets core routers be simple, dumb, and fast, but still support QoS!

• Interoperability: • PHBs suggest but do not imply implementations• QoS through concatenations of simple bilateral

SLSs• Administratability also a big win


Applications

Engineering

Motivate Enables

Internet2 Dogma:There is a circularity between advanced networks and

advanced apps


• Existing stalemate:

• QBone initiative seeks to turn the arrows around and create positive feedback:

Apps QoS

Enables

Motivate

Apps QoS

Inhibited

Prevented

QBone Dogma:Apps Networking circularity applies to QoS especially


The Internet2 QBone Initiative• Build interdomain testbed infrastructure

• Experiment and improve understanding• Incrementally improve testbed

• Support intradomain & interdomain deployment• Lead and follow IETF standards work

• Some parts of DiffServ architecture easy; others far from it• Our experience will inform standards process

• Openness of R&E community gives us an edge• Users will tolerate the flakiness of an experimental infrastructure• Engineers will share experience and measurement data• QBone as “infrastructure that only a graduate student

could love”


QBone Milestones

• Sep 98 - Call for participation • Oct 98 - QFC finalized QIG recommendations• Nov 98 - 1st Meeting of QBone BB Advisory Council• Dec 98 - QBone Networking Kickoff Meeting• Jan 99 - Revised QBone Architecture from

I2QoSWG • Jan 99 - RTP QIG Meeting (+ BB group)• Mar 99 - Las Cruces QIG Meeting (+ BB group)• May 99 - QBone Architecture in last call


QBone from 10km view• QBone Premium Service

• Well-defined SLS:• Parameterized by peak rate R and “service MTU” M implying a

token bucket meter with rate R and depth M• low loss (will quantify with feedback from measurements)• low jitter (delay variation due to queuing effects should be no

greater than the packet transmission time of a service MTU sized packet at the subscribed rate)

• Plus important value-adds:• Integrated measurement/dissemination

infrastructure• Experimentation with a pre-standards inter-domain BB

signaling protocol


Understand Premium

• Valuable even though I2 networks are largely uncongested

• Jitter and periodic loss still occur within I2

• Preparing for the future


Typical Internet2 PerformanceEast Coast University to West Coast DOE Lab

• Minimum Delay• 50th Percentile Delay• 90th Percentile Delay


Example QBone Deployment

• NCNI to Internet2 Washington, DC member meeting


AbileneJune '99

SoX/vBNS

NCSUCentennialJune '99

CiscoRTP

UNCChapel Hill

MCNCRTP

DukeDurham

NCSURaleigh

DS3

OC12c

Oc12c

Packetover

SONET

ATM

smj - 10/5/98

IBMRTP

NortelRTP

LEGEND

OC12c ATMOC48 SONET

OC3c ATM DS3 ATM

SONET ADM

ATM Switch

IP Router

Surveyor

Cisco 2926

OC3mon

North Carolina Networking Initiative(N Carolina gigapop)


NCNI/QBone April 99 Demo: Overview: DC to NC Path

SoX/vBNS

Abilene

UNCChapel Hill

DukeDurham

NCSURaleigh

Packetover

SONET

ATM

ATM

FastEthernetFastEthernet

ATM

Nortel Networks Routerw/ DiffServ/COPS

FastEthernetSwitch

FastEthernetSwitch


Highway-1Washington, D.C.

VideoConferencing

Client

Nanomanipulator Client

NCSUCentennial

ATM

MCNCRTP

ATM

NortelRTP

NanomanipulatorATM

ATM

FastEthernet

TrafficGenerator

Nortel NetworksOptivity Policy Server

COPS



ATM

FastEthernetNortel Networks Router

w/ DiffServ/COPS


Policy/QoS Implementation

MPEG2StereoVideo

VideoConferencing

Client


MPEG2 Stereo VideoLEGEND

Grey -

Blue -

Teal -

Existing Equipment andConnections

Planned Equipment andConnections

Equipment and Connectionsfor Qbone


NCNI/QBone April 99 Demo:Media, IP Switching, and Policy Protocols

RT Stereo Video Source

RT StereoVideo

VideoConferencin

g

SOX / vBNS ATM

BLNASNAccelar 1200

BLN ASNEthernet Switch

ATM/DS-3

ATM/OC3100BT 100BT 100BT 100BT

Optivity Policy Server

Nano-Manipulator

Client

LDAP Server

LDAP

COPS

First QBone demonstration of Bandwidth Broker, Premium Service

Multiple high-performance applications using Premium service

BLN

100BT

ATMATM

VideoConferencin

g

BLN

(No DS)

Nano-Manipulator

Highway 1 Washington D.C.

NCSU, Raleigh

MCNC, RTP

UNC, Chapel Hill


NCNI/QBone April 99 Demo: Testing Premium Service

RT Stereo Video Source

RT StereoVideo

VideoConferencin

g

vBNS ATM

BLNASNAccelar 1200

BLN ASNEthernet Switch

Optivity Policy Server

Nano-Manipulator

Client

LDAP ServerLDAP

COPS

BLN

VideoConferencin

g

BLN

(No DS)

Nano-Manipulator

Highway 1 Washington D.C

NC State Raleigh

MCNC, RTP

UNC, Chapel Hill

Controlled

Contending Best Effort Traffic

Marking Policing Shaping

Marking Policing Shaping

Policing Shaping Marking

VBR 10MBm

15MBpeak

Premium service contends with Best Effort traffic Limited resources require limited granting of Premium

service to high-performance applications


Scheduling

Route-pinning;Multicast

QoS Routing;

Static inter-domain interoperability

Inter-domain signaling;BB interoperability tests

Signaling through API

Real $

Down the Road...

More clouds...

More users...

Stronger services...


Many Hard Problems Ahead!• Many talents and much dialogue required

before production, interdomain services feasible• Engineering, planning - Network engineers

and planners• Advanced development, analysis, and

research - Networking researchers• Policy, economics - Administrators• Application, middle-ware design - Developers• Expectational shifts - Users

• QBone should enable “DiffServ research”


Near Future

• Jun 99: QBone BB Advisory council converging on prototype inter-BB protocol

• Jun 99: “Phase0” rollout planning

• Aug/Sep 99: Interdisciplinary QBone workshop

• Sep 99: QBone Connect-a-thon (“Con”) event


For more information...

• QBone home page:http://www.internet2.edu/qbone

• Internet2 QoS Working Group home page:http://www.internet2.edu/qos/wg

I2 Middleware Initiative:The “Services Rich” Network

Environment


What’s an Ideal “Internet2”

• Functional services available to users and developers• Enabling new collaborations and applications• Supported as production quality• An integrated framework

• Scaled to the size of the research and education community


Applications: Horizontal, Vertical, Spot Solutions

Middleware:Security, Directory, Quality of Service,Audio/Video Frameworks, Accounting,Collaboration Frameworks, Multicast

Operating system and network services

Standard APIs

Standard APIs

Interoperable Protocols


Technology Scope

• QoS• Digital video/audio• Security• Collaboration• Directories• Multicast• File systems• Measurement• Remote instruments

• Transaction systems• Meta-computing• Management• IP telephony• Accounting/billing• E-commerce• Object brokers• Search mechanisms• Printing


PhysicsApplications

PhysicsQoS

Digital LibraryApplications

Digital LibraryQoS

InstructionalApplications

InstructionalQoS

Data MiningApplications

Data MiningQoS

TCP/IP Network

PhysicsSecurity

PhysicsDirectories

PhysicsStorage

Digital LibrarySecurity

Digital LibraryDirectories

Digital LibraryStorage

InstructionalSecurity

InstructionalDirectories

InstructionalStorage

Data MiningSecurity

Data MiningDirectories

Data MiningStorage

Avoiding Segmentation


Initiative Overview

• Deliverables• Identification of a small number of key

community projects• Information dissemination• Demos • Workshops


Principles

• Focus on problems where • We have a unique incentive to solve• The benefit to our community is clear

and compelling• Results are attainable in a reasonable

timeframe


I2 Middleware Includes

• I2 Distributed Storage Infrastructure

• Qbone

• Digital Video

I2-Digital Video

www.internet2.edu/dvn


Ubiquitous Digital Video

• Scalable and easy to use

• Integrated into applications

• Streaming and interactive

• Real-time and asynchronous (stored)

• Unicast and native multicast

• Single source to multi-source

• Resolutions up to HDTV


I2 Digital Video

• Partnering with I2 Distributed Storage on servers

• Will rely on multicast• Sept 98 “learning experience” at I2 SF MM

with 7 channels

• Extensions of Content: Animation, 3D, Simulation, VR Movies, Immersion, etc.

• Digital Broadcasting Networks, Studios, DV-Stations (3-tiered architecture)


I2 Digital Video, con’t

• More Participants Welcome!


The End

Documents

Internet2: A Tutorial Part 4 of 4