Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!

["NOEL, ERIC C (ERIC C)" <[e-mail]>]

Janet,

Thank you for your thorough review and insightful comments.

[Janet Gunn] Pg 1 “This document proposes a   rate-based control solution to complement the loss-based control   defined in [draft-ietf-soc-overload-control-12].”  -> “This document proposes a   rate-based control solution to complement the loss-based control   defined in [draft-ietf-soc-overload-control-12], using the same signaling.”
[Eric Noel] Change accepted.

[Janet Gunn] Pg 3  “an  overloaded server..” -> “an overloaded server.”  (remove extra space and extra “.”)
[Eric Noel] Change accepted

[Janet Gunn] “…since the overloaded server must estimate   a separate target for each client, rather than an overall loss   percentage, equally applicable to all clients.”  I don’t think this is true.  There is no requirement for the “loss” algorithm to send the same loss percentage to all clients.  Suggest rewording as “ since the overloaded server is more likely  to use a different target (maximum rate) for each client, than the loss approach.”
[Eric Noel] Comment well taken, change accepted.

[Janet Gunn] Pg 4 Sec 3.2 Change order Change
“oc: Used by SIP clients to indicate draft-ietf-soc-overload-control- 12 support and by SIP servers to indicate the load reduction amount.   oc parameters defined in draft-ietf-soc-overload-control-12 are  summarized below:”
->  “ oc parameters defined in draft-ietf-soc-overload-control-12 are summarized below: oc: Used by SIP clients to indicate draft-ietf-soc-overload-control-12 support and by SIP servers to indicate the load reduction amount”
“… by SIP servers to notify clients of algorithm in effect.”
-> “… by SIP servers to notify clients of the algorithm in
   effect.”
“A non-zero value is required in conjunction with an "oc" parameter.”
-> “A non-zero value is required in conjunction for all other cases.”
[Eric Noel] Change accepted

[Janet Gunn] Pg 5 Sec 3.3  “Conversely, servers notify clients of selected overload control algorithm”  ->  “Conversely, servers notify clients of the selected overload control algorithm”
[Eric Noel] Change accepted

[Janet Gunn] “Support of rate-based control MUST be indicated by clients setting oc-algo to "rate". Selection of rate-based control MUST be indicated
   by servers by setting oc-algo to ''rate''.”  Do we need to explicitly say “the server can only set oc-algo to ‘rate’ if the client included ‘rate’ in its list of supported algorithms”?
[Eric Noel] Proposed changed is implicitly stated in existing text. Recommend not making any changes.

[Janet Gunn] Sec 3.4 “However, the server MUST be able to evaluate periodically its overload state and estimate …” -> “However, the server MUST periodically evaluate its  overload state and estimate …”
[Eric Noel] Change accepted

[Janet Gunn] Pg 5 – pg 6 “But when deriving this rate the server may need to take into account characteristics of the requests, and the effect of the client prioritization on the load it receives, e.g. CPU utilization will depend upon the characteristics of the requests which would presumably allow the server to take in account prioritization.”
This is long and awkward.  Suggest
“When setting the maximum rate FOR A PARTICULAR CLIENT, the server may need take into account the workload (e.g. cpu load per request) of the distribution of message types from that client.  Furthermore, because the client may prioritize the specific types of messages it sends while under overload restriction, this distribution of message types may be different from (e.g., either higher or lower cpu load) the message distribution for that client under non-overload conditions.”
Similarly “Note that the target SIP request rate is a max rate that may not be attained by the arrival rate at the client, and the server cannot assume that it will.”
Would be clearer as
“Note that the oc parameter for the rate algorithm is an upper bound (in messages per second) on the traffic sent by the client to the server.  The client may send traffic at a rate significantly lower than the upper bound, for a variety of reasons.”
[Eric Noel] Changes accepted with proposed modifications embedded (in caps)

[Janet Gunn] Pg 6 “Upon detection of overload, the server MUST…” -> “Upon detection of overload, and the determination to invoke overload controls, the server MUST…”
[Eric Noel] Changes accepted

