Subject: Re: [MMUSIC] RTSP 2.0 Issue: 503 issues (see also SIP)

From: Martin Stiemerling <[email-masked]>
Date: Thu, 21 Oct 2010 09:49:56 +0000

Hi all,

There will be a new section to handle overload in RTSP 2.0 in the updated draft (to appear on Monday).

Here is the suggested text waiting for your comments/suggestions:

10.7.  Overload Control

   Overload in RTSP can occur when server and proxies have insufficient
   resources to complete the processing of a request.  An improper
   handling of such an overload situation at proxies and servers can
   impact the operation of the RTSP deployment, probably worsen the
   situation.  RTSP defines the 503 (Service Unavailable) response
   (Section Section 15.5.4) to let servers and proxies notify requesting
   proxies and RTSP clients about an overload situation.  In
   conjuncation with the Retry-After header (Section Section 16.42) the
   server or proxy can indicate the time after the requesting entity can
   send another request to the proxy or server.

   Simply implementing and using the 503 (Service Unavailable) is not
   sufficient enough for properly handling overload situations.  For
   instance, a simplistic approach would be to send the 503 respones
   with a Retry-After header set to a fixed value.  However, this can
   cause the situation where multiple RTSP clients again send requests
   to a proxy or server at roughly the same time which may again cause
   an overload situation, or if the "old" overload situation is not yet
   solved, i.e., the length indicated in the Retry-After header was too
   short.

   An RTSP server or proxy in an overload situation must select the
   value of the Retry-After header carefully and in dependency of its
   current load situation.  It is RECOMMENDED to increase the length
   proportional with the current load of the server, i.e., an increasing
   workload should result in an increased length of the indicated
   unavailability.  It is RECOMMENDED to not send the same value in the
   Retry-After header to all requesting proxies and clients, but to add
   a variation the mean value of the Retry-After header.

   Another issue are load balancing RTSP proxies, i.e., where an RTSP
   proxy is used to select amongst a set of RTSP servers to handled the
   requests, or when multiple server addresses are available for a given
   server name.  The proxy or client may receive a 503 (Service
   Unavailable) from one of its RTSP servers or a TCP timeout (if the
   server is even unable to handled the request message).  The proxy or
   client simply retries the other addresses, but may also receive a 503
   (Service Unavailable) response or TCP timeouts from those addresses.
   In such a situation, where none of the RTSP servers/addresses can
   handled the request, the RTSP agent has to wait before it can send
   any new requests to the RTSP server.  Any additional request to a
   specific address MUST be delayed according to the Retry-After headers
   received.  For addresses where no response was received or TCP
   timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
   That timer MUST be doubled for each additional failure to connect or
   receive response.

 Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Martin Stiemerling
> Sent: Tuesday, June 29, 2010 2:54 PM
> To: [email-masked]
> Subject: [MMUSIC] RTSP 2.0 Issue: 503 issues (see also SIP)
> 
> Hi,
> 
> There is one open issue related to the 503 response in RTSP 2.0 (raise
> by Wolfgang Beck). From the tracker:
> "Section 15.5.4
> Response 503 has caused some headache in SIP. Some implementors tried
> the next IP address as returned in the DNS answer, some just gave up."
> (see also RFC 5390)
> 
> Section 15.5.4. 503 Service Unavailable
>    The server is currently unable to handle the request due to a
>    temporary overloading or maintenance of the server.  The implication
>    is that this is a temporary condition which will be alleviated after
>    some delay.  If known, the length of the delay MAY be indicated in a
>    Retry-After header.  If no Retry-After is given, the client SHOULD
>    handle the response as it would for a 500 response.
> 
> 
> Any thoughts on this?
> 
> I assume that we need to fix this NOW, as we otherwise will have to fix
> this during the IESG review.
> 
> You can find this also in the tracker:
> https://sourceforge.net/tracker/?func=detail&aid=3007825&group_id=23194
> &atid=377744
> 
>   Martin
> 
> 
> [email-masked]
> 
> NEC Laboratories Europe - Network Research Division
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic