- Test - lists.nanog.org

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

OUTAGE: gopher eats fiber
by Sean Donelan 24 Aug '98

24 Aug '98

Today's fiber cut --- In USWEST territory a gopher chewed through a fiber cable near Portales, New Mexico. Service to 6,000 customers including long distance, 9-1-1 and two airports was disrupted. Airport service has been restored. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Generation of traffic in "settled" peering arrangement
by John Curran 23 Aug '98

23 Aug '98

At 08:47 PM 08/21/1998 -0700, Mike Leber wrote: >... >And any suitably informed party to a peering arrangement like this can >simply offer free hosting to search engine crawlers until they are >extracting the desired amount cash from their peer via settlements. Folks, Think very carefully about what happens as traffic increases... Given that the context is the introduction of "settlement-based" peering for traffic imbalance in a shortest-exit world, then all of the various schemes for generation of traffic (web crawlers, backup services, etc) are no problem whatsoever, and may actually been seen as desirable... Background: Imagine a nationwide Internet provider with customer A on the west coast and customer B on the east coast. Customer B sends queries to customer A's server, and receives quite a bit of data in return. (all of this traffic stays on the provider's backbone in this case) Presume for the moment that the provider charges the customers (A&B) on a usage-basis which takes both sending and received traffic levels into consideration. Now, one could charge each of A and B the full cost of the traffic exchanged (which would effectively be "double dipping" and quite profitable :-) but a competitive market makes it far more likely that the rate per traffic measure will be such that A & B together pay the costs associated with their traffic exchange Now, given that A & B are both on the provider's network, everything is fine. When we hypothesize that A is instead connected to a peer network, we don't know whether costs will be recovered. In a shortest- exit world, traffic is quickly exchanged to the original provider's network and hence the costs of transmission to B are almost identical to the case where the A was a customer. Given that there's only one customer (B) now paying for these costs, this presents a potential problem. Customer B expects to pay their fair share of the costs, but doesn't expect to pay a larger portion of the total costs simply because A is connected to another provider. The truth is, there is actually nothing wrong with this situation if the traffic to/from the peer is of the same order of magnitude. To elaborate: a peer provides traffic which must be carried without corresponding sender-side revenue. On the other hand, the peer also allows the Internet provider to provide a similar level of sender-paid traffic which (by nature of being handed off) has very little actual transmission costs. This is why typical peers are overall neutral to cost recovery, and why peers which send far more traffic than received are problematic. There are a few options that have been mentioned to this situation, including the "receiver pays full freight / sending is free" model, the use of something other than shortest-exit routing, and introduction of settlements for such traffic. For purposes of this thread, we're trying to determine if the settlement approach is doomed to failure due to ability to generate additional traffic flows through innovation. Assessment: Presuming that a peer which is a net exporter of traffic begins to address this by encouraging additional traffic from customers to its network, this would result in more sender-paid originating traffic which quickly moves to the peer. Such traffic is (as noted above) quite profitable, as it includes full cost recover but little actual costs due to shortest to the peer. This is actually good for both networks, and us back to an Internet where more traffic is considered a good thing by ISP's at both ends of the connection. /John p.s. The fact that the sender of traffic should be paying some portion of the resulting costs is not a surprise to anyone; many of the content companies that I've spoken to believe they already are paying more as traffic increases, and were quite surprised to find that it doesn't actually make it to the networks which bear the brunt of the traffic carriage. p.p.s. As noted, departure from shortest-exit is also another approach which may provide some answers to this situation, but that's a different topic which deserves its own thread. This message is simply noting that settling for peering traffic is quite viable, despite assertions to the contrary regarding traffic generation. As long as you're billing the senders on your network for increased usage (and handing it off shortest-exit), increased traffic is good thing.

1 0

NON-OPERATIONAL.. Non-Stop Hoe
by Robert Mathews-ICICX 23 Aug '98

23 Aug '98

Who says that you have to be a carrier to be effected by a Hoe.. ---------- Forwarded message ---------- Date: Fri, 21 Aug 1998 10:47:25 -1000 From: Richard Crowe To: Robert Mathews Subject: Re: Could you.. Robert, I am working on it. [....] The contractor installing a sewer system cut the power line in half and the rest of the day was spent restoring power to the Computing and Math building. Unfortunately, a critical hub in College Hall did not have power and they could not fix that until today. That meant that the .115 subnet in Wentworth and Natural Sciences was cut off from the world for about 21 hours. Incompetence at its finest, is all I can say! Will continue to work on this today, now that the network has been restored. Cheers, Richard Richard A. Crowe, Ph.D. Chair and Professor of Astronomy Department of Physics & Astronomy University of Hawaii

