- Test - lists.nanog.org

Re: Trans-Atlantic Traffic
by Sean M. Doran 22 Aug '97

22 Aug '97

Per Gregers Bilse <pgb(a)EU.net> writes: > You need to study some more (European) Internet history. I certainly accept that, so with respect to your assertion that EUnet was "kicked out" of Ebone 6-7 years ago I decided to check on three obvious primary sources, viz. Frode, Kees Neggers and Glenn Kowack. The first choice was obviously the easiest. Frode (unsurprisingly) was surprised at your version of history. I was too, since it varied with what I remember seeing at the time (remember I have some UUNET history too :-) ). He also said that Ebone would be very happy to welcome EUnet back into the fold if the departure was due to some misunderstanding several years ago. I shall ask the other two at leisure today or tomorrow in email. BTW, since there are other people reading this who would make good primary sources, I welcome any historical retrospectives by private email. > Among other things, you seem to overlook Which other things, out of curiosity? Admittedly I'm crippled by having a viewpoint firmly fixed in North America for the past few years, and I'm certainly open to different points of view with respect to the history of European Internetworking. > while Ebone had its US half circuits paid by the NSF, > and Rick Adams lent us a big helping hand during those > years. Wow, this is a rat's nest. :) Um, my ICM memories are that in the first place Ebone was initially principally an academic consortium, but that as commercial traffic began appearing, NSF funding began disappearing. I believe (Steve Goldstein can correct me if I'm wrong) that Ebone generally acquired capacity on fractions of lines the NSF did not pay for. There is some fuzziness about the RENATER lines, and one could take several readings on the NORDUNET capacity over the past couple of years, but in any event, I think you will find that any indirect subsidy really didn't amount to all that much (Dr Goldstein's pockets are only so deep) and probably did go to the benefit of the NSF's community of interest, and in particular during the period when Ebone was still a consortium rather than the hybrid Association/Incorporation in place now. There is no question that Rick was a pioneer in investing in the international growth of the commercial Internet, and that alot of the proliferation of the Internet in Europe is due in some measure to him. > As you are probably aware, we have been on very friendly terms with > Ebone for several years now. Yup, EUnet is cool. Sean.

2 1

Re: Trans-Atlantic Traffic
by Sean M. Doran 22 Aug '97

22 Aug '97

