Re: [AVT] retransmission payload format

[Colin Perkins <csp@csperkins.org>]

[inline]

--> Magnus Westerlund writes:
>Colin Perkins wrote:
>>--> David.Leon@nokia.com writes:
...
>>>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. 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.
>>
>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.

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

>>>This approach also obviously implies that more PT values need to be used
>>>for the retransmission stream.  
>>>
>>>Another solution to the retransmission TS clock rate 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. 
>>
>>You could use the same rate as the original media, and include a delta in
>>the packet to save a couple of octets?
>>
>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.

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
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt