Subject: Re: draft-rao-rtsp-00.txt

From: Adrien de Croy <[email-masked]>
Date: Sat, 19 Oct 1996 14:48:17 +1300

At 12:45 18/10/96 -0700, Anup Rao wrote:
>Adrien de Croy wrote:
>
>[SNIPs as appropriate]
>
>>
>> I only have a couple of comments, which I hope you will find useful.
>>
>> First off - it looks good.  What I have to say relates in the main to proxy
>> servers, since that is where I am coming from, and am familiar with.
>>
>I have similar experience too, though only in application proxies. I
>therefore understand most of your points.
>

OK, my experience is also pretty much completely in application-level proxies.

>>
>> In general, a proxy does need to understand most of what it is passing
>> through - the information required normally is limited to
>>
>> 1. Client location / identification information (IP / port / ID)
>> 2. Server location / identification information (IP / port / ID)
>> 3. Requested resource information (file name / type / size)
>>
>> These are the data that proxy servers need in order to make their decisions
>> about whether or not to fulfil a client request.
>>
>> However, with the proposed protocol, there are many ways of conveying some
>> of this information - e.g
>>
>> REDIRECT
>This should just result in a new connection or fetch(i.e go back to
>square 1 as far as the proxy is concerned.) Could you explain to me why
>you see this as a problem?
>Likewise for EVENT_NOTIFY.
>
>> FETCH (like the flags!)
>
>The idea is that fetch and stream_header convey all the generic
>information for the stream.
>
>> EVENT_NOTIFY

OK, in answer to your question above, and reading that bit of the spec
again, I must have missed something.  If the REDIRECT and EVENT_NOTIFY
simply "reset" the protocol back to a FETCH, then I don't see any problem,
as the proxy will still be controlling any subsequent request.

>
>> If the proxy needs to understand a large part of the protocol in order to
>> extract this information , then it becomes difficult to implement a proxy,
>> and problematic when the protocol is extended.
>>
>
>This is always an issue. The more the proxy needs to understand, the
>more complex it is(But, I believe more secure). However, it is difficult
>to justify curbing the extensibility of the protocol due to this reason.
>Our attempt has been to:

I am not proposing curbing the extensibility of the protocol, I was just
querying whether it should be made mandatory that a proxy understand this
aspect of the protocol rather than giving the proxy the opportunity to
defer.  The more difficult it is to implement a proxy, the longer it will
take, and at the rate at which the number of proxy users is growing, this
affects a large number of users.  I agree that the more a proxy understands
a protocol, the more secure it can be made.  There is a flip-side to that as
well, in that the more a proxy understands, the more an administrator needs
to understand in order to configure the proxy.

>
>a) Provide basic stream information in the protocol. Rate/max transport
>size/generic type etc via fetch and stream_header. Transport channel
>information via set_transport.
>The idea is that the connection can be proxied/tunneled using this
>information.
>
>b) have media specific properties set in set/get param. If a proxy
>wanted to be really clever, it could use this information. But it should
>not need to. Likewise with things that change the rate like set_speed,
>for example if the proxy wanted to control total bandwidth.
>

I guess where I am coming from is an aspect of connectivity. I agree that
the protocol needs to incorporate the commands for handling the streaming
media.  However the main purpose of an application proxy is to provide
connectivity to a client, restrictions and regulation are a secondary job.
If you separate the connectivity functions from the other functions of the
protocol, then the primary job of a proxy can be achieved easily.  A better
proxy will always understand more of the protocol, however I believe we may
be setting the minimum understanding higher than appropriate.

I guess I am just being lazy here, since I will undoubtedly need to write an
application-level proxy for this protocol.

>
>> 1. The client must be aware when it is talking to a proxy server (obviously)
>> rather than a server. A server should also be aware if a proxy is connecting
>> to it rather than a client, as it may wish to give priority - e.g where a
>> proxy is re-casting a live broadcast to many clients.  I propose you add a
>> field into the HELLO packet to determine the agent type (client, proxy,
>> re-caster, or server).
>>
>We had actually envisaged using the sub-protocol field for this. It is a
>valid requirement.

OK, I guess this just needs to be documented in the spec so people can
standardise.

>
>> ----------------------------------------------------------------------------
>> ----------------------------
>>
>> 2. It must be made clear when there is a control connection between the
>> client and destination server, and that no OPTION (or even GETPARAM /
>> SETPARAM) packets are sent until that time - to ensure that the client only
>> ever negotiates these with the end server.
>> >
>Assuming that these(option/param) requests are small and few in number,
>is there a problem in the proxy caching them until the  end-end control
>tunnel is established ? We have done this in the past. Having the client
>wait just increases the response time due to round trip delays.

