- NANOG - lists.nanog.org

Re: logging systems/software
by Tony Tauber 24 Jun '97

24 Jun '97

On Jun 24, 12:27pm, richard welty wrote: > Subject: logging systems/software > i'll take advantage of the relative quiet to ask quick (and hopefully > non-controversial) question... > > does anyone have any particular favorites for reasonable cost > logging/tracking systems for trouble reports, outage reports, customer > service problems, and complaints (such as might be received about spam > at an abuse address)? > > we need to select something here soon, as we're going to actually be in > business shortly. > > thanks, > richard (soon to be welty(a)inet-solutions.net) >-- End of excerpt from richard welty You might try digging around in: http://netman.cit.buffalo.edu/Products.html which seems to have pointers to lotsa stuff. Tony

1 0

Re: logging systems/software
by Tony Tauber 24 Jun '97

24 Jun '97

On Jun 24, 12:27pm, richard welty wrote: > Subject: logging systems/software > i'll take advantage of the relative quiet to ask quick (and hopefully > non-controversial) question... > > does anyone have any particular favorites for reasonable cost > logging/tracking systems for trouble reports, outage reports, customer > service problems, and complaints (such as might be received about spam > at an abuse address)? > > we need to select something here soon, as we're going to actually be in > business shortly. > > thanks, > richard (soon to be welty(a)inet-solutions.net) >-- End of excerpt from richard welty You might try digging around in: http://netman.cit.buffalo.edu/Products.html which seems to have pointers to lotsa stuff. Tony

1 0

Re: logging systems/software
by Joseph C. Pistritto 24 Jun '97

24 Jun '97

>Date: Tue, 24 Jun 1997 10:34:33 -0700 >To: richard welty <welty(a)balltown.cma.com> >From: "Joseph C. Pistritto" <jcp(a)pointcast.com> >Subject: Re: logging systems/software > >At 12:27 PM 6/24/97 -0400, you wrote: > >Well, there are two products I'm familiar with: > Remedy - which is not low cost, but is designed to do exactly what you're doing. In fact they used it a couple of years ago for InteropNet, (which is where I got experience using it). Not inexpensive, but a pretty mature system that lots of people use. Has web capabilities as well. > > There's also a "bug tracking" system named "Visual Intercept" that runs on NT and Windows machines. We use it at PointCast extensively for bug tracking. I think it can probably be used for what you want to do too (since it's just keeping track of problems in a database). One good thing is the schema is open, so you can run scripts against the SQL database it's using (we use it on NT's SQL Server). You can check out the web site at http://www.elsitech.com/. This is definately lower cost than the "big ones" like Remedy, Scopus, or Vantive, and requires a lot less administration. > > -jcp- > >>i'll take advantage of the relative quiet to ask quick (and hopefully >>non-controversial) question... >> >>does anyone have any particular favorites for reasonable cost >>logging/tracking systems for trouble reports, outage reports, customer >>service problems, and complaints (such as might be received about spam >>at an abuse address)? >> >>we need to select something here soon, as we're going to actually be in >>business shortly. >> >>thanks, >> richard (soon to be welty(a)inet-solutions.net) >>

1 0

Internet Routing Instability paper
by Rob Malan 24 Jun '97

24 Jun '97

We finished our camera-ready copy of our paper this weekend, and would like to share it with a larger audience. Vern's annoucement reminded us to get this note out. You can find a copy of the paper: "Internet Routing Instability" to appear in Sigcomm '97 at the IPMA website: http://www.merit.edu/ipma/analysis/ -Rob - The abstract follows: Internet Routing Instability Craig Labovitz, G. Robert Malan, and Farnam Jahanian. Proceedings of the ACM SIGCOMM '97 Conference, September 1997; Cannes, France. This paper examines the network inter-domain routing information exchanged between backbone service providers at the major U.S. public Internet exchange points. Internet routing instability, or the rapid fluctuation of network reachability information, is an important problem currently facing the Internet engineering community. High levels of network instability can lead to packet loss, increased network latency and time to convergence. At the extreme, high levels of routing instability have lead to the loss of internal connectivity in wide-area, national networks. In this paper, we describe several unexpected trends in routing instability, and examine a number of anomalies and pathologies observed in the exchange of inter-domain routing information. The analysis in this paper is based on data collected from BGP routing messages generated by border routers at five of the Internet core's public exchange points during a nine month period. We show that the volume of these routing updates is several orders of magnitude more than expected and that the majority of this routing information is redundant, or pathological. Furthermore, our analysis reveals several unexpected trends and ill-behaved systematic properties in Internet routing. We finally posit a number of explanations for these anomalies and evaluate their potential impact on the Internet infrastructure.

1 0

paper on analyzing packet traces of TCP behavior available
by Vern Paxson 24 Jun '97

24 Jun '97

