February 1996 - Test - lists.nanog.org

Re: Idea for US Internet Benchmarking System...
by Eric Kozowski 14 Feb '96

14 Feb '96

>>The question we would like to pose to the provider community is, "Is >>this interesting and useful?" If the answer is yes, we will proceed >>with our work. >> > >Well, I can somewhat speak from an ISP perspective, since that is my >bailiwick; I can certainly see immense usefulness in such an application. >The ability to use asymmetric paths for troubleshooting is, from my >perspective, quite attractive. > >Please -- proceed. :-) Definately. I just had a problem today that would have been much easier and quicker to troubleshoot with a tool like that. As it was, it took about an hour w/ the MCI and AlterNet NOC, as well as myself, to diagnose a routing problem and get it fixed. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

1 0

NANOG multicast ?
by Andy Schmidt 14 Feb '96

14 Feb '96

Will the San Deigo meeting be multicast on the mbone? I don't recall seeing it in sd. ags

1 0

Re: Idea for US Internet Benchmarking System...
by Paul Ferguson 14 Feb '96

14 Feb '96

At 03:05 PM 2/14/96 -0500, Jamshid Mahdavi wrote: > >The question we would like to pose to the provider community is, "Is >this interesting and useful?" If the answer is yes, we will proceed >with our work. > Well, I can somewhat speak from an ISP perspective, since that is my bailiwick; I can certainly see immense usefulness in such an application. The ability to use asymmetric paths for troubleshooting is, from my perspective, quite attractive. Please -- proceed. :-) - paul

1 0

unsubscribe now
by Jordan Sharpl 14 Feb '96

14 Feb '96

unsubscribe nanog(a)merit.edu unsubscribe now

1 0

Idea for US Internet Benchmarking System...
by Jamshid Mahdavi 14 Feb '96

14 Feb '96

Matt and I have invented a way of expanding our Treno page to be far more useful to the US ISP community. This note is a brief description of what we have in mind; we'd like to hear comments from providers on whether they would be interested in this capability. The current Treno server uses treno in an attempt to emulate TCP behavior on a straight path from the PSC to an end site somewhere in the Internet. This feature, while useful, is somewhat limited in that all of the benchmarking tests start with our single provider, MCInet. We have found that, by using GRE tunnels, the vBNS, and some smoke and mirrors, we can offer a Treno-type test starting at any router at any NAP, traversing the Internet to a host of your choice, which then returns ACKs to the Treno server via the NAP of your choice. We believe that this very general capability, not rooted in any provider or NAP, will be very useful to debugging Internet performance problems. More details on how this could work: We would attach the Treno server directly to the vBNS, where is would have a clear path to each of the NAPs. A GRE tunnel (RFC1701 & 1702 if you are unfamiliar) would be set up between the Treno server and NAP routers owned by ISPs interested in participating. The Treno server would encapsulate probes inside of GRE packets and deliver them to the appropriate exit router. This router strips off the outer headers, and forwards the probes to their destination. These packets use a source address based on the NAP desired for return traffic. For example, a provider wishing to test their infrastructure could launch a Treno test which originates at the Sprint NAP and traverses their infrastructure to the PacBell NAP. The test would indicate the overall throughput for the path. The reverse test could be done independently, allowing the isolation of assymetric problems. Another example, a user seeing poor performance to a remote site. The user could indepently test performance from their closest NAP to each of their site and the remote site. If they wished, they could also look at the view from another NAP or a third provider not related to their site or the destination site. After this analysis, it would be trivial to file a trouble ticket with the provider who owns the problem. (An aside -- providers who participate would have access to the logs, so the user filing the trouble report could simply send a URL with the Treno summary indicating the problem. This might greatly aid the communication process between end-users and providers. Heck, we could even add a mailto: button to the page...) We have tested the GRE tunneling capability on a local Cisco 7507, and have found that the load placed on the router to de-encapsulate GRE packets is about the same as what treno currently places on Cisco 7500 class routers. If there is interest, and we procede with this idea, we would include a rate throttle which would automatically stop a treno test running at rates which would put more than a minimal load on the routers performing the GRE tunneling. For example, 100 pps puts about a 5% load on our 7507. If we throttled at this rate, people would still be able to run tests up to speeds to 3.2 Mb/s at FDDI size packets, or 1.2 Mb/s at ethernet sized packets. It is in principle possible for each GRE tunnel to define a different throttle, so that heavily loaded NAP routers could be more protected than less loaded routers. In addition to rate throttling, we plan to update the Treno code to run tests in reverse (starting at the end point and reducing the TTL, rather than the current algorithm) and also to emulate, rather precisely, the proposed TCP SACK (draft-ietf-tcplw-sack-00.txt) behavior. During the implemention of this plan, we would use a phased testing period to give providers a chance to test and use the new server on their infrastructure prior to openning it up to the general public. It might also be feasible to keep separate provider access which allows providers to do things to themselves (in order to debug problems) which normal mortals using the server would not be able to do. The question we would like to pose to the provider community is, "Is this interesting and useful?" If the answer is yes, we will proceed with our work. For all you non-US people who have patiently read this far, don't necessarily think you will be left out in the cold. If the first phase of this tool works, we are interested in exploring ways to expand this capability to include non-US sites. Please send us your feedback on these ideas. Matt will also be at the NANOG meeting tomorrow if you want to ask us questions directly. --Jamshid & Matt PS. The current Treno server is at http://www.psc.edu/~pscnoc/treno.html

