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

From: [email-masked]
Date: Tue, 9 Jul 2002 14:38:24 -0500

Magnus,
Thanks for the detailed comments.
 
[Magnus] 
> Have you thought of allowing to use SEL payloads with this type of 
> retransmission? It seems possible and gives a possibility to preserve 
> back-channel bandwidth if it is scarce.

[David]
So far, we haven't considered using the selective payload format as we haven't found any performance gains with the older feedback timing rules.
We will of course reassess whether they sould be used when Jose's performance evaluation with the new timing rules is available.  

[Magnus] 
> The references to multicast usage is lacking notice about feedback 
> explosion. The type of retransmission in multicast that you described 
> can only practical in small groups. This should be addressed.

[David]
The feedback timing rules make sure that there is no feedback implosion. Am I missing something?

[Magnus] 
> What possibilities exist of using one retransmission session for 
> multiple original streams/sessions? It will save ports compared to 
> having one session for each original media session. It will 
> also allow 
> for more bandwidth be assigned to RTCP traffic to report lost 
> retransmissions. The only constraint I can think of is that 
> SSRC must be 
> unique between sessions. Also having unique original PTs would be an 
> advantage but not required.

[David]
This would be possible but imagine that you want to receive only one session, e.g. audio and not video. You would then be receiving the retransmission of the video session that you chose not to receive.

[Magnus]
> Section 5.
> The format is identical to Selret's format RTX with X=1 therefore I 
> would strongly recommend that you reference that instead. This would 
> make implementation easier in the future.

[David]
If the retransmissions are sent in the same session, the receiver must not expect that the first bit (X or E) of the payload to be 1. The receiver should know that since this packet is sent in a separate RTP stream, it will get the full SN. This bit can thus be kept as an extension bit when the retransmissions are sent in a separate session. We actually had some comments in the mailing list a while back that the retransmission payload format should have some reserved bits. 
Whether there should be cross-references among the drafts depends on whether or not the WG decide to merge these drafts.

[Magnus]
> Is there any motivation of the SHOULD instead of a MUST regarding the 
> SSRC that is used in the retransmission session. What is the rule if 
> they are not identical between the original and retransmission?

[David] The SHOULD is here to allow SSRC multiplexing of a stream and its retransmission stream. If they are not identical, they should be sent to the same port.

[Magnus]
> Section 6.1
> Shouldn't the should in the second paragraph be uppercase one?

[David]
Right.

[Magnus]
> The usage of T_rr_interval in the feedback should be 
> addressed in this 
> section. As I understand it the feedback implementation 
> should be told 
> that there is feedback to send and therefore the it will schedule 
> without taking T_rr_interval into account.

[David]
This section was writtten before the change of the timing rules. It needs to be updated with the new rules.
 
[Magnus] 
> Section
> 
> Section 9.
> This section is very thin and lacks much today. It needs to 
> specify how 
> the payload format is used. It also has to explain how the 
> retransmission session is connected to the original session. 
> If only a 
> single session is retransmitted in the same session perhaps a rule on 
> locality could be used. If multiple retransmission streams is in the 
> same session another mechanism is needed. Due to port 
> handling in RTSP 
> the port numbers can't be used.

[David]
This is an open issue.
I can see two approaches:
*requiring that the m line of the retransmission stream always be the m line following the original stream
*using the same approach as with the FEC payload format, i.e. using a single m line for the original stream and the retransmission stream and then use an fmtp line in the retransmission format to specify the original stream.
I find the first approach simpler. Can you see any shortcoming with it?

[Magnus]  
> What is the motivation that the retransmission channel uses the same 
> media type as the original media? It could be application for 
> all as it 
> is application stream.
> 
> How are you going to address timestamp rate  changes for the 
> RTX flow? 
> This is again the case of the original stream switching codec 
> to one of 
> a different rate.

[David]
I'm sorry but I'm not sure I understand these comments.

[Magnus] 
> Shouldn't rtx be register for media type application.
> 
> Section 10:
> The MIME registrations should have the AVT as author/change 
> controller 
> also.
> 
> Section 11:
> Due to the method used for retransmission there is a 
> possibility for two 
> time pads between the original stream and the retransmitted 
> one unless 
> they use different keys when encrypting using SRTP.

[David]
ok. This needs to be corrected.

Thanks again,
David. 

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