NET99 Allows Resellers !!!
Aaron Nabil
>Attention: Resellers
>
>Network 99, Inc. NET99 is operational and OPEN for business !!!
>
>NOTE: NET99 allows you to resell services without the hassle you have had
>in the past.
So does Sprint!
-a
NET99 Network Operations
Attention: Resellers
Network 99, Inc. NET99 is operational and OPEN for business !!!
Contact: SALES
Phone: East Coast 703-442-7353
West Coast 602-780-7533
E-mail: ne...@cluster.mcs.net
Services: 56k, T-1, 10 Mbts
Service Area: Boston, New York, Washington D.C., Philadelphia, Baltimore,
Atlanta, Houston, Dallas, Los Angeles, San Jose, San Francisco,Minneapolis,
NOTE: NET99 allows you to resell services without the hassle you have had
in the past. We supply a USENET feed and offer DNS services at NO extra cost.
Business Hours are from 9 a.m. - 5 p.m. Mon - Fri.
--
Network Operations Center * Chicago *
Paul A Vixie
Karl, does someone with only a Net99 connection have access (that is, can
packets be exchanged) with NSFnet-only sites? If you have connectivity to
places that CIX does not, this is something the world would probably like
to know about.
--
Paul Vixie
La Honda, CA
<pa...@vix.com>
decwrl!vixie!paul
Karl Denninger
John Palmer <j...@tygra.Michigan.COM> wrote:
>In article <383eds$6...@Mercury.mcs.com> ka...@MCS.COM (Karl Denninger) writes:
>"In article <1994Oct19.0...@sonic.net>,
>"Dane Jasper <da...@sonic.net> wrote:
>">Aaron Nabil (na...@i.net) wrote:
>">a 56k.. (something like that, at least..)
>">
>">Dane
>"
>"Sprintlink is $2700 a month for a T1.
>"
>"And $1k/month for a 56kbps.
>"
>"The only way to get below that is to go with a LONG TERM commitment, and if
>"you quit on them part way through you end up paying *big time* for the
>"cancellation. This is true of all discounts; you give something up for
>"that, and its usually the right to leave.
>
>
>Rabbit Network offers T1 connectivity for $995, no bull, no tricks and
>no prepayment (with credit approval). $1100 setup fee rather than 2 or
>3k. (Note: Costs do not include the telco circuit, but then neither
>does NET99's $2k).
C'mon, John, Rabbit is a single T1 attachment in one place (Sprint).
Net99 is a *national* backbone with points of presence in cities all over
the US, peering agreements at the MAE and elsewhere, and significant
infrastructure.
MCSNet sells connectivity in the Chicagoland area. Net99 is a national
carrier and sells US-wide at the present time.
>We can get a T1 in to you OPERATIONAL in as little as EIGHT DAYS -
>THATS 8 CALENDAR DAYS, FOLKS! Karl's three days were probably within
>the same city.
Uh, Net99's sales office is in Phoneix, corporate on the east coast, and
the Network Operations (NOC) is in Chicago.
>If you are in Michigan, Ohio, Indiana or Wisconsin, RabbitNet can
>handle your dedicated circuit access to the Internet.
>
>Oh, and by the way, we also allow reselling at no additional costs!
>(With dedicated access, not with dial-up SLIP or UUCP).
And when you've sold 20 T1s, all going down the single T1 you have to
Sprint, and all resellable? Then what?
>P.S. - we won't force you to join any trade organization attempting
>to extort money from you by threatening network connectivity unless
>you pay them $10k a year. ;->
Neither does Net99. Net99 has no official policy on trade associations
or membership in them. Each customer must evaluate the value such an
organization brings to their operation on their own. We are in the
business of selling pipes and faucets; the water issues are up to the
individual customer.
Net99's business is providing connectivity. That's it. If you have
specific reachability questions just ask -- we can check from our core to
see if a specific location is reachable.
We've yet to say "no" to this request, by the way.
--
--
Karl Denninger (ka...@Net99.Net) | Net99 - Connectivity at a reasonable price
VP Network Engineering | Mr. Packet Says "Don't delay, reroute today"
Karl Denninger
Paul A Vixie <vi...@gw.home.vix.com> wrote:
>(Open letter to Karl@MCS)
>
>Karl, does someone with only a Net99 connection have access (that is, can
>packets be exchanged) with NSFnet-only sites? If you have connectivity to
>places that CIX does not, this is something the world would probably like
>to know about.
Yes. Net99 is AUP and NSFNet approved, and peers with ANS for transit to
NSF sites for those customers who agree to uphold the NSF AUP.
Karl Denninger
Josh Schneider <sch...@eagle.intlink.net> wrote:
>
>
>This is what I got with traceroute:
>
>> traceroute chicago-1.net99.net
>> traceroute: unknown host chicago-1.net99.net
>
>I tracerouted approx 10 other nets and it worked fine. (All 'cept net99
>that is). What is going on here?
Your nameserver is broken? Here's a dig from one of the big ones,
ns.uu.net, for chicago-1.net99.net:
; <<>> DiG 2.0 <<>> @ns.uu.net chicago-1.net99.net
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10
;; flags: qr rd ra ; Ques: 1, Ans: 1, Auth: 2, Addit: 2
;; QUESTIONS:
;; chicago-1.net99.net, type = A, class = IN
;; ANSWERS:
chicago-1.net99.net. 486598 A 204.157.0.131
;; AUTHORITY RECORDS:
NET99.NET. 486598 NS CEREBUS.MCS.COM.
NET99.NET. 486598 NS GENESIS.LACHMAN.COM.
;; ADDITIONAL RECORDS:
CEREBUS.MCS.COM. 159020 A 192.160.127.125
GENESIS.LACHMAN.COM. 65816 A 192.35.52.14
;; Sent 1 pkts, answer found in time: 126 msec
;; FROM: Mercury.mcs.com to SERVER: ns.uu.net 137.39.1.3
;; WHEN: Fri Oct 21 01:57:10 1994
;; MSG SIZE sent: 37 rcvd: 153
Sure as heck is present and accounted for.
>--
>Joshua E. Schneider /|\ TCP/IP Systems Integration
>Vice President & Operations Manager /|\ Since 1976. Advanced and
>American Information Systems, Inc. /|\ Large Scale Internet & WWW
>E-mail: schn...@ais.net /|\ Design and Implementation.
I don't know what the problem might be.
Bruce Sterling Woodcock
>In article <PST.94Oc...@feta.cisco.com>,
>Paul Traina <p...@shockwave.com> wrote:
>>In article <3843s6$n...@Mars.mcs.com> ka...@MCS.COM (Karl Denninger) writes:
>>
>> >What is the size of your outbound pipes?
>>
>> We peer in multiple locations, including MAE-EAST. The MAE is a 10Mbps
>> interconnect, and can be a 100Mbps FDDI interconnect (if we see the need for
>> it). Other interconnects are being sized appropriately for the traffic
>> carried.
>>
>>MAE-EAST is a 10mb ethernet.
>>
>>How big is your pipe to MAE-EAST?
>
>Net99 sits on a dialable-bandwidth ATM framework (with a few tricks in the
>middle). As a result we are able to order bandwidth on demand, and will
>certainly use a number of technologies in the future as appropriate when
>load rises to the point that these capabilities are required.
Yes, but how big is it *right now*? To say you have enough bandwidth to
handle existing traffic isn't saying much if not much traffic is currently
going over it. :) Your response, while true, amounts to little more than
marketing fluff. What happened to the no-nonsense, plain-speakin' Karl
Denninger I used to know?
>>Are you saying you have direct pipes to nearly every other major service
>>provider out there? Wow, that is impressive. I didn't realize Net99 was so
>>well funded. Who exactly do you have other direct pipes with (if the number
>>is more than 5, just keep to to the 5 biggest peer service provider links).
>
>No, I'm not. Our exact topology is proprietary, for obvious reasons.
>We peer and interconnect where and when it makes sense. Net99 has very
>rich interconnectivity. I have not yet run into a host I cannot reach
>over it, but I'm sure there are some out there.
A lot of places currently connect at MAE-East. So anyone who connects
via MAE-East can probably say "X-Net has very rich interconnectivity.
I have not yet run into a host I cannot reach over it, but I'm sure there
are some out there" and get away with it.
The "exact topology is proprietary" defense is a good one (I've heard Netcom
use it), but he's not asking for your exact topology. He's asking where you
interconnect. Why are you so shy about sharing? Here's an example:
NETCOM is connected to the Internet via 3 high-speed links:
1. A 10 Mbits/sec connection to MAE-East in Washington, DC.
MAE-East is a shared ethernet connection among many Internet
providers, including PSI, SURAnet, AlterNet, and SprintLink.
2. Direct T1 (1.544 Mbits/sec) to CIX (Commercial Internet eXchange)
in San Jose, CA. This is another common access point among
commercial providers.
3. Direct T1 (1.544 Mbits/sec) to the NFSNet (via ANS), also in
San Jose, CA.
Our internal network of POPs are connected mostly by T1's, with
a T3 (44.736 Mbits/sec) backbone linking San Jose, Chicago,
and Washington DC. Additional T1's are supported on high-traffic
links, such as the one between San Jose and Los Angeles.
I mean, anyone with traceroute and a few hours to kill can get a
good idea of your network, including what service providers you connect
with and where. So, why not just tell us who you currently conenct with
directly and who you don't? It's okay, really, to just say "No, we
are currently not connected to Netcom or PSI except via peering at
MAE-East, although we do plan on doing so next year" or something
like that. Net99 is a new network; no one expects you to be a major
backbone overnight. What they *do* expect is that you don't smokescreen
anyone into making them think you *are* a major backbone overnight.
Btw, I also have three curious questions:
1. Does Net99 service mcs.com directly? I thought they had a Sprintlink
connection. What exactly is the relationship between these two
enterprises?
2. Is Net99 really just a nationwide access provider, like PSI or Netcom,
or is it a cooperative like CIX? Do customers of Net99 have control
over it's administrative decisions?
3. Does Net99 connect to CIX? If not, why not?
Bruce
--
Bruce Sterling Woodcock ster...@netcom.com
The views and opinions expressed in this post are not necessarily those of
my employer, NETCOM On-line Communication Services. Honest, they aren't.
Peter Berger
>In article <PST.94Oc...@feta.cisco.com>,
>>Are you saying you have direct pipes to nearly every other major service
>>provider out there? Wow, that is impressive. I didn't realize Net99 was so
>>well funded. Who exactly do you have other direct pipes with (if the number
>>is more than 5, just keep to to the 5 biggest peer service provider links).
>
>No, I'm not. Our exact topology is proprietary, for obvious reasons.
What is "obvious" about a network provider not being willing to tell it's
potential customers what it's network looks like?
Anyone who purchases bandwidth -without- knowing what the provider's
network looks like is pretty naive. Did you guys just take MFS Datanet's
promises on faith, or did you demand to look at how they've engineered
their network? I know you're smarter than that, Karl, and I know you know
how -your- provider's network is engineered. So how about giving some of
us potential customers the same credit?
What -is- your exact topology?
--
......................................................................
Peter G. Berger, Esq. Telerama Public Access Internet, Pittsburgh
Internet: pet...@telerama.lm.com Phone: 412/481-3505 Fax: 412/481-8568
http://www.lm.com/users/peterb/peterb.html
Tim Pozar
: In article <3843s6$n...@Mars.mcs.com> ka...@MCS.COM (Karl Denninger) writes:
: >What is the size of your outbound pipes?
: We peer in multiple locations, including MAE-EAST. The MAE is a 10Mbps
: interconnect, and can be a 100Mbps FDDI interconnect (if we see the need for
: it). Other interconnects are being sized appropriately for the traffic
: carried.
: MAE-EAST is a 10mb ethernet.
: How big is your pipe to MAE-EAST?
: MAE-EAST is horribly overloaded precicely because it's only a 10mb ethernet
: and some providers out there just default to it.
: What about MAE-EAST+?
:[...]
Actually what was discussed at a PCE meeting at PacBell in San
Ramon a couple of weeks ago by MFS folks was that MAE-EAST is a
switched 10Mb/s connection for ISPs and each switch box has an FDDI
ring running at 100Mb/s between them. You may have old information
as they used to be just an 10Mb/s ethernet pipe.
Tim
John Palmer
"In article <1994Oct19.0...@sonic.net>,
"Dane Jasper <da...@sonic.net> wrote:
">Aaron Nabil (na...@i.net) wrote:
">a 56k.. (something like that, at least..)
">
">Dane
"
"Sprintlink is $2700 a month for a T1.
"
"And $1k/month for a 56kbps.
"
"The only way to get below that is to go with a LONG TERM commitment, and if
"you quit on them part way through you end up paying *big time* for the
"cancellation. This is true of all discounts; you give something up for
"that, and its usually the right to leave.
"
"make by doing so.
"
"Look at all the numbers, and all the facts. Then decide. Net99 is the
""no smoke and mirrors; just good service at a reasonable price" company.
"
"$2k/month for a T1 with no resale bull, no tricks (like a frame relay
"connection with a 56kbps CIR) and no hassles is a damn good price. In
"cities Net99 serves we generally can turn up a line as fast as you can get
"a circuit provisioned to one of our POPs.
"
Rabbit Network offers T1 connectivity for $995, no bull, no tricks and
no prepayment (with credit approval). $1100 setup fee rather than 2 or
3k. (Note: Costs do not include the telco circuit, but then neither
does NET99's $2k).
We can get a T1 in to you OPERATIONAL in as little as EIGHT DAYS -
THATS 8 CALENDAR DAYS, FOLKS! Karl's three days were probably within
the same city.
If you are in Michigan, Ohio, Indiana or Wisconsin, RabbitNet can
handle your dedicated circuit access to the Internet.
Oh, and by the way, we also allow reselling at no additional costs!
(With dedicated access, not with dial-up SLIP or UUCP).
P.S. - we won't force you to join any trade organization attempting
Karl Denninger
>Let me preface this with the fact that I'm a supporter of Net 99 in
>its idea of offering a good alternative to the mess we currently have
>of backbones which don't allow reselling very easily.
>
>I'm also impatiently awaiting the day when Net 99 is working smoothly
>with a host I have access to.
>
>Now, to the poop:
>
>In <38955l$l...@Venus.mcs.com> ka...@MCS.COM (Karl Denninger) writes:
>
>>Try it for yourself; I am happy to provide performance and reachability
>>numbers to other network providers.
>
>Since I took it out of context, I forget exactly what I'm supposed to
>try myself, but in the same vein, I did try these things myself. I'm
>sure that soon Net 99 will have a solution? I hope so ... I need more
>options than Sprint.
>
>Here are two traceroutes. One, I emailed to Karl. One, I didn't.
>Karl did respond very quickly. Thanks, Karl. But, now, there's
>another network doing the same thing ... so it's not just Sprint.
>It's also ANS. Hmm. A conspiracy?
Not at all.
Go ahead and play the "blast the traceroute" game. It is meaningless and
those of you who understand network engineering know it. If you want real
numbers, you have to run real traffic tests. It is common to option
equipment to consider anything done via traceroute to be "low intensity",
and even more common for variable pathing to make the TTL guessing that
traceroute uses cause this kind of thing to come back.
Karl Denninger
Peter Berger <pet...@telerama.lm.com> wrote:
>In article <38955l$l...@Venus.mcs.com>, Karl Denninger <ka...@MCS.COM> wrote:
>>In article <PST.94Oc...@feta.cisco.com>,
>>>Are you saying you have direct pipes to nearly every other major service
>>>provider out there? Wow, that is impressive. I didn't realize Net99 was so
>>>well funded. Who exactly do you have other direct pipes with (if the number
>>>is more than 5, just keep to to the 5 biggest peer service provider links).
>>
>>No, I'm not. Our exact topology is proprietary, for obvious reasons.
>
>What is "obvious" about a network provider not being willing to tell it's
>potential customers what it's network looks like?
>
>Anyone who purchases bandwidth -without- knowing what the provider's
>network looks like is pretty naive. Did you guys just take MFS Datanet's
>promises on faith, or did you demand to look at how they've engineered
>their network? I know you're smarter than that, Karl, and I know you know
>how -your- provider's network is engineered. So how about giving some of
>us potential customers the same credit?
>
>What -is- your exact topology?
Sorry, Peter, if you want that get out the pen, call 1-800-NET99-IP, and
sign a non-disclosure agreement. If you're serious about purchasing from
Net99 then this should not be a problem.
I do not hand out topology or engineering specifications without this.
And yes, I am quite satisfied with the engineering that all parties involved
have done to this point, and I have verified the portions of that I believe
are important to our success.
--
Karl Denninger
>
> Look at all the numbers, and all the facts. Then decide. Net99 is the
> "no smoke and mirrors; just good service at a reasonable price" company.
>
We peer in multiple locations, including MAE-EAST. The MAE is a 10Mbps
interconnect, and can be a 100Mbps FDDI interconnect (if we see the need for
it). Other interconnects are being sized appropriately for the traffic
carried.
>Where do they go?
Nearly everywhere as far as I can see.
>Do you carry full routing (i.e. do you route optimally in your network)?
Yes.
>These are the important questions, because price with no service
>infrastructure is rather irrelevant.
>
>I've seen some folks trying to selling 20 or 30 T1's to "The Internet" to
>their customer base with only a T1 to the <name withheld>IX as their outbound
>pipe, which isn't particularly useful if you're trying to get internet
>connectivity as opposed to just a VPN service.
That's not happening here. Net99 is an international backbone service, not
a single supplier with one link to someone else.
Peter Berger
legitimate. Thanks, Karl. You may be hearing from me.
(or Joe, rather :-)
Karl Denninger
Peter Berger <pet...@telerama.lm.com> wrote:
>Ok, the offer of information in return for a non-disclosure agreement is
>legitimate. Thanks, Karl. You may be hearing from me.
>
>(or Joe, rather :-)
Its not mine to offer. Its Mr. Stroup's to offer, if he chooses to. I
offered my perspective, which is not corporate policy, since I'm not
in a position to make corporate policy -- I'm in charge of engineering.
If you want a corporate policy from me, you'll have to ask MCSNet, and
not Net99, as I *can* speak for that company (since I own enough of it to
have a voice.)
Please read what I write, not what you choose to parse. I said "from my
perspective....."
Now I know why the larger providers don't bother posting on the net.
Paul Traina
>What is the size of your outbound pipes?
We peer in multiple locations, including MAE-EAST. The MAE is a 10Mbps
interconnect, and can be a 100Mbps FDDI interconnect (if we see the need for
it). Other interconnects are being sized appropriately for the traffic
carried.
MAE-EAST is a 10mb ethernet.
How big is your pipe to MAE-EAST?
MAE-EAST is horribly overloaded precicely because it's only a 10mb ethernet
and some providers out there just default to it.
What about MAE-EAST+?
Also, you didn't say where do your other interconnects go. If MAE-EAST is
your only interconnect point with the other large networks, as a potential
customer, I'd be concerned about the packet drop rate across it.
>Where do they go?
Nearly everywhere as far as I can see.
Are you saying you have direct pipes to nearly every other major service
provider out there? Wow, that is impressive. I didn't realize Net99 was so
well funded. Who exactly do you have other direct pipes with (if the number
is more than 5, just keep to to the 5 biggest peer service provider links).
>Do you carry full routing (i.e. do you route optimally in your network)?
Yes.
Oh, good. I had heard some nasty gossip that said that Net99 was defaulting
to ANS instead of taking down all 20000 routes.
>I've seen some folks trying to selling 20 or 30 T1's to "The Internet" to
>their customer base with only a T1 to the <name withheld>IX as their
>outbound pipe, which isn't particularly useful if you're trying to get
>internet connectivity as opposed to just a VPN service.
That's not happening here. Net99 is an international backbone service, not
a single supplier with one link to someone else.
That's great, I'm glad to hear that you're not like some of the folks that
are commonly regarded as "toaster networks."
I often consult with folks who are looking for multi-national VBN service.
To which other countries do your international backbone connections go?
Best regards,
Paul
--
"Warm and fuzzy feelings are not our department."
bi...@mix.com
> Can anyone say for sure what in the world is going on here?
Tony Li kindly explained to me why it's unfair to blame this solely
on ANS and a bit of how complicated the congestion at MAE-East is.
So, I stand corrected. And, I can see Net99 just fine over the same
ANS route..
Thanks!
Billy Y..
Edward Vielmetti
: In article <1994Oct26.150822.6939@eisner> bi...@mix.com writes:
: Well, at least right now today the NSF Net's (ANS) ENSS-136 is thoroughly
: stuffed, overloaded and just about impossible to use at least for anything
: interactive during office hours. Presumably this will get better soon, as
:
: It would be interesting to see some data on this because it certainly does
: not correspond to my experience.
The problem report I have seen on this refers to congestion on
the MAE EAST segment between PSI and ANS, with packet loss rates
observed up to 20%. If I read Billy's complaint right he's misinterpreting
a traceroute to see loss due to congestion at ENSS-136 where really
the problem is on MAE EAST.
Here's the NEARNET version of the trouble report, with a pointer to
the ANS trouble report. Note the "problem started date", this has
been an unfortunate situation for a long time.
Edward Vielmetti, vice president for research, Msen Inc. e...@Msen.com
Msen Inc., 320 Miller, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563)
[nic.near.net]
Retrieving information on NEARNET Trouble Ticket <10352>. Please wait...
Ticket Number: 10352 Ticket Status: open
Ticket Type: unplanned Ticket Source: noc
Ticket Scope: network Site/Line: network
Ticket Owner: perfetti Problem Fixer:
Telco Number: ans-10660
Ticket Opened: 10/17/94 13:13 Problem Started: 07/28/94 14:56
Problem Description:
There is a problem where connectivity via MAE-EAST is rather
sluggish caused by packet loss and possible congestion on
the pipe from ANS to MAE-EAST. This is resulting in multiple
user connectivity problems involving packet loss of roughly
7% to hosts where routing traverses the MAE-EAST connection.
For more information, please contact the NEARNET Network Operations Center
at nearn...@nic.near.net or (617) 873-8730. Thanks!
phil reed
>
>In article <386mf5$c...@Venus.mcs.com>, Karl Denninger <ka...@MCS.COM> wrote:
>
>> Net99's business is providing connectivity. That's it. If you have
>> specific reachability questions just ask -- we can check from our core to
>> see if a specific location is reachable.
>>
>> We've yet to say "no" to this request, by the way.
>
>was: only if you can run a circuit to NYC. You know the price of a 120+
>mile T1 grade leased line. The astronomical cost makes Net99 connectivity
>sound like a "no" to me. :)
>
> - Matt Zahorik
Did you check the cost of a frame relay link? Might be less expensive.
...phil
Wolfgang Henke
net99.net. 864000 SOA cerebus.mcs.com. karl.mcs.com. (
94102001 ;serial
360000 ;refresh
1800 ;retry
3600000 ;expire
864000 ) ;minim
net99.net. 864000 NS cerebus.mcs.com.
net99.net. 864000 NS genesis.lachman.com.
net99.net. 864000 MX 10 Mercury.mcs.com.
NY-1.net99.net. 864000 A 204.157.0.135
Mae-East.net99.net. 864000 A 192.41.177.170
Mosaic-Show.net99.net. 864000 A 204.157.1.10
Show-Gw.net99.net. 864000 A 204.157.0.200
Houston-1.net99.net. 864000 A 204.157.0.136
MAE-1.net99.net. 864000 A 204.157.0.133
LA-1.net99.net. 864000 A 204.157.0.129
Chicago-1.net99.net. 864000 A 204.157.0.131
Philly-1.net99.net. 864000 A 204.157.0.134
Boston-1.net99.net. 864000 A 204.157.0.132
SanJose-1.net99.net. 864000 A 204.157.0.130
CAIS.net99.net. 864000 A 204.157.1.2
; Matching SOA found
;; FROM: APlatform to SERVER: cerebus.mcs.com. 192.160.127.125
;; WHEN: Wed Oct 26 11:29:52 1994
--
Wolfgang Henke <wolf...@whnet.com> ... http://www.whnet.com/wolfgang/
WH Networks ............................. ftp.whnet.com /pub/wolfgang
2672 Bayshore Parkway Suite 503 ....................... (415) 390-9316
Mountain View CA 94043 ............................ fax (415) 390-9317
bi...@mix.com
> I can see Net99 just fine over the same ANS route..
Well, perhaps I spoke a bit too soon regarding reaching Net99 ok,
today it's not doing so well -
$ tra LA-1.net99.net
traceroute to LA-1.NET99.NET (204.157.0.129), 30 hops max, 38 byte packets
1 DECUS-gw (192.67.173.10) 0 ms 10 ms 0 ms
2 wpi-gw.near.net (131.192.81.1) 10 ms 10 ms 10 ms
3 prospect-gw.near.net (131.192.60.1) 30 ms 40 ms 10 ms
4 mit2-gw.near.net (131.192.7.1) 20 ms 20 ms 10 ms
5 enss.near.net (192.233.33.6) 20 ms 10 ms 10 ms
6 t3-3.cnss48.Hartford.t3.ans.net (140.222.48.4) 20 ms 20 ms 20 ms
7 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 20 ms 20 ms 10 ms
8 t3-1.cnss56.Washington-DC.t3.ans.net (140.222.56.2) 30 ms 30 ms 30 ms
9 mf-0.cnss58.Washington-DC.t3.ans.net (140.222.56.194) 30 ms 30 ms 40 ms
10 * t3-0.enss136.t3.ans.net (140.222.136.1) 20 ms *
11 Net99-Mae-East01.net99.net (192.41.177.170) 100 ms 60 ms 70 ms
12 204.157.0.129 (204.157.0.129) 140 ms * *
$ ping LA-1.net99.net
PING LA-1.NET99.NET (204.157.0.129): 56 data bytes
----LA-1.NET99.NET PING Statistics----
202 packets transmitted, 161 packets received, 20% packet loss
round-trip (ms) min/avg/max = 120/148/260
Billy Y..
bi...@mix.com
<e...@garnet.msen.com> writes:
> Here's the NEARNET version of the trouble report, with a pointer to
> the ANS trouble report. Note the "problem started date", this has
> been an unfortunate situation for a long time.
It's actually been even longer (about 4 months longer) than that..
NEAR Net opened trouble ticket 10352 keep track of this in one place
instead of multiple tickets until their new routing scheme is in and
working. Those interested in the details of all this may find some
useful pointers in #9940 (finger ticke...@near.net) as well.
Billy Y..
Paul A Vixie
the San Francisco Bay Area and those of us who don't read alt.flames.internet
really don't want to see this discussion.
Sean Doran
>Well, perhaps I spoke a bit too soon regarding reaching Net99 ok,
>today it's not doing so well -
The problem at MAE-EAST is known and is being worked on by MFS, who
supply MAE-EAST level-2 connectivity. Based on conversations I've had
with them in person (at NANOG) and in email, I'm pretty confident the
problem will go away at some point. (There are also some hacks that
Cisco has kindly provided that help out both with their router
products and with the Catalyst at the centre of MAE-EAST; this was
very nice of them, especially since the Cisco products are
emphatically not at fault, and the hacks are to cope with another
broken piece of hardware.).
Moreover, with the big traffic generators at or planning to be at
MAE-EAST+ (a FDDI ring talking to colocated routers in MFS colocate
space), traffic on the MAE-EAST ethernet will hopefully drop in time
too.
The issues were discussed among the MAE-EAST members at length not
long ago, and mostly involve hardware and implementation differences in
how much inter-frame gap is needed or generated on the wire. Right
now, bursty traffic results in lots of lost frames. :(
The problem "floats", that is, it can be seen between two providers on
one day and then two different providers on another, or between one of
those providers and another, while the original pair talk just fine.
This is probably why you have different results with Net99 on
different days.
Sean.
- --
Sean Doran <s...@sprint.net> SprintLink/ICM Engineering +1 800 669 8303
Scott Jennings
: In article <1994Oct27.042344.6960@eisner> I wrote:
: > I can see Net99 just fine over the same ANS route..
: Well, perhaps I spoke a bit too soon regarding reaching Net99 ok,
: today it's not doing so well -
: $ tra LA-1.net99.net
Also, there is *no* DNS service for 129.0.157.204.in-addr.arpa !!
(reverse dns for LA-1.NET99.NET)
Hmm...
Wolfgang Henke
: Further it appears that that connection is on the east coast, which from here
: means a 180+ ms added delay. My name server shows net99 as quite available,
Steven,
here is a traceroute to DC (the NET99 connection point) from Netcom
via both T3s available:
traceroute to mae-1.net99.net (204.157.0.133), 30 hops max, 40 byte packets
1 netcomgw.netcom.com (192.100.81.254) 8 ms 2 ms 3 ms
2 199.182.126.1 (199.182.126.1) 8 ms 3 ms 3 ms
3 t0-15.cnss12.San-Francisco.t3.ans.net (192.103.60.69) 15 ms 8 ms 11 ms
4 en-0.cnss11.San-Francisco.t3.ans.net (192.103.60.5) 19 ms 9 ms 7 ms
5 mf-0.cnss8.San-Francisco.t3.ans.net (140.222.8.222) 13 ms 14 ms 7 ms
6 t3-3.cnss25.Chicago.t3.ans.net (140.222.25.4) 57 ms 77 ms 59 ms
7 t3-0.cnss40.Cleveland.t3.ans.net (140.222.40.1) 63 ms 89 ms 141 ms
8 t3-1.cnss48.Hartford.t3.ans.net (140.222.48.2) 83 ms 90 ms 76 ms
9 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 94 ms 85 ms 87 ms
10 * t3-1.cnss56.Washington-DC.t3.ans.net (140.222.56.2) 100 ms 113 ms
11 mf-0.cnss58.Washington-DC.t3.ans.net (140.222.56.194) 85 ms 97 ms 91 ms
12 t3-0.enss136.t3.ans.net (140.222.136.1) 96 ms 96 ms 90 ms
13 192.41.177.170 (192.41.177.170) 132 ms * 99 ms
traceroute to netcom-dc1.netcom.com (163.179.13.2), 30 hops max, 40 byte packets
1 * netcomgw.netcom.com (192.100.81.254) 5 ms 5 ms
2 t3-1.scl-gw1.netcom.net (163.179.101.2) 2 ms 3 ms 2 ms
3 t3-1.chi-gw1-2.netcom.net (163.179.102.1) 47 ms 47 ms 47 ms
4 t3-1.dc-gw1-2.netcom.net (163.179.103.1) 61 ms 61 ms 60 ms
5 dc-gw1-1.netcom.net (163.179.13.1) 70 ms 72 ms 129 ms
6 NETCOM-dc1-1.netcom.net (163.179.13.2) 71 ms 71 ms 73 ms
So from Netcom you presently have a 99 msec latency into NET99 but
it could be reduced to 73 msec if NET99 connects directly to
Netcom in DC or to 47 msec if NET99 connects to Netcom in Chicago.
Cheers,
Wolfgang
Bruce Sterling Woodcock
>Steven,
>
>here is a traceroute to DC (the NET99 connection point) from Netcom
>via both T3s available:
Keep in mind, people, that this is another reason why non-Netcom staff
shouldn't try to interpret traceroutes:
>traceroute to mae-1.net99.net (204.157.0.133), 30 hops max, 40 byte packets
> 1 netcomgw.netcom.com (192.100.81.254) 8 ms 2 ms 3 ms
> 2 199.182.126.1 (199.182.126.1) 8 ms 3 ms 3 ms
This is actually a T1 link. ANS has the T3.
> 3 t0-15.cnss12.San-Francisco.t3.ans.net (192.103.60.69) 15 ms 8 ms 11 ms
> 4 en-0.cnss11.San-Francisco.t3.ans.net (192.103.60.5) 19 ms 9 ms 7 ms
> 5 mf-0.cnss8.San-Francisco.t3.ans.net (140.222.8.222) 13 ms 14 ms 7 ms
> 6 t3-3.cnss25.Chicago.t3.ans.net (140.222.25.4) 57 ms 77 ms 59 ms
> 7 t3-0.cnss40.Cleveland.t3.ans.net (140.222.40.1) 63 ms 89 ms 141 ms
> 8 t3-1.cnss48.Hartford.t3.ans.net (140.222.48.2) 83 ms 90 ms 76 ms
> 9 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 94 ms 85 ms 87 ms
>10 * t3-1.cnss56.Washington-DC.t3.ans.net (140.222.56.2) 100 ms 113 ms
>11 mf-0.cnss58.Washington-DC.t3.ans.net (140.222.56.194) 85 ms 97 ms 91 ms
>12 t3-0.enss136.t3.ans.net (140.222.136.1) 96 ms 96 ms 90 ms
>13 192.41.177.170 (192.41.177.170) 132 ms * 99 ms
>
>traceroute to netcom-dc1.netcom.com (163.179.13.2), 30 hops max, 40 byte packets
> 1 * netcomgw.netcom.com (192.100.81.254) 5 ms 5 ms
> 2 t3-1.scl-gw1.netcom.net (163.179.101.2) 2 ms 3 ms 2 ms
> 3 t3-1.chi-gw1-2.netcom.net (163.179.102.1) 47 ms 47 ms 47 ms
> 4 t3-1.dc-gw1-2.netcom.net (163.179.103.1) 61 ms 61 ms 60 ms
> 5 dc-gw1-1.netcom.net (163.179.13.1) 70 ms 72 ms 129 ms
> 6 NETCOM-dc1-1.netcom.net (163.179.13.2) 71 ms 71 ms 73 ms
Actually, netcom-dc1 is in Vienna, VA. What you want dc-gw1-2:
traceroute to dc-gw1-2.netcom.com (163.179.29.1), 61 hops max, 40 byte packets
1 netcomgw.netcom.com (192.100.81.254) 15 ms 3 ms 3 ms
2 t3-1.scl-gw1.netcom.net (163.179.101.2) 2 ms 4 ms 2 ms
3 t3-1.chi-gw1-2.netcom.net (163.179.102.1) 46 ms 47 ms 47 ms
4 t3-1.dc-gw1-2.netcom.net (163.179.103.1) 62 ms * 64 ms
>So from Netcom you presently have a 99 msec latency into NET99 but
>it could be reduced to 73 msec if NET99 connects directly to
>Netcom in DC or to 47 msec if NET99 connects to Netcom in Chicago.
Net99 does connect in DC via MAE-East just like Netcom, from what I
understand. However, routing is a much more complicated issue; there
are reasons why routing is going via ANS and not MAE-East, although
Karl would need to talk to Netcom's network operations (n...@netcom.com)
to determine exactly why.
Wolfgang Henke
should be. I guess the main factor is the speed of light, at
about 200 miles per millisecond. For a 2000 mile one-way and
4000 mile roundtrip it's 20 msec, divided by 0.7 the dielectric
for fiber or copper it comes out to about 30 msec. So why do we
see 46 milliseconds? It seems too slow.
(new)PING t3-1.chi-gw1-2.netcom.net (163.179.102.1): 56 data bytes
64 bytes from 163.179.102.1: icmp_seq=0. time=48. ms
64 bytes from 163.179.102.1: icmp_seq=1. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=2. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=3. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=4. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=5. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=6. time=46. ms
----t3-1.chi-gw1-2.netcom.net PING Statistics----
8 packets transmitted, 7 packets received, 12% packet loss
round-trip (ms) min/avg/max = 46/46/48
Bruce Sterling Woodcock
>should be. I guess the main factor is the speed of light, at
>about 200 miles per millisecond. For a 2000 mile one-way and
>4000 mile roundtrip it's 20 msec, divided by 0.7 the dielectric
>for fiber or copper it comes out to about 30 msec. So why do we
>see 46 milliseconds? It seems too slow.
>
>(new)PING t3-1.chi-gw1-2.netcom.net (163.179.102.1): 56 data bytes
>64 bytes from 163.179.102.1: icmp_seq=0. time=48. ms
>64 bytes from 163.179.102.1: icmp_seq=1. time=46. ms
>64 bytes from 163.179.102.1: icmp_seq=2. time=46. ms
>64 bytes from 163.179.102.1: icmp_seq=3. time=46. ms
>64 bytes from 163.179.102.1: icmp_seq=4. time=46. ms
>64 bytes from 163.179.102.1: icmp_seq=5. time=46. ms
>64 bytes from 163.179.102.1: icmp_seq=6. time=46. ms
>
>----t3-1.chi-gw1-2.netcom.net PING Statistics----
>8 packets transmitted, 7 packets received, 12% packet loss
>round-trip (ms) min/avg/max = 46/46/48
Well, the truth is that Netcom's network administrators suck, and they
are just out to try and screw you over by providing as slow a response
time as possible to the Internet.
No, really, it's because your back of the envelope calculations are just
that. You don't include a lot of other factors, latency, etc. in your
figures. First, you have to subtract the few milliseconds it takes to
get through the local network out and to be processed at each router.
Then factor in at least 10% error on your figures, and allow for the
fact that technology is finite and still doesn't quite run at the speed
of light yet (although it's close), and you find that anything in the
40ms range is very reasonable.
The link between t3-1.cnss8.San-Francisco.t3.ans.net and
t3-3.cnss25.Chicago.t3.ans.net, which is roughly the same distance,
also appears to to have a 40-50ms round-trip time. I had to do
some gateway tracerouting trhough the SF gateway to calculate this,
because a direct ping goes out over Netcom's internal network first.
So if someone else could provide direct ping times over a T3 between
the bay area and Chicago it would be helpful, as I can't get an
exact measurement over ANS's T3.
Wolfgang Henke
: figures. First, you have to subtract the few milliseconds it takes to
: get through the local network out and to be processed at each router.
: Then factor in at least 10% error on your figures, and allow for the
: fact that technology is finite and still doesn't quite run at the speed
: of light yet (although it's close), and you find that anything in the
: 40ms range is very reasonable.
Bruce,
it appears that it takes just 1 msec to get through the local network.
This leaves us with 45 msec latency on the T3 to Chicago. I suspect
the long distance carrier may not use the shortest distance to
Chicago (going through the operations center in Oklahoma maybe). I
also suspect that the optical repeaters introduce some latency.
It looks like a good question for a telco engineer.
Cheers,
Wolfgang
traceroute to t3-1.chi-gw1-2.netcom.net (163.179.102.1), 30 hops max,
40 byte packets
1 netcomgw.netcom.com (192.100.81.254) 3 ms 3 ms 6 ms
2 t3-1.scl-gw1.netcom.net (163.179.101.2) 3 ms 2 ms 2 ms
3 t3-1.chi-gw1-2.netcom.net (163.179.102.1) 47 ms * *
PING t3-1.scl-gw1.netcom.net (163.179.101.2): 56 data bytes
64 bytes from 163.179.101.2: icmp_seq=0. time=2. ms
64 bytes from 163.179.101.2: icmp_seq=1. time=2. ms
64 bytes from 163.179.101.2: icmp_seq=2. time=1. ms
64 bytes from 163.179.101.2: icmp_seq=3. time=1. ms
64 bytes from 163.179.101.2: icmp_seq=4. time=1. ms
64 bytes from 163.179.101.2: icmp_seq=5. time=2. ms
64 bytes from 163.179.101.2: icmp_seq=6. time=1. ms
----t3-1.scl-gw1.netcom.net PING Statistics----
7 packets transmitted, 7 packets received, 0% packet loss
round-trip (ms) min/avg/max = 1/1/2
PING t3-1.chi-gw1-2.netcom.net (163.179.102.1): 56 data bytes
64 bytes from 163.179.102.1: icmp_seq=0. time=49. ms
64 bytes from 163.179.102.1: icmp_seq=1. time=58. ms
64 bytes from 163.179.102.1: icmp_seq=2. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=3. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=4. time=47. ms
64 bytes from 163.179.102.1: icmp_seq=5. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=6. time=46. ms
64 bytes from 163.179.102.1: icmp_seq=7. time=46. ms
----t3-1.chi-gw1-2.netcom.net PING Statistics----
8 packets transmitted, 8 packets received, 0% packet loss
round-trip (ms) min/avg/max = 46/48/58
Bruce Sterling Woodcock
>: get through the local network out and to be processed at each router.
>: Then factor in at least 10% error on your figures, and allow for the
>: fact that technology is finite and still doesn't quite run at the speed
>: of light yet (although it's close), and you find that anything in the
>: 40ms range is very reasonable.
>
>Bruce,
>
>it appears that it takes just 1 msec to get through the local network.
Actually. it varies. I was also adding scl as the "local" network,
since that's a stopover on the way to the true T3 from there to Chicago.
And it's specifically the speed of that link of which we are speaking.
So you need to subtract 2-6 ms.
I was also using that to illustrate just one point of many that you
don't figure into your calculations because they seem negligible...
"optical repeaters" are another one which you bring up. A half-dozen
such instances, taking 1ms or 2ms each, and it starts to add up.
I think you are also on target with the "carrier may not use the
shortest distance" idea... that was another point I was trying to
make, in basically denouncing your "2000 miles" figure as too rough.
In short, 40-50ms is about right according to reality, regardless of
what one thinks they can achieve in a theoretical ideal world on paper.
Once you have a direct LOS laser beam from San Jose to Chicago, then
maybe you can approach 30ms over it. :)
Tony Li
Sterling Woodcock) writes:
In short, 40-50ms is about right according to reality, regardless of
what one thinks they can achieve in a theoretical ideal world on paper.
Once you have a direct LOS laser beam from San Jose to Chicago, then
maybe you can approach 30ms over it. :)
And my FTP might finish a whole 30ms sooner, too!!!! ;-)
Tony
Wolfgang Henke
: maybe you can approach 30ms over it. :)
:
: And my FTP might finish a whole 30ms sooner, too!!!! ;-)
Well, the only way to get faster than 30 ms to Chicago is to not use
copper or fiber but air for example. This reduces the theoretical
limit to about 20 ms. I'll leave the implementation details to the
creativity of the reader. It could for example be a low flying
laser mirror/switch over Colorado :-).
Cheers,
Wolfgang
Laser communication not star wars.
Joseph Malcolm,,,
Bruce Sterling Woodcock <ster...@netcom.com> wrote:
>I was also using that to illustrate just one point of many that you
>don't figure into your calculations because they seem negligible...
>"optical repeaters" are another one which you bring up. A half-dozen
>such instances, taking 1ms or 2ms each, and it starts to add up.
Well, one millisecond worth of delay is about 46,000 bit-times at
T3 speed, necessitating that much buffering. This seems like quite
a bit of buffering to me for an "optical repeater".
>I think you are also on target with the "carrier may not use the
>shortest distance" idea... that was another point I was trying to
>make, in basically denouncing your "2000 miles" figure as too rough.
I find this much more likely as an explanation.
Martin L. Schoffstall
> There was also a lot of discussion about how TCP performance over ATM
> was pretty abyssmal, apparently due to problems in the congestion
> control algorhythms of most TCP implementations. That spells trouble
> for anyone using ATM, at least under congested circumstances.
>
> >I believe you were not present at this meeting.
>
> I missed you, too, Marty...did you listen over Mbone, or just after
> lunch?
>
We had two of our people there as well, specifically Mark Fedor (who i'm
sure you know) and Cole Libby our Manage of Customer Support.
We can do network engineering and attend NANOG at the same time.....
On the material front, the tone/substance of the meeting was that the testing
was pretty bad so that a lot of the conclusions that were arrived at it are
pretty questionable.
lots of GIGO
Marty
Martin L. Schoffstall
on Internet issues.
bravo,
Marty
In article <38qej8$m...@news.sprintlink.net>, s...@sprint.net (Sean Doran)
writes:
> From: s...@sprint.net (Sean Doran) Newsgroups:
> alt.internet.access.wanted,alt.internet.services,ba.internet Subject:
> Re: NET99 Allows Resellers !!!
> Date: 28 Oct 1994 09:00:24 GMT
> Organization: SprintLink/ICM Engineering
Martin L. Schoffstall
SURANET and UUNET/Alternet. UUNET/Alternet traffic has been moved to the
SWAB, and new hardware at SURA seems to have fixed the SURANET traffic. Merit
just announced that the NSFNet connection will be moved to MAE-EAST+ (an FDDI)
which may help the situation.
What most of us had believed was that most of the NSFNet traffic was moving to
MCI and Sprint. PSI has worked hard to re-engineer its interconnection to
SPRINT for this brave new post-NSFNet world.
Marty
In article <38od7v$43$1...@heifetz.msen.com>, e...@garnet.msen.com (Edward
Vielmetti) writes:
> From: e...@garnet.msen.com (Edward Vielmetti)
> Newsgroups: alt.internet.access.wanted,alt.internet.services,
> ba.internet Subject: Re: NET99 Allows Resellers !!!
> Date: 27 Oct 1994 14:25:03 GMT
> Organization: Msen, Inc. -- Ann Arbor, MI (account
> info: +1 313 998-4562)
>
> Tony Li (t...@cisco.com) wrote:
> : In article <1994Oct26.150822.6939@eisner> bi...@mix.com writes:
>
> : Well, at least right now today the NSF Net's (ANS) ENSS-136
> is thoroughly : stuffed, overloaded and just about impossible to
> use at least for anything : interactive during office
> hours. Presumably this will get better soon, as :
> : It would be interesting to see some data on this because it
> certainly does : not correspond to my experience.
>
> The problem report I have seen on this refers to congestion on the
> MAE EAST segment between PSI and ANS, with packet loss rates observed
> up to 20%. If I read Billy's complaint right he's misinterpreting
> a traceroute to see loss due to congestion at ENSS-136 where really
> the problem is on MAE EAST.
>
> Here's the NEARNET version of the trouble report, with a pointer to
> the ANS trouble report. Note the "problem started date", this has been
> an unfortunate situation for a long time.
>
> Edward Vielmetti, vice president for research, Msen Inc. emv@
> Msen.com Msen Inc., 320 Miller, Ann Arbor MI 48103 +1 313 998 4562
Emperor Jose
well, my question has nothing to do with T3 but it does have to
do with speed...
can anyone answer whether running an internet equipped network
over 2Mbps-10Mbps microwave transmission would be plausible??
thanks for the input!
jyce
ken emery
Emperor Jose <st...@elroy.uh.edu> wrote:
>well, my question has nothing to do with T3 but it does have to
>do with speed...
>can anyone answer whether running an internet equipped network
>over 2Mbps-10Mbps microwave transmission would be plausible??
Sure, both HP and DEC get their internet connections from
Barrnet over 10Mbps microwave links. Also Barrnet uses microwave
for an OC3 speed connection (155Mbps) to MCI (3 DS3's).
It should be doable, the question is how much are you willing to
pay and do you have a clear path between the two sites.
bye,
ken emery
Joseph W. Stroup
: >>
: >3. Does Net99 connect to CIX? If not, why not?
We have NO connection to the CIX at this time. I see no point, at this time.
If in the near term that connection is important, we will make a decision to
inter-connect. NET99 is a company of 9 people. We have said all along that
NET99 is NOT for everyone. We are NOT SPRINT, we are NOT NETCOM. We are an
NSP and will continue to grow. I don't have the time I used to , to get
on the news groups and chat. Karl is very busy working & I don't know how
he finds the time. We have rich connectivity - we are happy. Thats not at all
bad for a new backbone company. We would be happy to trade you phone bills,
eh Karl ?
NET99 - Stroup Over n Out....
: I do engineering for Net99. If you want to talk to the business decision
: maker, talk to Mr. Stroup. You're asking what is, essentially, a political
: question and that isn't my department.
: Back to work.
: --
: --
: Karl Denninger (ka...@Net99.Net) | Net99 - Connectivity at a reasonable price
: VP Network Engineering | Mr. Packet Says "Don't delay, reroute today"
--
Joseph Stroup
bi...@mix.com
<sch...@us.psi.com> writes:
> PSI's experienced MAE-EAST problems with a number of other ISP's including
> SURANET and UUNET/Alternet. UUNET/Alternet traffic has been moved to the
> SWAB, and new hardware at SURA seems to have fixed the SURANET traffic. Merit
> just announced that the NSFNet connection will be moved to MAE-EAST+ (an FDDI)
> which may help the situation.
>
> What most of us had believed was that most of the NSFNet traffic was moving to
> MCI and Sprint. PSI has worked hard to re-engineer its interconnection to
> SPRINT for this brave new post-NSFNet world.
Does this mean the the only hope left for reaching NEAR Net from PSI
without any connectivity problems is MAE-East+? When exactly will this
become operational? And - are MCI and Sprint, who were going to carry
all this traffic, now not going to do that..??
Interestingly, though I've read NEAR Net was one of the few vendors
actually on schedule for the Nov. 1st date to switch (presumably to MCI)
that's now today and they are still on ANS.. and of course I still can't
use PSI to reach them during office hours either.
Billy Y..
Mike Stump
Martin L. Schoffstall <sch...@us.psi.com> wrote:
>PSI's experienced MAE-EAST problems with a number of other ISP's including
>SURANET and UUNET/Alternet.
This is an understatement. 15-40% packet loss has a very unique way
to kill interactive response. I was forced to leave PSI, because they
couldn't solve the problem in a timely fashion. Yes, I feel I gave
them plenty of time (2-4 months?) to fix it.
>What most of us had believed was that most of the NSFNet traffic was
>moving to MCI and Sprint. PSI has worked hard to re-engineer its
>interconnection to SPRINT for this brave new post-NSFNet world.
I just glanced now, and found an 8% loss still present at the
interconnect between Sprint and PSI. The exact sites involved for
those that want to confirm, or check this were:
7 sl-dc-6-H1/0-T3.sprintlink.net (144.228.10.1) 956 ms 474 ms 388 ms
8 psi-nsf-2.psi.net (192.41.177.235) 506 ms 414 ms *
So, did you think that you have solved the problem, or do you just
think that one day you maybe able to solve the problem? Personally, I
don't think a 10% loss over a single link is acceptable. I found
another provider that could move my packets to my destination with a
0-3% loss, total, over 11 hops. There were many things that I liked
about PSI's IP service. And for a long time (I have been a PSI IP
customer for almost 3 years), they moved my packets well. But, they
seemed to not be able to handle the explosive growth very well. I am
sure many other providers are also experiencing growing pains, the
trick is to find one that causes you the least ammount of pain. For
me, that meant finding a provider that has a good Sprintlink
connection. PSI just wasn't it.
bi...@mix.com
writes:
> can anyone answer whether running an internet equipped network
> over 2Mbps-10Mbps microwave transmission would be plausible??
Yes, it works fine, but - if you are where it rains a lot, be
sure to investigate the potential for rain fading. At higher
microwave frequencies this can be a problem, depending on the
length of the path, transmitter power, etc..
Billy Y..
Wolfgang Henke
>make, in basically denouncing your "2000 miles" figure as too rough.
By the way, there is a map available. Just click on "Favorite Places"
on our home page and then "John Kluge's Wiltel". Then look at the
info about WilView/X, the Xserver based network management system.
One can zoom to street level resolution.
In case similar info is available for Sprintlink, MCINet and ATT
I would appreciate an email.
Cheers,
Wolfgang
Bruce Sterling Woodcock
>
>>make, in basically denouncing your "2000 miles" figure as too rough.
>
>By the way, there is a map available. Just click on "Favorite Places"
>on our home page and then "John Kluge's Wiltel". Then look at the
>info about WilView/X, the Xserver based network management system.
>One can zoom to street level resolution.
Yeah, it's a pretty neat package, although I haven't used it that much.
In any case, you're assuming the T3 is WilTel's.
Bruce
--
Bruce Sterling Woodcock --- Systems Analyst / Admin --- ster...@netcom.com
The views and opinions expressed in this post | Power is being able
are not necessarily those of my employer, | to sneak into your
NETCOM On-line Communication Services. | house over a wire.
bi...@mix.com
<m...@cygnus.com> writes:
> I just glanced now, and found an 8% loss still present at the
> interconnect between Sprint and PSI. The exact sites involved for
> those that want to confirm, or check this were:
>
> 7 sl-dc-6-H1/0-T3.sprintlink.net (144.228.10.1) 956 ms 474 ms 388 ms
> 8 psi-nsf-2.psi.net (192.41.177.235) 506 ms 414 ms *
>
> So, did you think that you have solved the problem, or do you just
> think that one day you maybe able to solve the problem? Personally, I
> don't think a 10% loss over a single link is acceptable. I found
> another provider that could move my packets to my destination with a
> 0-3% loss, total, over 11 hops. There were many things that I liked
> about PSI's IP service. And for a long time (I have been a PSI IP
> customer for almost 3 years), they moved my packets well. But, [...]
Well, I'm more concerned with getting to ANS, but yes - this is exactly
the same for me (other than I've been with PSI more than 3 years) too.
The above began October 6th - I'd expected connectivity to Sprint to
get better, but I had to move from a Sprint system in North Carolina
(I was using to route around MAE-East) to one in Phoenix (much closer
to me in Los Angeles) to do the same thing (taking PSI out of the path
entirely).
So, while I'd much rather the problems at MAE-East get fixed first
(they've existed six months longer..) I too am curious what happened
to the Sprint-PSI connection - it used to be better than this..?
Billy Y..
Wolfgang Henke
Wiltel tarif tables give a total distance of 1840 V&H miles between
Santa Clara and Chicago. V&H stands for "vertical and horizontal"
and is more or less the air mileage but not the length of the true
fiberoptic path.
The length of the fiber is 2708 miles between those two POPs, which
yields with light speed in fiber a 38.7 ms latency. Add the routers
at each end with 2 ms each and it's 43 ms, very close to the observed
value of 46 ms. Wiltel's Susan Rogers also stated that the latency of
their internal repeaters/routers is expected to be very small. Thank
you all for helping to figure this one out!
: In any case, you're assuming the T3 is WilTel's.
Let's just say that I've been a quiet admirer of John Kluge's Wiltel
for quite some time. Fiber optics in oil pipelines, that's creative. :-)