- Test - lists.nanog.org

Re: sell shell accounts?
by Paul Ferguson 23 Jul '96

23 Jul '96

At 05:06 PM 7/23/96 -0500, Tim Salo wrote: > >The desire for a full mesh of VCs between routers becomes more compelling >if you have more than three routers. The diagram is left as an exercise >to the reader; I rather dislike having to draw in ASCII. > >Note that the two paths between A and C, (directly versus via B), seem >to take distinctly different paths. (Perhaps, I missed your point). > Perhaps I missed your point. Tim, I could've sworn that you had been following the IETF ION WG mailing list, where this has been discussed on hundreds of occasions. I hesitate to even mention this on NANOG (I really don't want to re-hash this on this list), but I can't hold my tongue. The scalability of an ATM network where each end-point is fully meshed to all other end-points decreases in direct proportion to the number of end-points. This is not so much a layer 2 problem, per se, but rather the ability to maintain functional routing (convergence, et al.) in a fully meshed network topology. This does not scale. - paul

1 0

Re: sell shell accounts?
by salo＠msc.edu 23 Jul '96

23 Jul '96

> From: Avi Freedman <freedman(a)netaxs.com> > Subject: Re: sell shell accounts? > To: vansax(a)atmnet.net (Jim Van Baalen) > Date: Fri, 19 Jul 1996 17:17:19 -0400 (EDT) > Cc: richards(a)netrex.com, agislist(a)interstice.com, nanog(a)merit.edu > [...] > Nope, remember - there is no magic. Any mesh of PVCs that one makes > over a switched network must reflect the toplogy of that network, and > one can set up a matching set of active routing sessions and route > weights which will cause traffic to flow the same way. > [...] If I understand what you are asserting, I probably don't agree with it. I assume that we are talking about using wide-area ATM networks, (or more specifically, wide-area ATM services provided by, for example, carriers). Consider the following configuration ________ _______________________ ________ | Router | loop A | | loop C | Router | | A |=========| Wide-Area ATM Service |========| C | |________| |_______________________| |________| | | local loop B | ________ | Router | | B | |________| The "long" path in this diagram between Router A and Router C is through Router B, with a VC between (A,B) and a VC between (B,C). The "shortcut" path in this diagram is a VC between (A,C). The biggest disadvantage of routing packets between A and C via B is that every packet (needlessly) traverses local loop B twice. Furthermore, this local loop is perhaps the most expensive component in the system. The desire for a full mesh of VCs between routers becomes more compelling if you have more than three routers. The diagram is left as an exercise to the reader; I rather dislike having to draw in ASCII. Note that the two paths between A and C, (directly versus via B), seem to take distinctly different paths. (Perhaps, I missed your point). It is not clear to me that being able to ping router B along the path between A and C buys you much. It sounds a bit (well, maybe only a bit) like wanting to cut a T1 in half to install a router in the middle so that you can tell which half of the T1 went down. (Again, I am assuming that the network in question is using ATM services, so the carrier is responsible for keeping the VCs up.) -tjs

1 0

Re: ATM Wide-Area Networks (was: sell shell accounts?)
by Paul Ferguson 23 Jul '96

23 Jul '96

Agreed. However, while one technology may be more economically efficient today, it certainly may not tomorrow. Also, economic comparisons need to also take into account functionality (or lack thereof), administrative & maintenance overhead, etc., not just monthly recurring transport costs. - paul At 02:50 PM 7/23/96 -0500, Tim Salo wrote: > >I think a more interesting measure of the value of ATM versus other >wide-area technologies is some sort of measure of throughput per dollar. > >-tjs >

1 0

T3 or not to T3
by dgaudet＠hotwired.com 23 Jul '96

23 Jul '96

