August 1998 - NANOG - lists.nanog.org

Re: BBN/GTEI (fwd)
by MegaZone 26 Aug '98

26 Aug '98

Once upon a time Austin Schutz shaped the electrons to say... > BBN should either find a way of making dialup profitable or get in to >other lines of service. Trying to extort money from peers is a ludicrous >waste of time. Um - BBN/GTEI doesn't DO dialup. The only dial we have is the DiaLinx wholesale dial reselling. There is GTE.net, but that's a completely seperate animal. GTEI/BBN does 56K-T3 lines, managed firewalls, web hosting, dial outsourcing, managed VPN, etc. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia!

1 0

Re: BBN/GTEI (fwd)
by MegaZone 26 Aug '98

26 Aug '98

Once upon a time Mark Tripod shaped the electrons to say... >Maybe Exodus should buy GTE :) No, that's Bell Atlantic. ;-) -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.gweep.net/> <URL:http://www.megazone.org/> Hail Discordia!

1 0

Re: Transaction Based Settlements Encourage Waste (was Re: B
by Sean M. Doran 26 Aug '98

26 Aug '98

Mike Leber asked: | Don't you mean senders here? (You seemed to be proposing a senders pay | system.) If not, of course receivers would continue to participate, they | earn money under your scenario for each bit they receive! A transmitter always has the option not to send. If they are unwilling to pay the receiver, they just don't send to it. Note that transmitters and receivers here are not end-to-end, but rather hop-by-hop, organizationally speaking. That is, sender host/site pays its provider, which pays the next provider which pays the next provider which pays the destination. What is paid is a business negotiation, clearly, and one option is that the payment amount is zero (i.e., I will only send you traffic if I don't have to pay for it). Basically that last sentence is precisely the issue between BBN and Exodus (cf. I will only accept traffic from you if you pay for it). Sean.

2 1

Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
by Sean M. Doran 25 Aug '98

25 Aug '98

> What about netflow ? [to Vadim Antonov who said that _metering_ traffic is intractable] Dear ISP - you have made an accounting error that I am able to demonstrate in my copious traffic logs. Please credit $x to my account. or Dear Customer - our copious traffic logs indicate that you generated x traffic last month. Please pay $x net 30 days. Thank you. Dispute resolution -- it's fun! Sean.

2 1

Re: Transaction Based Settlements Encourage Waste (was Re: BBN/GTEI)
by Chris A. Icide 25 Aug '98

25 Aug '98

Applying the current model of the telco transaction based settlement to the current end-user pricing model of the Internet is broken. There is a major disconnect between the two. When a standard telephone call is made one or the other end-user supplies revenue to the company/organization which supplies thier local service. Whereas in the Internet today, both sides pay for the privelege of having a full time open (or long-term part time open) connection to the network. These Internet end-users do not look anything like telephone end-users. Any attempt to apply the current telco model to the Internet model without significant rewriting of one or both will most likely be a taxation upon anyones sanity. There is another disconnect within the Internet that should (if it isn't already) be driving stong change that would most likely invalidate any hack that is developed on the current model. Whereas the cost of delivering packets outside of a small geographical area (call it the "Zero-mile" area) is based upon milage and bandwidth used. Currently in the US most bandwidth is sold at a flat price per Mbit. Whether or not it's billed upon usage or billed upon some predetermined level that the user cannot exceed. This constitues another disconnect between base cost of goods and revenues of sales. As the industry grows more mature, these need to be tied together, otherwise in the end, the end-user will be gouged in one manner or another, and the disconnect of COGS versus Revenues tends to lead toward artificial operating costs. -Chris

4 4

Re: Generation of traffic in "settled" peering arrangement
by owen＠DeLong.SJ.CA.US 25 Aug '98

25 Aug '98

> Owen DeLong wrote: > > > > Actually, if the content provider simply honors MEDs, that should cover most > > of the issue. Then, the long haul is done across the content providers' > > backbone anyway. > > Then you get into address aggregation issues that have already been > discussed before. > > The way I see it, an intelligent content distribution scheme addresses the > vast majority of these concerns. > > So, a question to the large web farms. Why is it that the largest web sites > still seem to be hosted out of a single data center? > Where do you get your data? It seems to me that the bulk of the largest web sites with which I am familiar are located in at least two datacenters. > Alec > Owen Senior Network Engineer Exodus > -- > +-------------------------------------+----------------------------------+ > |Alec H. Peterson - ahp(a)hilander.com | Lead Network Architect | > |http://www.hilander.com | Erols Internet - an RCN Company | > +-------------------------------------+----------------------------------+ >

5 6

Re: Generation of traffic in "settled" peering arrangement
by John Curran 25 Aug '98

25 Aug '98

At 03:15 PM 08/24/1998 -0700, Patrick Greenwell wrote: >>... >> Customers who receive traffic currently bear some of the costs >> and the sending customer bears some of the costs. In the case >> of an off-net sender with shortest-exit routing and no offsetting >> traffic in the other direction, the receiving customer ends up >> bearing all of the costs. > >Well, my understanding is (and someone correct me if I am wrong) in at >least the case of Exodus, they aren't using closest-exit. I can completely >understand requiring peers not use closest-exit. That seems somewhat >reasonable. I was not referring to any particular peering relationship, only problems brought about by closest-exit peering in the presence of highly assymetric traffic. >I haven't seen anything in these recent discussions to suggest that BBN >would be offering me a discount on inbound traffic since now the sender >would be paying for it. In the case of traffic coming coming from a peer network with wildly asymmetric traffic, the sending network is paying to offset the traffic assymetry; this returns the economics to that of a balanced peer or an on-net sender (which is the normal case today). /John

2 1

Re: There's no substitute for value, was Re: BBN/GTEI
by Sean Donelan 25 Aug '98

25 Aug '98

johnl(a)iecc.COM (John R. Levine) writes: >Lest anyone think this "pay for value" approach is too complex to be >used in the real world, consider the relationship between your local >CATV provider and its programming sources. The provider pays for HBO, >takes local broadcast for free, and gets paid for infomercial >channels. And the reason why the US Congress enacted "must-carry" was ? And the reason why Murdoch is buying both content generators and distribution channels was ? Why do things always look simple from the outside ? Where is Andy Rooney when you need him ? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Generation of traffic in "settled" peering arrangement
by Jerry Scharf 25 Aug '98

25 Aug '98

who pays for the root nameserver traffic? The ISC goes out of business if we have to pay the traffic rates for keeping a root. jerry

2 1

Re: Generation of traffic in "settled" peering arrangement
by Sean M. Doran 25 Aug '98

25 Aug '98

Actually the distribution problem is pretty simple. In your forwarding table add a per-prefix cost. The cost is expressed in terms of tokens. The tokens are deducted from a token bucket. The number of tokens in the bucket (depth and refresh-rate) is arrived at by some engineering or sales process. This polices MEDs nicely. Sean.

2 1