- NANOG - lists.nanog.org

Re: BBN/GTEI
by Sean M. Doran 25 Aug '98

25 Aug '98

The pizza place charges $19.95 to the recipient because it has to cover the costs of transport from the pizzeria to the customer. Car & driver don't generally work for free. Sean.

2 1

UUNET Outage in Portland OR
by Chad Skidmore 25 Aug '98

25 Aug '98

Currently UUNET is experiencing a network outage in Portland OR. Master ticket #0980776. No ETR at this time. ---------------------------------------------- Chad Skidmore Director of Network Engineering Northwest Nexus, Inc. http://www.nwnexus.com 888-NWNEXUS

1 0

Re: BBN/GTEI
by Joe Provo - Network Architect 25 Aug '98

25 Aug '98

[I really wasn't going to get involved in this mire, but this is too easy. Standard disclaimers abound.] > > 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? ...so now you are looking to dictate what business prodcuts/models someone uses? > 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. "Artificiality" applies in the telephone model, where the circuit is set up and you can't/won't/don't know about the payload [which end talks more? is there a lot of silence? does the quality suck?]. Packet switching shows a lot about the payload [packet sizes, packet frequency, and retransmissions] from both sides. > 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? The requests handled by pointy-clicky-"dub dub dub"; great wodges of traffic being burned on lossy protocols. The traffic doesn't spontaneously decide to slam down pipes to non-path-discovery Windoze dialups. The humans behind the dialups asked for something (albeit, they had no forwarnings about adverts, pictures, applets, etc etc.). Back to life, Joe -- Joe Provo, Network Architect 508.229.8400 x3006 Commercial Internet Services Group Fax 508.229.2375 UltraNet Communications, Inc., an RCN Company <jprovo(a)ultra.net>

4 3

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

25 Aug '98

Alec - You don't want to _measure_ traffic distribution, you want to use a barrier approach. This avoids messy disputes over how much should be paid for, in favour of less-messy disputes over whether the quality of what one has paid for is worthwhile. Sean.

1 0

Re: open relays at Earthlink
by Adam Todd 25 Aug '98

25 Aug '98

>ISPs sell customers a TCP/IP connection to the Internet. To me that means >taking my IP datagrams and delivering them to where I address them. I UUNET sells connections to users that allows them to deliver packets? Only problem is so many places block more and more UUNET traffic every day. Eventually UUNET will have to do something about it's inability to transit anything except the backbones and it's a pretty lonely world out there on your own. UUNET is not the only offender. Although I must compliment NETCOM.NET for their speedy and responsive fix to a SPAMER last week. I was actually SURPRISED to get a response - personalised. But it arrived and that's a credit to NETCOM. >On the other hand, I would fully support anyone's right to filter >connections from my dialin user pool addresses if they felt that they >needed to do that. I would, in my personal opinion, be happy to provide >such a person with my IP pool address ranges, or info on the domain names >we use for that (which are easy to deduce, anyway?). Please send me the list of Domain Names and IP addresses. You might have to do it via this list as we got fed up with sending requests to UUNET to sort out the SPAMING problems and just deny UU.NET totally. >(Of course, I'd rather persuade this person than my organization deals >responsibly with spammers - but no doubt I'd be unable to persuade some) Please try. I've got 20 odd forwards of SPAMS from the last two months that have had ZERO response and over 2 months from the first message, they kept coming. I guess there is a limit to patience and "seven day grace periods." >If enough people refused to take mail from my pool addresses then I guess >my customers will be duly "encouraged" to use the provided relays. (Most One hopes, but it's not the legitimate customers that are the problem and in some countries the ISPs have to foot the bill for YOUR clients sending JUNK to them anyway. It wodu lbe far cheaper for everyone to not have those little streches of SMTP spaning the world trying to make a delivery only to be rejected and instead rejected them where it doesn't cost money. >do anyway, of course) If only a few refuse to take the mail then most >deliveries still work fine directly; and those few feel happy that they >are "protected". I'm not happy. I've now got a list of SPAM relay sites that grows far to rapidly. Eventually no one will be able to send email to our networks or those of our associates. So much for "Inteenet" >Doesn't this arrangement make sense? No. Are you saying it's fine for your network users to send traffic over other peoples links to be rejected? When you know full well it will be rejected? -------------------------------------------------------------------------- Adam Todd http://adamtodd.ah.net Business Development, Technology, Domain Registration and Network Advisory Phone +61 2 9729 0565 - Todd Corporation http://www.todd.inoz.com Fax +61 2 4659 6786 - AHNET http://www.ah.net - AURSC http://www.aursc.ah.net Telstra Reseller and Telstra Convey Member (Not an Employee of Telstra) Get the DOMAIN NAME HANDBOOK NOW http://www.domainhandbook.com

1 0

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

25 Aug '98

Patrick Greenwell wrote: | Actually, since we were discussing sites such as sunsite, I think that we | at least have an idea. If we go to a settlement-based model, one can only | wonder what will happen to freeware/shareware sites. "If you like this anonymous ftp site, please send a cheque for $x to the following address..." Sean.

1 0

Re: BBN/GTEI
by mark＠exodus.net 25 Aug '98

25 Aug '98

Maybe Exodus should buy GTE :) -----Original Message----- From: Charles Sprickman <spork(a)inch.com> To: Michael Dillon <michael(a)memra.com> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Friday, August 21, 1998 11:19 AM Subject: RE: BBN/GTEI |Perhaps the best solution here is for BBN to purchase Exodus.

