Subject: [sip-overload] minutes from SoC Interim Meeting I

From: Salvatore Loreto <[email-masked]>
Date: Fri, 02 Jul 2010 10:50:57 +0200

Hi,
here a draft version of minutes from SoC Interim Meeting I.
Please review the minutes and submit any correction to the chairs by July 7th.
The chairs will send the notes [email-masked] on July Friday 9th.

cheers
/Sal

SoC (Sip Overload Control)
WebEx Interim - I
Tuesday, Jun-29-2010 at 11:00 EDT (17:00 CET; 15:00 UTC) for 1.5hour
Chairs: Volker Hilt&  Salvatore Loreto

(many thanks to Paul Kyzavit and Vijay Gurbani for taking notes)
(attends list at the end)

Reason of the meeting:
-----------------------
Try to speed up the work in the newly created WG.  Also,
for Maastricht we want to focus on the mechanism itself.  So
this virtual meeting is to synchronize on all the work that
has gone into Overload Controlo (oc) while it was at sipping/dispatch.

Agenda presented and accepted.
- 11:00-11:10 Welcome to the WG, Agenda Bash, Logistics (Chairs)
- 11:10-11:40 Summary of Design Team (Eric Noel)
- 11:40-12:00 Design Consideration Draft (Volker Hilt)

Summary of Design Team, Eric Noel
----------------------
IETF chartered a design team on oc; four independent simulation
models were developed and calliberated against each other.

Presented benchmark method -- 2 core proxies, 5 edge proxies.
R-R used, 7 message call setup.

Went through the oc control algorithms of various teams.
ATT used rate- and window-based oc algorithms.
Sonus used sender- and receiver-based flow controls.
Columbia used window-based oc algorithm.
Bell Labs/ALU used loss-based oc algorithm.

There was question about references. They are in these slices and also
in the overload control design draft.

OC algorithms are stable even in face of large retx delays (slide 11).

Results presented for UDP transport only.  Some papers include
studies on TCP, but the most work focuses on UDP.

Paul: Did you only use proxies or some other servers (SBCs, gateways).
Not clear how these results extend to non-proxies.
Eric: Focus on server-to-server control only.

SBCs and GWs also require overload control, it is a real problem
that needs to be investigated to check eventual differences with proxies,
but is out of scope for now (many people agreed).

???: Resources that we consider are those that are required to
process a SIP message not taking into considerations external resources like
codecs, DS0, etc.

Volker: We are trying to achieve SIP servers to handle incoming loads and
this is a different problem than a SIP server running out of audio resources.

Janet Gunn: We want to make sure that signaling survives 9/11 type of
emergencies.

Some discussion on whether an overloaded proxy should give preference
to in-dialog requests.  Generally, yes.  More specifics on the list.

Question if design team is planning to do more work.
Volker said no more planned, but if people would like more they could
revive the team and the simulators.

Overload design, Volker Hilt
----------------
Salvatore: Design draft to be sent to IESG by Sept. 2010.  Please
send comments on it.  After Maastricht IETF we'd go to WGLC.

This draft does not define a solution, just documents the design
space.  Solutions relegated to individual drafts.  More on these
in Maastricht.

Discussion on implicit and explicit overload control.

Discussions on Local Overload Control slide.  General feeling seems
to be that it is a good thing to have as a last resort.  Nothing to
standardize and can be used without any extensions.

Eric: But it is not sufficient to prevent congestion collapse.

Some more discussion on whether SIP extensions needed for implicit
overload control.  No time for detailed discussions, asked to be
taken to the list.

Went through rate-based and loss-based oc, window-based oc and
signal-based oc (503).

Went through message prioritization.
Paul: Should we leave priority to implementations or provide more
guidance?
Discussion ensued, but no consensus.  Need to take it to the mailing
list.

Meeting ended @ 11:38a US Central (10m over schedule).

Attendees:
- Nick Stewart, ATT
- Salvatore Loreto
- Eric Noel
- Ahmed Abdelal
- Anant Ghotkar
- Carolyn Johnson
- Christrian Schmidt
- Geof Hunt
- Janet Gunn
- Mary Barnes
- Muthu Perumal
- Padma
- Partha R
- Paul Jones
- Paul Kyzivat
- Richard Kaczmarek
- Robert Sparks
- Sheshadri Shalya
- Victor Pascual
- Vijay Gurbani
- Volker Hilt

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Jul 2010 09:29:56 -0400

> Discussion ensued, but no consensus.  Need to take it to the mailing

I think the above is ambiguous, or at least might be misconstrued.
I suggest replacing "Went through message prioritization" with 
"Discussed the process by which an upstream node selects messages to be 
redirected/rejected to reduce load."

