Subject: RE: RTCP Retransmission

From: "Fleischman, Eric W" <[email-masked]>
Date: Mon, 20 Dec 1999 10:44:41 -0800

Early experiments using TCP for streaming at Microsoft several years back seemed to indicate that TCP was an acceptable streaming transport over the Internet if (and only if) the TCP's sliding window was kept very small (e.g., 2 or 3 or 4).

> ----------
> From: 	Nikki Cranley[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Friday, December 17, 1999 8:41 AM
> To: 	Colin Perkins
> Cc: 	Koichi Yano; [email-masked]
> Subject: 	Re: RTCP Retransmission
> 
> Hi Colin -
> 
> The problem with TCP is that for real-time or near real time transmission its
> not feasible to use TCP as there may be lost packets/delays etc.and
> retransmission of these will hinder the real-time ability - so RTP/UDP/IP is
> used.
> But in the case of MPEG-4 - there are some important packets that probably
> shouldn't be lost - imagine if the packet with all the decoding information got
> lost - well that would render everything else useless. I am looking at this only
> from the perspective of unicast anyway - plus if we were to extend this to VR -
> then RTCP-Rx could be used to dictate user interaction as there is no scope for
> this in RTP/RTCP as far as I know. It would only be needed from client to
> server.
> I'm only new to this but thats what came to mind. I was thinking along the lines
> of say incorporating media specific functionality into the RTCP-Rx.
> 
> Rgds,
> Nikki
> 
> Colin Perkins wrote:
> 
> > --> Nikki Cranley writes:
> > >I am looking at RTCP-Rx also with respect to MPEG-4. In MPEG-4 the BIFS and
> > >IOD are very important for establishing the transmission and replay of the
> > >MPEG-4 file. I am thinking of using ways to implement the RTCP-Rx to ensure
> > >that these files are received.
> > >I think that there should be new payload types defined to reflect different
> > >media types etc. The intended purpose of RTCP-Rx is selective
> > >retransmisison  and so there need to be selection criteria otherwise its
> > >like TCP.
> >
> > For unicast, I wonder if TCP is not the correct means of transporting this
> > information, and would be interested in arguments why not.  For multicast,
> > I remind you of RFC2357 and the work in RMT, which might be appropriate.
> >
> > Cheers,
> > Colin
> 
>