Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification

From: Brett Tate <[email-masked]>
Date: Mon, 1 Dec 2014 09:18:59 -0500

> If you send a BYE to the same thing that sent you a 503
> for any other reason, before the Retry-After has expired,
> you are violating protocol.

Yes; it is a violation of the RFC 3261 section 21.5.4 SHOULD NOT.

"A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
attempt to forward the request to an alternate server.  It SHOULD NOT
forward any other requests to that server for the duration specified
in the Retry-After header field, if present."

RFC 5390 presents some reasons (directly or indirectly) why you might want
to violate the SHOULD NOT.  For instance, you might consider the 503 with
Retry-After mechanism to be too insecure to trust that you really should
not send any requests to a particular server for the next hour, day, or
year.

Similarly as mentioned within RFC 5390 section 5.2, RFC 3261 is unclear
concerning "server" in relation to the scope of the 503.  It is unclear
about "server" being 1) IP address where sent request, 2) source IP
address of received response, and/or 3) something else.  And based upon
draft-ietf-sipcore-dns-dual-stack's intention to cause trying both IPv4
and IPv6 addresses, I'd love to hear the proposal about how you avoid
attempting the same server twice when a 503 is received.

Thanks,
Brett

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 1 Dec 2014 15:34:39 +0100

> attempting the same server twice when a 503 is received.

Given that with dual stack the IPv4 IP for a given host name may go to one server,
and the IPv6 to another, I think there's a need for clarification here.
The IP that sends you the 503 with Retry-After has to be the one
blacklisted for a time. 

We may have to recommend not using one host name for IPs that leads
to two different servers. One host name per "server". If one name has
both A and AAAA it has to be *one* server with the same transport layer.

Would that make it easier?

Thank you for pointing this out. We all missed it.

/O

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 1 Dec 2014 16:08:29 +0000

> It is unclear about "server" being 1) IP address where sent request, 2) source IP address of received response, and/or 3) something else.  

I thought "server" is:
- entire URI (not just IP address and port) in the top Route header field of the request, if there is a Route header field in the request; and
- entire Request-URI (not just IP address and port) of the request, if there is no Route header field in the request.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer 

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: 1. prosince 2014 15:19
To: [email-masked]
Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification

> If you send a BYE to the same thing that sent you a 503 for any other 
> reason, before the Retry-After has expired, you are violating 
> protocol.

"A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server.  It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present."

RFC 5390 presents some reasons (directly or indirectly) why you might want to violate the SHOULD NOT.  For instance, you might consider the 503 with Retry-After mechanism to be too insecure to trust that you really should not send any requests to a particular server for the next hour, day, or year.

Similarly as mentioned within RFC 5390 section 5.2, RFC 3261 is unclear concerning "server" in relation to the scope of the 503.  It is unclear about "server" being 1) IP address where sent request, 2) source IP address of received response, and/or 3) something else.  And based upon draft-ietf-sipcore-dns-dual-stack's intention to cause trying both IPv4 and IPv6 addresses, I'd love to hear the proposal about how you avoid attempting the same server twice when a 503 is received.

Thanks,
Brett

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

---

From: Brett Tate <[email-masked]>
Date: Mon, 1 Dec 2014 12:15:47 -0500

Hi,

Yes; as mentioned within RFC 5390, "RFC 3261 is unclear on the scope of a
503" and it can lead to unintentional underutilization.

RFC 3263 section 4.3 is the main reason why I disagree with attempting to
apply the scope to a URI or its hostname.  That interpretation would allow
advancing upon receiving a 503; however the Retry-After would cause the
rest of the list to be skipped.

> From: Ivo Sedlacek [mailto:[email-masked]]
> Sent: Monday, December 01, 2014 11:08 AM
> To: Brett Tate; [email-masked]
> Subject: RE: [sipcore] 503 response with Retry-After header field -
request
> for clarification
>
> > It is unclear about "server" being 1) IP address where sent request,
2)
> source IP address of received response, and/or 3) something else.
>
> I thought "server" is:
> - entire URI (not just IP address and port) in the top Route header
field of
> the request, if there is a Route header field in the request; and
> - entire Request-URI (not just IP address and port) of the request, if
there
> is no Route header field in the request.
>
> Kind regards
>
> Ivo Sedlacek
>
> This Communication is Confidential. We only send and receive email on
the
> basis of the terms set out at www.ericsson.com/email_disclaimer
>
> Subject: Re: [sipcore] 503 response with Retry-After header field -
request
> for clarification
attempt
> to forward the request to an alternate server.  It SHOULD NOT forward
any
> other requests to that server for the duration specified in the
Retry-After
> header field, if present."
>
> RFC 5390 presents some reasons (directly or indirectly) why you might
want to
> violate the SHOULD NOT.  For instance, you might consider the 503 with
Retry-
> After mechanism to be too insecure to trust that you really should not
send
> any requests to a particular server for the next hour, day, or year.
>
about
> "server" being 1) IP address where sent request, 2) source IP address of
> received response, and/or 3) something else.  And based upon draft-ietf-
> sipcore-dns-dual-stack's intention to cause trying both IPv4 and IPv6
> addresses, I'd love to hear the proposal about how you avoid attempting
the
> same server twice when a 503 is received.
>
> Thanks,
> Brett
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 3 Dec 2014 08:23:29 +0000

