- NANOG - lists.nanog.org

Re: Satellite latency
by Dickson, Brian 27 Feb '02

27 Feb '02

"Tim Devries" <zsolutions(a)cogeco.ca> wrote: > I think this question may have been asked before, but what is the minimum > latency and delay I can expect from a satellite connection? What kind of > delay have others seen in a working situation? As others have pointed out, GEO is about 22,000 miles, plus offsets for both sending and receiving station, both in lat. and long. There are a lot of satellites up there, on the equator, spaced every 0.5 degrees or so. Another latency factor is something not normally factored in land-based systems. Doppler shift! Satellites are seldom in perfect orbits - they drift up and down, returning to zero (thus in stable orbit), but the relative motion results in clocking issues. Satellite modems usually have 8ms receive buffers to accommodate drift, and when local clocking is not available, clocking transmit from receive requires at least double. On the down-swing, the buffer drains; on the up-swing it fills (both rates are slow, but last a long time). Regardless, the buffer itself adds 8ms to each way delay. A good working value is 280ms each way, *plus* any router serialization delay and terrestrial backhaul at both ends (unless you live at an earth station). > What factors should be considered in end to end connectivity architecture > when utilizing a satellite link? If you have end users, put in a huge web cache, as big as you can afford. Not only will it reduce bandwidth usage, it lowers average latency considerably. Doesn't help non-cacheable content, or other applications, directly, but lowering usage minimizes latency at least. Another approach is asymmetric - buy a low-speed terrestrial link for return path. Round-trip time is the sum of transmit and receive paths, so reducing even one of them helps most applications. Brian Dickson

4 3

Cogent picks up PSInet
by David Ulevitch 27 Feb '02

27 Feb '02

Hello Nanog, Interesting news.... http://washington.bizjournals.com/washington/stories/2002/02/25/daily19.html Cogent Communications Group said Wednesday it will purchase PSINet's major U.S. assets, including part of the Ashburn, Va.-based Internet infrastructure company's customer base and network, certain equipment and three hosting facilities. The companies did not disclose the financial terms of the deal, nor would they provide specific details as to how much of PSINet's network the Washington-based high-speed Internet access provider wants to buy. Cogent (http://www.cogent.com) and PSINet (http://www.psinet.com) officials were not immediately available for comment. PSINet, which filed for Chapter 11 bankruptcy protection with more than $3 billion in debt late last spring, has been selling itself piece-meal -- including international assets in Latin America, Chile, Canada and Hong Kong -- ever since. Cogent's offer to buy part of PSINet's assets is also subject to bankruptcy court approval and requires a court-sanctioned auction. Thanks, David Ulevitch mailto:davidu@everydns.net Founder, EveryDNS.net http://www.everydns.net

2 1

Re: Satellite latency (fwd)
by Ukyo Kuonji 27 Feb '02

27 Feb '02

>The radius of the earth is about 6400km. Geostationary orbit is, as >you note, 36000km above the equator. The path from the satellite to >the North Pole is the hypotenuse of a right triangle with legs of >6400km and (6400+36000)km. That gives a distance from the North Pole >to the satellite of 43000km. It's reasonable to conclude that the >distance from either New York or San Diego is less than that. Is that 36000 km above the equator measures from the surface of the earth, or the center of the earth? I would assume that most companies would use the surface of the earth to determine the orbit, or sea level. Looking at a spam I just received from satcast.com, it looks like they are considering the distance from the dish to the satellite to be roughly 44000 miles. That's roughly 70000 km. Assuming that they are stating that from the dish to the bird, that would account for the larger RTT times that people see. My real problem with these directpc type systems are two fold. The first is that these systems use a USB connection. I use wireless at home since I have a number of laptops. I certainly am not willing to tie myself down to a usb cable. The second problem is that the users are addressed using rfc1918 address space and are translated via nat to the Internet. This may mess up any number of applications that I use, including VPN software. Add to this the first problem, and suddenly I have two levels of NAT that I have to contend with, one on my windows machine connected to the USB cable (with Internet sharing), and one at earthlink's edge. Those are what's keeping me at dialup, even though I only get 28.8 at best. Well... that and the fact that I can't get cable where I live, and the CO is sonething like 15 miles away (not that they can spell DSL out here). _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

