Subject: [AVT] retransmission payload format

From: [email-masked]
Date: Wed, 25 Sep 2002 12:51:11 -0500

We are in the process of merging the two retransmission payload format as outlined at the last group meeting. We have one open issue on which we would like to get the group feedback before submitting the draft.

We had first planned to use the payload format as described in Section 5 of http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-02.txt and reproduced below:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|   OPT       |            OSN                |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                  Original RTP Packet Payload                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

If this format were used, the PT field of the RTP header would map to the retransmission payload format, the OPT would map to the original PT of the media being retransmitted and the RTP TS would be set to the media TS of the original RTP packet.

However, an issue was brought up with regards to the TS clockrate to be used with the retransmission payload format in scenarios where the original RTP stream would be switching between media types with different TS clockrate. One example would be an audio stream which may switch between AMR, AMR-WB and AAC codecs which all have different TS clockrate. This can't be handled with the above payload format as there cannot be multiple clockrate for any payload format.

The solution that we propose in order to solve this problem, is to use multiple PT values in the retransmission stream if multiple payload formats are used in the original stream. In other words, instead of using the RTP header to signal the retransmission payload format and signal in the payload format (OPT) the original media payload, the RTP header PT would map directly to the retransmission/media type couple. In the above example, this would mean that retransmitted AMR, AMR-WB and AAC map to 3 different payload types. 

Note that as a consequence, there's no use of the OPT field and the payload format header could be reduced to 2 bytes as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            OSN                |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                  Original RTP Packet Payload                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Adopting this payload format has further implications on the random TS offset requirement and the RTCP jitter:
*The initial RTP TS SHOULD be random because of known plain text attacks. This payload format does not follow this recommendation as the initial TS will be the media TS of the first retransmitted packet. However, since the initial TS of the orignal stream is itself random, if the original stream is encrypted, the initial retransmitted TS would also be random to an attacker. Therefore, security requirements would be met. 
*The RTCP jitter value for the retransmission stream does not reflect the actual network jitter since there could be little correlation between the time a packet is retransmitted and its original media TS. There would thus be very little use of this jitter value computation to RTP senders. However, since the original packets and the retransmission packets are sent into separate streams, the RTCP jitter of the original stream is computed as usual and senders can estimate the network jitter using the RTCP jitter value of the original stream.

This approach also obviously implies that more PT values need to be used for the retransmission stream.  

Another solution to the retransmission TS clockrate problem would be to use an independent TS for the retransmission stream, such as the time instant the packet is retranmsitted and send the original media TS in the payload. 

With such a solution, the payload format would be as shown below:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         RTP Header                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           OTS                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|   OPT       |            OSN                |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                  Original RTP Packet Payload                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

where OTS is the orginal media TS of the retransmitted packet. Compared to the previous approach, this payload format adds 5 bytes of overhead.
The advantage of this payload format is to allow the computation of the network jitter since an sending time TS is used.
The RTP timestamp frequency for this payload format should be chosen so as to yield an RTCP jitter measurement with the desired precision. For example, a 10khz timestamp would yield a precision of 0.1 ms. 

To conclude, two approaches (media TS with multiple PT, sending time TS with unique PT) could solve the TS clockrate issue when multiple clockrates are used in the original stream. We favour the media TS approach which has lower overhead but we would like to hear from others' point of views.

David. 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sun, 29 Sep 2002 20:48:15 -0400

--> [email-masked] writes:
>We are in the process of merging the two retransmission payload format 
>as outlined at the last group meeting. We have one open issue on which 
>we would like to get the group feedback before submitting the draft.
>
>We had first planned to use the payload format as described in Section 5 of 
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-02.txt
>and reproduced below:
>
>If this format were used, the PT field of the RTP header would map to the
>retransmission payload format, the OPT would map to the original PT of the
>media being retransmitted and the RTP TS would be set to the media TS of
>the original RTP packet.
>
>However, an issue was brought up with regards to the TS clockrate to be
>used with the retransmission payload format in scenarios where the original
>RTP stream would be switching between media types with different TS
>clockrate. One example would be an audio stream which may switch between
>AMR, AMR-WB and AAC codecs which all have different TS clockrate. This
>can't be handled with the above payload format as there cannot be multiple
>clockrate for any payload format.

This is problematic in RTP in general, unless you switch SSRC when changing
to a different rate. 

>The solution that we propose in order to solve this problem, is to use
>multiple PT values in the retransmission stream if multiple payload formats
>are used in the original stream. In other words, instead of using the RTP
>header to signal the retransmission payload format and signal in the
>payload format (OPT) the original media payload, the RTP header PT would
>map directly to the retransmission/media type couple. In the above example,
>this would mean that retransmitted AMR, AMR-WB and AAC map to 3 different
>payload types. 
>
>Note that as a consequence, there's no use of the OPT field and the
>payload format header could be reduced to 2 bytes as follows:
>

An alternative would be to keep the original payload format, with the OPT
field, and signal different payload types for retransmission at each rate
(this uses one octet per packet, but may simplify the signalling).

>*The initial RTP TS SHOULD be random because of known plain text attacks.
> This payload format does not follow this recommendation as the initial TS
> will be the media TS of the first retransmitted packet. However, since
> the initial TS of the orignal stream is itself random, if the original
> stream is encrypted, the initial retransmitted TS would also be random to
> an attacker. Therefore, security requirements would be met. 
>
>*The RTCP jitter value for the retransmission stream does not reflect the
> actual network jitter since there could be little correlation between the
> time a packet is retransmitted and its original media TS. There would thus
> be very little use of this jitter value computation to RTP senders. How
> ever, since the original packets and the retransmission packets are sent
> into separate streams, the RTCP jitter of the original stream is computed
> as usual and senders can estimate the network jitter using the RTCP jitter
> value of the original stream.

