- Test - lists.nanog.org

RE: BBN/GTEI
by Jason Zigmont 24 Aug '98

24 Aug '98

Really the answer to all of the peering questions is that it is one big game of chicken. You have four players: Exodus GTEI/BBN Exodus's customers BBN's Customers The real question is who will pull out first. I do not agree with GTEI/BBN's tactics, but unfortunately they need to do what they need to do. The nature of peering is that it is voluntary. Therefore people can choose what their peering policy is. If Exodus gives in first then GTEI won. If GTEI gives in then Exodus and the rest of the smaller players win. (Which is better, of course). Which side will win is dependant on the customers. This is the danger of running a network dependant strictly on peering arrangements. But a network of peering is cheaper then one that is backed up by transit circuits. But this is a different business model then Exodus. No matter what happens, the end result will be a corner stone of what the Internet will become. Its not a technical issue. Its a business issue. There may be technical justifications, but it is still a business issue. Jason ____________________________________________________ Jason Zigmont (N1JIV) jzigmont(a)globalcenter.net Senior Account Executive 212.618.9625 (V) Frontier GlobalCenter 212.571.2036 (F) http://www.globalcenter.net 1.888.795.3124(Pager) Coalition Against Unsolicited Commercial E-mail http://www.cauce.org

1 0

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

24 Aug '98

> At 11:00 AM 08/24/1998 -0700, Owen DeLong wrote: > >... > >Except, John, that you ignore the fact that you have basically required > >anyone who wants to put a high-bandwidth server on your network to accept > >other people writing a blank check for them, regardless of the legitimacy > >of the hits they receive. > > Owen, > > Clarify... right now, many organizations with high-speed connections > to the Internet pay based on usage (including traffic sent). Doesn't > anyone on a usage-sensitive leased-line connection pay based on the > traffic regardless of the "legitimacy" of the hits received? Isn't > this why we all hunt down SMURFers? > > /John > > To some extent that's true. However, as a counter-point, consider such sites as sunsite, wustl, smc.vnet.net, etc. I doubt those sites would continue to exist in a solely bandwidth sensitive pay-as-you-go world. I think they count on flat rate connectivity to be able to continue to exist. I don't think the elimination of those sites (and many others like them) would benefit the net. Do you? Owen

3 2

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

24 Aug '98

> This ignores the fact that both companies have paying customers. If I am a > BBN access customer and I cannot get to any sites, then what good is BBN to > me? As an access provider, I built a access infrastructure and I get payed > by my customer for providing it to them (include in this cost is the price > to connect to content providers). If I am a Exodus customer and I pay for > hosting, Exodus is no good to me if it doesn't have any viewers. Exodus > built a hosting infrastructure, its customers pay for the right to use that > infrastructure(included in this cost is the price to connect to viewers). So > both companies need each other. Both companies get payed for providing a > service. Where is the problem? Why should BBN get a cut of what Exodus's > cutomers pay? BBN is trying to get payed to provide something it needs to > from Exodus. If BBN needs it, why would Exodus pay for it? Isn't BBN trying > to get payed twice? > If you are a BBN access customer, then you BUY TRANSIT FROM BBN. That's not ignored below, that puts you in the category of people that should make noise. Personally, I agree with your position. Owen > > -----Original Message----- > > From: Michael Dillon [SMTP:michael@memra.com] > > Sent: Friday, August 21, 1998 9:13 AM > > To: list(a)inet-access.net > > Subject: Re: BBN/GTEI > > > > On Fri, 21 Aug 1998, Brian Wallingford wrote: > > > > > If you don't peer with or buy > > > transit from GTEI, sit back, shut up, and watch and learn (seriously - > > > WATCH and LEARN). > > > > This is seriously good advice. A lot of people have compared this to the > > UUNet peering flap but the two incidents couldn't be more different. In > > UUNet's case you had John Sidgemore, an economist, attempting to throw his > > weight around and push towards a paid peering scenario with a cartel at > > the core, all of this based solely on an economics viewpoint. > > > > But with BBN, there is a network engineering problem at the core of the > > issue, that of assymmetric traffic patterns. And BBN realizes that this > > sort of assymmetry will become more and more common in the future and that > > the industry needs to find some sort of hybrid peering/settlement > > mechanism that will work for both parties in an asymmetric arrangement. > > They are looking at things like what kind of methodology can be used to > > measure the traffic, what constitutes free balanced peering, how to charge > > for regional transit on traffic that exceeds the limits of balanced > > peering, and similar difficult issues. > > > > I believe that the reason we are not hearing many details is that there > > are NDAs in place about the specifics of the Exodus, AboveNet and CRL > > peering contracts. But sooner or later those companies will come to some > > sort of agreement and BBN will explain the rationale behind their > > thinking. We may not totally agree with that rationale, but I think we can > > all see that establishing peering between two specialty providers has to > > be handled a bit differently than between two full-service providers. > > > > And if BBN's ideas can be refined and accepted by the industry, then we > > will be in a better position because there will be an established > > methodology and pricing structure for an ISP to transition from full > > transit to full peering. I know from my experience with Priori that a lot > > of peering negotiations happen like an old-boys club cartel and if you > > ain't a member of the club, you can't get in. We need to change this so > > that there is an open process by which anyone can transition to being a > > peer based on an open and accepted methodology and pricing structure. > > > > -- > > 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: Generation of traffic in "settled" peering arrangement
by Sean M. Doran 24 Aug '98

