Tango or Square Dance How Tightly Should we Integrate Network Functionality in Browsers

2025-05-02 0 0 531.06KB 8 页 10玖币

侵权投诉

Tango or Square Dance? How Tightly Should we Integrate

Network Functionality in Browsers?

A. DavidsonFM. Frei‡M. Gartnerz*H. HaddadiF†A. Perrig‡J. Subirà Nieto‡P. WinterFF. Wirz‡∗

FBrave Software ‡ETH Zurich †Imperial College London zOVGU Magdeburg

ABSTRACT

The question at which layer network functionality is pre-

sented or abstracted remains a research challenge. Tradition-

ally, network functionality was either placed into the core

network, middleboxes, or into the operating system – but

recent developments have expanded the design space to di-

rectly introduce functionality into the application (and in par-

ticular into the browser) as a way to expose it to the user.

Given the context of emerging path-aware networking tech-

nology, an interesting question arises: which layer should

handle the new features? We argue that the browser is be-

coming a powerful platform for network innovation, where

even user-driven properties can be implemented in an OS-

agnostic fashion. We demonstrate the feasibility of geo-fen-

ced browsing using a prototype browser extension, realized

by the SCION path-aware networking architecture, without

introducing any signiﬁcant performance overheads.

1 Introduction

With the emergence of path-aware networks (PAN) [50],

the question arises on how applications can harness the new

network properties. In particular, Segment Routing (SR) [17]

is emerging in intra-domain environments, and SCION is be-

coming available in several inter-domain locations [10,27].

As these architectures are seeing real-world deployment,

new opportunities emerge. In particular, PANs offer multiple

path options from which the end system can select from – si-

multaneously also providing native inter-domain multipath.

Furthermore, path-aware architectures can decorate network

paths with additional information, such as latency, expected

bandwidth, MTU, traversed ASes, carbon footprint, etc. The

combination of multiple path options and per-path informa-

tion enables exciting new possibilities. For instance, net-

work performance can be improved by selecting latency-

or bandwidth-optimized paths, by selecting a path with low

loss, or by knowing the accurate path MTU. Communication

quality can also be improved through selection of paths with

low jitter, or through QoS offerings some PAN architectures

provide [18]. PANs also enable enhanced privacy through a

property referred to as geofencing, deﬁned by ﬁne-grained

control over which ASes are encountered on the forwarding

*Corresponding authors: marten.gartner@ovgu.de, wirzf@ethz.ch

path, similar to Alibi routing [30]. Path decorations may also

include environmental, societal, and governance (ESG) in-

formation, such as the carbon footprint of the traversed ASes,

giving rise to ESG-based path selection. Finally, economic

aspects can be used for path selection, with the obvious low-

est-cost routing, but for instance also enabling selection of

paths based on allied ASes.

Given these new opportunities for path selection, interest-

ing research questions arise:

•What entity should collect the path information? How

is the information disseminated? How is this informa-

tion authenticated (or where applicable certiﬁed)?

•For the property classes of performance, quality, pri-

vacy, anonymity, ESG, and economics, at what layer

can or should the path decision be made? Entirely

“within” the network? By the operating system (OS)?

By the application? Or even by the user?

•What are the interfaces between the network layers to

convey path information (potentially all the way to the

user)?

In this paper, we consider the general problem of which

property would be best addressed at what layer. In particular,

we consider network properties that one can implement in

browsers – potentially even in a user-driven manner. In that

way, we leverage the browser to drive network innovation.

Browsers have already served as vehicles for network in-

novation, as in the deployment of QUIC, which was a de-

cisive force to making UDP work well throughout the In-

ternet. QUIC is also deliberately built in user-space to en-

able further evolution to be driven from the applications, be

it on the browser or web server side. Another example is the

pervasive deployment of VPN technology, which is directly

built into many browsers to provide improved privacy and

anonymity properties. The rapid deployment of DNS-over-

HTTPS (DoH) and DNS-over-TLS (DoT) constitute another

example. Being deployed in browsers, DoH and DoT bypass

the operating system’s DNS resolver.

Browser-based integration of network functionality offers

several compelling beneﬁts. Integrating new network func-

tionality in the network or the OS comes with near insur-

mountable challenges caused by highly heterogeneous in-

frastructure and long update cycles. As a small number of

arXiv:2210.04791v1 [cs.NI] 10 Oct 2022

Table 1: Different properties enabled by path-aware net-

working. The marks indicate that the layer can mean-

ingfully select a path based on the property. In contrast,

the #marks indicate that the layer would not be the ap-

propriate place to perform the path selection. A G# mark

shows that no particular beneﬁts are expected.

Property OS App User

Performance properties

Low latency G# G#

