Subject: Clarifications on [AVT] Sequence issue with draft-ietf-avt-rtp-selret-04.txt

From: José Rey <[email-masked]>
Date: Fri, 21 Jun 2002 14:02:16 +0200

Dear all,

I think the problem of SN-based applications with selret is not being
accurately described. Before continueing, let me state one thing clear: with
the scheme proposed in the selret draft is, FOR ALL RECEIVED RTP PACKETS,
always possible to put them in the correct order. For details see the
examples below.

To avoid confusion during email discussion let's define an MPEG SN (refer to
as x*=1*,2*,...) which is the display SN and is (to some extent) coupled
with the TS and on the other side the RTP SN (refer to as x=1,2,...) which
is incremented in one for each packet sent:  transmissions or
retransmissions.

I think that what Rahul meant with "correct frame sequencing" would
correspond here to MPEG SN sequence.

Taking this, we have that:

1.-the final RTP SN space has one gap for each retransmission. This doesn't
mean that these gaps cannot be identified. When you lose packets, as Rahul
says, you cannot identify how many of them where first transmissions or
retransmissions, because you don't know which RTP SN used the server to
re-transmit the requested packet. But, if you lose packets you request them
and the server uses the RTX header for retransmissions.

2.-The RTX header carries the SNs used for first transmissions and all
(possibly) subsequent retransmissions. When a retransmission comes, it
parses the RTX header and knows WHY the gaps happened: either were they 1st
transmissions or retranmissions. Each gap is identified.  AS LONG AS ALL
retransmissions arrive, ALL gaps can be identified as corresponding to
retransmissions or first transmissions. That is, as long as all
retransmissions arrive the MPEG SN space is restored and has no gaps because
the receiver knows WHERE the retransmissions happened.

Example:

Legend: x|y means packet with RTP SN =y carries is Retransmission of packet
with RTP SN = x.

		Server			Client

MPEG SN	RTP SN
1		1 	(gets lost)
2		2 			2 arrives
3		3			3 arrives
**Server receives RTX Request for RTP SN =1 **
1		4|1			4 arrives, RTX of packet 1
4		5			5 arrives

In this case the client obtains a RTP SN space = { 1,2,3,5} but it is
COMPLETELY SURE that RTP SN = 4 was a RTX for RTP SN = 1 and that 5 comes
IMMEDIATELY after 3. Thus, the MPEG SN space is continuous = { 1*(1), 2*(2),
3*(3), 4*(5)}
, where x*(y) indicates MPEG SN x* sent in packet with RT SN y.

3.- Let's now consider the case that retransmissions of a packet cannot
arrive at the receiver and the packet times out: if this packet in
particular was sent three times with RTP SNs: 3, 6, 9 the final RTP SN space
will have three gaps and the receiver has no way to know that they actually
belong to the same packet. Similarly the MPEG SN space will also have three
gaps.

		Server			Client

MPEG SN	RTP SN			RTP SN
1		1 			1 arrives
2		2 			2 arrives
3		3   	(gets lost)
4		4			4 arrives, gap detected, send RTX Req for RTP SN =3
5		5			5 arrives
** Server receives RTX Req for RTP SN = 3 **
3		6|3	(gets lost)
6		7			7 arrives, gap detected, send RTX Req for RTP SN =6
7		8			8 arrives
** Server receives RTX Req for RTP SN = 6 **
3		9|6|3	(gets lost)
8		10			10 arrives, gap detected, send RTX Req for RTP SN =9
9		11			11 arrives
** Server receives RTX Req for RTP SN = 9 **
** Server doesn't send any more RTXs of packet RTP SN =3 because it is
outdated **

Resulting SN spaces are:

RTP SN ={ 1,2,4,5,7,8,10,11} -> three gaps.

MPEG SN ={1*, 2*,3?*,4*,5*, 6?*,7*,8*,9?*,10*,11*} -> also three gaps

This means that the receiver is sure that 1-2, 4-5, 7-8, 10-11 are pair-wise
immediately successive but doesn't know what happens with 3*,6*,9*.

In this case the client would have to look in the TS to resolve correct
ordering or hand-over this uncertainty to the application, for example.

Another solution would be to add a 2 byte header to each packet. This header
would carry the number of retransmissions that took place before sending the
packet. Even if you loose retransmissions in this case the client can
reconstruct the exact MPEG SN space at any instant: MPEG SN = RTP SN - No.of
RTXs.

I hope this clears up any misunderstanding. I wonder whether this is really
a problem for applications such as Rahul described. Should this be solved by
the application or by the transport layer?

Looking forward to your feedback,

Jose

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