ieee globecom futurenet, miami, fl, dec 2010 1 meta-headers: top-down networking architecture with...

IEEE GLOBECOM FutureNet, Miami, FL, Dec 2010

1

Meta-Headers: Top-Down Networking Architecture with Application-Specific Constraints

Murat YukselUniversity of Nevada, Reno

Reno, NV

[email protected]://www.cse.unr.edu/~yuksem


2

Motivation: The trends

The variety of applications possible is increasing, especially in wireless wireless peer-to-peer, mobile data, community

wireless The size is increasing:

million-to-billion nodes The dynamism is increasing:

vehicular networks, sensor networks, MANETs

What is unavoidable?: More dynamism, more disruption tolerance, more entities, and more varieties


3

Motivation: The big picture

(a) OSI

Transport

Network

Data Link

Physical

Session

Presentation

Application

(b) Wireline

Transport(TCP, UDP)

Network (IP)

Data Link(Ethernet 802.3)

Physical(Fiber, Cable)

Application

(c) Wireless

Transport(TCP, UDP)

Network & MAC (IP, Mobile IP,

802.1x)

Physical(RF, Fiber, Cable)

Application

(d) MANET, peer-to-peer

?

Network & Routing

?

Application

Physical(RF, FSO, Fiber, Cable)

Ap

plicati

on

-Sp

ecifi

c

Hard

ware

-Sp

ecifi

c

Netw

ork

-Sp

ecifi

c

Static Structured Layered invariants

Mobile, ad-hoc, dynamic Unstructured Cross-layer & layered

invariants

We need a systematic way of implementing vertical components to avoid an unhealthy monolithic stack

architecture.

Economics always has the bigger force: economically attractive applications will keep forcing more vertical components into

the stack!


4

Motivation: Response to the trends

Wireless research has been responding with optimizing via cross-layer designs adding custom-designed vertical components to

the stack Old hat: layered vs. cross-layer tradeoff

Bottom-up cross-layer has been the main approach Scarcity of wireless resources dominated the

economics


5

Motivation: Response to the trends

A paradigm shift: wireless resources are becoming massively available Community wireless WiFi hotspots Google WiFi, AT&T Metro WiFi

Spectrum resources may still be scarce but connectivity is already ubiquitous

The key metric to optimize is becoming application utility rather than the wireless resources

App-specific vertical designs are needed..

We need top-down cross-layer designs in addition to the traditional bottom-up ones.


6

Why not continue merging layers?

Merging layers: A greedy approach Makes it hard to standardize – bad for sw

engineering

Which layers must be absolutely isolated? Application, Network, Physical?

Integrating lower level functions with a higher layer function will prevent them becoming a substrate for other higher layer protocols Cellular provisioning in the US – jailbreaks


7

Motivation: Application Layer Framing (ALF)

Layering was a main component of the e2e architecture..

“a major architectural benefit of such isolation is that it facilitates the implementation of subsystems whose

scope is restricted to a small subset of the suite’s layers.”Clark and Tennenhouse, SIGCOMM’90

But, Integrated Layer Processing (ILP) was there too! To achieve better e2e efficiency and resource optimization ILP never become a reality due to the lack of a systematic way of

doing it. An ALF-based approach is needed:network protocol services at lower layers can best be useful

when applications’ characteristics and intents are conveyed to the lower layers.


8

Meta-Headers: A vertical design tool

A packet meta-header: vertically travels across the network stack establishes a vertical communication channel

among the traditional layers co-exist with the traditional per-layer packet

headers

Applications can communicate their intent across all the protocol layers by attaching the meta-headers to data.

<meta-headers, message>


9

Headers vs. Meta-Headers

Application

Layer 4

Layer 3

Layer 2

Layer 1

message

H4 messageMH1MH2MH3MH4

H3 H4 messageMH1MH2MH3MH4

H3H2H1 H4 messageMH1MH2MH3MH4

H3H2 H4 messageMH1MH2MH3MH4

Traditional packet headers

Application-specific packet meta-headers

Application

Layer 4

Layer 3

Layer 2

Layer 1

Traditional packet headers

Application-specific packet meta-headers

Explicit Meta-Headers

message