[My apologies to those of you who will receive multiple copies of this announcement from other mailing lists ...] The paper "Automated Packet Trace Analysis of TCP Implementations", to appear in SIGCOMM '97, is now available from: ftp://ftp.ee.lbl.gov/papers/vp-tcpanaly-sigcomm97.ps.Z I've appended the abstract. Vern Automated Packet Trace Analysis of TCP Implementations Vern Paxson Network Research Group Lawrence Berkeley National Laboratory vern(a)ee.lbl.gov We describe "tcpanaly", a tool for automatically analyzing a TCP implementation's behavior by inspecting packet traces of the TCP's activity. Doing so requires surmounting a number of hurdles, including detecting packet filter measurement errors, coping with ambiguities due to the distance between the measurement point and the TCP, and accommodating a surprisingly large range of behavior among different TCP implementations. We discuss why our efforts to develop a fully general tool failed, and detail a number of significant differences among 8 major TCP implementations, some of which, if ubiquitous, would devastate Internet performance. The most problematic TCPs were all independently written, suggesting that correct TCP implementation is fraught with difficulty. Consequently, it behooves the Internet community to develop testing programs and reference implementations.

1 0

paper on end-to-end Internet packet dynamics available
by Vern Paxson 24 Jun '97

24 Jun '97

[My apologies to those of you who will receive multiple copies of this announcement from other mailing lists ...] The paper "End-to-End Internet Packet Dynamics", to appear in SIGCOMM '97, is now available from: ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z I've appended the abstract. Vern End-to-End Internet Packet Dynamics Vern Paxson Network Research Group Lawrence Berkeley National Laboratory vern(a)ee.lbl.gov We discuss findings from a large-scale study of Internet packet dynamics conducted by tracing 20,000 TCP bulk transfers between 35 Internet sites. Because we traced each 100 Kbyte transfer at both the sender and the receiver, the measurements allow us to distinguish between the end-to-end behaviors due to the different directions of the Internet paths, which often exhibit asymmetries. We characterize the prevalence of unusual network events such as out-of-order delivery and packet corruption; discuss a robust receiver-based algorithm for estimating ``bottleneck bandwidth'' that addresses deficiencies discovered in techniques based on ``packet pair''; investigate patterns of packet loss, finding that loss events are not well-modeled as independent and, furthermore, that the distribution of the duration of loss events exhibits infinite variance; and analyze variations in packet transit delays as indicators of congestion periods, finding that congestion periods also span a wide range of time scales.

1 0

Re: PacBell
by Curt Howland 24 Jun '97

24 Jun '97

I can think of one good reason: Not everyone you might want to peer with on the West Coast is at the PAIX. Curt- > Well, due to the lack of traffic, here's a question that > I've been pondering...are there any good reasons (besides > MCI's peering requirements) to go into the Pac Bell NAP > as well as MAE-West and the PAIX? > > (This question probably won't have any impact on any > decisions; I'm just curious as to people's thoughts on > the matter, and it's nice to be able to post something > here that isn't about net abuse.) > > *********************************************************************** > J.D. Falk voice: +1-415-482-2840 > Supervisor, Network Operations fax: +1-415-482-2844 > PRIORI NETWORKS, INC. http://www.priori.net > "The People You Know. The People You Trust." > *********************************************************************** >

4 3

logging systems/software
by richard welty 24 Jun '97

24 Jun '97

i'll take advantage of the relative quiet to ask quick (and hopefully non-controversial) question... does anyone have any particular favorites for reasonable cost logging/tracking systems for trouble reports, outage reports, customer service problems, and complaints (such as might be received about spam at an abuse address)? we need to select something here soon, as we're going to actually be in business shortly. thanks, richard (soon to be welty(a)inet-solutions.net)

1 0

Re: PacBell
by Curt Howland 24 Jun '97

24 Jun '97

> On Jun 24, Curt Howland <howland(a)conxion.com> wrote: > > > Not everyone you might want to peer with on the West Coast > > is at the PAIX. > > Right, the PAIX by itself wouldn't be enough (though the > lighting is really cool); but with the PAIX /and/ MAE-West? It is a very pretty facility, certainly. Coverage might reach whatever % of the 'net you're looking for with the PAIX and Mae-East alone, but that's not my major criteria for choosing exchange points. I look for efficient data transfer, and effective regionalization of data flow. I really don't want data from Sacramento going to San Jose by way of Florida. I would rather have several smaller pipes into the populous exchange points, such as Mae-East and West, and then add the big pipes at the ATM Naps for high flow peers like MCI, Sprint, UUnet, ANS, AT&T and their ilk. So maybe the question comes back to, "is everyone you want to peer with on the West coast at the PAIX?" (The apearance of a company name in this email does not imply or suggest any existance of a peering agreement. The names are used for illustration only, and should be considered a compliment.) Curt-

1 0

*tap* is this thing on?
by jamie＠dilbert.iagnet.net 24 Jun '97

24 Jun '97

No nanog mail since Fri Jun 20 15:44:25 1997? :/ -- jamie g.k. rishaw dal/efnet:gavroche Internet Access Group 'whois JGR2' for PGP keyID/Fingerprint __ Network Operations/TSD DID:216.902.5455 FAX:216.623.3566 \/ 800.637.4IAGx5455

4 3