[Janet Gunn] Sec 3.5 Needs some introductory text, giving context for the default algorithms. One possibility:
“In determining whether or not to transmit a specific message, the client may use any algorithm that limits the message rate to 1/T messages per second.  It may be strictly deterministic, or it may be probabilistic.  It may, or may not, have a tolerance factor, to allow for short bursts, as long as the long term rate remains below 1/ T.
The algorithm may have provisions for prioritizing traffic in accordance with REQ 13 of RFC5390.
If the algorithms requires other parameters (in addition to “T”, which is 1/oc), they may be set autonomously BY the client, or they may be negotiated independently between client and server.  In either case, the coordination is out of scope for this document.
The default algorithms presented here (one without provisions for prioritizing traffic, one with) are only examples.  Other algorithms that forward messages in conformance with the upper bound of 1/T messages per second may be used.”
[Eric Noel] Changes accepted with proposed modification embedded (in caps)

[Janet Gunn] 3.5.1 It would be easier to follow these algorithms is you provided “default” (or at least “sample”) values for the parameters TAU, TAU0, TAU1, TAU2.
[Eric Noel] In section 3.5, we attempted to address this issue by providing guidelines on how to set these parameters. We certainly can provide sample values.
In Section 3.5.1, After “Note that specification of a value for TAU is beyond the scope of this document.” We will add “Without priority, TAU=4*T is a reasonable compromise between burst size and throttled rate adaptation at low offered rate. While reasonable values for TAU0, TAU1 & TAU2 are: TAU0 = 0, TAU1 = 1/2*TAU2 and TAU2=10*T
=> Please confirm these changes addressed your comment.

[Janet Gunn] Top of pg 7, need commas “If at a new SIP request arrival the content of the bucket is less than or equal to the limit value TAU, then the SIP request is forwarded to the server; otherwise, the SIP request is rejected.”  ->
“If, at a new SIP request arrival, the content of the bucket is less than or equal to the limit value TAU, then the SIP request is forwarded to the server; otherwise, the SIP request is rejected.”
“In particular at mean arrival rates close to 1/T,…”  -> “In particular, at mean arrival rates close to 1/T,”
[Eric Noel] Changes accepted

[Janet Gunn] In some places it says “X” is the “content of the bucket”, in others the “value of the bucket”, and in others the “occupancy of the bucket”, or even “the counter”.  It would be easier to follow if it were more consistent.
[Eric Noel] Will modify document to make more consistent

[Janet Gunn] Bottom of pg 7 I am a little confused by this “At the arrival time of the k-th new SIP request ta(k) after control has been activated, the content of the bucket is provisionally updated to the value
   X' = X - ([ta(k) - LCT])
   where X is the content of the bucket after arrival of the last forwarded SIP request, and LCT is the time at which the last SIP request was forwarded.”

1.       First, it is an awfully long sentence, so it might be clearer if you broke it up.  More importantly, I am confused between the relationship between “ta(k)” and “LCT”.

2.       If no messages have been dropped, is LCT = ta(k-1) ?

3.       If n messages in a row have been dropped, is LCT = ta(k-n-1)?

4.       What do the square brackets ([]) mean?
[Eric Noel]
1. Will try to break up sentence to ease in readability.
2. If the k-th new SIP request (arrival time ta(k)) is not rejected, then yes LCT will set to ta(k)
3. If n consecutive SIP requests are dropped, but the n+1-th plus, then LCT will be set to ta(k+n+1)
4. Square bracket seems to be superfluous. It will be removed in next version.

[Janet Gunn] Top of page 8 “When the first response from the server has been received indicating control activation (oc-validity>0), LCT is set to the time of    activation, and the occupancy of the bucket is initialized to the parameter TAU0 (preferably configurable) which is 0 or larger but less than or equal to TAU.”
Does “occupancy of the bucket” = X? Clearer if you say so.
[Eric Noel] In page 7, we stated “…X is the content of the bucket after arrival of the last forwarded SIP request”  Within the context of page 8 sentence, would replacing “and the occupancy of the bucket is initialized to” with “and the size of the bucket is initialized to” address your comment?

[Janet Gunn] Can you explain why you set it (X?)  to TAU0, rather than leaving it at its current value?
[Eric Noel] Each time the control is activated, we reset the bucket content to a configurable value TAU0.  The larger TAU0 (bounded by 0 and T+TAU) the more offered load would be accepted. If there were strong correlation between successive overload events, keeping the last used value would make sense. But since we do not have any prior knowledge on such a correlation, we opted to re-initialize the bucket size to TAU0.

[Janet Gunn] Related question, if X >0 when the overload control ends, do you continue to process the bucket according to the algorithm, until the bucket empties? Or do you just send everything?
[Eric Noel] Until client is notified by server to abate control, the client will keep controlling load towards the server. As soon as the server notifies the client to stop the control, the client should no longer control load.  This further articulated in page 6, “However, when both oc-value and oc-validity are 0, the client should immediately stop throttling.”

