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

From: [email-masked]
Date: Thu, 13 Jun 2002 16:24:53 -0500

Rahul and all,

As I haven't seen any answers to your review of draft-ietf-avt-rtp-selret-04.txt sent to the mailing list, I'd like to say that I share your concern about the use of the sequence number. 
As you noted, if the receiver detects a gap sequence number, it doesn't know if there is a gap in the user data or not. This also means that the receiver cannot derive whether it should request the missing sequence number. If the gap in sequence number is because of missing user data, it would typically have this packet retransmitted. However, if the gap in sequence number does not map to a gap in the user data, the receiver might not want to request this sequence number (as the missing packet carried older data).

David.   

> 
> 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
> 

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