Extreme Networking
Sponsored Links
This presentation is the property of its rightful owner.
1 / 24

Jon Turner jst@cs.wustl arl.wustl/arl PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Extreme Networking Achieving Nonstop Network Operation Under Extreme Operating Conditions DARPA PI Meeting, July 23-26, 2002. Jon Turner jst@cs.wustl.edu http://www.arl.wustl.edu/arl. Presented by John DeHart jdd@arl.wustl.edu. Project Overview. Motivation

Download Presentation

Jon Turner jst@cs.wustl arl.wustl/arl

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Jon turner jst cs wustl arl wustl arl

Extreme NetworkingAchieving Nonstop Network Operation Under Extreme Operating ConditionsDARPA PI Meeting, July 23-26, 2002

Jon Turnerjst@cs.wustl.eduhttp://www.arl.wustl.edu/arl

Presented by John DeHartjdd@arl.wustl.edu

Project overview

Project Overview

  • Motivation

    • data networks have become mission-critical resource

    • networks often subject to extreme traffic conditions

    • need to design networks for worst-case conditions

    • technology advances making extreme defenses practical

Project overview1

Project Overview

  • Extreme network services

    • Lightweight Flow Setup (LFS)

      • simple soft-state reservations

      • (bulk of talk will be on LFS)

    • Network Access Service (NAS)

      • controls the creation of access pipes to an LFS network

      • preliminary specification has been developed

    • Reserved Tree Service (RTS)

      • network tree pre-reservations for ISPs.

Project overview2

Project Overview

  • Key router technology components

    • Super-Scalable Packet Scheduling (SPS)

      • Packet scheduling with very large number of queues.

    • Dynamic Queues with Auto-aggregation (DQA)

      • Aggregate queues based on source address prefixes

      • Limits impact of misbehaving host(s) to small # of queues

    • Scalable Distributed Queueing (SDQ)

      • Per flow Virtual Output Queueing

      • Data rate regulation to ensure high utilization

Prototype extreme router

Prototype Extreme Router


Field Programmable Port Ext.

Smart Port Card



Switch Fabric


























ATM Switch Core







Field Programmable Port Extenders









Transmisson Interfaces

Embedded Processors

Resource reservation in the internet

Resource Reservation in the Internet?

  • Bandwidth reservation can provide dramatically better performance for some applications.

  • Obstacles to resource reservation in the Internet.

    • distaste for signaling protocols

    • perceived complexity of IntServ+RSVP

    • requires end-to-end deployment

    • little motivation for service providers

  • How to get resource reservation in Internet?

    • keep it simple

      • focus on top priorities - one-way unicast flows

      • avoid complex signaling - leverage hardware routing mechanisms

    • make it useful when only partially deployed

    • provide motivation for ISPs to deploy it ($$)

Basic lfs operation

10 Mb/s available

5 Mb/s available

20 Mb/s available

5 Mb/s available

2 Mb/s available

Basic LFS Operation

Select path and perform partial reserve

Reserve bandwidth

Reserve 8 Mb/s to B

Complete reservation


20 Mb/s available


Select best next hop

Select path and reserve

  • Reservation request encoded in an IP option

  • One way, unicast setup with partial reservation.

    • complete reservations locally when bandwidth released

  • Optional ack returned by far-end access router.

  • Reservation may terminate explicitly or time out.

  • May alter reserved bandwidth but no re-routing.

Soft reservations

Soft Reservations

  • Basic LFS provides firm reservations.

    • user guaranteed bandwidth until releases

  • Can extend to provide soft reservations as well.

    • soft reservation can be adjusted by the network as traffic changes

    • can be intermixed with firm reservations to provide a firm minimum, plus more bandwidth as available

  • Uses of soft reservation.

    • apps. that need guaranteed minimum and can sometimes use more, but can adjust use to what’s available

    • more rapidly responding congestion control for traditional best-effort traffic

Basic ip option for lfs

IP header(fixed part)








IP payload

Basic IP Option for LFS

  • Allocated rate stored at “last hop” router for status generation

  • F.P. rates with 4 bit mantissa, 4 bit exponent.

    • specify rates from 64 Kb/s to 4 Gb/s , 6% “granularity”

  • Code identifies LFS option.

  • Operations

    • request firm reservation

    • request soft reservation

    • release state

  • Flags

    • sender status request

    • sender network status request

    • public network status request

    • intra-domain status request

    • congested path

  • Rrate: requested rate.

  • Arate: allocated rate.

  • Trace used by each domain to track usage.

Use of trace field












Use of Trace Field

acct. record[A,B,..] thru X

acct. record[A,B,..] thru Z

