Subject: RE: [AVT] Comments on draft-ietf-avt-rtp-retransmission-04.txt

From: [email-masked]
Date: Thu, 9 Jan 2003 12:07:04 -0600

Hi Colin,

Thanks for the review.

> 
> I've just read the -04 version of the retransmission draft. 
> It seems to be
> in reasonably good shape, but I do have some questions and comments:
> 
>  - At the end of section 3.1, after discussing the choice 
> between SSRC and
>    session multiplexing, the draft states "both multiplexing 
> approaches
>    SHOULD be supported". Is this intended to be a requirement 
> for both the
>    sender and receiver? 

Yes. We can write this explicitly.

> 
>  - In section 4, the draft mentions the possibility that the 
> retransmission
>    stream may include packets with multiple clock rates. How 
> is this to be
>    signalled in the SDP?

The retransmission RTP stream is no different from the original RTP stream in this regard. If multiple payload types are used, each payload type must be declared in the SDP and its clockrate is given by the rtpmap attribute.

> 
>  - In section 4, the draft states that and profile-specific 
> payload header
>    must be included in the retransmitted packet. Is this sent 
> before the
>    OSN payload header or after it?

The retransmission payload header should precede the payload of the original packet, including its payload header. This needs to be clarified in the draft.

> 
>  - Section 4 is unclear how RTCP for the retransmission 
> stream is handled.
>    Is the sender expected to send periodic SDES and SR reports? BYEs? 

We have been working under the assumption that the retransmission stream MUST follow the same RTCP rules as any other RTP stream.  We can of course write this in the draft.  
My understanding is that a payload format cannot modify the RTCP rules. Only a profile document can specify different rules. Is it so?
> 
>  - In section 5.3, the description of how to associate 
> streams when SSRC
>    multiplexing is used seems error-prone. Would it not be possible to
>    signal the mapping explicitly?

There could only be an error in the association if two streams use the same CNAME, same payload type and retransmit the same packet number at the same time. The probability is intuitively very low, in particular given that these two streams should have chosen different initial packet sequence numbers. If in addition the receiver follows the draft recommendation of not requesting the same sequence number for these two streams at the same time, the risk of the association to fail seems negligible.

The only way I can see how to make the mapping more explicit, would be to add the original stream SSRC in the retransmission payload header. This would make the payload header 6 bytes instead of 2 bytes. I'd rather keep the payload header as it is now. 

> 
>  - In section 6.1, when the original and retransmission 
> streams are sent
>    in the same RTP session, how are the RTCP timing rules 
> modified? Does
>    the sender get twice the RTCP bandwidth since it appears 
> as two SSRCs?

Here again, we thought that the RTP retransmission stream had to be treated like any other RTP stream as far as the RTCP timing rules are concerned. This means that we can't specify the fraction of the RTCP bandwidth available for the retransmission stream separatly. 
The original stream and the retransmission stream are seen as two independent senders that are sharing the RTCP bandwidths allocated to senders in the session as would any other sender do.

> 
>  - In section 6.2, a pointer to the RTCP Reporting Extensions 
> draft may be
>    appropriate, since that defines a receiver RTT report.
> 

My concern is that this would introduce one more dependency.

>  - In section 8, note that the correct syntax is 
> "a=fmtp:<number> ...".

Could you please point out which line in Section 8 is incorrect?

> 
>  - In section 12, how does this draft affect SRTP? Is it 
> possible to use 
>    the two formats together?

We'll try to draft something on that. My understanding is that the retransmission stream is seen as any other stream by SRTP and there should thus be no problem. 

> 
> I also think it would be appropriate if this draft describes 
> the level of
> reliability that can be expected from a session using 
> retransmission, and
> perhaps describes when this is acceptable, and when TCP 
> should be used?

Ok.

Thanks.

David.

> 
> Regards,
> Colin
> _______________________________________________
> 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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 09 Jan 2003 22:38:46 -0500

Hi,

(inline)

--> [email-masked] writes:
...
>>  - Section 4 is unclear how RTCP for the retransmission stream is handled.
>We have been working under the assumption that the retransmission stream
>MUST follow the same RTCP rules as any other RTP stream.  We can of course
>write this in the draft.  My understanding is that a payload format cannot
>modify the RTCP rules. Only a profile document can specify different rules.
>Is it so?

Yes, but the draft gave me the impression something different was intended.
A sentence to clarify would be helpful.

>>  - In section 5.3, the description of how to associate streams when SSRC
>There could only be an error in the association if two streams use the
>same CNAME, same payload type and retransmit the same packet number at the
>same time. The probability is intuitively very low, in particular given
>that these two streams should have chosen different initial packet sequence
>numbers. If in addition the receiver follows the draft recommendation of
>not requesting the same sequence number for these two streams at the same
>time, the risk of the association to fail seems negligible.
>
>The only way I can see how to make the mapping more explicit, would be to
>add the original stream SSRC in the retransmission payload header. This
>would make the payload header 6 bytes instead of 2 bytes. I'd rather keep
>the payload header as it is now. 

