Subject: Re: [sip-overload] draft-gurbani-sip-overload-control-02 submitted

From: "Bharrat, Shaun" <[email-masked]>
Date: Wed, 1 Sep 2010 09:51:52 -0400

Vijay:

oc-seq: Inserted by the SIP entity sending a response upstream.
       This is an optional parameter.  This parameter contains a value
       that indicates the sequence number 

versus

Implementations that are not capable of updating the "oc" and "oc-
   validity" parameter values for retransmissions --- or implementations
   that do not want to do so because they will have to regenerate the
   message to be retransmitted --- MUST still insert a "oc-seq"
   parameter in the first response associated with a transaction;
   however, they do not have to update the value in subsequent
   retransmissions. 

I take it that the parameter is only "optional" in the sense that it
is not there when the "oc" parmeter is not?

Overall I still have some qualms about the oc-seq requirement but I
understand
the problem we are trying to solve and haven't seen a better suggestion.
The
case I am worried about is the larger chassis-based systems where
multiple 
blades might be independently generating responses (and don't have a
common
sequence number space). If a sequence number generated from a timestamp
is
used, then multiple responses may have the same sequence number (i.e. it
is a
non-decreasing sequence rather than an increasing sequence). Is this
allowed
for the "Implementations that are not capable of updating the "oc" case?

4.7.  Self-Limiting

   In some cases, a SIP entity may not receive a response from a
   downstream server after sending a request.  RFC3261 [RFC3261] defines
   that when a timeout error is received from the transaction layer, it
   MUST be treated as if a 408 (Request Timeout) status code has been
   received.  If a fatal transport error is reported by the transport
   layer, it MUST be treated as a 503 (Service Unavailable) status code.

   In these cases, the SIP entity MUST stop sending requests to this
   server.  The SIP entity SHOULD occasionally forward a single request
   to probe if the downstream server is alive.  Once a SIP entity has

This seems too draconian and implementations should be given some leeway

here. Unless I misunderstand, a single transport error, or a single call
producing a timeout causes you to slam on the brakes and completely shut
off calls to that peer. We understand that you should stop sending calls
on these errors and my company's implementation does that but it not on
a single error -- and that is based on field experience that this leads
to wild oscillations in flow paths in "less than pristine" networks.

Thanks and cheers,
Shaun

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: Monday, August 23, 2010 1:39 PM
> To: [email-masked]
> Subject: [sip-overload] draft-gurbani-sip-overload-control-02 
> submitted
> 
> Folks: I have updated draft-gurbani-sip-overload-control to 
> reflect the discussion we had in Maastricht and subsequently, 
> on the mailing list.  Version -02 is now available in the 
> IETF archives (please see
> http://www.ietf.org/id/draft-gurbani-soc-overload-control-02.txt)
> 
> This version has the following changes:
> 
> 1) Reduced the parameters from 5 to 2, as per the Maastricht
>   discussion;
> 2) Simplified oc-validity ABNF, as per the Maastricht
>   discussion;
> 3) Include Janet's comments on RPH that were sent on the list
>   following the Maastricht meeting;
> 4) Took out the simplistic random number algorithm to determine
>   whether or not a request was to be forwarded.  Clearly,
>   based on the list discussion, we will need a more resilient
>   algorithm;
> 5) Attended to various nits and edits.
> 
> Please do take a look and post any comments.
> 
> Thank you,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 03 Sep 2010 14:37:09 -0500

Shaun: Please see inline.

On 09/01/2010 08:51 AM, Bharrat, Shaun wrote:
> oc-seq: Inserted by the SIP entity sending a response upstream. This
> is an optional parameter.  This parameter contains a value that
> indicates the sequence number
>
> versus
>

I think we are straddling a thin line here.  To wit, the issue is
whether a SIP server updates the "oc-seq" parameter in retransmissions
or whether it updates the parameter in a completely different
transaction.

The problems associated with updating the "oc-seq" parameter arose
in context of retransmissions.  Some implementations create a template
and use that template so they don't have to regenerate the message
to be transmitted on each retransmission.  Changing the value of
"oc-seq" would mean changing the template.

Those implementations that do not want to update the "oc-seq" and
"oc" parameters in retransmissions don't have to do so.  However,
these implementations must still update the "oc" and "oc-seq"
parameter in different transactions if the value of the last
sent overload control parameters have changed.

So from that point, the "oc-seq" parameter is not optional and
is to be inserted in all responses.  I will modify the document
accordingly.

> understand the problem we are trying to solve and haven't seen a
> better suggestion. The case I am worried about is the larger
> chassis-based systems where multiple blades might be independently
> generating responses (and don't have a common sequence number
> space). If a sequence number generated from a timestamp is used,
> then multiple responses may have the same sequence number (i.e. it is
> a non-decreasing sequence rather than an increasing sequence). Is
> this allowed for the "Implementations that are not capable of
> updating the "oc" case?

