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

From: [email-masked]
Date: Mon, 24 Jun 2002 16:37:28 -0500

Jose,

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

Ok. I guess it's fair to say that:
*if you are sending an RTP packet for the first-time you have to encapsulate the RTP packet in a newly defined RTP payload format which carries the retransmission sequence number.
*if you are retransmitting a packet, you have to encapsulate the original packet in this newly defined RTP packet which is itself encapsulated within the retransmission header.
*the length of  this newly defined retransmission sequence number field (1 or 2 bytes) has an impact on the reliability of the scheme.

> 
> > 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.
> >
> > 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 me please clarify, before this point causes more misunderstanding:

Am I mistaken to say that if you retransmit a packet twice, this packet would carry 5 payload type fields?

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

What do you mean when you say "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.
> > 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.
> 
> 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.

Let me try to clarify what I had in mind. 
We now have seen two proposals for retransmissions with both reliable user data loss detection and use of a minimum number of ports.
*My proposal to use two RTP streams multiplexed with different SSRCs
*Your proposal to use a single RTP stream with two sequence number spaces (regular RTP SN and a retransmission SN)
It was commented that a reason why not use SSRC multiplexing is that transport layer multiplexing would not be possible. I wanted to point out that with your proposal of single RTP sequence number encapsulation, transport layer multiplexing was not possible either. Therefore, if we have anyway to give up transport layer multiplexing in order to be able to perform both reliable loss detection and minimise the number of ports being use, it seems to me it would be a much better design to use SSRC multiplexing instead of RTP sequence number encapsulation.  

Hope this clarifies, 

David. 

> cheers,
> Jose

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

---

From: José Rey <[email-masked]>
Date: Tue, 25 Jun 2002 11:52:37 +0200

hi David and all,

[Jose]
> > DTMF tones. I don't see how this could be a problem or is

[David]
> We now have seen two proposals for retransmissions with both
> reliable user data loss detection and use of a minimum number of ports.
> *Your proposal to use a single RTP stream with two sequence
> number spaces (regular RTP SN and a retransmission SN)

This is not correct.

Please refer to my email to the AVT list from 21.06. You will see that:
1) there's no *retransmission SN* beign defined anywhere, but a
retransmission counter, as defined in:

[Jose]
>> 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.
>>

and,

2) there's STILL only one (1) SN-space.

[David]
> It was commented that a reason why not use SSRC multiplexing is
> that transport layer multiplexing would not be possible. I wanted
> to point out that with your proposal of single RTP sequence
> number encapsulation, transport layer multiplexing was not
> possible either.

Like I said in my last email, what we propose in selret draft is nothing
new:
using the same SSRC for different payload types is already used, for
example,
in point-to-point audio communication. We don't have to give up this
approach
because it is already being done out there in the real world.

The problem as I see it lies on your intention to adapt your
draft-ietf-avt-rtp-retransmission-01.txt to the one-session approach. The
retransmission proposal in draft-ietf-avt-selret-05.txt was designed to fit
the one-session approach and so is stated in the applicability statement in
both drafts. In designing the selret scheme one of the
conditions/requirements/design constraints taken into account was to allow a
retransmission scheme in ONE session. One of the main reasons for this is
that a one-session approach means less processing load for the servers and
this could be an issue.
At the 53rd IETF the inclusion of an applicability statement in both drafts
was decided. Following the Meeting, the authors of both proposals agreed on
the applicability statement during discussions offline. I quote from
selret's Applicability Statement: "The main difference between both
retransmission proposals (draft-ietf-avt-retransmission-01.txt and this) is
the way the retransmissions are sent, i.e. in the same RTP session for this
proposal and in an additional session for the "RTP Retransmission Framework"
proposal. We put our emphasis on the effects of this difference."

Therefore, the selret draft is THE one-session approach, as agreed at the
53rd IETF. Any enhancements on the one-session approach should be made in
the selret draft and not be added to the retransmission-01 proposal. Given
this fact, I don't see the need for the draft-ietf-avt-retransmission-01.txt
to consider this case.

thanks,

Jose