Re: PAIX Outages
On Thu, 28 April 2005 18:57:53 -0400, Richard A Steenbergen wrote: At the moment, the US IX's largely price their ports as high as the market will possibly bear (and then sometimes a few bucks more just as a kick in the teeth) Yeah, what's the issue? US public peering ports are absurdly overpriced. Anyone had a laugh at the PAIX list prices when seeing them first? Considering LINX and AMSIX are their own companies for some years now they are doing an excellent job at being (too?) affordable, but it surely works. Then when I think about the NYIIX woes some time ago and other stuff (like the current PAIX trouble) I cannot help but get rid of public peering, especially in the US. As another matter I do not believe in public peering at all when you have flows to a single peer that are ore than half of a full GE. Been there, was not at all nice. I guess more and more operators will have less and less public IX ports, and the open peering coalition will start wondering at some point... The AMSIX has a lot of 10G peers. While they just take two ports, and the AMSIX supposedly also being redundant (and cheap g) it is just a time- bomb. How many times did either LINX or AMSIX had issues (actually very rare!) and we happily overloaded our peers' interfaces at the respective other IX... Say what you want, but public peering (yes/no) has a lot to do with your amount of traffic, and your peers. Paying 3 to 4 times as much in the US for the very same I am sure I get even less value - and I'm pulling out. (Well, since we stumbled about this topic... thanks, ras!) Alexander
RE: PAIX Outages
From: Alexander Koch [mailto:[EMAIL PROTECTED] [..] As another matter I do not believe in public peering at all when you have flows to a single peer that are ore than half of a full GE. Been there, was not at all nice. I guess more and more operators will have less and less public IX ports, and the open peering coalition will start wondering at some point... The AMSIX has a lot of 10G peers. While they just take two ports, and the AMSIX supposedly also being redundant (and cheap g) it is just a time- bomb. How many times did either LINX or AMSIX had issues (actually very rare!) and we happily overloaded our peers' interfaces at the respective other IX... Say what you want, but public peering (yes/no) has a lot to do with your amount of traffic, and your peers. It depends. Thinking of reliability: FICIX over here in Finland requires all full members to join _two_ switches in physically separate locations from separate points in your own network, using redundant fiber paths. Result: a very reliable IX. In Sweden Netnod has IX facilities in five cities around the country. AFAIK most of the traffic exchange is done over public peerings in Finland and Sweden - very reliably. --Kauto
RE: PAIX Outages
and we happily overloaded our peers' interfaces at the respective other IX... That sounds more like a planning issue than anything else. If you have traffic going through a pipe, then you need to make sure you have somewhere else to send it. If you are managing your peers properly, private or public, there should be no issue.
Re: PAIX Outages
With public peering you simply never know how much spare capacity your peer has free. So? That doesn't make public peering bad, you don't know that for PI or transit either And would you expect your peer with 400 Mbit/s total to have 400 reserved on his AMSIX port for you when you see 300 at LINX and LINX goes down? Yes and more fool you if they have and you haven't Of course commercially that may be something you gamble with for profit margin brandon
Re: PAIX Outages
On Fri, 29 April 2005 13:24:06 +0100, Brandon Butterworth wrote: With public peering you simply never know how much spare capacity your peer has free. So? That doesn't make public peering bad, you don't know that for PI or transit either For PI I know how much spare I have towards them, taking for granted they can move the traffic. Which is the case in 99% for all our peers currently that we have privates with. And they can better move the traffic... and if not one tells the other normally and things can be done. And would you expect your peer with 400 Mbit/s total to have 400 reserved on his AMSIX port for you when you see 300 at LINX and LINX goes down? Yes and more fool you if they have and you haven't This was not about 'my' or 'our' side, believe me... Alexander
Re: PAIX Outages
On Fri, Apr 29, 2005 at 02:08:13PM +0200, Alexander Koch wrote: With public peering you simply never know how much spare capacity your peer has free. You also never know with private peering: Backbone links. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: PAIX Outages
With public peering you simply never know how much spare capacity your peer has free. So? That doesn't make public peering bad, you don't know that for PI or transit either For PI I know how much spare I have towards them, taking for granted they can move the traffic. That's still no different than public, the two may terminate in the same router/back haul. If you assume for one you may as well assume for both Yes and more fool you if they have and you haven't This was not about 'my' or 'our' side, believe me... The royal you, not personally brandon
Re: PAIX Outages
On Fri, 29 Apr 2005, Alexander Koch wrote: On Fri, 29 April 2005 13:04:05 +0100, Neil J. McRae wrote: and we happily overloaded our peers' interfaces at the respective other IX... That sounds more like a planning issue than anything else. If you have traffic going through a pipe, then you need to make sure you have somewhere else to send it. If you are managing your peers properly, private or public, there should be no issue. With public peering you simply never know how much spare capacity your peer has free. And would you expect your peer with 400 Mbit/s total to have 400 reserved on his AMSIX port for you when you see 300 at LINX and LINX goes down? what makes this a public peering issue.. i see a couple folks already made the point i wanted to do but just because you have capacity to a peer (on a public interface or a dedicated) PI doesnt mean they arent aggregating at their side and/or have enough capacity to carry the traffic where it needs to go this is also about scale, i would hope you arent peering 400Mb flows across a 1Gb port at an IX, this would imho not be good practice.. if your example were 40Mb then it would be different or perhaps 400mb on a 10Gb port. you might even argue there is more incentive to ensure public ix ports have capacity as congestion will affect multiple peers Steve
Re: PAIX Outages
On Wed, Apr 27, 2005 at 10:45:15AM -0400, Jay Patel wrote: I have heard rumors that SD has been having persistent switch problems with their switches at PAIX (Palo Alto), and I was kind of wondering if anyone actually cared? Personally I tend to suspect the general lack of uproar is a rather unfortunate (for them) sign that PAIX is no longer relevant when it comes to critical backbone infrastructures. It looks like different folks have been seeing different levels of outages depending upon which switch/card they are connected to, but I havn't been able to find anyone who has seen fewer than 30 hits between April 16th and the two this morning. Our ports have seen just under 28 hours of total downtime so far this month, while some lucky people have only seen around 6 hours. I'm not sure if anyone at SD or Extreme actually has any real idea what the problem is with these current switches, but given this amount of downtime, they should have replace every last component by now. If Extreme can't fix them, there should be a pile of Black Diamond's sitting on the curb waiting for trash day. In fact, 9/10ths of the way through writing this e-mail, I got a call from SD stating that they are doing exactly that. :) In the mean time, here are some of the more interesting snipits of what has been tried on the current switches: 16 Apr 2005 20:19:53 GMT We are currently experiencing some problems with 2 network cards in our Palo Alto peering switch. This might be causing possible service degradations. Switch Engineers are expecting new cards to replace the 2 suspected faulty network cards. These cards should be arriving in or around 1 hour. Right after the cards arrive, we will be scheduling an emergency maintenance window to get these cards replaced. 19 Apr 2005 14:16:07 GMT The Purpose of this Emergency Maintenance window is for Switch Engineers to replace a faulty processor module card affecting the Bay Area Peering customers. The estimated down time will be 15 minutes. (Actual downtime several hours) 19 Apr 2005 19:27:49 GMT This is the final update regarding the problems experienced today with the peering fabric. Our Switch Engineers corrected the problems during the emergency maintenance window by replacing two line cards and 2 processor cards in the Palo Alto switch. All peering sessions should be restored at this time. 22 Apr 2005 21:56:15 GMT The purpose of this emergency maintenance window is for engineers to replace defective power supply units on the Paix Switch. No impact to your services is expected. 24 Apr 2005 21:25:48 GMT Our Switch Engineers will be conducting and emergency processor cards replacement at the Palo Alto site. The expected downtime while this maintenance is being conducting will be 2 hours. 24 Apr 2005 21:36:18 GMT Our Switch Engineers will be conducting and emergency chassis replacement at the Palo Alto site. The expected downtime while this maintenance is being conducting will be 3 hours. 25 Apr 2005 19:17:41 GMT Our engineers have escalated the problems with the peering switch in Palo Alto to 3rd level support at Extreme, the switch vendor. More details will follow as they become available. 26 Apr 2005 03:00:34 GMT Our Switch Engineers have advised us that the switch has been migrated to a different power bus to rule out any power variables. Power is being monitored for the next 24 hours. 28 Apr 2005 13:33:05 GMT At approximately 6:05 AM local time, the peering switch rebooted itself. Our switch engineers are investigating this issue and believe all sessions are back to normal at this time. More details will be provided as they become available. When I see a stable switching platform going forward, and some service credits for the massive outages we've all endured so far, I'll probably be a lot less cranky about the entire situation. Until then I have to say, if they keep this up their are going to need to change their name to Switch or Data. Oh well, at least this didn't happen during the SD sponsored NANOG. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: PAIX Outages
In a message written on Thu, Apr 28, 2005 at 01:51:54PM -0400, Richard A Steenbergen wrote: Personally I tend to suspect the general lack of uproar is a rather unfortunate (for them) sign that PAIX is no longer relevant when it comes to critical backbone infrastructures. That, or a sign that operators are doing their job. There should be enough redundancy in the system that loss of any one site, for whatever reason, doesn't cause a major, or even minor disruption. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpLoBlj0pW01.pgp Description: PGP signature
Re: PAIX Outages
On Thu, Apr 28, 2005 at 02:11:40PM -0400, Leo Bicknell wrote: In a message written on Thu, Apr 28, 2005 at 01:51:54PM -0400, Richard A Steenbergen wrote: Personally I tend to suspect the general lack of uproar is a rather unfortunate (for them) sign that PAIX is no longer relevant when it comes to critical backbone infrastructures. That, or a sign that operators are doing their job. There should be enough redundancy in the system that loss of any one site, for whatever reason, doesn't cause a major, or even minor disruption. If you have a Cisco router that craps out on a regular basis, Cisco will tell you to get a second one. Some people find this to be a great solution, while other people go buy a Juniper. This probably isn't the way they wanted to announce this, but PAIX is rolling out a new 10GE capable platform (the Extreme Aspen series). Equinix is about to follow suit with their 10GE platform, and the only other two modern competetive IX's in the US have already deployed new 10GE capable platforms (NYIIX with Foundry MG8 and NOTA with Force10). Of course the europeans have had customers up on 10GE for 6 months now, and at a fraction of the price that the US IX's will be charging, but lets ignore that and focus on our own backwater continent right now. :) At the moment, the US IX's largely price their ports as high as the market will possibly bear (and then sometimes a few bucks more just as a kick in the teeth), and largely doesn't have 10GE ports available for either customers or multiple-site trunking. This means that most serious providers don't even have the option of public peering at interesting capacities, even if they weren't concerned about reliability issues. As the US IX market finally gets its act together and rolls out 10GE, many networks are going to start upgrading, and start putting much larger amounts of traffic on them to save on PNI costs. After all, we both know that due to current financial conditions not every network can afford to have all of the spare PNI ports they would like to ensure that they have sufficiently diverse/redundant interconnections with their peers, yes? :) With these IX's poised to take another order of magnitude step (remember the good 'old days when GE seemed to large?), they are about to get another shot in the arm as far as being used for mission critical peering infrastructure is concerned. But no matter how good an idea it may be to make sure that you always have diverse capacity at another location, if one IX is having significantly higher numbers of disruptions than the rest, the network operators are going to go elsewhere (well after their 5 year contracts are up at any rate). Besides, I don't think and for when we go down, there is an Equinix facility down the road is really the marketing angle that Switch and Data had in mind. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
PAIX Outages
I have heard rumors that SD has been having persistent switch problems with their switches at PAIX (Palo Alto), and I was kind of wondering if anyone actually cared?
Re: PAIX Outages
I have heard rumors that SD has been having persistent switch problems with their switches at PAIX (Palo Alto), and I was kind of wondering if anyone actually cared? well, they've sure been having fun up at the six in seattle randy
PAIX Palo-Alto
Anybody else having problems over the PAIX Palo-Alto LAN ? Cheers, André Andre Chapuis IP+ Backbone Engineering AS3303 Swisscom Enterprise Solutions Ltd Genfergasse 14, CH-3050 Bern +41 31 893 89 61 [EMAIL PROTECTED] CCIE #6023
route-views up at PAIX (Palo Alto)
Folks, We are now up and running at the PAIX (Palo Alto) and would like to invite folks at the PAIX to peer with with Route-Views. Please contact us at [EMAIL PROTECTED] if you would like contribute your view. Thanks, The Route-Views Team
Route-Views peering at PAIX and NSPIXP
As part of the Route-Views Update presentation delivered at the NANOG 29 in Chicago, we openly invited participants at the PAIX (install pending) and NSPIXP (WIDE) exchanges to peer with Route-Views (AS6447). For those who may have forgotten or were not present, we thought we would repeat the offer. Those willing to peer, please contact us at [EMAIL PROTECTED] Thanks, The Route-Views Team
VLAN between PAIX VA and EQUINIX ASHBURN
Does anyone here have reliable fiber between PAIX VA and EQUINIX in Ashburn that they would be willing to provide a 100mb VLAN across? We're running into some routing issues and need to find a long term solution in a hurry (a VLAN may solve it). Thanks. Offline responses, please :-) -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com Technology so advanced, even we don't understand it!(SM)
paix
Anybody else seeing a loss of paix? My peering dropped. as well as everyone else in sf. While writing this my phone rang and it was paix. Seems mfn did an unreported bit of maintenance. Anyone else on the peering by paix switch at e-xchange at least will have lost service but it should be restored.
Re: PAIX
To power the IPv6 networks of refridgerators, ovens, and light switches, as well as your 3G video conferencing phone None of these applications have any requirement for peering every 100km2. I'd expect my refrigerator, oven, light switches, etc. to be behind my house's firewall and only talk using link-local addresses anyways. Do you know how much traffic the high resolution MPEG4 video/audio stream from an oven uses!? Why on earth would a network operator want to haul that kind of traffic hundreds of kilometers when 99.5 % of it is going to a 3G mobile phone in the same city. Remember that this video stream from the oven is going to be carry far more data than the phone can handle so that the mobile phone operator can provide a zoom-in application that allows the customer to zoom in on a hotspot on the surface of the turkey to better evaluate whether to switch the oven from roast to broil. Oh, BTW, ask someone at Cisco to explain to you how firewalls work. Their purpose is security, not reduction in PPS or bps. People in general will communicate a lot more with other people who live nearby no matter what the communications medium. Therefore it is likely that as the Internet becomes a commonplace everyday tool for commonplace everyday communications, the vast majority of the traffic will be relatively local. And while there may be some technical gurus who believe in the purity of running a few mega peering points, over the long haul, the customers of networks will reject this kind of centralized system in the same way that they are rejecting every other form of centralized control. --Michael Dillon
Re: PAIX
Thus spake [EMAIL PROTECTED] None of these applications have any requirement for peering every 100km2. I'd expect my refrigerator, oven, light switches, etc. to be behind my house's firewall and only talk using link-local addresses anyways. Do you know how much traffic the high resolution MPEG4 video/audio stream from an oven uses!? Why on earth would a network operator want to haul that kind of traffic hundreds of kilometers when 99.5 % of it is going to a 3G mobile phone in the same city. If there is an economic reason to peer locally, the carriers will do it; however, there is no technical reason to do so: bandwidth is cheap and 20ms RTT is irrelevant to any proposed application in this thread. As pointed out previously, it is currently cheaper to carry that MPEG-4 video to a remote exchange and back than it is to equip and support 96,400 exchange points in the US plus another 99,820 in Canada -- that's one for every 100km2. Oh, BTW, ask someone at Cisco to explain to you how firewalls work. Their purpose is security, not reduction in PPS or bps. Please tell me that was a troll... People in general will communicate a lot more with other people who live nearby no matter what the communications medium. Therefore it is likely that as the Internet becomes a commonplace everyday tool for commonplace everyday communications, the vast majority of the traffic will be relatively local. Agreed; I think that one exchange per LATA (roughly) is a reasonable goal. But that's a far cry from one exchange per 3000 people in the US, or one per 311 people in Canada. Think about those numbers for a minute. And while there may be some technical gurus who believe in the purity of running a few mega peering points, over the long haul, the customers of networks will reject this kind of centralized system in the same way that they are rejecting every other form of centralized control. Nobody is arguing purity; I think it's more pure to have a zillion exchanges, perhaps one in every person's house! However, there are issues, both technical and economic, which limit the number of exchanges that are feasible. Today, that number is a few dozen, not a few hundred thousand. S
Re: PAIX
On Mon, 25 Nov 2002 10:43:35 GMT, [EMAIL PROTECTED] said: Do you know how much traffic the high resolution MPEG4 video/audio stream from an oven uses!? I do believe MPEG4 supports delta compression between frames. If there's enough delta between frames that you have any significant traffic, it's probably an indicator of movement such as flames, and therefor sending it to the 3G phone will be pointless, as said 3G phone had better be in use to call the local fire brigade. I also submit for consideration the observation that high resolution is probably not needed - in general, if you can tell where on the dough-colored to black-colored progression the biscuits are, the resolution is high enough. allows the customer to zoom in on a hotspot on the surface of the turkey to better evaluate whether to switch the oven from roast to broil. This would probably only require small changes to the already-existing Toaster MIB. I would however suggest an offsite backup turkey in case your oven isn't patched against CERT CA-2002-03. msg07013/pgp0.pgp Description: PGP signature
Re: PAIX
On Mon, 25 Nov 2002 [EMAIL PROTECTED] wrote: On Mon, 25 Nov 2002 10:43:35 GMT, [EMAIL PROTECTED] said: Do you know how much traffic the high resolution MPEG4 video/audio stream from an oven uses!? I do believe MPEG4 supports delta compression between frames. If there's enough delta between frames that you have any significant traffic, it's probably an indicator of movement such as flames, and therefor sending it to the 3G phone will be pointless, as said 3G phone had better be in use to call the local fire brigade. But, 3G phones do concurrent data AND voice don't they? You could describe the flames you're seeing! Jason -- Jason Slagle - CCNP - CCDP /\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail .
Re: PAIX
Thus spake Michael C. Wu [EMAIL PROTECTED] On Thu, Nov 14, 2002 at 10:00:48AM +0200, Petri Helenius scribbled: | | I'm putting the number closer to 40 (the NFL cities) right now, and | 150 by the end of the decade, and ultimately any metro with population | greater than 50K in a 100 sq Km area will need a neutral exchange point | (even if it's 1500 sqft in the bottom of a bank building.) | | What application will require this dense peering? To power the IPv6 networks of refridgerators, ovens, and light switches, as well as your 3G video conferencing phone None of these applications have any requirement for peering every 100km2. I'd expect my refrigerator, oven, light switches, etc. to be behind my house's firewall and only talk using link-local addresses anyways. Try again. S
Re: PAIX
Thus spake Brad Knowles [EMAIL PROTECTED] At 2:45 PM -0600 2002/11/24, Stephen Sprunk wrote: None of these applications have any requirement for peering every 100km2. I'd expect my refrigerator, oven, light switches, etc. to be behind my house's firewall and only talk using link-local addresses anyways. Using Rendezvous and multicast DNS? What happens when you bring in the rogue appliance that decides to start spoofing answers from other equipment, or maybe you contract a computer virus that does so? That's a potentially interesting discussion, but it has nothing to do with requiring peering in every 100km2. I think the real risk is VoIP and mobile phones used as Internet video phones with H.323 or other protocols that require high bandwidth and low latency. Imagine doing this for tens of millions of people in a large city. And the half-dozen carriers who operate those tens of millions of phones will have private peering in place if it makes technical sense -- just like they do for TDM phones. That doesn't mean those carriers will want to peer publicly in every city, nor does it necessarily mean that private peering in every city makes economic or technical sense. As I previously asserted, every point in the US is within 20ms RTT of a major exchange today, and 20ms latency is irrelevant in the VoIP arena. Try again. S
Re: PAIX
On Thu, Nov 14, 2002 at 10:00:48AM +0200, Petri Helenius scribbled: | | I'm putting the number closer to 40 (the NFL cities) right now, and | 150 by the end of the decade, and ultimately any metro with population | greater than 50K in a 100 sq Km area will need a neutral exchange point | (even if it's 1500 sqft in the bottom of a bank building.) | | What application will require this dense peering? To power the IPv6 networks of refridgerators, ovens, and light switches, as well as your 3G video conferencing phone | | Pete -
Re: PAIX
Michael C. Wu wrote: On Thu, Nov 14, 2002 at 10:00:48AM +0200, Petri Helenius scribbled: | | I'm putting the number closer to 40 (the NFL cities) right now, and | 150 by the end of the decade, and ultimately any metro with population | greater than 50K in a 100 sq Km area will need a neutral exchange point | (even if it's 1500 sqft in the bottom of a bank building.) | | What application will require this dense peering? To power the IPv6 networks of refridgerators, ovens, and light switches, as well as your 3G video conferencing phone All of the above combined don't generate bandwith even near what a current generation peer2peer file sharing client does. The mentioned applications are not really delay sensitive to the sub-20ms range either. Pete
Re: PAIX
On Mon, 18 Nov 2002, Jere Retzer wrote: Stephen Sprunk wrote: Any point in the US is within 25ms RTT (or less) of a major exchange; eliminating this 25ms of latency will have no effect on VoIP unless you're already near the 250ms RTT limit for other reasons. 25 MS is assuming that the only delay is due to the speed of light. Add equipment, especially routers or other gear that requires manipulating packets and the delays add up quickly. I once read that the most people wil tolerate on a regular basis is around 150-180 ms. I think that is much too high for regular use this is well studied and the numbers are not guessed they are empirical.. off top of my head its -something like- local calls 80-100ms is fine and totally unnoticable at that level, long distance people expect a little delay and 100-200ms is ok and slightly noticable and for long haul (satellite) etc people will tolerate anything up to 600ms so as you say 25ms even with extra ms for switching is fine.. Steve
Re: PAIX
Thus spake Jere Retzer [EMAIL PROTECTED] - Coast-to-coast guaranteed latency seems too low in most cases that I've seen. Not calling CEOs and marketers liars but the real world doesn't seem to do as well as the promises. Someone in the engineering group of a promising local ISP once told me their billing and capacity planning model was designed for them to fail every customer SLA and still turn a profit. Interpret that how you wish. As VOIP takes off local IP exchanges will continue/increase in importance because people won't tolerate high latency. Any point in the US is within 25ms RTT (or less) of a major exchange; eliminating this 25ms of latency will have no effect on VoIP unless you're already near the 250ms RTT limit for other reasons. What percentage of your phone calls are local? Who cares? I'm billed by the airtime I consume, not by the distance my call goes. Hawaii and the local pizza place cost me the same amount. - Yes, we do various kinds of video over Internet2. Guess what? Packet loss is very important. Fewer hops mean fewer lost packets. You've been listening to the MPLS/ATM crowd too long. Congestion, not hops, causes packet loss. - Unfortunately, these applications do not work with today's local broadband networks one reason being the lack of local interconnection. People have quit believing the Radio Shack ads. We have the technology to make these applications work if we'd stop arguing that no one wants to use them. Of course no one wants to use them they know they won't work! These apps are broken because the interested parties aren't interested. Ask any doctor if he wants to give up physically seeing his patients -- there are laws in most states outlawing doctors talking to patients unless they are physically present, not to mention most doctors refuse to even digitize their records or use Palm Pilots to look up forgotten symptoms or treatments. Blaming broadband for the failure of your killer apps is not going to help. S
Re: Simulated disaster exercise? Re: PAIX
It should also be noted that the CAIDA study only examined the core giant cluster of the Internet. In other words they only looked at the most interconnected part of the Internet not the whole Internet. While you could argue only the core matters, the methodological approach gives you much different results. You are ignoring the places that were disconnected or balkanized in other studies (Albert et al 2000, Cohen et al 2002...etc.) CAIDA are the data gurus, so I'm sure there is good justification for this, it is just not outline in their paper - http://www.caida.org/analysis/topology/resilience/ - Original Message - From: Sean Donelan [EMAIL PROTECTED] Date: Monday, November 18, 2002 0:55 am Subject: Re: Simulated disaster exercise? Re: PAIX On Sun, 17 Nov 2002, Richard A Steenbergen wrote: The usual response was it only affected the public exchange fabric, not any private point-to-point circuits between providers through the same facility. But if we're going to compare this to MAE Gigaswitch failures, shouldn't we be talking apples to apples and oranges to oranges? No. The world has changed. If people are buying tangerines and grapefruitnow, that's what we should be talking about, not apples and oranges. If most of today's Internet exchange is via private connections, those are the connections we should be looking at. The fine folks at Caimis and Caida have done some analysis, and identifiedthe nodes which make up the core of the Internet. They've also identified the most connected core nodes. The good news is the networkdoesn't go non-linear until more than 25% of the nodes are removed.
Re: PAIX
My apologies. This was not intended to go out to the list. - Dan On Mon, 18 Nov 2002, Daniel Golding wrote: Paul, Not sure if you are currently in a position to answer this... With the impending SD buyout of some of PAIX's assets, do you see PAIX Atlanta as a going concern? I know SD owns an adjacent floor at 56 Marieta. Do you think they will hold on to both? I am curious, as my company has a POP in PAIX Atlanta, and we are starting to do some contigency planning. Thanks, Daniel Golding On 17 Nov 2002, Paul Vixie wrote: speaking of paix, for those of you in atlanta (ietf) this week, i'm going to do a couple of site walkthroughs. send me e-mail if interested. -- Paul Vixie
Re: PAIX
daniel wrote: With the impending SD buyout of some of PAIX's assets, do you see PAIX Atlanta as a going concern? I know SD owns an adjacent floor at 56 Marieta. Do you think they will hold on to both? until the bankruptcy court's auction runs its course, we don't know who the new owner of PAIX will be. in any case, i can't speak for SD at this time. I am curious, as my company has a POP in PAIX Atlanta, and we are starting to do some contigency planning. it's very likely that SD would like to talk you about those plans, and that with appropriate NDA's in place, they would tell you more about PAIX-ATL1's likely future under their ownership. paul re: speaking of paix, for those of you in atlanta (ietf) this week, i'm going to do a couple of site walkthroughs. send me e-mail if interested. -- Paul Vixie
Re: PAIX
You should move to the Atlanta NAP. It is designed to withstand a plane crashing into the building. BTW, Netrail still owes me money. - Nathan Stratton On Mon, 18 Nov 2002, Daniel Golding wrote: Paul, Not sure if you are currently in a position to answer this... With the impending SD buyout of some of PAIX's assets, do you see PAIX Atlanta as a going concern? I know SD owns an adjacent floor at 56 Marieta. Do you think they will hold on to both? I am curious, as my company has a POP in PAIX Atlanta, and we are starting to do some contigency planning. Thanks, Daniel Golding On 17 Nov 2002, Paul Vixie wrote: speaking of paix, for those of you in atlanta (ietf) this week, i'm going to do a couple of site walkthroughs. send me e-mail if interested. -- Paul Vixie Get your free encrypted email at https://www.hushmail.com
Re: PAIX
Get over Netrail already Nathan. Enough years have passed... -ren At 08:48 AM 11/18/2002 -0800, you wrote: You should move to the Atlanta NAP. It is designed to withstand a plane crashing into the building. BTW, Netrail still owes me money. - Nathan Stratton On Mon, 18 Nov 2002, Daniel Golding wrote: Paul, Not sure if you are currently in a position to answer this... With the impending SD buyout of some of PAIX's assets, do you see PAIX Atlanta as a going concern? I know SD owns an adjacent floor at 56 Marieta. Do you think they will hold on to both? I am curious, as my company has a POP in PAIX Atlanta, and we are starting to do some contigency planning. Thanks, Daniel Golding On 17 Nov 2002, Paul Vixie wrote: speaking of paix, for those of you in atlanta (ietf) this week, i'm going to do a couple of site walkthroughs. send me e-mail if interested. -- Paul Vixie Get your free encrypted email at https://www.hushmail.com
Re: PAIX
On Mon, 18 Nov 2002 08:48:54 PST, [EMAIL PROTECTED] said: You should move to the Atlanta NAP. It is designed to withstand a plane crash ing into the building. I think Daniel Golding was more worried about an accountant crashing into the building msg06799/pgp0.pgp Description: PGP signature
Re: PAIX
Thus spake David Diaz [EMAIL PROTECTED] I agree with everything said Stephen except the part about the medical industry. There are a couple of very large companies doing views over an IP backbone down here. Radiology is very big on networking. They send your films or videos over the network to where the Radiologist is. For example one hospital owns about 6 others down here, and during off hours like weekends etc, the 5 hospitals transmit their films to where the 1 radiologist on duty is. I meant my reply to be directed only at telemedecine, where the patient is at home and consults their general practitioner or primary care physician via broadband for things like the flu or a broken arm. While there's lots of talk about this in sci-fi books, there's no sign of this making any significant inroads today, nor does it qualify as a killer app for home broadband. I do work with several medical companies who push radiology etc. around on the back end for resource-sharing and other purposes. This is quite real today, and is driving massive bandwidth upgrades for healthcare providers. However, I don't think it qualifies under most people's idea of telemedecine. S
Re: PAIX
Is this sort of radiology data sent over private lines or the public internet? What are the bandwidth demands? Not a good reason for extensive local peering, but a very interesting application. - Dan On Mon, 18 Nov 2002, Stephen Sprunk wrote: Thus spake David Diaz [EMAIL PROTECTED] I agree with everything said Stephen except the part about the medical industry. There are a couple of very large companies doing views over an IP backbone down here. Radiology is very big on networking. They send your films or videos over the network to where the Radiologist is. For example one hospital owns about 6 others down here, and during off hours like weekends etc, the 5 hospitals transmit their films to where the 1 radiologist on duty is. I meant my reply to be directed only at telemedecine, where the patient is at home and consults their general practitioner or primary care physician via broadband for things like the flu or a broken arm. While there's lots of talk about this in sci-fi books, there's no sign of this making any significant inroads today, nor does it qualify as a killer app for home broadband. I do work with several medical companies who push radiology etc. around on the back end for resource-sharing and other purposes. This is quite real today, and is driving massive bandwidth upgrades for healthcare providers. However, I don't think it qualifies under most people's idea of telemedecine. S
Re: PAIX
Stephen Sprunk wroteI meant my reply to be directed only at "telemedecine", where the patient is athome and consults their general practitioner or primary care physician viabroadband for things like the flu or a broken arm. While there's lots of talkabout this in sci-fi books, there's no sign of this making any significantinroads today, nor does it qualify as a "killer app" for home broadband. Cost and trouble has been too high. Widespread broadband could change this. Assisted living facilities, with wealthy retired baby boomers will be a high payoff market. We're already seeing some clinics and physicians who encourage e-mail with patients. Video is far better to assess the patient's attitude/condition even without any instrumentation
Re: PAIX/industry specific exchange pts
Actually I got to sit with a company deploying this as a product, and I was impressed. Right now, it's all run over *gulp* dsl. But they are moving towards tunnels on the open internet. My cousin actually does work in the field and when it's working, it's impressive. When there is a glitch such as a power failure (U can tell something isnt setup right if this affects their network) they have MIS issues and have to volkswagon it over to the main location. On the one had it makes me nervous that it's not rock solid, on the other hand if it means a senior doctor has a shot at looking at me pics, ultrasound videos etc, before they do something, then Im happier. Somehow I think it's really used in some locations to cut back on expensive staff. Still, not a need for an exchange pt. Perhaps a medical exchange point??? Perhaps that's the next thread? Goes against my philosophy of aggregation is the key to life But could there be medical or industry specific exchanges just like there are industry networks??? dave At 11:42 -0600 11/18/02, Daniel Golding wrote: Is this sort of radiology data sent over private lines or the public internet? What are the bandwidth demands? Not a good reason for extensive local peering, but a very interesting application. - Dan On Mon, 18 Nov 2002, Stephen Sprunk wrote: Thus spake David Diaz [EMAIL PROTECTED] I agree with everything said Stephen except the part about the medical industry. There are a couple of very large companies doing views over an IP backbone down here. Radiology is very big on networking. They send your films or videos over the network to where the Radiologist is. For example one hospital owns about 6 others down here, and during off hours like weekends etc, the 5 hospitals transmit their films to where the 1 radiologist on duty is. I meant my reply to be directed only at telemedecine, where the patient is at home and consults their general practitioner or primary care physician via broadband for things like the flu or a broken arm. While there's lots of talk about this in sci-fi books, there's no sign of this making any significant inroads today, nor does it qualify as a killer app for home broadband. I do work with several medical companies who push radiology etc. around on the back end for resource-sharing and other purposes. This is quite real today, and is driving massive bandwidth upgrades for healthcare providers. However, I don't think it qualifies under most people's idea of telemedecine. S
Re: PAIX
Any idea how large these images are? I seem to recall that they are massive, given ultra-hi-rez data (Are they attaching them to lookOut mail ;-?) And the radiologist may look for a few seconds at best so he is NOT going to want to wait -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: PAIX
I just asked, and you can video clip images,...85megs is typical At 12:46 -0500 11/18/02, David Lesher wrote: Any idea how large these images are? I seem to recall that they are massive, given ultra-hi-rez data (Are they attaching them to lookOut mail ;-?) And the radiologist may look for a few seconds at best so he is NOT going to want to wait -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433 -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] Smotons (Smart Photons) trump dumb photons
Re: PAIX
Thus spake Daniel Golding [EMAIL PROTECTED] Is this sort of radiology data sent over private lines or the public internet? What are the bandwidth demands? Not a good reason for extensive local peering, but a very interesting application. I've only seen companies pushing this data around between their own sites; for instance a remote clinic with just general practitioners may send films to a central hospital for analysis, or one hospital may send films to another hospital when their staff radiologist is out to lunch or on vacation. BW, of course, depends on how fast you want the transfers to go. The film files are in the hundreds of MB range, and providers are upgrading from FT1 FR to FT3 ATM at major sites. S
Re: PAIX
David Diaz replied to my comments Concerning latency Well the bingo latency number used a lot in voice is 50ms. Im simplifing without getting into all the details, but that's an important number. As far as VoIP goes, I think higher latency is ok, it's more important to have "consistent" latency. Fluctuating latency really affects VoIP more then a higher consistent latency. There are a lot of people doing VoIP and traditional voice on satellites and the latency there is huge. Here's an example. Without naming networks, I recently subscribed to DSL at the Oregon coast because the local phone company, which is also a national network provider advertised that they use a particular ISP, who we have in the NWAX exchange in Portland. I thought, well I should be able to get a good connection back to Oregon Health and Sciences University (OHSU), and if so this will be a good path for the physicians in that coastal community who have wanted to particpate in our grand rounds and other continuing medical education programs. They also have wanted to let the public participate in our "healthy chats" program. These events are live and interactive. So, I was very optimistic and set up my connection. I was shocked to learn, however that the DSL provider routes all the bits from that location to Dallas/Fort Worth, Texas before letting them find their way to their eventual destination. Rather than a nice direct route to OHSU, the route was 19 hops via Texas and Silicon Valley (Palo Alto and San Francisco) before getting to Portland. The average latency, which I duplicated consistently with multiple destinations in the Portland area is 180 msec and I have seen packet loss hitting 30% every minute or two. There is absolutely no way that this connection would be able to handle an interactive application. Yes, people have tolerated 500 msec latency on satellite links but only because they really had no choice. Dave Diaz continued Fewer hops = less packet loss? There has been a lot of discussion on the list about that. I still dont see it although it does push latency up a bit. Truth is that there are a lot of tunnels or express routes build in, so we arent seeing all the hops nowadays. I think that's more for sales and marketing as people keep judging networks by hops in a traceroute. See above. Partly, I think it is just the odds of encountering congestion goes up exponentially with the number of hops. No engineering reason other than if you have5% likelihood of hitting congestion on any one hop and then you have 19 your odds of hitting congestion are much higher. Combine that with a persistent connection for an interactive video session and you will find, as I did that every couple minutes you have a spike that causes fits with your video. Dave Diaz continued An IP backbone is a bad place for live TV. Delayed or on demand tv yes. Live tv plays to the benefits of One to Many broadcast ability of satellite as Doug Humphrey will tell you. So a feed from a DSS dish into your local cache would work well. It still can be done at a per city peering point to better feed the broadband users. If we fix the IP backbones for interactive TV then broadcast should be a piece of cake. While I agree with a later post that questioned convergence for the sake of convergence, the benefits of IP+Ethernet are that it is an order of magnitude cheaper and you eliminate the need for any local "head end" equipment, manipulation by local stations, etc, etc. Ultimately, the only stuff that will originate locally is local news and content. Jere
Re: PAIX
Vadim Antonov wrote: People are doing various kinds of video over Internet 1; works fine.Then I must be doing it all wrong because I've never had much luck. Maybe it is a function of the origin and destination location + network. Since Portland is not a top 25 market our service has never been very good that's why we started an exchange
Re: PAIX
Stephen Sprunk wrote: Any point in the US is within 25ms RTT (or less) of a major exchange; eliminating this 25ms of latency will have no effect on VoIP unless you're already near the 250ms RTT limit for other reasons. 25 MS is assuming that the only delay is due to the speed of light. Add equipment, especially routers or other gear that requires manipulating packets and the delays add up quickly. I once read that the most people wil tolerate on a regular basis is around 150-180 ms. I think that is much too high for regular use
Re: PAIX
Unnamed Administration sources reported that Stephen Sprunk said:
BW, of course, depends on how fast you want the transfers to go. The film files
are in the hundreds of MB range, and providers are upgrading from FT1 FR to FT3
ATM at major sites.
The answer is not wait at all...
See, over the last 20 years, radiologists went from being the
butt of MD jokes to being high demand subspecialists. They can
look at a view and charge {say} $100 for a glance.
If they can do say 5/minute, great. Ten, better. But in any case,
no way will [s]he cool heels waiting for an image to paint.
You want a buffer locally of the next n just to be sure.
They might send, oh, 6 scans; he looks at the first and says
Forget the rest, this guy's got {Mumble}, call the surgeon.
(Or Call the morgue, this guy will be there shortly..)
--
A host is a host from coast to [EMAIL PROTECTED]
no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433
Re: PAIX
On Mon, Nov 18, 2002 at 10:13:48AM -0800, Jere Retzer wrote: Stephen Sprunk wrote: Any point in the US is within 25ms RTT (or less) of a major exchange; eliminating this 25ms of latency will have no effect on VoIP unless you're already near the 250ms RTT limit for other reasons. 25 MS is assuming that the only delay is due to the speed of light. Add equipment, especially routers or other gear that requires manipulating packets and the delays add up quickly. I once read that the most people wil tolerate on a regular basis is around 150-180 ms. I think that is much too high for regular use True. As far as VoIP goes, take 2 (digital/pcs/gsm/whatnot) cell phones (preferably on different carriers, or even the same if you want to see it) and call the other phone. Check out the delay in there. People who think that VoIP needs low delay don't realize the [presumably compression and other dsp related] delays introduced that people will be able to withstand. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: PAIX
Jared Mauch wrote: True. As far as VoIP goes, take 2 (digital/pcs/gsm/whatnot) cell phones (preferably on different carriers, or even the same if you want to see it) and call the other phone. Check out the delay in there. People who think that VoIP needs low delay don't realize the [presumably compression and other dsp related] delays introduced that people will be able to withstand. - jared It's not compression only, at least GSM (which I'm familiar with) runs it's audio packetized. Or should we call them cells since they are all the same size? Pete
Re: PAIX
On Mon, 18 Nov 2002, David Lesher wrote: Depends. They can also be small. I recently was given 1 hour to ship X-rays and composite MRIs for a 2nd opinion. I was told by the radiologist to take the printed pix, get a late model digital camera and hold the pix up a window with no tree or electrical wires in the background and no direct sunlight and take a digital picture. The 800K files were sent via my home ADSL and worked quite well. -Hank Any idea how large these images are? I seem to recall that they are massive, given ultra-hi-rez data (Are they attaching them to lookOut mail ;-?) And the radiologist may look for a few seconds at best so he is NOT going to want to wait -- A host is a host from coast to [EMAIL PROTECTED] no one will talk to a host that's close[v].(301) 56-LINUX Unless the host (that isn't close).pob 1433 is busy, hung or dead20915-1433
Re: PAIX
Jere Retzer wrote: Vadim Antonov wrote: People are doing various kinds of video over Internet 1; works fine. Then I must be doing it all wrong because I've never had much luck. Maybe it is a function of the origin and destination location + network. Since Portland is not a top 25 market our service has never been very good -- that's why we started an exchange The unfortunate development in the video market has been high deployment of two applications which do streaming without too much regard to how the underlying network works. One sends a high number of fragmented packets and the other is highly suspectible to retransmission collapse where retransmission requests and retransmissions actually overload the already congested path by a margin. Additionally, the deployment habit of content providers to prefer HTTP instead of RTP/UDP makes monitoring and improving on these services and their performance quite challenging. Pete
Re: PAIX
Title: Re: PAIX Well... remember it's speed of light THROUGH fiber which isnt the same, its actually a bit slower then c Coast to coast you should see 35 - 65ms depending on the route. We've all had this thread about router overhead. If there is a congestions point in the middle with buffering and traffic level priorities running, then you are right. Otherwise I dont think you should see 150-180ms. In the real world however, yes, off several dsl links Im seeing those levels to various sites, I think it's more a factor of congested peering links or traffic aggregation at a hub. People arent spending the money to upgrade links right now. At 10:13 -0800 11/18/02, Jere Retzer wrote: Content-Type: text/html Content-Description: HTML Stephen Sprunk wrote: Any point in the US is within 25ms RTT (or less) of a major exchange; eliminating this 25ms of latency will have no effect on VoIP unless you're already near the 250ms RTT limit for other reasons. 25 MS is assuming that the only delay is due to the speed of light. Add equipment, especially routers or other gear that requires manipulating packets and the delays add up quickly. I once read that the most people wil tolerate on a regular basis is around 150-180 ms. I think that is much too high for regular use -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] Smotons (Smart Photons) trump dumb photons
Re: PAIX
David Diaz I just asked, and "you can video clip images,...85megs is typical"At 12:46 -0500 11/18/02, David Lesher wrote:Any idea how large these images are? I seem to recall thatthey are massive, given ultra-hi-rez data(Are they attaching them to lookOut mail ;-?)And the radiologist may look for a few seconds at best so heis NOT going to want to wait Try asking any radiologist, cardiologist, oncologist how much quality is good enough and they will probably say "it depends." Digital mammography is potentially hundreds of megabytes and you sure don't want to miss (or insert any extra) white spots! What we're seeing is higher and higher resolution combined with "longitudinal" (ie, over time) recording and in some cases additional 'dimensions' added using color and so on, and on top of that the ability to look at various depths, rotate, three spatial dimensions. So, for example a live echocardiogram today will use color as an indication of the "force" of the heart beat. MRIs typically record data at three dimensions. As we approach micron-level resolution the file size grows into the petabytes. No, I did not make a mistake there. Currently, no one even stores these but they will want to in time. Given our demands for instant feedback on our health these kinds of applications will eventually become more real time. One internationally recognized teaching hospital in the upper midwest advertises that all their x-rays are read by a radiologist within 30 minutes.
Re: PAIX
Actually the way it seems to work is head over to the local server,
and the radiologist goes through several patients at a time, taking
not of any notations the techie made on the film. I do not think
most are emergencies or code blues, just someone coming in with a
pain etc. 5min probably wont make a difference. If they are really
showing those kind of problems then of course the doctor is called in
from home by the attending.
Still for remote clinics etc, it's a powerful resource. Maybe for
second opinions when something isnt clear when surgery is needed
immediately or not.
I also know that certain places do not have good health care like
indian reservations say in Alaska. This way an expert can really
help even if not local.
The internet it's not just for spam anymore ;-)
ss
At 13:19 -0500 11/18/02, David Lesher wrote:
Unnamed Administration sources reported that Stephen Sprunk said:
BW, of course, depends on how fast you want the transfers to go.
The film files
are in the hundreds of MB range, and providers are upgrading from
FT1 FR to FT3
ATM at major sites.
The answer is not wait at all...
See, over the last 20 years, radiologists went from being the
butt of MD jokes to being high demand subspecialists. They can
look at a view and charge {say} $100 for a glance.
If they can do say 5/minute, great. Ten, better. But in any case,
no way will [s]he cool heels waiting for an image to paint.
You want a buffer locally of the next n just to be sure.
They might send, oh, 6 scans; he looks at the first and says
Forget the rest, this guy's got {Mumble}, call the surgeon.
(Or Call the morgue, this guy will be there shortly..)
--
A host is a host from coast to [EMAIL PROTECTED]
no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433
Re: PAIX
On Mon, 18 Nov 2002, David Diaz wrote: In the real world however, yes, off several dsl links Im seeing those levels to various sites, I think it's more a factor of congested peering links or traffic aggregation at a hub. People arent spending the money to upgrade links right now. I should move to whichever shangri-la you reside in; How about 4 seconds from a sfba SBC dsl link to www.pbi.net: http://snark.net/~mrtg/www.pbi.net.html Correlating data to other points on the net seems to suggest the problem isn't congested peering :) http://snark.net/~mrtg/ matto Shame on you, pacbell. [EMAIL PROTECTED]darwin Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include disclaim.h
Re: PAIX
David Diaz Actually the way it seems to work is head over to the local server, and the radiologist goes through several patients at a time, taking not of any notations the techie made on the film. I do not think most are emergencies or code blues, just someone coming in with a pain etc. 5min probably wont make a difference. If they are really showing those kind of problems then of course the doctor is called in from home by the attending.Still for remote clinics etc, it's a powerful resource. Maybe for second opinions when something isnt clear when surgery is needed immediately or not.I also know that certain places do not have good health care like indian reservations say in Alaska. This way an expert can really help even if not local.The internet it's not just for spam anymore ;-) In Internet2, we're starting to see the Internet used for real time distributed "tumor board" meetings. The way this works, you have some oncologists (cancer specialists) and radiologist, and the attending physicians for some cancer patients. The group consults on the appropriate treatment program for the patients. Using the Internet, it is possible to bringsome pretty heavy expertise to the discussion, which is important for smaller communities that do not have access to these experts.
Re: PAIX
Wow, well Im in the SE. Matter of fact, I did get adsl and sdsl from 2 different providers on the same line. Maybe I can multihome ;-) Telocity seems to be doing a decent job lately, however they seemed to be doing some maint yesterday as it was the 1st time I noticed any issues. Oh Telocity is dtv owned now. It would be curious to see how the cable/dsl providers are doing lately. I know cox has a buildout going to ashburn and will be doing peering. Wonder if that is going to help or hurt latency and packet loss. Depends if they decide not to continue upgrading their transit circuits (it would seem to me). I usually say more peering is a good thing. Hopefully the new broadband players will have a more open peering policy and KEEP it that way. Seems once people get close to tier1 they close it again. Like a 2yr window opening and closing. d At 11:29 -0800 11/18/02, just me wrote: On Mon, 18 Nov 2002, David Diaz wrote: In the real world however, yes, off several dsl links Im seeing those levels to various sites, I think it's more a factor of congested peering links or traffic aggregation at a hub. People arent spending the money to upgrade links right now. I should move to whichever shangri-la you reside in; How about 4 seconds from a sfba SBC dsl link to www.pbi.net: http://snark.net/~mrtg/www.pbi.net.html Correlating data to other points on the net seems to suggest the problem isn't congested peering :) http://snark.net/~mrtg/ matto Shame on you, pacbell. [EMAIL PROTECTED]darwin Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include disclaim.h
Re: PAIX
Thus spake Jere Retzer [EMAIL PROTECTED] Stephen Sprunk wrote: Any point in the US is within 25ms RTT (or less) of a major exchange; eliminating this 25ms of latency will have no effect on VoIP unless you're already near the 250ms RTT limit for other reasons. Can you please upgrade to a MUA with standard quoting semantics? 25 MS is assuming that the only delay is due to the speed of light. No. I'm asserting that every populated area in the U.S. is within 25ms ping time of a major exchange, absent congested pipes. Add equipment, especially routers or other gear that requires manipulating packets and the delays add up quickly. If your router(s), switch(es), or firewall(s) need more than 1ms to forward a packet, it's time to select a new vendor. It's 20 hops between my home and work box, including 2900mi of fiber, a couple firewalls, and a DSL link -- and that's only 80-90ms. We clearly don't need an exchange for every 100km2 to get acceptable RTT. What we need are uncongested pipes. I once read that the most people wil tolerate on a regular basis is around 150-180 ms. I think that is much too high for regular use ITU G.113 says users won't even notice the latency until it his 250ms. Do you have scientific studies that show 150-180ms is problematic? I'm sure the ITU (and a few hundred telcos) will be interested. Business experience shows users will tolerate over 1000ms latency if there's an economic incentive. There are many companies doing voice-over-internet that operate networks this way, and they're making a lot of money doing it. S
Re: Simulated disaster exercise? Re: PAIX
In the 1990's the MAEs and Gigaswitches would give us an unscheduled failure of a major exchange point on a regular basis, which let us demostrate our disaster recovery capabilities. With the improved reliability, i.e. the PAIXes haven't had a catastrophic failure, we haven't had as many opportunities to demonstrate how well we can handle a disaster at those locations. Without creating an actual disaster, what if all the providers turned off their BGP sessions with other providers at a PAIX (or Equinix or LINX or where ever), both through the shared switch and private point-to-point links, for an hour. More than likely no one would notice, but then we would have some hard data. Individually providers have tested parts of their own network, but I haven't heard of any coordinated efforts to test recovery across all the service providers in a particular location. This was more or less done in Sweden two weeks ago. In Stockholm there are two sites located in Government own locations. We migrated one of these sites to a new location, and then shut down one of the halves for around 8 hours. Best regards, - kurtis -
Re: PAIX
I definitely would NOT want to see my doctor over a video link when I need him. The technology is simply not up to providing realistic telepresense, and a lot of diagnostically relevant information is carried by things like smell and touch, and little details. So telemedicine is a poor substitute for having a doctor on site; and should be used only when it is absolutely the only option (i.e. emergency on an airplane, etc). (As a side note - that also explains reluctance of doctors to rely on computerized diagnostic systems: they feel that the system does not have all relevant information (which is true) and that they have to follow its advice anyway, or run a chance of being accused of malpractice. This is certainly the case with textbooks - if a doctor does something clearly against a textbook advice, with negative outcome, lawyers have a feast - but doctors never get rewarded for following their common sense when outcome is positive. And automated diagnostic systems are a lot more specific with their recommendations than textbooks!). Emergency situations, of course, require some pre-emptive engineering to handle, but by no means require major investment to allow a major percentage of traffic to be handled as emergeny traffic. As with VoIP, simple prioritization is more than sufficient for telemedicine apps. (Note that radiology applications are simply bulk file transfers, no interactivity). --vadim On Mon, 18 Nov 2002, Stephen Sprunk wrote: Thus spake David Diaz [EMAIL PROTECTED] I agree with everything said Stephen except the part about the medical industry. There are a couple of very large companies doing views over an IP backbone down here. Radiology is very big on networking. They send your films or videos over the network to where the Radiologist is. For example one hospital owns about 6 others down here, and during off hours like weekends etc, the 5 hospitals transmit their films to where the 1 radiologist on duty is. I meant my reply to be directed only at telemedecine, where the patient is at home and consults their general practitioner or primary care physician via broadband for things like the flu or a broken arm. While there's lots of talk about this in sci-fi books, there's no sign of this making any significant inroads today, nor does it qualify as a killer app for home broadband. I do work with several medical companies who push radiology etc. around on the back end for resource-sharing and other purposes. This is quite real today, and is driving massive bandwidth upgrades for healthcare providers. However, I don't think it qualifies under most people's idea of telemedecine. S
Re: PAIX
On Mon, 18 Nov 2002, Jere Retzer wrote: Maybe it is a function of the origin and destination location + network. Since Portland is not a top 25 market our service has never been very good that's why we started an exchange Yep, Intenet service quality is very uneven; and it does not seem to be an easily quantifiable factor allowing consumers and businesses to select a provider. So, all providers looking the same, they choose the lowest-priced ones, thus forcing providers to go air transport way (i.e. untimately destructive price wars). With full understanding of political infeasibility of proposed, I think that the best thing ISPs could do is to fund some independent company dedicated to publishing comprehensive regional ISP quality information - in a format allowing apple-to-apple comparison. Then they could justify price spread by having facts to back them up. --vadim
Re: [Re: PAIX]
for my voip network/peers, i can withstand rtt's of around 600ms - granted the quality sucks at that sort of latency, but data/ip routes into some of the less-than-developed places in the world are crap at best, and any phone is better than none Jared Mauch [EMAIL PROTECTED] wrote: On Mon, Nov 18, 2002 at 10:13:48AM -0800, Jere Retzer wrote: Stephen Sprunk wrote: Any point in the US is within 25ms RTT (or less) of a major exchange; eliminating this 25ms of latency will have no effect on VoIP unless you're already near the 250ms RTT limit for other reasons. 25 MS is assuming that the only delay is due to the speed of light. Add equipment, especially routers or other gear that requires manipulating packets and the delays add up quickly. I once read that the most people wil tolerate on a regular basis is around 150-180 ms. I think that is much too high for regular use True. As far as VoIP goes, take 2 (digital/pcs/gsm/whatnot) cell phones (preferably on different carriers, or even the same if you want to see it) and call the other phone. Check out the delay in there. People who think that VoIP needs low delay don't realize the [presumably compression and other dsp related] delays introduced that people will be able to withstand. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine. Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence. - Stephen Hawking -
Re: PAIX
Vadim Antonov wrote:I definitely would NOT want to see my doctor over a video link when I needhim. The technology is simply not up to providing realistic telepresense,and a lot of diagnostically relevant information is carried by things likesmell and touch, and little details. So telemedicine is a poor substitutefor having a doctor on site; and should be used only when it isabsolutely the only option (i.e. emergency on an airplane, etc).If you are really ill, this is true but there are always gray areas that go into the decision whether the 'illness' is worth a visit. Physicians often order things for patients they know based upon a phone call or even e-mail if they feel reasonably comfortable. I think that there are lots of situations that a physician would recommend "just keep Johnny home for a couple days, give him plenty of fluids and [fill in the blank] call me in two days if he isn't feeling better." Having live video of Johnny is a pretty good supplement to voice, or for that matter the receptionist could record the video call for the physician and he could play it back when he has a few minutes. It's potentially even more important with elderly shut-ins, because bringing them in can be difficult and expensive and their immune systems are typically weaker so you should try to minimize their exposure to people with contagious diseases. Jere
Re: PAIX
A much more real world example is in Heart medicine. I worked on a system that used ds1's between hospitals. Say you have hospital A which is a major institution and h ou have hospital B which is more remote and has fewer skilled Doctors etc. Using a standard such as Dicom a Dr in Hospital B. can send your cath image to a specialist in Hospital A. That specialist can do a study and determine with the primary Doctor in hospital B. the best course of action. Also, should it be critical your x-rays or cath images have already arrived at Hospital A. while you are in the air being rapidly transported to A from B. The team can already be planning and up o spead on your condition by the time you arrive saving in this case minutes and minutes and seconds count. Your Doctor in B. also can be kept up to speed and have his reco records updated from A s well. Its a very real situation one that Heartlab Inc. helped design and worked really well. Also don't forget that most Major hospitals use ATM even to the desk top. They can provide telemedicine services very easily over the wide area but in many cases these are not over the public IP backbone but rather over their own network. On Mon, 18 Nov 2002, Jere Retzer wrote: Vadim Antonov wrote: I definitely would NOT want to see my doctor over a video link when I need him. The technology is simply not up to providing realistic telepresense, and a lot of diagnostically relevant information is carried by things like smell and touch, and little details. So telemedicine is a poor substitute for having a doctor on site; and should be used only when it is absolutely the only option (i.e. emergency on an airplane, etc). If you are really ill, this is true but there are always gray areas that go into the decision whether the 'illness' is worth a visit. Physicians often order things for patients they know based upon a phone call or even e-mail if they feel reasonably comfortable. I think that there are lots of situations that a physician would recommend just keep Johnny home for a couple days, give him plenty of fluids and [fill in the blank] ¯ call me in two days if he isn't feeling better. Having live video of Johnny is a pretty good supplement to voice, or for that matter the receptionist could record the video call for the physician and he could play it back when he has a few minutes. It's potentially even more important with elderly shut-ins, because bringing them in can be difficult and expensive and their immune systems are typically weaker so you should try to minimize their exposure to people with contagious diseases. Jere
Re: PAIX
On Mon, 18 Nov 2002, Jere Retzer wrote: It's potentially even more important with elderly shut-ins, because bringing them in can be difficult and expensive and their immune systems are typically weaker so you should try to minimize their exposure to people with contagious diseases. What happened to the gool ol' house calls? --vadim
Re: PAIX
Which is worse - the marketeers that invent performance fiction like that, or the customers who go chasing after a lower number without any analysis of how that number is determined? Customers because, the are the ones which eventually make the choice and pay the bill. As long as there is successful misleading marketing, the marketers will be happy. Customers need to buy their own happiness with educated choices. Pete
Re: Simulated disaster exercise? Re: PAIX
On Sun, Nov 17, 2002 at 12:10:43AM -0500, Richard A Steenbergen wrote: On Sat, Nov 16, 2002 at 10:00:07PM -0500, Sean Donelan wrote: The usual response was it only affected the public exchange fabric, not any private point-to-point circuits between providers through the same facility. But if we're going to compare this to MAE Gigaswitch failures, shouldn't we be talking apples to apples and oranges to oranges? In this case, the MAE was a banana: Worldcom always officially discouraged private interconnects among colocated routers. Steve
Re: Simulated disaster exercise? Re: PAIX
On Sat, Nov 16, 2002 at 08:45:07PM -0500, Sean Donelan wrote: In the 1990's the MAEs and Gigaswitches would give us an unscheduled failure of a major exchange point on a regular basis, which let us demostrate our disaster recovery capabilities. With the improved reliability, i.e. the PAIXes haven't had a catastrophic failure, we haven't had as many opportunities to demonstrate how well we can handle a disaster at those locations. Without creating an actual disaster, what if all the providers turned off their BGP sessions with other providers at a PAIX (or Equinix or LINX or where ever), both through the shared switch and private point-to-point links, for an hour. More than likely no one would notice, but then we would have some hard data. Individually providers have tested parts of their own network, but I haven't heard of any coordinated efforts to test recovery across all the service providers in a particular location. There was a major power outage in Amsterdam on November 6th, which took down the power at 2 major housing locations (Nikhef and SARA), which house the original 2 AMS-IX sites, and lots of routers. Even though Amsterdam (and AMS-IX) is a major hub for european connections, most worked as usual, though some Dutch destinations has higher than normal delay and packet loss. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Senior network engineer @ AS3292, TDC Tele Danmark One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
Re: Simulated disaster exercise? Re: PAIX
On Sun, 17 Nov 2002, Richard A Steenbergen wrote: The usual response was it only affected the public exchange fabric, not any private point-to-point circuits between providers through the same facility. But if we're going to compare this to MAE Gigaswitch failures, shouldn't we be talking apples to apples and oranges to oranges? No. The world has changed. If people are buying tangerines and grapefruit now, that's what we should be talking about, not apples and oranges. If most of today's Internet exchange is via private connections, those are the connections we should be looking at. The fine folks at Caimis and Caida have done some analysis, and identified the nodes which make up the core of the Internet. They've also identified the most connected core nodes. The good news is the network doesn't go non-linear until more than 25% of the nodes are removed.
Re: PAIX
On Fri, 15 Nov 2002, Jere Retzer wrote: Some thoughts: - Coast-to-coast guaranteed latency seems too low in most cases that I've seen. Not calling CEOs and marketers liars but the real world doesn't seem to do as well as the promises. As VOIP takes off local IP exchanges will continue/increase in importance because people won't tolerate high latency. What percentage of your phone calls are local? Who cares? Voice is only 56 or so kbps. Just give it absolute queueing priority, and suddenly you have negligible jitter... - Yes, we do various kinds of video over Internet2. People are doing various kinds of video over Internet 1; works fine. - While we're on the topic of local video, what happens when television migrates to IP networks? Why should it? There's a cheap, ubiquitous, widely deployed broadcasting medium already. I never understood network integration for the sake of network integration. In any case, TV (of all things) does not have problems with latency or jitter below 10s of seconds. All TV content is pre-packaged. --vadim
Re: PAIX
- While we're on the topic of local video, what happens when television migrates to IP networks? Why should it? There's a cheap, ubiquitous, widely deployed broadcasting medium already. I never understood network integration for the sake of network integration. That medium only works for large audiences. It does not address geographically large sparse audiences at all. In any case, TV (of all things) does not have problems with latency or jitter below 10s of seconds. All TV content is pre-packaged. Live events and interactive show's are not. In some cases you start to suffer if your latency goes to multiple-seconds range. That's quite rare anyway, 500ms network latency is quite rare and add few hundred codec and de-jitter latency and you'll find that excessive jitter is your enemy, not the latency itself. Pete
Re: PAIX
- While we're on the topic of local video, what happens when television migrates to IP networks? Why should it? There's a cheap, ubiquitous, widely deployed broadcasting medium already. I never understood network integration for the sake of network integration. Primarily because it is not interactive. The ones that are interactive are not ubiquotous. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: PAIX
speaking of paix, for those of you in atlanta (ietf) this week, i'm going to do a couple of site walkthroughs. send me e-mail if interested. -- Paul Vixie
Simulated disaster exercise? Re: PAIX
In the 1990's the MAEs and Gigaswitches would give us an unscheduled failure of a major exchange point on a regular basis, which let us demostrate our disaster recovery capabilities. With the improved reliability, i.e. the PAIXes haven't had a catastrophic failure, we haven't had as many opportunities to demonstrate how well we can handle a disaster at those locations. Without creating an actual disaster, what if all the providers turned off their BGP sessions with other providers at a PAIX (or Equinix or LINX or where ever), both through the shared switch and private point-to-point links, for an hour. More than likely no one would notice, but then we would have some hard data. Individually providers have tested parts of their own network, but I haven't heard of any coordinated efforts to test recovery across all the service providers in a particular location.
Re: Simulated disaster exercise? Re: PAIX
On Sat, 16 Nov 2002, Sean Donelan wrote: In the 1990's the MAEs and Gigaswitches would give us an unscheduled failure of a major exchange point on a regular basis, which let us demostrate our disaster recovery capabilities. With the improved reliability, i.e. the PAIXes haven't had a catastrophic failure, we haven't had as many opportunities to demonstrate how well we can handle a disaster at those locations. Without creating an actual disaster, what if all the providers turned off their BGP sessions with other providers at a PAIX (or Equinix or LINX or where ever), both through the shared switch and private point-to-point links, for an hour. More than likely no one would notice, but then we would have some hard data. Individually providers have tested parts of their own network, but I haven't heard of any coordinated efforts to test recovery across all the service providers in a particular location. The main problem will be coordination.. you need to get all providers to do this in a tight slot of only one hour. And to make this a good test you need to ensure that all the major players take part more so than the smaller ISPs. From what I've seen its difficult enough to get ISPs to make config changes within a window of a couple of weeks so you're gonna have a problem pulling this together! Also from what I've seen I'll think you'll find things have changed, reduced budgets have forced compromises on redundancy and shutting down an exchange will have a noticable impact to users in the region... you could argue this is all the more reason to conduct these exercises! Steve
Re: Simulated disaster exercise? Re: PAIX
On Sat, Nov 16, 2002 at 08:45:07PM -0500, Sean Donelan wrote: With the improved reliability, i.e. the PAIXes haven't had a catastrophic failure, we haven't had as many opportunities to demonstrate how well we can handle a disaster at those locations. July 31st 2002, this list: 2121 Jul 31 Herb Leong ( 4) Is the PAIX Palo Alto taking a dump? How quickly we forget. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Simulated disaster exercise? Re: PAIX
On Sat, 16 Nov 2002, Richard A Steenbergen wrote: July 31st 2002, this list: 2121 Jul 31 Herb Leong ( 4) Is the PAIX Palo Alto taking a dump? How quickly we forget. :) The usual response was it only affected the public exchange fabric, not any private point-to-point circuits between providers through the same facility.
Re: Simulated disaster exercise? Re: PAIX
On Sat, Nov 16, 2002 at 10:00:07PM -0500, Sean Donelan wrote: On Sat, 16 Nov 2002, Richard A Steenbergen wrote: July 31st 2002, this list: 2121 Jul 31 Herb Leong ( 4) Is the PAIX Palo Alto taking a dump? How quickly we forget. :) The usual response was it only affected the public exchange fabric, not any private point-to-point circuits between providers through the same facility. But if we're going to compare this to MAE Gigaswitch failures, shouldn't we be talking apples to apples and oranges to oranges? -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: PAIX
On Thu, 14 Nov 2002 12:36:54 -0500 David Diaz wrote: People seem to prefer cost of quality at this time. Good Fast Cheap Honey, part of our success is that I don't accept the above. Sooner or later, you will have to compete with someone who believes: Good Fast Cheap we do all three. When one really knows one's field, it is possible to design simple systems. In the networking world, the qualities simple bring are: Good (reliable), Fast, Cheap. In a field where people think that it is perfectly acceptable to run MPLS through a NAT connected via PPP over Ethernet over ATM, it isn't harder to be simpler than the competition. good luck, fletcher
Re: PAIX
On Thu, 14 Nov 2002 14:48:17 -0800 (PST) [EMAIL PROTECTED] wrote: Its possible/likely that what Paul is saying may happen, but it requires a lot of locality-specific high-bandwidth applications (none exist now or in demand now) and technologies that make it possible (cost-effective) to manage such complex peering network for a very large network Should be modified to say none exists in the market in which [william] is familiar. regards, fletcher
Re: PAIX
Anyone that calls me honey is in question. It's standard, you cant have everything in life. You attempt to achieve all three however it's all relative. You can have a DSL line now instead of a T1, it's fast and cheap but most arent as good as a T1 and the SLAs arent there right? Usually you either build your network to one of two designed: Avg sustained traffic levels, or Peak traffic levels. Avg sustained means that during peak times you might have higher latency, but that you have not over bought capacity... Peak Traffic design means you looked at your max burst levels and bought enough capacity etc to handle that load. The rest of the time you have excess capacity, but your QoS is always great. You will have a higher costs basis here. We all strive for all three, I used to almost try a TDM approach. Where I would try and balance business day users, residential users, and backup service users on the network. They used 3 distinct time frames during the day. In this way the network was rarely idle, but each type of users peak time was not in conflict with another. So if you would like to say you can sell me an OC48 at Aleron's (or fill in the ISPs name) IP backbone quality, at Cogent's pricing of less then $30meg... great... At 9:55 -0500 11/15/02, [EMAIL PROTECTED] wrote: On Thu, 14 Nov 2002 12:36:54 -0500 David Diaz wrote: People seem to prefer cost of quality at this time. Good Fast Cheap Honey, part of our success is that I don't accept the above. Sooner or later, you will have to compete with someone who believes: Good Fast Cheap we do all three. When one really knows one's field, it is possible to design simple systems. In the networking world, the qualities simple bring are: Good (reliable), Fast, Cheap. In a field where people think that it is perfectly acceptable to run MPLS through a NAT connected via PPP over Ethernet over ATM, it isn't harder to be simpler than the competition. good luck, fletcher
Re: PAIX
Warning , this post won't configure a router. [EMAIL PROTECTED] wrote: On Thu, 14 Nov 2002 12:36:54 -0500 David Diaz wrote: People seem to prefer cost of quality at this time. Good Fast Cheap Honey, part of our success is that I don't accept the above. Sooner or later, you will have to compete with someone who believes: Good Fast Cheap we do all three. Huh, must be in marketing or sales, perhaps a CEO, even. * shrug * Hey, while we are at it, What is the difference between a Suit and an Engineer ? The Engineer -knows- when he is lying. :P Now, the Honey comment ? Sounds like a rather sticky wicket, not my style, I think I'll pass. However, You -=can=- tell the poster isn't from Baltimore, though... I think I heard once that the Baltimore City slogan is Welcome Home, Hon! :D router Conf t router # silobeth.shilobeth...seilobath... router # oh, forget it! router # ^Z :\ morning coffee I know, Susan... I know. I won't quit my day job. Exiting, stage left. ... .. . (No offense intended to anyone, really...) (just lightening up the conversation) (C'Ya)
Re: PAIX
On Fri, 15 Nov 2002 11:42:46 -0500 Richard Irving wrote: Huh, must be in marketing or sales, perhaps a CEO, even. Yup, I am a CEO. I am also (still) one of the most experienced and best educated IP engineers around. It is fun being CEO. Rather than throw stones, you might want to celebrate the fact that being CEO is now on the career path of an engineer. The Engineer -knows- when he is lying. Well, I don't know about that. Engineers are without a doubt the most active class of liar I know (but then, I don't get out much.) Some times I feel like it is real hard for engineers to know when they are telling the truth. I do know that it has been a a great professional boon to have an IP engineering background and know when I am having smoke blown at me by other engineers. Dilbert, a cartoon about engineers, is so funny because it is so true. In the final analysis, Dilbert is as much of a weasel as any of the other characters. regards, fletcher
Re: PAIX
On Fri, 15 Nov 2002 11:20:36 EST, [EMAIL PROTECTED] said: relatively cheap. I know our costs are lower and quality is higher than our competitors and I believe the reason is that we go for a simple network designed around cheap routers and fat pipes. We made OK. I'll bite. What do you define as a cheap router, and just as important, what counts as a fat pipe where you are? You didn't choose the well-known router line from the well-known vendor(*) that handles line-speed packets, as long as you don't even whisper ingress filtering within it's hearing, did you? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech (*) Yes, there's multiple answers to this one. msg06725/pgp0.pgp Description: PGP signature
Re: PAIX
[EMAIL PROTECTED] wrote: Yup, I am a CEO. 1-900-psy-kick Call now, Mon, we're a waiting for ya! I am also (still) one of the most experienced and best educated IP engineers around. And humble, too. :\ [Said to a list where Van Jacobson and Vixie have been known to lurk] Dilbert, a cartoon about engineers, is so funny because it is so true. In the final analysis, Dilbert is as much of a weasel as any of the other characters. Admit it, You just like his Tie! :P On a more serious note, FWIW, did you know PacBell was the source of Scott's Inspiration ? He worked on some of the first privately available ISDN lines... and attended some of the earliest public NANOG's. He said after working there for almost 10 years, he decided it was Suicide, or Dilbert. The Rest is History. :D http://www.dilbert.com/comics/dilbert/news_and_history/html/about_scott_adams.html .cheers. Hey, I just realized that DogBert and Pres Bush are both short... Coincidence ? http://www.dilbert.com/comics/dilbert/news_and_history/images/origin4.gif regards, fletcher lurk mode on Susan, put down that keyboard... I am moving on...promise.
Re: PAIX
On Fri, 15 Nov 2002 14:37:08 -0500 [EMAIL PROTECTED] wrote: relatively cheap. I know our costs are lower and quality is higher than our competitors and I believe the reason is that we go for a simple network designed around cheap routers and fat pipes. We made OK. I'll bite. What do you define as a cheap router, and just as important, what counts as a fat pipe where you are? Cheap is defined as the undepreciated Ciscos that UUnet threw out when the lyin' backbone engineers sold management the MPLS bill-of-goods in the late nineties. [ Why buy Juniper when you can get second-hand Cisco gear for almost free? ] Fat is 4 OC3s for uplinks at ~$200 per megabit and gigabit for internal at about $40 per fiber mile per month. This is consumer service in Northern New England. At those prices, it is far cheaper to overbuy than over-complicate. Naturally, in different geographic areas and different market niches your mileage may vary. Or at least offer an excuse to ignore me. You didn't choose the well-known router line from the well-known vendor(*) that handles line-speed packets, as long as you don't even whisper ingress filtering within it's hearing, did you? Whispering is not exactly my style. regards, fletcher
Re: PAIX
Some thoughts: - Coast-to-coast "guaranteed latency" seems too low in most cases that I've seen. Not calling CEOs and marketers liars but the real world doesn't seem to do as well as the promises. As VOIP takes off "local" IPexchanges will continue/increase in importance because people won't tolerate high latency. What percentage of your phone calls are local? - Yes, we do various kinds of video over Internet2. Guess what? Packet loss isvery important.Fewer hops mean fewer lost packets. Local exchanges, if there were lots of them with lots of peering reduces the theoretical number of hops. Who will most of the videoconferences involve in the future I think mostly people who see each other face-to-face periodically. Leading this are telework and telemed. Broadband is getting to the point that people will want to call up their doc/clinic rather than jump in the car just to be told to go home and go to bed, and get exposed to someone who has a contagious disease. Nursing homes, assisted living facilities, emergency rooms in malltownsshould be key targets for this technology. - While we're on the topic of local video, what happens when television migrates to IP networks? Seems like the "local" newsshould want to originate somewhere close. Most of our local TV and radio stations are part of chain today and their corporate headquarters have decided to host their web site at a central location without even worrying about Akamai or other local caching. - Unfortunately, these applications do not work with today's local broadband networks one reason being the lack of local interconnection. People have quit believing the Radio Shack ads. We have the technology to make these applications work if we'd stop arguing that no one wants to use them. Of course no one wants to use them they know they won't work! David Diaz [EMAIL PROTECTED] 11/14/02 05:52PM Voice of reason...The only possible reason I can think of is if these data networks replace the present voice infrastructure. Think about it, if we really all do replace our phones with some video screen like in the movies, then yes, most of those calls stay local within the cities. Mom calling son etc etcSo we can think of these "peering centers" as replacements for the 5-10 COs in most average cities.Otherwise what apps require such dense peering.At 14:44 -0800 11/14/02, Vadim Antonov wrote:On Thu, 14 Nov 2002, David Diaz wrote: 2) There is a lack of a killer app requiring peering every 100 sq Km.Peering every 100 sq km is absolutely infeasible. Just think of thenumber of alternative paths routing algorithms wil lhave to consider.Anything like that would require serious redesign of Internet's routingarchitecture.--vadim
Re: PAIX
Title: Re: PAIX At 16:01 -0800 11/15/02, Jere Retzer wrote: Content-Type: text/html; charset=ISO-8859-7 Content-Description: HTML Some thoughts: - Coast-to-coast guaranteed latency seems too low in most cases that I've seen. Not calling CEOs and marketers liars but the real world doesn't seem to do as well as the promises. As VOIP takes off local IPexchanges will continue/increase in importance because people won't tolerate high latency. What percentage of your phone calls are local? Well the bingo latency number used a lot in voice is 50ms. Im simplifing without getting into all the details, but that's an important number. As far as VoIP goes, I think higher latency is ok, it's more important to have consistent latency. Fluctuating latency really affects VoIP more then a higher consistent latency. There are a lot of people doing VoIP and traditional voice on satellites and the latency there is huge. Coast to coast latency on a good network is ~45 - 65ms depending on which customers you talk to. Most phone calls are local as I mentioned in an earlier post so I do agree with you here that it would be a replacement for the traditional CO. - Yes, we do various kinds of video over Internet2. Guess what? Packet loss isvery important.Fewer hops mean fewer lost packets. Local exchanges, if there were lots of them with lots of peering reduces the theoretical number of hops. Who will most of the videoconferences involve in the future I think mostly people who see each other face-to-face periodically. Leading this are telework and telemed. Broadband is getting to the point that people will want to call up their doc/clinic rather than jump in the car just to be told to go home and go to bed, and get exposed to someone who has a contagious disease. Nursing homes, assisted living facilities, emergency rooms in malltownsshould be key targets for this technology. Fewer hops = less packet loss? There has been a lot of discussion on the list about that. I still dont see it although it does push latency up a bit. Truth is that there are a lot of tunnels or express routes build in, so we arent seeing all the hops nowadays. I think that's more for sales and marketing as people keep judging networks by hops in a traceroute. - While we're on the topic of local video, what happens when television migrates to IP networks? Seems like the local newsshould want to originate somewhere close. Most of our local TV and radio stations are part of chain today and their corporate headquarters have decided to host their web site at a central location without even worrying about Akamai or other local caching. An IP backbone is a bad place for live TV. Delayed or on demand tv yes. Live tv plays to the benefits of One to Many broadcast ability of satellite as Doug Humphrey will tell you. So a feed from a DSS dish into your local cache would work well. It still can be done at a per city peering point to better feed the broadband users. Its the simplest solution probably although I know someone will mention multicast here... Actually I find it interesting that the movie industry is taking the initiative and putting up a website to do streaming movies for free to users. They are trying to learn from the mistakes of the music industry. Perhaps this is the killer app since it's one to one transmission over the IP backbone. It would be ironic if hollywood trying to avoid video theft drove peering and IP growth interesting world we live in. Have a nice weekend. dd - Unfortunately, these applications do not work with today's local broadband networks one reason being the lack of local interconnection. People have quit believing the Radio Shack ads. We have the technology to make these applications work if we'd stop arguing that no one wants to use them. Of course no one wants to use them they know they won't work! David Diaz [EMAIL PROTECTED] 11/14/02 05:52PM Voice of reason... The only possible reason I can think of is if these data networks replace the present voice infrastructure. Think about it, if we really all do replace our phones with some video screen like in the movies, then yes, most of those calls stay local within the cities. Mom calling son etc etc So we can think of these peering centers as replacements for the 5-10 COs in most average cities. Otherwise what apps require such dense peering. At 14:44 -0800 11/14/02, Vadim Antonov wrote: On Thu, 14 Nov 2002, David Diaz wrote: 2) There is a lack of a killer app requiring peering every 100 sq Km. Peering every 100 sq km is absolutely infeasible. Just think of the number of alternative paths routing algorithms wil lhave to consider. Anything like that would require serious redesign of Internet's routing architecture. --vadim
Re: PAIX
- Coast-to-coast guaranteed latency seems too low in most cases that = I've seen. Not calling CEOs and marketers liars but the real world doesn't = seem to do as well as the promises. As VOIP takes off local IP exchanges = will continue/increase in importance because people won't tolerate high = latency. What percentage of your phone calls are local? Those guarantees typically have nothing to do with actual service delivery. The test is what exception conditions are identified in the service level agreement, and the details of how the latency number is measured. Is it a direct measurement that can be independently and instantaneously verified, or is it a POP-POP number that uses techniques like averaging over a month or omitting the customer edge portion of the infrastructure in order to engineer a number that (a) looks impressive and (b) will never be violated even in the face of major outages. Which is worse - the marketeers that invent performance fiction like that, or the customers who go chasing after a lower number without any analysis of how that number is determined? Stephen
Re: PAIX
I'm putting the number closer to 40 (the NFL cities) right now, and 150 by the end of the decade, and ultimately any metro with population greater than 50K in a 100 sq Km area will need a neutral exchange point (even if it's 1500 sqft in the bottom of a bank building.) What application will require this dense peering? Pete
Re: PAIX
PV Date: 14 Nov 2002 05:14:30 +
PV From: Paul Vixie
[ re number of US exchange points ]
DD Right now seems domestically 6 may be all we need.
PV I'm putting the number closer to 40 (the NFL cities) right
PV now, and 150 by the end of the decade, and ultimately any
PV metro with population greater than 50K in a 100 sq Km area
PV will need a neutral exchange point (even if it's 1500 sqft in
PV the bottom of a bank building.)
Are we discussing:
1) locations primarily for peering between large carriers, or
2) carrier hotels including virtually all providers, where cheap
faste/gige peering runs are easily justified?
If #1, I agree with David. In the case of the latter, I think I
see what Paul is saying. IMESHO, local/longhaul price imbalance
and the growth of distributed hosting {would|will} help fuel the
smaller exchanges.
Eddy
--
Brotsman Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita
~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to [EMAIL PROTECTED], or you are likely to
be blocked.
Re: PAIX
I'm putting the number closer to 40 (the NFL cities) right now, and 150 by the end of the decade, and ultimately any metro with population greater than 50K in a 100 sq Km area will need a neutral exchange point (even if it's 1500 sqft in the bottom of a bank building.) What application will require this dense peering? today, we need this dense peering to keep local traffic local just with apps that folks already run. kazaa and gaming are examples where isochrony or high volume bidirectional peer-to-peer traffic are already present, but the fact is that hub spoke is a better topology for a metro than for a region, even where http/smtp/ftp are still the primary applications. going forward, movies on demand and other things that we currently use satellites or cable TV systems for. voip. internet-delivered radio, using things like 802.11 and bluetooth as the last mile. i want a Dick Tracy wristwatch and i know that thousands of other people will want it too and i can do the arithmetic to see that there will be more than one (probably more than several) providers per metro, even in small metros, and that if their closest exchange point is in some other metro, it can't take off. someone mentioned SIX. but a peering switch does not an exchange point make. without a PNI upgrade path, which means a certain amount of hard colo, the ceiling is too low. (that's one reason why ATM-based metro exchanges are not growing very fast, and why nobody is building new ones any more.)
Re: PAIX
Well thanks for the agreement Ed.
Philosophically, I agree with Paul. I think 40 exchange points would
be a benefit. At this time though, there is no model that would
support it.
1) Long haul circuits are dirt cheap. Meaning distance peering
becomes more attractive. L3 also has an MPLS product so you pay by
the meg. I am surprised a great many peers are using this. But
apparently CFOs love it
2) There is a lack of a killer app requiring peering every 100 sq Km.
VoIP might be the app. Seems to be gaining a great deal of traction.
Since it's obvious traffic levels would sky rockets, and latency is a
large concern, and there is a need to connect to the local voice TDM
infrastructure, local exchanging is preferred. However, many VoIP
companies claim latency right now is acceptable and they are
receiving no major complaints. So we are left to guess at other
killer apps, video conferencing, movie industry sending movies online
directly to consumers etc.
3) In order to get to the next level of peering exchanges... from 6
major locations to 12 we are going to need the key peers in those
locations. Many dont want to manage that growing complexity for
diminishing returns, as well as the increased cost in equipment.
Perhaps it's up to the key exchange companies to tie fabrics together
allowing new (tier2 locations) to gain visibility to peers at other
larger locations. This would allow peers at the larger locations to
engage in peering discussions, or turn ups, and when traffic levels
are justified a deployment to the second location begins. Problem
with new locations are 'chicken and the egg.' Critical mass must be
achieved before there is a large value proposition for peers.
And to everyone that emailed me with their we also are an exchange
email. Yes, I readily admit there are other companies doing peering
besides the ones I mentioned. I just did a quick post so I did not
list every single exchange company. So you have my apologies, and I
wont even hold it against you all that you were sales people
dave
At 9:52 + 11/14/02, E.B. Dreger wrote:
PV Date: 14 Nov 2002 05:14:30 +
PV From: Paul Vixie
[ re number of US exchange points ]
DD Right now seems domestically 6 may be all we need.
PV I'm putting the number closer to 40 (the NFL cities) right
PV now, and 150 by the end of the decade, and ultimately any
PV metro with population greater than 50K in a 100 sq Km area
PV will need a neutral exchange point (even if it's 1500 sqft in
PV the bottom of a bank building.)
Are we discussing:
1) locations primarily for peering between large carriers, or
2) carrier hotels including virtually all providers, where cheap
faste/gige peering runs are easily justified?
If #1, I agree with David. In the case of the latter, I think I
see what Paul is saying. IMESHO, local/longhaul price imbalance
and the growth of distributed hosting {would|will} help fuel the
smaller exchanges.
Eddy
--
Brotsman Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita
~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to [EMAIL PROTECTED], or you are likely to
be blocked.
--
David Diaz
[EMAIL PROTECTED] [Email]
[EMAIL PROTECTED] [Pager]
Smotons (Smart Photons) trump dumb photons
Re: PAIX
On Thu, 14 Nov 2002 10:22:09 -0500 David Diaz wrote: 2) There is a lack of a killer app requiring peering every 100 sq Km. David; I recommend some quality time with journals covering South Korea, broadband, online gaming and video rental. regards, fletcher
Re: PAIX
Thus spake [EMAIL PROTECTED] On Thu, 14 Nov 2002 10:22:09 -0500 David Diaz wrote: 2) There is a lack of a killer app requiring peering every 100 sq Km. David; I recommend some quality time with journals covering South Korea, broadband, online gaming and video rental. Current peering levels suggest that it is cheaper to haul the traffic to a dozen or so points than it is to manage peering at several hundred points. Wasting bandwidth is a lot cheaper than wasting humans. S
Re: PAIX
Wired covered several of these topics in their August issue. http://www.wired.com/wired/archive/10.08/korea.html The article points out several subtle, yet fundamental, changes that happen socially and psychologically once the broadband network is available everywhere, to virtually everyone, all the time. We have yet to experience this in the US. I suspect that when it happens, it will be much different than we expect it to be, technically and otherwise. We still have to remember that for all the hype about the Internet, the killer app is still email and instant messenging. The killer apps on Internet2 (video conferencing, digital libraries, media-rich collaboration), which give some indication of what the future killer app will be, seem to be equally mundane (but exciting at the same time). Pete. On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote: On Thu, 14 Nov 2002 10:22:09 -0500 David Diaz wrote: 2) There is a lack of a killer app requiring peering every 100 sq Km. I recommend some quality time with journals covering South Korea, broadband, online gaming and video rental.
Re: PAIX
Still seems that none of these requires peering every 100 km. Latency is still not a factor in this case. People seem to prefer cost of quality at this time. Good Fast Cheap Pick any two. As far as digital libraries and content and such... proxies and caches would fill the roll here. Akamai content servers or caches fed by something akin to Cidera's satellite feed to your caches [sitting on your network] would fill the need quite nicely. Local peering has 2 benefits right now: 1) reducing network costs (transit and backbone band) 2) decreasing latency Right now these two benefits are in not a factor in the present environment in my opinion At 10:22 -0700 11/14/02, Pete Kruckenberg wrote: Wired covered several of these topics in their August issue. http://www.wired.com/wired/archive/10.08/korea.html The article points out several subtle, yet fundamental, changes that happen socially and psychologically once the broadband network is available everywhere, to virtually everyone, all the time. We have yet to experience this in the US. I suspect that when it happens, it will be much different than we expect it to be, technically and otherwise. We still have to remember that for all the hype about the Internet, the killer app is still email and instant messenging. The killer apps on Internet2 (video conferencing, digital libraries, media-rich collaboration), which give some indication of what the future killer app will be, seem to be equally mundane (but exciting at the same time). Pete. On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote: On Thu, 14 Nov 2002 10:22:09 -0500 David Diaz wrote: 2) There is a lack of a killer app requiring peering every 100 sq Km. I recommend some quality time with journals covering South Korea, broadband, online gaming and video rental. -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] Smotons (Smart Photons) trump dumb photons
Re: PAIX
Used to be when it first came out, Wired was a mag the best quality printing on no substance I had ever seen, really seemed like a borderline artist mag. The colors were amazing. I see now, upon looking at a recent issue, their content seems to have improved dramatically. Brian - Original Message - From: Pete Kruckenberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 9:22 AM Subject: Re: PAIX Wired covered several of these topics in their August issue. http://www.wired.com/wired/archive/10.08/korea.html The article points out several subtle, yet fundamental, changes that happen socially and psychologically once the broadband network is available everywhere, to virtually everyone, all the time. We have yet to experience this in the US. I suspect that when it happens, it will be much different than we expect it to be, technically and otherwise. We still have to remember that for all the hype about the Internet, the killer app is still email and instant messenging. The killer apps on Internet2 (video conferencing, digital libraries, media-rich collaboration), which give some indication of what the future killer app will be, seem to be equally mundane (but exciting at the same time). Pete. On Thu, 14 Nov 2002 [EMAIL PROTECTED] wrote: On Thu, 14 Nov 2002 10:22:09 -0500 David Diaz wrote: 2) There is a lack of a killer app requiring peering every 100 sq Km. I recommend some quality time with journals covering South Korea, broadband, online gaming and video rental.
Re: PAIX
DD Date: Thu, 14 Nov 2002 10:22:09 -0500 DD From: David Diaz DD 1) Long haul circuits are dirt cheap. Meaning distance DD peering becomes more attractive. L3 also has an MPLS product DD so you pay by the meg. I am surprised a great many peers are DD using this. But apparently CFOs love it Uebercheap longhaul would _favor_ the construction of local exchanges. Let's say I pay $100k/mo port and $10M/mo loop... obviously, I need to cut loop cost. If an exchange brings zero-mile loops to the table, that should reduce loop cost. Anyone serious will want a good selection of providers, and the facility offering the most choices should be sitting pretty. Likewise, I agree that expensive longhaul would favor increased local peering... but, if local loop were extremely cheap, would an exchange be needed? It would not be inappropriate for all parties to congregate at an exchange, but I'd personally rather run N dirt-cheap loops across town from my private facility. Hence I refer to an imbalance in loop/longhaul pricing; a large proliferation in exchanges could be precipitated by _either_ loop _or_ longhaul being expensive... and it seems expensive loop would be a more effective driver for local exchanges. DD 2) There is a lack of a killer app requiring peering every DD 100 sq Km. VoIP might be the app. Seems to be gaining a minirant By the time IP packets are compressed and QOSed enough to support voice, one essentially reinvents ATM or FR (with ATM seeming suspiciously like FR with fixed-length cells)... /minirant DD great deal of traction. Since it's obvious traffic levels DD would sky rockets, and latency is a large concern, and there DD is a need to connect to the local voice TDM infrastructure, Yes, although cost would trump latency. Once latency is good enough, cost rules. Would I pay a premium to reduce latency from 50ms to 10ms for voice calls? No. DD local exchanging is preferred. However, many VoIP companies DD claim latency right now is acceptable and they are receiving DD no major complaints. So we are left to guess at other killer DD apps, video conferencing, movie industry sending movies DD online directly to consumers etc. The above are big bandwidth applications. However, they do not inherently require exchanges... _local_ videoconferencing, yes. Local security companies monitoring cameras around town, yes. Video or newscasting, yes. Distributed content, yes. (If a traffic sink could pull 80% of its traffic from a local building where cross-connects are reasonably priced...) DD 3) In order to get to the next level of peering exchanges... [ snip ] DD Perhaps it's up to the key exchange companies to tie fabrics DD together allowing new (tier2 locations) to gain visibility to DD peers at other larger locations. This would allow peers at DD the larger locations to engage in peering discussions, or DD turn ups, and when traffic levels are justified a deployment DD to the second location begins. Problem with new locations DD are 'chicken and the egg.' Critical mass must be achieved DD before there is a large value proposition for peers. Yes. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: PAIX
At 18:31 + 11/14/02, E.B. Dreger wrote: DD Date: Thu, 14 Nov 2002 10:22:09 -0500 DD From: David Diaz DD 1) Long haul circuits are dirt cheap. Meaning distance DD peering becomes more attractive. L3 also has an MPLS product DD so you pay by the meg. I am surprised a great many peers are DD using this. But apparently CFOs love it Uebercheap longhaul would _favor_ the construction of local exchanges. Let's say I pay $100k/mo port and $10M/mo loop... obviously, I need to cut loop cost. If an exchange brings zero-mile loops to the table, that should reduce loop cost. Anyone serious will want a good selection of providers, and the facility offering the most choices should be sitting pretty. This is an interesting and good point, but any carrier hotel provides the same thing. Likewise, I agree that expensive longhaul would favor increased local peering... but, if local loop were extremely cheap, would an exchange be needed? It would not be inappropriate for all parties to congregate at an exchange, but I'd personally rather run N dirt-cheap loops across town from my private facility. Hence I refer to an imbalance in loop/longhaul pricing; a large proliferation in exchanges could be precipitated by _either_ loop _or_ longhaul being expensive... and it seems expensive loop would be a more effective driver for local exchanges. Tried this. Yes you are right, problem is local loops are sometimes extremely difficult to get delivered in a timely manner and upgrading them can be an internal battle with the CFO. To solve this, we deployed the Bellsouth mix. I actually came up with the idea while have a terrible time getting private peering sessions up while at Netrail. 6months was a ridiculous timeframe. Bellsouth liked it and deployed it, eventually. So now you have a distributed optical exchange where you can point and click and drop circuits btw any of the nodes; nodes were located at many colos and undersea fiber drops. Theoretically this meant the exchange was colo neutral. With flat rate loops it meant location wasnt important. Each node also allows for hairpinning so you could do peering within the room at a reduced rate (since u werent burning any ring-side capacity). The neat part was that customers would be able to see and provision their own capacity via a login and pwd. Also, with UNI 1.0, the IP layer would be able to upgrade capacity on the fly. No one has put that into production but real world test have worked. In reality a more realistic scenario was the ability of a customer to upgrade from an OC3 to an OC12. The ports were the same so it was just a setting on the NMS to change. It was a nice feature and meant engineers did now have to justify ESP feelings on how traffic would grow to a grouchy CFO. DD 2) There is a lack of a killer app requiring peering every DD 100 sq Km. VoIP might be the app. Seems to be gaining a minirant By the time IP packets are compressed and QOSed enough to support voice, one essentially reinvents ATM or FR (with ATM seeming suspiciously like FR with fixed-length cells)... /minirant DD great deal of traction. Since it's obvious traffic levels DD would sky rockets, and latency is a large concern, and there DD is a need to connect to the local voice TDM infrastructure, Yes, although cost would trump latency. Once latency is good enough, cost rules. Would I pay a premium to reduce latency from 50ms to 10ms for voice calls? No. I agree. A couple off-list emails to me did not seem to understand this. Just because we post something does not mean it's our personal pref, it's just we are posting the reality of what will likely happen in our opinion. If there is not a competitive advantage, backed up by reduced cost or increased revenue, it would be a detriment to deploy it... more likely a CFO would shoot it down. Someone sent an example as if I am making the statement no one needs more then 640k of ram on their computer. Never made that analogy, but there is a limit. It also seems to me that shared supercomputer time is making a come back. IBM seems to be pushing in that direction, and there are several grid networks being setup. The world changes. Let's face it. Has anyone talked about the protocols to run these super networks? Where we have something like 100-400 peering nodes domestically? Injecting those routes into our IGP? Talk about a complex design... now we need to talk about tricks to prevent the overflow of our route tables internally... ok I can here people getting ready to post stuff about reflectors etc. Truth is, it's just plain difficult to hit critical mass at a new exchange point. No one wishes to be 1st since there is little return. Perhaps these exch operators need to prime the pump by offered tiered rates, the 1st 1/3 of peers deploying coming in at a permanent 50% discount. DD local exchanging is preferred. However, many VoIP companies DD claim
Re: PAIX
Thus spake E.B. Dreger [EMAIL PROTECTED] DD 1) Long haul circuits are dirt cheap. Meaning distance DD peering becomes more attractive. L3 also has an MPLS product DD so you pay by the meg. I am surprised a great many peers are DD using this. But apparently CFOs love it Uebercheap longhaul would _favor_ the construction of local exchanges. Incorrect. Cheap longhaul favors a few centralized exchanges. If there is no economic value in keeping traffic local, it is in carriers' interests to minimize the number of peering points. Let's say I pay $100k/mo port and $10M/mo loop... obviously, I need to cut loop cost. If an exchange brings zero-mile loops to the table, that should reduce loop cost. Anyone serious will want a good selection of providers, and the facility offering the most choices should be sitting pretty. Most vendor-neutral colos have cheap zero-mile loops. Likewise, I agree that expensive longhaul would favor increased local peering... but, if local loop were extremely cheap, would an exchange be needed? It would not be inappropriate for all parties to congregate at an exchange, but I'd personally rather run N dirt-cheap loops across town from my private facility. What is the cost of running N loops across town, vs. the cost of pushing that traffic to a remote peering location and back? Be sure to include equipment, maintenance, and administrative costs, not just circuits. The above are big bandwidth applications. However, they do not inherently require exchanges... _local_ videoconferencing, yes. Local security companies monitoring cameras around town, yes. Video or newscasting, yes. None of these applications require local exchanges. There is a slight increase in end-to-end latency when you must use a remote exchange, but very few applications care about absolute latency -- they only care about bandwidth and jitter. Distributed content, yes. (If a traffic sink could pull 80% of its traffic from a local building where cross-connects are reasonably priced...) Distributed content assumes the source is topologically close to the sink. The most cost-efficient way to do this is put sources at high fan-out areas, as this gets them the lowest _average_ distance to their sinks. This doesn't necessarily mean that putting a CNN mirror in 100,000 local exchanges is going to reduce CNN's costs. S
Re: PAIX
SS Date: Thu, 14 Nov 2002 13:32:55 -0600
SS From: Stephen Sprunk
SS Incorrect. Cheap longhaul favors a few centralized
SS exchanges. If there is no economic value in keeping traffic
SS local, it is in carriers' interests to minimize the number of
SS peering points.
True. However, cheap longhaul / expensive local means providers
_will_ try to reduce loop costs, favoring carrier hotels.
SS Most vendor-neutral colos have cheap zero-mile loops.
Correct. In my original post... are we discussing #1 or #2? It
seems as if #2. Where are we drawing the line between carrier
hotel and exchange? I believe Paul was being perhaps more
nebulous than today's definition of exchange when he referenced
1500 sq-ft in-bottom-of-bank-building facilities.
SS What is the cost of running N loops across town, vs. the cost
SS of pushing that traffic to a remote peering location and
SS back? Be sure to include equipment, maintenance, and
SS administrative costs, not just circuits.
It depends.
SS None of these applications require local exchanges. There is
SS a slight increase in end-to-end latency when you must use a
SS remote exchange, but very few applications care about
SS absolute latency -- they only care about bandwidth and
SS jitter.
With bounded latency and acceptable typical throughput, one
seeks to minimize jitter and cost. Jitter is caused by variable
queue time, which is due to buffering, which is a side-effect of
statmuxed traffic w/o strict { realtime delivery constraints |
QoS | TDM-ish architecture }... yes. And N^2 makes full-mesh
irresponsible when attempting to maximize bandwidth... yes.
(I think buying full transit from 10 providers is well beyond
the point of diminishing return; no offense to INAP.)
Again... if loop is expensive, and providers are concentrated in
carrier hotels with reasonably-priced xconns... when does it
become an exchange? Note that some exchanges do not provide a
switch fabric, but rather run xconns.
Sure, one must factor in all the costs. The breakeven point
varies, if it exists at all.
SS Distributed content assumes the source is topologically close
SS to the sink. The most cost-efficient way to do this is put
SS sources at high fan-out areas, as this gets them the lowest
SS _average_ distance to their sinks. This doesn't necessarily
SS mean that putting a CNN mirror in 100,000 local exchanges is
SS going to reduce CNN's costs.
It depends. Akamai certainly is overkill for smaller sites, and
perhaps not cost-effective for others. However, high fan-out can
be a _bad_ thing too: Assuming one has substantial traffic flow
to various regions, why source everything from NYC? Why not
replicate in London, AMS, SJO, IAD, CHI, DFW, LAX, SEA, KSCY?
From a source's point, distribution makes sense when cost of
geographically-diverse server presence (incremental admin/hw,
content distribution) is less than the cost of serving everything
from a centralized point. Once that happens... if a substantial
portion of Internet traffic were sourced from one local point,
sinks would gravitate toward said point.
Of course, I may well be stuck in distance-sensitive mode. If
local loop is the primary expense... we're back to what you said
about few, centralized exchanges and many carrier hotels?
So, where's the dividing line?
Eddy
--
Brotsman Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita
~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to [EMAIL PROTECTED], or you are likely to
be blocked.