3 2

RE: BBN/GTEI
by I Kobi 25 Aug '98

25 Aug '98

But of course, BBN already has their own competing hosting firm, Genuity. Charles Sprickman <spork(a)inch.com> wrote >Perhaps the best solution here is for BBN to purchase Exodus. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

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

25 Aug '98

[In the message entitled "Re: BBN/GTEI" on Aug 21, 13:48, Michael Dillon writes:] > > If such scalable peering already existed, I'm convinced that the current > situation between Exodus and BBN would not have developped. So while those > two companies figure out how to handle their relationship, maybe we could > all learn from this and figure out a way to make peering work in a more > scalable manner. > I'm all for this. What metric(s) shall we use? Traffic is an obvious one. Is that measured in packets per second, or bits per second? Since, in the USA (where the vast majority of traffic originates) circuits are provisioned as full duplex, _does it matter_ which direction the bits are flowing in? You _should_ have provisioned adequately for the flow, in any event. That is, if you care about how much bandwidth your customers can use. Assuming it does matter, in which direction does the value flow? Towards the recipient, because the infrastructure for provisioning hundreds of DS3s costs more, and the provider is not billing correctly for it? Or is it towards the content provider, because the infrastructure for provisioning hundreds of web servers costs more, and the provider is not billing correctly for it? Another one is route-miles. A provider with 1,000 route-miles of circuits 'obviously' has less value than a provider with 10,000 route-miles of circuits. How does speed of those circuits factor in? Perhaps the metric should be DS0-route-miles (64K-circuits per mile). Of course, one WDM dark fiber run of 250 miles would nuke this metric. How about dollar value of the network, in total bills paid to the telcos? Does this mean that networks that are owned by telcos have an almost-zero cost, or an "full retail price" accounting cost? Are networks that have reciprical agreements with telcos unduely penalized, or do they benefit? Another good metric might be number of customers. As a fine point, does an ISP transit customer of a network count as one customer, or does it count as 30,000 customers (the number of dialup customers serviced by that ISP). Does a web content provider count as one customer, or as 5,000 customers (the number of his hosting customers). What about special cases that offer free email accounts and/or web pages, that have thousands or millions of customers? How about number of network advertisments, or routes? Would this lead to silly announcements (de-aggregation) to 'equalize' the number of routing announcements? We haven't even got to the hard points, which is *how much* each of these metrics are 'worth'. We also haven't begun to address sites like gatekeeper.dec.com, ftp.cdrom.com, and the like. Nor networks with plently of suck bandwidth (but not much content) such as MSN and AOL. It's harder than it looks on the surface, folks. Clues appreciated. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

4 3

Re: Transaction Based Settlements Encourage Waste (was Re: B
by Sean Butler 25 Aug '98

25 Aug '98

>> >> My argument was that in addition to the peering settlement charges, >> each network would charge their customers for the traffic they generate. >> So, if you ask your web hosting customers to add traffic, and actually >> pay them for that, then my customers that request content from yours >> get a bigger bill than they used to. My customers stop going to your >> customers site. (I'll provide them with an itemized bill that lets them >> see what cost so much and why.) Alex(a)netaxs.com wrote: >This is nice. Do you have any idea what kind of backend software would you >need to be able to process that much data in real-time? Netflow seems to scale up to DS-3 levels with no problems, and, in fact, I haven't seen too many problems with it on OC-3's either... Now, the UDP export to the receiver could cause some issues. But with 400MHZ processors becoming common-place, I don't think its that difficult to do. I'm not saying the technology is there today, but is there any doubt it won't be tomorrow? And in another post, mleber(a)he.net wrote: >HA. Very funny. You really intend to send out billing notices to your >clients that detail each web transaction they did? So you intend to send >you ISP customers the equivalent of an inverted access_log file which they >will in turn send to each dialup customer? For a single T1 this data runs >in the range of 1 GB per day. The cost of handling this billing >information is non zero and the cost of reviewing it is non zero. I'm not saying it needs to be an inverted access-log. A simple destination and byte count should do the trick. And of course its non-zero. Its the same with the telco's and their settlements. It costs money to do accounting, but if you are now charging for usage, I don't think you'll lose money. And if you can't account on each destination and byte count, account based on packets sent in a 10 minute interval, or something that is scaleable today. (Yeah, you lose the destination that is sending the majority of the traffic, but I don't think that would be too difficult for the customer to figure out.) But, if the majority of nanoger's feel that its impossible to do accounting on traffic flows per customer, then I'll withdraw my argument that settlement based peering could work when you charge your customers based on usage. 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

2 1