Skip to content

Accessible paths by an offer #3

@juagargi

Description

@juagargi

Detailed conversation here: https://github.com/juagargi/esdx-scion/pull/1/files#r882890787

Observation: it seems convenient for buyers to know which paths they can reach by an offer.

The offering AS (the provider) cannot guarantee access to all or any beacons it has received in the past (even if they were received 1 minute before not_before), since the expiration time may happen before the contract starts. What the AS can do is:

  • List the neighbors attached to itself. Egress interfaces where they will allow traffic sent from the buyer.
  • Forward beacons received from these interfaces.
  • List which beacons will be propagated. This mandatory propagation is valid only $T_\text{beacon} \cap T_\text{contract}$, for each of the beacons
  • Filter certain beacons due to AS policy. This may include anything expressible by a path policy (filter).
  • Perform traffic control on any interface. By this I mean some egress interfaces may be more expensive and thus will have a smaller allocation for the buyer. This might be difficult to express, and at least on a first version of the protocol we might omit it. This is of course, the most general approach, as traffic control can also specify 0 bps.

It seems possible that the provider lists the accessible neighbors, beacons that will propagate, and provide samples of beacons it is willing to forward to the buyers.

For the path policies, we will follow the syntax on https://scion.docs.anapaya.net/en/latest/PathPolicy.html

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions