Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Frank Coluccio Technology Forum - ASAP -- Ignore unavailable to you. Want to Upgrade?

To: pfierb who wrote (542)	11/30/1999 11:09:00 AM
From: Frank A. Coluccio	Read Replies (1) \| Respond to of 1782

re: slow response pfierb, Thread, I would normally attempt to reply to all PMs, emails and posts but this morning I'm pressed by other obs, and some sites are really trying on the nerves this a.m. (such as this one at this time, which I am now finding painfully slow to negotiate) so I'll keep this short and return to unfinished business later in the day, hopefully. Just a few observations about response times. We tend to knee jerk anytime we see what we regard as obvious symptoms, as I am guilty of doing here, and as others have done both here and on the GBLX thread. But the 'net sometimes (often?) works in some not-so-obvious ways behind the curtains. I suspect that that is a gross understatement, in fact. The way in which service providers reads packet prefixes, for example, and forward them to the next node, may lead to some not-so-intuitive results for unsuspecting users who are left to their mercy. I'm not saying that this applies here necessarily, rather, I'm only offering it for its tutorial value. In fact, the problems here migh in fact be obvious ones. But one never really knows without somtimes performing some extended poking around the 'soft' areas. Here's a dialog I picked up on the NANOG list this morning which highlights this point. This does not have anything to do with the situation we're discussing here, to the best of my knowledge, but again, I offer it simply for its illustrative value. Later. Regards, Frank Coluccio -----snip from NANOG begins: Can someone indicate me some UUNet Looking Glass so I can check routes from Teleglobe ? I found only traceroute unfortunately. On Tue, 30 Nov 1999, Neil J. McRae wrote: > > Teleglobe's service is a complete joke. I've bought speakers > from a man in a white van and got better service. > I've just opened a ticket recently regarding UUNET issues also. > For some reason Teleglobe was routeing one of our prefixes via > their UUNET interconnect at LA and the other via Seattle, The LA > route was really bad whilst the Seattle was bearable, I emailed > trouble@teleglobe.net it takes 2 hours for them to respond to only > say: > > -------- > > THE FOLLOWING IS THE ANNOUNCEMENTS WE DO FOR BOTH YOUR NETWORKS IN NEW-YORK. > > ------- > > Do you notice something wrong with that picture? The actual information > that followed was a sh ip bgp of our routes on the access router that > we connect too. Useful? hoho not I think. > They then went on to blame UUNET. We re-routed the traffic via > one of our other transit providers and some miracle must have > happened on UUNET's network because the problem went away. > My view is that Teleglobe have severe congestion issues > with UUNET at the moment it seems to be a regular occurance with them. > Whats more annoying is that they never admit these problem unless > you make a huge noise about it, a regular occurance seems to be > report a fault and get a reponse that indicates that they already know > about the problem? IF SO WHY NOT TELL US? > > Regards, <delete> > > Hello! > > > > Macomnet (ISP, AS8470, Moscow, Russia) uses world connectivity via > > Teleglobe. We have a router, managed by us, in NY. The interface pointing > > to America uses Teleglobe's address and another one, pointing to Moscow > > - ours. > > > > Regullary I see a quite strange heavy delays on Teleglobe to > > Alternet interconnect point. I traced the route to several > > destinations with SRC addresses from Teleglobe's and Macomnet's IP blocks. > > The problem is that packets with SRC from Teleglobe address space passes > > through with lower delays than packets with Macomnet's SRC addresses. > <delete> ----------------snip ends