[...], even if someone is NOT doing "best exit" (or there is only one exit) that doesn't change the fact that the transit customers on the other network paid in part so they could get there!
I keep hearing this and I keep not understanding it. Let's define this in terms of sessions, where "session" means a bunch of related packets (i.e., packets with the same or symmetrical source/destination addresses and which are related to the same real-world action or end-user goal. Could be a TCP session, could be a sh*tload of DNS queries while processing a log file, could be a RealAudio(tm) stream, could be an MBONE broadcast of Grateful Dead. The quoted point is only controversial if the endpoints of a "session" are served/connected by different providers, since if there's only one provider there is no "exit" no "peering" and no problem. "Served" in this context means "carry stuff to/from this end point from/to where it's coming/going." In the current non-market economy used to fund the Internet, it's extremely rare for someone to actually pay by the bit-mile for the costs their service provider undergoes on their behalf. Billing strategies I'm familiar with are all in terms of maximum or average or peak or whatever, per unit time (like for example, T1 by the month.) In a non-market economy where costs don't determine price, costs have to be avoided rather than recovered. People who run big networks can't recover their bit-mile-related costs from their own customers, so they avoid these costs -- usually by requiring that anyone they exchange packets with at no cost be able to exchange those packets "locally" which means, at the greatest cost to the _sender's_ provider and the least cost to the _receiver's_ provider. Closest-exit routing doesn't do this. The biggest packets of the session are being carried by the person who isn't getting paid any money by the sender and is not being paid by the bit-mile by the receiver. We don't have a micropayment facility, and won't for some years yet, that can turn this into a free market where costs can be recovered rather than avoided. So you'll see folks avoiding them. And, getting back to the text I quoted to give this message context: NO. "No, the transit customers on the other network did NOT pay the costs of this traffic." Deaggregation and MEDs aren't a scalable solution to this problem. At the moment, negotiated transit or private peering are the only ways to get the costs of these bit-miles to be spread out among the people who benefit from them. This situation bears striking resemblence to the way the NBA and NFL do revenue sharing among large market and small market teams. That's not a market economy either, but we lack the technology for a market economy. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul@vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)
On Tue, Aug 25, 1998 at 08:17:48PM -0700, Paul Vixie wrote:
[...], even if someone is NOT doing "best exit" (or there is only one exit) that doesn't change the fact that the transit customers on the other network paid in part so they could get there!
In the current non-market economy used to fund the Internet, it's extremely rare for someone to actually pay by the bit-mile for the costs their service provider undergoes on their behalf. Billing strategies I'm familiar with are all in terms of maximum or average or peak or whatever, per unit time (like for example, T1 by the month.)
That's nobody's problem EXCEPT for the person who sold the transit at a non-market-based price. I dispute your assertion - pricing is in fact market-based. Whether you're on a measured ("burstable") circuit or an unmetered one, the person you buy it from has computed some statistical model which says that they can sell that transit at the price quoted and not lose their shirt. If they're wrong, they go out of business. If they're right, they make a profit. That model is between the transit customer and the provider they buy from, and is frankly nobody else's business. To assert that this model is not "market based" is to assert that in a marketplace with 5,000 US providers that there is effective collusion and pocket-stuffing going on - which I simply don't buy. The only way you can make such an attempt stick is if you have market power - which very, very few firms actually have to ANY level in this game. None of this has ANYTHING to do with what the customer has purchased - which is TRANSIT TO THE ENTIRE INTERNET. Not just the parts that someone else will pay that same provider to communicate with. Now, you might argue that some providers want to sell transit to only part of the Internet. I'd agree with you there - some providers will in fact do this; its called private negotiated peering (access only to a given backbone's customers, or to some subset of the peer relationships that a given provider has), and is ALSO a valid thing to sell someone. But general transit connections, which are what 99% of the end-user attachments are buying, are the general case and what is actually under discussion here. The fact is that when I, as a TRANSIT customer, buy a connection into Network <X>, what I have purchased is transit to the ENTIRE Internet. I don't CARE (as a customer) whether the backbone provider loses or gains on the packets I source and sink - that's the provider's problem, and their business risk to manage and express in their pricing formula (which we both agreed to when we signed our contracts). What I care about, and paid for, is the connectivity. Now if that connectivity is *deliberately* refused or interrupted, I argue that the provider is in violation of the implied covenants and warranties that attach when you sell a TRANSIT connection. This is NOT the same as an *accidental* discontinuity - we all agree, I think, that the model today is "best effort" beyond your own network infrastructure - because we can't control backhoe fade. But to turn down a peering session on purpose, or to refuse to establish one where both firms are at a public exchange, is a different matter entirely.
People who run big networks can't recover their bit-mile-related costs from their own customers
Yes they can. Its called negotiating appropriate pricing with your customers.
Closest-exit routing doesn't do this. The biggest packets of the session are being carried by the person who isn't getting paid any money by the sender and is not being paid by the bit-mile by the receiver.
So what? That's a business failure on the transit-selling firm's part, and nobody else's responsibility.
I quoted to give this message context: NO. "No, the transit customers on the other network did NOT pay the costs of this traffic."
Yes they did. If someone mis-priced a facility or service that is THEIR problem. Mispricing of a service (more accurately - lowballing a price to either capture a client from competitors or attempting to generally grab market share) is a time-honored way of building a market. What crosses the line into inappropriate behavior is when you do that and THEN try to recover the costs which you didn't properly factor into your pricing model from someone else!
but we lack the technology for a market economy.
We have a market economy. We also have firms which have historically tried to win market share not by service levels, but by lowballing quotes - and then grabbing back that which they failed to price properly from third parties when their customers actually USE what they purchased. All you have to do is look at the 2, 3, 4, or even 5-year "discount levels" that some transit firms are offering and have historically offered, and then tell me that a given transit firm has the right to offload THEIR business risk (which they now may be unhappy with, but were clearly happy with at the time they signed the original deal!) on someone else's back! Balderdash!
Paul Vixie
-- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
On Wed, Aug 26, 1998 at 02:41:58PM -0500, Karl Denninger wrote:
None of this has ANYTHING to do with what the customer has purchased - which is TRANSIT TO THE ENTIRE INTERNET. Not just the parts that someone else will pay that same provider to communicate with.
CustA - NetA <-> NetB - CustB. Both customer are _buying_ for transit for the whole source-destination path, but are _paying_ only for (in this case) half of it. Customers share the costs, because providing service to each other is considered beneficial. Therefore networks A and B peer if traffic is roughly equal or exchange traffic with settlement fees if not. -- tuomas.toivonen@fishpool.fi fishpool creations ltd http://www.kasvua.org/~toivotuo/ http://www.fishpool.fi/
On Thu, Aug 27, 1998 at 12:41:54AM +0300, Tuomas Toivonen wrote:
On Wed, Aug 26, 1998 at 02:41:58PM -0500, Karl Denninger wrote:
None of this has ANYTHING to do with what the customer has purchased - which is TRANSIT TO THE ENTIRE INTERNET. Not just the parts that someone else will pay that same provider to communicate with.
CustA - NetA <-> NetB - CustB. Both customer are _buying_ for transit for the whole source-destination path, but are _paying_ only for (in this case) half of it. Customers share the costs, because providing service to each other is considered beneficial. Therefore networks A and B peer if traffic is roughly equal or exchange traffic with settlement fees if not.
-- tuomas.toivonen@fishpool.fi fishpool creations ltd http://www.kasvua.org/~toivotuo/ http://www.fishpool.fi/
That's your view of the world, but its not reality. Assume CUSTb is a web server, and CUSTa is a T1 connected client. CUSTa sends a TCP SYN, accepts an ACK, and transmits 40 bytes of a URL. CUSTb responds to the SYN, accepts and ACK (3-way handshake) and transmits, in direct response to the URL request, 200KB of data back to the CUSTa. Now, NETb has a net deficit of packets to NETa. NETa says "pay up or else" and demands a settlement from NETb; a settlement which NETb cannot collect on, as NETb has no means of assessing CUSTa, which is the cause of the traffic so generated. NETb says "bite me", correctly perceiving that they should not allow arbitrary people to write blank checks on their accounts. NETa drops peering in response to the "bite me". NETa's customer drops their connectivity contract for a material breach of their agreement (deliberate interferance with their connectivity to NETb) and shops elsewhere. Who just lost by NETas activities here? That's what I thought. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
On Thu, Aug 27, 1998 at 12:10:20PM -0500, Karl Denninger wrote:
On Thu, Aug 27, 1998 at 12:41:54AM +0300, Tuomas Toivonen wrote:
On Wed, Aug 26, 1998 at 02:41:58PM -0500, Karl Denninger wrote:
None of this has ANYTHING to do with what the customer has purchased - which is TRANSIT TO THE ENTIRE INTERNET. Not just the parts that someone else will pay that same provider to communicate with.
CustA - NetA <-> NetB - CustB. Both customer are _buying_ for transit for the whole source-destination path, but are _paying_ only for (in this case) half of it. Customers share the costs, because providing service to each other is considered beneficial. Therefore networks A and B peer if traffic is roughly equal or exchange traffic with settlement fees if not.
That's your view of the world, but its not reality.
Risking being repetitive I disagree with your basic assumption as the web surfer being 'the cause' and therefore ruining the model of settlements based peering.
Assume CUSTb is a web server, and CUSTa is a T1 connected client.
CUSTa sends a TCP SYN, accepts an ACK, and transmits 40 bytes of a URL.
CUSTb responds to the SYN, accepts and ACK (3-way handshake) and transmits, in direct response to the URL request, 200KB of data back to the CUSTa.
Now, NETb has a net deficit of packets to NETa. NETa says "pay up or else" and demands a settlement from NETb; a settlement which NETb cannot collect on, as NETb has no means of assessing CUSTa, which is the cause of the traffic so generated.
This is where I don't agree with you. Yes, net-b certainly can't bill cust-a (the web surfer) which is why it bills its own client cust-b (the web server). Cust-b gladly pays because it has agreed to provide service to cust-a and has calculated that whatever it pays to its service provider, net-b, will be paid back by cust-a (perhaps site subscription fees or increased sales). So net-b pays its settlement fees to net-a from cust-b's pockets. Point is: the web surfer is only secodary cause to any traffic generated. Primary cause is the web server providing content to be browsed. Web server wants its content accessed and is willing to pay. (Funny thing is that the web surfer is also willing to pay which is why Internet economics work and it is heaven for marketing purposes.)
NETb says "bite me", correctly perceiving that they should not allow arbitrary people to write blank checks on their accounts.
NETa drops peering in response to the "bite me".
NETa's customer drops their connectivity contract for a material breach of their agreement (deliberate interferance with their connectivity to NETb) and shops elsewhere.
Who just lost by NETas activities here?
That's what I thought.
-- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
-- tuomas.toivonen@fishpool.fi fishpool creations ltd http://www.kasvua.org/~toivotuo/ http://www.fishpool.fi/
On Fri, Aug 28, 1998 at 10:56:01AM +0300, Tuomas Toivonen wrote:
On Thu, Aug 27, 1998 at 12:10:20PM -0500, Karl Denninger wrote:
CUSTa sends a TCP SYN, accepts an ACK, and transmits 40 bytes of a URL.
CUSTb responds to the SYN, accepts and ACK (3-way handshake) and transmits, in direct response to the URL request, 200KB of data back to the CUSTa.
Now, NETb has a net deficit of packets to NETa. NETa says "pay up or else" and demands a settlement from NETb; a settlement which NETb cannot collect on, as NETb has no means of assessing CUSTa, which is the cause of the traffic so generated.
This is where I don't agree with you. Yes, net-b certainly can't bill cust-a (the web surfer) which is why it bills its own client cust-b (the web server). Cust-b gladly pays because it has agreed to provide service to cust-a and has calculated that whatever it pays to its service provider, net-b, will be paid back by cust-a (perhaps site subscription fees or increased sales). So net-b pays its settlement fees to net-a from cust-b's pockets.
Point is: the web surfer is only secodary cause to any traffic generated.
On the contrary. The server, sitting there on its own, causes no traffic to be generated at all.
Primary cause is the web server providing content to be browsed. Web server wants its content accessed and is willing to pay.
Are you sure about that? What if the server provider already thinks they are paying, and doesn't like having their pocket picked at the whim of the browser?
(Funny thing is that the web surfer is also willing to pay which is why Internet economics work and it is heaven for marketing purposes.)
If there were no alternatives you'd be right. But there are alternatives. CUSTb can, instead of displaying the content CUSTa wants, display a screen (in plain text, and therefore very cheap to send) saying "your provider is being a jerk and trying to charge us for what we think you probably believe you already paid for; either enter your VISA number (in which case we'll send what you asked for, and you'll get billed for it) or find a new ISP that believes your service agreement is worth something". Now, if you wish to postulate that *ALL* providers do what NETa is doing, then my next question is "how did that happen?" The answer to THAT question is one that a whole gaggle of lawyers would likely find very interesting. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
On Fri, Aug 28, 1998 at 03:03:09AM -0500, Karl Denninger wrote:
On Fri, Aug 28, 1998 at 10:56:01AM +0300, Tuomas Toivonen wrote:
On Thu, Aug 27, 1998 at 12:10:20PM -0500, Karl Denninger wrote:
CUSTa sends a TCP SYN, accepts an ACK, and transmits 40 bytes of a URL.
CUSTb responds to the SYN, accepts and ACK (3-way handshake) and transmits, in direct response to the URL request, 200KB of data back to the CUSTa.
Now, NETb has a net deficit of packets to NETa. NETa says "pay up or else" and demands a settlement from NETb; a settlement which NETb cannot collect on, as NETb has no means of assessing CUSTa, which is the cause of the traffic so generated.
This is where I don't agree with you. Yes, net-b certainly can't bill cust-a (the web surfer) which is why it bills its own client cust-b (the web server). Cust-b gladly pays because it has agreed to provide service to cust-a and has calculated that whatever it pays to its service provider, net-b, will be paid back by cust-a (perhaps site subscription fees or increased sales). So net-b pays its settlement fees to net-a from cust-b's pockets.
Point is: the web surfer is only secodary cause to any traffic generated.
On the contrary. The server, sitting there on its own, causes no traffic to be generated at all.
Putting up a server is _agreeing_ to generating future traffic. Amount of that traffic can be reasonably estimated and transit for it bought. The transit provider uses fees collected from the server operator to 1) buy further transit or 2) buy "peering" with appropriate settlement fees.
Primary cause is the web server providing content to be browsed. Web server wants its content accessed and is willing to pay.
Are you sure about that? What if the server provider already thinks they are paying, and doesn't like having their pocket picked at the whim of the browser?
The web surfer's behaviour is not the cause for any possible misfortune. Either the web server operator ot its service provider has made a misjudgement in estimating traffic patterns from web surfing and therefore will go out of business.
(Funny thing is that the web surfer is also willing to pay which is why Internet economics work and it is heaven for marketing purposes.)
If there were no alternatives you'd be right. But there are alternatives.
Perhaps, but I am not satisfied by the below example. ;=)
CUSTb can, instead of displaying the content CUSTa wants, display a screen (in plain text, and therefore very cheap to send) saying "your provider is being a jerk and trying to charge us for what we think you probably believe you already paid for; either enter your VISA number (in which case we'll send what you asked for, and you'll get billed for it) or find a new ISP that believes your service agreement is worth something".
Uh, huh, this is not quite the real world. I certainly would like to see a corporate marketing dude even considering that. If connectivity to cust-a (surfer) sucks then cust-b will take net-b by the throat and demand something to be done (in essence net-b will pay settlement to net-a or lose cust-b).
Now, if you wish to postulate that *ALL* providers do what NETa is doing, then my next question is "how did that happen?"
It is not nice, but contrary to what you claim the big net is in better positions than the web farm when settlement fees come into discussion.
-- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
-- tuomas.toivonen@fishpool.fi fishpool creations ltd http://www.kasvua.org/~toivotuo/ http://www.fishpool.fi/
Uh, huh, this is not quite the real world. I certainly would like to see a corporate marketing dude even considering that. If connectivity to cust-a (surfer) sucks then cust-b will take net-b by the throat and demand something to be done (in essence net-b will pay settlement to net-a or lose cust-b).
Realizing that most large co-located websites are in facilities or at network providers who have many OTHER large co-located websites, the chances are great that cust-a will notice slow or no connectivity to MANY websites. Who do you think he will blame? : a.) net-a b.) net-b c.) cust-b Of course net-a, he pays net-a $$ for connectivity, the customer will not take many 'its on their side' answers from net-a, he will demand that net-a fix his connectivity or he will leave. -- Steven O. Noble -- Sr. Backbone Engineer, Exodus Communications (EXDS) -- Work:408.346.2333 -- All my love to the Canadian Mooing Frog.
On Fri, Aug 28, 1998 at 10:50:58AM -0700, steve@altrina.exodus.net wrote:
Uh, huh, this is not quite the real world. I certainly would like to see a corporate marketing dude even considering that. If connectivity to cust-a (surfer) sucks then cust-b will take net-b by the throat and demand something to be done (in essence net-b will pay settlement to net-a or lose cust-b).
Realizing that most large co-located websites are in facilities or at network providers who have many OTHER large co-located websites, the chances are great that cust-a will notice slow or no connectivity to MANY websites. Who do you think he will blame? :
a.) net-a b.) net-b c.) cust-b
Of course net-a, he pays net-a $$ for connectivity, the customer will not take many 'its on their side' answers from net-a, he will demand that net-a fix his connectivity or he will leave.
Yes, but when cust-a has bad connectivity to cust-b (and other co-located sites) I would see net-b receiving pressure from cust-b to improve connectivity to net-a. When customer is able to make demands to provider money has exchanged hands and provider has (should with a viable business model) means to pay settlement. -- tuomas.toivonen@fishpool.fi fishpool creations ltd http://www.kasvua.org/~toivotuo/ http://www.fishpool.fi/
participants (4)
-
Karl Denninger -
Paul Vixie -
steveļ¼ altrina.exodus.net -
Tuomas Toivonen