messageMH4MH3MH2MH1

MH1 messageH4MH3MH2

H2MH1 H3 messageH4

MH1MH2 messageH4H3

H3H2H1 H4 message

Implicit Meta-Headers


10

Meta-Headers: Demultiplexing


Layer 3

Layer 4

Protocol 1 Protocol 2

Dem

ult

iple

xin

g w

ith

tr

ad

itio

nal h

ead

ers



Layer 3

Layer 4

Service 1 Service 2

Dem

ult

iple

xin

g w

ith

m

eta

-head

ers



11

Informing Applications about Lower Layer Services

How will upper layers know about the service primitives of the layers lower than the one below?

Reactive – Meta-Headers in Reverse Direction detect lower layer services in an on-demand

manner as connections arise meta-headers rewritten by lower layers in reverse

direction Requires a closed-loop – connectionless or multi-

receiver services may not work


12

Informing Applications about Lower Layer Services (cont’d)

Proactive – Pre-informed Designer inform layer k designers about services of layers

k-2 and below apriori too much complexity as the number of lower

layer services increases – rank ordering might help

May not be desirable by ISPs Regional service discovery via broadcasting –

connectionless


13

End-to-End Coordination

Application

Layer 4

Layer 3

Layer 2

Layer 1

message

messageMH4MH3MH2MH1

MH1 messageH4MH3MH2

H2MH1 H3 messageH4

MH1MH2 messageH4H3

Traditional packet

headers

Application-specific

packet meta-headers

H3H2H1 H4 message

Application

Layer 4

Layer 3

Layer 2

Layer 1

Layer 3

Layer 2

Layer 1

H2MH1 H3 messageH4

MH1MH2 messageH4H3

H3H2H1 H4 message

Optional feedback loop for conveying available L1-L3 services

1Application at

source prepares meta-headers with default

options and sets flags to probe for available services

2Meta-headers

may or may not get converted to

traditional headers.

3Meta-headers are

filled with available L1-L3 services, and optionally fed back

to the source application.

4Meta-headers are filled

with summary of available end-to-end

L1-L4 services, and fed back to the source

application.

5Application at

source readjusts meta-headers

for joint vertical optimization of

end-to-end performance.

H3H2H1 H4 message

MH1MH2 messageH4MH3

H2MH1 H3 messageH4

MH1MH2 messageH4H3

MH1MH2 messageH4MH3

MH1MH2 messageMH4MH3

Feedback loop for conveying end-to-end

multi-hop L1-L4 services, possibly as a sequence of options over multiple hops.

Optional feedback loop

for local optimization of

last hop(s) of the end-to-end

path.

SOURCE

ROUTER

DESTINATION

A dynamic end-to-end negotiation..


14

An optimization perspectiveApplication

Top-Down Value Choice Optimization Framework

Application-Specific View of the Network

Application-Specific Constraints

Value Choices

E(application-

basedcost)

Q3(per-layer

state)

B(qualityconstraints)

Meta-header probes questing lower layer services

Meta-headers filled with available services

Q2(per-layer

state)

W2 (implicit)(per-layer constraints)

Network

Network State Information

Network Resource Constraints

Links

Link State Information

Link Resource Constraints

W3 (implicit)(per-layer constraints)

Lagrange multipliers (pieces of E)

Lagrange multipliers (pieces of Q2 and Q3)

Vertical optimizations are possible

More dynamic

Meta-headers as Lagrange multipliers


15

Summary A top-down networking architecture with meta-

headers Vertical optimizations at finer temporal and

spatial granularity A variety of top-down optimizations:

Top-down routing (layers 5, 3) Top-down QoS/value management (layers 5,

3, 2) Top-down dynamic transport (layers 4, 3, 2)

A new class of optimization problems aiming to improve joint performance of multiple layers while respecting the isolation among them.


16

Thank you!

THE END

This work is supported in part by the U.S. National Science Foundation awards 0721600 and 0721609.

ieee globecom futurenet, miami, fl, dec 2010 1 meta-headers: top-down networking architecture with...

Documents

lower layer services

ieee globecom futurenet

crosslayer designs

crosslayer tradeoff

reactive metaheaders

higher layer function

lower layers

layers lower