Subject: [MMUSIC] RTSP: Proposed text for client timeout

From: Sean Sheedy <[email-masked]>
Date: 11 Nov 2003 11:27:33 -0600

Here's a first cut at some proposed text describing client request
timeouts in RTSP.  Please seen http://rtsp.org/bug770522 for more
details.

Sean

*****

Servers SHOULD respond to requests in a timely manner even when a
reliable transport such as TCP is used.  Similarly, clients SHOULD wait
for a sufficient time for a response before concluding that the server
will not be acting upon its request.

Appropriate server and client time values are based on T1, which is a
bounded estimate of the round-trip time (RTT).  The RTT is estimated as
in TCP (RFC 1323), with an initial value of 500 ms.  The client MAY
derive a more refined estimate of the RTT using the Timestamp header as
described in Section 13.39.  A client implementation MAY cache the last
RTT measurement as the initial value for future connections.

T1 is equal to the RTT, with the restriction that T1 is never less than
500 ms.  This restriction is necessary because, while the client may
adjust its RTT estimate, the server does not know the client's value.

A client SHOULD wait at least 20*T1 before concluding that the server
will not be responding to its request.

A server SHOULD respond to all requests within 10*(minimum value of T1);
that is, within 5 seconds.  If the server is not ready to send its final
response within this time, it SHOULD send a 100 response.  After
receiving a 100 response, the client SHOULD wait for further responses. 
The server MAY send additional 100 responses.  Eventually, the server
MUST send a final response indicating the success or failure of the
request.

-- 
Sean Sheedy                                         [email-masked]
(503) 531-6427

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

---

From: Tom Marshall <[email-masked]>
Date: Tue, 11 Nov 2003 21:37:37 -0800

> will not be acting upon its request.

I agree with these statements.  Unfortunately, it is very difficult to
define "sufficient" above, as this is affected by both server load and
network conditions.

> RTT measurement as the initial value for future connections.

The TCP has access to control packets (ACKs) that the application typically
does not.  How can an application distinguish variations in RTT due to
packet loss vs. congestion vs. physical propagation delay?  Is it even
possible to have a meaningful RTT measurement in networks that have packet
loss on the physical layer (eg. wireless)?

As I am sitting here typing this using the wireless signal from the IETF in
a hotel around the block from the conference, I'm getting sporadic packet
loss.  If my SSH connection behaved according to this RTSP proposal, I would
not be able to finish writing this email.

> MUST send a final response indicating the success or failure of the

How were the 500ms and the T1 multiples arrived at?

Discussion in RFC 1323 characterizes the RTT measurement as a signal
processing problem.  I am admittedly not a signal processing expert, but I
think that if we are to speak of RTT, it must be done with this
characteristic in mind.  In particular, we cannot assume that the reader
understands the implications of the wide variety of network technologies,
TCP introduced delays, etc.  "RTT" needs to be better defined in terms of
how it is measured, how often it is measured, and what unexpected factors
can influence it.  I'm very concerned that someone will write an RTSP client
that does an RTT measurement with the first RTSP message and gets some small
result like 3ms, then drops the connection when a response is delayed by
60ms because the server happens to be a bit busy and/or a couple packets get
dropped due to congestion.  This is why I am opposed to acting on negative
feedback.  I think that the only sensible option for a protocol that runs on
top of TCP is to use positive feedback exclusively, and let the user decide
when too much time has passed without response (possibly via a configurable
setting with sensible defaults).

-- 
Beware of Programmers who carry screwdrivers.
        -- Leonard Brandwein

---

From: Tom Marshall <[email-masked]>
Date: Wed, 12 Nov 2003 12:40:19 -0800

> Since what constitutes acceptable delays in RTSP is determined by human
> perception, the source of the delay (packet loss, network congestion,
> server load, etc.) is irrelevant.  The only question that needs to be
> answered from the client's perspective is:  Is the server working on the
> request, or not?  I think it's important that a user interface provides
> this information to the human waiting for the media stream.

Absolutely.  So why are we proposing to measure RTT at all?  Why don't we
just say this:

  The server SHOULD respond to all requests as soon as practicable.  If a
  request takes a significant amount of time to process, or there is an
  expectation that it will, the server SHOULD send 100 responses at regular
  intervals so that the client knows its request is still being processed.

  The client SHOULD give the server a reasonable amount of time to process its
  requests.  If an unreasonable amount of time elapses without receiving any
  response, the client MAY assume the server is unresponsive and abort the
  connection.  If a 100 response is received, the client MUST reset its
  response timer.

The only remaining question would be what constitutes a reasonable amount of
time and a regular interval.

-- 
I put instant coffee in a microwave and almost went back in time.
        -- Steven Wright

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Nov 2003 21:58:50 +0100

Hi,

I think Tom's text is basically what the conclusions was of yesterday's 
RTSP meeting.

I think there was talk about being a little bit more strict on some 
cases. I think there was some talk about saying: A server MUST send a 
1xx response if the request takes or is expected to take more than 2 
seconds to process. The server SHOULD send further 1xx messages if 
further information about the processing of the request becomes available.

On the client side we talked about writing some general cautioning that 
the client needs to take transport delays into consideration.

Cheers

Magnus

Tom Marshall wrote:

>>Since what constitutes acceptable delays in RTSP is determined by
>>    
>>
>human
>  
>
>>answered from the client's perspective is:  Is the server working on
>>    
>>
>the
>  
>
>>request, or not?  I think it's important that a user interface
>>    
>>
>provides
>  
>