Add new SentenceTransformer model

1_Pooling/config.json

@@ -0,0 +1,10 @@
+{
+  "word_embedding_dimension": 384,
+  "pooling_mode_cls_token": false,
+  "pooling_mode_mean_tokens": true,
+  "pooling_mode_max_tokens": false,
+  "pooling_mode_mean_sqrt_len_tokens": false,
+  "pooling_mode_weightedmean_tokens": false,
+  "pooling_mode_lasttoken": false,
+  "include_prompt": true
+}

README.md

@@ -0,0 +1,2016 @@
+---
+tags:
+- sentence-transformers
+- sentence-similarity
+- feature-extraction
+- generated_from_trainer
+- dataset_size:23200
+- loss:MultipleNegativesRankingLoss
+base_model: sentence-transformers/all-MiniLM-L6-v2
+widget:
+- source_sentence: 'query: Why is historical data important for an AS when deciding
+    which SegRs to request?'
+  sentences:
+  - "passage:\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> 264 </page>\n<content>\n\
+    10 Extensions for the Data Plane\nAS X\n AS YAS S AS Z\nC\nSegR Y-Z\n1 2\n33 C\
+    \ C4 C\n2\n(a) Segment reservation setup.\nAS X\n AS YAS S AS Z\nC\nSegR Y-Z\n\
+    3 3\n44\nG SegR S-Y\nC\n3\n4 C\n352\n1 C\n(b) End-to-end reservation setup.\n\
+    AS X\n AS YAS S AS Z\n3\n4\n3 3\n4 4\n2\n1 G M M M\nBorder Router\n(c) Use of\
+    \ the end-to-end reservation.\nFigure 10.4: Overview of the COLIBRI system. C\
+    \ are CServs, G is the\nCOLIBRI gateway, the yellow-orange circles are border\
+    \ routers,\nand M are traffic monitors. A description is provided in Sec-\ntions\
+    \ 10.2.3.3 and 10.2.3.4.\nSegRs are always initiated by the first AS on the segment.\
+    \ For down-SegRs,\nthe first AS only sets up a SegR upon an explicit request by\
+    \ the last AS.\nAn AS can decide which SegRs to request based on historical data\
+    \ or traf-\nfic predictions. It selects segments generated by the SCION control\
+    \ plane and\nsends a SegR request ( 1 in Figure 10.4a) specifying requirements\
+    \ for the reser-\nvation such as requested minimum bandwidth. Each AS on the segment\
+    \ can\ncalculate how much bandwidth can be granted; if this is higher than the\
+    \ re-\nquested minimum, it records this reservation locally. It then updates the\
+    \ re-\nquest with the granted amount of bandwidth and forwards it to the next\
+    \ AS\non the segment ( 2 in Figure 10.4a). The last AS sends a reply via the same\n\
+    segment to the request initiator ( 3 in Figure 10.4a).\nIf the request was successful\
+    \ (each AS granted more than the minimum\namount of bandwidth), each AS locally\
+    \ stores the final amount of bandwidth\ngranted and includes a cryptographic token\
+    \ in the response that allows the re-\nquest initiator to use the segment for\
+    \ COLIBRI traffic ( 4 in Figure 10.4a; see\n§10.2.4.6 for details). In case of\
+    \ an unsuccessful request, the ASes clean up\ntheir temporary reservations and\
+    \ the initiator can determine the location of po-\n244\n</content>"
+  - "passage:\n<url> https://github.com/netsec-ethz/scion-apps/blob/master/webapp/README.md\
+    \ </url>\n<type> code </type>\n<content>\nWebapp AS Visualization\n=========================\n\
+    \nMore installation and usage information is available on the [SCION Tutorials\
+    \ web page for webapp](https://netsec-ethz.github.io/scion-tutorials/as_visualization/webapp/).\n\
+    \n# Webapp\nWebapp is a Go application that will serve up a static web portal\
+    \ to make it easy to visualize and experiment with SCIONLab test apps on a virtual\
+    \ machine.\n\n\n## Packaged Setup/Run\nFor running `webapp` in a packaged environment,\
+    \ like the default [SCIONLab](https://www.scionlab.org) environment, it now uses\
+    \ command-line options for `webapp` to find the tools it requires.\n\nTo install\
+    \ from our packages, install `webapp` including its `scion-apps` dependencies:\n\
+    ```shell\nsudo apt install scion-apps-webapp\n```\nAlternatively, the following\
+    \ will install all `scion-apps` binaries:\n```shell\nsudo apt install scion-apps-*\n\
+    ```\n\nStart the `webapp` service:\n```shell\nsudo systemctl start scion-webapp\n\
+    ```\n\nEnsure the `webapp` service is running:\n```shell\nsudo systemctl status\
+    \ scion-webapp\n```\n\nNow, open a web browser at [http://127.0.0.1:8000](http://127.0.0.1:8000),\
+    \ to begin.\n\nLogs from `webapp` can be monitored:\n```shell\njournalctl -u scion-webapp\
+    \ -e\n```\n\nYou won't need to add all the parameters yourself as the `scion-webapp.service`\
+    \ will do this for you. You may view the service command line options used with\
+    \ `cat`:\n```shell\nsystemctl cat scion-webapp\n```\n\n\n## Development Setup/Run\n\
+    For maintenance of `webapp` details of its structure and operation can be found\
+    \ at [development.md](./development.md).\n\nFor running `webapp` in a development\
+    \ environment for the SCION Infrastructure, follow the SCIONLab development install\
+    \ and run process at [https://github.com/netsec-ethz/scion](https://github.com/netsec-ethz/netsec-scion).\n\
+    \nThen, follow these steps to install SCIONLab Apps to run `webapp` in development.\n\
+    \nDevelopment Install:\n```shell\nmkdir ~/go/src/github.com/netsec-ethz\ncd ~/go/src/github.com/netsec-ethz\n\
+    git clone https://github.com/netsec-ethz/scion-apps.git\n```\n\nDevelopment Build:\n\
+    Install all [SCIONLab apps](https://github.com/netsec-ethz/scion-apps) and dependencies,\
+    \ including `webapp`:\n```shell\ncd scion-apps\n./deps.sh\nmake build\n```\n\n\
+    Development Run on ScionLab Topology:\nYou can alter the defaults on the command\
+    \ line, all of which are listed below:\n```shell\n./bin/scion-webapp \\\n-a 127.0.0.1\
+    \ \\\n-p 8000 \\\n-r $GOPATH/src/github.com/netsec-ethz/scion-apps/webapp/web/data\
+    \ \\\n-srvroot $GOPATH/src/github.com/netsec-ethz/scion-apps/webapp/web \\\n-sgen\
+    \ /etc/scion \\\n-sgenc /var/lib/scion \n```\nor can you run `webapp` like this,\
+    \ which will use the defaults above:\n```shell\n./bin/scion-webapp\n```\n\nDevelopment\
+    \ Run on Local Topology:\n```shell\n./bin/scion-webapp \\\n-a 127.0.0.1 \\\n-p\
+    \ 8080 \\\n-r $GOPATH/src/github.com/netsec-ethz/scion-apps/webapp/web/data \\\
+    \n-srvroot $GOPATH/src/github.com/netsec-ethz/scion-apps/webapp/web \\\n-sgen\
+    \ $HOME/scion/gen \\\n-sgenc  $HOME/scion/gen-cache\n```\n\n## Dependencies\n\
+    A list of dependencies for `webapp` can be found at [dependencies.md](./dependencies.md).\n\
+    \n## Help\n```shell\nUsage of webapp:\n  -a string\n        Address of server\
+    \ host. (default \"127.0.0.1\")\n  -p int\n        Port of server host. (default\
+    \ 8000)\n  -r string\n        Root path to read/browse from, CAUTION: read-access\
+    \ granted from -a and -p. (default \"$GOPATH/src/github.com/netsec-ethz/scion-apps/webapp\
+    \ /web/data\")\n  -sgen string\n        Path to read SCION gen directory of infrastructure\
+    \ config (default \"/etc/scion\")\n  -sgenc string\n        Path to read SCION\
+    \ gen-cache directory of infrastructure run-time config (default \"/var/lib/scion\"\
+    )\n  -srvroot string\n        Path to read/write web server files. (default \"\
+    $GOPATH/src/github.com/netsec-ethz/scion-apps/webapp/web\")\n```\n\n## Related\
+    \ Links\n* [Webapp SCIONLab AS Visualization Tutorials](https://netsec-ethz.github.io/scion-tutorials/as_visualization/webapp/)\n\
+    * [Webapp SCIONLab Apps Visualization](https://netsec-ethz.github.io/scion-tutorials/as_visualization/webapp_apps/)\n\
+    * [Webapp Development Tips](https://netsec-ethz.github.io/scion-tutorials/as_visualization/webapp_development/)\n\
+    \n</content>"
+  - 'passage:
+
+    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
+    to Formal Verification*. Springer International Publishing AG, 2022. </citation>
+
+    <type> book </type>
+
+    <page> 455 </page>
+
+    <content>
+
+    19.1 Background
+
+    DNSSEC was proposed to address this very problem. In brief, it allows a
+
+    zone to sign its DNS records and have the signing key endorsed by the parent
+
+    zone, thus creating an authentication chain all the way up to the root zone. A
+
+    signed record can be verified by following the chain terminated at a trust an-
+
+    chor (which in most cases is the root zone key) configured by the validating
+
+    entity. This eliminates threats of data tampering and forgery that originate out-
+
+    side zone authorities.
+
+    In general, end-to-end authenticity is achievable only by having zone author-
+
+    ities themselves secure the zone data with publicly verifiable authenticators.
+
+    One may attempt a similar assurance by establishing hop-by-hop secure (in
+
+    particular, authenticated) channels between entities involved in the name res-
+
+    olution process. However, channel security alone does not imply end-to-end
+
+    security: While such a solution can foil attacks launched from the commu-
+
+    nication network, it fails to address risks arising from authoritative servers,
+
+    resolvers, and any intermediary servers pertinent to name resolution. Clients
+
+    must place trust in all these entities, instead of just the zone authority in
+    the
+
+    ideal case, to be assured of data authenticity. We thus strive for an end-to-end
+
+    guarantee, where intermediaries do not need to be trusted from an authenticity
+
+    perspective.
+
+    19.1.3 End-User Privacy
+
+    The privacy implications of DNS have received a surge of attention in the past
+
+    few years. Name-resolution messages transmitted in the clear directly leak
+
+    the websites or applications accessed by clients; even if subsequent connec-
+
+    tions are secured with TLS, the leakage from DNS is already information-rich
+
+    enough to build accurate profiles of end users.
+
+    All privacy-enhancing solutions follow the same principle of establishing
+
+    encrypted channels between entities (mostly between clients and resolvers).
+
+    Examples include DoT and DoH as well as DNSCurve, which makes use of
+
+    customized encryption methods. One caveat to these solutions is that they pro-
+
+    tect data confidentiality against eavesdropping on the communication links but
+
+    not the entities themselves; countermeasures to further address this concern are
+
+    also emerging, e.g., Oblivious DNS (ODNS) [ 459], and they typically work
+
+    by using proxy servers to break the linkage of client identities to decrypted
+
+    queries.
+
+    Regardless of the exact design, encrypting name-resolution messages is es-
+
+    sential to preserving the privacy of end users and is complementary to naming
+
+    data authentication.
+
+    19.1.4 Service Availability
+
+    Another more subtle security aspect relates to availability. DNS is designed
+
+    to be available by redundancy: Each zone is typically replicated to multiple
+
+    distributed authoritative name servers. This simple mechanism is effective in
+
+    435
+
+    </content>'
+- source_sentence: 'query: What are the constants defined in the SCION traffic engineering
+    model?'
+  sentences:
+  - "passage:\n<url> https://github.com/scionproto/scion/blob/master/doc/dev/design/ColibriService.md\
+    \ </url>\n<type> code </type>\n<content>\n# COLIBRI Service Design\n\n* Author:\
+    \ Juan A. García Pardo\n* Last updated: 2020-07-08\n* Status: **Outdated**.\n\
+    \  Prototype was developed in [netsec-ethz/scion:scionlab](https://github.com/netsec-ethz/scion/tree/scionlab)\n\
+    \  ([commit permalink](https://github.com/netsec-ethz/scion/commit/37a556a4bc494a93fe8294ed77b6f2c9b6192746)),\n\
+    \  to be replaced with new approach for QoS system.\n* Discussion at: [#3653](https://github.com/scionproto/scion/issues/3653),\
+    \ [#3794](https://github.com/scionproto/scion/issues/3794)\n\n---\n⚠️  **NOTE**\
+    \ ⚠️\n\nOutdated contents! This document is kept for historical purpose.\n\n---\n\
+    \n## Abstract\n\nThis document specifies the design of the COLIBRI service. It\
+    \ aims for correctness not completeness,\nand some parts of the design are deliberately\
+    \ not yet specified.\n\nThis document will be reviewed and amended when necessary\
+    \ as the implementation of the COLIBRI\nservice matures.\n\n## Overview\n\nThe\
+    \ COLIBRI Service (*COS*) manages the reservation process of the COLIBRI QoS subsystem\n\
+    in SCION. It handles both the segment and end to end reservations (formerly known\
+    \ as steady and\nephemeral reservations).\n\nThe border router is also modified\
+    \ so it understands COLIBRI type packets in the data plane.\n\n**This document\
+    \ doesn't include the border router design and implementation changes yet.**\n\
+    \n## Design\n\nThere are three main components that need to be modified or created:\
+    \ the colibri service itself,\nthe border router and `sciond` in the endhost:\n\
+    \n* **COS** Enables the COLIBRI control plane. Used to negotiate both segment\
+    \ and end to\n  end reservations.\n* **Border Router** Needs to forward the COLIBRI\
+    \ traffic with higher priority than best effort.\n  Needs to monitor COLIBRI traffic.\n\
+    * **sciond** Needs to expose a COLIBRI *API*. Needs to manage end to end reservations\
+    \ in behalf\n  of the applications.\n\nThe COS is structured similarly to other\
+    \ existing Go infrastructure services. It reuses the\nfollowing:\n\n* [go/lib/env](https://github.com/scionproto/scion/tree/master/go/lib/env):\n\
+    \  Is used for configuration and setup of the service.\n* [go/pkg/trust](https://github.com/scionproto/scion/tree/master/go/pkg/trust):\n\
+    \  Is used for crypto material.\n* [go/lib/infra](https://github.com/scionproto/scion/tree/master/go/lib/infra):\n\
+    \  Is used for the messenger to send and receive messages.\n* [go/lib/periodic](https://github.com/scionproto/scion/tree/master/go/lib/periodic):\n\
+    \  Is used for periodic tasks.\n\nThe COS is differentiated into these parts:\n\
+    \n* **configuration** specifying admission and reservation parameters for this\
+    \ AS,\n* **handlers** to handle incoming reservation requests (creation, tear\
+    \ down, etc.),\n* **periodic tasks** for segment reservation creation and renewal,\n\
+    * **reservation storage** for partial and committed reservations.\n\n![COS parts\
+    \ overview](fig/colibri_srv/COS.png).\n\n## Sequence Diagrams\n\n### Segment Reservations\n\
+    \nNote: we use \"forward the request\" with the following meaning: if the current\
+    \ AS is not\nthe last AS in the reservation path, send the request to the next\
+    \ AS in the reservation path.\nIf the current AS is the last one, do nothing.\n\
+    \n#### Handle a Setup Response\n\nThe response message originated from another\
+    \ AS's *COS* handling a request.\nThe request is forwarded from AS<sub>i</sub>\
+    \ to AS<sub>i+1</sub>, where AS<sub>i+1</sub> is the\nnext AS after AS<sub>i</sub>\
+    \ in the path of the reservation.\n\n1. The store saves the reservation as final.\n\
+    1. If this AS is the first one in the reservation path (aka *reservation initiator*),\n\
+    \   the store sends an index confirmation request to the next AS in the path.\n\
+    1. If this AS is the not the first one in the reservation path, the store sends\
+    \ a\n   response message to the previous AS's *COS*.\n\n#### Handle a Setup Request\n\
+    \n(the reservation message originated from another AS nearer to the origin of\
+    \ the path in the reservation)\n\n1. The *COS* store is queried to admit the segment\
+    \ reservation.\n1. The store decides the admission for the reservation (how much\
+    \ bandwidth). It uses the\n   *traffic_matrix* from the configuration package.\n\
+    1. The store saves an intermediate reservation entry in the DB.\n1. If this AS\
+    \ is the last one in the path, the *COS* store saves the reservation as final\n\
+    \   and notifies the previous AS in the path with a reservation response.\n1.\
+    \ The store forwards the request with the decided bandwidth.\n\n#### Setup a Segment\
+    \ Reservation\n\nThe configuration specifies which segment reservations should\
+    \ be created from this AS to other\nASes. Whenever that configuration changes,\
+    \ the service should be notified.\n\n1. The service triggers the creation of a\
+    \ new segment reservation at boot time and whenever\n   the segment reservation\
+    \ configuration file changes.\n1. The service reads the configuration file and\
+    \ creates a segment reservation request per each entry.\n    * The path used in\
+    \ the request must be obtained using the *path predicate* in the configuration.\n\
+    1. The store in the *COS* saves the intermediate request and sends the request\
+    \ to the next AS\n   in the path.\n1. If there is a timeout, this store will send\
+    \ a cleanup request to the next AS in the path.\n\n#### Handle an Index Confirmation\
+    \ Request\n\n1. The store in the *COS* checks that the appropriate reservation\
+    \ is already final.\n1. The store modifies the reservation to be confirmed\n1.\
+    \ The *COS* forwards the confirmation request.\n\n#### Handle a Cleanup Request\n\
+    \n1. The *COS* removes the referenced reservation from its store.\n1. The *COS*\
+    \ forwards the cleanup request.\n\n#### Handle a Teardown Request\n\n1. The *COS*\
+    \ checks the reservation is confirmed but has no allocated end to end reservations.\n\
+    1. The *COS* checks there are no telescoped reservations using this segment reservation.\n\
+    1. The store removes the reservation.\n1. The *COS* forwards the teardown request.\n\
+    \n#### Handle a Renewal Request\n\nThe renewal request handler is the same as\
+    \ the [setup request](#handle-a-setup-request).\nThe renewal is initiated differently\
+    \ (by adding a new index to an existing reservation),\nbut handled the same way.\n\
+    \n#### Renew a Segment Reservation\n\n1. The service triggers the renewal of the\
+    \ existing segment reservations with constant frequency.\n1. The store in the\
+    \ *COS* retrieves each one of the reservations that originate in this AS.\n1.\
+    \ Per reservation retrieved, the store adds a new index to it and pushes it forward.\n\
+    \n#### Handle a Reservation Query\n\n1. The store in the *COS* receives the query\
+    \ and returns the collection of segment reservations\n   matching it.\n\n### End\
+    \ to End Reservations\n\nAll end to end reservation requests should be authenticated.\n\
+    \n#### Handle a E2E Setup Request\n\n1. The *COS* queries the store to admit the\
+    \ reservation\n1. The store computes the allowed bandwidth (knowing the current\
+    \ segment reservation and\n   the existing E2E reservations in it).\n1. The store\
+    \ pushes forward the setup request.\n\n#### Handle a Renewal Request\n\nThe renewal\
+    \ request handler is the same as the [setup request](#handle-a-e2e-setup-request).\n\
+    \n#### Handle a Cleanup Request\n\n1. The *COS* removes the request from its store.\n\
+    1. The *COS* forwards the cleanup request.\n\n## Interfaces\n\nInterfaces of the\
+    \ main classes.\n\nThe Reservation Store in the COS keeps track of the reservations\
+    \ created and accepted in this AS,\nboth segment and E2E.\nThe store provides\
+    \ the following interface:\n\n```go\ntype ReservationStore {\n    GetSegmentReservation(ctx\
+    \ context.Context, id SegmentReservationID) (SegmentReservation, error)\n    GetSegmentReservations(ctx\
+    \ context.Context, validTime time.Time, path []InterfaceId]) ([]SegmentReservation,\
+    \ error)\n\n    AdmitSegmentReservation(ctx context.Context, req SegmentReservationReq)\
+    \ error\n    ConfirmSegmentReservation(ctx context.Context, id SegmentReservationID)\
+    \ error\n    CleanupSegmentReservation(ctx context.Context, id SegmentReservationID)\
+    \ error\n    TearDownSegmentReservation(ctx context.Context, id SegmentReservationID)\
+    \ error\n\n    AdmitE2EReservation(ctx context.Context, req E2EReservationReq)\
+    \ error\n    CleanupE2EReservation(ctx context.Context, id E2EReservationID) error\n\
+    }\n```\n\nThe `sciond` endhost daemon will expose the *API* that enables the use\
+    \ of COLIBRI by applications:\n\n```go\ntype sciond {\n    ...\n    AllowIPNet(ia\
+    \ IA, net IPNet) error\n    BlockIPNet(ia IA, net IPNet) error\n    WatchSegmentRsv(ctx\
+    \ context.Context, pathConf PathConfiguration) (WatchState, error)\n    WatchE2ERsv(ctx\
+    \ context.Context, resvConf E2EResvConfiguration) (WatchState, error)\n    //\
+    \ WatchRequests returns a WatchState that will notify the application of any COLIBRI\
+    \ e2e request ending here.\n    WatchRequests() (WatchState, error)\n    Unwatch(watchState\
+    \ WatchState) error\n}\n```\n\n## Class Diagrams\n\nMain classes, arity and relationships.\n\
+    \n```go\ntype InterfaceIdPair struct\n    Ingress uint64\n    Egress  uint64\n\
+    }\ntype SegmentReservationID struct {\n    Ifids   []InterfaceIdPair\n    Index\
+    \   byte\n}\n\ntype E2EReservationID uint16\n```\n\n## ReservationDB\n\nThere\
+    \ are two main parts in the DB: the segment reservation entities, and the end\
+    \ to end entities.\nTo link the end to end reservations to the appropriate segment\
+    \ ones, a table is used.\n\nThere are no restrictions of cardinality other than\
+    \ uniqueness and non null-ness for some fields,\nbut nothing like triggers on\
+    \ insertion are used. E.g. it is technically possible to link more than three\n\
+    segment reservations with a given end to end one. These cardinality restrictions\
+    \ are enforced by code.\n\n![DB entities overview](fig/colibri_srv/DB.png).\n\n\
+    Furthermore, there are some indices created to speed up lookups:\n\n* seg_reservation\n\
+    \    * id_as,suffix\n    * ingress\n    * egress\n    * path\n* seg_index\n  \
+    \  * reservation,index_number\n* e2e_reservation\n    * reservation_id\n* e2e_index\n\
+    \    * reservation,index_number\n* e2e_to_seg\n    * e2e\n    * seg\n\n</content>"
+  - 'passage:
+
+    <citation> Pascal Marc Suter. *Traffic Engineering in SCION: The impact of end
+    host QoS mechanisms on network performance*. Master''s thesis, ETH Zurich, 2023.
+    </citation>
+
+    <type> research paper </type>
+
+    <page> 75 </page>
+
+    <content>
+
+    7. F uture work
+
+    Constants
+
+    q: a queue
+
+    f : a flow
+
+    p: a possible path
+
+    fbwd: the requested bandwidth of flow f
+
+    µq: processing capacity of q
+
+    MaxLength q: maximum queue length of q
+
+    The constants are defined by the topology. Each application would be repre-
+
+    sented as a flow and every router has one processing queue and one sending
+
+    queue per outgoing link. This is analog as to how the queues are imple-
+
+    mented in the simulator. µq is the number of packets that can be processed
+
+    or the number of packets that can be sent in a time-step if q is a processing
+
+    or sending queue respectively.
+
+    Variables
+
+    TPf ,p: throughput of flow f on path p
+
+    Pf ,p: indicator variable, 1 if and only if flow f chooses path p
+
+    Lat f ,p: latency of path p of flow f
+
+    λq: throughput of queue q
+
+    Varq: variance at queue q
+
+    Lossq: probability of packet loss at queue q
+
+    Objective
+
+    min ∑
+
+    f ,p
+
+    Lat f ,p
+
+    min ∑
+
+    f ,p
+
+    Pf ,p( ∑
+
+    q∈passes ( f ,p)
+
+    Varq)
+
+    min ∑
+
+    f ,p
+
+    Pf ,p( ∑
+
+    q∈passes ( f ,p)
+
+    Lossq)
+
+    Each objective minimizes global latency, jitter, and loss respectively. They
+
+    can be weighted depending on how import one thinks each to be.
+
+    68
+
+    </content>'
+  - "passage:\n<url> https://www.ietf.org/archive/id/draft-dekater-scion-controlplane-07.txt\
+    \ </url>\n<type> specification </type>\n<content>\nNetwork Working Group     \
+    \                                   C. de Kater\nInternet-Draft              \
+    \                               N. Rustignoli\nIntended status: Informational\
+    \                         SCION Association\nExpires: 27 June 2025           \
+    \                                 S. Hitz\n                                  \
+    \                       Anapaya Systems\n                                    \
+    \                    24 December 2024\n\n\n                          SCION Control\
+    \ Plane\n                  draft-dekater-scion-controlplane-07\n\nAbstract\n\n\
+    \   This document describes the Control Plane of the path-aware, inter-\n   domain\
+    \ network architecture SCION (Scalability, Control, and\n   Isolation On Next-generation\
+    \ networks).  One of the basic\n   characteristics of SCION is that it gives path\
+    \ control to SCION-\n   capable endpoints that can choose between multiple path\
+    \ options,\n   enabling the optimization of network paths.  The Control Plane\
+    \ is\n   responsible for discovering these paths and making them available to\n\
+    \   the endpoints.\n\n   The main goal of the SCION Control Plane is to create\
+    \ and manage path\n   segments which can then be combined into forwarding paths\
+    \ to transmit\n   packets in the data plane.  This document discusses how path\n\
+    \   exploration is realized through beaconing and how path segments are\n   created\
+    \ and registered.  Each SCION Autonomous System (AS) can\n   register segments\
+    \ according to its own policy and can specify which\n   path properties and algorithm(s)\
+    \ to use in the selection procedure.\n   The document also describes the path\
+    \ lookup process whereby endpoints\n   obtain path segments - a fundamental building\
+    \ block for the\n   construction of end-to-end paths.\n\nAbout This Document\n\
+    \n   This note is to be removed before publishing as an RFC.\n\n   The latest\
+    \ revision of this draft can be found at\n   https://scionassociation.github.io/scion-cp_I-D/draft-dekater-scion-\n\
+    \   controlplane.html.  Status information for this document may be found\n  \
+    \ at https://datatracker.ietf.org/doc/draft-dekater-scion-\n   controlplane/.\n\
+    \n   Source for this draft and an issue tracker can be found at\n   https://github.com/scionassociation/scion-cp_I-D.\n\
+    </content>"
+- source_sentence: 'query: How does SCION''s architecture improve scalability?'
+  sentences:
+  - "passage:\n<url> https://www.ietf.org/archive/id/draft-dekater-scion-controlplane-07.txt\
+    \ </url>\n<type> specification </type>\n<content>\nde Kater, et al.          Expires\
+    \ 27 June 2025                 [Page 80]\n\f\nInternet-Draft                 \
+    \ SCION CP                   December 2024\n\n\n     // Segment creation time\
+    \ set by the originating AS. Segment\n     // expiration time is computed relative\
+    \ to this timestamp.\n     // The timestamp is encoded as the number of seconds\
+    \ elapsed\n     // since January 1, 1970 UTC.\n     int64 timestamp = 1;\n   \
+    \  // The 16-bit segment ID integer used for MAC computation.\n     uint32 segment_id\
+    \ = 2;\n }\n\n message ASEntry {\n     // The signed part of the AS entry. The\
+    \ body of the SignedMessage\n     // is the serialized ASEntrySignedBody. The\
+    \ signature input is\n     // defined as follows:\n     //\n     //  input(ps,\
+    \ i) = signed.header_and_body || associated_data(ps, i)\n     //\n     //  associated_data(ps,\
+    \ i) =\n     //          ps.segment_info ||\n     //          ps.as_entries[1].signed.header_and_body\
+    \ ||\n     //          ps.as_entries[1].signed.signature ||\n     //         \
+    \ ...\n     //          ps.as_entries[i-1].signed.header_and_body ||\n     //\
+    \          ps.as_entries[i-1].signed.signature\n     //\n     proto.crypto.v1.SignedMessage\
+    \ signed = 1;\n     // The unsigned part of the AS entry.\n     proto.control_plane.v1.PathSegmentUnsignedExtensions\
+    \ unsigned = 2;\n }\n\n message SignedMessage {\n     // Encoded header and body.\n\
+    \     bytes header_and_body = 1;\n     // Raw signature. The signature is computed\
+    \ over the concatenation\n     // of the header and body, and the optional associated\
+    \ data.\n     bytes signature = 2;\n }\n\n message HopEntry {\n     // Material\
+    \ to create the data-plane Hop Field.\n     HopField hop_field = 1;\n     // MTU\
+    \ on the ingress link.\n     uint32 ingress_mtu = 2;\n }\n\n message PeerEntry\
+    \ {\n     // ISD-AS of peer AS. This is used to match peering segments\n     //\
+    \ during path construction.\n     uint64 peer_isd_as = 1;de Kater, et al.    \
+    \      Expires 27 June 2025                 [Page 81]\n\f\nInternet-Draft    \
+    \              SCION CP                   December 2024\n\n\n     // Remote peer\
+    \ interface identifier. This is used to match\n     // peering segments\n    \
+    \ // during path construction.\n     uint64 peer_interface = 2;\n     // MTU on\
+    \ the peering link.\n     uint32 peer_mtu = 3;\n     // Material to create the\
+    \ data-plane Hop Field\n     HopField hop_field = 4;\n }\n\n message HopField\
+    \ {\n     // Ingress interface identifier.\n     uint64 ingress = 1;\n     //\
+    \ Egress interface identifier.\n     uint64 egress = 2;\n     // 8-bit encoded\
+    \ expiration offset relative to the segment\n     // creation timestamp.\n   \
+    \  uint32 exp_time = 3;\n     // MAC used in the dataplane to verify the Hop Field.\n\
+    \     bytes mac = 4;\n }\n\n      Figure 20: Control Service gRPC API - Segment\
+    \ representation\n</content>"
+  - 'passage:
+
+    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
+    to Formal Verification*. Springer International Publishing AG, 2022. </citation>
+
+    <type> book </type>
+
+    <page> 674 </page>
+
+    <content>
+
+    Index
+
+    Nesquic, 309
+
+    OpenFlow, 578
+
+    Packet
+
+    ¨ format, 95–96
+
+    ¨ forwarding, 115
+
+    ¨ initialization, 115
+
+    Packet-carried forwarding state
+
+    (PCFS), 29, 643
+
+    Packet-carried forwarding
+
+    state (PCFS), 19
+
+    Path attack
+
+    ¨ path hijacking, 166
+
+    ¨ path manipulation, 165
+
+    ¨ path preference attack, 168
+
+    ¨ path selection, 168
+
+    ¨ path splicing, 171
+
+    ¨ source-address spoofing, 174
+
+    Path authorization, 30, 170–172,
+
+    228, 643
+
+    Path construction, 104–115
+
+    ¨ segment combination, 28
+
+    Path control, 9, 168, 382, 643
+
+    Path discovery, 69–71
+
+    Path exploration, 24, 69–71, 135,
+
+    136, 142, 144, 147
+
+    Path lookup, 80–87
+
+    Path quality
+
+    ¨ beaconing overhead, 150
+
+    ¨ evaluation, 154–156
+
+    Path registration, 24, 412
+
+    ¨ core, 72
+
+    ¨ intra-ISD, 71
+
+    Path resolution, 104–112, 306
+
+    ¨ path combination, 28, 104–112
+
+    ¨ path lookup, 26, 306, 412
+
+    Path reversal, 116
+
+    Path revocation, 27, 120–124
+
+    Path segment, 27, 643
+
+    ¨ combination, 28, 104–115
+
+    ¨ core-segment, 24, 29
+
+    ¨ down-segment, 24
+
+    ¨ registration, 71
+
+    ¨ selection, 27, 73
+
+    ¨ up-segment, 24
+
+    Path selection, 27, 168
+
+    ¨ diversity-based, 76
+
+    ¨ malicious, 147
+
+    Path server, 24, 27
+
+    Path service (PS), 20, 289, 643
+
+    ¨ discovery, 87
+
+    Path transparency, 9, 644
+
+    Path validation, 230
+
+    Path-aware networking, 239
+
+    Path-segment construction beacon
+
+    (PCB), 19, 66–69, 644
+
+    ¨ components, 66
+
+    ¨ extensions, 197–201
+
+    ¨ filtering, 76
+
+    ¨ path metadata, 197–201
+
+    ¨ propagation, 70
+
+    ¨ selection properties, 74
+
+    PCB, see Path-segment
+
+    construction beacon
+
+    PCFS, see Packet-carried
+
+    forwarding state
+
+    Peering link, 25, 29
+
+    Peering path, 109
+
+    PILA, 461–469
+
+    PKI
+
+    ¨ control-plane PKI, 21–23, 36–52
+
+    ¨ end entity PKI, 419
+
+    ¨ F-PKI, 419–430
+
+    ¨ Web PKI, 419
+
+    Post-quantum cryptography, 415
+
+    Private lines
+
+    ¨ replacement, 374
+
+    Property
+
+    ¨ availability, 377
+
+    Pseudorandom function (PRF),
+
+    410, 411
+
+    Pseudorandom number generator,
+
+    409, 411
+
+    Recovery, 23
+
+    Relying party, 644
+
+    Replay-suppression, 204–207
+
+    Reservations
+
+    ¨ COLIBRI, 237–266
+
+    654
+
+    </content>'
+  - 'passage:
+
+    <citation> Seyedali Tabaeiaghdaei, Adrian Perrig. "Data-Plane Energy Efficiency
+    of a Next-Generation Internet Architecture." *IEEE Symposium on Computers and
+    Communications (ISCC)*, 2022. </citation>
+
+    <type> research paper </type>
+
+    <page> 1 </page>
+
+    <content>
+
+    Data-Plane Energy Efficiency of a
+
+    Next-Generation Internet Architecture
+
+    Seyedali T abaeiaghdaei
+
+    Department of Computer Science
+
+    ETH Z ¨urich, Switzerland
+
+    Adrian Perrig
+
+    Department of Computer Science
+
+    ETH Z ¨urich, Switzerland
+
+    Abstract—In the face of the ever-increasing power consumption
+
+    of the information and communication technology sector , next-
+
+    generation Internet architectures offer an opportunity to improve
+
+    the energy consumption of the Internet. The SCION architecture
+
+    is unique in that it has reached commercial deployment and
+
+    thus opens up opportunities for estimating and understanding
+
+    the promised energy efficiency from a realistic perspective.
+
+    In this work, we introduce a method that uses the available
+
+    energy consumption models for the current Internet architecture
+
+    to estimate the energy efficiency of SCION’s data plane. By
+
+    applying this method to the best available power consumption
+
+    models of the Internet, we show that while providing advanced
+
+    security and availability guarantees, SCION can reduce global
+
+    data plane power consumption by around 700 MW. W e further
+
+    investigate the impact of the SCION’s quality of service (QoS)
+
+    extension on data plane’s power consumption and conclude that
+
+    SCION with its QoS extension can reduce the power consumption
+
+    of the Internet by up to 2.88 GW. Therefore, SCION, with its QoS
+
+    extension, reduces the power consumption of the Internet and the
+
+    whole ICT sector by up to 9.4% and 1.3%, respectively .
+
+    Index T erms—Power consumption, next-generation Internet
+
+    architecture, Quality of Service, QoS
+
+    I. I N T RO D U C T I O N
+
+    It is estimated that the information and communication tech-
+
+    nology (ICT) sector consumed 2000 TW h electrical energy in
+
+    2020 (which is around 7% of global electricity generation) and
+
+    is responsible for 2.7% of global CO2 emissions [1]–[5]. The
+
+    electricity consumption impact of the ICT sector is expected
+
+    to grow to 21% in 2030 [6], of which networks account for a
+
+    27% share in 2030 (13% in 2020) [1].
+
+    Given the rising concerns regarding climate change and the
+
+    environmental impact of the ICT sector, numerous researchers
+
+    have studied the power consumption and energy efficiency of
+
+    the Internet [1], [4], [6]–[10], trying to estimate the power
+
+    consumption of the Internet and predict the future trend by
+
+    proposing various models. These models, however, do not take
+
+    into account the potential changes to the Internet’s operation
+
+    proposed by next-generation Internet architectures.
+
+    Several next-generation architectures have been proposed,
+
+    typically substantially modifying the Internet’s operation.
+
+    These modifications can significantly impact energy efficiency ,
+
+    necessitating investigation prior to large-scale deployment.
+
+    SCION [11] is a next-generation Internet architecture that
+
+    provides strong security and availability guarantees. SCION
+
+    uses packet-carried forwarding state to forward packets, a fun-
+
+    damental architectural change with a tremendous potential im-
+
+    pact on the Internet’s energy efficiency . Furthermore, SCION’s
+
+    inter-domain bandwidth reservation system can simplify con-
+
+    gestion control algorithms, affecting the power consumption
+
+    of both networks and end hosts significantly . As SCION has
+
+    reached commercial deployment [12], it is important to study
+
+    its power impact.
+
+    In this paper, we introduce a method to analyze SCION’s
+
+    impact on the data-plane power consumption. Using this
+
+    method we first identify all modifications required by SCION
+
+    to all different types of devices in the Internet. Then, we inves-
+
+    tigate how these modifications change the power consumption
+
+    of each device by taking into account the available power
+
+    consumption models for those devices. Finally , we investigate
+
+    how the change in the power consumption of each device
+
+    changes the power consumption of the whole Internet using
+
+    the available power consumption models. This methodology
+
+    is independent of the available power consumption models
+
+    of the Internet and network devices and therefore can be
+
+    applied to any available power consumption model. However,
+
+    the accuracy of the analysis depends on the accuracy of the
+
+    underlying models.
+
+    In Section III we describe this method in more detail by
+
+    applying it to the available power consumption models of the
+
+    Internet, and providing an estimate of how SCION changes the
+
+    power consumption of the Internet. Furthermore, in Section IV
+
+    we investigate how the inter-domain QoS extension of SCION
+
+    impacts the Internet’s power consumption.
+
+    II. B AC K G RO U N D ON SCION
+
+    SCION is a path-aware Internet architecture providing rout-
+
+    ing security , availability , path transparency , and path control.
+
+    A. Architecture
+
+    T o improve scalability , SCION groups ASes into isolation
+
+    domains (ISDs) . An ISD is administered by its ISD core,
+
+    typically consisting of several core ASes. Core ASes provide
+
+    connectivity to core ASes in other ISDs, and issue certificates
+
+    for non-core ASes in their own ISD. In each ISD, all non-core
+
+    ASes are either direct or indirect customers of core ASes.
+
+    B. Data plane
+
+    SCION uses packet-carried forwarding state to forward
+
+    packets: the inter-domain forwarding path is included in packet
+
+    headers, and routers forward packets using this information.
+
+    978-1-6654-9792-3/22/$31.00 ©2022 IEEE
+
+    </content>'
+- source_sentence: 'query: What steps are involved in building the SCION HTTP Forward
+    Proxy for MacOS?'
+  sentences:
+  - 'passage:
+
+    <url> https://scion-http-proxy.readthedocs.io/en/latest/forward-proxy.html </url>
+
+    <type> documentation </type>
+
+    <content>
+
+    # SCION HTTP Forward Proxy
+
+
+    # SCION HTTP Forward Proxy
+
+
+    The SCION HTTP Forward Proxy provides access to HTTP(S) resources via SCION by
+    using a configured proxy for all SCION-enabled domains.
+
+    It is implemented as a Caddy plugin, and can be used with any compatible Caddy
+    server version.
+
+    If you are looking for the reverse proxy, see Reverse Proxy.
+
+
+    ## Prerequisites
+
+
+    - A SCION-enabled host in a SCION-enabled network (see Access and Host Configuration).
+
+
+    ## Installation
+
+
+    You can install the SCION HTTP Reverse Proxy plugin either building from source
+    or adding the plugin to an existing Caddy installation.
+
+
+    ### Add plugin to existing Caddy installation
+
+
+    If you have an existing Caddy installation, you can add the SCION HTTP Proxy plugin
+    to it. The plugin contains both the reverse proxy (supporting the 3 flavors of
+    HTTP) and the forward proxy.
+
+    Please visit the Caddy SCION plugin documentation for more information on how
+    to extend Caddy with SCION.
+
+
+    ## Build for Linux
+
+
+    You can build the caddy server containing the SCION plugin from source as follows:
+
+
+    - Download the source code from the Caddy SCION repository.
+
+    - Build the plugin by running the following command in the root directory of the
+    repository:  go build -o ./build/scion-caddy-forward./cmd/scion-caddy-forward
+
+    - or (if you only want to build the forward and reverse proxy)  go build -o ./build/scion-caddy
+    ./cmd/scion-caddy
+
+
+    Then, you can follow the steps below to install the plugin:
+
+
+    - Ensure that you are running the scion-endhost stack as described in the SCION
+    documentation.
+
+    - Copy the binary to /usr/local/bin or any other directory in your $PATH.
+
+    - Add a data directory for the plugin to store its data:  sudo mkdir -p /usr/share/scion/caddy-scion
+
+    sudo chown -R $USER:$USER /usr/share/scion
+
+    - Optionally you can create a systemd service and enable it. You can use the example
+    service file scion-caddy.service in the examples.
+
+    - You can use the forward.json file in examples folder as reference configuration
+    file.
+
+    The configuration is passed using the -config flag when running the binary. If
+    you created a service, move it to /etc/scion/ or the path that you have configured
+    in the systemd service file.
+
+    - If you are running the forward proxy as a local proxy, please follow the localhost
+    configuration instructions to integrate it with your browser.
+
+
+    ## Build for MacOS
+
+
+    You can build the caddy server containing the SCION plugin from source as follows:
+
+
+    - Download the source code from the Caddy SCION repository.
+
+    - Build the plugin by running the following command in the root directory of the
+    repository:  GOOS=darwin GOARCH=amd64 go build -o ./build/scion-caddy-forward./cmd/scion-caddy-forward
+
+    - or (if you only want to build the forward and reverse proxy)  GOOS=darwin GOARCH=amd64
+    go build -o ./build/scion-caddy ./cmd/scion-caddy
+
+
+    Then, you can follow the steps below to install the plugin:
+
+
+    - Ensure that you are running the scion-endhost stack as described in the SCION
+    documentation.
+
+    - Apply the necessary permissions to the binary:  chmod +x scion-caddy
+
+    - Add a data directory for the plugin to store its data:  sudo mkdir -p /usr/local/scion/caddy-scion
+
+    sudo chown -R $USER /usr/local/scion
+
+    - You can use the forward.json file in examples folder as reference configuration
+    file.
+
+    The configuration is passed using the -config flag when running the binary.
+
+    Next, modify the JSON configuration file to point to the correct paths for the
+    plugin data directory. Mainly, replace /usr/share/scion/caddy-scion with /usr/local/scion/caddy-scion.
+
+    - Run the binary with the configuration file:  ./scion-caddy -conf /path/to/your/scion-caddy-forward-proxy.json
+
+    - If you are running the forward proxy as a local proxy, please follow the localhost
+    configuration instructions to integrate it with your browser.
+
+
+    ## Build for Windows
+
+
+    Note
+
+
+    Experimental option. The SCION HTTP forward proxy has not been tested on Windows
+    yet.
+
+
+    You can build the caddy server containing the SCION plugin from source as follows:
+
+
+
+    </content>'
+  - 'passage:
+
+    <citation> Seyedali Tabaeiaghdaei et al.. "Carbon-Aware Global Routing in Path-Aware
+    Networks." *Proceedings of ACM International Conference on Future Energy Systems
+    (e-Energy)*, 2023. </citation>
+
+    <type> research paper </type>
+
+    <page> 4 </page>
+
+    <content>
+
+    e-Energy ’23, June 20–23, 2023, Orlando, FL, USA Tabaeiaghdaei et al.
+
+    DisseminationModule
+
+    ForecastingModuleCO2Forecast DB
+
+    AS TopologyPower-grid CIIngress Intf. 1
+
+    Ingress Intf. 2
+
+    Egress Intf.
+
+    CIRo
+
+    ASi ASi-1
+
+    ASi-1
+
+    ASi-1ASi-1
+
+    ASiASi
+
+    Figure 2: Overview of CIRo. A participating AS runs a CIRo
+
+    instance. An instance consists of a forecasting module and an
+
+    information dissemination module. The forecasting module
+
+    computes path carbon intensity forecasts using a model we
+
+    introduce, the topology of the AS, and power-grid carbon-
+
+    intensity (CI) forecasts, and inserts its forecasts into the fore-
+
+    cast database. The dissemination module disseminates fore-
+
+    casts to other ASes using routing messages. It also provides
+
+    endpoints within an AS with these forecasts.
+
+    4 MODELING CARBON INTENSITY OF
+
+    INTER-DOMAIN PATHS
+
+    In this section, we develop a model enabling CIRo to compute and
+
+    disseminate carbon-intensity forecasts of inter-domain paths in
+
+    a distributed manner that does not require ASes to disclose their
+
+    internal topology.
+
+    4.1 Carbon Intensity of Data Transmission
+
+    Data transmission over a network path may cause CO2 emission
+
+    through two levels of indirection: forwarding traffic causes (electri-
+
+    cal) energy consumption on network devices, and the electricity
+
+    used by each device is generated from energy resources in a process
+
+    that may emit CO2, depending on the energy resources.
+
+    We define Carbon Intensity of Data Transmission over a net-
+
+    work path, i.e., CIDT in g/bit, as the CO 2 emission that can be
+
+    attributed to a unit of data for being transmitted over that path.
+
+    Since energy is an additive quantity, the CO2 emission of energy
+
+    consumption and the CO2 emission of data transmission are addi-
+
+    tive.
+
+    4.2 Inter-Domain CIDT
+
+    Using CIDT’s additive property, we write the CIDT of an inter-
+
+    domain path (denoted by {ASsrc, ..., ASdst}) as the sum of CIDTs of
+
+    consecutive AS hops it consists of:
+
+    CIDT{ASsrc,...,ASdst} =
+
+    ∑︁
+
+    AS𝑖
+
+    [ing, eg] ∈{ASsrc,...,ASdst}
+
+    CIDTAS𝑖
+
+    [ing, eg]
+
+    , (1)
+
+    where AS[ing, eg] denotes an AS hop on the inter-domain path.
+
+    [ing, eg] denotes the ingress and egress interface pair from/to which
+
+    the inter-domain path enters/exits the AS hop.
+
+    The additive property is essential for distributed functionality
+
+    of CIRo: each CIRo instance only needs to compute the CIDT of
+
+    paths within one AS without disclosing topology information.
+
+    Eq. (1) does not explicitly include inter-domain links connecting
+
+    the border routers of neighboring ASes. That is because such links
+
+    are either (1) direct links connecting two routers in the same data
+
+    center, or (2) peerings via IXPs, IXP federations, IXP port resellers,
+
+    or layer-2 links to an IXP. In the first case, the preceding AS on a
+
+    path includes the CIDT of the link in its hop’s CIDT. In the second
+
+    case, previous research suggests IXPs and resellers constitute ASes
+
+    in a PAN context [34]. Thus, they compute their CIDT as normal
+
+    ASes in the same way we propose in this section.
+
+    4.3 Per-Hop CIDT
+
+    An AS may forward traffic on multiple internal paths, e.g., using
+
+    equal-cost multi-path (ECMP). Therefore, we define the CIDT of
+
+    AS[ing, eg] as the mean CIDT of all active intra-domain paths from
+
+    its ingress interface to its egress interface. Thus,
+
+    CIDTAS[ing, eg] = 1
+
+    |P[ing, eg] |
+
+    ∑︁
+
+    𝑃[ing, eg] ∈P[ing, eg]
+
+    CIDT𝑃[ing, eg] (2)
+
+    where 𝑃[ing, eg] is an intra-domain path connecting ing and eg inter-
+
+    faces within the AS, and P[ing, eg] is the set of all such paths. In case
+
+    of weighted ECMP (WECMP), Eq. (2) is substituted with a weighted
+
+    mean over all paths.
+
+    4.4 CIDT of a Single Intra-Domain Path
+
+    The CIDT over a network path within an AS is composed of two
+
+    components: (1) the marginal CIDT, which is the result of the actual
+
+    amount of energy consumed to forward a bit of data over a path,
+
+    and (2) amortized CIDT, which is the result of energy consumed
+
+    to keep network paths operational and is independent of traffic
+
+    volume over the path. Therefore,
+
+    CIDT𝑃[ing, eg] = CIDTmarginal
+
+    𝑃[ing, eg]
+
+    +CIDTamortized
+
+    𝑃[ing, eg] (3)
+
+    Because of the additive property, we can write
+
+    CIDT𝑃[ing, eg] =
+
+    ∑︁
+
+    D∈𝑃[ing, eg]
+
+    CIDTmarginal
+
+    𝐷 +CIDTamortized
+
+    𝐷 (4)
+
+    where 𝐷 denotes a network device on 𝑃[ing, eg] . Since inter-domain
+
+    communication mostly takes place over backbone networks, we con-
+
+    sider typical backbone-network devices in this work, e.g., IP/MPLS
+
+    core routers and optical wavelength-division multiplexed (WDM)
+
+    devices [1, 25].
+
+    4.4.1 Marginal CIDT. For each device 𝐷, CIDTmarginal
+
+    𝐷 is the re-
+
+    sult of (1) the marginal energy the device consumes to forward one
+
+    bit of data (or marginal Energy Intensity of Data Transmission,
+
+    EIDTmarginal
+
+    𝐷 in kWh/bit), and (2) the marginal per-bit energy con-
+
+    sumption of the device’s external cooling and facilities, which is
+
+    proportional to EIDTmarginal
+
+    𝐷 [25]. Thus, the total marginal energy
+
+    is also proportional to EIDTmarginal
+
+    𝐷 by a constant factor (𝜂D,c) de-
+
+    termined by the power-usage efficiency (PUE) [7, 25].
+
+    To compute CIDTmarginal
+
+    𝐷 , we multiply the total marginal energy
+
+    by the 𝐶𝐼𝐸 (in g/kWh cf. §2.2) in the location of that device (CIED).
+
+    Therefore,
+
+    CIDTmarginal
+
+    𝐷 = 𝜂D,cEIDTmarginal
+
+    D CIED (5)
+
+    </content>'
+  - 'passage:
+
+    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
+    to Formal Verification*. Springer International Publishing AG, 2022. </citation>
+
+    <type> book </type>
+
+    <page> 88 </page>
+
+    <content>
+
+    4 Control Plane
+
+    4.1.1.4 Peer Entry (PE)
+
+    Through a peer entry, an AS can announce that it has a peering link to another
+
+    AS. Peer entries have a format similar to that of hop entries, but with additional
+
+    fields:
+
+    PE “ x HF } Peer } PeerInterface } PeerMTU y, (4.7)
+
+    where HF contains the information necessary to create a data-plane hop, Peer
+
+    is the ISD-AS number of the peering AS, PeerInterface is the interface iden-
+
+    tifier of the peering link on the remote AS side, and PeerMTU specifies the
+
+    MTU on the peering link.
+
+    4.1.1.5 Hop Field (HF)
+
+    Finally, the hop field (HF), which is contained in hop entries and peer entries,
+    is
+
+    used directly in the data plane for packet forwarding: It specifies the incoming
+
+    and outgoing interfaces of the ASes on the forwarding path. To prevent forgery,
+
+    this information is authenticated with a message authentication code (MAC).
+
+    A hop field has the following format:
+
+    HF “ x FlagsHF } ExpTime } ConsIngress } ConsEgress } HFAuthy, (4.8)
+
+    where FlagsHF may be used to indicate processing options for the AS; ExpTime
+
+    specifies for how long the hop field is valid; 2 ConsIngress and ConsEgress
+
+    identify, respectively, the ingress and egress interfaces (in the direction of
+    con-
+
+    struction, i.e., in the direction of beaconing); and HFAuthis a MAC.
+
+    We show how hop fields are authenticated (i.e., how the MAC is computed)
+
+    in §5.3.3. While the format of a SCION hop field is standardized, each AS can
+
+    independently choose the algorithm used to calculate the MAC.
+
+    4.1.2 Beacon Extensions
+
+    In addition to basic routing information like hop entries and peer entries, PCBs
+
+    can be used to communicate additional metadata.
+
+    4.1.2.1 Signed and Unsigned Extensions
+
+    There are two fields in PCBs that can contain optional metadata: The field
+
+    Ext contains extensions that are included in the signed component of an AS
+
+    entry and thus protected by the AS’s signature; the field ExtUnsigned contains
+
+    extensions that are not protected by the signature.
+
+    2The expiration time of a hop field is an offset relative to the PCB’s absolute
+    info field times-
+
+    tamp TS. The combination of the two thus allows an AS to compute the absolute
+    expiration
+
+    time of the hop field. Data-plane packets using the hop field after the expiration
+    time can be
+
+    dropped.
+
+    68
+
+    </content>'
+- source_sentence: 'query: How does SCION handle modification of the address header?'
+  sentences:
+  - 'passage:
+
+    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
+    to Formal Verification*. Springer International Publishing AG, 2022. </citation>
+
+    <type> book </type>
+
+    <page> 177 </page>
+
+    <content>
+
+    7 Security Analysis
+
+    TOBIAS KLENZE , M ARKUS LEGNER , A DRIAN PERRIG , B ENJAMIN
+
+    ROTHENBERGER *
+
+    Chapter Contents
+
+    7.1 Security Goals and Properties . . . . . . . . . . . . . . . . . 158
+
+    7.1.1 Overall Security Properties . . . . . . . . . . . . . . . . . . 158
+
+    7.1.2 Security Properties of ASes . . . . . . . . . . . . . . . . . 159
+
+    7.1.3 Security Properties of End Hosts . . . . . . . . . . . . . . . 160
+
+    7.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . 161
+
+    7.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
+
+    7.3.1 Baseline: Security in Today’s Internet . . . . . . . . . . . . . 163
+
+    7.3.2 Security Properties Achieved by SCION . . . . . . . . . . . 164
+
+    7.4 Control-Plane Security . . . . . . . . . . . . . . . . . . . . . 165
+
+    7.4.1 Path Hijacking through Interposition . . . . . . . . . . . . . 166
+
+    7.4.2 Creation of Spurious ASes . . . . . . . . . . . . . . . . . . 167
+
+    7.4.3 Peering Link Misuse . . . . . . . . . . . . . . . . . . . . . 167
+
+    7.4.4 Manipulation of the Path-Selection Process . . . . . . . . . . 168
+
+    7.5 Path Authorization . . . . . . . . . . . . . . . . . . . . . . . 170
+
+    7.5.1 Crafting Unauthorized Hop Fields . . . . . . . . . . . . . . 171
+
+    7.5.2 Protection of Validity Period . . . . . . . . . . . . . . . . . 171
+
+    7.5.3 Path Splicing . . . . . . . . . . . . . . . . . . . . . . . . 171
+
+    7.6 Data-Plane Security . . . . . . . . . . . . . . . . . . . . . . . 172
+
+    7.6.1 Modification of Path Header . . . . . . . . . . . . . . . . . 173
+
+    7.6.2 Detectability . . . . . . . . . . . . . . . . . . . . . . . . . 173
+
+    7.6.3 Modification of Address Header . . . . . . . . . . . . . . . 174
+
+    7.7 Source Authentication . . . . . . . . . . . . . . . . . . . . . 174
+
+    7.7.1 Reflection Attacks on Local End Hosts . . . . . . . . . . . . 175
+
+    7.7.2 Reflection Attacks on End Hosts in Other ASes . . . . . . . . 175
+
+    7.7.3 Defenses against Address Spoofing . . . . . . . . . . . . . . 176
+
+    7.8 Absence of Kill Switches . . . . . . . . . . . . . . . . . . . . 176
+
+    7.8.1 Local ISD Kill Switch . . . . . . . . . . . . . . . . . . . . 177
+
+    *This chapter reuses content from Barrera, Klenze, Perrig, Reischuk, Rothenberger,
+    and Sza-
+
+    lachowski [52].
+
+    157
+
+    </content>'
+  - "passage:\n<url> https://www.ietf.org/archive/id/draft-dekater-scion-dataplane-04.txt\
+    \ </url>\n<type> specification </type>\n<content>\n\n\n\nde Kater, et al.    \
+    \      Expires 27 June 2025                  [Page 9]\n\f\nInternet-Draft    \
+    \              SCION DP                   December 2024\n\n\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n\
+    \   |                             |\n   |                             |\n   |\
+    \        Payload (L4)         |\n   |                             |\n   |    \
+    \                         |\n   |                             |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n\
+    \   |                             |\n   |            SCION            |\n   |\
+    \                             |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  --------------+\n\
+    \   |             UDP             |                |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
+    \  Intra-domain  |\n   |             IP              |                |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
+    \    protocol    |\n   |         Link Layer          |                |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
+    \  --------------+\n\n     Figure 1: The SCION header within the protocol stack\
+    \ in a typical\n                                deployment.\n\n   A complete SCION\
+    \ address is composed of the <ISD, AS, endpoint\n   address> 3-tuple.  The ISD-AS\
+    \ part is used for inter-domain routing.\n   The endpoint address part is only\
+    \ used for intra-domain forwarding at\n   the source and destination ASes.  This\
+    \ implies that endpoint\n   addresses are only required to be globally unique\
+    \ within each SCION\n   AS.  This means, for example, that an endpoint running\
+    \ a SCION stack\n   using a [RFC1918] could directly communicate with another\
+    \ SCION\n   endpoint using a [RFC1918] endpoint address in a different SCION AS.\n\
+    \n   The data transmission order for SCION is the same as for IPv6 as\n   defined\
+    \ in Introduction of [RFC8200].\n\n1.3.2.  Intra-Domain Forwarding Process\n\n\
+    \   When transiting an intermediate SCION AS, a packet gets forwarded by\n   at\
+    \ most two SCION routers.  The forwarding process consists of the\n   following\
+    \ steps.\n\n   1.  The AS's SCION ingress router receives a SCION packet from\
+    \ the\n       neighboring AS.\n\n   2.  The SCION router parses, validates, and\
+    \ authenticates the SCION\n       header.\n\n\nde Kater, et al.          Expires\
+    \ 27 June 2025                 [Page 10]\n\f\nInternet-Draft                 \
+    \ SCION DP                   December 2024\n\n\n   3.  The SCION router maps the\
+    \ egress interface ID in the current Hop\n       Field of the SCION header to\
+    \ the destination address of the\n       intra-domain protocol (e.g.  MPLS or\
+    \ IP) of the egress border\n       router.\n\n   4.  The packet is forwarded within\
+    \ the AS by SCION-unaware routers\n       and switches based on the header of\
+    \ the intra-domain protocol.\n\n   5.  Upon receiving the packet, the SCION egress\
+    \ router strips off the\n       header of the intra-domain protocol, again validates\
+    \ and updates\n       the SCION header, and forwards the packet to the neighboring\n\
+    \       SCION router.\n\n   6.  The last SCION router on the path forwards the\
+    \ packet to the\n       packet's destination endpoint indicated by the field DstHostAddr\n\
+    \       of the Address Header (Section 2.2).\n\n1.3.3.  Configuration\n\n   Border\
+    \ routers require mappings from SCION interface IDs to underlay\n   addresses\
+    \ and such information MUST be supplied to each router in an\n   out of band fashion\
+    \ (e.g in a configuration file).  For each link to\n   a neighbor, these values\
+    \ MUST be configured.  A typical\n   implementation will require:\n\n   *  Interface\
+    \ ID.\n\n   *  Link type (core, parent, child, peer).  Link type depends on\n\
+    \      mutual agreements between the organizations operating the ASes at\n   \
+    \   each end of each link.\n\n   *  Neighbor ISD-AS number.\n\n   *  For the router\
+    \ that manages the interface: the neighbor interface\n      underlay address.\n\
+    \n   *  For the routers that do not manage the interface: the address of\n   \
+    \   the intra-domain protocol on the router that does.\n\n   In order to forward\
+    \ traffic to a service endpoint address (DT/DS ==\n   0b01 in the common header\
+    \ (Section 2.1)), a border router translates\n   the service number into a specific\
+    \ destination address.  The method\n   used to accomplish the translation is not\
+    \ defined by this document\n   and is only dependent on the implementation and\
+    \ the choices of each\n   AS's administrator.  In current practice this is accomplished\
+    \ by way\n   of a configuration file.\n</content>"
+  - 'passage:
+
+    <citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles
+    to Formal Verification*. Springer International Publishing AG, 2022. </citation>
+
+    <type> book </type>
+
+    <page> 191 </page>
+
+    <content>
+
+    7.5 Path Authorization
+
+    7.5.1 Crafting Unauthorized Hop Fields
+
+    Hop fields are protected with MACs and, if the corresponding key is unknown,
+
+    the adversary can at best attempt to perform a brute-force attack to determine
+
+    the key. Candidate keys can be validated by checking the MAC contained in
+
+    sample hop fields. As SCION uses 128-bit keys by default, such an off-line
+
+    attack is computationally infeasible in practice. Furthermore, the keys for the
+
+    MAC computation are short-lived, with a validity period of 24 hours.
+
+    MAC schemes are not generally specified by SCION and may thus be indi-
+
+    vidually chosen by each AS. A hop field’s MAC is only checked by the AS that
+
+    created it, which enables algorithm agility for the MAC scheme. If a certain
+
+    MAC algorithm is discovered to be weak or insecure, ASes can quickly switch
+
+    to a secure algorithm without the need for coordination with other ASes. This
+
+    property is known as cryptographic agility and is further discussed Chapter 17.
+
+    The adversary might also attempt to directly brute-force a MAC (instead of
+
+    the MAC’s key). However, this requires an online attack : One packet would
+
+    need to be sent to verify each guess. For an ℓ-bit MAC, the adversary needs
+
+    to generate 2 ℓ´1 packets on average to forge one correct MAC. For the 6-byte
+
+    MACs, which are proposed at the time of writing, the adversary would need
+
+    to try 2 47 « 140 trillion different MACs to successfully forge the MAC of a
+
+    single hop field. For each incorrect hop field, the corresponding AS returns an
+
+    SCMP packet. Even though an adversary can observe whether a hop field has
+
+    been accepted, each incorrect guess is visible to a monitoring entity and thus
+
+    the attack can be easily detected.
+
+    Unfortunately, in the unlikely case where such an online brute-force attack
+
+    succeeds, the obtained hop field can be reused until its eventual expiration. The
+
+    EPIC path type presented in § 10.1 resolves this issue by introducing per-packet
+
+    unique MACs.
+
+    7.5.2 Protection of Validity Period
+
+    The metadata for each path segment stored in the info field inside the path in
+
+    the SCION header (see § 5.4 on page 101) includes a timestamp, which is set
+
+    by the initiator of the PCB. This timestamp cannot be modified by an adversary
+
+    as it is included in the calculation of the MAC for each hop field. This ensures
+
+    that the timestamp cannot be set to a later date to extend the validity of the
+
+    path.
+
+    7.5.3 Path Splicing
+
+    In a path-splicing attack, an adversary (either controlling an AS or an end host)
+
+    takes valid hop fields of multiple path segments and splices them together to
+
+    obtain a new valid path. We have already described such attacks in § 5.3.2 and
+
+    used them to motivate SCION’s MAC-chaining mechanism: By including the
+
+    info field of a segment in the input to each hop field’s MAC computation and
+
+    171
+
+    </content>'
+pipeline_tag: sentence-similarity
+library_name: sentence-transformers
+metrics:
+- cosine_accuracy@1
+- cosine_accuracy@3
+- cosine_accuracy@5
+- cosine_accuracy@10
+- cosine_precision@1
+- cosine_precision@3
+- cosine_precision@5
+- cosine_precision@10
+- cosine_recall@1
+- cosine_recall@3
+- cosine_recall@5
+- cosine_recall@10
+- cosine_ndcg@10
+- cosine_mrr@10
+- cosine_map@100
+model-index:
+- name: SentenceTransformer based on sentence-transformers/all-MiniLM-L6-v2
+  results:
+  - task:
+      type: information-retrieval
+      name: Information Retrieval
+    dataset:
+      name: dev evaluation
+      type: dev-evaluation
+    metrics:
+    - type: cosine_accuracy@1
+      value: 0.14969135802469136
+      name: Cosine Accuracy@1
+    - type: cosine_accuracy@3
+      value: 0.33101851851851855
+      name: Cosine Accuracy@3
+    - type: cosine_accuracy@5
+      value: 0.4209104938271605
+      name: Cosine Accuracy@5
+    - type: cosine_accuracy@10
+      value: 0.5327932098765432
+      name: Cosine Accuracy@10
+    - type: cosine_precision@1
+      value: 0.14969135802469136
+      name: Cosine Precision@1
+    - type: cosine_precision@3
+      value: 0.11033950617283951
+      name: Cosine Precision@3
+    - type: cosine_precision@5
+      value: 0.0841820987654321
+      name: Cosine Precision@5
+    - type: cosine_precision@10
+      value: 0.05327932098765433
+      name: Cosine Precision@10
+    - type: cosine_recall@1
+      value: 0.14969135802469136
+      name: Cosine Recall@1
+    - type: cosine_recall@3
+      value: 0.33101851851851855
+      name: Cosine Recall@3
+    - type: cosine_recall@5
+      value: 0.4209104938271605
+      name: Cosine Recall@5
+    - type: cosine_recall@10
+      value: 0.5327932098765432
+      name: Cosine Recall@10
+    - type: cosine_ndcg@10
+      value: 0.32869830265467476
+      name: Cosine Ndcg@10
+    - type: cosine_mrr@10
+      value: 0.26489733367626966
+      name: Cosine Mrr@10
+    - type: cosine_map@100
+      value: 0.27706589741663973
+      name: Cosine Map@100
+---
+
+# SentenceTransformer based on sentence-transformers/all-MiniLM-L6-v2
+
+This is a [sentence-transformers](https://www.SBERT.net) model finetuned from [sentence-transformers/all-MiniLM-L6-v2](https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2). 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.
+
+## Model Details
+
+### Model Description
+- **Model Type:** Sentence Transformer
+- **Base model:** [sentence-transformers/all-MiniLM-L6-v2](https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2) <!-- at revision fa97f6e7cb1a59073dff9e6b13e2715cf7475ac9 -->
+- **Maximum Sequence Length:** 256 tokens
+- **Output Dimensionality:** 384 dimensions
+- **Similarity Function:** Cosine Similarity
+<!-- - **Training Dataset:** Unknown -->
+<!-- - **Language:** Unknown -->
+<!-- - **License:** Unknown -->
+
+### Model Sources
+
+- **Documentation:** [Sentence Transformers Documentation](https://sbert.net)
+- **Repository:** [Sentence Transformers on GitHub](https://github.com/UKPLab/sentence-transformers)
+- **Hugging Face:** [Sentence Transformers on Hugging Face](https://huggingface.co/models?library=sentence-transformers)
+
+### Full Model Architecture
+
+```
+SentenceTransformer(
+  (0): Transformer({'max_seq_length': 256, 'do_lower_case': False}) with Transformer model: BertModel 
+  (1): Pooling({'word_embedding_dimension': 384, 'pooling_mode_cls_token': False, 'pooling_mode_mean_tokens': True, '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()
+)
+```
+
+## Usage
+
+### Direct Usage (Sentence Transformers)
+
+First install the Sentence Transformers library:
+
+```bash
+pip install -U sentence-transformers
+```
+
+Then you can load this model and run inference.
+```python
+from sentence_transformers import SentenceTransformer
+
+# Download from the 🤗 Hub
+model = SentenceTransformer("tjohn327/scion-all-MiniLM-L6-v2")
+# Run inference
+sentences = [
+    'query: How does SCION handle modification of the address header?',
+    'passage:\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> 177 </page>\n<content>\n7 Security Analysis\nTOBIAS KLENZE , M ARKUS LEGNER , A DRIAN PERRIG , B ENJAMIN\nROTHENBERGER *\nChapter Contents\n7.1 Security Goals and Properties . . . . . . . . . . . . . . . . . 158\n7.1.1 Overall Security Properties . . . . . . . . . . . . . . . . . . 158\n7.1.2 Security Properties of ASes . . . . . . . . . . . . . . . . . 159\n7.1.3 Security Properties of End Hosts . . . . . . . . . . . . . . . 160\n7.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . 161\n7.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162\n7.3.1 Baseline: Security in Today’s Internet . . . . . . . . . . . . . 163\n7.3.2 Security Properties Achieved by SCION . . . . . . . . . . . 164\n7.4 Control-Plane Security . . . . . . . . . . . . . . . . . . . . . 165\n7.4.1 Path Hijacking through Interposition . . . . . . . . . . . . . 166\n7.4.2 Creation of Spurious ASes . . . . . . . . . . . . . . . . . . 167\n7.4.3 Peering Link Misuse . . . . . . . . . . . . . . . . . . . . . 167\n7.4.4 Manipulation of the Path-Selection Process . . . . . . . . . . 168\n7.5 Path Authorization . . . . . . . . . . . . . . . . . . . . . . . 170\n7.5.1 Crafting Unauthorized Hop Fields . . . . . . . . . . . . . . 171\n7.5.2 Protection of Validity Period . . . . . . . . . . . . . . . . . 171\n7.5.3 Path Splicing . . . . . . . . . . . . . . . . . . . . . . . . 171\n7.6 Data-Plane Security . . . . . . . . . . . . . . . . . . . . . . . 172\n7.6.1 Modification of Path Header . . . . . . . . . . . . . . . . . 173\n7.6.2 Detectability . . . . . . . . . . . . . . . . . . . . . . . . . 173\n7.6.3 Modification of Address Header . . . . . . . . . . . . . . . 174\n7.7 Source Authentication . . . . . . . . . . . . . . . . . . . . . 174\n7.7.1 Reflection Attacks on Local End Hosts . . . . . . . . . . . . 175\n7.7.2 Reflection Attacks on End Hosts in Other ASes . . . . . . . . 175\n7.7.3 Defenses against Address Spoofing . . . . . . . . . . . . . . 176\n7.8 Absence of Kill Switches . . . . . . . . . . . . . . . . . . . . 176\n7.8.1 Local ISD Kill Switch . . . . . . . . . . . . . . . . . . . . 177\n*This chapter reuses content from Barrera, Klenze, Perrig, Reischuk, Rothenberger, and Sza-\nlachowski [52].\n157\n</content>',
+    "passage:\n<url> https://www.ietf.org/archive/id/draft-dekater-scion-dataplane-04.txt </url>\n<type> specification </type>\n<content>\n\n\n\nde Kater, et al.          Expires 27 June 2025                  [Page 9]\n\x0c\nInternet-Draft                  SCION DP                   December 2024\n\n\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n   |                             |\n   |                             |\n   |        Payload (L4)         |\n   |                             |\n   |                             |\n   |                             |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n   |                             |\n   |            SCION            |\n   |                             |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  --------------+\n   |             UDP             |                |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Intra-domain  |\n   |             IP              |                |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    protocol    |\n   |         Link Layer          |                |\n   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  --------------+\n\n     Figure 1: The SCION header within the protocol stack in a typical\n                                deployment.\n\n   A complete SCION address is composed of the <ISD, AS, endpoint\n   address> 3-tuple.  The ISD-AS part is used for inter-domain routing.\n   The endpoint address part is only used for intra-domain forwarding at\n   the source and destination ASes.  This implies that endpoint\n   addresses are only required to be globally unique within each SCION\n   AS.  This means, for example, that an endpoint running a SCION stack\n   using a [RFC1918] could directly communicate with another SCION\n   endpoint using a [RFC1918] endpoint address in a different SCION AS.\n\n   The data transmission order for SCION is the same as for IPv6 as\n   defined in Introduction of [RFC8200].\n\n1.3.2.  Intra-Domain Forwarding Process\n\n   When transiting an intermediate SCION AS, a packet gets forwarded by\n   at most two SCION routers.  The forwarding process consists of the\n   following steps.\n\n   1.  The AS's SCION ingress router receives a SCION packet from the\n       neighboring AS.\n\n   2.  The SCION router parses, validates, and authenticates the SCION\n       header.\n\n\nde Kater, et al.          Expires 27 June 2025                 [Page 10]\n\x0c\nInternet-Draft                  SCION DP                   December 2024\n\n\n   3.  The SCION router maps the egress interface ID in the current Hop\n       Field of the SCION header to the destination address of the\n       intra-domain protocol (e.g.  MPLS or IP) of the egress border\n       router.\n\n   4.  The packet is forwarded within the AS by SCION-unaware routers\n       and switches based on the header of the intra-domain protocol.\n\n   5.  Upon receiving the packet, the SCION egress router strips off the\n       header of the intra-domain protocol, again validates and updates\n       the SCION header, and forwards the packet to the neighboring\n       SCION router.\n\n   6.  The last SCION router on the path forwards the packet to the\n       packet's destination endpoint indicated by the field DstHostAddr\n       of the Address Header (Section 2.2).\n\n1.3.3.  Configuration\n\n   Border routers require mappings from SCION interface IDs to underlay\n   addresses and such information MUST be supplied to each router in an\n   out of band fashion (e.g in a configuration file).  For each link to\n   a neighbor, these values MUST be configured.  A typical\n   implementation will require:\n\n   *  Interface ID.\n\n   *  Link type (core, parent, child, peer).  Link type depends on\n      mutual agreements between the organizations operating the ASes at\n      each end of each link.\n\n   *  Neighbor ISD-AS number.\n\n   *  For the router that manages the interface: the neighbor interface\n      underlay address.\n\n   *  For the routers that do not manage the interface: the address of\n      the intra-domain protocol on the router that does.\n\n   In order to forward traffic to a service endpoint address (DT/DS ==\n   0b01 in the common header (Section 2.1)), a border router translates\n   the service number into a specific destination address.  The method\n   used to accomplish the translation is not defined by this document\n   and is only dependent on the implementation and the choices of each\n   AS's administrator.  In current practice this is accomplished by way\n   of a configuration file.\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]
+```
+
+<!--
+### Direct Usage (Transformers)
+
+<details><summary>Click to see the direct usage in Transformers</summary>
+
+</details>
+-->
+
+<!--
+### Downstream Usage (Sentence Transformers)
+
+You can finetune this model on your own dataset.
+
+<details><summary>Click to expand</summary>
+
+</details>
+-->
+
+<!--
+### Out-of-Scope Use
+
+*List how the model may foreseeably be misused and address what users ought not to do with the model.*
+-->
+
+## Evaluation
+
+### Metrics
+
+#### Information Retrieval
+
+* Dataset: `dev-evaluation`
+* Evaluated with [<code>InformationRetrievalEvaluator</code>](https://sbert.net/docs/package_reference/sentence_transformer/evaluation.html#sentence_transformers.evaluation.InformationRetrievalEvaluator)
+
+| Metric              | Value      |
+|:--------------------|:-----------|
+| cosine_accuracy@1   | 0.1497     |
+| cosine_accuracy@3   | 0.331      |
+| cosine_accuracy@5   | 0.4209     |
+| cosine_accuracy@10  | 0.5328     |
+| cosine_precision@1  | 0.1497     |
+| cosine_precision@3  | 0.1103     |
+| cosine_precision@5  | 0.0842     |
+| cosine_precision@10 | 0.0533     |
+| cosine_recall@1     | 0.1497     |
+| cosine_recall@3     | 0.331      |
+| cosine_recall@5     | 0.4209     |
+| cosine_recall@10    | 0.5328     |
+| **cosine_ndcg@10**  | **0.3287** |
+| cosine_mrr@10       | 0.2649     |
+| cosine_map@100      | 0.2771     |
+
+<!--
+## Bias, Risks and Limitations
+
+*What are the known or foreseeable issues stemming from this model? You could also flag here known failure cases or weaknesses of the model.*
+-->
+
+<!--
+### Recommendations
+
+*What are recommendations with respect to the foreseeable issues? For example, filtering explicit content.*
+-->
+
+## Training Details
+
+### Training Dataset
+
+#### Unnamed Dataset
+
+* Size: 23,200 training samples
+* Columns: <code>sentence_0</code>, <code>sentence_1</code>, and <code>label</code>
+* Approximate statistics based on the first 1000 samples:
+  |         | sentence_0                                                                        | sentence_1                                                                           | label                                                         |
+  |:--------|:----------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------|:--------------------------------------------------------------|
+  | type    | string                                                                            | string                                                                               | float                                                         |
+  | details | <ul><li>min: 9 tokens</li><li>mean: 19.41 tokens</li><li>max: 34 tokens</li></ul> | <ul><li>min: 111 tokens</li><li>mean: 254.6 tokens</li><li>max: 256 tokens</li></ul> | <ul><li>min: 1.0</li><li>mean: 1.0</li><li>max: 1.0</li></ul> |
+* Samples:
+  | sentence_0                                                                                 | sentence_1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | label            |
+  |:-------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------|
+  | <code>query: Explain the role of the Packet Timestamp in SCION data packets.</code>        | <code>passage:<br><url> https://docs.scion.org/en/latest/protocols/scion-header.html </url><br><type> documentation </type><br><content><br>Control plane:<br>The beaconing process is the same as for SCION, but the ASes not<br>only add the 6 bytes of the truncated MAC to the beacon, but further<br>append the remaining 10 bytes.<br><br>Data plane:<br>The source fetches the path, including all the 6-byte short hop<br>authenticators and the remaining 10 bytes of the authenticators,<br>from a (hidden) path server. We will refer to the fully assembled 16-byte<br>authenticators of the penultimate and last hop on the path as<br>\({\sigma_{\text{PH}}}\) for the penultimate hop (PH) and<br>\({\sigma_{\text{LH}}}\) for the last hop (LH), respectively.<br><br>The source then copies the short authenticators to the corresponding<br>MAC-subfield of the Hop Fields as for SCION path type packets and<br>adds the current Packet Timestamp. In addition, it calculates the<br>PHVF and LHVF as follows:<br><br>Here, “Timestamp” is the Timestamp from the first Info Field and<br>“Flags...</code>          | <code>1.0</code> |
+  | <code>query: What does the Dolev–Yao closure imply for intruder knowledge in SCION?</code> | <code>passage:<br><citation> Laurent Chuat et al.. *The Complete Guide to SCION. From Design Principles to Formal Verification*. Springer International Publishing AG, 2022. </citation><br><type> book </type><br><page> 526 </page><br><content><br>22 Design-Level Verification<br>hop field and tok field, respectively. This check ensures that the hop field (and<br>indeed the whole or partial path) is authorized. In SCION, this corresponds<br>to Item 6 of the checks performed by the ingress border router. Additionally,<br>the same check is performed by the egress border router. In the event system<br>that we present here, we do not include the update of the packet token field,<br>which is required to model Item 5 of the SCION ingress border router, where<br>the segment identifier is updated. We introduce instead an update mechanism<br>as an extension of our framework in § 22.4.5.<br>The events sendc and deliverc use the function fwdc to forward a packet:<br>fwdcpmq “ p |tok “ tokpmq, past “ hdpfutpmqq#pastpmq, fut “ tlpfutpmqq,<br>hist “ hdpfutpmqq#...</code>                               | <code>1.0</code> |
+  | <code>query: How does the trust anchor pool function in SCION's certification path?</code> | <code>passage:<br><url> https://www.ietf.org/archive/id/draft-dekater-scion-pki-08.txt </url><br><type> specification </type><br><content><br><br>de Kater, et al.           Expires 3 July 2025                 [Page 40]<br>  <br>Internet-Draft                SCION CP-PKI                 December 2024<br><br><br>   Two TRCs with byte equal payloads can be considered as equal because<br>   the TRC payload exactly defines which signatures must be attached in<br>   the signed TRC:<br><br>   *  The REQUIRED signatures from voting certificates are explicitly<br>      mentioned in the votes field of the payload: If index "i" is part<br>      of the votes field, then the voting certificate at position i in<br>      the certificates sequence of the predecessor TRC casted a vote on<br>      the successor TRC.  See also Section 3.1.2.2.6.<br><br>   *  The REQUIRED signatures for new certificates are implied by the<br>      currently valid TRC payload, and, in case of a TRC update, the<br>      predecessor payload.<br><br>3.1.4.   Certification Path - Trust Anchor Pool<br><br>   Th...</code> | <code>1.0</code> |
+* Loss: [<code>MultipleNegativesRankingLoss</code>](https://sbert.net/docs/package_reference/sentence_transformer/losses.html#multiplenegativesrankingloss) with these parameters:
+  ```json
+  {
+      "scale": 20.0,
+      "similarity_fct": "cos_sim"
+  }
+  ```
+
+### Training Hyperparameters
+#### Non-Default Hyperparameters
+
+- `eval_strategy`: steps
+- `per_device_train_batch_size`: 200
+- `per_device_eval_batch_size`: 200
+- `fp16`: True
+- `multi_dataset_batch_sampler`: round_robin
+
+#### All Hyperparameters
+<details><summary>Click to expand</summary>
+
+- `overwrite_output_dir`: False
+- `do_predict`: False
+- `eval_strategy`: steps
+- `prediction_loss_only`: True
+- `per_device_train_batch_size`: 200
+- `per_device_eval_batch_size`: 200
+- `per_gpu_train_batch_size`: None
+- `per_gpu_eval_batch_size`: None
+- `gradient_accumulation_steps`: 1
+- `eval_accumulation_steps`: None
+- `torch_empty_cache_steps`: None
+- `learning_rate`: 5e-05
+- `weight_decay`: 0.0
+- `adam_beta1`: 0.9
+- `adam_beta2`: 0.999
+- `adam_epsilon`: 1e-08
+- `max_grad_norm`: 1
+- `num_train_epochs`: 3
+- `max_steps`: -1
+- `lr_scheduler_type`: linear
+- `lr_scheduler_kwargs`: {}
+- `warmup_ratio`: 0.0
+- `warmup_steps`: 0
+- `log_level`: passive
+- `log_level_replica`: warning
+- `log_on_each_node`: True
+- `logging_nan_inf_filter`: True
+- `save_safetensors`: True
+- `save_on_each_node`: False
+- `save_only_model`: False
+- `restore_callback_states_from_checkpoint`: False
+- `no_cuda`: False
+- `use_cpu`: False
+- `use_mps_device`: False
+- `seed`: 42
+- `data_seed`: None
+- `jit_mode_eval`: False
+- `use_ipex`: False
+- `bf16`: False
+- `fp16`: True
+- `fp16_opt_level`: O1
+- `half_precision_backend`: auto
+- `bf16_full_eval`: False
+- `fp16_full_eval`: False
+- `tf32`: None
+- `local_rank`: 0
+- `ddp_backend`: None
+- `tpu_num_cores`: None
+- `tpu_metrics_debug`: False
+- `debug`: []
+- `dataloader_drop_last`: False
+- `dataloader_num_workers`: 0
+- `dataloader_prefetch_factor`: None
+- `past_index`: -1
+- `disable_tqdm`: False
+- `remove_unused_columns`: True
+- `label_names`: None
+- `load_best_model_at_end`: False
+- `ignore_data_skip`: False
+- `fsdp`: []
+- `fsdp_min_num_params`: 0
+- `fsdp_config`: {'min_num_params': 0, 'xla': False, 'xla_fsdp_v2': False, 'xla_fsdp_grad_ckpt': False}
+- `fsdp_transformer_layer_cls_to_wrap`: None
+- `accelerator_config`: {'split_batches': False, 'dispatch_batches': None, 'even_batches': True, 'use_seedable_sampler': True, 'non_blocking': False, 'gradient_accumulation_kwargs': None}
+- `deepspeed`: None
+- `label_smoothing_factor`: 0.0
+- `optim`: adamw_torch
+- `optim_args`: None
+- `adafactor`: False
+- `group_by_length`: False
+- `length_column_name`: length
+- `ddp_find_unused_parameters`: None
+- `ddp_bucket_cap_mb`: None
+- `ddp_broadcast_buffers`: False
+- `dataloader_pin_memory`: True
+- `dataloader_persistent_workers`: False
+- `skip_memory_metrics`: True
+- `use_legacy_prediction_loop`: False
+- `push_to_hub`: False
+- `resume_from_checkpoint`: None
+- `hub_model_id`: None
+- `hub_strategy`: every_save
+- `hub_private_repo`: None
+- `hub_always_push`: False
+- `gradient_checkpointing`: False
+- `gradient_checkpointing_kwargs`: None
+- `include_inputs_for_metrics`: False
+- `include_for_metrics`: []
+- `eval_do_concat_batches`: True
+- `fp16_backend`: auto
+- `push_to_hub_model_id`: None
+- `push_to_hub_organization`: None
+- `mp_parameters`: 
+- `auto_find_batch_size`: False
+- `full_determinism`: False
+- `torchdynamo`: None
+- `ray_scope`: last
+- `ddp_timeout`: 1800
+- `torch_compile`: False
+- `torch_compile_backend`: None
+- `torch_compile_mode`: None
+- `dispatch_batches`: None
+- `split_batches`: None
+- `include_tokens_per_second`: False
+- `include_num_input_tokens_seen`: False
+- `neftune_noise_alpha`: None
+- `optim_target_modules`: None
+- `batch_eval_metrics`: False
+- `eval_on_start`: False
+- `use_liger_kernel`: False
+- `eval_use_gather_object`: False
+- `average_tokens_across_devices`: False
+- `prompts`: None
+- `batch_sampler`: batch_sampler
+- `multi_dataset_batch_sampler`: round_robin
+
+</details>
+
+### Training Logs
+| Epoch | Step | dev-evaluation_cosine_ndcg@10 |
+|:-----:|:----:|:-----------------------------:|
+| 1.0   | 58   | 0.3021                        |
+| 2.0   | 116  | 0.3203                        |
+| 3.0   | 174  | 0.3287                        |
+
+
+### Framework Versions
+- Python: 3.12.3
+- Sentence Transformers: 3.4.1
+- Transformers: 4.49.0
+- PyTorch: 2.6.0+cu124
+- Accelerate: 1.4.0
+- Datasets: 3.3.2
+- Tokenizers: 0.21.0
+
+## Citation
+
+### BibTeX
+
+#### Sentence Transformers
+```bibtex
+@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",
+}
+```
+
+#### MultipleNegativesRankingLoss
+```bibtex
+@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}
+}
+```
+
+<!--
+## Glossary
+
+*Clearly define terms in order to be accessible across audiences.*
+-->
+
+<!--
+## Model Card Authors
+
+*Lists the people who create the model card, providing recognition and accountability for the detailed work that goes into its construction.*
+-->
+
+<!--
+## Model Card Contact
+
+*Provides a way for people who have updates to the Model Card, suggestions, or questions, to contact the Model Card authors.*
+-->

config.json

@@ -0,0 +1,26 @@
+{
+  "_name_or_path": "sentence-transformers/all-MiniLM-L6-v2",
+  "architectures": [
+    "BertModel"
+  ],
+  "attention_probs_dropout_prob": 0.1,
+  "classifier_dropout": null,
+  "gradient_checkpointing": false,
+  "hidden_act": "gelu",
+  "hidden_dropout_prob": 0.1,
+  "hidden_size": 384,
+  "initializer_range": 0.02,
+  "intermediate_size": 1536,
+  "layer_norm_eps": 1e-12,
+  "max_position_embeddings": 512,
+  "model_type": "bert",
+  "num_attention_heads": 12,
+  "num_hidden_layers": 6,
+  "pad_token_id": 0,
+  "position_embedding_type": "absolute",
+  "torch_dtype": "float32",
+  "transformers_version": "4.49.0",
+  "type_vocab_size": 2,
+  "use_cache": true,
+  "vocab_size": 30522
+}

config_sentence_transformers.json

@@ -0,0 +1,10 @@
+{
+  "__version__": {
+    "sentence_transformers": "3.4.1",
+    "transformers": "4.49.0",
+    "pytorch": "2.6.0+cu124"
+  },
+  "prompts": {},
+  "default_prompt_name": null,
+  "similarity_fn_name": "cosine"
+}

model.safetensors

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:7dd9a00dc4b88130472da5d291d1230c3eb1271a204cc1c34c47e4fcffe17262
+size 90864192

modules.json

@@ -0,0 +1,20 @@
+[
+  {
+    "idx": 0,
+    "name": "0",
+    "path": "",
+    "type": "sentence_transformers.models.Transformer"
+  },
+  {
+    "idx": 1,
+    "name": "1",
+    "path": "1_Pooling",
+    "type": "sentence_transformers.models.Pooling"
+  },
+  {
+    "idx": 2,
+    "name": "2",
+    "path": "2_Normalize",
+    "type": "sentence_transformers.models.Normalize"
+  }
+]

sentence_bert_config.json

@@ -0,0 +1,4 @@
+{
+  "max_seq_length": 256,
+  "do_lower_case": false
+}

special_tokens_map.json

@@ -0,0 +1,37 @@
+{
+  "cls_token": {
+    "content": "[CLS]",
+    "lstrip": false,
+    "normalized": false,
+    "rstrip": false,
+    "single_word": false
+  },
+  "mask_token": {
+    "content": "[MASK]",
+    "lstrip": false,
+    "normalized": false,
+    "rstrip": false,
+    "single_word": false
+  },
+  "pad_token": {
+    "content": "[PAD]",
+    "lstrip": false,
+    "normalized": false,
+    "rstrip": false,
+    "single_word": false
+  },
+  "sep_token": {
+    "content": "[SEP]",
+    "lstrip": false,
+    "normalized": false,
+    "rstrip": false,
+    "single_word": false
+  },
+  "unk_token": {
+    "content": "[UNK]",
+    "lstrip": false,
+    "normalized": false,
+    "rstrip": false,
+    "single_word": false
+  }
+}

tokenizer_config.json

@@ -0,0 +1,65 @@
+{
+  "added_tokens_decoder": {
+    "0": {
+      "content": "[PAD]",
+      "lstrip": false,
+      "normalized": false,
+      "rstrip": false,
+      "single_word": false,
+      "special": true
+    },
+    "100": {
+      "content": "[UNK]",
+      "lstrip": false,
+      "normalized": false,
+      "rstrip": false,
+      "single_word": false,
+      "special": true
+    },
+    "101": {
+      "content": "[CLS]",
+      "lstrip": false,
+      "normalized": false,
+      "rstrip": false,
+      "single_word": false,
+      "special": true
+    },
+    "102": {
+      "content": "[SEP]",
+      "lstrip": false,
+      "normalized": false,
+      "rstrip": false,
+      "single_word": false,
+      "special": true
+    },
+    "103": {
+      "content": "[MASK]",
+      "lstrip": false,
+      "normalized": false,
+      "rstrip": false,
+      "single_word": false,
+      "special": true
+    }
+  },
+  "clean_up_tokenization_spaces": false,
+  "cls_token": "[CLS]",
+  "do_basic_tokenize": true,
+  "do_lower_case": true,
+  "extra_special_tokens": {},
+  "mask_token": "[MASK]",
+  "max_length": 128,
+  "model_max_length": 256,
+  "never_split": null,
+  "pad_to_multiple_of": null,
+  "pad_token": "[PAD]",
+  "pad_token_type_id": 0,
+  "padding_side": "right",
+  "sep_token": "[SEP]",
+  "stride": 0,
+  "strip_accents": null,
+  "tokenize_chinese_chars": true,
+  "tokenizer_class": "BertTokenizer",
+  "truncation_side": "right",
+  "truncation_strategy": "longest_first",
+  "unk_token": "[UNK]"
+}