[Janet Gunn] If you are plugging along with, say oc=100 (100 messages per second) and then oc changes to 50 (50 messages per second) (oc-validity >0 the whole time), then what happens?
[Eric Noel] Each time the client receives a new oc value, it updates T accordingly (T = 1/oc value).  Reducing oc by 1/2 would double T and double the bucket size increment following acceptance of a new SIP request.

[Janet Gunn] I would make the second (priority based) algorithm a separate subsection, 3.5.2.  That would make it easier to follow.
[Eric Noel] Change accepted. Will add Section 3.5.2 Priority treatment.

[Janet Gunn]  I’d also add a statement something like (if I am understanding this correctly):
“This section presents a priority based rate-control algorithm. Normal priority messages are throttled  when the transmission rate reaches R1.  Priority messages may continue to be sent when the transmission rate exceeds R1 , and are not throttled until the overall (priority and normal) transmission rate exceeds R2 (with R2 <= oc).”
Then include some text on the relationship between  TAU 1 and TAU2, and R1 and R2.
If I am not understanding it properly, then provide a better explanation, and explain how TAU1 and TAU2 relate to the explanation.
[Eric Noel] The priority rate-based overload control must still limit the combined rate of priority and non-priority load (R1+R2) so that the admitted rate does not exceed rate 1/TAU.  To provide priority treatment, two tolerance parameters TAU1 & TAU2 must be introduced. In the proposed approach, TAU1 modulates deviation of combined priority and non priority arrival rates from expected inter arrival time T.  While TAU2, in effect, control how close from strict priority the control is (in the proposed approach for a fixed TAU1, the larger TAU2 the larger priority traffic bursts are accepted or the more priority traffic is accepted while conforming to the rate limit 1/TAU).
=> Please let me know if you wish to further discuss this area.

[Janet Gunn] Top of pg 9 Change  “Note that specification of a value for TAU is beyond the scope of  this document.”
-> “Note that specification of a value for TAU, and any communication or coordination between servers,  is beyond the scope of this document.”
[Eric Noel] Change accepted

[Janet Gunn]  I don’t think “emission interval” is the right term.  Maybe “inter-transmission interval”?
[Eric Noel] Yes, inter-transmission or inter-arrival time would work better.

[Janet Gunn] In this “LCT:  arrival time of last conforming SIP request….”, what does “conforming SIP request” mean?  Do you mean the last SIP request that was sent to the server?
[Eric Noel] Yes, let’s replace “conforming” by  “last SIP request that was sent to the server”

[Janet Gunn] In this, “ta: arrival time of last arrival” “last” is not clear.  Do you mean the “most recent arrival”?  Or the “previous arrival”?
[Eric Noel] ta is the arrival time of the SIP request the algorithm is operating upon, the last arrival or most recent arrival if this works better.

[Janet Gunn] Here you say “X: current value of leaky bucket counter (initialized to 0)”.  But earlier (unless I am confused), you said that X was initialized to TAU0
[Eric Noel] Good catch, should be initialize to TAU0

[Janet Gunn]
“  // After first arrival, calculate auxiliary variable Xp
   Xp = X - (ta - LCT);”
Do you really mean only after the FIRST arrival?  Or do you mean after EACH arrival?  Do you also update ta with each arrival?
[Eric Noel] Should be “After most recent arrival” (with your suggested terminology above)

[Janet Gunn]What do you mean by “Accept SIP request”?  Do you mean “transmit SIP request?
[Eric Noel] Yes. Will replace text to make it clearer

[Janet Gunn]
In the priority algorithm, if I am understanding it correctly  on this line
“if (AnyRequestReceived && Xp <= TAU1 || PriorityRequestReceived &&
   Xp <= TAU2 && Xp > TAU1)”
Why do you need the final “Xp > TAU1” clause?  Wouldn’t it work just as well without it?
[Eric Noel] Yes, Xp > TAU1 is redundant and will be removed

[Janet Gunn]
Top of page 11  I am not really knowledgeable about the resonant case, but it seems to me that in this bullet
“     . If TAU0 is chosen to be equal to TAU and all sources were to
        activate control at the same time due to an extremely high
        request rate,”
the issue is more the abrupt INCREASE in the request rate, rather than just the high VALUE of the request rate.
[Eric Noel] Correct

