Recent Advances in Network Computing
Zhiwei Zhao
zhiwei@mobinets.org
Recent advances
NDN: Named Data Networking.
- An instance of ICN[1][2].
- Data has names and can be identified.
SDN: Software Defined Networks
NFV: Network Function Virtualization
Edge: Edge Computing
- Cloud in proximity.
- Dispersed and resource constrained.
ICN*: Transfer data based on its properties not opaque bytes and addresses
Recap for TCP/IP
Today's Internet is established in 1970's
Originates from telephony systems
End-to-end communication
Source-destination
No packet states
Finding a content
- You enter a URL into a web browser
- The browser looks up the IP address for the domain name via DNS
- The browser sends a HTTP request to the server
- The server sends back a HTTP response
- The browser begins rendering the HTML
- The browser sends requests for additional objects embedded in HTML (images, css, JavaScript) and repeats steps 3-5.
- Once the page is loaded, the browser sends further async requests as needed.
Finding a content
To find content in the network
..you have to learn where the content is
..and then ask the network to take you there
..so you can tell the server what you want
Hmm.. Why do we care about the servers really!
Things have changed
Most communications are end-to-end.
Security is not built into the TCP/IP Internet, but was added as an add-on.
Things have changed
Main communications are no longer end-to-end (82% are videos!).
Things have changed
New communication paradigms
Content-intensive communications
Mobility
Cloud computing
Suffers from security challenges
Inefficient
Ideal solution
Next generation Internet
More efficient
content oriented
more scalable
less overhead
...
More secure
Next generation Internet
Content-centric networking
Named Data Networking
Many others
*US NSF's FIA program.
Main principles
Built-in security
Content is the first-class citizen
Cache content
Name content
Look for content
Mobility is pervasive
Computing is ubiquitous
CCN/NDN Design
The narrow waist becomes content
NDN Design
Name the content instead of end hosts.
- Consumers: send Interest packets
- Producers: return pulled contents
Routing in TCP/IP
Routing in NDN
Comparison
| TCP/IP |
NDN |
| Name end-hosts (e.g., IP addresses) |
Name content |
| Communication |
Content distribution |
| Mobility is difficult |
Mobility-friendly |
| Make processes secure |
Make content secure |
NDN Security
All contents are signed by publishers
Authenticity
Integrity
Content objects are encrypted
Confidentity of content
Privacy?
NDN: Privacy
No "source address" in content interests (no need for routing)
Traffic monitoring less effective for non-global adversaries
NDN: Privacy challenges
Name privacy
/Bili/Video/BV1j4411W7F7
Content privacy
Public content
Cache privacy
Detect hit/miss
Signature privacy
Reveal publisher identity
Stateful Forwarding
Stateful Forwarding
Stateful Forwarding
Interest forwarding is determined by:
FIB
Measurement of Interest-data exchange (and more local information)
Per-namespace forwarding policies
Resillient data availability
- Multicast delivery
- Pervasive in-network caching
- Delay/disruption tolerance
- Multipath forwarding
🤔 Can be solved by IP network? with many many tweaks
All the above add redundant means to obtain data.
NDN make data identifiable, independent from its containers or channels
How we secure data today
Encrypting point-to-point channels
TLS, QUIC
Assumptions
Synchronized connectivity between two communicating ends
All CAs' keys configured into all nodes
Delay and disruptions everywhere
No centralized CAs
How about NDN?
The NDN design mandates that all Data packets are
secured at the time of production
Signed
Encrypted as needed
Interest can be secured as needed
Enabling secure communication independent from
data containers or underlying communication
channels
NDN enables E2E security
independent from intermediate communication channels, middle boxes, intermittent connectivity
NDN enables E2E security
Security bootstrapping
Installing trust anchor(s) into all entities
All data producing entities receive crypto certificates
Security is simple in NDN
Data authentication → Sign/Verify produced/received data
Data confidentiality → Encrypting data
NDN supports name & attribute-based encryption
Data availability → via redundancy
Maintaining multiple copies
Trying multiple paths
native properties built into the NDN forwarding plane
Concept Takeways
A new way to communicate
without need for network addressing
Fetching named data at network layer
demanded by new apps and scenarios
enabled by technology advances
Networking by app-defined data names
Securing data directly
Increasing data availability via multicast delivery, in-network cache, ...
Traffic engineering in NDN
- Manipulation of traffic to
reflect network intent
(mission requirements)
- Traffic prioritization
- Traffic shaping
- QoS signaling
- Primary focus of a number
of protocols such as OSPF-
TE
|
|
Elements of TE
| Load balancing |
Load distribution |
Diff. Obj. functions |
| Bcast, Mcast, and Ucast |
Estimation and measurements |
Priority signaling |
Elements of TE
| Load balancing |
Load distribution |
Diff. Obj. functions |
| Bcast, Mcast, and Ucast |
Estimation and measurements |
Priority signaling |
Elements of TE
| Load balancing |
Load distribution |
Diff. Obj. functions |
| Bcast, Mcast, and Ucast |
Estimation and measurements |
Priority signaling |
Elements of TE
| Load balancing |
Load distribution |
Diff. Obj. functions |
| Bcast, Mcast, and Ucast |
Estimation and measurements |
Priority signaling |
Elements of TE
| Load balancing |
Load distribution |
Diff. Obj. functions |
| Bcast, Mcast, and Ucast |
Estimation and measurements |
Priority signaling |
Elements of TE
| Load balancing |
Load distribution |
Diff. Obj. functions |
| Bcast, Mcast, and Ucast |
Estimation and measurements |
Priority signaling |
Who signals prioritization
Today's model
Today's traffic engineering model is anchored off of end-points, not content
Anchored off of TCP/IP header information
Per-flow granularity
Why limiting
- QoS must reflect content not end-point semantics
- Different chunks of data
may carry information
with different QoS
requirements
- Per-chunk granularity as
apposed to per flow
granularity
|
|
NDN functions for TE
Producer driven
Explicit signaling (embedded in name)
/ndn/uestc/ranc/2022/QoS/latency-max=2
Same data can be served at diff. QoS
Implicit signaling (inferred from name)
/task-a/states/room1/vip → reliable/fast
/task-a/states/room1/common → reliable
Data chunks can carry different QoS signals
Forwarding strategy will attempt to honor both QoS
signaling approaches
Consumer driven
QoS signaling can be part of the ApplicationParameters of an Interest packet
/task-a/states/room1/vip
Forwarders will attempt to honor the embedded QoS signal
TE Driven
- Forwarding strategies are equipped to provide very strong TE mechanisms
- Can derive link (or path) reliability through the Interest ←→ Packet feedback loop.
- Can derive link (or path) latency through the Interest ←→ Packet feedback loop.
- NDN-LP provides reliability and latency information between NDN nodes
|
|
Can also measure traffic demand from Interest rate/class of service
TE Driven
- Forwarding decision can
be based on QoS
signaling from consumer
and/or producer
- Forwarding strategy can
continue to leverage the
in-band Interest/Data
feedback loop to
measure demand as well
as link (or path)
characteristics and adjust
FIB accordingly
|
|
Traditional load balancing
Load balancing is typically not
implemented because
of the impact of putting
TCP segments from the
same flow on two
different links (different
latencies can cause out-
of-order delivery)
Forwarding strategies
drive load balancing
An NDN forwarding
strategy can be devised
to accomplish load
balancing (and/or load
distribution)
TE Driven Forwarding Strategies
Forwarding strategies
can easily service
unicast, multicast, as
well as anycast request
Examples
- /task-a/states/room1/common
- Bcast since the info is
important to deliver to all nodes
fast
- Other nodes can enable
opportunistic caching for this
prefix
- /task-a/states/room1/vip/latency=x
- Send on link with latency less than x/2.
- /task-a/ftp/file-111219
- Send on highest capacity link
QoS-aware Caching
Insertion/eviction
policies can factor
QoS
Retaining chunks that
are latency-sensitive in
the network (e.g.
hostile tracks)
Factor in the value of
the information over
time
Factor in reliability of
links where the data is
typically serviced
Example policies
Retain only latest
sequence of chunks
where older sequence
numbers do not matter
Retain chunks longest
when the only path to
retrieve them is through
an unreliable link
Policy synchronization
QoS policy dataset can be retained and synched in network using Sync protocols
Appropriate security measures can be provided
Access control
Authentication (tie specific policies to specific administrative
domains)
Confidentiality
Integrity
Policy override (domain overrides local)
Thinking about NDN
“It is widely accepted that creative design is not a
matter of first fixing the problem and then
searching for a satisfactory solution concept;
instead it seems more to be a matter of
developing and refining together both the
formulation of the problem and ideas for its
solution.”
——Cross & Dorst (1999)
Thinking provided by Alex Afanasyev, Jeff Burke
Outline
How NDN (rather than IP) impact the app design and development
Outline affordances of NDN and design principles that may be good starting points for application research.
Introduce an example application -- AR Browser irrelevant video
NDN's offer to AR
- Low latency interactivity via packet granularity requests with
app semantics and enabling edge acceleration;
- Context-dependent retrieval of media, ranging from location
to content preferences and demographics;
- High throughput for scene video and content overlays;
- Progressive retrieval for responsive/scalable display, variable
level-of-detail, predictive fetching;
- Reverse CDN to scale consumers: Content and context
publishing, incl. users' mobile terminals;
- Heterogeneous wireless: Mobile terminals should be able to
transparently use a variety of comm technologies;
- Real-world trust: Diverse, non-binary trust models;
- IoT Integration: Ability to integrate with data/devices that may
not / should not be be Internet-accessible.
Challenges with IP
From Architecture to Apps
Define apps in terms of named data
Emphasize real-world principles, data ecosystems, rather than devices
Borrow what works from existing Internet
End-to-end principle, request-response model, SPKI-style security
Implement data-centric design and deployment patterns
Avoid what comes with point-to-point connection assumptions
Define apps with NDN
Data: thin waist |
 Get anywhere |
 All signed |
