Subject: [Sip] comments on draft-hilt-sip-correction-503-01

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 02 Dec 2007 23:47:19 -0500

Something that needs to be looked into; I think one of the interworking 
specs to ISUP uses the 503 response code as well to map to certain PSTN 
failure cases. Those need to be looked at to make sure they still fit 
with the proposed new definition.

The draft implies that the Retry-After mechanism provides too 
coarse-grained solution for overload control, and finer-grained controls 
are needed. As you know, some of the solutions being investigated for 
overload algorithms still use on/off behavior but just tune the 
Retry-After more algorithmically. So your statements about this need to 
be tempered a bit.

I'm really unsure about whether this is an essential correction or not. 
Its not a functional bug, but a performance bug. So a system based on 
rfc3261 works, but just not that well under load. I'm a bit worried 
that, in an attempt tFrom [email-masked] Mon Dec 03 03:03:39 2007
Date: Sun, 02 Dec 2007 23:47:19 -0500
From: Jonathan Rosenberg <[email-masked]>
To: IETF SIP List <[email-masked]>
Subject: [Sip] comments on draft-hilt-sip-correction-503-01

Something that needs to be looked into; I think one of the interworking 
specs to ISUP uses the 503 response code as well to map to certain PSTN 
failure cases. Those need to be looked at to make sure they still fit 
with the proposed new definition.

The draft implies that the Retry-After mechanism provides too 
coarse-grained solution for overload control, and finer-grained controls 
are needed. As you know, some of the solutions being investigated for 
overload algorithms still use on/off behavior but just tune the 
Retry-After more algorithmically. So your statements about this need to 
be tempered a bit.

I'm really unsure about whether this is an essential correction or not. 
Its not a functional bug, but a performance bug. So a system based on 
rfc3261 works, but just not that well under load. I'm a bit worried 
that, in an attempt to squeeze this in as an essential correction, we 
may define the wrong thing so as to minimize change. In particular I 
don't like alternative 2 and think we probably need a new response code.

The other big question is, is it worth defining a new response code now, 
and then later on basically updating it with the right overload handling 
behavior, or do it all at once. I think that requires some discussion.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 3 Dec 2007 16:04:50 -0500

> I'm really unsure about whether this is an 
> essential correction or not. Its not a 
> functional bug, but a performance bug.

I'm also uncertain if this should be an essential correction.

The only 503 essential corrections that I see needed are clarification
of "server" within the rfc3261 section 21.5.4 and security implications
of honoring a 503's Retry-After.  Draft-hilt-sip-correction-503-01
attempts to provide some clarification concerning "server".  However I
did not notice what should occur if immediate destination IP address of
request was different than source address of 503 response.  Leaving it
vague is ok with me; however the topic (and 503 with Retry-After in
general) should be likely be discussed from a security perspective.

The rest of the draft appears to mainly be an rfc3261 extension and
related justification.