Subject: Re: RTCP Retransmission

From: Colin Perkins <[email-masked]>
Date: Thu, 06 Jan 2000 08:44:43 +0000

--> Alagu Periyannan writes:
>At 01:56 PM 12/27/99 +0000, Colin Perkins wrote:
>>--> Alagu Periyannan writes:
>>>
>>>A "time-based streaming" protocol in my definition is a protocol that
>>>delivers timestamped packets period. It must cover the case of time bounded
>>>delivery with no reliability guarantees and the case of 100% reliability
>>>with no time bound.
>>
>>We have RTP over UDP for the first case, and the new profile draft
>>specifies a TCP encapsulation for RTP which should deal with the case of
>>"100% reliability with no time bound"? 
>>
>>This leaves the case where we have a time bound, but desire enhanced reliability 
>>compared to UDP. We have some options here already (eg: redundant audio and
>>parity FEC), and the RTCP retransmission draft offers another alternative.
>
>I was not aware of the RTP over TCP draft. (A pointer is appreciated.)

It's in section 7 of draft-ietf-avt-profile-new-07.txt.

>Nevertheless, in many cases one may need to mix the various cases I
>mentioned in one RTP session. For example if we are streaming an animation
>over RTP, we may want to send the "actor" information in a reliable fashion
>and the motion vectors in a non-reliable fashion.
>
>This is not possible if the "100% reliability with no time bound" case is
>covered in a separate profile that does not include features of the
>standard A/V profile.

It's in the standard profile, but I suspect we may need a minor SDP
addition to signal it. At present we have something like
	m=video 49170/2 RTP/AVP 31
which indicates the "Realtime Transport Protocol using the Audio/Video
profile carried over UDP" (quoting rfc2327). There's no defined way to
signal RTP-over-TCP - we'd need to define 
	m=video 49170/2 RTP/AVP/TCP 31
for example to allow this.

Colin

---

From: [email-masked] (Alagu Periyannan)
Date: Thu, 06 Jan 2000 01:13:57 -0800

>for example to allow this.

I want to cover the case where in a single RTP session we may want to send
a few packets reliably and the rest unreliably.

In the scheme you illustrate above I have to choose UDP or TCP for the
entire session.

--

Alagu Periyannan                     [email-masked]
Entera, Inc.                         +1 510 770 5225

---

From: Colin Perkins <[email-masked]>
Date: Thu, 06 Jan 2000 09:45:19 +0000

>a few packets reliably and the rest unreliably.

This is what RTCP-Rx is for! But that has to be a different profile, since
it requires separate RTCP transmission rules (it can be an extension which
uses the same payload formats as the current audio/video profile, if that 
is your concern).

Alternatively, send the character data in parallel/in advance using a TCP
stream, and the animation data over RTP. It depends on how much data you
have to transmit - RTP is not, and should not be, a file transfer protocol.

Colin

---

From: Nikki Cranley <[email-masked]>
Date: Thu, 06 Jan 2000 10:38:20 +0000

Hi all,

That is what I was trying to say earlier using RTP-Rx for streamed MPEG-4 data.
There are just a few packets such as the BIF and the IOD which are more
important to the transmission, the rest of the packets would hopefully get
there but if they don't -well its no big deal if some of them get lost or
delayed.

> uses the same payload formats as the current audio/video profile, if that

In MPEG-4 there is a back channel defined for feedback but it still has to be
put into RTCP packets - I think that RTP-Rx is better. But there will need to
be profiles defined.

What is meant by separate RTCP transmission rules?

> have to transmit - RTP is not, and should not be, a file transfer protocol.

Or using SDP - some out of band means. This has to be done anyway to get the
path MTU and QoS limitations etc.

Nikki

---

From: Colin Perkins <[email-masked]>
Date: Thu, 06 Jan 2000 15:53:50 +0000

>What is meant by separate RTCP transmission rules?

The current rules for when you send RTCP packets don't allow for its use to
request retransmission. We have to update these rules, to allow this, and to
specify congestion control for retransmission request traffic.

Colin

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 06 Jan 2000 17:59:32 +0100

Dear AVT:

The more I follow this thread, the less I'm convinced that a combination of
reliable and unreliable transmission using RTP is a good idea.

I believe, that media coding specific feedback messages (e.g. for
reference picture selection in H.263+ and MPEG-4 visual video version 2)
make sense, and that such mechanisms fit into the current RTCP
model.  They just have to be defined in the payload specs.  The same
is the case for the more generic ARQ mechanisms of which some video 
people still believe that they are useful.

But I don't think that we should allow 'reliable' transmission mechanisms
based on UDP at all, for reasons like missing/to be defined congestion
control, muliticast/broadcast scaling aspects, and so on.  People who
try to do this would have to re-invent most functionality of TCP, plus
reliable multicast if they want to cover multicast transmission as well.

I believe that a better alternative would be to use two transmission channels,
one reliable using TCP/RTP and one unreliable using UDP/RTP.
Synchronization of this two channels could be done using the RTP
timestamps.  MPEG-folk could come up with an Internet draft 
describing what data has to go over the unreliable, and what data should
go over the reliable channel.

I could also settle for a packet based re-transmission allowing a fixed,
low number of attempts.  H.223, for example, allows for video data (AL3)
exactly one re-transmission attempt.  This can greatly impove the
transmission quality, without interfering too much with the real-time
character of the protocol, or generating too many congestion problems.
But, again, this is not reliable transmission, and likely not sufficent for
MPEG needs.

Frankly, MPEG made the mistake to define most of their work as 
media independent, and left the definition of transport aspects to the
vaporware DMIF part.  Now, after most people believe that DMIF is not
going to happen, we (AVT) should not try to construct a completely new
protocol (with all the resulting problems) to solve their problems.
Especially not, as there is with RTP over TCP a solution that is just
barely less efficient then the best we could, after significant work,
come up with.

My 2 cents.

Stephan