- Names facilitate management and trust derivation.
- Signed by producer and verified by consumers.
- Repos enable persistent storage of data objects.
- Sync enables multi-party synchronized state.
Generalizing AR and web
Observation: Context and content require processing and storage not achievable on mobile handsets or well-served by cloud.
"In terms of named data"
| What are the various kinds of data? |
What process creates them? |
Who owns them? |
| Who (what) processes can access then? |
When are they needed? |
How will the data evolve over time? |
AR Example #1
Even cinematic content will not be linear
AR Example #2
Context will be determined in real-time, with edge assistance
Augmented Reality as web
Borrow what works from existing Internet
A (decentralized, interoperable) data web integrated with physical
world. Layers instead of tabs.
Apps as per-layer unikernels / containers.
Consumer responsible for requesting what it needs.
Sessions replaced by multi-party context-content exchange.
URLs as user-facing names that start in-network discovery. Many
entry points into content navigation – brand, location, etc.
Common service interactions expressed as data-centric protocols.
Edge supported context analysis (and content generation).
All named...
Context,Content, Metadata, Certs, Service, Storage, Identity
Implementation
Implementing data-centric design and deployment patterns
- Create host-independent behavior
- Embrace Multicast
- Enable (and Use) Storage Everywhere
- Communicate Assertively & Opportunistically
- Share Namespace Updates, Not Connections
Aspects of these show up in cloud-based designs but don't work well in highly dynamic/mobile environments.
A prerequisite for how NDN achieves these
Secure data at its creation.
Secure data at creation
- Simple concept.
Required for all the rest to work.
- Key granularity (in data type, time, identity
dimensions) is closely tied to granularity of
control.
- Foregrounds identity and ownership.
- Applications must consider retention, privacy,
etc.
|
|
Name all data
Create Host-Independent Behavior
- A reason for "cloud" success
- Now possibly in a wider variety of networking
situations by using named, signed data.
- In IP, requires mapping services, which add
brittleness / complexity and increase attack
surface.
- Instead, name (and sign) all the things.
- Requires designing (and coding) with host-independent thinking, even for data about
hosts.
- More work to do: In-network name discovery.
|
|
Embrace Multicast
- Though TCP/IP supports multicast in theory,
in practice, build around unicast
- Because of connection-level security
- Limited infrastructure support
- Handling in a host-based way is cumbersome
- NDN provides intrinsically
- In networks, via stateful forwarding
- In local context, e.g., by leveraging broadcast nature of many media
- Follows easily from host independence
|
|
Enable/Use Storage Everywhere
- No difference at network layer between
accessing stored and on-demand data
- Every node has some storage
- Publish-and-forget for high level applications;
using in-memory and persistent storage
- Challenges:
- Retention policies
- Data for namespaces you don't control
- Relationship to data access patterns.
|
|
Communicate Assertively & Opportunistically
- Best-effort delivery is an important part of
Internet's success
- Extend best-effort to attempts to
communicate
- In many cases, data-centric designs and
deployments should aim for async
communications, whenever they can
- Offers resilience
- Considered originally for tactical applications
and other IoT, but applicable even just for
one's laptop or desktop
|
|
Share Namespace Updates, Not Connections
- Namespaces as (selectively) shared memory
between different ecosystem components.
- TCP can be seen as two-party
synchronization, with simple chunk
numbering (for each end) as the namespace
- NDN can generalize this to multi-party sync
using app namespace
- Leverage efficient set reconciliation
techniques
|
|
