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

From: [email-masked]
Date: Tue, 25 Jun 2002 11:35:03 -0500

Jose,

[David]
> >
> > 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)
> 

[Jose]
> 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]
You are sending in every packet a variable which is incrementing by one for every packet retransmission you send. You may call this variable retransmission counter or retransmission sequence number as you prefer.

I find it helpful to refer to it as a retransmission sequence number since this is the sequence number that you would send in the retransmission stream if you were sending it as a separate stream. Therefore, your proposal is in essence to encapsulate this retransmission sequence number space (or retransmission counter) in the RTP stream which is equivalent to sending two sequence number spaces per RTP stream. 

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

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

[David]
I don't see how this is related to your proposal of defining an RTP encapsulation format.

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

[David]
I do not see why you would not find it appropriate that I added to draft-ietf-avt-retransmission-01.txt the solution based on SSRC multiplexing that I proposed if it turns out there is a consensus that it is a better way of solving both reliable user data loss detection and minimising the number of ports than your proposal of defining a new RTP encapsulation payload format for that purpose.
SSRC multiplexing for retransmission would belong naturally to the draft-ietf-avt-retransmission-01.txt approach. It is based as described in the draft on two separate streams with their own SN spaces and separate RTP statistics. I do not see why you would want to include this idea in your draft based on a single RTP stream and sequence number sharing.

In my original message there were some questions on your proposal that you have not answered. Could you please follow up on that? I'm copying these questions below:

[Jose]
> Let me please clarify, before this point causes more misunderstanding:

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

[Jose]
> This is also
> why this
> new 2-byte payload format would be defined separately.

[David]
What do you mean when you say "this new 2-byte payload format would be defined separately" ?

[David]
Also I commented on the efficiency of the payload format and I would appreciate if you could follow up on that as well.
You can find my comments sent on June 11 at:
http://www1.ietf.org/mail-archive/working-groups/avt/current/msg01288.html

Thanks, David.

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

---

From: José Rey <[email-masked]>
Date: Wed, 26 Jun 2002 19:32:50 +0200

Hi David and all,

see inline...

(note that not all questions are replied, I'll do it as time allows)

> You are sending in every packet a variable which is incrementing
> by one for every packet retransmission you send. You may call
> this variable retransmission counter or retransmission sequence
> number as you prefer.
>
> I find it helpful to refer to it as a retransmission sequence
> number since this is the sequence number that you would send in
> the retransmission stream if you were sending it as a separate
> stream. Therefore, your proposal is in essence to encapsulate
> this retransmission sequence number space (or retransmission
> counter) in the RTP stream which is equivalent to sending two
> sequence number spaces per RTP stream.
>
>

Let's just call them RTP SN and RTX counter.

> I do not see why you would not find it appropriate that I added
> to draft-ietf-avt-retransmission-01.txt the solution based on
> SSRC multiplexing that I proposed if it turns out there is a
> consensus that it is a better way of solving both reliable user
> data loss detection and minimising the number of ports than your
> proposal of defining a new RTP encapsulation payload format for
> that purpose.
> SSRC multiplexing for retransmission would belong naturally to
> the draft-ietf-avt-retransmission-01.txt approach. It is based as
> described in the draft on two separate streams with their own SN
> spaces and separate RTP statistics. I do not see why you would
> want to include this idea in your draft based on a single RTP
> stream and sequence number sharing.
-------------------

> In my original message there were some questions on your proposal
> that you have not answered. Could you please follow up on that?
> I'm copying these questions below:
>
> [Jose]
> Am I mistaken to say that if you retransmit a packet twice, this
> packet would carry 5 payload type fields?
>

This is NOT correct.

The correct PT sequence for the second retransmision of a packet would be:

RTP header - PT=RTX | RTX header1 - PT=RTX | RTX header2 - PT=RTXcounter |
RTX counter - PT=media, e.g. MPEG4 video|

Total 4 PT fields

and for the third:

RTP header - PT=RTX | RTX header1 - PT=RTX | RTX header2 - PT=RTX |  RTX
header3 - PT=RTXcounter |RTX counter - PT=media, e.g. MPEG4 video|

Total 5 PT fields.

> would be defined separately" ?

This means as a third payload format in the draft.

>
> [David]
> Also I commented on the efficiency of the payload format and I
> would appreciate if you could follow up on that as well.

There's been a change in the SEL payload format. In previous versions SEL
wouldn't allow to report the loss of packets not marked as important. This
has changed. In draft-ietf-avt-rtp-rtp-selret-05.txt it is allowed to send
feedback on every lost packet as long as there's enough RTCP feedback
bandwidth. The only requirement is the losses of important packets are
reported BEFORE the losses of other less important packets. This ensures a
quality as constant as possible at the receiver, that is WITHOUT abrupt
changes, because the maximum number of important packets (for the given
bandwidth) reached the receiver.

Taking this, your comment below (taken from the url above) is no longer
valid:

> [David]
> Let me illustrate what the penalty of requesting only some of the
> packets could be. In your above example, if the selective payload
> format is used and the only packet loss is a P frame, this packet
> will not be retransmitted.
> On the other hand, if no selective payload format is used, the
> sender will be able to know about the loss of this P frame. It
> may then decide to retransmit the packet and adapt to a lower rate.
>
> David.
>
>

Therefore, if the RTCP feedback bandwidth is limited you can ensure by using
SEL that the maximum number of important losses will be reported (and
eventually be retransmitted and reach the client) as allowed by the current
RTCP bandwidth and forward link conditions.

Two observations about SEL:
1.-in a retransmission scheme without such selective mechanism it happens
that the loss of less important packets may be reported before the ones of
the more important, as the client doesn't know which packets are more
important than others. This has as a consequence that when receiving
feedback for the more important (which would have come earlier if using
SEL), it may already be too late. This means that the receiver would have
variable reception quality, with abrupt changes. SEL enables this
selectivity at RTP level.
2.-what's more, the importance of the packets doesn't have to be fixed
apriori. For example, if the server sees that the client has enough
bandwidth to send more retransmission of important packets then it marks
more RTP packets as important (e.g. the I frames and 2 P-frames after every
I-frame). This allows the server to adaptively provide the client with the
best video quality.
While it can be argued that this last item (2) is possible also at
application level, the benefit of SEL is that everything remains at the
transport level, avoiding interactions with the application who know about
the importance of each packet, e.g. the encoder. The processing is thus
minimised.

cheers,

Jose