I've been doing a lot of reading and thinking on what the best solution is for an application that initially requires approximately 15Mbps outgoing and 8Mbps incoming (as viewed from my router), and talks with 500000 unique hosts daily (i.e. has fairly wide coverage of the net). The application involves at least thirty machines, so colocation is likely to be cost-prohibitive. A single T3, or frac T3 isn't an option because there isn't a single provider that I can trust for the availability we want. Even ignoring availability, I seriously doubt that any provider can consistently fill a single customer's T3 pipe these days. >From stuff I've seen here and elsewhere I think the most important reason for this is congestion at NAPs making it impossible to suck (or shove) lots of bandwidth at anything but your provider's backbone. Taking all of this into account, I'm really leaning towards a solution that involves lots of small pipes to lots of providers. Essentially eliminating the need for 90% of our packets to traverse NAPs by using each backbone mostly for their own customers. Now that I've done my homework, I'd like to hear comments from some of the more experienced folk here. I haven't considered yet the maintenance/logistical cost of managing 15 T1s to 6 or 7 providers vs. the "ease" of two frac-T3s to two providers. >From a provider's point of view, if a site wanted to connect, and was willing to sign a use-policy saying they wouldn't use the connection for transit to other providers (i.e. would only ask for customer BGP and only route to the nets you provide in BGP updates), would that site have lower costs associated with it? (that you could pass on?) Thanks, Dean

11 17

Re: ATM Wide-Area Networks (was: sell shell accounts?)
by salo＠msc.edu 23 Jul '96

23 Jul '96

> Date: Tue, 23 Jul 1996 14:28:27 -0400 > From: Paul Ferguson <pferguso(a)cisco.com> > Subject: Re: ATM Wide-Area Networks (was: sell shell accounts?) > [...] > It depends on what you mean when you say 'performance'. I think > there is more and more interest being vested in ATM inefficiency, > and alternate technologies to better efficiency in the long-haul. > > Recall Jerry Scharf's numbers; they're indicative of the issue. > [...] > HDLC framing bytes = 3080633605 HDLC efficiency = 97.72 > ATM framing bytes = 3644304857 ATM efficiency = 82.61 > ATM w/snap framing bytes = 3862101043 ATM w/snap efficiency = 77.95 At a certain point, some of these arguments about ATM efficiency sound a bit like saying FDDI is terrible because 4B/5B encoding is only 80% efficient. I think a more interesting measure of the value of ATM versus other wide-area technologies is some sort of measure of throughput per dollar. -tjs

1 0

CIX or CRL problems?
by sob＠academ.com 23 Jul '96

23 Jul '96

I am not able to get past 149.20.0.0 to get to CRL. Is this a problem with CRL or CIX? Does anyone know? owlman.academ.com% traceroute 140.145.0.1 traceroute to 140.145.0.1 (140.145.0.1): 1-30 hops, 38 byte packets 1 ACADEM-ISDN.ACADEM.COM (198.137.249.254) 1.99 ms (ttl=64!) 2.5 ms (ttl=64!) 1.93 ms (ttl=64!) 2 HOU6-E0.SESQUI.NET (128.241.151.86) 68.6 ms (ttl=63!) 24.1 ms (ttl=63!) 23.6 ms (ttl=63!) 3 128.241.151.83 (128.241.151.83) 295 ms 24.6 ms 37.4 ms 4 HOU1-F20.SESQUI.NET (128.241.200.81) 91.4 ms 34.2 ms 43.8 ms 5 MCI-F0.SESQUI.NET (192.67.13.189) 96.8 ms 25.7 ms 36.7 ms 6 border1-hssi1-0.Houston.mci.net (204.70.36.5) 29.5 ms 260 ms 312 ms 7 core1-fddi-0.Houston.mci.net (204.70.2.97) 421 ms 492 ms 146 ms 8 core1-hssi-4.Dallas.mci.net (204.70.1.121) 59.1 ms 108 ms 41.1 ms 9 core3.SanFrancisco.mci.net (204.70.4.17) 75.9 ms 195 ms 75.3 ms 10 mae-west-nap.SanFrancisco.mci.net (204.70.1.14) 98.9 ms 79.5 ms 103 ms 11 T3-CRL-SFO-01-H1/0.US.CRL.NET (198.32.136.10) 87.9 ms 172 ms 185 ms 12 T3-CRL-SFO-01-H3/0.US.CRL.NET (149.20.64.19) 122 ms (ttl=245!) 178 ms (ttl=245!) 215 ms (ttl=245!) 13 * * * 14 * * * 15 * * * .... 30 * * * owlman.academ.com% traceroute 165.113.19.6 traceroute to 165.113.19.6 (165.113.19.6): 1-30 hops, 38 byte packets 1 ACADEM-ISDN.ACADEM.COM (198.137.249.254) 74.6 ms (ttl=64!) 29.1 ms (ttl=64!) 3.8 ms (ttl=64!) 2 HOU6-E0.SESQUI.NET (128.241.151.86) 314 ms (ttl=63!) 93.7 ms (ttl=63!) 216 ms (ttl=63!) 3 128.241.151.83 (128.241.151.83) 130 ms 120 ms 96.2 ms 4 HOU1-F20.SESQUI.NET (128.241.200.81) 202 ms 282 ms 889 ms 5 MCI-F0.SESQUI.NET (192.67.13.189) 206 ms 25.8 ms 25.0 ms 6 border1-hssi1-0.Houston.mci.net (204.70.36.5) 29.5 ms 35.4 ms 36.8 ms 7 core1-fddi-0.Houston.mci.net (204.70.2.97) 81.9 ms 160 ms 233 ms 8 core1-hssi-4.Dallas.mci.net (204.70.1.121) 35.9 ms 193 ms 165 ms 9 core3.SanFrancisco.mci.net (204.70.4.17) 233 ms * 128 ms 10 mae-west-nap.SanFrancisco.mci.net (204.70.1.14) 135 ms 271 ms 311 ms 11 T3-CRL-SFO-01-H1/0.US.CRL.NET (198.32.136.10) 178 ms 114 ms 80.3 ms 12 T3-CRL-SFO-01-H3/0.US.CRL.NET (149.20.64.19) 98.2 ms (ttl=245!) 137 ms (ttl=245!) 255 ms (ttl=245!) 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 T3-CRL-SFO-01-H3/0.US.CRL.NET (149.20.64.19) 116 ms (ttl=245!) !H * *