24 Aug '98

John Curran wrote (to someone not really worth bothering with): | Clarify... right now, many organizations with high-speed connections | to the Internet pay based on usage (including traffic sent). Doesn't | anyone on a usage-sensitive leased-line connection pay based on the | traffic regardless of the "legitimacy" of the hits received? Isn't | this why we all hunt down SMURFers? Moreover, the technology to mitigate the damage caused by an increase in demands on a traffic-generating service is straightforward. Several companies have inventive solutions for doing admissions control and traffic shaping, and several even more interesting efforts (notably some work on congestion- sensitive admissions control, which seeks to impose TCP-like congestion avoidance on fundamentally non-congestion-avoiding traffic) are being worked upon. As Scott Huddle noted a number of days ago, a source of traffic in theory *ALWAYS* has it in its power to control the volume and pattern of its transmissions. As right now, most such sources are in easy reach of practical ways of controlling the volume and pattern of its admissions for very low (or no) cost, a wise source of traffic in a sender-pays settlements-based world will already have been investigating ways of optimizing their traffic output. The one nit in John's followup is that in a sender-pays settlements-based world we do not have to hunt down SMURFers, or flooders -- providing they pay the larger bills based on the larger amount of traffic, the affected targets will have necessary revenue to adapt to such things, either through building bigger pipes or building systems to stop such traffic before one's egress interface (to avoid having to pay the next network along for all the flood traffic). Sean.

1 0

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

24 Aug '98

