Your fundamental assumption that all peering arrangements MUST be free is just plain wrong.
I made no such claim. My claim was that Sprint's paying customers pay Sprint to send and receive packets to and from folks connected to Cogent, regardless of the arrangement Sprint negotiates with Cogent.
You say that Cogent could have paid for a connection to route to Sprint's network via somewhere else. I say that Sprint could have paid for a connection to route to Cogent's network via somewhere else. Who do you figure has more pressure from their paying customers to stay connected?
If Sprint wants to double-dip and Cogent is willing to let them, so be it. As it happens, Cogent wasn't willing and when Sprint realized that keeping their paying customers is more important than collecting money from Cogent, they blinked.
I'm reasonably sure that using a service constitutes a certain implicit acceptence of terms.
Companies would like you to believe that's the way it works. It makes their lives easier if you do. But when the rubber meets the road, that's not the way of things.
Contracts are a "meeting of the minds." That means that in order to form a contract, both parties must understand the terms and signal their assent. I'll assume that at least some people at both Cogent and Sprint understood the terms. While its possible to implicitly signal assent, its tough to prove. If a Cogent exec says, "Well, we had no idea Sprint had changed the terms and certainly never agreed to it," Sprint would have to produce a letter in which Cogent did agree to it or they'd fail to prove assent. Additionally, explicit always beats implicit. If Cogent made the effort to say, "No, the terms you offer are not acceptable," (and they surely did) then there is no contract and Sprint continued the service without any contractual expectation of being paid for it.
That's a fine explanation but unfortunately it doesn't describe peering.
Transit: You pay an ISP to send and receive traffic to and from "the Internet." "The Internet" consists of: his paid customers, his peers and (recursively) anybody he pays for an Internet Transit connection. When you say, "I have an Internet connection," that means a transit connection.
Peering: You arrange with an ISP to send and receive traffic to and from his paid customers only. The peer network -does not- pass your traffic to his peers or transit connections, only to his paid customers. Because his paid customers have already paid him to carry this traffic from you (just as yours have paid you to carry the traffic to him) such a connection is often "settlement free" meaning that neither peer network pays the other for the privilege of a connection or the packets sent across it.
So, in your example the two neighbors would be peering if they ran the cable between them but -did not- share each other's DSL connections. There would be no point asking a third neighbor to pay to be added because the third neighbor would only be able to talk to you... not the Internet via you and not even your first neighbor via you.
What is the deal with this 'equal traffic' nonsense.
The theory is that the "eyeball" networks which receive most of the traffic cost more to build since they had to be connected to all the locations where your and my eyeballs happen to be. The origin networks, on the other hand, are just a few buildings with computers in them... barely any network infrastructure at all. As a result, the eyeball networks are more valuable. So if you send me more traffic that I send you, you should pay me for the difference in value.
Sprint probably decided to block Cogent's routes from the rest of their peers.
Correction: this was in fact not the case. Cogent made a choice not to try to pay anybody to connect them to Sprint. Their position was that since Sprint's customers paid Sprint to connect to Cogent as much as Cogent's customers paid Cogent to connect to Sprint, they shouldn't have to pay anybody to make that connection. Sprint made no attempt to prevent Cogent from connecting via another ISP.
you don't seem to understand how the Internet works.
I pay my ISP to deliver my packets for you to your ISP and you pay your ISP to deliver packets to you that arrive from my ISP. Same in the other direction.
The Sprint/Cogent issue is happening at that border between the two ISPs where the packet has already been paid for by the two customers on either side.
if I stopped paying for my web server's bandwidth,
If you stopped paying for your web server's bandwidth, your ISP should and would stop carrying those packets to the border with your fans' ISPs.
Sprint was fearing for their own customers, the ones who pay Sprint to deliver their packets to "the Internet," including that part of it connected to Cogent. Customers who might ask Sprint, "What do you mean Cogent didn't pay you? I paid you!" If Sprint wasn't trying to double-dip by getting their customers and Cogent to both pay for the same packet, none of this would have happened.
A contract offer not accepted is rejected. Sprint chose to keep Cogent connected without a contract, allegedly in the hope of negotiating a paid transit agreement. Fine, but that was Sprint's decision; it's not binding on Cogent. It isn't as if Cogent said, "Well, lets keep it running while we talk about an appropriate monetary agreement." Cogent steadfastly refused to accept anything other than settlement-free peering.
Also, bear in mind that Sprint is trying to double-dip. Settlement-free peering means that I agree to accept packets from you because the only packets you'll send me are addressed to one of my customers who has already paid me to receive those packets. Likewise, I'll send you packets which you tell me that someone has already paid you to receive.
Sprint wants to collect money twice for the same packet: both from their subscribers and from Cogent.
It's about Cogent trying to leech for free AND Sprint trying to unilaterally change a contract (which they have no right to do) instead of simply ending it (which they do have a right to do.) Both companies have misbehaved.
I'm with you right up to the point where Sprint tried to unilaterally convert a settlement-free peering trial into a paying account. Sprint had the right to end the peering trial. They crossed the line instead.
Sprint was just [...] trying to find a way to work with Cogent
Baloney. These companies weren't unknown to each other. Everybody in this agreement understood perfectly well that the deal was for settlement-free peering and if it didn't work out it would be discontinued. There was never any intent to buy on Cogent's part nor did Sprint harbor any serious illusion that there was.
Cogent understood that when they failed to accept Sprint's paid peering offer, Sprint would cut them off at Sprint's pleasure.
Sprint drank their own koolaid with the idea that they can somehow unilaterally change the agreement and Cogent's inaction would constitute acceptance. It's the old penny-record scam where you get a record for a penny but then they send you another record at full price every week and you have to send each one back or pay for it.
Cogent figure that Sprint would try to pull this kind of stunt so they led Sprint right down the garden path, keeping connection alive outside of any contractual obligation to pay for it.
Both companies have behaved dishonorably here. I don't shed a tear for either one of them.
If Cogent was your sole provider at this point, you'd either be an idiot or completely out of touch. This isn't the first time this has happened with Cogent. It isn't the second either. And it surely won't be the last.
Sprint doesn't get off so easy though. They pulled what amounts to a "sure, try it risk free for 3 months. Cancel if you don't like it, but if you fail to inform us in triplicate you owe us hundreds of thousands of dollars." That's a crock.
Nobody who initiates a settlement-free peering agreement intends to pay for a transit connection if the trial period doesn't work out. If there was a serious chance that Cogent could be convinced to buy service from Sprint, Sprint would never have agreed to peering since the two types of connection are mutually incompatible. And Sprint damn well knows it.
Then too, Sprint probably decided to block Cogent's routes from the rest of their peers. Otherwise I expect Cogent would simply have routed around the downed connections. That was a step too far, one which makes Sprint a dangerous selection as your sole carrier as well.
The problem with that argument is that as a governor and mayor, Sarah Palin has more relevant experience for President as the 1-heartbeat away candidate than Barack Obama does as the 0-heartbeats away candidate.
My biggest fear with Obama is that he'll be another Jimmy Carter: a bright but unprepared president whose closest advisers are his bright but inexperienced gang from back home. I sincerely wish he'd given me the opportunity to vote for him in 2016, after broadening both his experience and circle of advisers.
A hard drive is not analogous to an individual disk. Rather, a hard drive is comprised of many platters, or magnetic data storage units, mounted together. Each platter, as opposed to the hard drive in its entirety, is analogous to a single disk as discussed in Runyan.
It's probably too late now. You needed to open them up immediately, rinse them out with a spray of clean water, place them in a dry location and evaporate the water with forced, cool air (e.g. with a fan). If they've been sitting wet and stagnant for a few days corrosion may have set in. If so, your chance of recovering them is practically nil.
DNS is still unworkable as a failover mechanism. Existing software simply isn't very good about honoring the TTL. The primary API for accessing the DNS (gethostbyname) doesn't even return the TTL to the application.
That's like buying a second computer, doing no backups and then finding out if the first computer malfunctions it has to still work well enough to copy your files to the second computer or else you're screwed.
If reliability is important enough to you that you're willing to pay for two Internet connections, you don't want to "often" be able to recover from one of them failing.
TYhe provider whose link drops might be required to temporarily carry an extra route itself to re-direct any left over packets for the non-functioning link.
Unfortunately, the provider in the midst of a failure can't be reliably expected to accomplish anything with success, least of all a redirection task. The whole point of multihoming is to address the case when operations at one of the providers are -not- working.
It's not any kind of IF. The DNS-change approaches have been thoroughly investigated and proved unwieldy to the point of uselessness. The Shim6 folks gave tried to find a way to modify existing IPv6 TCP to allow for multiple addresses and got the same result.
We had to invent two new terms for network addresses to describe the problem: locator and identifier. A locator specifies a node's location within the network hierarchy while an identifier uniquely identifies it. The layer-3 IP address in both IPv4 and IPv6 overloads both functions. That's root cause of the routing scalability problem: Locators aggregate well. Identifiers don't. As long as the layer-3 address serves as an identifier, it won't aggregate well enough for the routing system to scale.
I personally suspect that we also need to differentiate between a node identifier, a service identifier and a session identifier. The rest of the RRG isn't there yet, but if you think about it, a node identifier doesn't serve much of a purpose. We want one because there has always been one, but it really doesn't doesn't help us to know that a particular machine exists independent of any services that machine may provide. What we really need are service identifiers (e.g. http at www.slashdot.org) and session identifiers (my particular http connection to www.slashdot.org).
The service identifier is needed to map a service (such as a web site) to the locators that currently provide the service. The session identifier is needed to keep track of individual communications sessions even though the locators in use change while the session is ongoing.
But in all fairness, we've now moved past what's proven and into my own personal hypothesis.
It may be that some business arrangements simply cannot scale and will have to be modified (not an uncommon situation in business anyway, change happens).
Unfortunately, we're not talking about oddball hair-brained business relationships. We're talking about the basic paid transit and peering relationships which have been the foundation of the commercial Internet ever since the NSF announced its intention to end the NSFnet way back in the early '90s.
It may be that portable IP space will need to be limited
This has already been done. The maximum savings we're going to achieve from provider aggregately addresses has already been achieved by ARIN. That's why we only have 260k routes in the table right now instead of 2M. The plain reality, though, is that anybody from the smallest home office to the largest corporation who wants to multihome with two or more Internet Service Providers must announce portable address space. And as the Internet invades our lives ever more thoroughly, the need for reliability via multihoming is only going to increase.
Correct, For C, the route to left area is B. For G, the route to left area is F. Neither announces a route to left area over the C-G peer link because they're not willing to route each other's traffic to left area.
Actually, you have to announce the left area route over the peering link or you end up with a connectedness problem. It isn't evident in this diagram but its a trivial matter to draw one where it is.
Anyway, if C's route to E is via the left-area route from B then C steals B's bandwidth to get to E, an unacceptable situation. To change that, you have to radically redesign the business model for the Internet, something that has a lot lower chance of happening than deploying a new protocol to replace IPv6.
Slashdot Mirror
Your fundamental assumption that all peering arrangements MUST be free is just plain wrong.
I made no such claim. My claim was that Sprint's paying customers pay Sprint to send and receive packets to and from folks connected to Cogent, regardless of the arrangement Sprint negotiates with Cogent.
You say that Cogent could have paid for a connection to route to Sprint's network via somewhere else. I say that Sprint could have paid for a connection to route to Cogent's network via somewhere else. Who do you figure has more pressure from their paying customers to stay connected?
If Sprint wants to double-dip and Cogent is willing to let them, so be it. As it happens, Cogent wasn't willing and when Sprint realized that keeping their paying customers is more important than collecting money from Cogent, they blinked.
I'm reasonably sure that using a service constitutes a certain implicit acceptence of terms.
Companies would like you to believe that's the way it works. It makes their lives easier if you do. But when the rubber meets the road, that's not the way of things.
Contracts are a "meeting of the minds." That means that in order to form a contract, both parties must understand the terms and signal their assent. I'll assume that at least some people at both Cogent and Sprint understood the terms. While its possible to implicitly signal assent, its tough to prove. If a Cogent exec says, "Well, we had no idea Sprint had changed the terms and certainly never agreed to it," Sprint would have to produce a letter in which Cogent did agree to it or they'd fail to prove assent. Additionally, explicit always beats implicit. If Cogent made the effort to say, "No, the terms you offer are not acceptable," (and they surely did) then there is no contract and Sprint continued the service without any contractual expectation of being paid for it.
Well, Cogent just did and Sprint blinked.
That's a fine explanation but unfortunately it doesn't describe peering.
Transit: You pay an ISP to send and receive traffic to and from "the Internet." "The Internet" consists of: his paid customers, his peers and (recursively) anybody he pays for an Internet Transit connection. When you say, "I have an Internet connection," that means a transit connection.
Peering: You arrange with an ISP to send and receive traffic to and from his paid customers only. The peer network -does not- pass your traffic to his peers or transit connections, only to his paid customers. Because his paid customers have already paid him to carry this traffic from you (just as yours have paid you to carry the traffic to him) such a connection is often "settlement free" meaning that neither peer network pays the other for the privilege of a connection or the packets sent across it.
So, in your example the two neighbors would be peering if they ran the cable between them but -did not- share each other's DSL connections. There would be no point asking a third neighbor to pay to be added because the third neighbor would only be able to talk to you... not the Internet via you and not even your first neighbor via you.
What is the deal with this 'equal traffic' nonsense.
The theory is that the "eyeball" networks which receive most of the traffic cost more to build since they had to be connected to all the locations where your and my eyeballs happen to be. The origin networks, on the other hand, are just a few buildings with computers in them... barely any network infrastructure at all. As a result, the eyeball networks are more valuable. So if you send me more traffic that I send you, you should pay me for the difference in value.
Yeah, it is nonsense. But that's the deal.
How is offering an alternative 'unilaterally converting' anything?
The part were Sprint sues Cogent for non-payment on the never-accepted alternative.
But your Sprint/Cogent dialog is pretty much on target.
Sprint probably decided to block Cogent's routes from the rest of their peers.
Correction: this was in fact not the case. Cogent made a choice not to try to pay anybody to connect them to Sprint. Their position was that since Sprint's customers paid Sprint to connect to Cogent as much as Cogent's customers paid Cogent to connect to Sprint, they shouldn't have to pay anybody to make that connection. Sprint made no attempt to prevent Cogent from connecting via another ISP.
you don't seem to understand how the Internet works.
I pay my ISP to deliver my packets for you to your ISP and you pay your ISP to deliver packets to you that arrive from my ISP. Same in the other direction.
The Sprint/Cogent issue is happening at that border between the two ISPs where the packet has already been paid for by the two customers on either side.
if I stopped paying for my web server's bandwidth,
If you stopped paying for your web server's bandwidth, your ISP should and would stop carrying those packets to the border with your fans' ISPs.
Sprint was fearing for their own customers, the ones who pay Sprint to deliver their packets to "the Internet," including that part of it connected to Cogent. Customers who might ask Sprint, "What do you mean Cogent didn't pay you? I paid you!" If Sprint wasn't trying to double-dip by getting their customers and Cogent to both pay for the same packet, none of this would have happened.
A contract offer not accepted is rejected. Sprint chose to keep Cogent connected without a contract, allegedly in the hope of negotiating a paid transit agreement. Fine, but that was Sprint's decision; it's not binding on Cogent. It isn't as if Cogent said, "Well, lets keep it running while we talk about an appropriate monetary agreement." Cogent steadfastly refused to accept anything other than settlement-free peering.
Also, bear in mind that Sprint is trying to double-dip. Settlement-free peering means that I agree to accept packets from you because the only packets you'll send me are addressed to one of my customers who has already paid me to receive those packets. Likewise, I'll send you packets which you tell me that someone has already paid you to receive.
Sprint wants to collect money twice for the same packet: both from their subscribers and from Cogent.
It's about Cogent trying to leech for free AND Sprint trying to unilaterally change a contract (which they have no right to do) instead of simply ending it (which they do have a right to do.) Both companies have misbehaved.
I'm with you right up to the point where Sprint tried to unilaterally convert a settlement-free peering trial into a paying account. Sprint had the right to end the peering trial. They crossed the line instead.
Sprint was just [...] trying to find a way to work with Cogent
Baloney. These companies weren't unknown to each other. Everybody in this agreement understood perfectly well that the deal was for settlement-free peering and if it didn't work out it would be discontinued. There was never any intent to buy on Cogent's part nor did Sprint harbor any serious illusion that there was.
Cogent understood that when they failed to accept Sprint's paid peering offer, Sprint would cut them off at Sprint's pleasure.
Sprint drank their own koolaid with the idea that they can somehow unilaterally change the agreement and Cogent's inaction would constitute acceptance. It's the old penny-record scam where you get a record for a penny but then they send you another record at full price every week and you have to send each one back or pay for it.
Cogent figure that Sprint would try to pull this kind of stunt so they led Sprint right down the garden path, keeping connection alive outside of any contractual obligation to pay for it.
Both companies have behaved dishonorably here. I don't shed a tear for either one of them.
If Cogent was your sole provider at this point, you'd either be an idiot or completely out of touch. This isn't the first time this has happened with Cogent. It isn't the second either. And it surely won't be the last.
Sprint doesn't get off so easy though. They pulled what amounts to a "sure, try it risk free for 3 months. Cancel if you don't like it, but if you fail to inform us in triplicate you owe us hundreds of thousands of dollars." That's a crock.
Nobody who initiates a settlement-free peering agreement intends to pay for a transit connection if the trial period doesn't work out. If there was a serious chance that Cogent could be convinced to buy service from Sprint, Sprint would never have agreed to peering since the two types of connection are mutually incompatible. And Sprint damn well knows it.
Then too, Sprint probably decided to block Cogent's routes from the rest of their peers. Otherwise I expect Cogent would simply have routed around the downed connections. That was a step too far, one which makes Sprint a dangerous selection as your sole carrier as well.
The problem with that argument is that as a governor and mayor, Sarah Palin has more relevant experience for President as the 1-heartbeat away candidate than Barack Obama does as the 0-heartbeats away candidate.
Well, if he turns out to be another Bill Clinton I'll enthusiastically support him in 2012.
My biggest fear with Obama is that he'll be another Jimmy Carter: a bright but unprepared president whose closest advisers are his bright but inexperienced gang from back home. I sincerely wish he'd given me the opportunity to vote for him in 2016, after broadening both his experience and circle of advisers.
The same judge also said:
A hard drive is not analogous to an individual disk. Rather, a hard drive is comprised of many platters, or magnetic data storage units, mounted together. Each platter, as opposed to the hard drive in its entirety, is analogous to a single disk as discussed in Runyan.
Which is thoroughly asinine.
It's probably too late now. You needed to open them up immediately, rinse them out with a spray of clean water, place them in a dry location and evaporate the water with forced, cool air (e.g. with a fan). If they've been sitting wet and stagnant for a few days corrosion may have set in. If so, your chance of recovering them is practically nil.
DNS is still unworkable as a failover mechanism. Existing software simply isn't very good about honoring the TTL. The primary API for accessing the DNS (gethostbyname) doesn't even return the TTL to the application.
That's like buying a second computer, doing no backups and then finding out if the first computer malfunctions it has to still work well enough to copy your files to the second computer or else you're screwed.
If reliability is important enough to you that you're willing to pay for two Internet connections, you don't want to "often" be able to recover from one of them failing.
TYhe provider whose link drops might be required to temporarily carry an extra route itself to re-direct any left over packets for the non-functioning link.
Unfortunately, the provider in the midst of a failure can't be reliably expected to accomplish anything with success, least of all a redirection task. The whole point of multihoming is to address the case when operations at one of the providers are -not- working.
It's not any kind of IF. The DNS-change approaches have been thoroughly investigated and proved unwieldy to the point of uselessness. The Shim6 folks gave tried to find a way to modify existing IPv6 TCP to allow for multiple addresses and got the same result.
We had to invent two new terms for network addresses to describe the problem: locator and identifier. A locator specifies a node's location within the network hierarchy while an identifier uniquely identifies it. The layer-3 IP address in both IPv4 and IPv6 overloads both functions. That's root cause of the routing scalability problem: Locators aggregate well. Identifiers don't. As long as the layer-3 address serves as an identifier, it won't aggregate well enough for the routing system to scale.
I personally suspect that we also need to differentiate between a node identifier, a service identifier and a session identifier. The rest of the RRG isn't there yet, but if you think about it, a node identifier doesn't serve much of a purpose. We want one because there has always been one, but it really doesn't doesn't help us to know that a particular machine exists independent of any services that machine may provide. What we really need are service identifiers (e.g. http at www.slashdot.org) and session identifiers (my particular http connection to www.slashdot.org).
The service identifier is needed to map a service (such as a web site) to the locators that currently provide the service. The session identifier is needed to keep track of individual communications sessions even though the locators in use change while the session is ongoing.
But in all fairness, we've now moved past what's proven and into my own personal hypothesis.
It may be that some business arrangements simply cannot scale and will have to be modified (not an uncommon situation in business anyway, change happens).
Unfortunately, we're not talking about oddball hair-brained business relationships. We're talking about the basic paid transit and peering relationships which have been the foundation of the commercial Internet ever since the NSF announced its intention to end the NSFnet way back in the early '90s.
It may be that portable IP space will need to be limited
This has already been done. The maximum savings we're going to achieve from provider aggregately addresses has already been achieved by ARIN. That's why we only have 260k routes in the table right now instead of 2M. The plain reality, though, is that anybody from the smallest home office to the largest corporation who wants to multihome with two or more Internet Service Providers must announce portable address space. And as the Internet invades our lives ever more thoroughly, the need for reliability via multihoming is only going to increase.
Correct, For C, the route to left area is B. For G, the route to left area is F. Neither announces a route to left area over the C-G peer link because they're not willing to route each other's traffic to left area.
Actually, you have to announce the left area route over the peering link or you end up with a connectedness problem. It isn't evident in this diagram but its a trivial matter to draw one where it is.
Anyway, if C's route to E is via the left-area route from B then C steals B's bandwidth to get to E, an unacceptable situation. To change that, you have to radically redesign the business model for the Internet, something that has a lot lower chance of happening than deploying a new protocol to replace IPv6.