- NANOG - lists.nanog.org

Re: Who runs the net
by Sean Donelan 03 Jun '98

03 Jun '98

>The folks on this list don't run the net. They just operate the equipment >that runs one of the private networks that forms a portion of the >Internet. They don't necessarily even make all of the policy decisions for >that one network that they do operate. This is a plumbers list, not the >municipal water board list. I had settled more or less in to a state of blissfull funk, but last week I added some equipment to a new exchange point and had to start of the whole process trying to interconnect with other networks again. I have a stack of interconnection agreements about half-a-foot high, supposedly reviewed, approved and signed by lawyers and officers of various companies that represent the policy for exchanging traffic between the various interconnected networks. The only problem, I don't think anyone actually reads the darn things. They certainly don't actually reflect what we (the collective we) do. So we are left passing around the same bad agreements written long before the people who wrote the original agreements had any experience with what they were trying to do. Its not my intent to cause problems, just for the sake of causing problems. I certainly don't want to go through all the blood-letting that happened the last time around. But if no one has any intent of "providing for the notification of the other party of all scheduled maintenance that could cause significant connectivity degradation or loss of connectivity at the Interconnection Point of more than five (5) minutes" why bother with such a paragraph in the agreement signed by the people supposedly setting the policy? When was the last time you actually sent, or received such a notification from a network you interconnect with? And there are other issues have arisin over the years. For example, network address hijacking wasn't an issue in 1991, but does seem to be an issue now. I don't agree with AGIS that what the Net needs is a bunch of lawyers to solve the problems. If a handshake and an e-mail is good enough for you, its likely good enough for me. But I do think if we are going to have policies, we should follow them. And if we are going to document things, they should try to reflect what we actually intend to do. Right now we seem to have the worst of all possible states. Yes, this is a plumber's list. But even plumbers have been known to write to the the plumbing standards boards and say "Things have changed." >They're probably wondering why those plumbers don't solve the problem with >a piece of lead pipe. Of course they fail to realize that most of the >plumbers are wearing earplugs and are wondering what all the fuss is >about. Then the building inspector shows up. But you don't want to go there. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Jim Fleming and procmail
by Jay R. Ashworth 03 Jun '98

03 Jun '98

I wrote: > >To whom do I go to file a formal request to filter Jim Fleming's > >postings from this mailing list? And half a dozen people who apparently think I just fell off the turnip truck wrote back to me to suggest... On Mon, Jun 01, 1998 at 05:11:30PM -0700, Mark Milhollan wrote: > Procmail? Some were more creative than others, actually giving suggestions that, since I could feed them into my router (well, if my router were a Cisco, instead of an Ascend), were at least on topic: On Mon, Jun 01, 1998 at 09:18:36PM -0400, Eric Germann wrote: > Best one I've seen is > ip route 207.32.128.0 255.255.224.0 Null0 > If the net did it, his mail would go away. Or maybe we should classify him > as spam and get him in the RBL. Does Merit participate in that? > Hmmmmmmmm.... Some were smarmy: On Tue, Jun 02, 1998 at 11:35:43AM +0900, just me. wrote: > `man procmailex` > Note the flag jamie set in the Subject: line. > HTH. HAND. Some just suggestive: On Mon, Jun 01, 1998 at 11:05:31PM -0400, D'Arcy J.M. Cain wrote: > Your own .procmailrc? And some a bit more loquacious than others: On Mon, Jun 01, 1998 at 08:05:38PM -0700, Roeland M.J. Meyer wrote: > Well, I filed the request with my Eudora Filtering sub-system ... instant > gratification! Jim Flemming and Jeff Williams both now occupy the /Misc > Politicks/Bulkmeister folder and status get auto reverted to "Read". Since > 5May98 Flemming has posted 262 messages, very few of them less than 5KB. > I'm also tired of hearing about IPv8. Now I can read them when I have > nothing better to do, or they actually say something pertinent. > > Personally, I don't agree with removing them from the list. But none of them got the point I was trying to make. Folks, this list is for network operations and related topics. I don't think there's anyone left out there (except Jim) who thinks that any of the content of the message I was responding to is remotely on-topic for this list... which is read by quite a few members of the press. I know; several of them have written to me on different occasions for comment or clarification of things I've written. Now, even at this late date, it seems to me that many people, some in positions of power over the stuff we do here, still think that the folks who run the net are a bunch of asocial geeks and nerds who can't play nice together. While this is, in some cases, correct (:-), for the most part, I've found that almost everyone on this list, at least, is pretty easy to get along with... except Randy, of course. <grin> Anyway, my point is: if we, as the keepers of the bits, give the appearance that we can't keep our own sandbox clean, when someone is so clearly violating the rules which pertain to that portion of it, what appearance does that give of us to "outsiders", who may be listening in, about our ability to do the job we actually get paid for. Sticking _my_ head in the sand isn't going to do a thing about that, and, having been here since about 1983, I'm sorta protective of this here net. No, I don't think Jim can singlehandedly kill the Internet... but standards do have to start somewhere. I've changed the subject line so people who aren't interested in this thread can can it. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com

2 2

Spammers
by Anthony Sticha 03 Jun '98

03 Jun '98

I may be on the wrong list here but here it goes. Can someone direct me to the right place for complaining about a US ISP who continues to host a know spammer. We can block his domain but this might not be fair to others. I have spoken to the LA providor (who I will not name as yet) after he refused to answer e-mail. However calling the US from Australia can get expensive. Any ideas where to turn?

5 5

RE: The Great Exchange
by Pete Farmer 02 Jun '98

02 Jun '98

Roeland M.J. Meyer [mailto:rmeyer@mhsc.com] wrote on June 02, 1998 at 7:12 AM: >Even when [decent bandwidth at the end-user site] does happen, >they won't want to use it for video. A classic is the MCI >commercial where that gal was telecommuting (bath-robing at noon), >the last thing such would want is a video-based conference. Been >there, doing that. Real-time, two-way videoconferencing is just *one* form of video over IP. In some people's eyes, video over IP might involve someone Web-surfing to a site from which they can view Episode 89 of Gilligan's Island (streamed video), possibly with commercials embedded. There are all sorts of possible pricing models here, ranging from flat-rate subscription fees to pay-per-use to commercial-paid, and everything in-between. Lots of possible cache schemes, too. Pete ______________________________________________________________________ Peter J. Farmer E-mail: pfarmer(a)strategies-u.com Strategies Unlimited Voice: +1 650 941 3438 201 San Antonio Circle, Suite 205 Fax: +1 650 941 5120 Mountain View, CA 94040 WWW: http://www.strategies-u.com

1 0

Re: PC Bozo's World bites again (CNN, too)
by Matt Sommer 02 Jun '98

02 Jun '98

