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

From: Sean Sheedy <[email-masked]>
Date: 12 Nov 2003 14:20:28 -0600

On Tue, 2003-11-11 at 23:37, Tom Marshall wrote: 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.

I don't think comparing SSH connections to RTSP requests and responses
is valid.

The goal of an SSH connection is to provide reliable data delivery, even
in the face of underlying network difficulties.  As such, long delays in
the face of a lossy network are acceptable since the reliability goal
can still be accomplished.

The goal of RTSP is to provide an interactive user experience.  This
implies that network and server response time affects whether the goal
can be accomplished.  Although you can still play a media stream with a
30-second delay on the control channel, the user experience would likely
be unacceptable.  In other words, the standard for "sufficient" in RTSP
is what human users are willing to accept.

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.

> > 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.
> 
> How were the 500ms and the T1 multiples arrived at?

500 ms is the default RTT for both TCP and SIP.  The multiples involved
a bit of guessing, but were based on deployment experience.

The 20* client multiplier for the recommended client wait time was
chosen to provide a default time of 10 seconds, which in my experience
on low-loss high-bandwidth networks is about the outer limit of what
people are willing to tolerate.

The 10* server multiplier was simply chosen to be something less than
20*, but not so small as to necessitate a 100 response under normal
operation.  In our discussions Tuesday, we settled on a slightly
different server strategy.  As soon as a server believes servicing a
request will take longer than a fixed amount of time (2 seconds seemed
like a popular value), it should immediately send a 100.  It may then
issue additional 100 responses as it deems useful until it's ready to
send the final response.

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

This is why the floor T1 value is 500 ms.  If a client follows the
suggested algorithm, it should wait at least 10 seconds before giving
up, but may wait longer if it wishes based either on the course-grained
RTT measurement possible with the Timestamp header, or on a
user-configurable setting.

Sean

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

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