February 1999 - Test - lists.nanog.org

Why the temptation for dial users to crank back rwin/mtu?
by mcmanus＠appliedtheory.com 07 Feb '99

07 Feb '99

Hi Folks, As we know[1], packet sizes on the network fall almost exclusively into one of 4 categories: Small (<50 byte) dataless packets.. tcp acks/syns/rsts.. 576 byte packets 1500 byte packets runt packets less than sender MTU.. It's always been my belief that the 576 values were generated by hosts that didn't support Path MTU discovery and wanted to be conservative and avoid fragmentation. Fair enough.. but, as I'm sure everybody knows, there's a plethora of website/utilities ([2],[3],[4],[5],[6],..) imploring windows dial users to use any one of a number of tools/techniques to play with their mtu/rwin settings to 'make things faster'.. In typical windows fashion nothing is quantified in any meaningful fashion and the only motivation provided is typically some garbage like "windows comes setup for LAN not internet use".. these tools tend to crank down both rwin and mtu an awful lot. apparently there's some performance value in this (at least to the immediate user) because they keep doing it in droves. It's not obvious to me why the heck this would be. (warning: I am a protocol guy, but I'm not a dialup guy at all.. and even less of a windows guy) MTU - at least this makes a little bit of sense.. If they're doing HTTP/1.0 stuff with parallel connections then a smaller MTU is going to make that parallelization latency much more effective and perceived performance will go up some.. it doesn't impact full document retrieval time though (at least not positively!).. are dial links really lossy enough that chopping the segment size to 1/3 is a big win in retransmit time or are the win95/98 stacks really braindead enough that they don't do pmtud so are just trying to dodge fragmentation? I found it really odd that [7] which I use all the time to track features in a myriad of shipped OS's actually has a blank entry for pmtud on both of those (neither yes nor no..) RWIN - this is the one that boggles my mind.. it gets set way way way down by the above mentioned tools.. I've seen it as low as 2500 bytes recently. Anyone have any insight into the value of pushing this all the way down? The web pages generally mumble about capping the amount of data that needs to be resent in case of a failure.. which is of course true in the extreme case, but I'd much rather have the congestion window providing the throttle than the hard-limit of rwin that can just cap transfer rates on you.. about the only reason I can think of for small RWINs is to conserve the buffer space, but it sure seems worth a few K to me to be sure I can work with high latency links. You could argue that 3 or 4 K is sufficient for any reasonable latency that is bottlenecked by a modem's throughput.. and eventually I might give in (or maybe not ;)).. what I don't get is why this results in any kind of perceived performace increase on the part of the user under any condition.. It almost implies that TCP congestion control is too conservative, although almost all work on that indicates it's a little too aggressive (which would be the side to err on..) Any thoughts? -P [1] http://www.caida.org/Papers/Inet98/ [2] http://www.cerberus-sys.com/~belleisl/tune_faq/tuning.htm [3] http://www.trumpet.com.au/wsk/faq/config.htm [4] http://www.mc-pro.com/hardware/windialup.shtml [5] http://www0.delphi.com/pccompat/mtu.html [6] http://www.pattersondesigns.com/tweakdun/index.html [7] http://www.psc.edu/networking/perf_tune.html

3 3

Re: Discussing, or not discussing, major business outages
by dlr＠bungi.com 07 Feb '99

07 Feb '99

[In the message entitled "Discussing, or not discussing, major business outages" on Feb 6, 23:06, George Herbert writes:] > > I would like to see the issue discussed in general terms > at least; what is appropriate for notifications, what are > fair responsibilities to customers, the public, other ISPs etc. > in terms of this sort of event. > As has happened in the past, it is my opinion that the techincal contacts for that organization should step forth at the appropriate time with details. This may, in fact, be after connectivity has been lost. Often, last minute negotations can restore services with only a momentary outage. No one but the people directly involved should be aware of this, for business reasons. Sometimes, business go through tough times for reasons beyond their control. No reflection on the technical abilities of the people involved - but just business. I'm certain that others would like to see the insides of every company exposed at all times. While it may be important to the customers, or potential customers, it should be a part of the diligence of the customer to inspect the worthiness of their supplier. I'm equally certain that the providers in question will step forward at the appropriate time to establish facts. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

The Cidr Report
by Tony Bates 05 Feb '99

05 Feb '99

