- Test - lists.nanog.org

Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
by owen＠DeLong.SJ.CA.US 22 Aug '98

22 Aug '98

> On Sat, 22 Aug 1998, Mike Leber wrote: > > > If your split isn't 50/50 (in other words settlement free) I guarantee > > anybody with half a brain will balance out their traffic by hosting the > > correct type of applications so that you owe them money. > > Of course if everybody does this, then the traffic will balance out. Seems > to be a good thing to create the incentive, no? > > > In fact, TRANSACTION BASED SETTLEMENTS ENCOURAGE WASTE to the point where > > it should be obvious to the casual observer that anybody reasonably > > informed would never suggest them. > > Then I must be unreasonably informed because I think that some form of > exchanging money to even out imbalances would give providers more choice. > No, I think your just missing his point, whether deliberately or not... The point was that althoug the traffic flows would appear balanced, they would be artificially balanced by wasteful automatons asking for or delivering traffic with no benefit just for the sake of consuming bandwidth in the opposite direction in order to balance assymetry. > > The factors that are the cause of the inherent problem with transactions > > based settlements are: > > > > 1) Either party can end up paying. > > 2) Transactions are generated by machines. > > 3) Machines can generate transactions which are either positive flow or > > negative flow. (web servers vs web crawlers as two simplistic examples). > > OK. So now you've convinced us that network traffic shres a number of > characteristics with electric power distribution. Yet the power companies > seem to manage quite well with settlements. I wouldn't want to slavishly > imitate their system any more than I want to slavishly imitate the long > distance telcos. But these things can be made to work. > There's a difference. Power is inherently a one-way flow, and whichever way it is flowing obviously has a TO is purchasing from FROM value system built in. This is not inherently true in IP traffic, and so the model doesn't work as well. > > Oh, and before anybody comes up with a simplistic (and flawed) rebuttal > > such as banning the large web crawlers from settlements, there are plenty > > of other legitimate automated methods of getting flows in either > > direction. > > They aren't legitimate if the sole purpose of the method is to create > traffic; that would be fraud. A webcrawler would be fine if it was for a > search engine but not if you just ran it and discarded the data. > It's not fraud if you create real traffic. It's only fraud if you claim traffic that didn't exist. Reread the legal definition of fraud. > -- > Michael Dillon - Internet & ISP Consulting > Memra Communications Inc. - E-mail: michael(a)memra.com > Check the website for my Internet World articles - http://www.memra.com > > > Owen

1 0

Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
by William Allen Simpson 22 Aug '98

22 Aug '98

> From: Michael Dillon <michael(a)memra.com> > They aren't legitimate if the sole purpose of the method is to create > traffic; that would be fraud. A webcrawler would be fine if it was for a > search engine but not if you just ran it and discarded the data. > Are you telling me that your model requires examination of the content of packets, and auditing the "legitimate" internal practices of the hosts? Are you telling me that I should not duplicate packets, as that would be "fraud"? Are you telling me that I should not fill my pipe with duplicate Acks, as that would be "fraud"? Michael, go home, take the weekend off, and in your spare time, re-read RFCs 1 to 1123. Take special note that duplication of packets is permitted, even encouraged. Your model does not correspond to the Internet. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

3 2

RE: BBN/GTEI
by owen＠DeLong.SJ.CA.US 22 Aug '98

22 Aug '98

