On the value of a GNS in Informatjon-Centric Network Architectures - - PowerPoint PPT Presentation

▶
on the value of a gns in informatjon centric network
SMART_READER_LITE
LIVE PREVIEW

On the value of a GNS in Informatjon-Centric Network Architectures - - PowerPoint PPT Presentation

May 17, 2023 907 likes •1.27k views

On the value of a GNS in Informatjon-Centric Network Architectures V. Arun University of Massachusetus Amherst 1 What is ICN? ICN Named informatjon is a central architectural principle [ICNRG] Ofuen contrasted against TCP/IPs

slide-1
SLIDE 1

On the value of a GNS in Informatjon-Centric Network Architectures

  • V. Arun

University of Massachusetus Amherst

1

slide-2
SLIDE 2

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

What is ICN?

  • ICN  Named informatjon is a central architectural

principle [ICNRG]

  • Ofuen contrasted against TCP/IP’s host-to-host IP-address-

centric (locatjon-dependent) communicatjon abstractjon

2

[ICNRG] htups://irtg.org/icnrg

slide-3
SLIDE 3

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Locatjon-independence

3

An abstractjon to communicate using fjxed names without worrying about (changing) locatjons.

get(“Alice’s webpage”) send(“Bob’s phone”, msg) connect(“BofA banking service”) HTTP UDP/SMS TCP

Why is today’s Internet not locatjon-independent?

[ICNRG] htups://irtg.org/icnrg “data becomes independent from locatjon…"

slide-4
SLIDE 4

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Internet confmates locatjon and identjty

4

B B

app app TCP/UDP IP socket socket

device_name service_name 128.119.240.93

B B B B B B B B

X

multjhoming mobility

content_name

All communicatjon must be straitjacketed to an IP- addressable, host-to-host communicatjon primitjve

slide-5
SLIDE 5

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Locatjon-independent network architectures

  • Host-centric: HIP
  • Informatjon-centric: TRIAD

5

ROFL NDN SEATTLE Serval PURSUIT LISP MobilityFirst XIA LNA DONA

Locatjon independence (and informatjon centrism?) not incompatjble with presence of locator hints

[ICNRG] htups://irtg.org/icnrg

i3

slide-6
SLIDE 6

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

FUNDAMENTAL APPROACHES TO LOCATION INDEPENDENCE

6

slide-7
SLIDE 7

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Locatjon independence  mobility

  • Locatjon independence largely matuers only when

locators change frequently a.k.a. mobility

7

slide-8
SLIDE 8

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Approaches for handling mobility

8

A A A A R B B

A?

slide-9
SLIDE 9

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

HA

Indirectjon routjng

9

A A A A B B

FA 1 2 3 4 Indirectjon entails data path stretch (steps 3 and 4)

slide-10
SLIDE 10

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Name-to-address resolutjon

10

A A A A B B

1 2

GNS

3 4 Lookup/update overhead but no data path stretch

slide-11
SLIDE 11

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Name-based routjng

11

A A A A B B

1 2 3 Update cost? FIB size? Path stretch?

slide-12
SLIDE 12

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Research fjndings

  • A logically centralized GNS can signifjcantly enhance

mobility support for any network architecture

  • Empirical analysis [GVKH14]
  • Modeling-driven analysis [CKV18]

12

  • [GVKH14] Z. Gao. A. Venkataramani, J. Kurose, S. Hiemlicher, A Quantjtatjve

Comparison of Locatjon-Independent Network Architectures, ACM SIGCOMM 2014

  • [CKV18] V. Chagantj, J. Kurose, A. Venkataramani, A cross-architectural quantjtatjve

evaluatjon of mobility approaches, IEEE INFOCOM 2018

slide-13
SLIDE 13

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

MOBILITYFIRST GNS

13

slide-14
SLIDE 14

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

MobilityFirst: Mobility-Centric + Trustworthy

  • Key insight: A logically centralized global name service

can dramatjcally enhance seamless mobility, security, and rich network functjonality

  • Name-based communicatjon abstractjon enabled by self-

certjfying GUIDs (globally unique identjfjers)

15

slide-15
SLIDE 15

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Scalable global name service (GNS)

16

A massively scalable, logically centralized GNS to enable secure, name-based communicatjon with fmexible endpoint principals with arbitrary (fjxed) names despite high mobility.

Global name service (GNS) Global name service (GNS) interface device service content group of names f0:56:81:c1:c0:eb node1.cs.umass.edu arun’s phone netglix.com/<object> devices in [lat,long,radius]

slide-16
SLIDE 16

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

GNS DEEPER DIVE

17

slide-17
SLIDE 17

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Why GNS critjcal to handle mobility

18

Global name service

Alice IP1 IP2 IP3 Bob’s address? IP4 IP5 Bob IP6 IP7 A l i c e ’ s a d d r e s s ?

Pre-lookup mobility Connect-tjme mobility Individual mobility Simultaneous mobility Pre-lookup mobility

GNS critjcal or can signifjcantly benefjt mobility handling in any network architecture

slide-18
SLIDE 18

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

DNS limitatjons

19

DNS DNS

cache

Load α 1/TTL Latency α 1/TTL

Mobility Mobility

Passive caching Statjc placement Hierarchical names

Authoritatjve name- server ns.xyz.net node1.xyz.net

. com edu net

yahoo cnn umass cs ece

F e d e r a tj

  • n

D N S S E C k e y c h a i n Single root of trust

