Isn't being a pioneer doing best-exit to eliminate the cost imbalances?
I thought that was the whole idea behind what BBN/Exodus were doing.
I don't know your network and BBN's well enough to do anything but guess
here, but wouldn't there still be asymmetry in the number of bits of
traffic exchanged, even with best exit?
I'm not sure if the things I am discussing are directly applicable to your
situation with BBN but if you think some of this stuff could work and are
willing to try it, why not ask BBN if they would consider some sort of
interim agreement while you work out the details. I guess I'm the kind of
guy who always looks for a creative, off-the-wall, "think different" kind
of solution to a problem in negotiations. The worst the other folks can
say is no. But sometimes they say hmmm...
That is nice, but it doesn't change the fundamentals of what is going on.
That is, 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!
[...], 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.
> [...], 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!
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.
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.
>
> > 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.)
>
> 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.
> >
> > 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.
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.