> If we look at any other downstream, or end, customer, they still pay their > provider for a full circuit's worth of bandwidth. Even if they are not > symmetrically using their bandwidth. So, you pay not only the telco, but > your upstream provider for use of data in both directions. ISPs use > customers like this to not only balance their traffic patterns with other > services that suck massive bandwidth (such as universities and dialup), but > to provide additional revenue (by not discounting a circuit in half because > they primarily use traffic headed in one direction) > OK, I completely agree with you so far. > A network that has chosen a business model that is tailored towards outbound > only transit should be prepared to pay for transit the same way their > customers do. Their customers should pay a premium to have a network that > is better connected than they could provide themselves, not so their > upstream can reap the benefits of not having to pay for their own transit. > These companies have opted towards a business model that does not balance > traffic, thus making it difficult to be a "peer" with a network. > I don't get the connection. True, Exodus has a business model tailored towards OUTBOUND flows, but not OUTBOUND TRANSIT. The outbound flows are exactly a portion of the INBOUND traffic above. Nothing else. > This, of course, brings up many, many interesting questions about which > companies have the right to be at the top of the network pyramid. Although > it seems the market place has already determined this, at least a majority > of it. > That's assuming a pyramid is necessary, desirable, etc. In fact, there's no real need for such a pyramid, but at the moment, there does seem to be a small number of larger providers with increasing numbers of providers as you reduce the size of said provider. > This shift in costs have been a long time coming, you can't charge your > customers for bandwidth, and then not expect to have to pay for it yourself. > Exactly. That's exactly why I think that Exodus/BBN are peers and that the assymetrical nature of the relationship is mostly irrelevant at this point. As you've pointed out, the BBN customer pays BBN for a full circuits worth of bandwidth. Exodus provides to BBN what those BBN customers request from Exodus. Exodus does not charge those BBN customers (or BBN) for the requests or related ACKs, nor does Exodus charge the BBN customers or BBN for the data being delivered across Exodus network to the point where BBN has told Exodus they would like to receive the traffic for that customer. Given that, I don't see how you say anyone is currently charging customers for bandwidht and not paying for it themseleves. Exodus runs a very large national network, with very high growth rates. > -jamie > jamie(a)networked.org > > The views stated above are mine and do not reflect those > of my employer. > The views I have expressed are mine and may or may not coincide with my employer. Owen > -----Original Message----- > From: Michael Dillon [mailto:michael@memra.com] > Sent: Friday, August 21, 1998 7:44 PM > To: nanog(a)merit.edu > Subject: Re: BBN/GTEI > > > On Fri, 21 Aug 1998, Karl Denninger wrote: > > No, its actually becoming MORE suitable. Instead of burning the entire > > circuit in both directions, you're only burning half of it now (one > > direction). > > You still have to pay for the whole circuit. > > -- > Michael Dillon - Internet & ISP Consulting > Memra Communications Inc. - E-mail: michael(a)memra.com > Check the website for my Internet World articles - http://www.memra.com > > >

1 0

RE: GTE BBN - Rand originated BUSINESS MODEL discussion
by Richard Irving 22 Aug '98

22 Aug '98