1 0

last minute addition
by Elise Gerich 14 Feb '96

14 Feb '96

For those of you who are interested, Steve Richardson and Jake Khuon are prepared to give a quick tutorial on how to register in the RADB and how to establish a peering session with the Route Servers. Steve and Jake will offer this tutorial immediately following the last session on Friday, February 16th. More info on this at the NANOG meeting. See you in San Diego. --Elise

1 0

Re: [NIC-960209.1757] Routing Problem (fwd)
by Simon Chan 14 Feb '96

14 Feb '96

> On Mon, 12 Feb 1996, Paul Ferguson wrote: > > > Creating a consortium [akin to the NAP model] of small ISP's could > > easily resolve this problem, if all address space allocated to each > > ISP was contiguous and could be aggregated to a larger prefix. > > > > This has been suggested on numerous occasions. > > It's not only been suggested, but I believe it's been somewhat > implemented. :) Back in September '94, Chris Alan (Electriciti) and a few > others came up with an idea called PCH -- Packet Clearing House. > > The primary concept was, as you suggested, connect a bunch of small ISPs > together using shared resources and address space and peer with the "big > boyz." Unfortunately I haven't been involved with it lately, so hopefully > someone that has can share if it was successful or not. > > > -jh- > > The unfortunate requirement of such scheme to work is that all address space allocated to the small ISP's has to be contiquous so that it could be aggregated to a larger prefix under an autonomous system. Given the completely arbitrary manner adopted by the Internic's address allocation policy, (eg. 4 C's to ISP A, skip a few C's, 8 C's to ISP B where A and B can be 4,000 miles apart) it is safe to assume that the small chunks of C class addresses are geographically dispersed throughout the States with many holes still unassigned or unaccounted for. If you are talking about swamp, this is it. However, a survey for how those chunks of address got broken up into many different places perhaps can help in the direction of finding such solution. If these small IP pieces can be grouped together according to their geographic locations, there is chance that some broken chunks may be pieced together to form large enough piece by pure luck. If such solution exists, I am sure someone would be interested in forming such regional consortiums to help salvage the once lost IP addresses. SC SC

5 4

ISP Domain Auction
by Mark Kosters 14 Feb '96

14 Feb '96

Hi The InterNIC appreciates the concerns of the Internet community about the auction of a block of domain names. Until now, we have maintained the position that we have no oversight responsibility regarding the resale of domain names other than they be actively used on the Internet. If you have any constructive comments about the role that the domain registrar should take in this case, we will be happy to help develop an IANA sanctioned policy to exercise such a role. There is a list already setup to discuss domain policy-related matters - domain-policy(a)internic.net. To subscribe, send a message to domain-policy-request(a)internic.net with "subscribe domain-policy" in the body of the message. Regards, Mark -- Mark Kosters markk(a)internic.net +1 703 742 4795 Software Engineer InterNIC Registration Services

1 0

Re: [NIC-960209.1757] Routing Problem (fwd)
by kai＠netcom.com 13 Feb '96

13 Feb '96