“JohnSmith2178@Amherst” “Living room chandelier” “Taxis near Times Square”

slide-19
SLIDE 19

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

GNS: Decoupling certjfjcatjon and resolutjon

20

Name: “Alice’s phone”

TLD name services Auth. name services Root name service (ICANN,

  • US. Dept. of Commerce)

Certjfjcate search services

GUID=X, GNS=Auspice

Domain name system Global name system

getAddress(X) [IP1, IP2,…] 3 3 3 3 4 4 4 4 1 1 Local name services 1 1 Local name services 2 2 Name certjfjcatjon services Managed DNS services Auspice-like global name services

slide-20
SLIDE 20

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Open-source GNS for community use

  • htups://github.com/MobilityFirst/GNS

21

Currently being used as a foundatjon for Light-Speed Networking (LSN) ICN-WEN project and being beta- tested in several pre-productjon pilot deployments

slide-21
SLIDE 21

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

CONTEXTUAL COMMUNICATION DRIVEN BY GNS

22

slide-22
SLIDE 22

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Contextual Communicatjon

  • Ability to communicate based on (changing) aturibute

values (or context), e.g.,

  • send(msg, [lat, lon, radius])
  • get(cam_recording, type=“4K”, building=”CSAIL”, tjme=3pm)

23

slide-23
SLIDE 23

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Context-based communicatjon

  • At source: CAID  {UT1, T2, …, Tk} // get terminal networks
  • At terminal n/w: CAID  {Umembers(CAID) | Ti} // late binding

Global name service

CAID {T1,T2,…,Tk}

T1 Tk T2

send_data(CAID,T1) send_data(CAID,T2) send_data(CAID,T3)

CAIDmembers(CAID){UT1, T2, …, Tk}

24

GUIDi[UTi,{“type””yellowcab”,“geo””Times Sq.”}] GUIDiCAID

24

msocket.bind([Ulat, long, radius]) msocket.send(msg)

msg msg msg msg msg

slide-24
SLIDE 24

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Why GNS for contextual communicatjon

  • Key insight: “Solving” the problem of high mobility in a

network locatjon space naturally generalizes to mobility in any aturibute space

25

slide-25
SLIDE 25

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Apps: Hazardous weather warning

26

CASA Alerts: Collaboratjve Adaptjve Sensing of the Atmosphere

slide-26
SLIDE 26

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

EM web dashboard Alertjng app Contextual cloud engine Proprietary third-party sensor data streams

Functjonal prototype being pilot-trialed at UMass; followed by UCSD

(open-source)

Apps: Campus emergency management

slide-27
SLIDE 27

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Research challenges

  • Scalability: Balancing frequent updates and distributed

search in a scalable manner

  • Privacy: Ensure provider privacy, i.e., even GNS service

provider must not be able to access or infer ACL- protected sensitjve contextual atuributes

  • Programmable APIs: Simple robust APIs for app

developers to build contextual applocatjons

28

slide-28
SLIDE 28

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Discussion

29

slide-29
SLIDE 29

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

BACKUP

30

slide-30
SLIDE 30

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

High device mobility norm, not exceptjon

31

20% of users change over 10 addresses per day 370+ users, 14+ months

  • Z. Gao, A. Venkataramani, J. Kurose, S. Heimlicher, Towards a Quantjtatjve Comparison
  • f Locatjon-Independent Network Architectures, ACM Sigcomm 2014
slide-31
SLIDE 31

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Takeaways [GVKH14]

  • Mobility is the norm, e.g., 20% of users make well
  • ver 10 transitjons a day
  • Update cost of name-based routjng high for devices,

e.g., some routers impacted by 14% of mobility events

  • Update cost of name-based routjng small for content,

especially for the unpopular long tail

  • FIB size? forwarding traffjc? path stretch with caching?

32

[LocInd] A Quantjtatjve Comparison of Locatjon-Independent Network Architectures, ACM SIGCOMM 2014

slide-32
SLIDE 32

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Conclusions [CKV18]

  • Best-port: Best when TTC is high priority and control bandwidth is

expendable.

  • P-multjcast: Best when endpoint has a high probability of being at a

popular locatjon, cuttjng average control cost 60% from best-port, but at the expense of an increased forwarding traffjc cost.

  • Indirectjon: Best for small # packets and when TTC is not a concern.
  • GNS-based approach: Best when small TTC infmatjon above best-port

is acceptable for a scalable data and control plane cost. Provides the most suitable balance of costs.

18

slide-33
SLIDE 33

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

GNS with actjve names

  • Programmable client code upon reads/writes to names

34

Global name service

<GUID, attr>

actjve user- installed code Load balancing

  • Stateful,
  • Feedback-driven
  • Spot-price-aware

Actjve ACLs

  • pseudonyms
  • policy-based ACLs

Context-based comm.

  • delay-tolerant delivery
  • multjhomed traffjc engg.
slide-34
SLIDE 34

UNIVERSITY OF MASSACHUSETTS AMHERST • College of Information and Computer Sciences

Auspice GNS summary

Enables secure, name-based communicatjon

  • arbitrary name/locatjon representatjon
  • fmexible endpoint principals
  • handles all types of mobility
  • Key difgerences from DNS for today’s Internet
  • federatjon decoupling certjfjcatjon and resolutjon
  • actjve replicatjon
  • demand-aware placement

35

A logically centralized global name service dramatjcally enhances mobility, security, and network-layer functjonality