- From: Brian Behlendorf <brian@organic.com>
- Date: Thu, 10 Aug 1995 14:35:55 -0700 (PDT)
- To: Simon Spero <ses@tipper.oit.unc.edu>
- Cc: Jeffrey Mogul <mogul@pa.dec.com>, Paul Leach <paulle@microsoft.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On the audio/video/streaming tip - it should be noted that RealAudio is using a proprietary protocol that sits on top of UDP to deliver their "real-time" audio data. They haven't released any information about internals, nor mentioned any plans to support caching or application gateways for proxies. I'm not going to argue they should have done it in HTTP of course, but I do wonder if HTTP should be expected to handle streaming, lossy media instead of some other protocol. Brian On Thu, 10 Aug 1995, Simon Spero wrote: > Audio data: > > 1) Audio data is linear, and real time: If a message containing > audio data fails to arrive within a given window, it has missed its > chance and is no longer wanted. Retransmission is not helpful- > the only way to deal with data loss is via regeneration from > other packets (I think Christian has done some work on this?) > > 2) Audio data rates are adaptable: If the bandwidth available to > the sender decreases, the data rate can be reduced by increasing > compression ratios (MPEG), or by switching to a different > encoding scheme (ADPCM, etc). TCP does not make bandwidth information > available to the application, and does not allow data that has been > sent but not delivered to be recalled. > > > Real Time Transport protocols. > > A better approach for these particular media types is to use some sort of > Real Time Protocol, such as RTP. These protocols provide feedback to the > application as to the bandwidth available, latencies and jitters, > together with an indication of the rate of data loss. Although RTP isn't > a transport protocol in itself, transport protocols can be build on top > of it by using the information provided to do limited re-transmission > where applicable, and to do some sort of rate based congestion control > (e.g., clock packets out at the same rate the receiver receives them, > treat increased jitter as a sign of router queue instability, etc) --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Received on Thursday, 10 August 1995 14:36:21 UTC