3 2

RE: Satellite latency
by Rowland, Alan D 27 Feb '02

27 Feb '02

IIRC, DirecWay is the new name (name change only) for DirecTV related to it's new two way capability. Yes, local packets are up linked, no phone line is involved in the connection. Original marketing material said things like "400kbps down, 128kpbs up" but now only state "best effort." There are various reasons for latency/bandwidth issues including the physical loop distance. As stated by a previous poster, it's better than nothing. IMHO it's yet another great product sullied by the tendency of marketing departments to be highly optimistic. :) Just my 2¢. The delete key is your friend. -Al Rowland Personal capacity -----Original Message----- From: Barb Dijker [mailto:barb@netrack.net] Sent: Tuesday, February 26, 2002 7:09 PM To: Tim Devries Cc: nanog(a)merit.edu Subject: Re: Satellite latency I have a tachyon.net system. 600ms is typical with a good aim. Higher latitudes are more error prone. They don't do tcp/ip over the up/down link. They effectively terminate the tcp/ip session on the local lan (answering handshake and acks), encapsulate, and proxy for you on the other end. It makes a BIG difference in overall performance for typical things like surfing and mail delivery. Doesn't help much for interactive work. Type ahead at 600ms is much better than 2x that. vi is usable. Our unit is available for demos and events. DirecPC (Hughes) now has a business grade service called DirecWay. Haven't tried it. One would expect it would be better than the ones intended for residential only. It claims to go to 1.5M down like Tachyon. Barb Dijker NeTrack

1 0

Re: Satellite latency
by Jim Mercer 27 Feb '02

27 Feb '02

On Wed, Feb 27, 2002 at 07:25:52AM -0700, David R Huberman wrote: > My biggest pbeef is the delay while using ssh or telnet. I attribute > this mostly to speed of light issues. Web browsing, Remedy, and other > IP software seem to work acceptably fast given my expectations. > > Have you found 'tools' to assist removing delay from the typical > connection, especially as it relates to ssh? actually, i think the problem you are seeing is moreso related to the asymetric nature of the connection (i think you were referring to directway which is a "one-way" satelite feed). i generally only use such connections for front-ending a squid server. the problem is that the round trip routing of your packets gets pretty diverse. when you type the packets go out the modem, across a terrestrial network to the uplink, then back down over satelite. not much can be done to make that better. if you "own" the network, there are some tunneling things you can do to make things appear to be less asymetric, which might help, but if you are an end-user, you'll just have to tough it out. alternately, configure your router/etc to use the IP of your dial-up connection for ssh/telnet, instead of the IP of the downlink. this will make your telnet/ssh work using only the dial-up connection, which will eliminate the asymetric routing. (ie. interactive traffic uses the dial-up addr, "bulk" services use the downlink). -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ I want to live forever, or die trying. ]

2 2

Maformed SNMP Packet log/trace
by Brennan_Murphy＠NAI.com 27 Feb '02

27 Feb '02

I need a trace or log file of the Malformed SNMP packets recently tracked by CERT. http://www.cert.org/advisories/CA-2002-03.html Thanks, BM

10 9

Re: ICANN - The Case for Replacing its Management
by brandon＠rd.bbc.co.uk 27 Feb '02

27 Feb '02

> So you support limiting TLDs to make lawyer's lives easier? I said the potential of new TLDs is spoilt by those lawyers and some TLD managers actions. More or less doesn't seem to be the solution to the problem brandon

1 0

Re: Maformed SNMP Packet log/trace
by Eric Brandwine 27 Feb '02

27 Feb '02

>>>>> "sd" == Sean Donelan <sean(a)donelan.com> writes: sd> On Tue, 26 Feb 2002, Richard A Steenbergen wrote: >> A lot of those protocols have people looking at them on a regular basis, >> and they still manage to come up with obscure exploits noone else noticed >> (ex: 23mb of buffer overflows to exploit telnetd). sd> So what is the solution for a public network operator. I attended sd> a presentation last week where a Checkpoint reseller suggested the sd> client needed to buy eight Checkpoint firewalls to protect a sd> single web server. I was impressed, what about the undercoating sd> and scotchguard fabric protector. That's actually a possibility, soon as they support OC-192 interfaces ;) Stay away from the undercoating, but the ScotchGuard(tm) is definitely worth it! sd> Is it time to fall back in punt? How would you architect a backbone if sd> you could do it over? Security is not about making things foolproof. They'll always be able to break you, no matter what you do. Security is about assuming acceptable risk, and mitigating unacceptable risk. This whole recent mess has actually gone over fairly cleanly. The vast majority of public infrastructure seems to have been patched with a fair amount of speed, and nobody's noticed any serious outages due to it. Apparently, the risk we assumed was acceptable, and when it became unacceptable, it was mitigated quickly enough. If I could do it over? I'd get in my Tardis, and go back to 1969. I'd teach everyone at DARPA how to spell security. Loose source route, IP options in general, ICMP address mask requests, all these things should go away. sd> Is the complexity of SSH code worth the protection? Or is it better sd> never to access your routers through VTY ports, and always use an sd> reverse-terminal server to the console from an out-of-band management sd> LAN? Console is slow, logs can easily DoS a 9600 baud line. It only allows one connection. Good fallback point, operationally does not scale. SSH is worth the protection, as reference implementations are available, and it requires very little in the way of system support. As long as in-band access to routers is required, SSH (or HTTPS or IPSec) will be with us. As time passes, the quality of the tools that we have to work with improves, and our trust in them can grow. The official answer is control plane separation. This worked for the PSTN, and it's the way the Internet will go, eventually. ericb -- Eric Brandwine | Things should be as simple as possible, but not simpler. UUNetwork Security | ericb(a)uu.net | +1 703 886 6038 | - Albert Einstein Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

4 3

Re: ICANN - The Case for Replacing its Management
by brandon＠rd.bbc.co.uk 27 Feb '02

27 Feb '02

> The bottom line is that expanding the name space with additional TLDs > solves this problem. Then "Two (or more) companies don't *HAVE* to fight > for identical flat space" - because they are each given unique space. Duh! That was nice until someone decided that they're really trade marks and caused legal people to run around registering in each TLD (you have to collect them all or you're not defending your mark), after that new TLDs were just a license to print money. What a waste. brandon

2 1

Re: ICANN - The Case for Replacing its Management
by John Palmer (NANOG Acct) 27 Feb '02

27 Feb '02

Two of the major root server networks are: ORSC (http://www.open-rsc.org) and PacificRoot (http://www.pacroot.net) We are at www.adns.net ----- Original Message ----- From: "Michael 'Moose' Dinn" <dinn(a)twistedpair.ca> To: "John Palmer (NANOG Acct)" <nanog(a)adns.net> Sent: Tuesday, February 26, 2002 10:28 PM Subject: Re: ICANN - The Case for Replacing its Management > > Where do I go for more info on orsc? > > > > We operate one of the ORSC root servers (H.ROOT-SERVERS.ORSC) and > > have seen a FIVE FOLD increase in traffic since the "big announcement" > > yesterday. > > > -- > Michael 'Moose' Dinn, Twisted Pair Network Consulting Incorporated > dinn(a)twistedpair.ca // 902 423 4700 (voice) // 902 423 8407 (fax) > > Colocate your server in our underground bunker! >

1 0