acct. record[A,B,..] thru Y

  • Network providers need to monitor LFS usage for network management and accounting purposes.

    • trace field used by ingress router of each domain to mark LFS packets with domain-specific identification

    • egress router of each domain maintains record of each LFS flow, including copy of trace field

    • end-to-end records created through off-line accounting resolution mechanisms

Status reporting

sender status

sender net status

public net status

sender LAN



rcvr. LAN

intra-domain status

Status Reporting

  • Basic LFS option supports sender status and trace field for accounting.

  • Network providers likely to want more.

    • sender net status allows LFS service verification

    • public net status allows “end-to-end” status check

    • intra-domain status for verifying local status

    • each “extra” status report requires insertion of requestor’s IP address, increasing LFS option length

Partial deployment

Partial Deployment

  • Receivers need not be LFS-aware.

    • web site may use LFS to reserve bandwidth for streaming media - users benefit, even without LFS-aware hosts

  • Issues with non-contiguous LFS domains.

    • route changes may create “orphan reservations”

    • no simple way to determine status reporter

  • No support for non-contiguous LFS domains.

    • LFS router forwarding to a non-LFS router (or host) strips LFS option and implements status reporting

      • status report includes IP address of reporting router, letting sender know how far the reservation went

  • Public IP carrier can accept LFS option from client networks (LAN) even if client net is not LFS-aware.

  • Clients may use tunnel to access LFS service.

Regulating lfs use net access svc

Regulating LFS Use - Net Access Svc

  • Permitting unconstrained access to LFS creates big security vulnerability.

  • Limit use to authorized users.

  • Limit number of reservations and amount of reserved bandwidth by authorized users.

    • access router keeps record and enforces limits

    • complication - user may use LFS from multiple locations

      • maintain records in distributed set of servers - each server keeps records for some fraction of the users - use hashing to select

  • Access router needs means to identify user.

    • host IP address insufficient (DHCP, NAT)

    • encryption-based authentication (IPSEC)

  • Combine access control with usage accounting.

  • What special issues arise with multiple domains?

Test 1 lfs video demo configuration

Test 1: LFS Video Demo Configuration

cross traffic sinks

video source

~12.5 Mb/s links

(artificially constricted for test purposes)

video sink

cross traffic sources

  • SPC based implementation of LFS.

  • Wavelet-coded video with and without LFS.

    • competing datagram traffic

    • with no reservation, lost packets cause poor video quality

    • with reservation, high quality preserved

Video demo no reservation

Video Demo - No Reservation

video source

cross traffic sources

all sinks

video flow - no reservation

datagram cross traffic flow 1

datagram cross traffic flow 2

Video demo with reservation

Video Demo - With Reservation

video sink

cross traffic sinks

video flow - with reservation

datagram cross traffic flow 1

datagram cross traffic flow 2

Test 2 competing lfs flows

Test 2: Competing LFS Flows


sink 2

sinks 1&2

sink 1

sink 3

flow 1 - no reservation

flow 2 - reservation added

flow 3 - no reservation

no reservations

reservation for flow 2

Partial reservation

Partial Reservation

source 1

flow 2

sink 1

sink 3

flow 1 - partial reservation made

Completing partial reservation

Completing Partial Reservation

sink 2

sink 1

sink 3

flow 1 - completes partial reservation

flow 2 - drops reservation

Addition of flow 3 reservation

Addition of Flow 3 Reservation

sink 2

sink 3

flow 3 - adds reservation

Performance of lfs at single link

Performance of LFS at Single Link

Pareto distributed session times make little difference

OC-48 link can carry 200 flows of 12 Mb/s

  • m = number of flows link can carry

  • exponential session times for flows, infinite queue

very few flows experience any delay

Sensitivity to load and hop count

Sensitivity to Load and Hop Count

delay probability scales linearly with number of hops

at 90% load, less than 1 flow in 100 delayed more than 12% of session time

Overload performance

Overload Performance

with no buffer most sessions still succeed

with infinite buffer, no sessions get small delays (10%)

buffer reduces rejection fraction at low loads



  • LFS provides simple reservations for QoS.

    • no complex signaling, wire speed setup

    • limited deployment can be broadly beneficial

    • support for usage monitoring & accounting gives network providers a motivation to deploy service

    • First version is implemented and working

  • Network access service for regulating usage.

    • preliminary specification has been developed

    • uses IPSEC for host/user authentication

  • Performance analysis, simulation study underway.

  • Routing issues.

    • evaluate QoS routing with multiple-choice forwarding

    • link state distribution for inter-domain routing

    • inter-domain routing policies

  • Login