>Or, let's say A finds artificial ways to send more >traffic to B to balance it out so they get charged >less. Hmmm... I don't see any way changing the charging >model addresses that. I think that if both the source of the traffic and the destination, i.e. the sender and receiver, have to pay for the traffic they get and receive, that it is much more difficult to come up with schemes to 'even out' the flow.. Continued below. >I don't think that good content should have to succumb >to advertising littering it's pages in order to support >itself. I don't think that ftp.cs.berkeley.edu should >have to install ADs in the readme files so that you >see an ad everytime you go to download sendmail, as >an example. Get real. Advertising is just one way the content provider can generate money. If it is content that someone wants, shouldn't they pay for it? If the business model changes so that traffic starts to cost something to the users at both ends, per usage rather than flat rate, someone has to pay. If that content provider is idealogically opposed to advertsing, then they better fnid someway to pay. >In fact, it's easier to generate what you want to a >host that doesn't respond. No need to worry about the >responses counteracting your intent. I'm not sure how >you would distinguish fraudulent traffic to enforce >such a provision. Afterall, it could look like a port >scanner, or any number of other things. Hmm. I think that if network A continuously generates traffic to a host on network B that doesn't exist, this would be easy to catch. For instance, Cisco's netflow shows traffic flow to and from source and destination. If its all one way, then it is invalid traffic. I see that there are issues with this, especially with today's tools, but I don't think it is impossible to catch fraudulent traffic. I would also say that there is no need for settelements until you reach some scale of difference. Whether that is an order of magnitude, or some smaller scale, doesn't matter to much. But when you do this, I think it quickly becomes obvious when you start to get enough invalid traffic to pass that threshhold... >> Thus, there will most likely have to be, at a minimum, >> an Independent Peering Council, or at worst, government >>regulation, to make this happen. :-( >The worst would be if this did happen. The proposal has >_WAY_ too many holes and sounds like exactly the kind of >proposal that is why we all dread regulation so much. I agree that noone wants regulation, but I don't see an Independent Peering Group, or a group that has board members from many ISP's as a bad thing. I don't know if such a group could ever come to an agreement, but that is another story. As for the holes, you listed a couple. That people can generate fraudulent traffic and it isn't easy to catch was one -- I think if it isn't easy today, it will be soon, especially if you need it to survive as an ISP. And the other I saw was that advertising shouldn't be needed to generate the $$ the content provider needs to pay usage based charges vs. flat-rate. All I can say is there are other means to generate money, and the content providers will do so if they have to to stay on-line. Again, not advocating this is the way to go, nor expressing the views of my employer... 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

Re: Transaction Based Settlements Encourage Waste (was Re: B
by owen＠DeLong.SJ.CA.US 24 Aug '98

24 Aug '98

> >> Transaction Based Settlements Encourage Waste > > > I think everyone agrees that the above statement is true in today's Internet > model, where customers are charged flat rates for their connections. But if > we change the peering model, why should we not change the model for > charging customers? If we do that, then settlements can work, and the > problem of metrics for how to charge should become much easier... > > Take the aggregate traffic from A --> B, and from B--> A, and whoever receives > more bits pays the other provider. Say it is A that has to pay B, as B is a > big > content provider and A is a big dial ISP. Now, if A charges $19.95/month flat > rate to all of its dial users, A instantly loses. But if A charges its dial > customers > based on the bits received, or time connected, perhaps it becomes more even. > Or, let's say A finds artificial ways to send more traffic to B to balance it out so they get charged less. Hmmm... I don't see any way changing the charging model addresses that. > Network A can't win in a settlement based peering relationship unless he passes > the costs on to his customers, and at flat-rates, whether it is dial up or > leased line, Sure he can... He just has to change the traffic ratio. > that is not happening. So, charge the content provider for outbound *and* > inbound > traffic. This can and should be subsidized by advertisers, as the more 'hits' > that > site generates, the more $$ you can charge. (Of course, this only works when > advertisers are willing to pay to be on your site, but if they aren't > willing, either > your site has content that doesn't have mass appeal or the advertiser doesn't > want to be associated with your content. For the former, you probably aren't > getting enough hits to worry about usage based costs. For the latter, find > another > advertiser or someone else to pay...) For the dialup user, charge him a lower > fixed > monthly cost of, say $5, but charge him for the traffic to and from him. > What's the > cost? Whatever it takes to make money while remaining competitive! > I don't think that good content should have to succumb to advertising littering it's pages in order to support itself. I don't think that ftp.cs.berkeley.edu should have to install ADs in the readme files so that you see an ad everytime you go to download sendmail, as an example. Get real. > There are still problems with DOS based attacks, but those need to be resolved > anyway. As for writing 'fraudulant apps' that generate asymmetric flows to > try to > 'even out' the peering relationship, it doesn't work anymore for creating flow > in > to your own network. Your paying the other provider because they are sending > you more traffic than you are sending them. For the opposite direction, if you > can write an app that sends more traffic out to the other network, you'll need > a > valid host to talk to. I'm sure the other provider won't have one of their own > machines doing that, so you'll need a customer of the other network to receive > that traffic. But now that they are charged for it, that won't happen. (I'm > sure > someone out there can think of ways around this, but I imagine there are > solutions to them. If its fraudulent traffic, and you face serious fines and/or > periods of time where you have to shut down your network, would you really > take the chance?) > No you don't, you just need something inside one of the prefixes advertised to you. In fact, it's easier to generate what you want to a host that doesn't respond. No need to worry about the responses counteracting your intent. I'm not sure how you would distinguish fraudulent traffic to enforce such a provision. Afterall, it could look like a port scanner, or any number of other things. Another question that evolves is how you measure this at the MAEs. > Of course, the first ISP that starts to do usage-based charges may stand a good > chance of losing many of their customers, so this would have to be Industry > wide. And > the peering charges would have to be the same (or at least on the same order of > magnitude) between all ISPs, or peering imbalances will quickly be created. > Thus, > there will most likely have to be, at a minimum, an Independent Peering > Council, or > at worst, government regulation, to make this happen. :-( > The worst would be if this did happen. The proposal has _WAY_ too many holes and sounds like exactly the kind of proposal that is why we all dread regulation so much. > DISCLAIMER: I'm not advocating this solution, and it may or may not express > the views of my employer. > > I should also state that I am doing my M.S. Thesis on "The Evolution of > Peering." > Any original ideas I see on nanog (or com-priv, where this discussion really > should > be) will be quoted as such! > Fair enough. > 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 > Owen

1 0

re: intranet
by william＠pacific.net.ph 24 Aug '98

24 Aug '98

HI all! Thanks to all who responded, privately and publicly. To end the topic, we can't use BGP since we do not have an AS# and we will not get valid or Internet-routable IP addresses. We will only use the 2 subnets provided by the 2 ISPs. All IP addresses behind the router will be internal IPs. The DNS will be configured to have primary and secondary name servers. The MX records will point to 2 IP addresses (from each ISP) and will point to the same mail server. The router will use metrics to determine the primary ISP and the backup ISP. Once again, thanks to all who responded. William

1 0

spare swamp space?
by Brandon Ross 24 Aug '98

24 Aug '98

I'm currently working on a project to help reduce the impact of smurf attacks on our IRC server. Part of the plan requires a /24 of swamp space. Since I'm sure ARIN wouldn't even consider assigning anything out of the swamp or anything that small, I'm wondering if any of you might have one that you're not using and would consider transferring to me. Since I'm sure questions will arise, and this is operational related, I'll share the plan. Most smurf attacks we receive are directed at our IRC server (imagine that). We offer IRC service to both our customers and the outside world. Our customers are not only on our network, but also on several other wholesale dialup providers. To minimise the impact of a smurf attack against our IRC server we will split the server off into 2 servers, one for the outside world and one for our customers only. The public server will be connected via a T1 to a smurf tracing friendly transit provider for external connectivity. This T1 will be used for this purpose only and not be part of the rest of our infrastructure (which is made up mostly of T3's to transit providers for our external connectivity). The public server will use an address assigned by the upstream. There will be a private network connection over Ethernet between the public and private servers. The private server will be connected to the rest of our infrastructure and will use an address out of swamp space. This swamp space will only be advertised to our wholesale dialup providers on a private peering setup so only machines attached to these providers will be able to reach the private irc server. So how does this work? Well, the typical attacker will launch his smurf attack against irc.mindspring.com. irc.mindspring.com resolves to an address within that swamp space I discussed. When the echo-reply from a far off network without "no ip directed-broadcast" gets sent, it has nowhere to go because their upstream doesn't have a route for it. So what happens if they attack the public server? The public server, since it's separated from the rest of our network will at least not effect our customers, only people connected to our public irc server from the outside world. So why don't you just use private IP space? That would require that we and our wholesale providers agree on a private block to use for this purpose. Even if this can be done, if/when we add another wholesaler, who's to say if they will agree to that space as well? Well, you could use NAT between private space in your network and your wholesalers, you say?. I'm trying to keep this as simple and inexpensive as possible. While I'm sure NAT would work fine, I'd like to avoid it if possible. So, any takers? Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.

7 14

Re: MAE-East - Operational question
by Jeff Barrows 24 Aug '98

24 Aug '98

Alex - When I have seen packet loss between two providers peering across the various shared medium FDDI interconnects, it has almost always been due to one or more of the following situations : - Network A has congested pipe(s) into the L2 thing. - Network B has congested pipe(s) into the L2 thing. - Network A has congested pipe(s) to the rest of their network. - Network B has congested pipe(s) to the rest of their network. - The peering session between Network A and Network B is traversing the network of FDDI switches at the IX, as the networks are not peering across a FDDI switch that they have in common, and the links are congested. The above situations are mostly correctable, assuming : - Additional FDDI ports are available. - Additional capacity to their network is obtainable. Other things one can do : - FD-FDDI - Peering session can be moved to a FDDI switch that the two networks have in common. Don't get me wrong-- certainly one should explore means of interconnecting beyond the shared medium FDDI option. The various ATM public peering services seem a viable way of scaling public peering as it exists today... while also affording a network the opportunity to put "private [atm-vc] peering" on their marketing web pages. ;) This is my personal observation- hope it helps. - jsb >Does anyone care about trying to get packet loss over MAE-East reduced >any more? Some peers have quite heavy packet loss to them from where >I'm sitting, and have done for a good while. It seems to me it's >not a problem with my port, and I don't think I have head of line blocking >problems, which means it's either a Gigaswitch problem, or their ports >are simply full. Does anyone still hassle Worldcom and peers about this >or have we lost hope of ever getting it fixed (i.e. people peer privately >or hope other exchange points or a replacement will come along). > >-- >Alex Bligh >GX Networks (formerly Xara Networks)

4 3

Re: BBN/GTEI
by owen＠DeLong.SJ.CA.US 24 Aug '98

24 Aug '98

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? > Since flow studies are confidential information, I will not quote from them. However, I will say that I would think it intuitively obvious to almost anyone on this list that Web Hosters don't OFFER very many packets that aren't a response to a REQUEST. Now, if we were discussing a large content provider that hosted alot of push-oriented sites, that might be a different story. > 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 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. > Ah, but with the advent of providers that focus primarily on access and other providers that focus primarily on hosting, the similar number of octets concept is disappearing. Not because one side is changing the balance, but because both sides are changing. More and more of the access providers are becoming larger and larger sinks at the same time that the hosting providers are becoming larger and larger sources. The shifting of the traffic flows is changing at roughly the same rate on BOTH sides, not because of one sides business model. Also, long distance phone calling didn't introduce the concept, it was around prior to telephones. Look at how shipping was handled on catalog orders in days before telephones. Generally, the purchaser pays shipping in almost all commerce. This has been true for a very long time. > So what do we do when that is no longer the case? > I _REALLY_ don't see that much of a need for changing the way things are. If the access providers cannot deliver the packets their customers request from the point they say they want to receive said traffic to their customers for the price they are charging said customers, then they need to reevaluate their pricing model. Similarly, it is the responsibility (IMHO) of the content provider to deliver the packets to the requested handoff point. Owen

3 2