Subject: RE: [AVT] retransmission and SSRC-based multiplexing

From: Rahul Agarwal <[email-masked]>
Date: Mon, 24 Jun 2002 12:16:37 -0700

Increasing port usage is indeed a performance issue for high-scale RTP 
servers and/or middle-ware proxies.

If you consider just the client-server interaction, increasing the port 
usage for a typical source with two streams (A/V) from 4 to 8 does not seem 
that bad since each client can afford the increase from 4 to 8 and the 
server can "optimize" and multiplex ALL clients on the same 8 ports. 
However, increasing the port usage has a direct performance impact on 
middle-ware proxies since it will now have to open 8 ports back to the 
server for each client connection (assuming it "optimizes" client side 
connection and multiplexes all client connections on the same set of 8 ports).

Some Operating Systems have a per process File Descriptor limitation at 
1024. On such OSes, for every 128 clients (assuming file descriptors are 
not used for anything else), the server/proxy will have to spawn new 
processes. While this can be considered an implementation issue, using 
multiple processes and using inter-process communication is a real life 
performance issue for high-scale RTP Proxies.

I completely agree that SSRC multiplexing for *different* media streams is 
a bad idea. But doing it for resend packets for the *same* media stream 
should be ok, specially when it decreases the port usage and makes it for 
the most efficient design and implementation of resend support in RTP.

Considering that some servers using proprietary transport protocols can get 
away with using ONE port to multiplex A/V streams, a jump to 4 for using 
RTP is high enough. Increasing it to 8 may make it even harder for such 
servers to stop using proprietary protocols, specially at the expense of 
reduced performance.

- Rahul

At 02:29 PM 6/18/2002 -0500, [email-masked] wrote:
>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.
>
>
>
> > -----Original Message-----
> > 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,
> >
> > 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-retrans
> > mission-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
> >
> >
> >
> >
> >
>
>_______________________________________________
>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: Rahul Agarwal <[email-masked]>
Date: Fri, 28 Jun 2002 13:00:54 -0700

David,

I would really like to see an option to use SSRC multiplexing in your 
re-transmission draft. Since the cut-off date for the non-00 draft is July 
1st, I was wondering if you plan to add SSRC multiplexing support in your 
draft before then.

Thanks
- Rahul

At 12:16 PM 6/24/2002 -0700, Rahul Agarwal wrote:
>usage for a typical source with two streams (A/V) from 4 to 8 does not 
>seem that bad since each client can afford the increase from 4 to 8 and 
>the server can "optimize" and multiplex ALL clients on the same 8 ports. 
>Considering that some servers using proprietary transport protocols can 
>get away with using ONE port to multiplex A/V streams, a jump to 4 for 
>using RTP is high enough. Increasing it to 8 may make it even harder for 
>such servers to stop using proprietary protocols, specially at the expense 
>of reduced performance.
>
>- Rahul
>