Subject: draft-rao-rtsp-00.txt

From: Adrien de Croy <[email-masked]>
Date: Thu, 17 Oct 1996 12:31:08 +1300

Hi all, my name is Adrien de Croy of Qbik Software - developers of the
WinGate proxy server for Windows NT and 95.  As part of the Progressive
Networks firewall development programme, I was asked to peruse the spec, and
provide comments.

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.

There is a little bit of unclearness however around the OPTION negotiation
packets and when these would be used.

I am familiar with the telnet protocol, and some of the option negotiation
sequences for it, having done research into this for the telnet proxy in
WinGate.  I found however that when it comes to proxying, these sort of
sequences cause large headaches.

This is because a proxy must perform as a server for the client, and a
client for the end server.  If the initial client tries negotiating options
with a proxy server, which must then negotiate with another agent (perhaps a
server or even another proxy agent) then the proxy is in a difficult
situation.  It must decide whether to accept an option from the client, and
then remember it and try to negotiate for that option on behalf of the
client with whatever the proxy needs to connect to.  Proxies may not even
understand these options, nor necessarily should they, unless they wish to
regulate access to certain options.

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
FETCH (like the flags!)
EVENT_NOTIFY

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.

What I would propose:

----------------------------------------------------------------------------
----------------------------

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

----------------------------------------------------------------------------
----------------------------

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.  

----------------------------------------------------------------------------
----------------------------

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.

----------------------------------------------------------------------------
----------------------------

4. the FETCH packet for a proxy request must contain the server and port number.

The protocol mentions number of hops, and URL, but does not define a
mechanism for defining these hops.

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

In this way, the client can know and specify what sequence of proxy servers
to tunnel through in order to get to the server with the resource.  Also,
each proxy server has a simple job in using the URL - simply remove the
RTSP://host:port/ from the start of the URL, connect to host on port, and
send the rest in a recompiled FETCH message. It also allows for the
possibility of protocol gateways, as the URL could specify many protocols
which the user agent(s) might understand and be able to convert between.

The proxy can also check for loops by scanning the whole URL, and if it
finds a reference back to itself in the URL, it can decline it.

The designer of the client must decide whether or not to allow the
definition of such URLs (e.g whether to allow source-defined routing). This
will undoubtedly be difficult to implement a solution that is easily
explainable to users, however a content provider could specify the compund
URLs on say their web pages, and users would simply point and click on a
link.  The client must scan URLs for validity before presenting them to
another agent.

Each agent should decrement the hop count as the packets pass through so
that the original hop count specified by the client is honoured.

----------------------------------------------------------------------------
----------------------------

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.

Hope this is useful.

Sorry I seem to have lost your last email about which mailing list to send
this to.  If you would like to subscribe me to it, I will post to there in
future.

Regards

Adrien de Croy

-------------------------------------------------------------------------------
Adrien de Croy - [email-masked].  Qbik Software Limited, Auckland, New Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
-------------------------------------------------------------------------------

---

From: Anup Rao <[email-masked]>
Date: Fri, 18 Oct 1996 12:45:37 -0700

Adrien de Croy wrote:

[SNIPs as appropriate]

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

> of this information - e.g
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.

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

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.

> field into the HELLO packet to determine the agent type (client, proxy,
We had actually envisaged using the sub-protocol field for this. It is a
valid requirement.

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.

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.

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

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

> that the original hop count specified by the client is honoured.

That is exactly what was meant, though not explicitly stated.

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.

> Hope this is useful.

It sure is. Thanks.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.  -  LiveMedia                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------