RE: RTTP-- any comments?

From: Mark Day (markday@cisco.com)
Date: Wed Mar 28 2001 - 11:55:53 PST


Your analysis may be correct, but has little/no connection to the "RTTP"
site referenced. There, the author says nothing as cogent as the below and
instead spends his time noodling about (for example) the fact that TCP won't
work (duh!).

If he spent the space noodling about situations where RTP won't work, I
would think it was at least potentially interesting. As a document of
someone slowly reinventing RTP, I can definitely live without knowing about
it.

--Mark

Mark Stuart Day
Senior Scientist
Cisco Systems
+1 (781) 663-8310
markday@cisco.com

> -----Original Message-----
> From: Eugene Leitl [mailto:Eugene.Leitl@lrz.uni-muenchen.de]
> Sent: Wednesday, March 28, 2001 12:39 PM
> To: Mark Day
> Cc: strata@virtual.net; fork@xent.ics.uci.edu
> Subject: RE: RTTP-- any comments?
>
>
> On Wed, 28 Mar 2001, Mark Day wrote:
>
> > Oh, c'mon. How can anyone be talking about the "possibility" of
> > real-time data transmission over IP?
>
> I don't think IP is suitable for hard realtime/QoS multi-hop transmission
> at high (>>1 GBps) data rates. What you need is a protocol which is
> cut-through capable with (hitherto mostly mythical) purely photonical
> switches. I.e. deciding which link to switch to while the headers are
> still cruising through a (short) fiber optic loop (acting as optical delay
> line), while using low total numbers of optical switches (these things are
> big and power hungry, since using NLO), using shallow gate hierarchy (gate
> switch delays do accumulate).
>
> Ideally, you preallocate crossbar bits with a temporal lock (built-in bit
> rot implemented in hardware, path preburned through with admin messages
> sent ahead), then stream it through, with the headers sorted in the right
> sequence (sender smart, router dumb) so that the header bits directly
> switch the crossbar, being consumed in the process (thus needing a very
> shallow optical FIFO, if any).
>
> If a bit lock decays before you're able to transmit, then you fallback to
> store-and-forward.
>



This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:15:06 PDT