Hello,

I was not aware of RFC 5390 and of RFC 3263 section 4.3. Thanks for pointing them out.

Just to double-check - "that server" in RFC3261 section 21.5.4 statement below is the IP address of the next hop to which SIP request was sent and from which 503 response was received. Correct?
--------------------
It SHOULD NOT
   forward any other requests to __that server__ for the duration specified
   in the Retry-After header field, if present.
--------------------

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: 1. prosince 2014 18:16
To: Ivo Sedlacek; [email-masked]
Subject: RE: [sipcore] 503 response with Retry-After header field - request for clarification

Hi,

Yes; as mentioned within RFC 5390, "RFC 3261 is unclear on the scope of a 503" and it can lead to unintentional underutilization.

RFC 3263 section 4.3 is the main reason why I disagree with attempting to apply the scope to a URI or its hostname.  That interpretation would allow advancing upon receiving a 503; however the Retry-After would cause the rest of the list to be skipped.

request
2)
field of
there
the
request
> for clarification
>
> > If you send a BYE to the same thing that sent you a 503 for any 
> > other reason, before the Retry-After has expired, you are violating 
> > protocol.
>
attempt
any
Retry-After
want to
Retry-
send
> Similarly as mentioned within RFC 5390 section 5.2, RFC 3261 is 
> unclear concerning "server" in relation to the scope of the 503.  It 
> is unclear
about
> "server" being 1) IP address where sent request, 2) source IP address 
> of received response, and/or 3) something else.  And based upon 
> draft-ietf- sipcore-dns-dual-stack's intention to cause trying both 
> IPv4 and IPv6 addresses, I'd love to hear the proposal about how you 
> avoid attempting
the

---

From: Brett Tate <[email-masked]>
Date: Wed, 3 Dec 2014 07:33:30 -0500

Hi,

As far as I know, the IETF has not clarified what "server" means within the
RFC 3261 snippet.

RFC 5390 did not clarify it.  Maybe it was to motivate everyone to start
using the soc working group mechanisms such as RFC 7339.

"5.2.  Underutilization

 Interestingly, there are also examples of deployments where the
 network capacity was greatly reduced as a consequence of the overload
 mechanism.  Consider again Figure 1.  Unfortunately, RFC 3261 is
 unclear on the scope of a 503.  When it is received by P1, does the
 proxy cease sending requests to that IP address?  To the hostname?
 To the URI?  Some implementations have chosen the hostname as the
 scope.  When the hostname for a URI points to an SRV record in the
 DNS, which, in turn, maps to a cluster of downstream servers (S1, S2,
 and S3 in the example), a 503 response from a single one of them will
 make the proxy believe that the entire cluster is overloaded.
 Consequently, proxy P1 will cease sending any traffic to any element
 in the cluster, even though there are elements in the cluster that
 are underutilized."

> Sent: Wednesday, December 03, 2014 3:23 AM
> I was not aware of RFC 5390 and of RFC 3263 section 4.3. Thanks for
> pointing
> them out.
>
> Just to double-check - "that server" in RFC3261 section 21.5.4 statement
> below is the IP address of the next hop to which SIP request was sent and
> from which 503 response was received. Correct?
> --------------------
> It SHOULD NOT

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 04 Dec 2014 23:12:29 -0500

> - entire Request-URI (not just IP address and port) of the request, if there is no Route header field in the request.

I've not used 503 in implementations.  But I would expect that its
principal use is to cause the UAC to choose a different target
(address/port/protocol) out of the set of targets that the URI resolves
to.  In order to make that work, the implementation must "blacklist"
only a single target, not the targeted URI.

Dale