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

From: [email-masked]
Date: Tue, 9 Jul 2002 14:32:48 -0500

Jose and Magnus,

[Jose]
> >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.
> >

[Magnus]
> 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.

[David]
Jose, you cannot do without the RTT estimation as otherwise you would not be able to detect the loss of a NACK packet.
Besides, I do not understand your arguing against using an RTT estimation and at the same time recommending it in your draft (section 7).

[Jose]
> >- 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?
> >

[Magnus]
> 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.
> 

[David] 
Magnus' answer shows that you can get a pretty good estimation of the packet TS at the receiver.
In addition, the receiver is the entity which knows the true buffering delay at a given point in time and should decide whether to request a packet. Requesting a packet without estimating its TS could lead to unnecessary retransmission as the sender does not know the actual receiver buffering delay. 

[Jose]
> >- 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?
> >

[Magnus]
> 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.

[David]
It wouldn't harm to add this text but it looks pretty obvious to me. Besides, as I have already commented to Bill, I have some trouble thinking of an application where the sender would send at so high a rate that it has to choose between two packets of the same SN and at the same time where the packet loss would be so high that multiple retransmissions are needed.

David.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Jul 2002 08:59:41 +0200

Hi David,

See comment below.

>Besides, I do not understand your arguing against using an RTT estimation and at the same time recommending it in your draft (section 7).
No, I was trying to say that sequence number gaps can be a complement in 
detecting lost retransmissions. Of course you still need the RTT timer 
to detect losses. The usage of  sequence number gaps may simply allow 
for earlier detection.

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:33:02 +0200

Hi all,

please see my comments,
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag von
> [email-masked]
> Gesendet: Dienstag, 9. Juli 2002 21:33
> An: [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [AVT] Issues on draft-ietf-avt-rtp-retransmission-02.txt
>
>
>
> Jose and Magnus,
>
> [Jose]
> Jose, you cannot do without the RTT estimation as otherwise you
> would not be able to detect the loss of a NACK packet.
> Besides, I do not understand your arguing against using an RTT
> estimation and at the same time recommending it in your draft (section 7).
>
----
Section 7 explains the SEL payload format. The SEL payload format is an
optional payload format with an option (DTI=0/1) to include information
about the TS of lost important packets. If the server/client doesn't see any
need/sense to use this option, he will turn it off.

What I am argueing about is that you make your decisions to send
retransmission requests based on two estimations and don't take the priority
of the packet into account. A TS estimation and an RTT estimation which are,
as stated in your draft, necessary for the client. I would say in
environments where there are strong delay variations, like wireless links,
or in cases where you have TS jumps you would discard valid requests more
often than if you just request everything, and what's worse: you don't know
what you discard, if is more or less important data.

In the case of the TS jump the solution in my opinion would be to add the
SEL headet to those packets before and after the jump and then you can
exactly know what happened and avoid complications.

-----
As for the detection of loss NACKs: it is in fact possible without timers.
Using selret you can do several things to detect a lost retransmission
request: two as per current draft and a third one, being here introduced.
The options are:

1.- if using SEL with DTI=1 is used together with RTX, retransmission
requests for lost important packets can be repeated as long as the packet is
not there, just by using an RTT estimation and the EXACT TS of lost packets.
It could be used in the same cases as your scheme with the two estimations
is suitable but is able to distinguish if the packet is important. This
could, for example, be used to trigger early feedback and make the packet
come on time. OK I admit that this is particular for important packets
but...
2- if you are just using RTX header you can send feedback (together or not
with NACKs) in form of ACKs (see selret draft, examples section). Periodic
ACKs shall inform the receiver about what came and what didn't, thus the
server can detect the loss of rtx request because he sees that certain
packets are not received and weren't requested. Upon this obervation he
retransmits them . Additionally periodic ACKs give also the receiver control
over what the server sends, so the client can change its buffer size,
depending on its needs.
3- furthermore, there's also a possibility to solve the issue of NACK loss
detection and the issue of the gaps in the SN space at the same time. This
would be to extend the SR to include a profile specific extension, say
SR-RTX. We've seen in our discussion all along that when using selret, there
are two reasons why there might exist unidentified gaps (receiver doesn't
know if they correspond to first transmissions or rtxs) in the SN space at
the receiver:
	1.- the Rtx. Request was lost. No retransmissions for those packets are
ever sent ->the unidentified gaps are always there.
	2.- multiple retransmissions of a packet don't make it through (for
whatever reason: expired, skipped,..).

