- Test - lists.nanog.org

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

/24 in the RIPE netblocks
by Mikael Abrahamsson 02 Jun '98

02 Jun '98

Ripe delegates the 193/8, 194/8 and 195/8 blocks to european customers and some of these are /24 called "provider independant" nets and therefore arent connected to an ISP but rather directly to the customer and thus by definitition cannot be aggregated. The original idea was to have these so people wouldnt have to renumber when changing ISPs. I guess a lot of you consider this "a bad thing" (tm) but it's the way it is... My question is how many in the US filter out these /24 announcements from these blocks? And if you filter, would you consider making an exception for /24 in 193,194,195/8? ----- Mikael Abrahamsson email: swmike(a)swm.pp.se

3 2

RE: (*F) Re: USAC and SPIN
by Jim Fleming 02 Jun '98

02 Jun '98

On Monday, June 01, 1998 4:18 AM, James Rishaw[SMTP:jamie@dilbert.ais.net] wrote: @If you're trying to infer that SPIN = IP addresses, you're way wrong. @ 1. No, I was not trying to infer that. 2. There is more to life than configuring routers. 3. I often wonder if people that configure routers know how routing *should* work. Do people that drive cars know how cars work ? Do they care ? Here is some more information for people interested in the more global issues of numbering, and network operations. The U.S. Government provides ISPs with SPIN numbers, FREE of charge. Service Provider Identification Number (SPIN) ARIN sells 16 bit ASNs for $500. <http://www.arin.net> The IEEE provides 24 bit Organizationally Unique Identifiers (OUI). <http://standards.ieee.org/db/oui/> The cost of the OUI is U.S. $1,250. Maybe we should create a Top Level Domain named .SPIN. That TLD could be used to register the free SPIN numbers at the second level. For example, Bell Atlantic might have 143001398.SPIN for Pennsylvania. A TXT Record could be included in the DNS to contain the name "Pennsylvania" for the SPIN number. After registering a SPIN number, an ISP could add A records for their ASNs and OUI information. Since an A record is a general purpose container for 32 bit quantities, a single A record can be used to hold an ASN in the low 16 bits. Another A record can hold the 24 bit OUI in the low 24 bits. With this, the following DNS entries would return A records: ASN.143001398.SPIN OUI.143001398.SPIN As an alternative to the above, ARIN could negotiate with the IEEE to obtain a unique 8 bit pre-fix for a block of OUI codes. This would allow the 16 bit ASN to be combined with that prefix to complete the unique 24 bit "company id" that is used in many IEEE standards. This would allow ARIN to provide OUI numbers for $500 which is less than the IEEE charge of $1,250. Still another approach would be for ARIN to negotiate with the Universal Service Administrative Company (USAC) to obtain a block of SPIN numbers. Since ASNs are 16 bits, the largest value is 65535. Maybe USAC can assign a SPIN prefix such as 1431xxxxx and all ASNs could be mapped to SPIN numbers. This would effectively allow ARIN to create SPIN numbers for $500 each. @@@@@ Other References @@@@@@ @@@ http://www.neca.org/usnewrel.htm Whippany, NJ -- May 21, 1998 - The Universal Service Administrative Company (USAC) is pleased to announce the appointment of former Wisconsin Public Service Commission (PSC) Chairman Cheryl L. Parrino as USAC's first Chief Executive Officer (CEO), effective June 1, 1998." @@@@@@@@@@@@@ @@@@ http://www.bell-atl.com/edk-12/spincode.htm Bell Atlantic Service Provider Identification Numbers (SPIN) 143001398 143002680 143001362 143001422 143001401 143001432 143002681 143012559 143001291 143001288 143001303 143002682 143001314 143001359 143004468 143004333 143000677 @@@@@@@@@@ @@@@ http://www.neca.org/funds/usacspin.htm "For companies which have not filed a FCC Form 457, you may contact USAC at (888) 641-8722 to obtain a SPIN assignment. @@@@@@@@@@@@@@@@@@@@@@@ @@@ http://standards.ieee.org/faqs/OUI.html What is an Organizationally Unique Identifier (OUI)/"company_id"? An OUI/"company_id" is a 24 bit globally unique assigned number referenced by various standards. OUI is used in the family of 802 LAN standards, e.g., Ethernet, Token Ring, etc. @@@@@@@@@@@@@@@@@@@ @@@@ http://standards.ieee.org/db/oui/tutorials/lanman.html Use of the IEEE assigned Organizationally Unique Identifier with ANSI/IEEE Std 802-1990 Local and Metropolitan Area Networks @@@@@@@@@@@@@@ @@@ http://standards.ieee.org/db/oui/tutorials/cdpd.html Cellular Digital Packet Data Networks The EUI-48 consists of the 24 bit company_id (assigned by the IEEE/RAC) and a 24 bit unique CDPD M-ES number (assigned by the manufacturer). @@@@@@@@@@@@@@@@@@@@ @@@ http://standards.ieee.org/db/oui/tutorials/futurebus.html Use of the IEEE assigned 'company_id' value with IEEE Std 896.2-1991 Futurebus+ Physical Layer and Profiles @@@@@@@@@@@@@@@@@@@@ @@@ http://standards.ieee.org/db/oui/tutorials/EUI64.html GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY @@@@@@@@@@@@@@@@@@@@@@ Jim Fleming Unir Corporation - An H.323 GateKeeper for the IPv8 Network http://www.unir.net 0:196 .MALL

5 4

PROPOSAL #2 - reform of the fee schedule (fwd)
by Karl Denninger 01 Jun '98

01 Jun '98

I am expanding the discussion list to NANOG and the ARIN Members mailing lists. Please post comments PUBLICALLY, or if you feel you cannot do so without "cloaking" yourself, through someone else (who you trust to strip the attribution). Towards a more fair fee proposal: I would like to ask the AC to direct Kim Hubbard to produce a list of the number of allocations in each of the fee categories currently listed, along with the documentation required to process each. >From this I believe we will find: 1) *TO BE FAIR*, one must document all allocations and use in all existing space at least bi-annually (once every two years) when coming back for more space. 2) A smaller allocation history naturally has less to produce. Therefore, I argue that the fees should be *proportionate* to the existing space. The smallest allocation, a /19, is 8192 addresses. Let's say that we set the "desired entry price" at $2,000. Therefore, the "cost per address allocated, including the current request", is set at, say, $0.25. Now Mr. Big Provider comes in and wants space. They have, let's say, the equivalent of an /8. They pay ~$4M under this formula. Obviously, we have just set the cost too high. Ok. ARIN has an operating budget of $2M. So we cut the base cost by 90%. Therefore, the /19 requestor pays $200 (!), or 0.025 cents per address IN USE, including the NEW requested allocation. Mr. Big Provider pays ~$400,000 Annually. The first allocation you request in a calendar year, you get assessed for ALL space you have, including the request you put in for. So if you have a /16, and ask for another /16, you get assessed for 65536 * 2, or 128k addresses. This works out to a fee of $3276.80. Note that if you ask for less, the fee is lower. There's your resistor on people asking for more than they need - it costs money (regardless of whether or not you get approved!) This is *FAIR*. We're now charging for the amount of verification work to be performed and EVERY allocation is treated equally. Now the reality is that this will put us WAY over budget. This is GOOD. What we need to do then is cut the base membership fee to something that ordinary people can afford - $50/year. The stakeholders should have a say in this, and the stakeholders, folks, are the average users. Would someone please tell me why this isn't a more proper fee strategy? -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

4 4