Subject: RE: LSP failure detection

From: [email-masked]
Date: Fri, 10 Nov 2000 17:16:28 -0000

Thanks Glen......seems a good candidate for a very robust network solution.
But I think the answer is not to blanket cover the whole network with
performance that only a small number of applications need (this is not
cost-effective).  The answer here would be very focussed and specific
treatment for that application....maybe even setting up 3 disjoint (if
possible) network connections.  
neil

> > Can someone please tell me what these are?  I think we should
> > start by listing them.
> 
> Haptics (touch) applications for one.
> 
> We've got a researcher in Western Australia who has a supercomputer
> driving an industrial robot strapped to some poor blighter's thumb.
> As supercomputers are a tad rare, there's an Internet link between
> the computer and the robot.
> 
> The idea is that the blighter can be a medical student learning
> how to do surgery (and thus saving lots of furry animals).
> 
> I was a bit dismissive of this as a wide-spread future application
> until I saw the success of the PlayStation Shock Controller :-)  The
> researcher is being funded by the mining industry, as it could allow
> a mine to call in a remote expert to drive the cutting machine
> through a particularly tricky seam.  Other applications spring
> to mind.
> 
> The downside of this rosy picture is that the latency is quite
> tight.  And if there is the loss of more than 50ms of data the
> industrial robot enters fail safe mode so that the blighter
> doesn't lose any more fingers.
> 
> I'm not suggesting that this is the sort of application that
> will be on the Internet tomorrow, but if you're asking about
> the worst-case application for the current Internet, then
> remote haptics would be it as it tickles the tricky issues
> in latency, jitter, protection, availability, denial of service
> and authentication.
> 
> 
> Also, if you think that voice and video are the ultimate in
> multimedia applications, then consider that we have barely
> started to experiment with sending RADAR streams across the
> Internet.  There's about 7 dimensions of data.
> 
> -- 
>  Glen Turner                                 Network Engineer
>  (08) 8303 3936      Australian Academic and Research Network
>  [email-masked]          http://www.aarnet.edu.au/
> --
>  The revolution will not be televised, it will be digitised

---

From: "Frank Hujber" <[email-masked]>
Date: Fri, 10 Nov 2000 12:59:39 -0500

Neil, Glen,

As we approach a 40 Gbps network (OC-768), a 50 ms outage causes the loss of
2 Gb of data. If you consider a bunch of telephone calls aggregated on a
(for example) SONET/SDH path, it's insignificant because the loss that any
one takes is small, even if they have to re-dial. But the next generation of
"television" (beyond HDTV) may well be a 3D imaging system, and the amount
of data in a 3D "frame" is immense, relatively. A consumer watching a sitcom
in 3D can afford to lose a few frames, but a telemedine application cannot.

I don't necessarily suggest that sticking with the current SONET/SDH
implementation is the right answer, but as data rates go up, the value in
terms of data lost per millisecond goes up as well. If we are talking about
a unified Internet, albeit with shared ownership among a variety of
carriers, then it should do better than the minimum required for
discretionary services; it needs to support high-reliability services as
well, and that may well drive the handful-of-millisecond switching times the
SONET/SDH provides.

Frank Hujber
[email-masked]

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 10 Nov 2000 13:30:18 -0500

> -----Original Message-----
> To: [email-masked]; [email-masked]; MPLS Group
> Subject: Re: LSP failure detection
>
>
> Neil, Glen,
>

Well, you have rightly articulated the relationship between high
transmission speed and the need of lower latency. But remember, that
in a few years time - you would also likely have optical buffers where
data can be temporarily buffered for short duration so that it can be
re-transmitted once alternate path is available.

Cheers,

--brijesh
Ennovate Networks Inc.