Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt

From: Thomas Zeng <[email-masked]>
Date: Mon, 3 Mar 2003 15:37:55 -0800

Magnus, Tom:

Another reason that ports are precious resource on the server is that, a
well designed
streaming server may be able to scale up to 10000 simultaneous clients
(which Microsoft's Windows Media server claims to support... I know
Microsoft today doesn't use RTSP but it may in the future). If each has 6
RTP tracks then there will not be enough ports to go around with Magnus
proposal.

Therefor I still think we must be prepared to resolve client SSRC conflict.
Someone suggested that we can put in the "contributing SSRC" field the
server's SSRC for that session. The combination of client SSRC and server
SSRC in the binding RTP packets would be certainly possible to ensure
uniqueness (since the server can choose its SSRC with no collision).

What do people think?

- thomas

-----Original Message-----
From: Tom Marshall [mailto:[email-masked]]
Sent: Monday, March 03, 2003 9:52 AM
To: Magnus Westerlund
Cc: Thomas Zeng; [email-masked]
Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-rtsp-nat-00.txt

On Mon, Mar 03, 2003 at 10:13:52AM +0100, Magnus Westerlund wrote:
> Hi Thomas,
> 
> Comments below:
> 
> Thomas Zeng wrote:
> 
> >Magnus:
> >
> >I have a comment on 3.2 Symetric RTP.
> >
> >As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server
> >normally uses a single RTP port (let's call it X) to send RTP packets to
> >many (potentially hundreds) of clients. Now Symetric RTP asks these
clients
> >to send an RTP packet with their individual client SSRC in the payload to
> >this port X on the server host. Since each client randomly generates
client
> >SSRC, there is some chance (as high as 10^-4 according to RFC1889,
section
> >8.1) that two clients may end up with same SSRC, in which case the server
> >may send RTP packets to wrong clients. I did study the SSRC collision
> >detection scheme in RFC1889 and found it irrelevant because it only
applies
> >to multicast RTP sessions. I don't think destination IP can help here
since
> >prior to the establishment of binding  our server doesn't know clients
> >public IPs. Besides, the two collided clients may well be behind the same
> >NAT and hence probably share public IP.
> > 
> >
> 
> My first comment is that the easiest way of solving this problem, is for 
> the server to send from different ports for each client. That way you 
> reduce the probability of collisions and ensures maximum security in 
> respect to hijacking.

This is a big resource drain on the server.  It effectively *triples* the
number of sockets you need to pass into select() or poll().  That is, for N
clients, the server must poll on 3*N sockets (one RTSP, RTP, and RTCP socket
per client) instead of 1*N+2 (one RTSP socket per client plus a fixed RTP
and RTP socket).

I can see an example server doing this, but I have doubts that commercial
code would be willing to take the hit.

-- 
"When competing for a section of road or a parking space, remember that the
vehicle in need of the most body work has the right-of-way."
        -- Massachusetts Driver Education Manual
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Mar 2003 10:34:00 +0100

Hi Thomas and Tom,

I understand your performance considerations. I know we have discussed 
this before on the teleconference. One reason raised for poor port 
performance was the lack of optimized implementations. For example 
linear search that of course give works performance as the number of 
ports increase.

Should we fix this problem I think we should design something that are a 
general mechanism that actually help us in other cases. Therefore my 
suggestion is still to construct a RTP payload format and a RTCP packet 
type that can carries challenge and responses containing security tags.

>RTP tracks then there will not be enough ports to go around with Magnus

At least not with only a single IP address.

>uniqueness (since the server can choose its SSRC with no collision).
I think this last proposal is a bad idea. It may very well have 
implications on the future extensions that we deploy. It also changes 
the meaning of the SSRC and CSRC field to not be the standardized ones. 
The general problem is that RTP was not designed to have multiple 
sessions on the same port. This is simple something the manufacturers of 
streaming severs has done to solve an operations system performance 
problem.

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]