Subject: [MMUSIC] Comments on RTSP Draft: Important Issues

From: Tom Marshall <[email-masked]>
Date: Tue, 19 Nov 2002 22:48:14 -0800

I would like to bring up a few issues regarding the recent RTSP draft.

How should a proxy handle "OPTIONS * RTSP/1.0", and what capabilities is a
proxy expected to have (see section 12.28)?  I have always thought of the
proxy as "passing on" whatever capabilites the origin server has, and having
little or no capabilites of its own.

Why does the RTSP specification disallow byte ranges (see section 12.4)? 
There was some talk of removing this restriction during the telecons but the
change has apparently not made the draft.  Byte ranges can be useful in some
circumstances.

The client_port and server_port transport attributes specify where data is
to be sent (see section 12.40).  It is not written that the reverse is true
(eg. server's data packets originate from the server_port).  As a
consequence, at least one implementation has chosen to provide an option to
send from different ports than specified in server_port because higher
performance can be achieved.  Should this be allowed?  How will it affect
firewalls/NAT?

-- 
An American is a man with two arms and four wheels.
        -- A Chinese child

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Nov 2002 15:16:13 +0100

Hi Tom,

See comments inline

Tom Marshall wrote:

>How should a proxy handle "OPTIONS * RTSP/1.0", and what capabilities is
>a proxy expected to have (see section 12.28)?  I have always thought of
>the proxy as "passing on" whatever capabilities the origin server has, and
>having little or no capabilities of its own.
>

The request you have written ask for the next hop capabilities, if a 
proxy is present, that is proxy. A proxy has capabilities and shall 
answer exactly as any other entity, i.e. with a public header to which 
method it interprets, if supported is included the option tags that it 
supports. If the proxy does not interpret the request just forwards 
them, i.e. transparent, it just forwards it to the next entity.

>There was some talk of removing this restriction during the telecons but
>the change has apparently not made the draft.  Byte ranges can be useful in
>some circumstances.
>

I think we discussed it shortly on some telecon, however I don't find 
anything in the notes. So evidently there was no action assigned to 
anyone. Can you please provide a bit more argumentation why it is useful?

>
>The client_port and server_port transport attributes specify where data
>is to be sent (see section 12.40).  It is not written that the reverse is
>true (eg. server's data packets originate from the server_port).  As a
>consequence, at least one implementation has chosen to provide an option
>to send from different ports than specified in server_port because higher
>performance can be achieved.  Should this be allowed?  How will it
>affect firewalls/NAT?
>
Firstly, this only concerns UDP transported media. I think we should 
mandate that one must also send from the specified receiver port. 
Otherwise we might have problem that firewalls that block traffic coming 
from ports that are not signaled in the transport header. The same issue 
is present for NAT's that do binding to a to fine degree and actually 
cares of sender port.

Best Regards

Magnus

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

---

From: Tom Marshall <[email-masked]>
Date: Wed, 20 Nov 2002 11:41:53 -0800

> them, i.e. transparent, it just forwards it to the next entity.

The language in 2326 was not clear on this point.  Therefore, our proxy
currently returns a 451 error to the request.  I'm not arguing against the
proposed behavior -- only stating that this requirement will break an
existing implementation.

You say "A proxy has capabilities".  Is this always true?  Does a
non-caching, non-transparent proxy on a firewall necessarily have any
capabilities of its own?  If it does not, you say that "[it] just forwards
[the request(s)] .. to the next entity".  This would seem to contradict the
statement that the request is asking for next-hop capabilities.

I would like to see the semantics of the "*" url defined very clearly for
proxies so this type of misunderstanding does not happen again.  I think
that defining it to be a request for next-hop capabilities is fine, so long
as (1) we realize it breaks some implementations, (2) no exceptions are
allowed (including transparent proxies), and (3) we define exactly what the
minimum capabilities are for a proxy (which might be "none").

> anyone. Can you please provide a bit more argumentation why it is useful?

Our proxy does not work as described in section 13.  Our architecture
requires that, for at least some data types, the original file be available
via an export mechanism.  The most straightforward and reliable export
mechanism is to transfer portions of the file via RTSP using byte ranges.

> mandate that one must also send from the specified receiver port. 

I have no problems with this mandate.  I think it's a good idea and said
implementation is exploiting a loophole in the wording of the spec. 
However, see below.

> is present for NAT's that do binding to a to fine degree and actually 

I am certainly no firewall expert.  However, I have written Linux
masquerading code for several protocols and I have analyzed streaming
protocols other than RTSP.  Some servers do not even guarantee that the UDP
packets originate from the same IP address as the control channel (in the
case of multiple NICs).  As I pointed out above, at least one server does
not send UDP packets from the port designated in the server_port attribute. 
Therefore, when I write firewall and NAT code, I usually take advantage of
the "loose" specification for UDP packets.  I tell the kernel that the
source port (and sometimes the source IP address) are not known and the
kernel should use the first UDP packet it sees that is destined for the
NATted port as the source.  To do otherwise (especially in a commercial
product) would limit usability and thus would not be desirable.

-- 
Absurdity, n.: A statement or belief manifestly inconsistent with one's own
opinion.
        -- Ambrose Bierce, "The Devil's Dictionary"

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Nov 2002 22:49:21 +0100

Hi Tom,

See comments below

Tom Marshall wrote:

>>>How should a proxy handle "OPTIONS * RTSP/1.0", and what capabilities
>>>
>is
>
>>>a proxy expected to have (see section 12.28)?  I have always thought
>>>
>of
>
>>>the proxy as "passing on" whatever capabilities the origin server
>>>
>has, and
>

Yes, I agree that we need to clarify this. I would in fact be very happy 
if someone could do a summary of proxy types and there behavior. This 
would be very helpful when reviewing the wording regarding proxies. 
Which will be necessary as the proxy part seem to be unclear in several 
regards.

>
>>>Why does the RTSP specification disallow byte ranges (see section
>>>
>12.4)?
>
>>>There was some talk of removing this restriction during the telecons
>>>
>but
>
>>>the change has apparently not made the draft.  Byte ranges can be
>>>
>useful in
>
>>>some circumstances.
>>>
>>anyone. Can you please provide a bit more argumentation why it is
>>
>useful?
>

Okay, then the question is if including this will affect any clients. 
Currently the Range header does not allow for any extensions. Which I 
can agree is a shortcoming. It should define possibility to extend the 
format and rules for how to handle extensions not supported. I think 
usage of Accept-ranges allows easy way of knowing when one can use the 
format. Also request including ranges not understood is probably safest 
to fail with an error code.

>
>>>The client_port and server_port transport attributes specify where
>>>
>data
>
>>>is to be sent (see section 12.40).  It is not written that the
>>>
>reverse is
>
>>>true (eg. server's data packets originate from the server_port).  As
>>>
>a
>
>>>consequence, at least one implementation has chosen to provide an
>>>
>option
>
>>>to send from different ports than specified in server_port because
>>>
>higher
>
>>Otherwise we might have problem that firewalls that block traffic
>>
>coming 
>
>>from ports that are not signaled in the transport header. The same
>>
>issue 
>
Yes, I can agree. We should probably straight out the requirement to use 
server_port and source correctly to indicate from where the stream will 
come. But at the same time write a note that it exist severs not doing 
the correct thing.

Best Regards

Magnus

---

From: Gayathri Ramakrishnan <[email-masked]>
Date: Thu, 21 Nov 2002 15:01:39 +0530

Hi Magnus,

Just a brief snippet on types of HTTP proxies:

Forward Proxy Cache - A proxy cache operates by explicitly cooperating
with the browser by directing HTTP requests to the cache rather than the 
target web server. The cache then either satisfies the request itself or 
passes on request to the server as a proxy for the browser (hence the 
name). Proxy caches are particularly useful on enterprise Intranets,
where they serve as a firewall that protects intranet servers against 
attacks from the Internet. The most obvious disadvantage of the proxy 
configuration is that each browser must be explicitly configured to use 
it.

Reverse Proxy/Web Server Acceleration - A reverse proxy is a proxy cache 
that sits in front of one or more specific web servers. The cache 
intercepts all requests for one or more servers, caches a copy of the 
objects served, and then serves those objects when it next receives 
requests for them. By serving frequently requested content itself, the 
cache relieves the origin servers of this load, freeing up processing 
power on those servers for other tasks, such as managing dynamic content 
requests like e-commerce.

Transparent Cache - A transparent cache is so named because it works by 
intercepting the network traffic transparently to the browser. In this 
mode, the cache short-circuits the retrieval process if the desired file 
is in the cache. Transparent caches are especially useful to ISPs 
because they require no browser set-up modification. The main
disadvantage of the transparent approach is that the cache must be
placed at a "choke point" in the network through which all the traffic
to benefit from caching is guaranteed to pass

HTH,
Gayathri