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

From: [email-masked]
Date: Fri, 21 Jun 2002 15:10:38 -0500

Jose,
Please see my comments below.

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

As you said, this approach would require to add an extra (2-byte) field to *each* packet. It has to be emphasised that this field would have to be carried in both the retransmission packets and the first-time sent packets. As far as retransmission packets are concerned, you could add this field to your retransmission payload format. However, in the case of first-time sent packets, how could you include this field in the RTP packet?
This would require that you define another payload format whose purpose whould be to encapsulate the original RTP packet in this new packet type. In other words, you are creating an additional level of indirection. This also means that this new payload format should not only include this extra field but also the packet original payload.

For example, let's assume:
*The PT field for your new payload format is x
*The sender is sending some media whith PT value y

With the retransmission scheme you are suggesting, every time the sender wants to send new data, instead of simply sending RTP packets of payload type y, it has to send a packet:
*with the RTP header PT field set to x
*add this new payload format payload header which is composed of the actual media PT value x and the new 2-byte field.
*shift there the payload header and data of the actual media packet

The number of indirections is again increasing if you are sending a retransmission packet as you now have to indicate three PT values in your packet: x,y and the retransmission payload format.

Note also that the selret draft requires cumulative payload headers for multiple retransmissions, i.e. if a packet is retransmitted twice it has two RTX headers, if it retransmitted 3 times it has 3 RTX headers, etc..

So if a packet was for instance retransmitted twice, there would now be 5 payload type fields in this packet. 

Let's now assume that there would actually be defined such a payload format in order to carry this new number of retransmissions field.
What you are doing is in essence send two sequence numbers per packet:
*the total number of packets sent
*the sequence number of retransmitted packets (note that it is equivalent to send the sequence number of first-time sent packets since you can derive one from the other)
So it seems legimitate to think that if you need two sequence number spaces, a simpler solution would be to send the original packets and the retransmitted packets into two separate RTP streams.
Jose, please also refer to the thread on RTP retransmission and SSRC multiplexing as it was commented that it is beneficial to have the original and the retransmission streams multiplexed by the transport layer and not by the application.

David.

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

---

From: José Rey <[email-masked]>
Date: Mon, 24 Jun 2002 20:39:15 +0200

hi David and all,

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Freitag, 21. Juni 2002 22:11
> An: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: RE: Clarifications on [AVT] Sequence
> issuewithdraft-ietf-avt-rtp-selret-04.txt
>
>
>
>
> Jose,
> As you said, this approach would require to add an extra (2-byte)
> field to *each* packet. It has to be emphasised that this field
> would have to be carried in both the retransmission packets and
> the first-time sent packets.

Yes, this is correct.

> As far as retransmission packets are
> concerned, you could add this field to your retransmission
> payload format.

It isn't meant to be that way, but to consitute a new payload format for
itself, as follows:
1 bit reserved | 7 bit payload type | 8 bit rtxs. counter.

> However, in the case of first-time sent packets,
> how could you include this field in the RTP packet?
> This would require that you define another payload format

Exactly, a new 2-byte payload format, as above described.

> whose
> purpose whould be to encapsulate the original RTP packet in this
> new packet type. In other words, you are creating an additional
> level of indirection. This also means that this new payload
> format should not only include this extra field but also the
> packet original payload.
>
> With the retransmission scheme you are suggesting, every time the
> sender wants to send new data, instead of simply sending RTP
> packets of payload type y, it has to send a packet:
> *add this new payload format payload header which is composed of
> the actual media PT value x and the new 2-byte field.
> The number of indirections is again increasing if you are sending
> a retransmission packet as you now have to indicate three PT
> values in your packet: x,y and the retransmission payload format.
>
> Note also that the selret draft requires cumulative payload
> headers for multiple retransmissions, i.e. if a packet is
> retransmitted twice it has two RTX headers, if it retransmitted 3
> times it has 3 RTX headers, etc..
>
> So if a packet was for instance retransmitted twice, there would
> now be 5 payload type fields in this packet.
>

Let me please clarify, before this point causes more misunderstanding:
the new payload format would ONLY add 2-byte overhead ONCE per packet.

As you describe, the selret draft uses header chains (cumulative RTX payload
headers).
These are used to identify the gaps in the resulting RTP SN space. So, one
thing is
identifying the gaps in the RTP SN space and the other recovering the (let's
say)
MPEG SN space. That is, to restore the MPEG SN, the receiver only needs to
know
how many retransmissions took place before the FIRST transmission of the
packet,
thus the retransmission counter is only needed once, irregardless of the
number of
retransmissions (RTX headers) a packet experiences (carries). This is also
why this
new 2-byte payload format would be defined separately.

> Let's now assume that there would actually be defined such a
> payload format in order to carry this new number of retransmissions field.
> *the sequence number of retransmitted packets (note that it is
> equivalent to send the sequence number of first-time sent packets
> since you can derive one from the other)
> So it seems legimitate to think that if you need two sequence
> number spaces, a simpler solution would be to send the original
> packets and the retransmitted packets into two separate RTP streams.

I followed the SSRC-thread. The selret draft selret doesn't intend to define
different SSRCs for different payload types.
The fact that selret proposes to use the same SSRC for two different PTs is
nothing new. One example are audio sessions using some audio codec, e.g.
PCMU
or G.711, combined with RFC 2833 packets to indicate telephone events such
as
DTMF tones. I don't see how this could be a problem or is related to the
thread
you mention.

cheers,

Jose