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

From: Rahul Agarwal <[email-masked]>
Date: Fri, 31 May 2002 15:40:49 -0700

In reviewing the Selective Retransmission Draft 
(draft-ietf-avt-rtp-selret-04.txt), we came across an issue that we would 
like to highlight and solicit opinion on.

Per Section 4.2, rule 4:
"The RTP sequence number MUST be increased by one to the previous RTP 
packet and the timestamp and marker bit MUST be set to the values of the 
original transmission's RTP header. "

Resent packets share the same sequence space as the normal packets. Since a 
resent packet consumes a sequence number, the sequence number for the 
original data packets do not increase linearly. In certain circumstances 
where resent packets are not fully recovered by the client, it makes it 
impossible for the client to re-construct the proper sequencing of data 
packets.

Consider the following example:

Say original data packets from the source are P1, P2......Pn and the 
sequence numbers used to send these packets are 1, 2,.....

Pi(k) indicates a Data Packet i sent with an RTP sequence number k

Server sends P1(1), P2(2), P3(3), P4(4), P5(5)
Client receives: 1, 2, 4
Client sends resend request for 3
Server receives resend request for 3
Server sends P3(6) -- a resent packet with internal sequence number 3
Server sends P6(7) -- original data packet number 6
Client receives 7 (and misses both 5 and 6)
So, from the client''s perspective, it has received the following packets:
1, 2, 4, 7.

It should have ideally given out the packets in the following sequence to 
the upper layer:
P1, P2, Lost, P4, Lost, P6

However, just by looking at the sequence number, the client has no way to 
derive this information.  It will probably deduce the following:
P1, P2, Lost, P4, Lost, Lost, P7

which is clearly wrong.

Please advise.

- Rahul

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