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

From: Thomas Zeng <[email-masked]>
Date: Tue, 4 Mar 2003 10:58:47 -0800

Magnus:

You wrote:

>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.

Refering to section 3 of RFC1889, RTP session was defined by one
"source-destination" pair of (ip, rtp-port, rtcp-port) tuples.
It is VERY legal to have one source (ip, rtp-port, rtcp-port) serve traffic
to multiple destination (ip, rtp-port, rtcp-port)'s in unit-cast fashion.
Therefore us streaming server manufactures have not broken the law.

I'd like to point out it is not just OS performance we are talking about. It
is also the *reality* that there are only 64K ports per IP in IPV4, in
addition to the inclination of server Firewall administrators always wanting
to limit port range that the firewall (perhaps without address/port
translation) on the server side will let pass.

If we look at RFC1889 and RFC2326, RTSP servers do NOT have to open a RTP
send port per RTP session. So we are talking about
introducing new rules.

Any time a new restriction is imposed, it must be studied long and hard. In
this case, there exist alternatives. Let me summarize below:

-- Alternative A is to include a SessionID in the binding RTP packet. 
-- Alternative B is to have server suggest client SSRC in setup response, as
part of Transport header. Server and only server can make sure no collision
in suggested client SSRC.  To do so, a new transport parameter,  client_ssrc
will need to be added as optional parameter to Transport header in SETUP
response. For some reason,  "client_ssrc" parameter has already been
proposed in
http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.txt, or
is that just a typo?  I double checked to make sure that client_ssrc is not
part of RFC2326.

- thomas

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

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.

Thomas Zeng wrote:

>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.
>

At least not with only a single IP address.

>
>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?
>
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]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Mar 2003 16:41:04 +0100

Hi Thomas,

>Therefore us streaming server manufactures have not broken the law.

This is in fact a multiplexing problem. One needs to establish the 
session and what it consist of. For unicast it is possible to define a 
session by defining the two end points and the port numbers it uses. 
This gives sufficient information for demultiplexing. This has so far 
been used in servers to save ports. Each session is defined by the 
clients IP/Ports.
For a multicast session the multicast address and port is used for 
multiplexing. If we would have a multi-unicast session one way of 
defining the session is to say all that I receive on a certain port 
belongs to this session, independly of source address.

As shown above how you can utilize the port depends on the 
demultiplexing requirements you have. For normal unicast sessions where 
you know the remote address it works fine. However in the case of 
symmetric RTP we don't know the external address. Therefore one solution 
is to use different server ports.

>translation) on the server side will let pass.

Yes, there is a limitation to the number of ports per IP. However this 
is a fairly high limitation as it is sufficient for 15000 users each 
having two RTP sessions, i.e. 2 * 2 ports. I don't think using firewalls 
as an argument is a very valid one. If your having a streaming service 
you need to configure the FW to handle this server correctly. Doesn't 
the server in fact belong in the demilitarized zone in most cases.

>send port per RTP session. So we are talking about

I haven't talking so much about introducing new rules as of actually on 
how you can implement things within the standard.

>
>Any time a new restriction is imposed, it must be studied long and hard. 
>
As this is no restriction just a implementation question.

>In
The information used to id the session is not important, just that 
something is used. This requires a new RTP payload format and for RTCP 
new packet type. I think this is a good idea, especially when you are at 
it to define a format that can be used to handle destination 
verification of media streams. This solution does allow for much greater 
security by having longer id tags.

>response. 
Yes, this could be one way of assigning the ssrc. However one other 
consideration to think of in regards to symmetric RTP is that if we have 
10000 clients on the same port it will be that many times easier to 
hijack a stream. If you multiplex using different port for each session 
you ensure that the whole number space of the SSRC is used.

>For some reason,  "client_ssrc" parameter has already been
>proposed in
This was added by me in this version. My intention was to use it with 
symmetric RTP and be used by the client to tell which SSRC it will be 
using. This would of course rely on the server ensuring that no two 
users with the same SSRC will be sent to the same server side port.  So 
this is Alternative C as described by the RTSP & NAT draft. The 
parameter should perhaps belong to the RTSP & NAT draft.

There is a fourth alternative (D) as you have earlier described:
Putting this sessions server SSRC as a CSRC. However I still think this 
is a bad idea as it redefines the field. This may interfere with future 
services.

To summarize:
Solution A, good can solve another problem and gives best security. 
Requires more standards work.

Solution B, Requires minimal standards work. Its security might not be 
that good. Changes the assignment rules for SSRC.

Solution C,  Requires minimal standards work (same as B). Its security 
is slightly better than B. Uses more ports.

Solution D. Same standards works as B & C. Does not look future proof.

I would prefer A.

Best Regards

Magnus Westerlund