1 0

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

23 Aug '98

> > The shifting of the traffic flows is > > changing at roughly the same rate on BOTH sides, not because of one sides > > business model. > > Yes. And I don't pretend to have all the answers here and I don't intend > to imply that only one type of provider should pay the other type. Let's > remember that any two peers are exchanging traffic at several points in > the network. But the only situation in which a dialup provider and a > webhosting provider will not have problematic asymmetry is when both > providers have POPs in the same set of cities and both providers > have private exchange points in every one of those cities. Then, although > there would be asymmetry of traffic flows, if you go by my model where > only inter-city transit has a value, there would be no value asymmetry in > this situation. > I think city is too narrow a term in this situation. I think your proposal could have merit if we consider it in terms of Metros. Further, I think we can both agree that it is not necessary or efficient for both content and access providers to build out networks to every little podunk town. I think that we can effectively address the issues if we agree that the provider receiving more than they transmit should be able to require of their peer who is transmitting more than they receive to connect at whichever metros the receiving provider deems necessary. I would define a Metro as a contiguous geographical area with a population density greater than N people per square mile and a total population over P. I don't have the value of N or P off the top of my head, but it would be some value such that it would eliminate Red Bluff, CA, Needles, CA, Chambersburgh, VA, but would include Phoenix, Albuquerque (sp?), Los Angeles, the San Francisco Bay Area (San Francisco and San Jose are close enough together and the area in between is contiguous high density, so they would be one metro), Sacremento, etc. I think the access provider can appropriately charge his customers to cover the cost of getting traffic to/from the nearest Metro to/from the customer. I think the content provider can charge his customers to cover the cost of getting traffic to/from wherever they are hosting said customers servers to/from the metro closest to the requestor. > > Generally, the purchaser pays shipping in almost all > > commerce. This has been true for a very long time. > > I hesitate to draw parallels between the movement of atoms and that of > electrons. > Fair enough, however, I was not the one who started that part of the thread. Owen

1 0

Generation of traffic in "settled" peering arrangement
by John Curran 23 Aug '98

23 Aug '98

At 08:47 PM 08/21/1998 -0700, Mike Leber wrote: >... >And any suitably informed party to a peering arrangement like this can >simply offer free hosting to search engine crawlers until they are >extracting the desired amount cash from their peer via settlements. Folks, Think very carefully about what happens as traffic increases... Given that the context is the introduction of "settlement-based" peering for traffic imbalance in a shortest-exit world, then all of the various schemes for generation of traffic (web crawlers, backup services, etc) are no problem whatsoever, and may actually been seen as desirable... Background: Imagine a nationwide Internet provider with customer A on the west coast and customer B on the east coast. Customer B sends queries to customer A's server, and receives quite a bit of data in return. (all of this traffic stays on the provider's backbone in this case) Presume for the moment that the provider charges the customers (A&B) on a usage-basis which takes both sending and received traffic levels into consideration. Now, one could charge each of A and B the full cost of the traffic exchanged (which would effectively be "double dipping" and quite profitable :-) but a competitive market makes it far more likely that the rate per traffic measure will be such that A & B together pay the costs associated with their traffic exchange Now, given that A & B are both on the provider's network, everything is fine. When we hypothesize that A is instead connected to a peer network, we don't know whether costs will be recovered. In a shortest- exit world, traffic is quickly exchanged to the original provider's network and hence the costs of transmission to B are almost identical to the case where the A was a customer. Given that there's only one customer (B) now paying for these costs, this presents a potential problem. Customer B expects to pay their fair share of the costs, but doesn't expect to pay a larger portion of the total costs simply because A is connected to another provider. The truth is, there is actually nothing wrong with this situation if the traffic to/from the peer is of the same order of magnitude. To elaborate: a peer provides traffic which must be carried without corresponding sender-side revenue. On the other hand, the peer also allows the Internet provider to provide a similar level of sender-paid traffic which (by nature of being handed off) has very little actual transmission costs. This is why typical peers are overall neutral to cost recovery, and why peers which send far more traffic than received are problematic. There are a few options that have been mentioned to this situation, including the "receiver pays full freight / sending is free" model, the use of something other than shortest-exit routing, and introduction of settlements for such traffic. For purposes of this thread, we're trying to determine if the settlement approach is doomed to failure due to ability to generate additional traffic flows through innovation. Assessment: Presuming that a peer which is a net exporter of traffic begins to address this by encouraging additional traffic from customers to its network, this would result in more sender-paid originating traffic which quickly moves to the peer. Such traffic is (as noted above) quite profitable, as it includes full cost recover but little actual costs due to shortest to the peer. This is actually good for both networks, and us back to an Internet where more traffic is considered a good thing by ISP's at both ends of the connection. /John p.s. The fact that the sender of traffic should be paying some portion of the resulting costs is not a surprise to anyone; many of the content companies that I've spoken to believe they already are paying more as traffic increases, and were quite surprised to find that it doesn't actually make it to the networks which bear the brunt of the traffic carriage. p.p.s. As noted, departure from shortest-exit is also another approach which may provide some answers to this situation, but that's a different topic which deserves its own thread. This message is simply noting that settling for peering traffic is quite viable, despite assertions to the contrary regarding traffic generation. As long as you're billing the senders on your network for increased usage (and handing it off shortest-exit), increased traffic is good thing.