3 3

Re: ATM Wide-Area Networks (was: sell shell accounts?)
by Paul Ferguson 23 Jul '96

23 Jul '96

At 10:22 AM 7/23/96 -0700, Dave Siegel wrote: > >It's difficult to quantify wrt to how ATM plays a role in end-to-end >performance on the Internet. There is very little research to support how >ATM affects the overall performance. Even Ameritech and PacBell restricted >the majority of their performance evaluation on performance in the switch, >and only extended their scope if they leased an ADSU to a customer. Even >with the improved buffering, if you fill your pipe into the ATM switch, >your ATM switch still becomes a packet shredder, compared to the more >graceful packet drops seen on a clear channel line. > It depends on what you mean when you say 'performance'. I think there is more and more interest being vested in ATM inefficiency, and alternate technologies to better efficiency in the long-haul. Recall Jerry Scharf's numbers; they're indicative of the issue. [snip] Date: Tue, 18 Jun 1996 23:24:12 -0700 (PDT) From: scharf(a)vix.com (Jerry Scharf) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: nanog(a)merit.edu Subject: tilting at windmills discussion 2 Sender: owner-nanog(a)merit.edu In an attempt to reduce the signal to noise ratio of NANOG, I felt like ATM should get equal time with registry policy for unending discussion of week award. In Bob Melcalfe's concept that all we care about is working code, I have included a PERL program for your benefit. The programs reads a histogram file like the ones kc generates from mae-west (http://www.nlanr.net/NA/Learn/packetsizes.html) and computes the overhead for various framing methods. Hopefully taking empirical data from the internet and giving people code will reduce the discussions of what the "cell tax" for real traffic is. Don't like my traffic, collect your own. Fighting over conclusions will be left to others. Jerry Here's the output from the 15 minute collection run on Feb 10th, '96: % packettax.pl < packetsizes.data total packets seen = 11708789, total payload bytes seen = 3010380871 HDLC framing bytes = 3080633605 HDLC efficiency = 97.72 ATM framing bytes = 3644304857 ATM efficiency = 82.61 ATM w/snap framing bytes = 3862101043 ATM w/snap efficiency = 77.95 [snip] - paul

1 0

Re: sell shell accounts?
by salo＠msc.edu 23 Jul '96

23 Jul '96

> Subject: Re: sell shell accounts? > To: freedman(a)netaxs.com (Avi Freedman) > Date: Fri, 19 Jul 1996 16:34:27 -0500 (CDT) > From: "Karl Denninger, MCSNet" <karl(a)mcs.com> > Cc: vansax(a)atmnet.net, richards(a)netrex.com, agislist(a)interstice.com, > nanog(a)merit.edu > [...] > > The question is: Will there be routers available that can make IP > > routing decisions based on 40-60kroutes and move 2-3 OC3s worth of > > bidirectional traffic? ... > > Avi > > Uh, yes. Like today. > > See NetStar (recently acquired by ASCEND). > > Their hardware does nothing *slower* than DS-3 right now, and updates the > route forwarding table 20x/second. :-) > > This thing is a monster, and will make the so-called "state of the art" > 7513s look like dogmeat when in full production (presuming the BGP issues > get completely resolved). I think there are a number of measures, beyond the speed of the interfaces, which are important when thinking about fast boxes: o Aggregate bandwidth of the box in bps. o Aggregate bandwidth of the box in packets per second. o Amount of buffering in box; (can TCP gracefully back off?) o And, a whole pile of specific, often implementation- dependent measures, regularly discussed on this list. Some boxes do very well on some of these measures, but not too well on others. An extreme example is a HIPPI switch: really fast interfaces (800 or even 1600 Mbps), lots of aggregate bandwidth (gigabits/sec), but almost no buffering and not good for more than a few hundred or a few thousand packets per second, (although the attached hosts often are responsible for much of this limitation). Also, things go much better if the HIPPI hosts are in the same room. Nonetheless, they are really fast based on select measurements... -tjs By the way, I like the NetStar box and wish them well.

