August 1998 - Test - lists.nanog.org

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

31 Aug '98

Well, the telco can't really show me proof of half the things they're billing me for either, since they don't exist. In fact, I've confirmed with the guys running the switches that I only have the number of PVCs I thought I had. The telco is still billing me for n+2 PVCs. I agree with you that ISPs are nowhere near ready to do rock-solid usage billing. My point was that the Telcos aren't either. Let's not drag ISP service down to the level of customer service that is provided by Telcos, PLEASE. Owen > On 08/28/98 01:14:36 PM owen wrote: > > > >> > >> > >> > >NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > > >Please NOT that!!! I've spent the last 6 months trying to get my > >home phone bill straightened out with MCI and PacBell has been > >overbilling me for PVC's on my Frame Relay for 18 months. > > > >Please, let's not drop the internet to the level of service we all > >complain about from the Telcos. > > well alright, they're not perfect but i seriously doubt that if an isp > customer (anyone's customer) disputed pulling down a 1.5M .zip file > sometime last month as part of their overall usage sensative bill that said > isp could show the customer proof in the log files or captured packet > traces. my only point was that we have a long way to go on the isp side. > > and if i'm wrong, i'd appreciate pointers to any rock-solid billing > software out there. > > -brett > > >

1 0

http://www.isi.edu/div7/people/bmanning.home/in-addr-audit.html
by bmanning＠ISI.EDU 30 Aug '98

30 Aug '98

The rest of the data will get added tonight for the /8 detail -- --bill

1 0

Re: BBN/GTEI
by Paul Vixie 29 Aug '98

29 Aug '98

> [...], 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. -- Paul Vixie La Honda, CA "Many NANOG members have been around <paul(a)vix.com> longer than most." --Jim Fleming pacbell!vixie!paul (An H.323 GateKeeper for the IPv8 Network)

4 8

Re: MAE-W worse than normal?
by Sean Butler 29 Aug '98

29 Aug '98

>Anyone seeing worse than normal drops at MAE-W ? We are seeing 5-10% >drops from our connection off giga2 to anything on giga1, while giga2 to giga3 >and giga4 seems to be ok... > >We're contacting MFS now to see if this is know. It seems to have started last >night some... MFS ticket is 284300, and there is blocking going towards giga 1. MFS states at least 48 hours (from last night) to contact all involved, and perhaps as late as Wednesday to correct... Here's a list of connections off giga 1: > giga1/4 198.32.136.55+198.32.184.55 maewest-sjose-fddi.cerf.net > giga1/10 198.32.136.23 mae-west.psi.com > giga1/11 198.32.136.118+198.32.184.38 mae-west-2.px.concentric.net > giga1/11 198.32.136.26 mae-west.pch.net > giga1/11 198.32.136.38+198.32.184.118 mae-west.px.concentric.net > giga1/12 198.32.136.33 mae-west.exodus.net > giga1/14 198.32.136.37+198.32.184.37 mae-west.good.net > giga1/18 198.32.184.42 Fddi9-0.San-Jose9-gw.CA.Alter.Net > giga1/19 198.32.136.56 f6.peer1.sjc1.genuity.net > giga1/21 198.32.136.15+198.32.184.15 mae-west.netcom.net > giga1/22 198.32.136.96 fddi0-0.enss221.t3.ans.net > giga1/23 198.32.136.40 fddi0-0.br4.SJC.globalcenter.net > giga1/26 198.32.136.60+198.32.184.60 > sjc2-core1-fddi-3-0-0.atlas.digex.net If you are off giga 1, you are probably seeing 5-10% loss at high use times. We noticed it starting around 15:00 - 16:00 EDT yesterday and continuing until 02:00 - 03:00 EDT.... This happened on Thursday as well. Sean __________________________________ Sean Butler, CCIE #3897 IBM Global Services -- OpenNet Support Phone: 8-631-9809, 813-523-7353 Fax: 8-427-5475 813-878-5475 Internet email: sebutler(a)us.ibm.com

1 0

Using NAT for best-exit routing
by Brian Dickson 29 Aug '98

29 Aug '98

The following is a suggestion for a scalable solution to the best-exit problem (hot-potato requests to a web farm, best-exit data return). (This was prompted by thinking about the original problem which induced the most-popular topic of late.) As far as I know it's original, so if you use it, let me know how it works, and maybe give me some credit. :-) The idea is basically this: the web farm provider uses a NAT device (or configures NAT on a router) for every peering point with a given peer who wants best-exit. Separate address pools (in private address space) are used for each such NAT (and distinct such pool sets amongst multiple such peer networks). Ingress traffic to the web farm provider has it's *source* address NAT'd, and internal routing points return traffic to the *same* NAT through which the request traffic came. Thus, return (data) traffic is best-exit. This scales as the number of flows, not as the number of addresses announced, so the MEDs scaling issue goes away. Performance may be an important factor, so it is advised that anyone trying this test it in a lab first. ;-) Pictorially ,-------- provider "G" -------. / \ | | NAT1 NAT2 | | \ / `------- web farm "E" -------' Traffic flows: West coast, G -> NAT 1 (closest)-> web farm -> NAT1 -> west coast, G (best exit) East coast, G -> NAT 2 (closest)-> web farm -> NAT2 -> east coast, G (best exit) (Also works for NATs 3,4,5,...) If the NAT can handle #flows seen, at wire speed, all is well. Limits would be the total number of simultaneous flows, and max speed of NAT. Side benefits are that the unique address pools allow for much easier per-peer and per-region collection of stats, eg netflow (at some place other than NATs). Comments? -- Brian Dickson, Email: briand(a)teleglobe.net Teleglobe USA, Inc., Tel : +1 703 821 4818 Suite 400, 8251 Greensboro Drive, Fax : +1 703 821 4885 McLean, Virginia, USA, 22102 http://www.teleglobe.com

3 2

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

28 Aug '98

Someone not worth replying to wrote: > [nothing important] Typical, really. Sean.

1 0

Re: Transaction Based Settlements Encourage Waste (was Re: BBN /GTEI)
by Brett_Watson＠enron.net 28 Aug '98

28 Aug '98

On 08/25/98 03:48:29 PM Sean M. Doran wrote: >> 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! i think this point is the single largest barrier to doing proper billing. isp billing needs to be as bullet-proof as telco/voice billing. i suspect that with many isp's (and certainly from some of my past experience) if customers would ever have disputed an invoice we wouldn't have had a leg to stand on. i'm sure some providers have good billing systems but i know many that don't yet they do some kind of usage based billing. also, as useful as netflow can be, at oc-3 speeds and higher the sheer amount of data exported can be overwhelming both to routers and trunks (in agreement with vadim). -brett

2 1

Re: Using NAT for best-exit routing
by owen＠DeLong.SJ.CA.US 28 Aug '98

28 Aug '98

> The following is a suggestion for a scalable solution to the best-exit > problem (hot-potato requests to a web farm, best-exit data return). > (This was prompted by thinking about the original problem which induced > the most-popular topic of late.) > As far as I know it's original, so if you use it, let me know how it > works, and maybe give me some credit. :-) > Depends on your definition of scalable. Please show me a NAT box that can keep up with 1.5Gbps sustained with peaks in excess of 1.9. > The idea is basically this: the web farm provider uses a NAT device > (or configures NAT on a router) for every peering point with a given peer > who wants best-exit. Separate address pools (in private address space) > are used for each such NAT (and distinct such pool sets amongst multiple > such peer networks). Ingress traffic to the web farm provider has it's > *source* address NAT'd, and internal routing points return traffic to > the *same* NAT through which the request traffic came. > Thus, return (data) traffic is best-exit. > An interesting idea, but the address management alone becomes a nightmare. Then, when you add the sheer number of customers some of the content providers have, it becomes even more complex. It would be really cool if such a system could be made to work without turning address management into an unmitigated nightmare for the content provider, but I don't see that as being too likely. > This scales as the number of flows, not as the number of addresses announced, > so the MEDs scaling issue goes away. Performance may be an important factor, > so it is advised that anyone trying this test it in a lab first. ;-) > Yeah, performance would be a BIG factor in a large content network. > Pictorially > ,-------- provider "G" -------. > / \ > | | > NAT1 NAT2 > | | > \ / > `------- web farm "E" -------' > > Traffic flows: > West coast, G -> NAT 1 (closest)-> web farm -> NAT1 -> west coast, G (best exit) > East coast, G -> NAT 2 (closest)-> web farm -> NAT2 -> east coast, G (best exit) > > (Also works for NATs 3,4,5,...) > > If the NAT can handle #flows seen, at wire speed, all is well. Limits would be > the total number of simultaneous flows, and max speed of NAT. > > Side benefits are that the unique address pools allow for much easier > per-peer and per-region collection of stats, eg netflow (at some place > other than NATs). > Could be interesting, but I don't think it scales. Owen

1 0

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

28 Aug '98

> On 08/25/98 03:48:29 PM Sean M. Doran wrote: > > >> 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! > > i think this point is the single largest barrier to doing proper billing. > isp billing needs to be as bullet-proof as telco/voice billing. i suspect > that with many isp's (and certainly from some of my past experience) if > customers would ever have disputed an invoice we wouldn't have had a leg to > stand on. i'm sure some providers have good billing systems but i know > many that don't yet they do some kind of usage based billing. > > also, as useful as netflow can be, at oc-3 speeds and higher the sheer > amount of data exported can be overwhelming both to routers and trunks (in > agreement with vadim). > > -brett > > > NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Please NOT that!!! I've spent the last 6 months trying to get my home phone bill straightened out with MCI and PacBell has been overbilling me for PVC's on my Frame Relay for 18 months. Please, let's not drop the internet to the level of service we all complain about from the Telcos. Owen

1 0

MAE-W worse than normal?
by Sean Butler 28 Aug '98

28 Aug '98

Anyone seeing worse than normal drops at MAE-W ? We are seeing 5-10% drops from our connection off giga2 to anything on giga1, while giga2 to giga3 and giga4 seems to be ok... We're contacting MFS now to see if this is know. It seems to have started last night some.... Sean ___________________________________ Sean Butler, CCIE #3897 IBM Global Services -- OpenNet Support Phone: 8-631-9809, 813-523-7353 Fax: 8-427-5475 813-878-5475 Internet email: sebutler(a)us.ibm.com

1 0