It also becomes difficult to use header compression, if the retransmitted
packets are sent as a separate stream.

>Another solution to the retransmission TS clockrate problem would be to
>use an independent TS for the retransmission stream, such as the time
>instant the packet is retranmsitted and send the original media TS in the
>payload. 
>
>where OTS is the orginal media TS of the retransmitted packet. Compared to
>the previous approach, this payload format adds 5 bytes of overhead.
>
>The advantage of this payload format is to allow the computation of the
>network jitter since an sending time TS is used.

>The RTP timestamp frequency for this payload format should be chosen so as
>to yield an RTCP jitter measurement with the desired precision. For example, 
>a 10khz timestamp would yield a precision of 0.1 ms. 

You could use the same rate as the original media, and include a delta in
the packet to save a couple of octets?

Cheers,
Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Sep 2002 10:40:21 +0200

Hi Colin,

See comments inline:

>This is problematic in RTP in general, unless you switch SSRC when changing
I would just like to clarify, that switching SSRC does not remove the 
requirement that each payload type can only have a single TS rate. 
However I do agree that switching SSRC when changing RTP TS rate has 
some advantages. It does avoid the unclarity for the receiver to exactly 
know when the switch point was. This unclarity can really be problematic 
if you would switch rate rapidly several times. However if the switch 
does not happen often it can be decently enough handled.

When doing retransmission according to the current proposal (SSRC 
multiplexing) one will be required to follow the original stream and how 
it is handled. If the original stream switch SSRC when switching rate, 
each rate will have its own retransmission SSRC. If the original stream 
switch rate and keeps the rate the retransmission stream needs to do the 
same.

>(this uses one octet per packet, but may simplify the signalling).
I don't think it will simplify the signaling at all. You will still need 
one RTX payload format for each rate existing in the original stream. 
Then having the original PT signaled in the RTX payload format seems 
redundant. Making a simple 1-1 mapping of the original PTs and the RTX 
PTs seems straightforward enough.

>packets are sent as a separate stream.
I would not say it becomes difficult to use header compression. The 
efficiency will simple be less as the RTP TS must be sent using more 
bits or uncompressed. But as the retransmitted stream uses much less 
bandwidth than the original stream I would think it is a minor problem.

>>Another solution to the retransmission TS clock rate problem would be to
Yes, but then you would still require to have as many RTX payload types 
as you have original rates. By including the full field you don't care 
about the original rate. Also having a delta requires a more advanced 
mechanism for reconstructing the TS.

My view is that the later solution is a cleaner and nicer, but its cost 
is rather high.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Mon, 30 Sep 2002 09:36:05 -0400

[inline]

>>--> [email-masked] writes:
...
>bandwidth than the original stream I would think it is a minor problem.

This was what I meant: the compression is likely to be seriously impacted.
We may not care, since retransmission packets will hopefully be rare.

>My view is that the later solution is a cleaner and nicer, but its cost 

I don't see a problem with using many payload types. That seems cleaner
than having to deal with synchronisation problems if the retransmission 
format chooses a different clock rate to the original media.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 Sep 2002 17:06:18 +0200

[even more inline]

>We may not care, since retransmission packets will hopefully be rare.
I guess this depends on the compression type. In the case of the ROHC 
RTP profile it will only mean that each packets header becomes up to 2 
bytes bigger compared to a optimal performance. But maybe some of the 
other standards has worse performance.

>format chooses a different clock rate to the original media.
I agree that doubling the number of payload types is not a problem with 
the normal small number of payload types we have seen so far. However I 
don't see how this helps the synchronization problem. If the original 
stream switches rate by changing payload type, any retransmitted packet 
must after reconstructing have its correct timestamp.

Using multiple payload types with different rates in the retransmission 
stream and having the original timestamp in the RTP header forces the 
RTP session of switching the rate also for the retransmission SSRC. And 
the number of switches can potentially be several for each switch in the 
original stream. If packets before and just after switch is 
retransmitted the following might occur: Packet A has one rate of the 
x's and Packet B of the y's.

Original stream   x x A B y y y
Packet losses         l l
Retransmission stream  A1 B1 A2 B2 A3
RTX losses             l  l  l

In the above scenario the retransmission streams switches 5 times very 
rapidly on the sender side. The receiver although only sees 2 switches. 
Still, I don't see this as a desired behavior. If one would use a single 
static RTX pt with its individual RTP TS the retransmission stream would 
not switch a single time. The reconstructed packets would simply have 
there correct RTP TS. So having larger or smaller synchronization 
problems when switching rate depends if the RTP TS is used to transport 
the original or not.

Having a RTP TS based on send time is nicer as it doesn't screw up the 
RTCP measurements and instead allows them to work as intended. If we 
sometimes in the future are going to do a new version of RTP we really 
should consider having two timestamps. One for media synchronization and 
another one for transport statistics.

However I don't know it these nice things is worth the four byte in 
extra overhead for each retransmitted packet. Especially as they aren't 
really needed for the retransmitted stream.
 
Regards

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Mon, 30 Sep 2002 17:28:25 -0400

>problems when switching rate depends if the RTP TS is used to transport 

Okay, but you'd need to restrict the clock for the retransmission stream,
such that the timing of the original streams can be exactly deduced from
the clock in the retransmission.

>really needed for the retransmitted stream.

The RTCP jitter statistics are probably not useful for the retransmission
stream anyway?

Colin