Simon Leinen <simon(a)limmat.switch.ch> writes: > There are many of these small links over the pond. One of the reasons there are so many trans-oceanic links between Europe and North America is that the cost of a trans-oceanic full-circuit is almost infinitely cheaper than inter-country circuits at PNO tariffs, thanks to inexpensive U.S. half-circuits. This is changing, largely due to E.U. telecomms liberalization. > I'd be interested > in whether (and if so: how) different providers manage to save costs > by sharing fast transcontinental lines among themselves. Hm, I wonder if I can put enough value into answering this question to have people forgive me for talking about my (European) employer on an ostensibly North American mailing list? :-) Ebone is a customer-owned trans-continental backbone provider that functions as a buyers' cooperative with respect to inter-country (and in some cases intra-country) capacity. The not-marketing-person designed web page describing this can be found at http://www.ebone.net/structure/objectives.html This largely works in part because of the origins of Ebone and the people who have worked with it since then, and because Ebone focuses principally on large ISPs. That leads to the assumption that customers aggregate enough traffic that they will use all the capacity they pay for at all times, which also leads to Ebone's no-overbooking design, and consequently to Ebone's rather large cost-based prices relative to its competitors which target vastly different markets, or do massive loss-leading, or do massive cross-subsidy, or all three. One way of looking at the Ebone backbone is as a large TDM network, much as one could build with ATM and CBR VCs, only without the drawbacks of ATM or a big VC mesh (and with the drawbacks of a complicated router-based network). There are of course several other pan-European providers such as Unisource's UBN, BT's CIP, UUNET, EUNET, Compuserve, Global -1, and IBM Advantis, each of which appears to function much like their counterparts or analogues in the U.S.A. This, however, is not exactly "line sharing" per se. Finally, there may be people sharing lines bilaterally or multilaterally among a small group of organizations. Some alternative capacity providers are offering decent rates on STM-1s among large cities; pulling VC3s or VC4s out of an STM-1 and paying proportionately has some economic attraction, particularly in cases where competition among providers doing this isn't quite as cutthroat as it is in North America. A "how" diagram following a model other than something closely mirroring the Ebone approacj would be: City A City B provider 1-----\ /-------provider 1 | | provider 2-----ADM===========ADM------provider 2 | | provider 3-----/ \-------provider 3 Where the single-stroke lines represent 45Mbps or 34Mbps circuits, whether through a local bandwidth provider (like the PNO) or using cables or something across a colocation facility like Telehouse, and the double-stroke line represents an international STM-1 provided by a bandwidth carrier. This kind of thing tends to bring the per-bit-per-second-per-month price down quite a bit compared to three individual E3s or DS3s, assuming that pricing is done relative to ordinary PNO tariffs. There are cost and complexity issues for all largeish ISPs to consider when choosing among various approaches for moving traffic around, obviously, so there is certainly on One True Approach to sharing really expensive bandwidth. One observation, however, is that aggregating providers appear to be popular choices when dealing with very expensive lines or high levels of complexity, and unpopular choices when they don't actually solve either problem (like when a large ISP can't use much of its flat-rate paid-for bandwidth because of massive overbooking or other design issues, or when routing and other things break alot). Finally, returning to the question of how many small pipes there are and how much trans-oceanic bandwidth there is, it is worth noting that a large number (but not most) of Ebone's customers have their own circuits across the Atlantic ocean, in spite of Ebone's pricing discounts on people who use Ebone'e trans-atlantic capacity. (Our trans-atlantic capacity is vastly less expensive than our trans-European capacity, and across a full customer pipe, a customer who is receiving U.S.-sourced traffic (or sending U.S.-bound traffic) through Ebone typically uses enough traffic that the cost incurred by meeting that customer's traffic needs is less than the cost incurred if the pipe was full of only European-to-European traffic). In essence, the reason there are lots of trans-Atlantic pipes is that in order to have sufficient capacity one would have to connect with a relatively large pipe to a trans-Atlantic traffic aggregator, which tends to be alot more expensive than a smaller pipe within Europe and a separate pipe across the ocean. This will probably remain the case, price-wise, until intra-European bandwidth prices fall to less than inter-continental prices, or to the point where the cost of connecting to a provider (or multiple providers) within Europe is perceived as less than the cost of maintaining a more complicated network. Sean.

4 4

Re: Asymetrical Routing
by Vern Paxson 22 Aug '97

22 Aug '97

> My question is: How bad is this? Is it terminaly bad or simply not > so great? Asymmetric routing by itself has virtually no impact on performance. It does present a measurement headache, though. This is discussed in a paper of mine available from ftp://ftp.ee.lbl.gov/papers/routing.SIGCOMM.ps.Z a revised version of which will be appearing in IEEE/ACM TON later this year. > Out of order TCP packets are bad, but can simply be reassembled. Asymmetry doesn't lead to out-of-order delivery, so this isn't a problem. Routes that *change* often, on the other hand, can indeed lead to performance problems. Vern

1 0

Re: ICMP Attacks???????
by Danny McPherson 21 Aug '97

21 Aug '97

