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

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

Hi Rahul and all,

first of all, sorry for the long silence...

please see my comments below,

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag von Rahul
> Agarwal
> Gesendet: Samstag, 1. Juni 2002 00:41
> An: [email-masked]
> Betreff: [AVT] Sequence issue with draft-ietf-avt-rtp-selret-04.txt
>
>
> 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

The problem described by Rahul is correct. The selret draft describes a
one-session approach to deal with retransmissions in RTP. Thus, when using
selret, the receiver application gets a SN space with gaps in it (1 for each
retransmission). A SN-based application could not use this SN-space to
reconstruct the correct frame sequencing.

However, this issue was already discussed in the IETF#50, where we presented
our draft-ietf-avt-selret-01.txt. The conclusion was reflected in the AVT
meeting report:

----snip --from Meeting Report IETF#50
"Carsten Burmeister then presented an RTP Retransmission Payload Format
(draft-ietf-avt-rtp-selret-01.txt). Note that IPR exists on this draft. The
draft has changed since the last meeting, and now comprises two parts: 1) an
RTP payload format for retransmitted packets which implies that
retransmissions get a new sequence number from the original space, so their
loss can be detected (the original seqnum is sent in the payload header); 2)
a low priority payload format with a different sequence number space for the
"important" packets which is used to enable receiver to report only
important packet losses.

Open issues include: non-constant SN-TS relation when retransmissions occur
(but this also occurs due to silence suppression, so this is not a problem),
and gaps in the received sequence number space (as seen by the application,
not in the RTP packets) once the data has been recovered (this is an
application design issue, not a protocol issue)."
----snip---from Meeting Report IETF#50

No further comments were heard from the WG.

Based on this we continued our work on the draft.

Rahul's email expresses interest on having a one-session solution which
enables the receiver application to reconstruct the right frame sequencing
based on the SN.

It is for this reason that, at this point, it may be necessary to re-visit
the issue. Therefore, the WG's opinion is kindly asked on whether the selret
draft should include a solution for SN-based applications or the gaps in the
SN-space remains to be an application issue, NOT to be solved by the
protocol.

thanks,

Jose

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

---

From: Rahul Agarwal <[email-masked]>
Date: Fri, 14 Jun 2002 18:22:36 -0700

Hello Jose and all,

Good to hear from you.

We apologize for not being closely involved with RTP re-transmission drafts 
in earlier IETF meetings but Real's position is to solve the sequencing 
issue at the transport layer and NOT at the application layer.

 From our perspective, it is really important for any transport to 
guarantee delivery of packets (lost or otherwise) in the same order they 
were generated/sent by the server. A lot of A/V formats rely on this 
transport behavior. To name a few:

- MPEG4 video - RFC3016 -
Packets with *same* time stamp need to be concatenated together to form 
coded frames. Concatenation needs to occur in sequence based on sequence 
numbers (or the derived sequence numbers based on the order in which 
packets were received) and accurate indication of loss, if any.

- AAC audio: mpeg4-generic
Our implementation counts on received sequence being correct. While it may 
be possible to change the algorithm to operate reliably without this 
assumption, it would certainly make it more complicated.

- RealAudio/RealVideo
RealAudio packets may be interleaved. The RealAudio Decoder/Renderer relies 
on getting accurate loss report and packet sequencing from the transport to 
properly de-interleave packets.

Many companies have built Plugins on the RealMedia Architecture on the 
premise that sequencing of packets, including accurate loss report is 
guaranteed by the underlying transport.

I think it is fair to say that a bare minimum feature expected from any 
transport used for MultiMedia is preservation of packet sequencing from 
delivery to reception.

Using the same session for re-transmissions definitely has advantages, if 
we can solve the sequence issue without incurring a substantial per-packet 
overhead.

- Rahul

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Jun 2002 19:42:01 -0400

Hi Rahul,

I'm somewhat surprised by your comments: the Internet, and RTP in turn,
does not guarantee to deliver packets in sequence. Reordering can - and
frequently does - occur, and RTP implementations are expected to be able
to compensate. 

See V. Paxson,  End-to-End Internet Packet Dynamics. IEEE/ACM Transactions
on Networking, Vol.7, No.3, pp. 277-292, June 1999 (available online at
ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-ton99.ps.gz) for background.

Colin

---

From: Rahul Agarwal <[email-masked]>
Date: Thu, 20 Jun 2002 17:43:01 -0700

Sorry for not being clear.

What I mean by packet sequencing requirement is that the receiver should be 
able to re-construct packet sequencing for the original data packets based 
on the sequence number of the received packets, whether they arrive late, 
out-of-order or get lost. This is not possible with the current selret 
draft since resend packets use the same sequence space as the original packets.

As Jose mentioned, a SN-based application cannot use this SN-space to 
reconstruct the correct frame sequencing. In case of loss of multiple 
packets, the receiver has no way to determine if all the the lost packets 
were original data packets or included some resent packets as well.

If a server needs to send "n" packets for a given stream and exactly "m" do 
not make it to the client even after multiple resend attempts, the client 
should be able to derive that it missed exactly "m" packets and also which 
ones.

Hope this clears up any confusion.

- Rahul

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Jun 2002 13:29:20 -0400

>Hope this clears up any confusion.

Yes, thanks.

Colin