>"Matt Sommer" writes: >> Does RFC-879 still have any validity? > . . >No, that rule is no longer valid qua valid, in so far as negotiation >and Path MTU discovery make it obsolete. > >Perry ahhh, and 95 has a path mtu discovery problem: (from Rich Graves (mailto:win95netbugs-owner@lists.stanford.edu) http://burks.bton.ac.uk/burks/pcinfo/osdocs/hansie/nwtcpip.htm#c10 ) "If you can't send mail or news longer than 10 lines or so, or if you can't upload files with FTP or Microsoft networking, this is likely your problem. Downloads (from the net to your PC) are not affected. This assumes that you can upload files and send one-line messages fine; if not, you have a more fundamental problem. If the technical and political details don't interest you, skip them. In late November, Microsoft finally documented this known problem in Knowledge Base Article Q138025. However, they got it wrong, because the Usenet article that Microsoft evidently copied, <199509242223.PAA04539(a)Networking.Stanford.EDU>, was unclear (my fault). In late December or early January, after reading this FAQ repeatedly through the tide and jericho proxy servers, Microsoft removed this article and every other mention of the PathMTU problem from the Knowledge Base. Apparently it's just to embarrassing to leave documented. I would appreciate it if Microsoft would please mail me when they have restored and corrected the KB article, so that I can remove this paragraph from the FAQ. Anyway, the problem, as originally diagnosed in article <443n5c$ff9(a)aix1.segi.ulg.ac.be> by Andri Pirard pirard(a)vm1.ulg.ac.be, is that Microsoft does MTU path discovery according to RFC 1191 (written in 1990 by folks from DEC and Stanford University), but many routers don't. Since Microsoft jumped on the TCP/IP bandwagon so late, they apparently don't understand that a standard only drafted in 1990 is an infant not likely to be adopted Internet-wide. To fix this problem, run RegEdit.EXE and open it to the following key: Hkey_Local_Machine\System\CurrentControlSet\Services\VxD\MSTCP Create the following binary variable with a value of 1: PMTUBlackHoleDetect = 0 or 1 This should always fix the problem, unless there's a bug in their code, and we know that couldn't happen. If this doesn't solve the problem, create this variable in the same place: PMTUDiscovery = 0 or 1 Now, this is where I believe Microsoft gets it wrong. Knowledge Base Article Q138025 says to create this with a binary value of 1. This does nothing. You really want to create it with a value of 0. Setting MTU to some ridiculously low value is another effective way to fix the problem, but it hurts performance -- except over dialup, where an MTU of 576 or so might be a good idea anyway, especially if you have a cheap modem whose buffering doesn't work well. All other TCP/IP stacks available for DOS and Windows fragment properly according to existing Internet standards. You'll only see this problem with the stack that Microsoft includes "free." "

1 0

Re: PC Bozo's World bites again (CNN, too)
by sysadmin 02 Jun '98

02 Jun '98

>"Matt Sommer" writes: >> Does RFC-879 still have any validity? >

1 0

Re: PC Bozo's World bites again (CNN, too)
by Matt Sommer 02 Jun '98

02 Jun '98

Does RFC-879 still have any validity? " HOSTS MUST NOT SEND DATAGRAMS LARGER THAN 576 OCTETS UNLESS THEY HAVE SPECIFIC KNOWLEDGE THAT THE DESTINATION HOST IS PREPARED TO ACCEPT LARGER DATAGRAMS. This is a long established rule. To resolve the ambiguity in the TCP Maximum Segment Size option definition the following rule is established: THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS FORTY. The default IP Maximum Datagram Size is 576. The default TCP Maximum Segment Size is 536. " >Michael Dillon <michael(a)memra.com> writes: > >> I don't think so. They even said in their article that the technical >> details are based upon this URL >> http://www.sns-access.com/%7Enetpro/maxmtu.htm >> and this guy says stuff like: >> >> And, it turns out, depending on how your ISP and other routers >> encountered on the Internet handle your TCP/IP requests, that a MaxMTU >> setting of 576, often referred to as the "Internet Standard", will in >> many cases avoid the fragmentation of packets of data and the slow >> transfer speeds which result. > >He used to be one of my users, at two different ISPs, in fact. I >had a long drawn out disagreement about how this was wrong, and >mathematically didn't make any sense. > >However, lots of people have confirmed that it really does >help... which leads me to accept Karl's explanation. > >We shouldn't expect anymore from microsoft, really. > >Darrell

2 1

Re: (*F) Re: USAC and SPIN
by John Fraizer 02 Jun '98

02 Jun '98

At 02:46 PM 6/1/98 -0400, Jay R. Ashworth wrote: >On Mon, Jun 01, 1998 at 09:23:38AM -0500, Jim Fleming wrote: >> Here is some more information for people interested in the more global >> issues of numbering, and network operations. > >[ kilobytes of off-topic drivel elided ] > >Ok; now I'm past _my_ limit, too. > >To whom do I go to file a formal request to filter Jim Fleming's >postings from this mailing list? I've got some nice sendmail filters that do nicely. I just put him in the list of denied addresses, denied domains and denied IP ranges. Email from him bounces as soon as it sees his address in the header or if it is direct and not from nanog, it bounces at the HELO stage. ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

Re: The Great Exchange
by Roeland M.J. Meyer 02 Jun '98

02 Jun '98

At 12:42 PM 6/2/98 +0200, Julian Rose wrote: >Some crystal ball gazing... Those who peer too much, into crystal balls, often eat glass <grin>. >I expect to see an amount of distance billing in the future, but only >alongside QoS billing, for example. > >Email - Non urgent, low traffic - I would expect this to remain flat rate >(i.e. Free with connection). As with browsing traffic etc. Caches will >add an intersting factor to this model, e.g Retrieving files from the ISP's >local cache - (Free with connection), Retrieving from distant locations, >perhaps dependant on time of day etc. Why would there be a difference? On one hand, ISP disk capacity is used and OTOH ISP band-width is used. These days, about the same cost. Besides, it's second-order effect anyway and the market won't stand-still for it. >Voice over IP - This is starting to get bandwidth and delay sensitive >dependant on the efficiency of the Internet in the future, I expect this >might start to be billed dependant on distance/providers travelled over >etc. As otherwise if two ISP's do not directly connect or peer, an >intermediate ISP would have to carry this traffic. If this traffic >requires a high QoS, I would imagine the intermediate ISP would want to >charge for it. Does that "Intermediate ISP" include such as MAE-WEST? They're already charging for it, have you seen NAP bandwidth prices lately? >Video over IP - When it comes around and end users via their xDSL >connections want to receive 1.5Mbs of video traffic - I can see definate >costs being incurred. Of course multicast techniques, caching etc will >make this not a geographical distance based pricing model, but a pricing >model will surely evolve. Until we get decent bandwidth at the end-user site, this simply won't happen. Modem connections barely support Voice-over-IP. I mean a preponderance of end-users must have sufficient direct band-width to make them a decent market. Even when this does happen, they won't want to use it for video. A classic is the MCI commercial where that gal was telecommuting (bath-robing at noon), the last thing such would want is a video-based conference. Been there, doing that. >Of course this argument of carrying others traffic applies to peering also, >if two ISP's peer a similar amount of data, no problem, but if it is one >sided then billing would have to occur. In other words, we will all buy >and sell our connectivity to each other. > >One thing this state of affairs would lead to if it occurs is some scope >for very interesting pricing models, value adds etc. I don't think so. We have had remarkable lack of success in moving away from the flat-rate pricing model, in the face of competition. Customers want predictable bills. Volume based billing will not give them this. However, they are more than willing to pay higher flat-rate costs, if there is value-add. >A topic measured earlier was the ratio between payroll/equipment costs vs >line costs. The ratio of this will depend on the model of the ISP. A >dialup provider will incurr much higher support costs for a much smaller >bandwidth than a transit/backbone provider, which the line costs would be >expected to be the majority of their costs. > >... Perhaps a bit more than 2 cents... > >Julian Rose >---------------------------------------------------------- > Internet Planning & Design >AT&T Unisource Communications Services, Hoofddorp, Holland > Tel: +31 (0)23 569 7878 Fax: +31 (0)23 569 7455 >---------------------------------------------------------- > ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer(a)mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ SecureMail from MHSC.NET is coming soon!

1 0

Re: The Great Exchange
by shields＠crosslink.net 02 Jun '98

02 Jun '98

In article <19980528101417.10618(a)scfn.thpl.lib.fl.us>, "Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> wrote: > On Thu, May 28, 1998 at 03:19:26AM +0000, Michael Shields wrote: [...] > > Probably it will never make market sense to have distance-sensitive > > traffic pricing for "low-speed" users, where the cost of providing the > > service is mostly the cost of tech support, billing, dialin or xDSL > > aggregation, &c., and bandwidth is a small proportion of the cost. > > With current trends, will the actual bandwidth _ever_ be more than a > small fraction of the cost? Despite preductions, very few resources have ever actually become "too cheap to meter". Can you back up your comment about metering requiring three times the current CPU capacity of routers? -- Shields, CrossLink.

10 16