This is an auto-generated mail on Fri Feb 5 12:00:00 PST 1999 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 05Feb99 0) General Status Table History ------------- Date Prefixes 290199 55694 300199 55734 310199 55712 010299 55847 020299 55793 030299 55899 040299 55881 050299 55641 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4500 Number of ASes announcing only one prefix: 2232 (1187 cidr, 1045 classful) Largest number of cidr routes: 353 announced by AS701 Largest number of classful routes: 881 announced by AS701 1) Gains by aggregating at the origin AS level --- 05Feb99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 386 140 246 63.7% BCnet Backbone AS2493 315 169 146 46.3% iSTAR Internet, Inc. AS174 656 541 115 17.5% Performance Systems International AS11305 115 13 102 88.7% UNKNOWN AS3749 158 66 92 58.2% TECNET AS1267 111 30 81 73.0% IUNET-AS AS4755 152 72 80 52.6% Videsh Sanchar Nigam Ltd. India AS4293 211 140 71 33.6% IMCI AS7046 273 207 66 24.2% UUNET-CUSTOMER AS4200 161 99 62 38.5% AGIS (Apex Global Information Ser AS4740 389 328 61 15.7% Ozemail Pty Ltd (ASN-OZEMAIL) AS1221 405 345 60 14.8% AARNET-AS AS701 881 825 56 6.4% Alternet AS1239 529 474 55 10.4% SprintLink Backbone AS7657 142 90 52 36.6% The Internet Group Limited AS72 89 37 52 58.4% Schlumberger Information Network AS7545 109 58 51 46.8% TPG Internet Pty Ltd AS10928 100 50 50 50.0% UNKNOWN AS7496 77 28 49 63.6% Power Up AS577 221 172 49 22.2% Bell Canada Backbone AS719 452 407 45 10.0% LANLINK autonomous system AS3221 84 42 42 50.0% EENet Autonomous System AS852 173 135 38 22.0% AGT Advance Communication AS803 72 36 36 50.0% SaskNet Backbone AS6897 64 28 36 56.2% Global-One Spain AS7745 39 4 35 89.7% BIGSKY-AS AS7122 112 77 35 31.2% MTS ADVANCED Network Policy AS6332 98 64 34 34.7% TELNOR AS2764 334 301 33 9.9% connect.com.au pty ltd AS4307 32 1 31 96.9% SVINET-1 For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

NANOG 15 - Wacky Paparazzi Pics
by Craig A. Haney 05 Feb '99

05 Feb '99

URL-> http://seamless.kludge.net/nanog/15 Pics include: ------------- - SkyCache Gang http://seamless.kludge.net/nanog/15/jpg/19990202-11.jpg - Breaking into the Qwest NOC http://seamless.kludge.net/nanog/15/jpg/19990202-05.jpg - Microsoft attends NANOG, Port in progress http://seamless.kludge.net/nanog/15/jpg/19990202-27.jpg - Trialing the @HOME official download counter (non-caching) http://seamless.kludge.net/nanog/15/jpg/19990202-19.jpg - @HOME employee goes to Jail http://seamless.kludge.net/nanog/15/jpg/19990202-31.jpg - Sprint caught in the act of Private Peering with Microsoft http://seamless.kludge.net/nanog/15/jpg/19990202-34.jpg - SPRINT drives employees to loony farm http://seamless.kludge.net/nanog/15/jpg/19990202-30.jpg - Police Line-up in the Vault...who is guilty? http://seamless.kludge.net/nanog/15/jpg/19990202-33.jpg Enjoy.

1 0

Re: spam whore, norcal-systems.net
by Dean Anderson 05 Feb '99

05 Feb '99

At 11:45 AM 2/3/1999 -0800, Dan Hollis wrote: >On Wed, 3 Feb 1999, Dean Anderson wrote: >> Unless of course the publicity is that Verio can't be trusted to keep >> private information private. Or that the publicity is that Verio thinks it >> can use any private information that passes through it to its own ends. > >Now we see Dean's true motives. It isnt legal issues at all, but rather >smear campaigns of people he doesnt agree with. Calling me pro-spam is a smear. Smearing is when you switch from argument to hateful or false labeling. Smearing attempts to avoid the issues by name calling. Privacy laws were passed that apply to Verio. They apply to everyone. They apply to you, too. Smear all you want. It doesn't change that. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: Data Collection and Statistics Analysis
by John Zollo 04 Feb '99

04 Feb '99

Thanks for your feedback! The only problem is Concord is pretty expensive -- something like $100K I think. I should've specified that in my original post, along with the fact that the reason I need the percentile data is to be able to compute fees for bursts above a baseline amount of traffic. I'm not /that/ familiar with concord, but I don't think there's an easy way to integrate it with a billing system of some sort. Is there anything else you can think of? thanks! john On Thu, 4 Feb 1999, James Regovich wrote: > Concord Communications has Network Health that provides very comprehensive > analysis of networks, including frame and ATM. It's a pricey package, but > well worth it. > > You can get a sample analysis of your network at > http://www.concord.com/checkup.htm and a demo of the reports at > www.comcord.com/webdemo/start_here.htm > > This is the most detailed and comprehensive package I have seen. > > Jim Regovich > Sprint Internet Service Center > (703) 689-7049 > jamesr(a)sprint.net > > <For security, this message encoded using double-rot13> > > On Thu, 4 Feb 1999, John Zollo wrote: > > > > > I'm trying to find an application that will SNMP poll my routers > > and calculate statistics a little more complicated than the simple > > average in MRTG. For instance, other than a mean average, I'd like to > > see a break-up in percentiles -- especially the top percentiles. Does > > anyone have any suggestions of a program that will do this? By the way, > > I'd like to stick to UNIX for the polling and analysis platform. > > > > Thanks in advance for any help!!! > > John Zollo > > > > > > > > > > > > > >

1 0

Data Collection and Statistics Analysis
by John Zollo 04 Feb '99

04 Feb '99

I'm trying to find an application that will SNMP poll my routers and calculate statistics a little more complicated than the simple average in MRTG. For instance, other than a mean average, I'd like to see a break-up in percentiles -- especially the top percentiles. Does anyone have any suggestions of a program that will do this? By the way, I'd like to stick to UNIX for the polling and analysis platform. Thanks in advance for any help!!! John Zollo

1 0

Re: Monitoring, Flow Stats (Re: spam whore, norcal-systems)
by owen＠DeLong.SJ.CA.US 04 Feb '99

04 Feb '99

> Thats a different claim. Spammer is authorized to send packets. You can't > charge them with a real theft. "Theft of service" is a term used by > anti-spammers, not a legal statement of a criminal activity. In this case, > you don't have any bonafide abuse of your property rights. So you can't > claim the abuse clause. > Spammer is _NOT_ authorized to send SPAM packets through my network. Spammer has no way to get to my network other than through networks which have signed an AUP/TOS which specifically precludes them from sending SPAM packets through my network for SPAMMER. As such, spammers SPAM packets are theft of service, and I have the property rights to block them. Owen

1 0

Re: Monitoring, Flow Stats (Re: spam whore, norcal-systems)
by owen＠DeLong.SJ.CA.US 04 Feb '99

04 Feb '99

> Owen DeLong in private communication points up that he thinks that this > permission is transitive. That has the problem that it trivially obviates > all privacy. Every provider is automatically authorized, no one is not > authorized. Privacy is in the eyes of the provider. The ECPA was intended > to prevent communications providers from looking at things they shouldn't > and don't need to. So I'm not convinced. **thanks to Dean Robb, the > Attorneys manual says it must be "specifically authorized" > Apologies to the list for posting this, but I had to respond to this violation of my privacy and this slander. No, I didn't. I said that my AUP/TOS can create a transitive OBLIGATION to disclose on the part of the downstream providers. Further, I have repeatedly said that if the downstream providers can provide their service to spammers without violating my AUP/TOS, then there is no issue. However, if they deliver content to my network for transit which is in violation of my AUP/TOS, then I have the rights to defend my property from this theft of service. Owen

1 0

persistent smtp connectins
by michael 04 Feb '99

04 Feb '99

Before anyone flames me I asked the moderators if this would be appropriate to post. The answer was "Sure". For several months we have experienced massive amounts of persistent smtp connections from a forged from address from various dialup accounts around the USA. With the help from one of these ISP's it was found to be a program that preports to scan various search engines, like four11, based upon a user supplied search criteria and generates a mail list. When a user would run this program is when we would see the smtp connections. Yet the user was unaware of this. In conversation with this user they were not aware of anything other than polling of these search engines and the generation of a mail list. I obtained a copy of the program and looked at the code. It has hundreds of domain names as well as the forged from address. A phone call to the distributor as well as the company that produces this program, they all say "all it does is query several search engines like four11". When I confronted them about the hundreds of domain names in their code and the forged from address they claimed ignorance. In conclusion, I have not run the program personaly and the above are my observations from looking at the code. For those of you who are interested in this fee free to email me and I will supply you with the url and program name. A hint to see if you or your users or your systems have been the victim of this program is a from address of savings.com in your sendmail logs.

1 0