1from sentence_transformers import SentenceTransformer
2
3# Download from the 🤗 Hub
4model = SentenceTransformer("tjohn327/scion-snowflake-arctic-embed-s-v2")
5# Run inference
6sentences = [
7 'How is the concept of configurable rates in Z-Lane intended to accommodate varying traffic demands',
8 'Research paper section providing a Z-lane system description. Introduces AS/ISD-level bandwidth isolation and configurable rates using SCION\'s ISDs. Explains how ASes can overuse allocated bandwidth and send traffic at guaranteed rates.\n<citation> Marc Wyss et al.. "Zero-setup Intermediate-rate Communication Guarantees in a Global Internet." *Proceedings of the USENIX Security Symposium*, 2024. </citation>\n<type> research paper </type>\n<page> 5 </page>\n<content>\nZ-Lane. The decision how to configure the rates is ultimately\nup to the network operator and, importantly, does not require\nany inter-domain coordination. Due to the aggregation of\nASes into ISDs, configurations remain manageable even if\nthe Internet grows to hundreds of thousands of ASes.\nEnd Host Guarantees. Z-Lane lets end hosts, more specifi-\ncally their applications, define what traffic should be sent with\nforwarding guarantees, and what traffic should be forwarded\nover best-effort. Still, to protect against malicious end hosts,\ntheir AS has the ultimate authority in this matter and can re-\nclassify traffic to be sent as best-effort only. This protection\nis implemented through a Z-Lane gateway, which schedules\nend host traffic and authenticates it towards on-path routers\nusing a secret key not known to the end hosts. How traffic is\nscheduled is up to the AS operator; configurations can range\nfrom fair sharing to prioritizing certain traffic from critical AS\nservices like routing or time synchronization. We emphasize\nthat, to avoid any setup overhead (R3), neither ISDs, nor ASes\nor end hosts explicitly learn their configured rate; instead, end\nhosts implicitly discover their allowed rate through existing\nmechanisms like congestion control.\nCompatibility with Other Systems. Bandwidth reserva-\ntion systems cannot provide zero-setup communication guar-\nantees and are therefore not suitable to protect short-lived\nintermediate-rate communication (Section 8). Still, we design\nZ-Lane to seamlessly coexist with them, as they complement\nour work by effectively protecting non-setup-critical, high-\nvolume communication such as from video conferencing. We\nchoose COLIBRI [27] as a reservation system instantiation,\nbut other systems could be deployed as well. To prevent at-\ntacks targeting DRKey’s AS-level key exchange, which is a\nfundamental requirement for EPIC, our design also ensures\ncompatibility with the DoCile system [74], which leverages\ndedicated channels between neighboring ASes to successfully\nbootstrap the key exchange even under DDoS.\nWe therefore consider the following four types of inter-\ndomain traffic: COLIBRI reservation traffic, DoCile’s\nneighbor-based communication, authenticated traffic from\nEPIC, and unauthenticated SCION traffic.\n4.2 Source Authentication\nZ-Lane employs EPIC for authenticating traffic sources to\nborder routers, allowing every border router to verify the au-\nthenticity of every received packet. An important insight in the\ndesign of Z-Lane is that efficient and reliable source authen-\ntication as provided by EPIC allows for meaningful source-\nbased traffic control at border routers. The realization of this\nidea has not been possible so far because previous source\nauthentication mechanisms would cause excessive commu-\nnication or computation overhead and therefore impede de-\nployment, or were based on heuristics or probabilities, and\nwould thus fail to reliably distinguish between authentic and\nspoofed addresses (Appendix H). Z-Lane is the first system\nto explore the use of comprehensive source authentication to\nprotect the availability of short-lived intermediate-rate Inter-\nnet traffic – with EPIC’s security rooted in AS-level secret\nkeys, it integrates seamlessly into Z-Lane.\nWe want to highlight that EPIC together with a fairness\nmechanism provided by some congestion control algorithm,\ni.e., without any guaranteed rates, would not be enough in\nour threat model, as an attacker would just not respect the\nalgorithm’s feedback and instead keep sending traffic at high\nrates, or leverage a botnet to create many low-volume flows.\n4.3 End Host Traffic Generation\nEnd hosts, i.e., their applications, can choose among several\nmechanisms on how their traffic is forwarded (Figure 1). For\nlong-term traffic they request a bandwidth reservation and\nuse it by sending their COLIBRI traffic class packets through\nthe COLIBRI gateway. While the overhead for requesting\na reservation is significant, the result is a fixed amount of\nbandwidth that is exclusively reserved along the communi-\ncation path. In a similar way, applications send short-lived\nintermediate-rate traffic using the EPIC traffic class over the\nZ-Lane gateway, where traffic is forwarded immediately with-\nout any delay (requirement R3), but without the applications\nknowing the concrete rates. In both cases traffic is protected\nagainst congestion on the communication path. The default\noption is for end hosts to send their traffic using the EPIC\ntraffic class directly to a border router of their AS, where they\nare forwarded along the path using best-effort. This option\nis useful for non-latency-critical communication such as file\ndownloads, or for long-term traffic for which no reservation\nis available, which can for example happen if the end host has\nalready created a large number of reservations and gets denied\nfrom creating even more. Z-Lane envisages unauthenticated\nSCION traffic to be sent only in scenarios where it is not\notherwise possible, e.g., if an AS needs to request shared keys\nusing DRKey from another AS for the first time.\n4.4 Z-Lane Gateway\nASes use the gateway to control the traffic volumes that their\nend hosts (incl. AS infrastructure services) are allowed to send\nusing Z-Lane, which serves the primary purpose of protecting\nbenign from malicious or compromised end hosts.\nFor end host traffic complying with the allowed rate, the\ngateway sets a QoS flag in the EPIC header, which indicates\nto on-path routers that the corresponding packets should be\nforwarded using the AS’ guaranteed rate. If an end host’s\npacket exceeds the allowed rate at the gateway, then either (i)\nthe QoS flag is not set (or removed, if it was already set by the\nend host), meaning that those packets will be treated as best-\neffort, or (ii) the packets are dropped, depending on the AS’\npolicy. In contrast to best-effort EPIC packets generated at\n5\n</content>',
9 'Research paper setup description section detailing the specific SCIONLab configuration, including AS creation, attachment to ETHZ-AP, and VM setup. Lists and describes SCION applications crucial the experiments: \'scion address\', \'scion showpaths\', \'scion ping\', \'scion traceroute\', and \'scion-bwtestclient\', including their options and parameters(like packet size, bandwidth target) for performance evaluation on the network.\n<citation> Antonio Battipaglia et al.. "Evaluation of SCION for User-driven Path Control: a Usability Study." *Proceedings of the SC \'23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis*, 2023. </citation>\n<type> research paper </type>\n<page> 3 </page>\n<content>\nEvaluation of SCION for User-driven Path Control: a Usability Study SC-W 2023, November 12–17, 2023, Denver, CO, USA\nFigure 1: SCIONLab Topology: in light orange there are Core ASes; Non-Core ASes are white colored; Attachment Points are\ngreen; our AS is blue.\nhelp us run specific experiments we will discuss in later sections.\nOnce this configuration phase was completed, SCIONLab web inter-\nface provided a unique ASN for our AS, along with cryptographic\nkeys and public-key certificates. Subsequently, a Vagrant file for\nour AS was generated to instruct the configuration of a Virtual\nMachine (VM) that represents our AS. This file made the setup\nprocess lightweight by automating the installation of SCIONLAB\nservices, relevant packages, and necessary configurations. Finally\nwe were ready to use a fully configured VM belonging to the global\nSCIONLab topology.\n3.3 Available Applications\nThe VM configuration process also installs a predefined set of\nSCION applications. The SCION apps that we used in our experi-\nments are:\n• scion address : this command returns the relevant SCION\naddress information for the local host, that is, our AS where\nwe launch commands from.\n• scion showpaths : it lists available paths between the local\nand the specified AS. By default, the list is set to display 10\npaths only, it can be extended using the-moption. Moreover,\na really useful feature for this work, is the—extendedoption,\nwhich provides additional information for each path (e.g.\nMTU, Path Status, Latency info).\n• scion ping : it tests connectivity to a remote SCION host\nusing SCMP echo packets[4]. When the —countoption is en-\nabled, the ping command sends a specific number of SCMP\necho packets and provides a report with corresponding statis-\ntics. Furthermore, the real innovation is the —interactive\nmode option, which displays all the available paths for the\nspecified destination allowing the user to select the desired\ntraffic route.\n• scion traceroute : it traces the SCION path to a remote\nAS using SCMP traceroute packets. It is particularly useful\nto test how the latency is affected by each link. Even this\ncommand makes interactive mode available.\n• scion-bwtestclient: it is the only application presented\nin this work that is not installed by default in the VM.\nBwtestclientis part of a bigger bandwidth testing applica-\ntion named bwtesterwhich allows a variety of bandwidth\ntests on the SCION network. The application enables speci-\nfication of the test duration (up to 10 seconds), the packet\nsize to be used (at least 4 bytes), the total number of packets\nthat will be sent, and the target bandwidth. For example,\n5,100,?,150Mbps specifies that the packet size is 100 bytes,\nsent over 5 seconds, resulting in a bandwidth of 150Mbps.\nThe question mark ? character can be used as wildcard for\nany of these parameters, in this case the number of packets\nsent. Its value is then computed according to the other pa-\nrameters. The parameters for the test in the client-to-server\ndirection are specified with -cs, and the server-to-client\ndirection with -sc.\nWe will analyze further these scion commands and how we used\nthem in the next section.\n4 SOFTWARE DESIGN\nWe now present our software to test SCION features of path aware-\nness and path selection. We will also test network performances\nsuch as: latency, bandwidth and packet loss in order to provide\nUPIN users with paths that fulfill requirements on these properties.\n787\n</content>',
10]
11embeddings = model.encode(sentences)
12print(embeddings.shape)
13# [3, 384]
14
15# Get the similarity scores for the embeddings
16similarities = model.similarity(embeddings, embeddings)
17print(similarities.shape)
18# [3, 3]