Sprint's filtering of routes based on prefix-length has made the popular press: Communications Week International, Oct.20,1995 (as far as I can tell from the website). Please take a look at: http://techweb.cmp.com/techweb/cwi/current/153newssprint.html The article unfortunately quotes me completely out of context: I was never asked by the correspondent in question (Christy Hudgins-Bonafield), nor informed that I would be quoted, or things would have been portrayed a little different, as I cannot remember having uttered words that could be interpreted as "Schlichting said Sprint's action disrupted an international conference of 600 government and civilian participants in Kazakhstan late last month." I am somewhat upset that it took using the new big brother tool 'http://altavista.digital.com' to find this reference , today. Needless to say, it came up with other interesting digital footprints of my past. Small fact sheet: - BelCom was a client of a Sprint reseller at the time, and was not victim of Sean's policy, but WOULD have been , if we had been a non-Sprint- connected network at the time - connectivity was impaired by not having an entry of the network (a /22) in the routing registries (who was responsible for this remains unclear, people at ANS and the Sprint INSC were ultimately helpful with this issue) - the conference was a great success, the real-IP connectivity was "The" killer at the conference. Indeed it was so successful, that we decided to present the Internet at the regional Oil&Gas show the week after, with DEC's support and contributions (which shall not go umnmentioned here) Note, that at the time I had full justification for an independent network number block, as the plan was to multi-home said network in both Moscow and New York, with growth expections beyond rationality (confirmed by success and follow-up inquieries resulting from the shows). BelCom (net worth: $25M) has been decapitated by Comsat Corp. (net: $900M) since, in what I call a 'corporate crime in progress' : the failure to successfully usurp BelCom into Comsat's empire has led to an internal power-struggle at Comsat, with Beltway-Lions fighting over the control of a $900M company. Can you say 'chopped heads' , 'body bags' , anyone ? For control over one billion dollars, people will do anything. I have never seen people act so ugly in my life. As one of the managers, I am getting dragged into a mess of lawsuits at this time, with the DC boys and girls sending gov't agencies my way, the whole charade: if you thought COINTELPRO was a joke, think again: DC stands for District of Crime, and Norman Schwartzkopf meant this literally. In most likeliness, we will see a new chapter of the entire filtering issue very soon: I am working on a new New York-Moscow IP link for a new company at this time: same issues, same story, just a different name. To Sean Doran: I was rather impressed by your recent statement, call it commitment to your business: reselling IP wholesale, with the goal of preserving functionality of the network as a whole, and a commitment to what I previously believed to be untrue: not to squeeze the small guys out of the market with arbitrary new filtering rules. Yet, I think it's necessary to not follow this policy indefinitely into the future: - we need faster routers. Cisco does not provide them at this time. Where will they come from ? Take a look at the 'gigarouter' (URL lost right now): it seems to implement what we have been talking about before: a general purpose unix-type engine for route processing, with interface cards with memory to hold complete static routing tables. The two components talk on a separate bus with each other, both can be upgraded independently. MCI uses them for the experimental vBNS. - IPv6 will not solve aggregation issues the way we would like to see it: we will see a greater trade-off for non-optimal routes (number of hops, length) in favour of more aggregation, though. What is growing faster: link speed, or processing power ? We all know the answer. In the end, engineering will prevail over filtering, and when this is reality, I expect the route filtering to disappear: if it doesn't, it will go the way 800 numbers have gone: it took a significant change in technology to accomplish number portability, but it was done because the customers wanted it, and because AT&T (rightfully) feared to lose a lot of business, yet had to cave in to external pressure, and to Judge Greene. If you don't want to see the equivalent of Judge Greene on the Internet, you (major NSPs) will soon dedicate significant resources to solving the problems mentioned here. bye,Kai ------------------------------------------------------------------------ Kai Schlichting Independent Telecommunications Consultant Internet Consultancy : Cisco, Livingston, BSDI, SunOS, Linux spoken here New York City, NY kai(a)netcom.com

1 0

Re: [NIC-960209.1757] Routing Problem (fwd)
by Paul Ferguson 13 Feb '96

13 Feb '96

At 10:54 AM 2/13/96 -0800, bmanning(a)ISI.EDU wrote: >> >> CIDR is a hell of a lot more than a band-aid. It extends the life of >> IP v4 for an indiscriminate amount of time, and while v6 may be just > indeterminate <-- Intended? Okay. Busted. :-) >> around the corner [according to some sources], the same type of CIDR >> mechanisms will still be needed. >> > > Heck of a BandAid... like a heart transplant. > Now if we could just get brain transplants.... :) > >--bill > What would we do with them if we had them? - paul

1 0