[Janet Gunn] In the example in section 4, the SIP response (for the non-overloaded case), seems to be missing the “oc” parameter.
[Eric Noel] Yes, 100-TRYING should have the following parameters set oc=0;oc-algo="rate";oc-validity=0

Please note, we will wait until expiration of WGLC prior updating our draft RFC. Once again your comments and/or suggestions are most appreciated.

Thanks

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
[e-mail]<mailto:[e-mail]>

From: [e-mail] [mailto:[e-mail]] On Behalf Of Janet P Gunn
Sent: Thursday, June 20, 2013 3:45 PM
To: Janet P Gunn
Cc: [e-mail]; [e-mail]; Volker Hilt
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!


Here is my more complete review.

Pg 1

“This document proposes a   rate-based control solution to complement the loss-based control   defined in [draft-ietf-soc-overload-control-12].”
->
“This document proposes a   rate-based control solution to complement the loss-based control   defined in [draft-ietf-soc-overload-control-12], using the same signaling.”

Pg 3
“an  overloaded server..”
->
“an overloaded server.”
(remove extra space and extra “.”)

“…since the overloaded server must estimate   a separate target for each client, rather than an overall loss   percentage, equally applicable to all clients.”
I don’t think this is true.  There is no requirement for the “loss” algorithm to send the same loss percentage to all clients.  Suggest rewording as “ since the overloaded server is more likely  to use a different target (maximum rate) for each client, than the loss approach.”

Pg 4

Sec 3.2
Change order
Change
“oc: Used by SIP clients to indicate draft-ietf-soc-overload-control-
   12 support and by SIP servers to indicate the load reduction amount.

   oc parameters defined in draft-ietf-soc-overload-control-12 are
   summarized below:”
->
 “   oc parameters defined in draft-ietf-soc-overload-control-12 are
   summarized below:

oc: Used by SIP clients to indicate draft-ietf-soc-overload-control-
   12 support and by SIP servers to indicate the load reduction amount”

“… by SIP servers to notify clients of algorithm in
   effect.”
->
“… by SIP servers to notify clients of the algorithm in
   effect.”

“A non-zero value is required in conjunction with an "oc" parameter.”
->
“A non-zero value is required in conjunction for all other cases.”

Pg 5

Sec 3.3

“Conversely, servers notify clients of selected overload
   control algorithm”
->
“Conversely, servers notify clients of the selected overload
   control algorithm”

“Support of rate-based control MUST be indicated by clients setting
   oc-algo to "rate". Selection of rate-based control MUST be indicated
   by servers by setting oc-algo to ''rate''.”

Do we need to explicitly say “the server can only set oc-algo to ‘rate’ if the client included ‘rate’ in its lost of supported algorithms”?

Sec 3.4

“However, the server MUST be able to evaluate periodically its
   overload state and estimate …”
->
“However, the server MUST periodically evaluate its
   overload state and estimate …”


Pg 5 – pg 6
“But when deriving this
   rate the server may need to take into account characteristics of the
   requests, and the effect of the client prioritization on the load it
   receives, e.g. CPU utilization will depend upon the characteristics
   of the requests which would presumably allow the server to take in
   account prioritization.”

This is long and awkward.  Suggest
“When setting the maximum rate, in messages per second, for a particular client, the server may need take into account the workload (e.g. cpu load per request) of the distribution of message types from that client.  Furthermore, because the client may prioritize the specific types of messages it sends while under overload restriction, this distribution of message types may be different from (e.g., either higher or lower cpu load) the message distribution for that client under non-overload conditions.”

Similarly
“Note that the target SIP request rate is a max rate that may not be
   attained by the arrival rate at the client, and the server cannot
   assume that it will.”
Would be clearer as
“Note that the oc parameter for the rate algorithm is an upper bound (in messages per second) on the traffic sent by the client to the server.  The client may send traffic at a rate significantly lower  than the upper bound, for a variety of reasons.”

Pg 6

“Upon detection of overload, the server MUST…”
->
“Upon detection of overload, and the determination to invoke overload controls, the server MUST…”

Sec 3.5
Needs some introductory text, giving context for the default algorithms.
One possibility:
“In determining whether or not to transmit a specific message, the client may use any algorithm that limits the message rate to 1/T messages per second.  It may be strictly deterministic, or it may be probabilistic.  It may, or may not, have a tolerance factor , to allow for short bursts, as long as the long term rate remains below 1/ T.

