Subject: [AVT] Issues on draft-ietf-avt-rtp-retransmission-02.txt

From: José Rey <[email-masked]>
Date: Thu, 04 Jul 2002 21:30:38 +0200

hi David and all,

there are a couple of issues in draft-ietf-avt-rtp-retransmission-02.txt
that I would like to raise for discussion in the WG, as follows:

- delayed detection of lost retransmissions
The detection of lost retransmissions is based on timers that use an
estimation of the RTT. This is a problem in environments where RTT is
variable, e.g. wireless links. In environments where delay jitter IS an
issue RTT measurements are generally not accurate. Thus a timer-based loss
detection scheme might lead to repeated (unnecessary) or delayed
retransmission requests that make the requested packet expire, thus
decreasing the performance of a retransmission scheme.

- false estimation of the timestamp of lost packets:
The retransmission-01-draft requires a estimation of the TS of lost RTP
packets to correctly set timers for further retransmission requests in case
the retransmissions fail. An accurate estimation is quite simple to achieve
(e.g.
linear estimation) ONLY if the relation of TS and SN for the media remains
constant during the duration of the session.

However, TS-jumps (e.g. RTSP FFWDing...) or any other heterogeneity that
alters this constant relation  (e.g. a frame being divided into several RTP
packets) causes a linear estimation to be erroneous. Could you please
describe how a TS estimation is performed for non-constant relations of TS
and SN?

- also coming back to the email from Bill Foster from June,22nd:
"
>
> Also an RTX format where headers accumulative (along with the approach of
> using the same sequence number space) is important for some applications.
> For example, with draft-ietf-avt-rtp-retransmission-01.txt, if
> the sequence
> number wraps before I get a chance to get the retransmitted
> packet through,
> I've lost the opportunity to retransmit the packet.
> draft-ietf-avt-rtp-selret maintains a history, so that even if a wrap
> occurs, the opportunity to retransmit has not gone away.
>
"
the retransmission-02 draft doesn't keep a history of lost packets. David,
how do you plan to solve this issue? If this is not an issue, why?

regards,

Jose

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 05 Jul 2002 17:07:37 +0200

Hi,

I have some comments on the issues.

>decreasing the performance of a retransmission scheme.
A lost retransmission will also be detected based on sequence number 
gaps in the retransmission streams. Due to much less traffic this will 
of course be less good than in the original stream. My opinion is that 
this is something you have to accept when you have the requirement to 
use a separate session.

>describe how a TS estimation is performed for non-constant relations of TS
Yes, but you can create a rather good worst case estimation, which are 
basically the last packet received previous to the lost packet. This 
will for example for a 10 Hz picture rate be no more than 100 ms in 
error and this can be considered worst case in it self.

I would also like to point out that in a correct implemented RTSP server 
Fast forwarding the stream will not create TS jumps. As long as the 
stream is played out in scale=1.0 the timestamp should match the time 
elapsed since session setup. To clarify in example. A stream with TS 
rate 1000 Hz was started at play time 0 with timestamp 0. After 10 
seconds the stream is fast forwarded (requires a pause and play) to 20 
seconds into the media. This last packet before fast forwarding has TS 
10000 and the first packet after fast forwarding will have 10000+x, 
where x is in the order of 100 if there is normally sent 10 packets 
every second.

>how do you plan to solve this issue? If this is not an issue, why?
I don't understand Bill's arguing of the matter. How can the sequence 
number wrapping in the original stream prevent retransmission? I could 
perhaps agree that there is to little specified regarding the use of the 
feedback format telling to not consider sequence number with more than 
32767 in negative distance as old packet but rather as new.

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: José Rey <[email-masked]>
Date: Fri, 12 Jul 2002 21:37:33 +0200

Hi Magnus and all,

please see my comments below...

> -----Ursprüngliche Nachricht-----
> Von: Magnus Westerlund [mailto:[email-masked]]
> Gesendet: Freitag, 5. Juli 2002 17:08
> An: José Rey
> Cc: Avt@Ietf. Org; David Leon
> Betreff: Re: [AVT] Issues on draft-ietf-avt-rtp-retransmission-02.txt
>
>
> Hi,
>
> gaps in the retransmission streams.

Not according to the retransmission-02 draft; in this retransmission
requests are only issued when the timer expires.

> Due to much less traffic this will

In any case, if you do want to add the detection the lost retranmission by
means of a gap to the draft the comment still applies: you have more delay
than using one session due to
the reduced traffic of the retransmission session. Thus I agree in saying
that the trade-off is the latency in loss retransmission detection.

> error and this can be considered worst case in it self.

Of course the estimation is better the closer the lost packet is to the last
received packet. But this is the closest it gets.
If there's a TS jump in the media and packets get lost before and
after the jump, you can:
1) request all packets based on the simple TS estimation at the risk of
causing spurious retransmissions.
2) request each packet one after the other and performing the estimation
every time upon reception of a retransmission. This has the disadvantage of
1 RTT delay adding up with each retransmission and probably making the
oldest packets expire.

> where x is in the order of 100 if there is normally sent 10 packets
Thanks for the clarification.

cheers,

Jose