On Wed, 06 June 2001, Vijay Gill wrote:
On 6 Jun 2001, Sean Donelan wrote:
If you think it will hurt the other provider more than you, you'll terminate the agreement. If you think it will hurt you more, you'll fight to keep it in place.
If it will hurt you more than it will hurt them, then you aren't a really a "peer", and in that case, the disparity is resolved by the use of a service contract whereby you pay them money in exchange for connectivity.
I agree, but how do you decide who is hurt more? And therefore who should be the vendor and who is the customer? Is the "bigger" network always the vendor, or is the network with more content the vendor, or the network with more eyeballs the vendor? That's what I don't understand about the "balance" requirement. Ok, so you know the traffic is imbalanced, but whose fault/hurt is it when traffic is imbalanced? And who is responsible for "fixing" the imbalance in traffic? The simple answer is I'm the vendor and you are the customer, so you should pay me. The more difficult answer is one side turns off the connection (C&W) and the first side to blink is the customer (C&W). If C&W didn't feel any pain, why would they turn the peering sessions back on?
On 6 Jun 2001, Sean Donelan wrote:
I agree, but how do you decide who is hurt more?
Turn off connectivity and see.
And therefore who should be the vendor and who is the customer?
See above.
Is the "bigger" network always the vendor, or is the network with more content the vendor, or the network with more eyeballs the vendor? That's what I don't understand about the "balance" requirement. Ok, so you know the traffic is imbalanced, but whose fault/hurt is it when traffic is imbalanced? And who is responsible for "fixing" the imbalance in traffic?
The simple answer is I'm the vendor and you are the customer, so you should pay me.
The simple answer is: Do the people you are selling to ask how your connectivity to <Network A> is AND if Network A's sales people get asked the same question about _your_ network. If not, then giddy up and start following the "sales process (C) 2001 smd" /vijay "time to put the peer back in peering" gill
Turn off connectivity and see.
And therefore who should be the vendor and who is the customer?
See above.
I would imagine that such actions tend to irritate the hive of regulatory officials. Self regulation would be one way to prevent such action. Regards, James
I agree, but how do you decide who is hurt more?
And therefore who should be the vendor and who is the customer?
Is the "bigger" network always the vendor, or is the network with more content the vendor, or the network with more eyeballs the vendor? That's what I don't understand about the "balance" requirement. Ok, so you know the traffic is imbalanced, but whose fault/hurt is it when traffic is imbalanced? And who is responsible for "fixing" the imbalance in traffic?
In the telecommunications industry the role of "vendor" is played mutually depending on the initiation of the transaction. The finite start and stop point (or "call minute" as Geoff Huston referes to it) allows exchanging parties to assign cost for a specific transaction and a specific time. Since we have no such transaction basis in the Internet model, we are forced to rely on intangible metrics that can not be easily quantified. The examples are as old as "peering" itself; traffic levels, number of customers, operational impact, geographic reach, et cetera. The "peering" agreements derived from this criteria force certain parties into a virtual hierarchy. One who does not meet a specific set of intangible qualifications is not eligble for a particular arrangement that is deemed favorable, and is forced into a less favorable arrangement. Why did the majority of providers choose to adopt the settlement models of the few? Obviously they had to. What is surprising is that some parties who are obviously economically disadvantaged in such arrangements continue to fight for the model as a primary means of settlement. I say economically disadvantaged because it is often the case that in an equal trade, not all things are equal. When I look at the models in place around "peering" agreements today, I am forced to wonder who is the beneficiary in this transaction? Put in another light (and as the saying goes): If you are playing poker and can not identify the sucker, YOU are the sucker. One thing that is certain is that the current models make the benefits of more mature markets difficult to obtain. Hedging would be a primary example. Perhaps continued outages attributed to inequitable settlement arrangements will prompt greater focus on the "data transaction issue". Regards, James
The simple answer is I'm the vendor and you are the customer, so you should pay me.
The more difficult answer is one side turns off the connection (C&W) and the first side to blink is the customer (C&W). If C&W didn't feel any pain, why would they turn the peering sessions back on?
At 6/7/01 07:21 AM, James Thomason wrote:
I agree, but how do you decide who is hurt more?
And therefore who should be the vendor and who is the customer?
Is the "bigger" network always the vendor, or is the network with more content the vendor, or the network with more eyeballs the vendor? That's what I don't understand about the "balance" requirement. Ok, so you know the traffic is imbalanced, but whose fault/hurt is it when traffic is imbalanced? And who is responsible for "fixing" the imbalance in traffic?
In the telecommunications industry the role of "vendor" is played mutually depending on the initiation of the transaction. The finite start and stop point (or "call minute" as Geoff Huston referes to it) allows exchanging parties to assign cost for a specific transaction and a specific time.
Since I've been quoted in this stream, maybe I should humbly offer a few opinions masquerading as observations ( :-) ) The peering game has no real objective rules - its a game that is played out in the jungle every night - you see a pair of eyes a few inches in front of you - should you try to eat it or try to get away? Unfortunately there's not enough information to make a rational choice, so you would normally run away, but if you are also hungry at the same time..... The interactions in the inter-Provider space tend to work out to one of three outcomes: 1 Either A pays B unconditionally (and becomes a customer of B) (and, yes, this includes 'paid peering') 2 A and B do not interconnect directly, and resolve connectivity through third party interactions 3 A and B interconnect and agree not to pay each other - i.e. peering There's simply not enough information at the packet header level (the 20 bytes of IP header) to calculate a 'true' value transfer per packet passed between the two providers, so the call minute arrangement calculation used in the PSTN is simply not an option here. Instead, you inevitably arrive at one of the three outcomes above. Peering is a game of working out that there is perceived equity in the benefits of the arrangement. Sometimes this is established as equity of denial - i.e. if both parties are equally disadvantaged by NOT interconnecting directly, then peering is a logical outcome. If one party is perceived as being more disadvantaged by such an outcome, and both parties can privately admit to themselves that this is the outcome, then that party becomes the customer of the other, if they interconnect. The issue is one of figuring out equity of perceived benefit. If A works out that the benefit to A is $10 and its calculation of the benefit to B is $10, and _at the same time_ B undertakes a similar calculation and works out that the benefits to A is $20 and the benefit to B is $20, peering is still a stable outcome. Even if A works out that it is better off than B AND at the same time B works out that it is better off than A as a result, then peering is still a stable outcome. Over time A and B change their perception of their own value and their perception of the value to the other party. If A and B are peering, then A naturally wants to create a situation where if can force B to become a customer, and B has precisely the same motivation. The forcing function used is sometimes one of disconnection. Sometimes its a three or more party game - to demonstrate that A no longer relies on B's transit services, A may become a customer of C and then approach B for peering. If A can negotiate a peering relationship with B on this basis, A can subsequently renegotiate its arrangement with C. And so on and so on... Its not a bad trading market, as trading markets go. Open information of trade outcomes is available in the BGP table, so that the market can be considered to be a well informed market even though individual negotiations and outcomes are private. Its an interesting outcome to consider the BGP table as the stock exchange listing service of the inter-provider trading market. Geoff
Geoff writes:
The peering game has no real objective rules - its a game that is played out in the jungle every night - you see a pair of eyes a few inches in front of you - should you try to eat it or try to get away? Unfortunately there's not enough information to make a rational choice, so you would normally run away, but if you are also hungry at the same time.....
(Note to self: Do not walk with Geoff at night....) Permit me to humbly suggest that this metaphor is more vivid than accurate. The available behaviors include many more than fight and flight. Among others I can think of are: (honestly) offer to cooperate, (dishonestly) attempt to defraud the eyes' owner out of resources, and even call in the regulators to have *them* eat the eyes' owner instead. It's a big, wild world out there and almost everything has been tried once. Sometimes twice.
The interactions in the inter-Provider space tend to work out to one of three outcomes:
1 Either A pays B unconditionally (and becomes a customer of B) (and, yes, this includes 'paid peering')
2 A and B do not interconnect directly, and resolve connectivity through third party interactions
3 A and B interconnect and agree not to pay each other - i.e. peering
From an engineering standpoint the interactions in Inter-provider space all boil down to that one question: do these ASes exchange
I think this elides one of the most important questions: pays for what? There are cases that look like (1) where the revenue A pays B is earmarked as revenue for a layer 2 pipe to reach a POP or NAP at which layer 3 traffic is traded under terms that look (3). Is the IP traffic in that case an inducement to buy the layer 2 pipe, is the agreement a way of hiding the fact that A pays B for peering, or evidence that B still thinks like a telco? Business relationships can be convoluted; I know of cases where who pays whom is actually banded in a way that means A pays B if A sends lower than N/mbps or higher than 3N/mbps but B pays A otherwise. The motivation behind that agreement is pretty tortured (at least three of the people involved are still in therapy), but it results in A and B trading traffic. traffic directly, or is there an AS in the middle? From a business standpoint, there are as many potential interactions layered on top that simple question as there are business models drifting in the trash baskets of the VCs on Sand Hill Road. I agree with Sean Donelan that the use of the same term "peering" for "direct BGP-based traffic exchange" and "cost-free traffic exchange" makes things very difficult. Unfortunately, I can't see "neighboring" taking off as an alternative. regards, Ted Hardie
On Thu, 7 Jun 2001 hardie@equinix.com wrote:
Geoff writes:
...
The interactions in the inter-Provider space tend to work out to one of three outcomes:
1 Either A pays B unconditionally (and becomes a customer of B) (and, yes, this includes 'paid peering')
2 A and B do not interconnect directly, and resolve connectivity through third party interactions
3 A and B interconnect and agree not to pay each other - i.e. peering
From an engineering standpoint the interactions in Inter-provider space all boil down to that one question: do these ASes exchange
I think this elides one of the most important questions: pays for what? ... Business relationships can be convoluted ... traffic directly, or is there an AS in the middle? From a business standpoint, there are as many potential interactions layered on top that simple question as there are business models drifting in the trash baskets of the VCs on Sand Hill Road. ... regards, Ted Hardie
This brings up a question that I have not been able to answer definitively. Are there relationships out there where the operator of ASx pays the operator of ASy for connectivity to ASz, but with the caveat that the connectivity is through exactly one router in y's network for each peering connection? Say y and z connect in NY, SF and DC. x connects to y in DC and SF. y announces x's routes to z only in DC and SF (not in NY). Furthermore, if x and y lose connectivity in DC, then y does not announce x's routes to z in DC. It seems, for example, that a large provider could lead a coalition that would be able to fill C&W's traffic requirements, even though the lead provider would not qualify without the coalition. Is this done? Steve Schaefer Dashbit - The Leader In Internet Topology www.dashbit.com www.traceloop.com
participants (6)
-
Geoff Huston -
hardie＠equinix.com -
James Thomason -
Sean Donelan -
Steve Schaefer -
Vijay Gill