Under good channel conditions, where neither 1 nor 2 apply, the receiver is
always able to identify the gaps in its SN space = no problem for SN-based
applications.

But if 1 or 2 apply the receiver needs to identify these gaps. This
extension would look something like this :

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | total retransmission count	   |            lentgh             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            SN                 | 	    mask	       	     | for length=1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            SN                 |      mask		           | for length=2
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            SN                 |      mask		           | for length=3,
etc...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The profile specific extension header must include, at least, a
retransmission count in order for the receiver  to detect the loss of a
SR-RTX and a length field to indicate the number of SN-mask fields below.
The SN field is the first reported retransmission that together with the
mask indicate up to 17 retransmissions. The sender would append this
extension to each receiver report only if retransmissions took place.

The receiver behavior would be as follows:  the receiver should check upon
reception of each SR-RTX if there are still unidentified gaps since the last
retranmission reported in the received SR-RTXs. If so, these packets should
be requested in the next retransmission request. Upon reception of this
retransmission request the server generates a SR-RTX extension and sends
these packets if they can still be sent (maybe they have expired or were
skipped by the server,due to rate control or scheduling for example).

Summarizing 3.)

1.- (-+) the scheme is not 100% reliable, but do we need it? I mean, the
case where the SN gaps are persistent should be the rare case, what's the
probability of repeatedly losing SR-RTXs, retransmission requests and
retransmitted packets all together with a rather high number of
retransmissions possible? ..Relatively small, and if this is the case, the
question is rather: is it worth to do streaming at all under such
conditions?
Let's imagine an example with a session bandwidth of 64 kbps and 50 media
fps, the sender gets 0.0375*64kbps=2.4kbps which allows it to sent 5 SR-RTXs
(5x116bytes to report <=5x34 rtxs) in a little bit more than 2 seconds. This
allows full reporting of all possible retransmissions by far while complying
with the BW share. The receiver gets 800bps and this is enough to report 51
losses in little more than 1 second. If the client has 3 seconds buffer,then
for gaps to be there, it has to happen that after 3 seconds no
retransmission of these packet AND the last one from the 7 SR-RTXs didn't
arrived or none of the multiple retransmission requests AND the last SR-RTXs
didn't arrived, which is, I think, quite unprobable...
2.- (-) some extra buffer that's needed at the client, is this an issue? is
memory an issue nowadays?
3.- (+) making an extension to reflect the sent retranmissions is the
logical extension of RTCP for the retransmission framework. Provides
complete statistics in one session.
4.- (+) both, non-SN-based and SN-based applications are supported. The
header extension is only used if the client application is SN-based. It can
be setup in SDP, for example.
5.- (+) you still get fast detection of lost retransmissions thanks to the
SN multiplexing
6.- (-+) RTCP Sender bandwidth increases but remains under 5%.

I would like to hear comments about this extension. Does anybody see any
problems ?

> the packet TS at the receiver.

David, the example Magnus set has no TS jump....

Magnus, could you be a little more descriptive ? I still see how the errors
in TS jumps could be much bigger. In which case are you in? how many packets
do you loose?

> In addition, the receiver is the entity which knows the true
> buffering delay at a given point in time and should decide
> whether to request a packet. Requesting a packet without
> estimating its TS could lead to unnecessary retransmission as the
> sender does not know the actual receiver buffering delay.

I think I don't understand . what if the server buffer is the limitation?
Please see the email from Magnus from 10.07...

Jose