Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks
Paper • 1908.10084 • Published • 16
How to use tjohn327/scion-snowflake-arctic-embed-s-v2 with sentence-transformers:
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("tjohn327/scion-snowflake-arctic-embed-s-v2")
sentences = [
"What are \"Authoritative ASes\" and their roles relate to TRC?",
"Research paper detailing the architecture and implementation of a P4-based SCION border router. Explains SCION's ISD and PCFS concepts in Section 2.1 and how routers use hop fields (HFs) with IFIDs for forwarding. Introduces a modular design with a \"bridge header,\" separating cryptographic validation from forwarding, addressing Tofino's lack of native cryptographic support. Presents two configurations 1BR+2AES using three pipelines, and 1BR+1AES using only two by recirculating packets, details how AES implementation is deployed and that key expansion is done in the control plane.\n<citation> Lars-Christian Schulz et al.. \"Cryptographic Path Validation for SCION in P4.\" *Proceedings of the 6th on European P4 Workshop*, 2023. </citation>\n<type> research paper </type>\n<page> 2 </page>\n<content>\nEuroP4 ’23, December 8, 2023, Paris, France Lars-Christian Schulz, Robin Wehner, and David Hausheer\ncompare it to other existing implementations. Finally, we conclude\nthis paper and give a brief outlook on future work.\n2 BACKGROUND\nIn this section, we briefly describe the architecture of the SCION\nInternet and the Intel Tofino 2 switch.\n2.1 SCION\nSCION is a path-aware Internet protocol. It introduces Isolation\nDomains (ISDs) as groups of ASes sharing a common jurisdiction.\nSCION is path-aware, i.e., end hosts can choose from available\nforwarding paths and encode the desired one in the SCION header\nas what is known as packet-carried forwarding state (PCFS). Hence,\nthe SCION data plane does not rely on longest prefix matching to\ndetermine the next hop router. Instead, SCION routers examine\nthe hop fields (HF) in the SCION header which directly encode the\nAS-level path by means of interface IDs (IFIDs).\nEach AS can uniquely map its IFIDs to a neighbor and even a cer-\ntain link in case there are multiple links to this neighbor. Together\nwith the source AS, the chain of ingress and egress IFIDs uniquely\ndescribes a SCION path. The hop fields are cryptographically signed\nby the AS corresponding to the hop with an AES-CMAC truncated\nto 6 bytes. To avoid forgery of HFs, SCION border routers must\ncheck the CMAC of every HF they use to make a forwarding deci-\nsion. Packets with invalid HFs should be dropped. In most cases, a\nHF corresponds to a specific border router, requiring each of them\nto only validate a single HF. Hop fields are grouped into segments\nresulting in a special case where a border router has to check two\nHFs when the path switches from one segment to another and the\nAS ingress and egress router happen to be the same device.\nThe AES-CMAC is calculated over a 128 bit pseudo-header. As\nthis matches up with the block size of the AES cipher, a single round\nof AES encryption is sufficient to generate the authentication tag,\nexcluding the subkey derivation AES-CMAC calls for. A precise de-\nscription of the AES-CMAC algorithm is available in the correspond-\ning RFC [15]. AES-128 is widely supported in commodity server\nhardware, making HF checks much faster than lookups in Internet-\nscale IP routing tables [3]. However, the switching ASICs used in\nhardware routers designed over decades to efficiently forward IP\ntraffic do not include AES in their forwarding logic. Fortunately, re-\ncent P4-programmable switches have sufficient match-action stages\nto implement AES in standard P4 [4].\nFor more information on SCION we refer to the corresponding\nliterature [3, 5, 19].\n2.2 Tofino Architecture\nWe develop our SCION border router for Intel Tofino 2 switches.\nThe P4 programmable Tofino architecture is an embodiment of the\nProtocol Independent Switching Architecture (PISA) data plane\nmodel. PISA switches contain three major types of programmable\ncomponents: parsers, deparsers, and match-action units (MAUs). In\nthe Tofino architecture, switch pipes consist of an in- and an egress\npipeline each containing its own parser, MAUs and deparser [18].\nEach switch pipe is hardwired to a set of, in case of Tofino 2, 8x\n400G Ethernet ports [1].\nThe number of operations that can be performed per pipeline\nis limited. If a program exhausts the resources of one pipeline, the\nprogrammer can recirculate packets in order to process them itera-\ntively. If a packet is diverted to a different pipeline and recirculated\nthere, there is the option to process the same packet sequentially\nwith different P4 programs as each pipeline can be programmed\nindependently. This is the key to fit the SCION border router in a\nTofino 2 switch as described in Section 5.1.\n3 RELATED WORK\nThe SCION reference border router is implemented in Go [2] and\nuses regular IP/UDP sockets for packet I/O. Although being multi-\nthreaded, the reference border router is not suitable for high traffic\nvolume. Schulz et al. have proposed a BPF implementation of SCION\npacket forwarding [14] which achieves a throughput of 0.676 Mpps\nper core within a virtual machine test environment. However, the\nBPF data path has not been integrated in the reference border router\nyet. A commercial DPDK-based SCION router software is available\nfrom Anapaya Systems [17], but to our knowledge no production-\nready SCION routers exist in hardware.\nThe first attempt at a hardware implementation of SCION was\nmade by Součková, targeting a NetFPGA SUME development board\nprogrammable in P4 [16]. The full 10 Gbit/s line rate of the devel-\nopment platform has been achieved in experiments. However, the\nSCION packet parser and cryptographic validation circuitry did not\nfit in the FPGA at the same time due to inefficient workarounds\nthat had to be taken to handle SCION’s non-standard header layout.\nNevertheless, the project led to improvements to SCION’s header\nlayout making it more suitable for high-speed processing.\nA first implementation of SCION for Tofino 1 was presented by\nde Ruiter et al. [7] being capable of processing packets at 100 Gbit/s\nline rate. However, as Tofino does not support cryptographic opera-\ntions in hardware, the AES-CMAC hop field validation in de Ruiter’s\napproach relies on a pre-populated table of valid hop fields. This\nsimplification works as current SCION deployments change valida-\ntion keys infrequently. An unfortunate consequence of this design\nis that the SCION router is no longer stateless and instead has to\ncommunicate with the path discovery and registration services of\nthe AS to obtain valid hop fields. Furthermore, the lookup-table\nsolution also prevents the deployment of the SCION extensions\nEPIC [\n11] and Colibri [ 9] which rely on MACs that do not just\nchange per-path, but per-packet. Nevertheless, the P4 code pub-\nlished by de Ruiter et al. inspired our work and is incorporated in\nour implementation.\nChen has shown that it is possible to implement an AES encryp-\ntion in a Tofino 1 switch using so called scrambled lookup tables [4].\nTheir implementation was limited to an encryption throughput of\n10.92 Gbit/s due to limited recirculation capacity.\nOur work addresses the issues encountered by Součková and de\nRuiter et al. We implement the SCION packet parsing and validation\nlogic separately in different pipelines of a Tofino 2 switch in order\nto bridge the gap between SCION’s requirements and achieving\nline-rate throughput. We furthermore develop an approach to AES\nin P4 that takes full advantage of the resources provided by Tofino 2\nrealizing the first 400G line-rate packet validator for SCION.\n18\n</content>",
"Book excerpt providing an overview of LightningFilter operation. It keeps AS-level aggregates and stores long-term traffic profiles for traffic shaping. Describes a process for rate-limiting based on these, and prediction to account for recent traffic. Emphasizes prevention of source address spoofing and replay attacks using DRKey(§3.2) , SPAO(§3.3), and replay suppression modules. Differentiates authenticated traffic vs. best-effort approach pipelines.\n<citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. </citation>\n<type> book </type>\n<page> 229 </page>\n<content>\n9.2 High-Speed Traffic Filtering with LightningFilter\n9.2.1.2 Design Goals\nLightningFilter is designed to achieve the following objectives:\n• Guaranteed access for legitimate users within traffic profile: The\nsystem must ensure that a client in a non-compromised domain (i.e., a\ndomain without an adversary) has a guarantee to reach a target domain\neven in the presence of adversaries in other domains. We define a traffic\nprofile as a sequence of measurements over a specific period of time\n(profiling window) on a per-flow basis (flow count). As long as the traffic\nof a flow is within such a traffic profile, its packets are guaranteed to be\nprocessed.4\n• Enabling traditional firewalls to filter packets using metadata: The\nsystem should enable traditional firewalls to employ meaningful rule-\nbased packet filtering using packet metadata (such as the 5-tuple in the\npacket header). Without LightningFilter, these filtering rules can be cir-\ncumvented by spoofing attacks due to the lack of authentication.\n• Elimination of collateral damage across domains: The system should\nguarantee that compromised domains cannot introduce collateral dam-\nage on non-compromised domains by consuming all available resources.\nLegitimate clients within a compromised domain, however, may be af-\nfected by an adversary consuming excessive resources at a target domain.\nThis provides an incentive for domain owners to eliminate attack traffic\nsent by their end hosts.\n• Non-goal: Guaranteed traffic delivery to the domain is not a goal of this\nsystem, but can be achieved by a complementary system in SCION.\n9.2.2 Overview of LightningFilter\nConsidering our threat model, the adversary’s goal is to consume all available\nprocessing resources to prevent legitimate clients from reaching a target ser-\nvice, e.g., by sending an excessive number of requests. To prevent a single en-\ntity from achieving this goal, the available processing resources should be sub-\ndivided and distributed among all clients. However, allocating an equal share\nof resources to each entity inhibits high utilization and potentially punishes\nbenign traffic. As a consequence, researchers have suggested the use of more\ndynamic approaches, such as history-based filtering [ 213, 407] or binning of\nrequests [ 470]. The potentially huge number of clients poses a challenge to\nthe former approaches, as storing a traffic history (e.g., packet counters) per\nclient is impractical. Instead, we propose to aggregate and store traffic profiles\nat the level of domains, i.e., ASes. These traffic profiles denote a sequence\n4The replay-suppression system causes a negligible number of packets to be dropped due to\nfalse positives; however, end hosts must be able to handle packet loss anyway.\n209\n</content>",
"Technical document on SCION CP-PKI trust model and terminology specification. Defines terms like base TRC, TRC signing ceremony, TRC update (regular/sensitive), voting ASes, voting quorum, grace period, trust reset. Explains SCION's trust model with Isolation Domains addressing limitations of monopoly/oligopoly PKI models. Mentions trust agility/resilience, multilateral governance, policy versioning, and lack of IP prefix origin validation by design in contrast to RPKI.\n<url> https://www.ietf.org/archive/id/draft-dekater-scion-pki-08.txt </url>\n<type> specification </type>\n<content>\nde Kater, et al. Expires 3 July 2025 [Page 5]\n\f\nInternet-Draft SCION CP-PKI December 2024\n\n\n *Authoritative AS*: Authoritative ASes are those ASes in an ISD that\n always have the latest TRCs of the ISD. As a consequence,\n authoritative ASes also start the announcement of a TRC update.\n\n *Base TRC*: A base TRC is a trust root configuration (TRC) that other\n parties trust axiomatically. In other words, trust for a base TRC is\n assumed, not derived from another cryptographic object. Each ISD\n MUST create and sign a base TRC when the ISD is established. A base\n TRC is either the first TRC of the ISD or the result of a trust\n reset.\n\n *TRC Signing Ceremony*: The ceremony during which the very first base\n TRC of an ISD, called the initial TRC, is signed. The initial TRC is\n a special case of the base TRC where the number of the ISD is\n assigned.\n\n *TRC Update*: A _regular_ TRC update is a periodic re-issuance of the\n TRC where the entities and policies listed in the TRC remain\n unchanged. A _sensitive_ TRC update is an update that modifies\n critical aspects of the TRC, such as the set of core ASes. In both\n cases, the base TRC remains unchanged.\n\n *Voting ASes*: Those ASes within an ISD that may sign TRC updates.\n The process of appending a signature to a new TRC is called \"casting\n a vote\".\n\n *Voting Quorum*: The voting quorum is a trust root configuration\n (TRC) field that indicates the number of votes (signatures) needed on\n a successor TRC for it to be verifiable. A voting quorum greater\n than one will thus prevent a single entity from creating a malicious\n TRC update.\n\n *Grace Period*: The grace period is an interval during which the\n previous version of a trust root configuration (TRC) is still\n considered active after a new version has been published.\n\n *Trust Reset*: A trust reset is the action of announcing a new base\n TRC for an existing ISD. A trust reset SHOULD only be triggered\n after a catastrophic event involving the loss or compromise of\n several important private keys.\n\n1.2. Conventions and Definitions\n\n The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\",\n \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\", \"MAY\", and\n \"OPTIONAL\" in this document are to be interpreted as described in\n BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all\n capitals, as shown here.de Kater, et al. Expires 3 July 2025 [Page 6]\n\f\nInternet-Draft SCION CP-PKI December 2024\n\n\n1.3. Trust Model\n\n Given the diverse nature of the constituents in the current Internet,\n an important challenge is how to scale authentication of network\n elements (such as AS ownership, hop-by-hop routing information, name\n servers for DNS, and domains for TLS) to the global environment. The\n roots of trust of currently prevalent public key infrastructure (PKI)\n models do not scale well to a global environment because (1) mutually\n distrustful parties cannot agree on a single trust root (monopoly\n model), and because (2) the security of a plethora of roots of trust\n is only as strong as its weakest link (oligopoly model) - see also\n [BARRERA17].\n\n The monopoly model suffers from two main drawbacks: First, all\n parties must agree on a single root of trust. Secondly, the single\n root of trust represents a single point of failure, the misuse of\n which enables the forging of certificates. Its revocation can also\n result in a kill switch for all the entities it certifies.\n\n The oligopoly model relies on several roots of trust, all equally and\n completely trusted. However, this is not automatically better:\n whereas the monopoly model has a single point of failure, the\n oligopoly model has the drawback of exposing more than one point of\n failure.\n\n Thus, there is a need for a trust architecture that supports\n meaningful trust roots in a global environment with inherently\n distrustful parties. This new trust architecture should provide the\n following properties:\n\n * Trust agility (see further below);\n\n * Resilience to single root of trust compromise;\n\n * Multilateral governance; and\n\n * Support for policy versioning and updates.\n\n Ideally, the trust architecture allows parties that mutually trust\n each other to form their own trust \"union\" or \"domain\", and to freely\n decide whether to trust other trust unions (domains) outside their\n own trust bubble.\n</content>"
]
embeddings = model.encode(sentences)
similarities = model.similarity(embeddings, embeddings)
print(similarities.shape)
# [4, 4]This is a sentence-transformers model finetuned from Snowflake/snowflake-arctic-embed-s. It maps sentences & paragraphs to a 384-dimensional dense vector space and can be used for semantic textual similarity, semantic search, paraphrase mining, text classification, clustering, and more.
SentenceTransformer(
(0): Transformer({'max_seq_length': 512, 'do_lower_case': False}) with Transformer model: BertModel
(1): Pooling({'word_embedding_dimension': 384, 'pooling_mode_cls_token': True, 'pooling_mode_mean_tokens': False, 'pooling_mode_max_tokens': False, 'pooling_mode_mean_sqrt_len_tokens': False, 'pooling_mode_weightedmean_tokens': False, 'pooling_mode_lasttoken': False, 'include_prompt': True})
(2): Normalize()
)
First install the Sentence Transformers library:
pip install -U sentence-transformers
Then you can load this model and run inference.
from sentence_transformers import SentenceTransformer
# Download from the 🤗 Hub
model = SentenceTransformer("tjohn327/scion-snowflake-arctic-embed-s-v2")
# Run inference
sentences = [
'How is the concept of configurable rates in Z-Lane intended to accommodate varying traffic demands',
'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>',
'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>',
]
embeddings = model.encode(sentences)
print(embeddings.shape)
# [3, 384]
# Get the similarity scores for the embeddings
similarities = model.similarity(embeddings, embeddings)
print(similarities.shape)
# [3, 3]
val-ir-evalInformationRetrievalEvaluator| Metric | Value |
|---|---|
| cosine_accuracy@1 | 0.7255 |
| cosine_accuracy@3 | 0.902 |
| cosine_accuracy@5 | 0.9314 |
| cosine_accuracy@10 | 0.9608 |
| cosine_precision@1 | 0.7255 |
| cosine_precision@3 | 0.3007 |
| cosine_precision@5 | 0.1863 |
| cosine_precision@10 | 0.0961 |
| cosine_recall@1 | 0.7255 |
| cosine_recall@3 | 0.902 |
| cosine_recall@5 | 0.9314 |
| cosine_recall@10 | 0.9608 |
| cosine_ndcg@10 | 0.8542 |
| cosine_mrr@10 | 0.8188 |
| cosine_map@100 | 0.8212 |
sentence_0 and sentence_1| sentence_0 | sentence_1 | |
|---|---|---|
| type | string | string |
| details |
|
|
| sentence_0 | sentence_1 |
|---|---|
What are the two scenarios for LightningFilter deployment depending on the level of trust with the AS |
Book chapter detailing SCION LightningFilter's packet authentication using DRKey. Describes key derivation using PRF with AS-level (KLF_A->B) and host-level (KLF_A:HA->B:HB) keys. Explains two deployment scenarios: trusted entity with direct access to SVLF_A and less-trusted entity fetching second-level keys. Covers header and payload authentication using SPAO, MAC computation with symmetric key (tag = MAC{KLF_A:HA->B:HB}(hdr)), and payload hash (h = H(pld)). |
How do preferences, such as customer, peering link, or transit provider, are expressed in BGP? |
Book excerpt on Approaches to Implementing Path Policies and Gao–Rexford Model describing how ASes add path policy information to PCBs, specifying usage restrictions. Highlights accountability for violating AS, explain the need of a default, arbitrary path. Explains the "preference policy" for economics and "export policy" for stability. |
What is the structure of a complete SCION address? ,How is intra-domain forwarding handled at the destination AS? |
Technical document describing inter- and intra-domain forwarding in SCION. Explains the separation of inter-domain (SCION-based) and intra-domain (AS-specific, often IP-based) forwarding. SCION routers forward based on Hop Fields and need not inspect destination IP address. Includes advantages like path control and simplified processing. |
MultipleNegativesRankingLoss with these parameters:{
"scale": 20.0,
"similarity_fct": "cos_sim"
}
eval_strategy: stepsper_device_train_batch_size: 50per_device_eval_batch_size: 50num_train_epochs: 5multi_dataset_batch_sampler: round_robinoverwrite_output_dir: Falsedo_predict: Falseeval_strategy: stepsprediction_loss_only: Trueper_device_train_batch_size: 50per_device_eval_batch_size: 50per_gpu_train_batch_size: Noneper_gpu_eval_batch_size: Nonegradient_accumulation_steps: 1eval_accumulation_steps: Nonetorch_empty_cache_steps: Nonelearning_rate: 5e-05weight_decay: 0.0adam_beta1: 0.9adam_beta2: 0.999adam_epsilon: 1e-08max_grad_norm: 1num_train_epochs: 5max_steps: -1lr_scheduler_type: linearlr_scheduler_kwargs: {}warmup_ratio: 0.0warmup_steps: 0log_level: passivelog_level_replica: warninglog_on_each_node: Truelogging_nan_inf_filter: Truesave_safetensors: Truesave_on_each_node: Falsesave_only_model: Falserestore_callback_states_from_checkpoint: Falseno_cuda: Falseuse_cpu: Falseuse_mps_device: Falseseed: 42data_seed: Nonejit_mode_eval: Falseuse_ipex: Falsebf16: Falsefp16: Falsefp16_opt_level: O1half_precision_backend: autobf16_full_eval: Falsefp16_full_eval: Falsetf32: Nonelocal_rank: 0ddp_backend: Nonetpu_num_cores: Nonetpu_metrics_debug: Falsedebug: []dataloader_drop_last: Falsedataloader_num_workers: 0dataloader_prefetch_factor: Nonepast_index: -1disable_tqdm: Falseremove_unused_columns: Truelabel_names: Noneload_best_model_at_end: Falseignore_data_skip: Falsefsdp: []fsdp_min_num_params: 0fsdp_config: {'min_num_params': 0, 'xla': False, 'xla_fsdp_v2': False, 'xla_fsdp_grad_ckpt': False}fsdp_transformer_layer_cls_to_wrap: Noneaccelerator_config: {'split_batches': False, 'dispatch_batches': None, 'even_batches': True, 'use_seedable_sampler': True, 'non_blocking': False, 'gradient_accumulation_kwargs': None}deepspeed: Nonelabel_smoothing_factor: 0.0optim: adamw_torchoptim_args: Noneadafactor: Falsegroup_by_length: Falselength_column_name: lengthddp_find_unused_parameters: Noneddp_bucket_cap_mb: Noneddp_broadcast_buffers: Falsedataloader_pin_memory: Truedataloader_persistent_workers: Falseskip_memory_metrics: Trueuse_legacy_prediction_loop: Falsepush_to_hub: Falseresume_from_checkpoint: Nonehub_model_id: Nonehub_strategy: every_savehub_private_repo: Nonehub_always_push: Falsegradient_checkpointing: Falsegradient_checkpointing_kwargs: Noneinclude_inputs_for_metrics: Falseinclude_for_metrics: []eval_do_concat_batches: Truefp16_backend: autopush_to_hub_model_id: Nonepush_to_hub_organization: Nonemp_parameters: auto_find_batch_size: Falsefull_determinism: Falsetorchdynamo: Noneray_scope: lastddp_timeout: 1800torch_compile: Falsetorch_compile_backend: Nonetorch_compile_mode: Nonedispatch_batches: Nonesplit_batches: Noneinclude_tokens_per_second: Falseinclude_num_input_tokens_seen: Falseneftune_noise_alpha: Noneoptim_target_modules: Nonebatch_eval_metrics: Falseeval_on_start: Falseuse_liger_kernel: Falseeval_use_gather_object: Falseaverage_tokens_across_devices: Falseprompts: Nonebatch_sampler: batch_samplermulti_dataset_batch_sampler: round_robin| Epoch | Step | val-ir-eval_cosine_ndcg@10 |
|---|---|---|
| 1.0 | 44 | 0.7533 |
| 2.0 | 88 | 0.8088 |
| 3.0 | 132 | 0.8296 |
| 4.0 | 176 | 0.8326 |
| 5.0 | 220 | 0.8542 |
@inproceedings{reimers-2019-sentence-bert,
title = "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks",
author = "Reimers, Nils and Gurevych, Iryna",
booktitle = "Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing",
month = "11",
year = "2019",
publisher = "Association for Computational Linguistics",
url = "https://arxiv.org/abs/1908.10084",
}
@misc{henderson2017efficient,
title={Efficient Natural Language Response Suggestion for Smart Reply},
author={Matthew Henderson and Rami Al-Rfou and Brian Strope and Yun-hsuan Sung and Laszlo Lukacs and Ruiqi Guo and Sanjiv Kumar and Balint Miklos and Ray Kurzweil},
year={2017},
eprint={1705.00652},
archivePrefix={arXiv},
primaryClass={cs.CL}
}
Base model
Snowflake/snowflake-arctic-embed-s