[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] retransmission payload format
As I understand the debate, and I did come in well after it appears to have started,
the issue is how to deal gracefully with "real-time" commands in a "real-time"
media stream and provide some security against various attacks. The communications
scenario appears to be oriented toward multicast.
Where do I find a summary document of the objectives and concerns relevant to this
discussion? In particular, the retransmission issue is not, I take it, an attempt
to develop full handshaking between sender and receiver. Which security concerns
are most relevant at this level?
Thanks.
This e-mail contains information confidential to EyeWonder Inc. No contents of this e-mail shall be retransmitted or communicated to any party other than the intended recipient without the expressed written consent of an authorized representative of Eyewonder Inc. Transmission of this message does not constitute public disclosure of any message contents.
Mike Marchywka
Chief Scientist
EyeWonder Inc.
2859 Paces Ferry Rd
Suite 1200
Atlanta GA 30339
770-261-5084
> -----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
>
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt