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? - Yes, we do various kinds of video over Internet2. Guess what? Packet loss is very 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 mall towns should 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" news should 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 <techlist@smoton.net> 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
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" IP exchanges 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 is very 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 mall towns should 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" news should 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 <techlist@smoton.net> 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
- 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
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
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
- 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
On Sat, 16 Nov 2002, Petri Helenius wrote:
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.
"Live" events are typically delayed by a minute or so to give time to editors to decide on course of action if something goes wrong with "live" feed. In any case, nobody cares about another half-minute of delay. The same pretty much goes for "interactive" shows - which all have interaction loops of minutes, not sub-second response which is hard to do over the regular Internet.
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.
Excessive jitter is easily converted into latency by having bigger buffers at the receiving end. So far, the only mass applications which have real need to have low latency are telephony (including video kind) and on-line gaming. Those are relatively low-bandwidth, and so don't contribute much to long-haul traffic. Of course, hauling bits over long-distance circuits costs more than doing the same over local exchanges - but the current routing technology makes having hundreds of local exchanges somewhat infeasible. --vadim
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
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.
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
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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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.
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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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
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.
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.
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 -
Paul, Not sure if you are currently in a position to answer this... With the impending S&D buyout of some of PAIX's assets, do you see PAIX Atlanta as a going concern? I know S&D 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
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 S&D buyout of some of PAIX's assets, do you see PAIX Atlanta as a going concern? I know S&D 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
- 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, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Thus spake "Jere Retzer" <retzerj@ohsu.edu>
- 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
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. There are also several clinic chains where they take the films and then send them to the radiologists in another location. Some of these are really rural areas and apparently the doctors used to have to drive in on certain days, or fedex, not exactly great if it really is an emergency. Dont know the legality, but apparently people are really doing it. Im not sure any of this needs an exchange pt though. None of it is real time yet. At 6:55 -0600 11/18/02, Stephen Sprunk wrote:
Thus spake "Jere Retzer" <retzerj@ohsu.edu>
- 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
Thus spake "David Diaz" <techlist@smoton.net>
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
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" <techlist@smoton.net>
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
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 coast.................wb8foz@nrk.com & 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 dead....................................20915-1433
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 coast.................wb8foz@nrk.com & 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 dead....................................20915-1433
-- David Diaz dave@smoton.net [Email] pagedave@smoton.net [Pager] Smotons (Smart Photons) trump dumb photons
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 coast.................wb8foz@nrk.com & 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 dead....................................20915-1433
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" <techlist@smoton.net>
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
Thus spake "Daniel Golding" <dgold@FDFNet.Net>
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
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 coast.................wb8foz@nrk.com & 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 dead....................................20915-1433
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 coast.................wb8foz@nrk.com & 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 dead....................................20915-1433
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" <techlist@smoton.net>
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
participants (17)
-
Alex Rubenstein -
Daniel Golding -
David Diaz -
David Lesher -
Hank Nussbacher -
Jere Retzer -
Jesper Skriver -
Kurt Erik Lindqvist -
Paul Vixie -
Petri Helenius -
Richard A Steenbergen -
Sean Donelan -
Stephen J. Wilcox -
Stephen Sprunk -
Stephen Stuart -
Steve Feldman -
Vadim Antonov