I guess caching could get around it.  As soon as the option negotiation
process becomes more drawn out and complex, as happened with telnet, you run
into problems.  Maybe I am just recalling bad experiences with telnet, as
with telnet the proxy actually needed to understand and act on many of the
options, and also cache them.

Caching options may also render the proxy vulnerable.  Consider the following.

hacker connects to proxy.

Sends option / getparam/setparam commands until the proxy runs out of memory
and crashes.

While this may seem unlikely, and you could set a limit on the number of
options etc a proxy would cache, this would have to be an arbitrary limit,
and would then limit the extensibility of the option negotiation process

remember also that there are a large number of proxy servers running on
low-spec machines with less-than-optimally-stable OSs (e.g Win 95),
providing access to large numbers of users.

there is also no reason why a client could not behave differently talking to
a proxy than a server.  If a client knows it is talking to a proxy, it could
wait for receipt of a certain packet before sending option negotiations etc
etc, whereas if it knew it was talking to a server, it could go straight
ahead.  I don't believe this would add much complexity at all to the
requirements of a client.

>
>> ----------------------------------------------------------------------------
>> ----------------------------
>>
>> 3. Add a FETCH_RESPONSE packet.  This allows a proxy (or a server) to
>> decline a request gracefully, and also tells the client when it should
>> continue with its protocol.  The proxy would establish communications with
>> the server before sending back the response.  The client should not send any
>> more packets until it has received the FETCH_RESPONSE packet.
>>
>> ----------------------------------------------------------------------------
>> ----------------------------
>Same answer as above.
>The fetch_response is really the stream header though. So it  really
>becomes a question of whether the client should wait for it before
>sending anything  not needing the information of stream_header.

Understood.
>
>>
>> 4. the FETCH packet for a proxy request must contain the server and port
number.
>>
>Yes, it is supposed to. In a simple client-server case it would be
>RTSP://server:port/name.
>
>
>> I would propose: (e.g client connects to proxy1:port and sends FETCH with
>> following URL)
>>
>> RTSP://proxy2host:port/RTSP://proxy3host:port/RTSP://serverhost:port/resource
>>
>
>The difference here is that you are proposing that the client knows the
>route.
>I think in most cases it would be up to proxies to(be configured to)
>define the route and use nhops to make sure it does not get out of hand.
>This is the way most routing(telephony/IP) works today  for the most
>part. To make things clearer:-
> 
>Client A talks to a proxy B
>fetch(rtsp://abcd:nnn/resource_name).
>
>Proxy B is set up to direct requests for abcd:nn to Proxy C.
>B->C:
>fetch(rtsp://abcd:nnn/resource_name).
>
>Proxy C talks to server abcd:nnnn and sets up a tunnel from A to server
>abcd.
>
>However, I do not see a problem in the client optionally specifying the
>route(something like IP loose source routing). It could have advantages
>in some cases.

Sure.  

>
>>
>> Each agent should decrement the hop count as the packets pass through so
>> that the original hop count specified by the client is honoured.
>
>That is exactly what was meant, though not explicitly stated.
>
>>
>> ----------------------------------------------------------------------------
>> ----------------------------
>>
>> 5. You may like to think about the situation of a re-caster.  A re-caster is
>> an agent that re-broadcasts a live feed to reduce backbone bandwidth.  These
>> are usful where multi-cast is not available.  A re-caster serving many
>> connected clients on a stream arguably deserves a higher priority and
>> bandwidth from a source provider than a single client.  A mechanism for
>> specifying and updating a count of connected clients would be useful
>> information for a server to decide on its priorities.
>>
>
>Excellent point. We have experienced problems trying to do this with a
>basic client-server protocol. Would you agree though that the basic
>client-server protocol should not be taxed by all of this and should
>remain simple ? We think this is really an application-level
>routing/multicast issue which has great possibilites, but poses some
>interesting questions and needs to be brainstormed further.
>

I understand.  I guess this is getting more into the realms of a
server-server protocol.  Maybe the protocol needs to define client-server,
and server-server comms.

Regards

Adrien de Croy

>> Hope this is useful.
>>
>
>It sure is. Thanks.
>
>-- 
>-----------------------------------------------------------------
>  Anup Rao                                                      
>  Netscape Communications Corp.  -  LiveMedia                   
>  email : [email-masked]         Phone : (415) 937 3129       
>-----------------------------------------------------------------
>
-------------------------------------------------------------------------------
Adrien de Croy - [email-masked].  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------