Loss rate #

Path MTU information G# #

Bandwidth G#

Quality properties

QoS G#

Jitter optimization G#

Privacy / Anonymity

Geofencing (Alibi routing) G#

Onion routing G#

ESG Routing

Carbon footprint reduction G#

Ethical routing G# G#

Economic aspects

Allied AS routing G#

Price optimization

browsers see high penetration [44], and as browsers run on a

variety of platforms, new functionality can be disseminated

to a spectrum of users with relative ease.

Another important beneﬁt relates to usability. Many brow-

sers update automatically (requiring minimal user interven-

tion), making it possible to disseminate new features rapidly

and comprehensively [34].

Another aspect of this usability is that a browser integra-

tion can design interfaces for directly interacting with the

user itself if needed. The Brave browser provides a concrete

motivating example for these considerations, as it provides

a tight integration with the Tor network: a user can sim-

ply open a browser window for anonymous communication,

avoiding a manual installation of Tor [6].

To make our discussion more concrete, we leverage the

beneﬁts of tight browser integration to instantiate the PAN

architecture with SCION [10], which is deployed as a prod-

uction-ready, next-generation network architecture currently

operated by 12 ISPs. We consider the geofencing network

property in more detail, and present an implementation in

the Brave browser. Our approach demonstrates that browser

vendors are a powerful ally when deploying new networking

functionality such as PAN.

2 Which Layer Should Make Path Decisions?

Given the exciting new properties that PAN architectures

offer, we discuss in this section which layer should best make

path decisions.

Table 1lists the set of properties we consider.

The network layer implements PAN mechanisms in both

the control and data plane. For most properties, the con-

trol plane aggregates the required information and decorates

the path segments that are established. In the SCION con-

text, the path-segment construction beacons sent from AS

to AS, iteratively accumulate information during construc-

tion [10] – similar to a BGP update traversing the Internet.

The created path segments are then disseminated through a

path server infrastructure, along with the additional informa-

tion. End hosts fetching path segments thus receive the fully

decorated paths containing all added information.

We seek to address the following question: at what layer

should path selection take place? As the end host selects the

end-to-end path from a set offered by the network, the net-

work layer has limited discretion about which path the packet

traverses. Instead, the network layer relies on enforcing poli-

cies regarding which paths are created and disseminated, and

how much bandwidth can be obtained in the data plane.

Consequently, the ultimate decision point for the path se-

lection is at the end host, which can choose from a set of of-

fered paths. Depending on the network topology, SCION can

offer on the order of dozens to even over a hundred potential

paths through the combination of different path segments.

Such a large number of path choices offer a meaningful way

for multi-criteria end-to-end path optimization.

The question thus remains at what layer path selection

should be implemented. We see three broad possibilities:

OS, application, and user. Table 1lists various PAN proper-

ties along with the perceived best locus of decision. The OS

networking stack can select the path based on performance

or quality properties: low-latency and high-bandwidth con-

nections clearly provide a good user experience, especially

if that connectivity is available at a low price. However, for

properties such as privacy, anonymity, or ESG (environment,

society, governance) routing, the OS generally lacks context

to determine that trafﬁc is privacy sensitive, or how much

performance the user is willing to trade for better ESG met-

rics. Conversely, the user cannot make an informed decision

for some metrics. Metrics such as loss and MTU get ab-

stracted by lower layers, since they are directly impacted by

their interactions with the transport layer and OS.

With a path-based network API, the application can per-

form application-speciﬁc path optimizations, such as select-

ing low-latency paths for the voice channel of conferencing

applications, or low-loss paths for IoT command-and-control

channels, or anonymity for medical web sites.

An interesting observation of these considerations is that

for some properties the user context is decisive, as an appli-

cation can hardly ﬁgure out automatically for which desti-

nations CO2optimization is desired, and when geofencing

(restricted to which areas) should be used.

3 Network Innovation in the Browser

Section 2indicates that operating PAN architectures at the

application layer provides advantages over operating at the

OS layer, which raises the question: in which applications

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

TangoorSquareDance?HowTightlyShouldweIntegrateNetworkFunctionalityinBrowsers?A.DavidsonFM.FreizM.Gartnerz*H.HaddadiFyA.PerrigzJ.SubiràNietozP.WinterFF.WirzzFBraveSoftwarezETHZurichyImperialCollegeLondonzOVGUMagdeburgABSTRACTThequestionatwhichlayernetworkfunctionalityispre-sentedorabstractedremainsa...

展开>> 收起<<

Tango or Square Dance How Tightly Should we Integrate Network Functionality in Browsers.pdf

共8页,预览2页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

Tango or Square Dance How Tightly Should we Integrate Network Functionality in Browsers

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: