Re: [dispatch] Request for discussion of end2end SIP Overload Control

[Brett Tate <[e-mail]>]

> Any comments or suggestions will be greatly appreciated.

Hi,

Concerning draft-wang-appsawg-end2end-overload-control-00, the hop-by-hop nature of the 503 likely means that it cannot be used to satisfy the desired end-to-end algorithm.  More specifically, the algorithm to use 503 as mentioned within section 2.2 appears to have two flaws would likely need to be addressed.

1) The 503 might trigger advancing to the next location.  Thus the edge server would not always receive the 503.

2) RFC 3261 section 16.7 indicates "A proxy which receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503".  Thus middle boxes frequently convert a 503 into a 500.

Draft-wang-appsawg-end2end-overload-control-00 section 2.2:

"In end-to-end overload control, the core servers SHOULD only
 implement local overload control that rejects requests by using 503
 responses.  When receiving a 503 response from a downstream neighbor,
 the server SHOULD forward this response to the upstream neighbor,
 from which the INVITE request related to this response has been
 received.  In this way, the 503 response will finally be forwarded to
 the edge server.  The edge servers SHOULD calculate and follow the
 restrictions on the traffic admitted to the SIP network based on the
 received 503 responses."

Thanks,
Brett