1 0

Hotel Info for October NANOG Meeting
by Pam Ciesla 23 Jul '96

23 Jul '96

Hotel info is available on the Merit Web Page for the October NANOG Meeting http://www.merit.edu/. Please mention the NANOG Meeting when making your reservations at the hotels with blocked rooms. The Holiday Inn room block is until 10/9/96 all others end 9/23/96. Although this is not a football weekend, hotel rooms are at a premium, so book early. Shuttles will be provided from the hotel to the meeing from the Holiday Inn & the Sheraton Inn, the Bell Tower & Campus Inn are within walking distance and the Weber Inn you are on your own. If you have any problems making reservations please contact me. Thanks Pam Ciesla

1 0

NetSCARF Release 1.1 Available
by William B. Norton 23 Jul '96

23 Jul '96

N E T S C A R F R E L E A S E 1.1 Hi all - In April, Merit received funding from the Resource Allocation Committee (RAC) to develop and evolve a prototype ISP Network Statistics Collection And Reporting Facility (NetSCARF) package. The basic idea is to make it dead easy for ISPs to collect and report data about their part of the Internet. We expect about three more releases during the next 8 months, based on the feedback we get from the ISP and R&E community. The end result will hopefully be widely-available and consistent ISP performance data much as Merit produced during the operation of the NSFNET. The 1st public release of the software is now available at: http://www.merit.edu/~netscarf A technical overview article is being published in the July Connexions magazine (Vol. 10 No. 6) and some on-line docs exist at the above URL as well. The NetSCARF Code -------------------------- The NetSCARF code is easy to install, runs automatically, and consists of four separate programs. Every fifteen minutes the collections program queries all network nodes in parallel. (This is especially important for large networks where the serial skew can affect the ability to correlate data.) Nightly these raw statistics get pre-processed (cooked). The cooked data is delivered to CGI scripts using what we think is the first Public Domain implementation of the OpStats (rfc1856) client/server model. Finally, ISP performance reports (based on the cooked data) are displayed on the web via the CGI scripts. The source and pre-compiled executables are available for each of these on the BSDi and SunOS platforms. SNMP Version 1 is used to query the network nodes, although the code includes support for the User Security (USEC) model for SNMPv2. ( The Routing Arbiter project will use the privacy (DES Encryption) facility, but this capability is disabled for the public release due to export restrictions. You do get the benefits of authenticated management communications with the released SNMPv2u code though.) Release 2 is scheduled for October and will include ports to Windows NT, AIX, and perhaps Solaris and LINUX. We are primarily customer-driven in choosing additional features, but our own experience so far leads us to adding a few features to release 2 including raw network statistics maintenance functions, raw data file compression, and another report or two. During the operation of the NSFNET we found there were really only three graphs that were widely seen as useful. The first cut of the code includes only these three most popular graphs: System UpTime, Interface Uptime, and the McD's chart (total packets served) by the network. There is a mailing list (netscarf(a)merit.edu) for community discussion and guidance. Details are available at the URL above. Cheers - Bill ---------------------------------------------------------------------- William Norton <wbn(a)merit.edu> (313) 936-2656

1 0