Subject: [AVT] retransmission and SSRC-based multiplexing

From: [email-masked]
Date: Mon, 17 Jun 2002 15:52:36 -0500

Hello,
 
As requested at the last WG meeting, the RTP retransmission framework draft now includes an applicability statement and can be found at http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-01.txt 
We would like to hear any comments you may have on this applicability statement and draw your attention on the following point.
The draft requires that two separate sequence number spaces be used for the original stream and the retransmission stream. As noted in the applicability statement, this requires that the retransmission stream have a separate addresse/port. If setting additional ports for the retransmission stream is a concern for some implementers, we would like to ask feedback from the working group whether it would be acceptable to use SSRC based multiplexing for the original and the retransmission stream instead of port multiplexing.
We had proposed SSRC based multiplexing for retransmission back in August 2001 at the IETF meeting in London. It was commented that since the SSRC is a random number chosen by the RTP sender, it would not be possible to associate  original stream and retransmission stream in a multicast group.
However, in unicast we believe that SSRC based multiplexing could be used. Let's imagine that an RTP receiver receives the original stream and retransmission stream on the same multicast address/port. Since the receiver knows the payload types used by the original stream and the retransmission stream, it would be able to derive which SSRC corresponds to the original data and which SSRC corresponds to retransmissions. 
So would like to  propose that in the multicast case, separate address and/or port be used as described in the draft but to allow in unicast the retransmission stream to be either multiplexed based on the port or the SSRC.
We are aware that multiplexing RTP streams based on SSRC and payload type should generally be avoided. Section 5.2 of the RTP states that "Separate audio and video streams SHOULD NOT be carried in a single  RTP session and demultiplexed based on the payload type or SSRC fields". However, in the case of retransmission, it is the same media sent in both streams.
 
We would thus like to hear feedback whether there is any objection to update the draft to allow the use of SSRC-based multiplexing for unicast retransmission.
 
Thanks, David.

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 17 Jun 2002 14:15:53 -0700

David,
   Did you consider addressing SRTP usage in the Security Considerations
section of your I-D?

Mark
At 03:52 PM 6/17/2002 -0500, [email-masked] wrote:
>Hello,
>
>As requested at the last WG meeting, the RTP retransmission framework 
>draft now includes an applicability statement and can be found at 
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-01.txt
>We would like to hear any comments you may have on this applicability 
>statement and draw your attention on the following point.
>The draft requires that two separate sequence number spaces be used for 
>the original stream and the retransmission stream. As noted in the 
>applicability statement, this requires that the retransmission stream have 
>a separate addresse/port. If setting additional ports for the 
>retransmission stream is a concern for some implementers, we would like to 
>ask feedback from the working group whether it would be acceptable to use 
>SSRC based multiplexing for the original and the retransmission stream 
>instead of port multiplexing.
>We had proposed SSRC based multiplexing for retransmission back in August 
>2001 at the IETF meeting in London. It was commented that since the SSRC 
>is a random number chosen by the RTP sender, it would not be possible to 
>associate  original stream and retransmission stream in a multicast group.
>However, in unicast we believe that SSRC based multiplexing could be used. 
>Let's imagine that an RTP receiver receives the original stream and 
>retransmission stream on the same multicast address/port. Since the 
>receiver knows the payload types used by the original stream and the 
>retransmission stream, it would be able to derive which SSRC corresponds 
>to the original data and which SSRC corresponds to retransmissions.
>So would like to  propose that in the multicast case, separate address 
>and/or port be used as described in the draft but to allow in unicast the 
>retransmission stream to be either multiplexed based on the port or the SSRC.
>We are aware that multiplexing RTP streams based on SSRC and payload type 
>should generally be avoided. Section 5.2 of the RTP states that "Separate 
>audio and video streams SHOULD NOT be carried in a single  RTP session and 
>demultiplexed based on the payload type or SSRC fields". However, in the 
>case of retransmission, it is the same media sent in both streams.
>
>We would thus like to hear feedback whether there is any objection to 
>update the draft to allow the use of SSRC-based multiplexing for unicast 
>retransmission.
>
>Thanks, David.
>

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 18 Jun 2002 09:18:01 +0300

Hi,
I think that one of the advantage of IP communication and RTP is that the
streams are multiplexed by the transport layer, and not by the application,
This gives flexibility in deciding where each stream will go, I do not like
the circuit switch where you have to multiplex in the application. Changing
that will be a mistake.
Regards
Roni Even
Polycom

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, June 17, 2002 11:53 PM
> To: [email-masked]
> Subject: [AVT] retransmission and SSRC-based multiplexing
> Importance: High
> 
> 
> Hello,
>  
> As requested at the last WG meeting, the RTP retransmission 
> framework draft now includes an applicability statement and 
> can be found at 
> We would like to hear any comments you may have on this 
> applicability statement and draw your attention on the 
> following point.
> The draft requires that two separate sequence number spaces 
> be used for the original stream and the retransmission 
> stream. As noted in the applicability statement, this 
> requires that the retransmission stream have a separate 
> addresse/port. If setting additional ports for the 
> retransmission stream is a concern for some implementers, we 
> would like to ask feedback from the working group whether it 
> would be acceptable to use SSRC based multiplexing for the 
> original and the retransmission stream instead of port multiplexing.
> We had proposed SSRC based multiplexing for retransmission 
> back in August 2001 at the IETF meeting in London. It was 
> commented that since the SSRC is a random number chosen by 
> the RTP sender, it would not be possible to associate  
> original stream and retransmission stream in a multicast group.
> However, in unicast we believe that SSRC based multiplexing 
> could be used. Let's imagine that an RTP receiver receives 
> the original stream and retransmission stream on the same 
> multicast address/port. Since the receiver knows the payload 
> types used by the original stream and the retransmission 
> stream, it would be able to derive which SSRC corresponds to 
> the original data and which SSRC corresponds to retransmissions. 
> So would like to  propose that in the multicast case, 
> separate address and/or port be used as described in the 
> draft but to allow in unicast the retransmission stream to be 
> either multiplexed based on the port or the SSRC.
> We are aware that multiplexing RTP streams based on SSRC and 
> payload type should generally be avoided. Section 5.2 of the 
> RTP states that "Separate audio and video streams SHOULD NOT 
> be carried in a single  RTP session and demultiplexed based 
> on the payload type or SSRC fields". However, in the case of 
> retransmission, it is the same media sent in both streams.
>  
> We would thus like to hear feedback whether there is any 
> objection to update the draft to allow the use of SSRC-based 
> multiplexing for unicast retransmission.
>  
> Thanks, David.
>

