Background. The Internet is made up of interconnected networks of autonomously governed domains containing many entities (computers and servers) that communicate by sending each other messages (packets). Domains must collaborate in order to send and receive messages between entities across domain boundaries. Presently, neighboring domains often have “peering agreements” where each domain will agree to transport messages from its neighboring domain to its other neighboring domains without charge on a best effort (BE) basis; these peering agreements are how the Internet is able to send messages between entities across domain boundaries. Scenario. In newer applications like voice, video and corporate data, messages have higher transport requirements. Messages from voice and video applications need to get to the destination super fast and do not care if some messages are lost, and messages from corporate data applications may not be too particular about speed but need to have all messages arrive safe and sound – both these types of applications require more quality of service (QoS) than older Internet applications like email or chatting applications that typically get BE service. Providing QoS transport services within a domain takes more effort by the domain management and is inherently more expensive than providing BE transport service, so transporting messages without charge does not work with the QoS scenario. While a QoS application user may be willing to pay to have better service, the user’s domain management may not be able to offer QoS services that cross domain borders, especially if the messages need to traverse multiple domains, which is often the case. The Problem. In order to deploy inter-domain QoS services across domain boundaries, every domain along the path must implement a policy that allows QoS messages from the source domain to be honored as a QoS message in every domain. 
This raises the question of 1) how do you know which domain has the available resources for the task, 2) which of the domains with the available resource should be picked, and 3) once you pick the domains, how do you negotiate the policy propagation in such a way as to protect all parties. The complicating factor is that viable solutions must refrain from giving power to any specific or central authority since domains are extremely independent. The above figure illustrates what needs to be implemented for inter-domain QoS policy to be deployed. 
iREX. The Inter-domain Resource Exchange (iREX) project is a proposed solution to the above problem based on the economics concept of “Posted Price Competition”. iREX facilitates market mechanisms for inter-domain resources that respects each participating domain’s autonomy. Domains that want to supply QoS resources advertise the price of their resource so that domains needing to send QoS traffic can choose from the advertised QoS resources to make a message transport path to the destination. 
iREX allows domains needing inter-domain resources to acquire information about the cheapest available resources, and then to communicate directly with the resource owners to establish an end to end QoS deployment. | 
 "Domain to Domain Interaction")
 "Inter-Domain Management")
 "irex-price-1a")