> That's helpful, but even as an RFC people still have to be aware that > the problem exists before they do anything about it. A typical person > that I deal with would be a small networking integrator that is selling > Bay routers to school districts. This is not somebody who reads > RFCs, and most of them don't have any idea what issues face the > Internet today. I'm not sure what we can do, but this is one of the > types of people that severely need the education. I guess it probably > falls back on the vendors here to educate their resellers and customers. Ideally, ingress filtering would be applied as close to the edges as possible. This, for obvious reasons (one of which you pointed out above), isn't feasible. What is feasible is that all providers that possess some amount of cluefulness (this should cover *most* at the public exchanges), deploy ingress filtering on their customer connections. IMO, vendors should only be accountable for providing mechanisms to put these policies in place, most of which already exist. It's the responsibility of the participants of groups such as this to see that those policies are deployed. -danny

1 0

Internet Route Filtering
by Robert Malally 21 Aug '97

21 Aug '97

Hello, Does any one truely know what the current route filtering polices are for Sprint and MCI. The following rules are some that I have heard : Sprint currently filters announcements from its non-customers as follows: RFC 1597 reserved space: accept nothing (**) In the classical "A" space: accept nothing longer than /8 In the classical "B" space: accept nothing longer than /16 in 24/8 space: accept nothing longer than /19 (*) in 195/8: accept nothing longer than /19 in 206/8 - 223/8: accept nothing longer than /19 in 192/8 - 205/8: accept nothing longer than /24 (*) in-line with the IP registries allocation (**) RFC 1597> Private Address Space RFC 1597> The Internet Assigned Numbers Authority (IANA) has reserved RFC 1597> the following three blocks of the IP address space for private RFC 1597> networks: RFC 1597> 10.0.0.0 - 10.255.255.255 RFC 1597> 172.16.0.0 - 172.31.255.255 RFC 1597> 192.168.0.0 - 192.168.255.255 How are MCI and Sprint going to adjust their routing polices when the reclaimed class A's are given out. Thanks Robert Malally

1 0

RE: Trans-Atlantic Traffic
by Thomas P. Koltai 20 Aug '97

20 Aug '97

--- On Wed, 13 Aug 1997 23:46:56 +1000 Stuart Bryant <stuartb(a)ourworld.net> wrote: >Hi, > Does anyone know the kind/amount of data currently being moved either >way over the Atlantic links ? About 11,520,000,000 bit per hour. Tom -------------------------------------------------- Thomas P. Koltai Mobile: +61-419-333331 187 Liverpool Street, Sydney NSW Australia 2000 --------------------------------------------------

5 4

THENET update
by sob＠academ.com 20 Aug '97

20 Aug '97

It appears things have returned to normal with THENET. I am seeing their service machines and UT Austin from the major peering points now. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

THENET outage
by sob＠academ.com 20 Aug '97

20 Aug '97

FYI, I understand that there has been a significant power problem at UT Austin that has affected THENET connectivity. I observe that the MAEs don't have routes to either UT-AUSTIN or the THENET service machines. I don't know much more than this about it. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

[NON-Operational Issue]: Paul Vixie is a Vigilante?
by Chris A. Icide 19 Aug '97

19 Aug '97

List, First, sorry for the non-operational issue. They said it, I read it.... Here it is. http://www4.zdnet.com/anchordesk/story/story_1170.html Comments concerning a spam "black hole" list maintained by Paul that makes the spammers "disappear".... Chris

2 1

Re: ICMP Attacks???????
by Vadim Antonov 18 Aug '97

18 Aug '97

Just for the record -- the first description of such mechanism is in Sep 95 draft for TRAP ICMP: "Trace Back messages allow to locate the source of a stream of packets even if they carry incorrect or forged source address. Trace Back message causes a gateway to install a "trap" route to the specified desti- nation, to catch the incoming packet to that destination. Once the packet is received, the gateway reports it to the trace initiator, removes the trap, and sends the Trace Back message to the neighbour gateway the message came from. A trap expires (thus terminating the trace) if no packet addressed to the destination is received." --vadim "Alex.Bligh" writes: > > The other nice solution would be an inverse traceroute that went > back to each router in turn, passing it a bit of BPF saying "where > are you getting packets like this from please?". If such a protocol > existed...

2 1