---

From: [email-masked]
Date: Tue, 18 Jun 2002 10:43:50 +0200

David,

I would favor UDP port multiplex too
and BTW I dont remember what was listed
as  *advantage(s)* of using SSRC ?

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.mpeg-4.philips.com

                      David.Leon@nokia                                                                                                 
                      .com                         To:  <[email-masked]>                                                                 
                      Sent by:                     cc:  (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS)                                     
                      [email-masked]             Subject:   [AVT] retransmission and SSRC-based multiplexing                         
                      rg                                                                                                               
                                                   Classification:                                                                     
                                                                                                                                       
                      17/06/2002 22:52                                                                                                 

Hello,

As requested at the last WG meeting, the RTP retransmission framework draft now includes an applicability statement and can be found at http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-01.txt
We would like to hear any comments you may have on this applicability statement and draw your attention on the following point.
The draft requires that two separate sequence number spaces be used for the original stream and the retransmission stream. As noted in the applicability statement, this requires that the retransmission stream have a separate addresse/port. If setting
additional ports for the retransmission stream is a concern for some implementers, we would like to ask feedback from the working group whether it would be acceptable to use SSRC based multiplexing for the original and the retransmission stream instead of
port multiplexing.
We had proposed SSRC based multiplexing for retransmission back in August 2001 at the IETF meeting in London. It was commented that since the SSRC is a random number chosen by the RTP sender, it would not be possible to associate  original stream and
retransmission stream in a multicast group.
However, in unicast we believe that SSRC based multiplexing could be used. Let's imagine that an RTP receiver receives the original stream and retransmission stream on the same multicast address/port. Since the receiver knows the payload types used by the
original stream and the retransmission stream, it would be able to derive which SSRC corresponds to the original data and which SSRC corresponds to retransmissions.
So would like to  propose that in the multicast case, separate address and/or port be used as described in the draft but to allow in unicast the retransmission stream to be either multiplexed based on the port or the SSRC.
We are aware that multiplexing RTP streams based on SSRC and payload type should generally be avoided. Section 5.2 of the RTP states that "Separate audio and video streams SHOULD NOT be carried in a single  RTP session and demultiplexed based on the
payload type or SSRC fields". However, in the case of retransmission, it is the same media sent in both streams.

Thanks, David.

---

From: [email-masked]
Date: Tue, 18 Jun 2002 14:29:57 -0500

Philippe and Roni, 

Thanks for the comments on SSRC multiplexing. I agree that it's better to used port multiplexing rather than SSRC multiplexing. The only advantage of using SSRC in unicast would be to minimise the number of ports used by the application.
The draft applicability statement mentions:
   This retransmission scheme requires a separate RTP session to send
   retransmitted packets. As a consequence, two additional ports are
   needed: one port for the RTP retransmission stream and one port for
   the associated RTCP. While this is generally not a problem, the
   implementers should assess the implications in the targeted
   environment.
So I'd like to hear if anyone has real-life problems with the number of ports used for retransmission (and if yes, why). If no problems are reported, then SSRC multiplexing will not be considered in the draft.

David.

> From: ext [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, June 18, 2002 3:44 AM
> To: Leon David (NRC/Dallas)
> Cc: [email-masked]
> Subject: Re: [AVT] retransmission and SSRC-based multiplexing
> 
> 
> 
> David,
> 
>                       .com                         To:  
> <[email-masked]>                                                
>                       [email-masked]             Subject:   
> [AVT] retransmission and SSRC-based multiplexing              
>            
>                       rg                                      
>                                                               
>            
>                                                    
> Classification:                                               
>                       
>                                                               
>                                                               
>            
>                       17/06/2002 22:52                        
>                                                               
>            
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
> 
> 
> 
> 
> Hello,
> 
> addresse/port. If setting
> additional ports for the retransmission stream is a concern 
> for some implementers, we would like to ask feedback from the 
> working group whether it would be acceptable to use SSRC 
> based multiplexing for the original and the retransmission 
> stream instead of
> port multiplexing.
> original stream and
> types used by the
> original stream and the retransmission stream, it would be 
> able to derive which SSRC corresponds to the original data 
> and which SSRC corresponds to retransmissions.
> be carried in a single  RTP session and demultiplexed based on the
> payload type or SSRC fields". However, in the case of

---

From: [email-masked]
Date: Tue, 18 Jun 2002 15:53:09 -0500

Mark,
The retransmission draft does not address SRTP usage but this could be included in the next revision. I guess the issue with retransmission is whether the original and retransmission streams could/should use the same master key.
Please let me know if you have any recommendations on the interactions of SRTP and RTP retransmission.
Thanks, David.
 
> framework