There is real policy-based prioritization, based insertion and honoring 
of Resource-Priority header.

And then there is the algorithm for selecting messages to be 
diverted/rejected when there is need to do so but no business (is that 
the right word?) policy for doing so.

Perhaps there is no clear cut line between these, but I am inclined to 
think there ought to be. It is the latter that I was concerned with.

My reasoning is that the choice of which messages to reject/divert 
matters to the downstream system - some choices will be better than 
others. Selecting dialog-establishing requests may in general be better 
than selecting messages at random. But that may not always be so, and it 
may not be sufficient.

When a downstream node indicates that it requires its load to be 
reduced, the amount of reduction is requires may well depend on its 
expectation of what will be reduced. IOW the upstream and downstream 
nodes have to agree on what impact the reduction will have. So having 
guidelines for how this should be done, and where it is/isn't 
appropriate to apply local policy, seem important.

(For example, is a request for a 20% reduction in load a request for 20% 
less dialog establishing requests, or 20% less requests, or 20% less 
messages?)

I also asked, without getting an answer, what time window should be 
applied for computing the rate? The probabilistic algorithm for deciding 
whether to drop a message is great, because it doesn't require any 
window at all. But that only works for the messages its applied to. If 
you prefer to drop only dialog establishing requests, but need to 
achieve a reduction in all requests, then it doesn't work.

	Thanks,
	Paul

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 2 Jul 2010 10:10:14 -0400

Many of the same issues also apply to the interaction of policy (e.g., 
drop Invites before dropping other messages) with rate reduction (e.g., 1 
message every 0.1 sec).  It is certainly a solvable problem, and "local 
policy" may vary, but we need to have a consensus, at a minimum, on 
terminology and end results.

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.

From:
Paul Kyzivat <[email-masked]>
To:
Salvatore Loreto <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
07/02/2010 09:30 AM
Subject:
Re: [sip-overload] minutes from SoC Interim Meeting I

                 Thanks,
                 Paul
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 2 Jul 2010 19:54:36 +0530

Janet,
 
As I mentioned in the meeting, the currently mentioned algorithm will
not work well for Dialog stateful entity like B2BUA. All the algorithm
assumes transactions as a unit whereas Dialog stateful entity has to
consider from dialog as a unit. The overload information has to provide
"number of dialog" rather than "number of transaction". In case B2BUA,
the transaction inside the dialogs (like session timer refresh) are not
given priority, it will impact  the existing dialogs (call) during the
overload scenario of the system. IMO, the algorithm has to indicate the
value to the neighbor. 
 
Thanks
Partha  
________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: Friday, July 02, 2010 7:40 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]; [email-masked]
Subject: Re: [sip-overload] minutes from SoC Interim Meeting I

Many of the same issues also apply to the interaction of policy (e.g.,
drop Invites before dropping other messages) with rate reduction (e.g.,
1 message every 0.1 sec).  It is certainly a solvable problem, and
"local policy" may vary, but we need to have a consensus, at a minimum,
on terminology and end results. 

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. 

From: 	Paul Kyzivat <[email-masked]> 
To: 	Salvatore Loreto <[email-masked]> 
Cc: 	"[email-masked]" <[email-masked]> 
Date: 	07/02/2010 09:30 AM 
Subject: 	Re: [sip-overload] minutes from SoC Interim Meeting I

________________________________

may not be sufficient.

                Thanks,
                Paul
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload
<https://www.ietf.org/mailman/listinfo/sip-overload>

---

From: Volker Hilt <[email-masked]>
Date: Fri, 9 Jul 2010 22:34:45 -0400

The semantic of feedback needs to be well defined. I.e., it needs to be 
specified to which messages feedback applies (e.g., the value 10 means 
reduce number of requests by 10%). I think the semantics should be well 
defined ahead of time and not changed on the fly in the protocol (e.g., 
from 10% of dialogs to 10% of transactions to 10% of messages).

Thanks,

Volker

On 7/2/2010 10:24 AM, Parthasarathi R (partr) wrote:
> ------------------------------------------------------------------------
> *From:* [email-masked]
> [mailto:[email-masked]] *On Behalf Of *Janet P Gunn
> *Sent:* Friday, July 02, 2010 7:40 PM
> *To:* Paul Kyzivat (pkyzivat)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [sip-overload] minutes from SoC Interim Meeting I
>
>
> 1 message every 0.1 sec). It is certainly a solvable problem, and "local
> ------------------------------------------------------------------------
>
>
>
>
>
> Salvatore Loreto wrote:
>  > Hi,