1 0

Re: BBN/GTEI
by Bruce Hahne 23 Aug '98

23 Aug '98

Dave Rand wrote: >> Assuming it does matter, in which direction does the value flow? and Michael Dillon responds: > Here's the complex part. The value is not expressed in bits and it depends > on the destination within the peer's network. I am assuming that we can > map the IPv4 address space by city and that we can set some value to each > intercity link. This means that a stream of bits entering a peers network > in San Jose with a final destination in San Jose would be free. But if the > stream of bits was destined for Santa Cruz there would be a small cost. I don't see that you've answered his question about value flow. You're describing how to set a value on a stream of packets without answering the question of who should pay. Should we charge the sender or the receiver? Back at the 1995 APRICOT conference there was a mention of an IETF WG (likely now dissolved) which was specifically working on the settlements issue, and their answer to this question was "it depends". For every packet you have to determine a packet owner who is responsible for paying. The owner could vary per application, per site, and/or per end user. I could even imagine that responsibility for payment could be split between sender and receiver: 50/50, 90/10, choose your favorite. If I'm downloading a copy of sendmail, I'm probably the "owner" of those ftp packets because Berkeley makes sendmail available as a public service and doesn't want to pay settlement costs to reach me. If I'm downloading a product white paper, maybe I expect the company that wrote the white paper to pay transit costs to reach me because it's a marketing expense that they should absorb. If somebody is sending me spam, I want the spammer to be the owner of those SMTP packets because I'm certainly not going to pay a settlement fee so that people can spam me. Back to Dave Rand again: >Down this path lies madness. Perhaps. On the other hand, there are already multiple Silicon Valley startups whose business models revolve entirely around metering every packet. And several well-known SF Bay area companies are already paying on a strictly metered (per Gb) basis to deliver web and ftp content to customers and potential customers. Metering in a multi-provider environment generally requires settlements. >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. Bruce Hahne hahne(a)netcom.com

5 10

welcome to the one size fits all Internet discussion swamp
by Jerry Scharf 23 Aug '98

23 Aug '98

I think we're being more than a little silly here. Person A says that the financial model for internet peering should be client funded, and B says no is should be content provider. folks, you can both be right for various situations. Most newspapers and magazines are largely paid for by the advertiser. Most subsciption services are paid for mostly by the clients. In each case the line is not simple, and the delivery media adapts to the money flow and vice versa. The problem comes from one of two major insanity swamps. a) deciding that there is one model that should be used for pricing. b) trying to decide how to classify a given flow, and the contractual concepts involved. Maybe I'm just hardened to it all, but anything I can't describe in a contract with terms, costs and redress is too soft for me to chage money. That's why we have these simple minded peering agreements. Anything beyond the mindless trading starts you onto a slippery slope from which I see no return. Phone settlements are 100x simpler than this stuff, and you see as the cost of haul drops this will become a major part of total cost of a phone call. I can understand bandwidth times distance hauled in simple terms, so saying I may not accept nearest exit routing from someone else is within my scope of simple minded. my last mail on this whole subject, jerry

1 0