-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
Sent: Monday, September 30, 2002 11:06 AM
To: Colin Perkins
Cc: avt@ietf.org
Subject: Re: [AVT] retransmission payload format
[even more inline]
Colin Perkins wrote:
[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.
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.
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.
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
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: magnus.westerlund@era.ericsson.se
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt