August 1998 - Test - lists.nanog.org

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

Re: BBN Peering issues
by Sean Donelan 22 Aug '98

22 Aug '98

fair(a)clock.ORG (Erik E. Fair) writes: >If this perception breaks down, watch out. Theodore Vail was allowed to >create the regulated monopoly AT&T in the early part of this century on the >promise of Universal Service, which meant not only that everyone had a >telephone, but that *all* telephones could call *all* other telephones - >one big, happy, PSTN. I think the history of Western Union interconnections with other telegraph companies may be more interesting. At one point the US Congress passed a law requiring Western Union interconnect with other telegraph companies. How many other telegraph companies can you remember? Missouri still has a law on the books imposing a $25 per day fine on any telecommunications company which doesn't offer interconnection to other telco's in the state. Perhaps the amount of the fine hasn't kept up with inflation since the law was originally enacted, I suspect several large providers would willing pay $25/day in perputity to not intereconnect with their competitors. But the sentiment remains. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: BBN/GTEI
by Richard Irving 22 Aug '98

22 Aug '98

Jeff Mcadams wrote: > > Thus spake Richard Irving > >============================================================== > >***As the originator of syn, *actively requested* content.*** > >============================================================== > I know... I had the same *exact* thought on the way home.. :) (PASV) Also, some about UDP. :\ Transmitter Paid ? But, as you realize the stuff of pricing this model is not inplace yet, (although, most have the skeletons laying around) Lots of things could be given thought ...... For example.. Mileage banding. Cost for "call" = INBAND XX DS0Mile/Seconds + YY OUTBAND DS0Mile/Seconds (Ie: What I should have called earlier SYN path, and ACK path to coin terms) The earlier math didn't expound upon async flows.. :\ Interesting ramifications if you roll out towards that model. It sort of parallels the book, and record industry, as well. Gain popularity.... And you local NSP will "build" out to *you*! (ACK clustering, and final mileage.) :) > Nit-pick...ftp/ftp-data. Maybe a suggestion that we switch completely > to pasv mode? (certainly would make ACL's easier to deal with :) > -- > Jeff McAdams Email: jeffm(a)iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456

1 0

RE: BBN/GTEI
by Jamie Scheinblum 21 Aug '98

21 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) 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. 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. 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. -jamie jamie(a)networked.org The views stated above are mine and do not reflect those of my employer. -----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: BBN/GTEI
by William Allen Simpson 21 Aug '98

21 Aug '98

I'm a bit tired of the flood we are having, on an old topic we put to rest years ago. Remember the "economists" showing up on the IETF list? Here is the answer from the previous go 'round, tailored to the recent imbroglio. If GTE/BBN is concerned about asymmetry in bytes or packets, then Exodus should oblige them! (1) Once a day, gather a list of all BBN IP destinations. (2) Route all these destinations thru a special socks proxy, or modify the TCP accept() to check the destination. (3) Cut the MSS to the minimum 48 bytes. (4) Disable slow start threshhold advancement, forcing an Ack per data packet. (5) Add a _red_ _blinking_ _text_ warning to all main hosted pages (for everyone), stating clearly that GTE/BBN is experiencing slow service and congestion, that faster service can be had thru another provider, and list those providers that are recommended. You might even be able to get folks to pay you to add them to the list. That will take care of the asymmetry problem, both technically and financially! Those of you who have been around longer than most :-) will remember that I was (and still am) an advocate of the dial-up subscriber fees being subsidized by the content providers, just as we had in the old days when the universities provided both the destination servers (content) and the dial-up modem pools. Dialing in was free. Accessing the servers was not free. The reason for the network was rarely for the subscribers to talk to each other. They already need authentication to access the "content", even their own POP3 accounts. We appear to be coming back to that older model, with "free" dial-up subsidized by advertising at the providers. But I am strongly opposed to the big "middle" carriers charging both ends. It would never happen in a truly competitive market. It is clear that mergers such as GTE/BBN have passed the monopoly/oligopoly barrier. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0