Can we not prohibit the situation from occuring? You can always choose to
use non-clashing payload types, to avoid the problem?

>>  - In section 6.1, when the original and retransmission streams are sent
>>    in the same RTP session, how are the RTCP timing rules modified? Does
>>    the sender get twice the RTCP bandwidth since it appears as two SSRCs?
>
>Here again, we thought that the RTP retransmission stream had to be
>treated like any other RTP stream as far as the RTCP timing rules are
>concerned. This means that we can't specify the fraction of the RTCP
>bandwidth available for the retransmission stream separatly. The original
>stream and the retransmission stream are seen as two independent senders
>that are sharing the RTCP bandwidths allocated to senders in the session as
>would any other sender do.

Okay, but the draft says "the receiver sends report blocks for the original
and the retransmission streams in the same RTCP RR packet". It is not clear
that two separate RTP sessions are used.

>>  - In section 6.2, a pointer to the RTCP Reporting Extensions draft may be

Doesn't have to be a normative reference...

>Could you please point out which line in Section 8 is incorrect?

It says:
	a=fmtp <number>: rtx-time=<rtx-time-val> 
but should be:
	a=fmtp:<number>  rtx-time=<rtx-time-val> 

(i.e. the ":" is in the wrong place)

>>  - In section 12, how does this draft affect SRTP? Is it possible to use 
>We'll try to draft something on that. My understanding is that the
>retransmission stream is seen as any other stream by SRTP and there should
>thus be no problem. 

I was not clear if retransmitting packets caused problems for SRTP; maybe
one of the SRTP authors can comment on any potential security issue?

Cheers,
Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Jan 2003 09:24:27 +0100

Hi,

as usual, see below:

>use non-clashing payload types, to avoid the problem?

Yes, you must use non colliding PTs however this is not the problem. The 
problem is if you have multiple senders doing SSRC multiplexing. When 
first receiving a retransmission packet you need to bind this new SSRC 
to the original streams SSRC so you know what stream the retransmission 
repairs.

The current proposal is to rely on the CNAME to know which SSRCs that 
comes from the same host. You also verify that retransmission packet 
belongs to a certain original stream by matching the OSN (Original 
Sequence Number) so that they actually match what you have requested. 
The corner case here is if a certain host using the same CNAME for two 
different sources (two SSRCs) sending with the same codec and both 
transmit at the same time. With an non negligible probability there can 
be losses in both original streams for the first requested 
retransmission (before binding between SSRCs are established) with 
identical RTP sequence numbers. In this case the request must not be 
sent for both losses. One has to first send one of them listen for 
response, verify it and make the binding, then request the other 
retransmission.

And actually this mechanism is not 100% infallible. In multicast 
sessions with one sender and many requesters and the retransmissions 
goes out on the multicast, a sender can be requested to retransmit both 
streams with equal sequence number at the same time. However this 
probability is not that big, but as it exist the draft should recommend 
receiver to continue evaluate the mapping. To me it seems that any 
mechanism for evaluating this can never be 100 % sure that the mapping 
is correct. But in my view this becomes only problematic in multicast 
sessions with SSRC multiplexing and retransmissions going out to all 
participants. In all unicast cases the mechanism proposed will work as 
there is a single requester that can ensure that two outstanding request 
for different streams does not have the same sequence number until the 
mapping is firmly established.

So my proposal is to add a note saying:

SSRC multiplexing SHALL NOT be used in multicast sessions where 
retransmission packets are sent in other ways then exclusively by 
unicast to the requester. This is due to possibility for erroneous 
mapping of the original SSRC to the retransmission SSRC. Use session 
multiplexing instead to avoid this ambiguity.

I think this is significant better than the 100% always working solution 
of adding a 32 bit Original SSRC field in the retransmission payload.

>Doesn't have to be a normative reference...
I agree, put it in as an informative one.

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Jose Rey <[email-masked]>
Date: Wed, 15 Jan 2003 17:53:23 +0100

Hi all,

thanks Colin and Magnus for your comments. Please see mine below.

...snip

> of adding a 32 bit Original SSRC field in the retransmission payload.

Magnus explains well the problem. Although one could argue the estimated
TS (by the receiver) would be helpful to distinguish the two streams in
this particular multicast case, there is still a chance that both TSs
are equal or close enough so that no distinction is possible. In
summary, better keep it simple and working :)

The proposed text will be included in the retransmission draft.

cheers,

Jose