Now for the case you point above, a blade may generate a "oc-seq"
value and that value will remain constant during retransmissions,
but will change across transactions (i.e., it will increase across
transactions.)  So, I think that we are okay.

> downstream server after sending a request.  RFC3261 [RFC3261]
[...]
> This seems too draconian and implementations should be given some
> leeway here. Unless I misunderstand, a single transport error, or a
> single call producing a timeout causes you to slam on the brakes and
> completely shut off calls to that peer. We understand that you
> should stop sending calls on these errors and my company's
> implementation does that but it not on a single error -- and that is
> based on field experience that this leads to wild oscillations in
> flow paths in "less than pristine" networks.

That is a good point.  The current wording the draft says that
the upstream SIP entity SHOULD occasionally forward a single
request to probe the health of the downstream server.  It leaves
out how occasional is "occasionally."  To avoid oscillations
of the type you have seen above, you can probe more frequently.
This will approximate what you want to do, if I understand your
concern correctly.

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Bharrat, Shaun" <[email-masked]>
Date: Fri, 3 Sep 2010 16:25:52 -0400

Vijay:

> > generating responses (and don't have a common sequence 
> number space). 
> > If a sequence number generated from a timestamp is used, 
> then multiple 
> > responses may have the same sequence number (i.e. it is a 
> > allowed for the "Implementations that are not capable of 
> updating the 
> > "oc" case?

> value and that value will remain constant during 
> retransmissions, but will change across transactions (i.e., 
> it will increase across

Don't think I got my concern across. This is a *single* system
consisting
of multiple blades. Let's take two transactions, generated by two
separates
blades at the same time. Without a global counter (which is usually not
available because you want the blades to run without write contention on
globals), 
each blade will presumably generate this oc-seq from a timestamp or
something like
that. This then leads to the possibility of both transactions having the
*same*
oc-seq. Externally, it looks like the *system* repeated the oc-seq #
(i.e. it
is not a strictly increasing sequence).

At first I thought this wasn't allowed by the text but on further
reading of
section 6:

  The "oc-seq" Via header parameter contains a sequence number.  Those
   implementations that are capable of providing finer-grained overload
   control information may do so, however, each response that contains
   the updated overload control information MUST have an increasing
   value in this parameter.

seems to allow repeated sequence numbers provided that ones with updated
load information have a higher value. So moot point.

> > completely shut off calls to that peer. We understand that 
> you should 
> > stop sending calls on these errors and my company's implementation 
> > does that but it not on a single error -- and that is based 
> on field 
> > experience that this leads to wild oscillations in flow 
> paths in "less 
> > than pristine" networks.
> 
> That is a good point.  The current wording the draft says 
> that the upstream SIP entity SHOULD occasionally forward a 
> single request to probe the health of the downstream server.  
> It leaves out how occasional is "occasionally."  To avoid 
> oscillations of the type you have seen above, you can probe 
> more frequently.

Doesn't quite do it for us. If we are sending 300 cps to a peer, and a
*single*
error occurs, we are not going to switch all the calls to another peer
until a 
probe completes. (Not unless we want to get into a fistfight with the
network design
guys.) This would have to be something where over some short period a
large % of the 
calls start failing, then we'll switch off. 

We obviously do not want to HAVE to violate any MUST clauses so we would
prefer
this be worded as:

  In the event of repeated timeouts or fatal transport errors, the SIP
entity
  MUST stop sending ....

Thanks and cheers,
Shaun 

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Friday, September 03, 2010 3:37 PM
> To: Bharrat, Shaun
> Cc: [email-masked]
> Subject: Re: [sip-overload] 
> draft-gurbani-sip-overload-control-02 submitted
> 
> I think we are straddling a thin line here.  To wit, the 
> issue is whether a SIP server updates the "oc-seq" parameter 
> in retransmissions or whether it updates the parameter in a 
> completely different transaction.
> 
> The problems associated with updating the "oc-seq" parameter 
> arose in context of retransmissions.  Some implementations 
> create a template and use that template so they don't have to 
> regenerate the message to be transmitted on each 
> retransmission.  Changing the value of "oc-seq" would mean 
> changing the template.
> 
> Those implementations that do not want to update the "oc-seq" 
> and "oc" parameters in retransmissions don't have to do so.  
> However, these implementations must still update the "oc" and "oc-seq"
> So from that point, the "oc-seq" parameter is not optional 
> and is to be inserted in all responses.  I will modify the 
> document accordingly.
> 
> > generating responses (and don't have a common sequence 
> number space). 
> > If a sequence number generated from a timestamp is used, 
> then multiple 
> > responses may have the same sequence number (i.e. it is a 
> > allowed for the "Implementations that are not capable of 
> updating the 
> > "oc" case?
> 
> value and that value will remain constant during 
> retransmissions, but will change across transactions (i.e., 
> it will increase across
> > completely shut off calls to that peer. We understand that 
> you should 
> > stop sending calls on these errors and my company's implementation 
> > does that but it not on a single error -- and that is based 
> on field 
> > experience that this leads to wild oscillations in flow 
> paths in "less 
> > than pristine" networks.
> 
> That is a good point.  The current wording the draft says 
> that the upstream SIP entity SHOULD occasionally forward a 
> single request to probe the health of the downstream server.  
> It leaves out how occasional is "occasionally."  To avoid 
> oscillations of the type you have seen above, you can probe 
> more frequently.
> This will approximate what you want to do, if I understand 
> your concern correctly.
> 
> Thank you.
> 
> - vijay
> --

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Sep 2010 17:01:44 -0400

Shaun,

If these blades are as independent as you describe, are they really one 
system for purposes of soc? How can they determine a common number for 
how overloaded they are?

Do they actually send the messages themselves? Or are the generated 
messages queued up in a common server for writing? If so, maybe it can 
insert the sequence numbers in the messages.

	Thanks,
	Paul

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 3 Sep 2010 17:10:21 -0400

I am reading through this,and have lots of detailed comments.

But before that, I have a very high level comment/question.

The design document makes the point that  it is desirable to allow many 
different overload algorithms to use the same protocol sematics:

"Overload control algorithms have been studied to a large extent and
   many different overload control algorithms exist.  With many
   different overload control algorithms available, it seems reasonable
   to suggest a baseline algorithm in a specification for a SIP overload
   control mechanism and allow the use of other algorithms if they
   provide the same protocol semantics.  This will also allow the
   development of future algorithms, which may lead to a better
   performance."

It seems to me that the corollary of this is that the "protocol semantics" 
should be designed in a way that permits their use by a variety of 
different algorithms (including ones not yet developed).

However this Overload Control document specifies "protocol semantics" 
which are tied to a particular calls of overload algorithms (percent 
throttling), even though the document itself points out that there is an 
open issue related to "other types of overload feedback", such as 
rate-based or window based.

It seems to me that it would be more useful to specify "protocol 
semantics" and syntax which can be used with a variety of different types 
of overload feedback.  I would rather NOT end up with "loss-based", 
"rate-based" and "window-based" having distinctly different  protocol 
semantics and syntax.

I can think of two approaches to protocol semantics and syntax that would 
serve multiple approaches.

One would be to have the "oc" parameter represent an "overload level" 
rather than a "percent loss".  The interpretation of the "overload level" 
would be externally agreed to.

The other would be tho have a two part parameter, in which one part was  a 
number, and the other part was a type.  So if the "type" were "loss", the 
number would represent the percent that needed to be dropped.  If the type 
were "rate" the number would represent the desired (maximum) rate.  If the 
type were "window", the number would represent the desired window size.

I am sure there are other, better ways.

But I would really like to see protocol semantics and syntax which permit 
(at least) the three approaches that have already been discussed.

I don't think "it would be problematic for interoperability purposes" is a 
good enough reason.  It would be EVEN MORE  "problematic for 
interoperability purposes" to have completely different protocol semantics 
and syntax  for each algorithm type.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

[email-masked] wrote on 08/23/2010 01:38:37 PM:

> "Vijay K. Gurbani" <[email-masked]> 
> Sent by: [email-masked]
> 
> 08/23/2010 01:38 PM
> 
> To
> 
> "[email-masked]" <[email-masked]>
> 
> cc
> 
> Subject
> 
> [sip-overload] draft-gurbani-sip-overload-control-02 submitted
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 03 Sep 2010 16:20:07 -0500

On 09/03/2010 03:25 PM, Bharrat, Shaun wrote:
> consisting [...] of multiple blades. At first I thought this wasn't
> allowed by the text but on further reading of section 6: [...] seems
> to allow repeated sequence numbers provided that ones with updated

OK, good.  Let's concentrate on the other point, then.

> Doesn't quite do it for us. If we are sending 300 cps to a peer, and
> a *single* error occurs, we are not going to switch all the calls to
> another peer until a probe completes. (Not unless we want to get into
> a fistfight with the network design guys.) This would have to be
> something where over some short period a large % of the calls start
> failing, then we'll switch off.
>
> We obviously do not want to HAVE to violate any MUST clauses so we
> would prefer this be worded as:
>
>   entity MUST stop sending ....

What you suggest above seems fine --- the core idea of the section
is still retained with the above text.  Unless someone objects, I will
go ahead and use your text in the next revision.

Thanks,

- vijay