You cannot configure your router from this message... warning. This is continuation of the "BLUE SKY INTERNET BUSINESS MODEL" discussion. Obviously I am missing something..( I may be naive on this) Why would you want to charge hosters for hits ? (seriously !) I cannot conceive charging an author of a popular book for everyone who reads a copy.... Most could never afford it.... Worse, popularity would create hardhship. Now streaming UDP, (UNI/MULTI) growing in popularity so rapidly for multimedia distribution, could be originator based. More of a Television Industry method... The origin would want to make sure they have the credit card of the user who is about to tune into their latest "multimedia transmission" before they start the *push* based application. (Back to "no surprises" concept) Also, to someone else's point... (in a *much* more *real world now* discussion :) In my *opinion*: Your right, details of peering should be between peers. It already *is* between telco's... Next "Lata" (Peer AS's ?) transactions should go to the owner of the physical. (Which if they pull to you, is them...) (If you pull to them, it is you... If you choose not to charge, your choice! ) (Bonus: Owner of last physical collects the *hypothetical* acks fee's.) However, in my heart, I do not feel that the users are *not* responsible... They performed an "ACTION" to cause that data to flow... The hoster did *not*...... Remember, NO surprise bills! I really feel that this is a better philosophy.. I would hate someone being able to call my grandmother collect, without her having the option to say *NO*.... Also, popularity *should be* *desirable* on the internet. But, lets look at the economics of it... THE WORLD could decide to descend on "IGGY the IGUANA" ( a simple mid-west families site hosted on our circuits, *extremely popular* with children worldwide..) Now, should that family be billed 1 million at the end of the month ? Or, should the provider be billed 1 million. Which of these should be punished for providing interesting content ? Or , how about, the 1 billion users who went there ?? What if they were all billed about .001 cents for that transaction, would they be discouraged? I Don't think so... You billed the same 1 million dollars, but everybody paid a price about equal to the service's they received. (and with the hypothetical ack fee's, the ISP could afford to put up pipe to support IGGY's popularity) ("Morris the Cat" sure never "hurt" for cat food :\ Regarding complexity of DS0m/s billing..... Certainly this could be approached with a "region uniform pricing" to the end users... "Surf AnyWhere in the Continental North America, for a simple flat fee .0004c DS0/s! With "Sprat Cents" no more confusing bills" (Any relationship to a real companies approach is purely hysterical, er.. hypothetical ;) But, that wouldn't mean that the *providers* wouldn't settle up in a more controlled detailed fashion... (or maybe not, interesting....) "Cross MCI pathways for a simple .0001 cents a DS0/second, good anywhere in continental america, and your MCI local region remains free" Finally, a fiscal motive to peer. Also, given a hypothetical unit DS0mile/seconds.. What would prevent someone from routing poorly to increase the "cost of call", as the "maximum throughput" (which in turn would generate volume in terms of DS0 *mile* seconds) does not go down *that* linearly with distance... maybe you could throw in a *real* shoe... Mile bands are based on *geography*, not physical path taken. ;) Or even upon "regions" (AS's with SUB-'AS's, a model already currently in use [check your AS-SETS], and regional LATA's). This sure could motivate inter-provider meshing..... And assist in reducing "across the street, via MAE-E" routing... Thoughts? The more efficiently your route your data, the greater the margin, as the costs are reduced... Less efficient ? Your loss, higher cost of call.. You absorb it. (In terms of reduced margins) Now data loss becomes an issue.. This unfortunately would be a challenging issue, as it is the pipe of the ISP connected to a "poor quality" NSP that will be consumed by lossy fabric. Perhaps the accumulated CDR would result in fiscal punishment to the lossy NSP.. "5000 DS0/s were delivered to said NSP, 4000 DS0/s were completed resulting in 150000 DS0m/s".. collected. Hrmmmmm.. A reason to change NSP's ? After all, that NSP is losing you money. NSP's who have a greater completion rate would be a competitive angle... Better circuit, better management = greater DSO/s completion ratio = Competitive advantage. "Use NSP SOMEPROVIDER. We guarantee a 98% DS0/s completion ratio, if *your* DS0/s completion ratio drops below this threshold we will pay you any ways." small print follows, DS0 Second payments based on average "DS0 miles" accumulated on existing completed seconds of traffic, UDP exclusion clause, etc, etc... Maybe I should get some coffee.... I am taking this too seriously. :\

2 2

Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
by dlr＠bungi.com 22 Aug '98

22 Aug '98

[In the message entitled "Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)" on Aug 22, 11:26, Michael Dillon writes:] > On Sat, 22 Aug 1998, William Allen Simpson wrote: > > > Are you telling me that I should not fill my pipe with duplicate Acks, > > as that would be "fraud"? > > No. I'm saying that if you generate spurious traffic with the > *INTENT* of creating a revenue stream to you then you are probably > committing fraud. If the duplicate acks are created by a program that > serves no other useful purpose then it would be just as fraudluent as if > you were to set up a 900 number, don a bicycle messenger's outfit, and > visit downtown offices asking to use the phone for a momemnt and then > calling your 900 number. > Where's the line? If I set up "free dial-in accounts, all you can eat", do I get settlement peering? How about free T1's? Free DS3's? This isn't the right answer. Like it or not, data has value. Bits have value. The size of the packets cannot be the only metric used. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: BBN/GTEI
by William Allen Simpson 22 Aug '98

22 Aug '98