The algorithm may have provisions for prioritizing traffic in accordance with REQ 13 of RFC5390.

If the algorithms requires other parameters (in addition to “T”, which is 1/oc), they may be set autonomously be the client, or they may be negotiated independently between client and server.  In either case, the coordination is out of scope for this document.

The default algorithms presented here (one without provisions for prioritizing traffic, one with) are only examples.  Other algorithms that forward messages in conformance with the upper bound of 1/T messages per second may be used.”

3.5.1

It would be easier to follow these algorithms is you provided “default” (or at least “sample”) values  for the parameters TAU, TAU0, TAU1, TAU2.

Top of pg 7, need commas

“If at a new SIP request arrival the content of the bucket is less
   than or equal to the limit value TAU, then the SIP request is
   forwarded to the server; otherwise, the SIP request is rejected.”
->
“If, at a new SIP request arrival, the content of the bucket is less
   than or equal to the limit value TAU, then the SIP request is
   forwarded to the server; otherwise, the SIP request is rejected.”

“In particular at
   mean arrival rates close to 1/T,…”
->
“In particular, at
   mean arrival rates close to 1/T,”


In some places it says “X” is the “content of the bucket”, in others the “value of the bucket”, and in others the “occupancy of the bucket”, or even “the counter”.  It would be easier to follow if it were more consistent.

Bottom of pg 7

I am a little confused by this
“At the arrival time of the k-th new SIP request ta(k) after control
   has been activated, the content of the bucket is provisionally
   updated to the value

   X' = X - ([ta(k) - LCT])

   where X is the content of the bucket after arrival of the last
   forwarded SIP request, and LCT is the time at which the last SIP
   request was forwarded.”

First, it is an awfully long sentence, so it might be clearer if you broke it up.  More importantly, I am confused between the relationship between “ta(k)” and “LCT”.

If no messages have been dropped, is LCT = ta(k-1) ?
If n messages in a row  have been dropped, is LCT = ta(k-n-1)?

What do the square brackets ([]) mean?

Top of page 8
“When the first response from the server has been received indicating
   control activation (oc-validity>0), LCT is set to the time of
   activation, and the occupancy of the bucket is initialized to the
   parameter TAU0 (preferably configurable) which is 0 or larger but
   less than or equal to TAU.”
Does “occupancy of the bucket” = X? Clearer if you say so.

Can you explain why you set it (X?)  to TAU0, rather than leaving it at its current value?

Related question, if X >0 when the overload control ends, do you continue to process the bucket according to the algorithm, until the bucket empties? Or do you just send everything?

If you are plugging along with, say oc=100 (100 messages per second) and then oc changes to 50 (50 messages per second) (oc-validity >0 the whole time), then what happens?

I would make the second  (priority based) algorithm a separate subsection, 3.5.2.  That would make it easier to follow.  I’d also add a statement something like (if I am understanding this correctly):

“This section presents a priority based rate-control algorithm. Normal priority messages are throttled  when the transmission rate reaches R1.  Priority messages may continue to be sent when the transmission rate exceeds R1 , and are not throttled until the overall (priority and normal) transmission rate exceeds R2 (with R2 <= oc).”

Then include some text on the relationship between  TAU 1 and TAU2, and R1 and R2.

If I am not understanding it properly, then provide a better explanation, and explain how TAU1 and TAU2 relate to the explanation.

Top of pg 9

Change
“Note that specification of a value for TAU is beyond the scope of
   this document.”
->
“Note that specification of a value for TAU, and any communication or coordination between servers,  is beyond the scope of
   this document.”

I don’t think “emission interval” is the right term.  Maybe “inter-transmission interval”?

In this “LCT:  arrival time of last conforming SIP request….”, what does “conforming SIP request” mean?  Do you mean the last SIP request that was sent to the server?

In this, “ta: arrival time of last arrival” “last” is not clear.  Do you mean the “most recent arrival”?  Or the “previous arrival”?

Here you say “X: current value of leaky bucket counter (initialized to 0)”.  But earlier (unless I am confused), you said that X was initialized to TAU0

“  // After first arrival, calculate auxiliary variable Xp
   Xp = X - (ta - LCT);”
Do you really mean only after the FIRST arrival?  Or do you mean after EACH arrival?  Do you also update ta with each arrival?

What do you mean by “Accept SIP request”?  Do you mean “transmit SIP request?

