- Test - lists.nanog.org

Re: larger space was: Re: [NIC-....
by Paul Ferguson 16 Feb '96

16 Feb '96

At 07:28 PM 2/15/96 -0500, The Heretic wrote: > >The use of terms like 'shameful' are really out of line when discussing >ideas born from different perspectives. We all know that the continuing >deployment of a hierarchical routing model for the Internet means more >routers sold; big ISPs get bigger; etc. ad infinitum. > Okay -- perhaps ludicrous is a more apropos term. Reality check: ISPs already force renumbering. And as several people have already stated [deja vu, many times over], this draft, if moved to BCP, has no teeth. It simply states that the idea of address ownership is null and void, and Joe's ISP decides to pull up stakes and move to another upstream provider [B] for whatever reason, Joe should not be surprised when his [A] provider asks him to return his address allocation so that its doesn't punch holes in his CIDR block. This makes sense to me. - paul

2 1

Re: larger space was: Re: [NIC-....
by Paul Ferguson 16 Feb '96

16 Feb '96

At 03:23 PM 2/15/96 -0500, Alan B. Clegg wrote: > >How exactly does a larger address space ease deployment of an ISP? >"Current thinking" of who? Sure we should conserve space, but that was >not my argument. My argument is that small ISPs are *NOT* going to >cooperate to get larger blocks. They use any tactic to make themselves >out to be 'larger fish' in that network bowl. Ever seen a nasty catfight >between small local ISPs? I have. Not pretty. Cooperation? Not likely. > This is exactly the type of mentality that the address ownership draft addresses, and without the word 'mandatory' appearing anywhere in the text. This attitude of non-cooperation is shameful. - paul

3 2

ATM availibility and reliability
by Justin W. Newton 15 Feb '96

15 Feb '96

Sorry if this is somewhat off topic, but I couldn't think of a better place to look. I need to get up to speed on ATM in a relatively short time frame, and as a starting point I need to start looking at its current availibility and reliability on a national scale. That topic seems /somewhat/ germane to this group, but if y'all point me somewhere else that would certainly be fine as well. Justin Newton | jnewton(a)hq.mainet.com Internet Administrator # (703) 506-0505 MAI Network Services | Detroit MXP online now # Justin Newton | jnewton(a)hq.mainet.com Internet Administrator # (703) 506-0505 MAI Network Services | Detroit MXP online now #

1 0

Unsubscribe
by Krishin Asnani 15 Feb '96

15 Feb '96

unsubsribe. krish(a)ans.net

1 0

Re: Policy Statement on Address Space Allocations
by jnc＠ginger.lcs.mit.edu 15 Feb '96

15 Feb '96

From: Geoff Huston <G.Huston(a)aarnet.edu.au> it will be economically infeasible IF we continue with this strange system of zero dollar interconnections we use as a peering model. ... In the same way that giving away IP addresses and giving away IP routing can only be described as a very bad case of irrational behaviour, especially when the underlying resource is under stress ... then I'd also note that giving away transit is similarly a case completely irrational behaviour! All this points to a desperate need for a more realistic economic structure to be used within a number of key aspects of Internet infrastructure. Geoff, while I sort of agree with you, please note that the current "free" models in all these areas do have one real advantage, which is that they are simple. Perhaps we will need "more realistic economic structure[s]", but I can more or less guarantee you that those will be more complex as well. Also, that complexity has a cost, which also has to be figured in. (The classic example is long-distance telephone service, where the cost of creting the bill is said to be far larger than the cost of the underlying service.) Finally, given past history, I suspect that the 'Net community, and particularly the 'Net technical community, is going to have a painful transition, on the emotional level and others, to this brave new world of more commercial structures, and the inevitable technical impacts that causes. That has certainly been the case in every such step in the past... Noel

14 24

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

15 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