> From: Michael Dillon <michael(a)memra.com> > On Fri, 21 Aug 1998, Owen DeLong wrote: > > > Sure, but only the assymetry that results from BBN customers ASKING for more > > than they OFFER. > > Or is it the asymmetry that results from Exodus customers OFFERING more > than they ASK FOR? > > I don't think one of these views has any claim to precedence over the > other. Just because long distance phone calling introduced the purely > artificial concept that the initiator of the transaction pays for it does > not mean we should analyze IP traffic in the same way. In the past, on other topics, Michael often has had thoughtful responses, but this time he has gone off the deep end (and is drowning). Long distance carriers charge the initiator, even when the initiator merely sits and listens to the content coming toward them, using little or no bandwidth the other direction. 800 number services charge the terminator, instead. Both models are in vogue. But they depend upon: 1) the initiator and terminator being obvious, 2) a setup time, 3) total circuit time much greater then the setup time. IP traffic has none of these characteristics. Who is the "initiator" for the FTP data PORT? PASV? What setup time? What circuit time? We are "packet" oriented, not "circuit" oriented. > In the past we have > considered the initiator of IP transactions to be irrelevant and had > no-charge peering for networks that basically send a similar number of > bytes to what they receive. > > So what do we do when that is no longer the case? > Those of us who have been around longer then most, remember that this has _NEVER_ been the case. My simple telnet to a host (circa '78...) delivered far more to the screen than my typed commands, even with an old teletype or decwriter. My FTPs from Simtel20 to Umich to MSU (circa '84-92) usually were asymmetric, except when I was making a submission. My POP{2,3} (circa '86, '88) was (and still is) asymmetric! WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

4 3

Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
by Richard Irving 22 Aug '98

22 Aug '98

(Caution you cannot configure from this post...) Mike Leber wrote: > > As much as I like your idea :) I still have to poke holes in it. > Your *supposed* to.. that is creative collaboration. :) > On Sat, 22 Aug 1998, Richard Irving wrote: > > Hoster's are rewarded for gaining popularity. (receiver) > > They also get rewarded for have very large images, and 24 hour contious > sound files, and live video, and contiously updating web pages. *Live* video, and sound are usually push based. (See UDP/MULTI discussion) Otherwise, someone *clicked* to receive that stream.. Cacher's ? SYN fee, Ack fee, but reduced DS0mile/s... = Margin. (And cheaper surf) I am not sure what to do with the large images... Hrmmmm..... But, if the user didn't like the site, or it was slow.....and resulted in increased costs.. They wouldn't request the content as often. (Maybe ?) However, ** Imperative ! ** Hopefully any *single* ** web page a surfer hits would *almost* be inconsequential.. But, we are back to informing/involving the end user.... :( What to do with Continued Updates ?? Thoughts anyone... TCP based "Subscribers" should know.... (Option in browser to allow expires/refreshes/streams to work, after hitting site, like JAVASCRIPT, triggers a pop-up asking for permission ?) GOOD points, though !!! > > Again, incentivizing bad behavior. Traffic for traffic's sake. Probably would be better than incenting poor connectivity, at least we are motivating internet content, and connectivity. Without it, we would evolve to the PSTN. :( It sure would flesh out the "richness" of the surf "multimedia experience" :} And provide a method to compensate for that increased transmission volume... So, all of sudden "big" content doesn't cream pipe's, it pays for them. Local Browsers track DSO/s (Volume) from sites... Provides "Volume Util Analysis" with a click... And you learn to avoid those sites with the highest DS0/s/Per Page rating... Unless you really *like* that site... (It might, however, disourage the "surfing accelerators", why request a page you *may* not read....) Really, our problem isn't "big content", it is being able to get it there.... Today transmission is a balanced math equation , with *one* side of the equation "fixed" Our current model implies minimizing content transmission, because the sides *must* balance... Fix one side of the equation, and it will fix the other side... We keep trying to preach efficiency. (Content reduction) because pipe costs per volume today, are fixed... If those costs aren't so fixed.... Volume no longer becomes the concern, it becomes desirable, and supports itself, creating more pipe. The goal. Just thoughts... sure needs polish!

1 0

Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
by dlr＠bungi.com 22 Aug '98

22 Aug '98

[In the message entitled "Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)" on Aug 22, 12:03, "John A. Tamplin" writes:] > When enough CLECs are concentrating on businesses that only have > incoming calls (ISPs, tech support centers, 900-style services, etc), Bell > will scream to the FCC that termination charges need to be reevaluated. > With this approach, eventually *no one* will want customers that make lots > of outbound calls -- let the other providers have them and then collect the > money when they call your customers. This has already happened in California, and many deals that were contingent on settlement fees for termination of calls are not so attractive any more. It also seems to be very difficult for CLECs (like Brooks) to obtain sufficient trunks from Pacific Bell to be able to terminate the number of calls that they want... Go figure. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
by dlr＠bungi.com 22 Aug '98

22 Aug '98

[In the message entitled "Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)" on Aug 22, 7:55, Michael Dillon writes:] > On Sat, 22 Aug 1998, Dave Rand wrote: > > > All I can say is that if settlements are based on who is receiving > > the traffic, there will be huge increase in the amount of money > > that networks pay to attract everyone's favortive smurf target, > > the IRC servers. A 2-day-long 100 Mbps smurf will be _encouraged_ :-) > > The peer whose network the SMURF originates in will trace that back to the > source so fast you'll smell the rubber burning. DoS based on large numbers > of packets will be a thing of the past. > _Sure_ they will. Someday. But they won't be able to contact the customer/university until monday morning, and the 2 days smurf-fun will elapse, and that will adjust the 95th percentile data for the month appropriately. But the fact is that the vast majority of networks do not charge for bandwidth used - and _that_ (not the direction) is the core of the problem. If you bill customers for what they _use_, versus the size of the pipe, you have: 1) A positive incentive for them to control the amount of data they use.. If they are sourcing data, they will make sure that they adjust the graphics and so on to be efficient. I _know_ that customers do this, on at least one major network. If they are sinking data, they have a reason to put in a cache, and better manage their users. I _know_ that customers do this, on at least one major network. 2) A positive incentive for the network owner to keep ahead of the bandwidth. Currently, if a company buys a T1 - the NSP has _no_ incentive to ever permit the customer to use more than 300 bps over it. In fact, there is negative incentive to provide adequate bandwidth. You make _more_ money by _not_ ungrading the backbone, and overselling the crap out of it. I _know_ that NSP's do this, on at least one major network. Currently, there is a strong incentive for networks that source a lot of data to better interconnect to networks that sink a lot of data. As a classic example, the data rate to AOL doubled the day a large network added a private interconnect to AOL, instead of going through ANS. Was this because ANS was underprovisioned, because the slow start algorithm sucked on the TCP implementation, or because the latency was reduced? In this new model you propose, who cares? Private interconnects like this would just Not Happen. This makes the net worse for everyone. Large scale interconnections between networks are a good thing. Settlement based peering may be a way to do that, but the metrics for how to do this are not clear. Strictly looking at the size of the flows between peers does not appear to be the correct way to measure this. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: BBN/GTEI
by dlr＠bungi.com 22 Aug '98

22 Aug '98

[In the message entitled "Re: BBN/GTEI" on Aug 21, 23:20, Bruce Hahne writes:] > >On-net facilities have made distance-sensitive pricing in most metro areas a > >thing of the past. Sub $0.04 per DS0-mile long-haul rates have made long > >haul circuits very affordable. High speed WDM dark fiber routes will make > >long haul very, very cheap in the next 2 years. > > This is the old "bandwidth is so cheap that it's free" argument. True, > bandwidth is now inexpensive enough for a single DS0 that it's becoming > counterproductive, from a marketing standpoint, for the telco to attempt to > differentiate based on distance for a voice call. But if we're ever to > arrive at the day when I can turn on my 100Mbps video-over-IP feed to my > home PC over my FTTH connection, and expect to actually get reasonable > performance, we're probably going to need both metering and inter-provider > settlements. > What I said was "distance-sensitive pricing in most metro areas" is not a market reality. Billing for bandwidth used is a good thing. Billing for packet-flow-ds0-miles-per-aardvark is madness. Figure out what your costs are, and bill your customers appropriately. A customer in Borneo is going to have to pay more that a customer in Borneo, Idaho, who may have to pay more than a customer in Dallas, who may have to pay more than a customer in New York. Large metro areas have economies of scale that make very high speed pipes available. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0