In the priority algorithm, if I am understanding it correctly  on this line
“if (AnyRequestReceived && Xp <= TAU1 || PriorityRequestReceived &&
   Xp <= TAU2 && Xp > TAU1)”
Why do you need the final “Xp > TAU1” clause?  Wouldn’t it work just as well without it?

Top of page 11

I am not really knowledgeable about the resonant case, but it seems to me that in this bullet
“     . If TAU0 is chosen to be equal to TAU and all sources were to
        activate control at the same time due to an extremely high
        request rate,”
the issue is more the abrupt INCREASE in the request rate, rather than just the high VALUE of the request rate.

In the example in section 4, the SIP response (for the non-overloaded case), seems to be missing the “oc” parameter.

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.

[e-mail]<mailto:[e-mail]> wrote on 06/13/2013 09:49:08 AM:

> From: Janet P Gunn/USA/CSC@CSC
> To: Salvatore Loreto <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>, "[e-mail]<mailto:[e-mail]>" <sip-
> [e-mail]<mailto:[e-mail]>>, Volker Hilt <[e-mail]<mailto:[e-mail]>>
> Date: 06/13/2013 09:49 AM
> Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-
> control - PLEASE COMMENT!
> Sent by: [e-mail]<mailto:[e-mail]>
>
> (Coming out from under analysis of the Boston Bombing overload, the
> Oklahoma Tornado overload, etc.)
>
> I am working on some more detailed comments, but here are a couple
> of higher level things
>
> Needs to be made clearer that the "default algorithms" are simply
> "existence" examples, and that other rate based algorithms can be used.
>
> Need to be clearer about what the constraints (how strictly they
> limit traffic) are on other algorithms (and for the default
> algorithms too - if you make TAU too big , you are not really
> limiting to a specific rate)
>
> Need to make it clearer that only "T" (the target rate) is
> transmitted in the "oc" value.  The other parameters (TAU, TAU0,
> TAU1, TAU2) are not part of the message protocol.
> Are you expecting that there will be some external negotiation
> between the client and the server on appropriate values for these
> "tolerance" parameters?
>  Or are you expecting that the client will pick values for these
> parameters on its own, without involving the server in the decision?
>
> Since they are default algorithms, it would make sense (and make it
> easier to follow) to give default, or recommended,  values for TAU,
> TAU0, TAU1, TAU2.
>
> More later, and hoping these thunderstorms don't lead to more overloads!
>
> Janet
> .
>
> [e-mail]<mailto:[e-mail]> wrote on 06/12/2013 09:36:17 AM:
>
> > From: Salvatore Loreto <[e-mail]<mailto:[e-mail]>>
> > To: Volker Hilt <[e-mail]<mailto:[e-mail]>>
> > Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
> > Date: 06/12/2013 09:36 AM
> > Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -
> > PLEASE COMMENT!
> > Sent by: [e-mail]<mailto:[e-mail]>
> >
> > Dear SoC WG participants
> >
> > we are trying to finalize all the SIP Overload efforts before the next
> > IETF meeting in Berlin.
> >
> > The Overload-Rate-Control is the last wg-item we have, and in order to
> > progress it,
> > we need people reading and reviewing and a clear evidence that people
> > have done it.
> > Comments and especially full and deep reviews of the draft are really
> > appreciate, but also simple feedback
> > like "I have read the draft and I think is ready for IESG" would be enough.
> >
> > We haven't received any comments from the first call so we are extending
> > the WGLC till Fri Jun 21th.
> >
> > This is our last draft, let's make a final push to get this done.
> >
> > Thanks
> > Salvatore
> >
> > On 5/24/13 12:59 PM, Volker Hilt wrote:
> > > Folks,
> > >
> > > with draft-ietf-soc-overload-control-13 getting close to finalization,
> > > we are ready to start the WGLC for our last remaining draft:
> > >
> > > http://www.ietf.org/id/draft-ietf-soc-overload-rate-control-04.txt
> > >
> > > The WGLC will end on Fri Jun 7.
> > >
> > > Please review the draft and send your comments to the mailing list. It
> > > is very important that the WG reviews this draft. YOUR comments are
> > > important - even if it is just to say you agree!
> > >
> > > This is our last draft, let's make a final push to get this done.
> > >
> > > Thanks,
> > >
> > > Salvatore and Volker
> > > SOC WG co-chairs
> > >
> >
> >
> > _______________________________________________
> > sip-overload mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________
> sip-overload mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sip-overload