ken carlberg <carlberg@g11.org.uk> · 04/17/2011 03:38 PM

_______________________________________________

sip-overload mailing list

sip-overload@ietf.org

https://www.ietf.org/mailman/listinfo/sip-overload

_______________________________________________

sip-overload mailing list

sip-overload@ietf.org

https://www.ietf.org/mailman/listinfo/sip-overload

__=
_____________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.=
ietf.org/mailman/listinfo/sip-overload
Janet, All,

are you comfortable with the changes for this draft as proposed below?

The proposal is the add the following sentence at the end of the RPH 

discussion in Sec 12:

     The action taken is determined by the characteristics defined
for

     the set of priority values of a Namespace as well as the
local

     policies defined for the various Namespaces supported by
the server.

Thanks,

Volker

On 4/18/2011 1:27 PM, ken carlberg wrote:

> Volker,

>

> I leave it in your hands as to what to keep, remove, or simply move
to another document.

>

> cheers,

>

> -ken

>

>

> On Apr 18, 2011, at 1:22 PM, Volker Hilt wrote:

>

>> Ken,

>>

>> comments inline.

>>> 12. Message Prioritization

>>>

>>> Overload control can require a SIP server to prioritize requests
and

>>> select requests to be rejected or redirected. The selection
is

>>> largely a matter of local policy of the SIP server, the overall

>>> network, and the services it provides. As a general rule,
SIP server

>>> should prioritize requests for ongoing dialogs over requests
that set

>>> up a new dialog. Targeting requests for ongoing dialogs may
prevent

>>> users from modifying or terminating an ongoing dialog.

>>>

>>> While there are many factors which can affect the prioritization
of

>>> SIP requests, the Resource-Priority header field [RFC4412]
is a prime

>>> candidate for marking the prioritization of SIP requests.
Depending

>>> on the particular network and the services it offers, a particular

>>> namespace and priority value in the RPH it could indicate
i) a high

>>> priority request, which should be preserved if possible during

>>> overload, ii) a low priority request, which should be dropped
during

>>> overload, or iii) a label, which has no impact on message

>>> prioritization in this network.

>>

>> I've shortened the added text as follows:

>>> <insert text>  The action taken is

>>> determined by the characteristics defined for the set of priority
values

>>> of a Namespace as well as the local policies defined for the
various

>>> Namespaces supported by the server.

>>>

>>

>> I would suggest to move this text to the Gurbani draft as it defines
the specific processing of RPH.

>>> We note that [RFC4412] allows the presence of multiple RPH
entries

>>> per SIP request. Local policy would determine which Namespace
and

>>> Priority tuple are used to prioritize requests. However, for
the sake of

>>> simplicity, a default position should be the use of the first
RPH entry to

>>> determine the priority of the SIP request.

>>

>> I'm not sure how much this is related to the design considerations
of an overload control mechanism and how much it is related to RPH. I'd
suggest to keep this text out of the oc design document.

>>> Another scenario that should be considered is the presence
of Back

>>> to Back User Agents (B2BUA) that may strip out the RPH from
the

>>> upstream SIP request. Operators or Administrators may choose
to

>>> insert their own RPH to support downstream prioritization
of the SIP

>>> request. This RPH inserted by the B2BUA may conform to a

>>> Namespace set defined in [RPH4412], or it may reflect a new

>>> Namespace set.

>>> </insert text>

>>>

>> Generally, at this point I'd like to keep the changes to the document
to the absolute necessary. It has been discussed for a long time including
issues related to RPH.

>>

>> Thanks,

>>

>> Volker

>>

>>> For a number of reasons, responses should not be targeted
in order to

>>> reduce SIP server load. Responses cannot be rejected and would
have

>>> to be dropped. This triggers the retransmission of the request
plus

>>> the response, leading to even more load. In addition, the
request

>>> associated with a response has already been processed and
dropping

>>> the response will waste the efforts that have been spent on
the

>>> request. Most importantly, rejecting a request effectively
also

>>> removes the request and the response. If no requests are passed

>>> along there will be no responses coming back in return.

>>>

>>> Overload control does not change the retransmission behavior
of SIP.

>>> Retransmissions are triggered using procedures defined in
RFC 3261

>>> [RFC3261] and not subject to throttling.

>>>

>> _______________________________________________

>> sip-overload mailing list

>> sip-overload@ietf.org

>> 
https://www.ietf.org/mailman/listinfo/sip-overload

>

sip-overload mailing =
list

Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 12:43:38 -0000

--Apple-Mail-73-639780307
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 19, 2011, at 8:23 AM, Janet P Gunn wrote:

>=20
> Volker,=20
>=20
> I would just as soon stick with the original text.  =20
>=20
> I think the new proposed text is misleading.=20
>=20
> Both Queuing and Preemption are mechanisms that make sense when the =
"holding time" is several orders of magnitude more that the time to =
manipulate the queue, or organize the preemption.  This makes them =
useful mechanisms for dealing with SIP sessions.  =20
>=20
> But when dealing with a SIP server, processing SIP messages, the =
"holding time" is likely to be the same order of magnitude as the time =
to manipulate the queue, or organize the preemption.  In this case =
introducing queue manipulation or preemption is counterproductive, and =
likely to lead to thrashing..=20

you can't have it both ways.  you cannot say that the Namespaces in =
rfc4412 are the ones to be used, but that their defined characteristics =
(either being queuing or preemption) are inappropriate.

I fail to see how pointing out aspects in rfc4412 is misleading.  Note =
that my suggested text does not advocate nor dismiss existing =
Namespaces.  The text is general and it simply points out existing =
aspects, such as the potential for multiple RPH, which is not mentioned =
in the original text of soc-overload-design.  How that can be construed =
as misleading is beyond me.

-ken

> We have been through this discussion many times, going back to the =
development of  Req 13 in 5390, and I see no advantage in re-introducing =
it to this document.=20
>=20
> Janet
>=20
> 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.=20
> 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.=20
>=20
>=20
> From:	Volker Hilt 
> To:	Janet P Gunn/USA/CSC@CSC
> Cc:	"sip-overload@ietf.org" 
> Date:	04/18/2011 09:23 PM
> Subject:	Re: [sip-overload] draft-ietf-soc-overload-design-05
>=20
>=20
>=20
>=20
> Janet, All,
>=20
> are you comfortable with the changes for this draft as proposed below?=20=

> The proposal is the add the following sentence at the end of the RPH=20=

> discussion in Sec 12:
>=20
>     The action taken is determined by the characteristics defined for
>     the set of priority values of a Namespace as well as the local
>     policies defined for the various Namespaces supported by the =
server.
>=20
> Thanks,
>=20
> Volker
>=20
>=20
>=20
> On 4/18/2011 1:27 PM, ken carlberg wrote:
> > Volker,
> >
> > I leave it in your hands as to what to keep, remove, or simply move =
to another document.
> >
> > cheers,
> >
> > -ken
> >
> >
> > On Apr 18, 2011, at 1:22 PM, Volker Hilt wrote:
> >
> >> Ken,
> >>
> >> comments inline.
> >>> 12. Message Prioritization
> >>>
> >>> Overload control can require a SIP server to prioritize requests =
and
> >>> select requests to be rejected or redirected. The selection is
> >>> largely a matter of local policy of the SIP server, the overall
> >>> network, and the services it provides. As a general rule, SIP =
server
> >>> should prioritize requests for ongoing dialogs over requests that =
set
> >>> up a new dialog. Targeting requests for ongoing dialogs may =
prevent
> >>> users from modifying or terminating an ongoing dialog.
> >>>
> >>> While there are many factors which can affect the prioritization =
of
> >>> SIP requests, the Resource-Priority header field [RFC4412] is a =
prime
> >>> candidate for marking the prioritization of SIP requests. =
Depending
> >>> on the particular network and the services it offers, a particular
> >>> namespace and priority value in the RPH it could indicate i) a =
high
> >>> priority request, which should be preserved if possible during
> >>> overload, ii) a low priority request, which should be dropped =
during
> >>> overload, or iii) a label, which has no impact on message
> >>> prioritization in this network.
> >>
> >> I've shortened the added text as follows:
> >>>   The action taken is
> >>> determined by the characteristics defined for the set of priority =
values
> >>> of a Namespace as well as the local policies defined for the =
various
> >>> Namespaces supported by the server.
> >>>
> >>
> >> I would suggest to move this text to the Gurbani draft as it =
defines the specific processing of RPH.
> >>> We note that [RFC4412] allows the presence of multiple RPH entries
> >>> per SIP request. Local policy would determine which Namespace and
> >>> Priority tuple are used to prioritize requests. However, for the =
sake of
> >>> simplicity, a default position should be the use of the first RPH =
entry to
> >>> determine the priority of the SIP request.
> >>
> >> I'm not sure how much this is related to the design considerations =
of an overload control mechanism and how much it is related to RPH. I'd =
suggest to keep this text out of the oc design document.
> >>> Another scenario that should be considered is the presence of Back
> >>> to Back User Agents (B2BUA) that may strip out the RPH from the
> >>> upstream SIP request. Operators or Administrators may choose to
> >>> insert their own RPH to support downstream prioritization of the =
SIP
> >>> request. This RPH inserted by the B2BUA may conform to a
> >>> Namespace set defined in [RPH4412], or it may reflect a new
> >>> Namespace set.
> >>> 
> >>>
> >> Generally, at this point I'd like to keep the changes to the =
document to the absolute necessary. It has been discussed for a long =
time including issues related to RPH.
> >>
> >> Thanks,
> >>
> >> Volker
> >>
> >>> For a number of reasons, responses should not be targeted in order =
to
> >>> reduce SIP server load. Responses cannot be rejected and would =
have
> >>> to be dropped. This triggers the retransmission of the request =
plus
> >>> the response, leading to even more load. In addition, the request
> >>> associated with a response has already been processed and dropping
> >>> the response will waste the efforts that have been spent on the
> >>> request. Most importantly, rejecting a request effectively also
> >>> removes the request and the response. If no requests are passed
> >>> along there will be no responses coming back in return.
> >>>
> >>> Overload control does not change the retransmission behavior of =
SIP.
> >>> Retransmissions are triggered using procedures defined in RFC 3261
> >>> [RFC3261] and not subject to throttling.
> >>>
> >> _______________________________________________
> >> sip-overload mailing list
> >> sip-overload@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sip-overload
> >
>=20
>=20
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

--Apple-Mail-73-639780307
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

On Apr 19, 2011, at 8:23 AM, Janet P Gunn wrote:

Volker, 

I would just as soon stick with the
original text.  

I think the new proposed text is misleading.

Both Queuing and Preemption are mechanisms
that make sense when the "holding time" is several orders of
magnitude more that the time to manipulate the queue, or organize the preemption.
 This makes them useful mechanisms for dealing with SIP sessions.

But when dealing with a SIP server,
processing SIP messages, the "holding time" is likely to be the
same order of magnitude as the time to manipulate the queue, or organize
the preemption.  In this case introducing queue manipulation or preemption
is counterproductive, and likely to lead to thrashing..

you can't have it both ways.  you cannot say that the Namespaces in rfc4412 are the ones to be used, but that their defined characteristics (either being queuing or preemption) are inappropriate.

I fail to see how pointing out aspects in rfc4412 is misleading.  Note that my suggested text does not advocate nor dismiss existing Namespaces.  The text is general and it simply points out existing aspects, such as the potential for multiple RPH, which is not mentioned in the original text of soc-overload-design.  How that can be construed as misleading is beyond me.

-ken

We have been through this discussion
many times, going back to the development of  Req 13 in 5390, and
I see no advantage in re-introducing it to this document.

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:
Volker Hilt <volker.hilt@alcatel-lucent.com>

To:
Janet P Gunn/USA/CSC@CSC

Cc:
"sip-overload@ietf.org" <sip-overload@ietf.org>

Date:
04/18/2011 09:23 PM

Subject:
Re: [sip-overload] draft-ietf-soc-overload-design-05

Janet, All,

are you comfortable with the changes for this draft as proposed below?

The proposal is the add the following sentence at the end of the RPH 

discussion in Sec 12:

     The action taken is determined by the characteristics defined
for

     the set of priority values of a Namespace as well as the
local

     policies defined for the various Namespaces supported by
the server.

Thanks,

Volker

On 4/18/2011 1:27 PM, ken carlberg wrote:

> Volker,

>

> I leave it in your hands as to what to keep, remove, or simply move
to another document.

>

> cheers,

>

> -ken

>

>

> On Apr 18, 2011, at 1:22 PM, Volker Hilt wrote:

>

>> Ken,

>>

>> comments inline.

>>> 12. Message Prioritization

>>>

>>> Overload control can require a SIP server to prioritize requests
and

>>> select requests to be rejected or redirected. The selection
is

>>> largely a matter of local policy of the SIP server, the overall

>>> network, and the services it provides. As a general rule,
SIP server

>>> should prioritize requests for ongoing dialogs over requests
that set

>>> up a new dialog. Targeting requests for ongoing dialogs may
prevent

>>> users from modifying or terminating an ongoing dialog.

>>>

>>> While there are many factors which can affect the prioritization
of

>>> SIP requests, the Resource-Priority header field [RFC4412]
is a prime

>>> candidate for marking the prioritization of SIP requests.
Depending

>>> on the particular network and the services it offers, a particular

>>> namespace and priority value in the RPH it could indicate
i) a high

>>> priority request, which should be preserved if possible during

>>> overload, ii) a low priority request, which should be dropped
during

>>> overload, or iii) a label, which has no impact on message

>>> prioritization in this network.

>>

>> I've shortened the added text as follows:

>>> <insert text>  The action taken is

>>> determined by the characteristics defined for the set of priority
values

>>> of a Namespace as well as the local policies defined for the
various

>>> Namespaces supported by the server.

>>>

>>

>> I would suggest to move this text to the Gurbani draft as it defines
the specific processing of RPH.

>>> We note that [RFC4412] allows the presence of multiple RPH
entries

>>> per SIP request. Local policy would determine which Namespace
and

>>> Priority tuple are used to prioritize requests. However, for
the sake of

>>> simplicity, a default position should be the use of the first
RPH entry to

>>> determine the priority of the SIP request.

>>

>> I'm not sure how much this is related to the design considerations
of an overload control mechanism and how much it is related to RPH. I'd
suggest to keep this text out of the oc design document.

>>> Another scenario that should be considered is the presence
of Back

>>> to Back User Agents (B2BUA) that may strip out the RPH from
the

>>> upstream SIP request. Operators or Administrators may choose
to

>>> insert their own RPH to support downstream prioritization
of the SIP

>>> request. This RPH inserted by the B2BUA may conform to a

>>> Namespace set defined in [RPH4412], or it may reflect a new

>>> Namespace set.

>>> </insert text>

>>>

>> Generally, at this point I'd like to keep the changes to the document
to the absolute necessary. It has been discussed for a long time including
issues related to RPH.

>>

>> Thanks,

>>

>> Volker

>>

>>> For a number of reasons, responses should not be targeted
in order to

>>> reduce SIP server load. Responses cannot be rejected and would
have

>>> to be dropped. This triggers the retransmission of the request
plus

>>> the response, leading to even more load. In addition, the
request

>>> associated with a response has already been processed and
dropping

>>> the response will waste the efforts that have been spent on
the

>>> request. Most importantly, rejecting a request effectively
also

>>> removes the request and the response. If no requests are passed

>>> along there will be no responses coming back in return.

>>>

>>> Overload control does not change the retransmission behavior
of SIP.

>>> Retransmissions are triggered using procedures defined in
RFC 3261

>>> [RFC3261] and not subject to throttling.

>>>

>> _______________________________________________

>> sip-overload mailing list

>> sip-overload@ietf.org

>> https://www.ietf.org/mailman/listinfo/sip-overload

>

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

--Apple-Mail-73-639780307--

From keith.drage@alcatel-lucent.com  Tue Apr 19 06:04:03 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F1F78E0663 for ; Tue, 19 Apr 2011 06:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.849
X-Spam-Level: 
X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHnW4LSvjh14 for ; Tue, 19 Apr 2011 06:03:54 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfc.amsl.com (Postfix) with ESMTP id CBBE3E065A for ; Tue, 19 Apr 2011 06:03:53 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3JD3D1Y002305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 15:03:41 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 19 Apr 2011 15:03:04 +0200
From: "DRAGE, Keith (Keith)" 
To: ken carlberg 
Date: Tue, 19 Apr 2011 15:03:03 +0200
Thread-Topic: [sip-overload] draft-ietf-soc-overload-design-05
Thread-Index: Acv+jsF3s8sG4xGrQCGJsYydTr7qlwAAejlg
Message-ID: 
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>   <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>
In-Reply-To: <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21EC517B7FRMRSSXCHMBSC3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Cc: "sip-overload@ietf.org" 
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 13:04:03 -0000

--_000_EDC0A1AE77C57744B664A310A0B23AE21EC517B7FRMRSSXCHMBSC3d_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

My confirmation was on what Janet wrote, rather than the original text.

Two comments.

1)         Any statement about some specific RPH being taken as a default a=
re inappropriate. If you are using RPH you must handle them in the way you =
already know. If you do not know about an RPH value, then you have to ignor=
e it (and possibly delete it in the outgoing INVITE depending on your polic=
y). There are certainly use cases where multiple RPH values can exist, cove=
ring different aspects of priority on the same request. It may be the secon=
d one that is received that defines the priority in regard to the handling =
in the SIP server itself (as opposed to priority of giving a media stream o=
r whatever).

2)         In a case of load shedding, I suspect that the discussion on whe=
ther either priority or pre-emption are relevant depend on whether you are =
using them to represent the request to the original target server that indi=
cated overload, or to some other server. I believe that in the case of repr=
esenting to the original targetted server it is inappropriate. It is making=
 the assumption that some of the existing traffic directed from this server=
 to that server is somehow responsible for the overload, and that is an ent=
irely invalid assumption.

Regards

Keith

________________________________
From: ken carlberg [mailto:carlberg@g11.org.uk]
Sent: 19 April 2011 13:39
To: DRAGE, Keith (Keith)
Cc: Janet Gunn; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05

If your comment is about the original text, then we are in some measure of =
agreement.  If you agree with a position that its incorrect to point out th=
e characteristics for currently defined Namespaces as stated in rfc4412, th=
en we are in disagreement.

-ken

On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:

Janet's statements about RPH align with the way I understand RPH works.

Keith

________________________________
From: sip-overload-bounces@ietf.org [=
mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: 18 April 2011 19:21
To: ken carlberg
Cc: sip-overload-bounces@ietf.org; si=
p-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05

Ken,

First of all, that text is included in quite a few of the soc documents, so=
 if you change it in the design doc, it will need to be changed in the othe=
rs too.

More importantly, I STRONGLY disagree with the statement that  " The action=
 taken is determined by the characteristics defined for the set of priority=
 values of a Namespace (e.g., preemption versus queuing) ".

 Neither "preemption" nor "queuing" are appropriate responses to a request =
for load shedding.  Either the request is shed, or it is not.  AFAIK, there=
 is no intention to "preempt" another request, nor to change in the order i=
n which the messages respond to load shedding..

In particular, in systems already deployed, SIP messages using the ets/wps =
family of namespaces (which are defined as "queuing based" , and do queue f=
or MEDIA resources) receive exemption from SIP server  overload based shedd=
ing.  They do NOT have any special queuing based behavior  for SIP server r=
esources.  Not do they preempt other SIP requests.

Furthermore, the behavior associated with a particular namespace is highly =
dependant on the particular network.  dsn.flash-override is not going to el=
icit any priority behavior in a civilian or public network.  It will certai=
nly not  preempt anything.  Conversely, ets.0, wps.0  is not going to elici=
t any priority behavior in the DSN network

The statement "An example local policy may even include exemptions from net=
work management control." introduces a new term - " network management cont=
rol" which would need to be defined.  I presume that what you really mean i=
n this context is "exemption from load shedding".  This is already covered =
in i) of the existing text.

I fail to see the reason for your proposed statement "However, for the sake=
 of simplicity, a default position should be the use of the first RPH entry=
 to   determine the priority of the SIP request. "  AFAIK, the order of the=
 headers is not generally relevant to SIP, and I do not see any particular =
need to introduce it here.   Furthermore, a given SIP agent only "understan=
ds" certain namespaces.  It seems highly  counterproductive to suggest that=
 a SIP server, by default, should "use" a namespace it doesn't understand (=
just because it is "first") , and ignore the one(s) it does understand (jus=
t because not "first").

Even if you change the statement to read "the first RPH entry it understand=
s", you would need a "default behavior" to go with the "default namespace."

As far as I am concerned, if a particular SIP server does NOT have a local =
policy for RPH (both which namespaces are relevant/understood, and the appr=
opriate behavior for each namespace or combination of namespaces), then it =
should simply ignore the RPH namespaces.  This seems consistent with generi=
c SIP behavior with regard to namespaces in general.

I fail to see the significance of the statement about B2BUAs.  ALL SIP serv=
ers, (not just B2BUAs) can and will insert, delete, or change the RPH.

 I also fail to see the need to refer explicitly to Namespaces not defined =
in RFC4412.  There are already a large number of IETF registered RPH namesp=
aces which do not appear in RFC4412 (see RFC 5478 for example) and others h=
ave been proposed (for instance draft-ietf-ecrit-local-emergency-rph-namesp=
ace).  If you are suggesting that specific networks may be using purely "pr=
ivate" RPH namespaces that have never been subject to IETF review, that may=
 well be true in practice, but I don't think it should be introduced into I=
ETF documents- especially ones that are not primarily about RPH.

Janet

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

From:

ken carlberg >

To:

sip-overload@ietf.org

Date:

04/17/2011 03:38 PM

Subject:

[sip-overload] draft-ietf-soc-overload-design-05

________________________________

Hello,

in following up on the discussion point I brought up at the Prague-IETF mee=
ting concerning RPH related text, I've added some suggested text to section=
 12 of draft-ietf-soc-overload-design-05.  The suggested text is bound by t=
he following tags:

The purpose of the new text is to present a more complete picture and point=
 out aspects that others following this effort should be aware of.  I've ke=
pt the rest of the original text for that section as is (ie, I did not remo=
ve any original text).  I've also sent the suggested text to Martin and Jam=
es for a sanity check before posting to the list.

cheers,

-ken

 12.  Message Prioritization

  Overload control can require a SIP server to prioritize requests and
  select requests to be rejected or redirected.  The selection is
   largely a matter of local policy of the SIP server, the overall
  network, and the services it provides.  As a general rule, SIP server
  should prioritize requests for ongoing dialogs over requests that set
  up a new dialog.  Targeting requests for ongoing dialogs may prevent
  users from modifying or terminating an ongoing dialog.

  While there are many factors which can affect the prioritization of
  SIP requests, the Resource-Priority header field [RFC4412] is a prime
  candidate for marking the prioritization of SIP requests.  Depending
  on the particular network and the services it offers, a particular
  namespace and priority value in the RPH it could indicate i) a high
  priority request, which should be preserved if possible during
  overload, ii) a low priority request, which should be dropped during
  overload, or iii) a label, which has no impact on message
  prioritization in this network.   The action taken is
   determined by the characteristics defined for the set of priority values
   of a Namespace (e.g., preemption versus queuing) as well as the
   local policies defined for the various Namespaces supported by the
   server.  An example local policy may even include exemptions from
   network management control.

  We note that [RFC4412] allows the presence of multiple RPH entries
   per SIP request.  Local policy would determine which Namespace and
   Priority tuple are used to prioritize requests.  However, for the sake o=
f
   simplicity, a default position should be the use of the first RPH entry =
to
   determine the priority of the SIP request.

  Another scenario that should be considered is the presence of Back
   to Back User Agents (B2BUA) that may strip out the RPH from the
   upstream SIP request.  Operators or Administrators may choose to
   insert their own RPH to support downstream prioritization of the SIP
   request.  This RPH inserted by the B2BUA may conform to a
   Namespace set defined in [RPH4412], or it may reflect a new
   Namespace set.

  For a number of reasons, responses should not be targeted in order to
  reduce SIP server load.  Responses cannot be rejected and would have
  to be dropped.  This triggers the retransmission of the request plus
  the response, leading to even more load.  In addition, the request
  associated with a response has already been processed and dropping
  the response will waste the efforts that have been spent on the
  request.  Most importantly, rejecting a request effectively also
  removes the request and the response.  If no requests are passed
  along there will be no responses coming back in return.

  Overload control does not change the retransmission behavior of SIP.
  Retransmissions are triggered using procedures defined in RFC 3261
  [RFC3261] and not subject to throttling.
_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

--_000_EDC0A1AE77C57744B664A310A0B23AE21EC517B7FRMRSSXCHMBSC3d_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

My confirmation was on what Janet wrot=
e,
rather than the original text.

Two comments.=

1)      =
   Any
statement about some specific RPH being taken as a default are inappropriat=
e. If
you are using RPH you must handle them in the way you already know. If you =
do
not know about an RPH value, then you have to ignore it (and possibly delet=
e it
in the outgoing INVITE depending on your policy). There are certainly use c=
ases
where multiple RPH values can exist, covering different aspects of priority=
 on
the same request. It may be the second one that is received that defines th=
e
priority in regard to the handling in the SIP server itself (as opposed to
priority of giving a media stream or whatever).

2)      =
   In
a case of load shedding, I suspect that the discussion on whether either
priority or pre-emption are relevant depend on whether you are using them t=
o
represent the request to the original target server that indicated overload=
, or
to some other server. I believe that in the case of representing to the
original targetted server it is inappropriate. It is making the assumption =
that
some of the existing traffic directed from this server to that server is
somehow responsible for the overload, and that is an entirely invalid
assumption. 

Regards

Keith

From:=

ken carlberg [mailto:carlberg@g11.org.uk] 

Sent: 19 April 2011 13:39
To: DRAGE, Keith (Keith)

Cc: Janet Gunn;
sip-overload@ietf.org

Subject: Re: [sip-overload]
draft-ietf-soc-overload-design-05

If your comment is about the original text, then we are in some mea=
sure
of agreement.  If you agree with a position that its incorrect to poin=
t
out the characteristics for currently defined Namespaces as stated in rfc44=
12,
then we are in disagreement.

-ken

On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:=

Janet’s statements about RPH ali=
gn
with the way I understand RPH works.<=
/p>

 =

Keith<=
/o:p>

 =

From:=
 sip-overload-bounces@ietf.org=
 [mailto:sip-overload-bounces@iet=
f.org] On
Behalf Of Janet =
P Gunn

Sent: 18 April 2011 19:21

To: ken carlberg

Cc: sip-overload-bounces@ietf.org=
; sip-overload@ietf.org

Subject: Re: [sip-overload]
draft-ietf-soc-overload-design-05

Ken, <=
br>

First
of all, that text is included in quite a few of the soc documents, so if yo=
u
change it in the design doc, it will need to be changed in the others too.<=
/span> 

More
importantly, I STRONGLY disagree with the statement that  " The
action taken is determined by the characteristics defined for the set of
priority values of a Namespace (e.g., preemption versus queuing) ". 

 Neither
"preemption" nor "queuing" are appropriate responses to=
 a
request for load shedding.  Either the request is shed, or it is not.
 AFAIK, there is no intention to "preempt" another request, =
nor
to change in the order in which the messages respond to load shedding.. &nb=
sp; 

In
particular, in systems already deployed, SIP messages using the ets/wps fam=
ily
of namespaces (which are defined as "queuing based" , and do queu=
e
for MEDIA resources) receive exemption from SIP server  overload based
shedding.  They do NOT have any special queuing based behavior  f=
or
SIP server resources.  Not do they preempt other SIP requests.<=
/font> 

Furthermore,
the behavior associated with a particular namespace is highly dependant on =
the
particular network.  dsn.flash-override is not going to elicit any pri=
ority
behavior in a civilian or public network.  It will certainly not
 preempt anything.  Conversely, ets.0, wps.0  is not going t=
o
elicit any priority behavior in the DSN network 

The
statement "An example local policy may even include exemptions from
network management control." introduces a new term - " network
management control" which would need to be defined.  I presume th=
at
what you really mean in this context is "exemption from load
shedding".  This is already covered in i) of the existing text. 

I fail
to see the reason for your proposed statement "However, for the sake o=
f
simplicity, a default position should be the use of the first RPH entry to
  determine the priority of the SIP request. "  AFAIK, the o=
rder
of the headers is not generally relevant to SIP, and I do not see any
particular need to introduce it here.   Furthermore, a given SIP agent
only "understands" certain namespaces.  It seems highly
 counterproductive to suggest that a SIP server, by default, should
"use" a namespace it doesn't understand (just because it is
"first") , and ignore the one(s) it does understand (just because=
 not
"first"). =

Even
if you change the statement to read "the first RPH entry it
understands", you would need a "default behavior" to go with=
 the
"default namespace." 

As far
as I am concerned, if a particular SIP server does NOT have a local policy =
for
RPH (both which namespaces are relevant/understood, and the appropriate
behavior for each namespace or combination of namespaces), then it should
simply ignore the RPH namespaces.  This seems consistent with generic =
SIP
behavior with regard to namespaces in general. 

I fail
to see the significance of the statement about B2BUAs.  ALL SIP server=
s,
(not just B2BUAs) can and will insert, delete, or change the RPH. 

 I
also fail to see the need to refer explicitly to Namespaces not defined in
RFC4412.  There are already a large number of IETF registered RPH
namespaces which do not appear in RFC4412 (see RFC 5478 for example) and ot=
hers
have been proposed (for instance
draft-ietf-ecrit-local-emergency-rph-namespace).  If you are suggestin=
g
that specific networks may be using purely "private" RPH namespac=
es
that have never been subject to IETF review, that may well be true in pract=
ice,
but I don't think it should be introduced into IETF documents- especially o=
nes
that are not primarily about RPH. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please de=
lete
without copying and kindly advise us by e-mail of the mistake in delivery.<=
span
class=3Dapple-converted-space> 

NOTE: Regardless of content, this e-mail shall not operate to bind CSC to a=
ny
order or other contract unless pursuant to explicit written agreement or
government initiative expressly permitting the use of e-mail for such purpo=
se. 

  From:

  ken carlberg <carlberg@g11.org.uk>

  To:

  sip-overload@=
ietf.org

  Date:

  04/17/2011 03:38 PM

  Subject:=

  [sip-overload] draft-ietf-soc-overload-design-05

Hello, 

in following up on the discussion point I brought up at the Prague-IETF mee=
ting
concerning RPH related text, I've added some suggested text to section 12 o=
f draft-ietf-soc-overload-design-05.  The sug=
gested
text is bound by the following tags: 

<insert text><=
/font> 

</insert text> 

The purpose of the new text=
 is to
present a more complete picture and point out aspects that others following
this effort should be aware of.  I've kept the rest of the original te=
xt
for that section as is (ie, I did not remove any original text).  I've
also sent the suggested text to Martin and James for a sanity check before
posting to the list. =
;

cheers, 

-ken 

 12.  Message Prioritization

  Overload control can require a SIP server to prioritize requests and=

  select requests to be rejected or redirected.  The selection is=

   largely a matter of local policy of the SIP server, the overal=
l

  network, and the services it provides.  As a general rule, SIP
server

  should prioritize requests for ongoing dialogs over requests that se=
t

  up a new dialog.  Targeting requests for ongoing dialogs may
prevent

  users from modifying or terminating an ongoing dialog.

  While there are many factors which can affect the prioritization of<=
br>
  SIP requests, the Resource-Priority header field [RFC4412] is a prim=
e

  candidate for marking the prioritization of SIP requests.
 Depending

  on the particular network and the services it offers, a particular
  namespace and priority value in the RPH it could indicate i) a high<=
br>
  priority request, which should be preserved if possible during

  overload, ii) a low priority request, which should be dropped during=

  overload, or iii) a label, which has no impact on message

  prioritization in this network.&=
nbsp; <insert text> The action taken i=
s 

   determined by the characteristics defined for the set of prior=
ity
values 

   of a Namespace (e.g., preemption versus queuing) as well as th=
e 

   local policies defined for the various Namespaces supported by=
 the 

   server.  An example local policy may even include exempti=
ons
from 

   network management control. 

  We note that [RFC4412] allows the presence of multiple RPH entries

   per SIP request.  Local policy would determine which
Namespace and 

   Priority tuple are used to prioritize requests.  However,=
 for
the sake of 

   simplicity, a default position should be the use of the first =
RPH
entry to 

   determine the priority of the SIP request. 

  Another scenario that should be considered is the presence of Back 

   to Back User Agents (B2BUA) that may strip out the RPH from th=
e 

   upstream SIP request.  Operators or Administrators may ch=
oose
to 

   insert their own RPH to support downstream prioritization of t=
he
SIP 

   request.  This RPH inserted by the B2BUA may conform to a=

   Namespace set defined in [RPH4412], or it may reflect a new 

   Namespace set. 

   </ins=
ert
text>

  For a number of reasons, responses should not be targeted in order t=
o

  reduce SIP server load.  Responses cannot be rejected and would
have

  to be dropped.  This triggers the retransmission of the request
plus

  the response, leading to even more load.  In addition, the requ=
est

  associated with a response has already been processed and dropping
  the response will waste the efforts that have been spent on the

  request.  Most importantly, rejecting a request effectively als=
o

  removes the request and the response.  If no requests are passe=
d

  along there will be no responses coming back in return.

  Overload control does not change the retransmission behavior of SIP.=

  Retransmissions are triggered using procedures defined in RFC 3261
  [RFC3261] and not subject to throttling. 

__=
_____________________________________________

sip-overload mailing list

sip=
-overload@ietf.org

https://www.=
ietf.org/mailman/listinfo/sip-overload

--_000_EDC0A1AE77C57744B664A310A0B23AE21EC517B7FRMRSSXCHMBSC3d_--

From carlberg@g11.org.uk  Tue Apr 19 06:23:24 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87124E068E for ; Tue, 19 Apr 2011 06:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkGTptFOKrji for ; Tue, 19 Apr 2011 06:23:22 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfc.amsl.com (Postfix) with ESMTP id 9C50AE06EE for ; Tue, 19 Apr 2011 06:23:21 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=cNrqe6hnqMLEgRGf0EMKcF8QZD6OASazcivfX6hkTTKDXq+PyBvoEQBostJhsI1nqMvYLabBSfPaughXVzictsLIH5UalG+/BUmwKCBRK7Ipe+39F53ZteL6cUj7HsjT;
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:63483 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1QCAtc-0002WI-1h; Tue, 19 Apr 2011 13:23:12 +0000
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-75-642166497
From: ken carlberg 
In-Reply-To: 
Date: Tue, 19 Apr 2011 09:23:17 -0400
Message-Id: <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>   <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk> 
To: "DRAGE, Keith (Keith)" 
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "sip-overload@ietf.org" 
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 13:23:24 -0000

--Apple-Mail-75-642166497
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:

> My confirmation was on what Janet wrote, rather than the original =
text.
> =20
> Two comments.
> =20
> 1)         Any statement about some specific RPH being taken as a =
default are inappropriate. If you are using RPH you must handle them in =
the way you already know. If you do not know about an RPH value, then =
you have to ignore it (and possibly delete it in the outgoing INVITE =
depending on your policy). There are certainly use cases where multiple =
RPH values can exist, covering different aspects of priority on the same =
request. It may be the second one that is received that defines the =
priority in regard to the handling in the SIP server itself (as opposed =
to priority of giving a media stream or whatever).

or it may be the first, or the last.  I'll concede the difficulty in =
stating the first "recognized/supported" RPH is the one to be used.  But =
I think one is deferring the problem that arises with no position taken =
at all.  The primary point that I wanted to make was that the =
possibility of multiple RPHs may exist.  I'm fine with removing the text =
of choosing a default RPH in that instance.

> 2)         In a case of load shedding, I suspect that the discussion =
on whether either priority or pre-emption are relevant depend on whether =
you are using them to represent the request to the original target =
server that indicated overload, or to some other server. I believe that =
in the case of representing to the original targetted server it is =
inappropriate. It is making the assumption that some of the existing =
traffic directed from this server to that server is somehow responsible =
for the overload, and that is an entirely invalid assumption.

again, the intent of the suggested added text was to point out to the =
reader that preemption and queuing are *examples* of what has been =
defined so far with respect to Namespaces.  What you have stated above =
makes a case that another Namespace should be defined, otherwise, you =
one is overloading new characteristics from what has already been =
defined. =20

-ken

> Regards
> =20
> Keith
> =20
> From: ken carlberg [mailto:carlberg@g11.org.uk]=20
> Sent: 19 April 2011 13:39
> To: DRAGE, Keith (Keith)
> Cc: Janet Gunn; sip-overload@ietf.org
> Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
> =20
> If your comment is about the original text, then we are in some =
measure of agreement.  If you agree with a position that its incorrect =
to point out the characteristics for currently defined Namespaces as =
stated in rfc4412, then we are in disagreement.
> =20
> -ken
> =20
> =20
> =20
> On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:
>=20
>=20
> Janet=92s statements about RPH align with the way I understand RPH =
works.
> =20
> Keith
> =20
> From: sip-overload-bounces@ietf.org =
[mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
> Sent: 18 April 2011 19:21
> To: ken carlberg
> Cc: sip-overload-bounces@ietf.org; sip-overload@ietf.org
> Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
> =20
>=20
> Ken,=20
>=20
> First of all, that text is included in quite a few of the soc =
documents, so if you change it in the design doc, it will need to be =
changed in the others too.=20
>=20
> More importantly, I STRONGLY disagree with the statement that  " The =
action taken is determined by the characteristics defined for the set of =
priority values of a Namespace (e.g., preemption versus queuing) ".=20
>=20
>  Neither "preemption" nor "queuing" are appropriate responses to a =
request for load shedding.  Either the request is shed, or it is not.  =
AFAIK, there is no intention to "preempt" another request, nor to change =
in the order in which the messages respond to load shedding..  =20
>=20
> In particular, in systems already deployed, SIP messages using the =
ets/wps family of namespaces (which are defined as "queuing based" , and =
do queue for MEDIA resources) receive exemption from SIP server  =
overload based shedding.  They do NOT have any special queuing based =
behavior  for SIP server resources.  Not do they preempt other SIP =
requests.=20
>=20
> Furthermore, the behavior associated with a particular namespace is =
highly dependant on the particular network.  dsn.flash-override is not =
going to elicit any priority behavior in a civilian or public network.  =
It will certainly not  preempt anything.  Conversely, ets.0, wps.0  is =
not going to elicit any priority behavior in the DSN network=20
>=20
> The statement "An example local policy may even include exemptions =
from network management control." introduces a new term - " network =
management control" which would need to be defined.  I presume that what =
you really mean in this context is "exemption from load shedding".  This =
is already covered in i) of the existing text.=20
>=20
> I fail to see the reason for your proposed statement "However, for the =
sake of simplicity, a default position should be the use of the first =
RPH entry to   determine the priority of the SIP request. "  AFAIK, the =
order of the headers is not generally relevant to SIP, and I do not see =
any particular need to introduce it here.   Furthermore, a given SIP =
agent only "understands" certain namespaces.  It seems highly  =
counterproductive to suggest that a SIP server, by default, should "use" =
a namespace it doesn't understand (just because it is "first") , and =
ignore the one(s) it does understand (just because not "first").=20
>=20
> Even if you change the statement to read "the first RPH entry it =
understands", you would need a "default behavior" to go with the =
"default namespace."=20
>=20
> As far as I am concerned, if a particular SIP server does NOT have a =
local policy for RPH (both which namespaces are relevant/understood, and =
the appropriate behavior for each namespace or combination of =
namespaces), then it should simply ignore the RPH namespaces.  This =
seems consistent with generic SIP behavior with regard to namespaces in =
general.=20
>=20
> I fail to see the significance of the statement about B2BUAs.  ALL SIP =
servers, (not just B2BUAs) can and will insert, delete, or change the =
RPH.=20
>=20
>  I also fail to see the need to refer explicitly to Namespaces not =
defined in RFC4412.  There are already a large number of IETF registered =
RPH namespaces which do not appear in RFC4412 (see RFC 5478 for example) =
and others have been proposed (for instance =
draft-ietf-ecrit-local-emergency-rph-namespace).  If you are suggesting =
that specific networks may be using purely "private" RPH namespaces that =
have never been subject to IETF review, that may well be true in =
practice, but I don't think it should be introduced into IETF documents- =
especially ones that are not primarily about RPH.=20
>=20
> Janet
>=20
> 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.=20
> 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.=20
>=20
>=20
>=20
> From:
> ken carlberg 
> To:
> sip-overload@ietf.org
> Date:
> 04/17/2011 03:38 PM
> Subject:
> [sip-overload] draft-ietf-soc-overload-design-05
> =20
>=20
>=20
>=20
> Hello,=20
>=20
> in following up on the discussion point I brought up at the =
Prague-IETF meeting concerning RPH related text, I've added some =
suggested text to section 12 of draft-ietf-soc-overload-design-05.  The =
suggested text is bound by the following tags:=20
> =20
> =20
>=20
> The purpose of the new text is to present a more complete picture and =
point out aspects that others following this effort should be aware of.  =
I've kept the rest of the original text for that section as is (ie, I =
did not remove any original text).  I've also sent the suggested text to =
Martin and James for a sanity check before posting to the list.=20
>=20
> cheers,=20
>=20
> -ken=20
>=20
>=20
>  12.  Message Prioritization
>=20
>   Overload control can require a SIP server to prioritize requests and
>   select requests to be rejected or redirected.  The selection is=20
>    largely a matter of local policy of the SIP server, the overall
>   network, and the services it provides.  As a general rule, SIP =
server
>   should prioritize requests for ongoing dialogs over requests that =
set
>   up a new dialog.  Targeting requests for ongoing dialogs may prevent
>   users from modifying or terminating an ongoing dialog.
>=20
>   While there are many factors which can affect the prioritization of
>   SIP requests, the Resource-Priority header field [RFC4412] is a =
prime
>   candidate for marking the prioritization of SIP requests.  Depending
>   on the particular network and the services it offers, a particular
>   namespace and priority value in the RPH it could indicate i) a high
>   priority request, which should be preserved if possible during
>   overload, ii) a low priority request, which should be dropped during
>   overload, or iii) a label, which has no impact on message
>   prioritization in this network.   The action taken is=20=

>    determined by the characteristics defined for the set of priority =
values=20
>    of a Namespace (e.g., preemption versus queuing) as well as the=20
>    local policies defined for the various Namespaces supported by the=20=

>    server.  An example local policy may even include exemptions from=20=

>    network management control.=20
>  =20
>   We note that [RFC4412] allows the presence of multiple RPH entries  =20=

>    per SIP request.  Local policy would determine which Namespace and=20=

>    Priority tuple are used to prioritize requests.  However, for the =
sake of=20
>    simplicity, a default position should be the use of the first RPH =
entry to=20
>    determine the priority of the SIP request.=20
>=20
>   Another scenario that should be considered is the presence of Back=20=

>    to Back User Agents (B2BUA) that may strip out the RPH from the=20
>    upstream SIP request.  Operators or Administrators may choose to=20
>    insert their own RPH to support downstream prioritization of the =
SIP=20
>    request.  This RPH inserted by the B2BUA may conform to a=20
>    Namespace set defined in [RPH4412], or it may reflect a new=20
>    Namespace set.=20
>    
>=20
>   For a number of reasons, responses should not be targeted in order =
to
>   reduce SIP server load.  Responses cannot be rejected and would have
>   to be dropped.  This triggers the retransmission of the request plus
>   the response, leading to even more load.  In addition, the request
>   associated with a response has already been processed and dropping
>   the response will waste the efforts that have been spent on the
>   request.  Most importantly, rejecting a request effectively also
>   removes the request and the response.  If no requests are passed
>   along there will be no responses coming back in return.
>=20
>   Overload control does not change the retransmission behavior of SIP.
>   Retransmissions are triggered using procedures defined in RFC 3261
>   [RFC3261] and not subject to throttling.=20
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>=20
>=20
>=20
> =20

--Apple-Mail-75-642166497
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

On Apr 19, 2011, at 9:03 AM, DRAGE, =
Keith (Keith) wrote:

My =
confirmation was on what Janet wrote, rather than the original =
text.
 Two =
comments.

 ken carlberg =
[mailto:carlberg@g11.org.uk] 
Sent: 19 April 2011 =
13:39
To: DRAGE, Keith =
(Keith)
Cc: Janet Gunn; sip-overload@ietf.org
Subject: Re: [sip-overload] =
draft-ietf-soc-overload-design-05
If your comment is about =
the original text, then we are in some measure of agreement.  If =
you agree with a position that its incorrect to point out the =
characteristics for currently defined Namespaces as stated in rfc4412, =
then we are in disagreement.
 -ken   On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) =
wrote:
Janet=92s statements about RPH align with the way I =
understand RPH =
works.
  [mailto:sip-overload-bounces@=
ietf.org] On Behalf Of Janet P =
Gunn
Sent: 18 April 2011 =
19:21
To: ken carlberg
Cc: sip-overload-bounces@ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] =
draft-ietf-soc-overload-design-05

 Neither "preemption" nor "queuing" are appropriate =
responses to a request for load shedding.  Either the request is =
shed, or it is not.  AFAIK, there is no intention to "preempt" =
another request, nor to change in the order in which the messages =
respond to load shedding..   

In =
particular, in systems already deployed, SIP messages using the ets/wps =
family of namespaces (which are defined as "queuing based" , and do =
queue for MEDIA resources) receive exemption from SIP server =
 overload based shedding.  They do NOT have any special =
queuing based behavior  for SIP server resources.  Not do they =
preempt other SIP requests. 

The =
statement "An example local policy may even include exemptions from =
network management control." introduces a new term - " network =
management control" which would need to be defined.  I presume that =
what you really mean in this context is "exemption from load shedding". =
 This is already covered in i) of the existing =
text. 

I =
fail to see the reason for your proposed statement "However, for the =
sake of simplicity, a default position should be the use of the first =
RPH entry to   determine the priority of the SIP request. " =
 AFAIK, the order of the headers is not generally relevant to SIP, =
and I do not see any particular need to introduce it here.   =
Furthermore, a given SIP agent only "understands" certain namespaces. =
 It seems highly  counterproductive to suggest that a SIP =
server, by default, should "use" a namespace it doesn't understand (just =
because it is "first") , and ignore the one(s) it does understand (just =
because not "first"). 

As =
far as I am concerned, if a particular SIP server does NOT have a local =
policy for RPH (both which namespaces are relevant/understood, and the =
appropriate behavior for each namespace or combination of namespaces), =
then it should simply ignore the RPH namespaces.  This seems =
consistent with generic SIP behavior with regard to namespaces in =
general. 

I =
fail to see the significance of the statement about B2BUAs.  ALL =
SIP servers, (not just B2BUAs) can and will insert, delete, or change =
the RPH. 

 I also fail to see the need to refer explicitly to =
Namespaces not defined in RFC4412.  There are already a large =
number of IETF registered RPH namespaces which do not appear in RFC4412 =
(see RFC 5478 for example) and others have been proposed (for instance =
draft-ietf-ecrit-local-emergency-rph-namespace).  If you are =
suggesting that specific networks may be using purely "private" RPH =
namespaces that have never been subject to IETF review, that may well be =
true in practice, but I don't think it should be introduced into IETF =
documents- especially ones that are not primarily about =
RPH. 

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. 

ken carlberg <04/17/2011 03:38 =
PM
[sip-overload] =
draft-ietf-soc-overload-design-05

Hello, 

in following up on =
the discussion point I brought up at the Prague-IETF meeting concerning =
RPH related text, I've added some suggested text to section 12 of  
<insert text> 
</insert text> 

The purpose of the new text =
is to present a more complete picture and point out aspects that others =
following this effort should be aware of.  I've kept the rest of =
the original text for that section as is (ie, I did not remove any =
original text).  I've also sent the suggested text to Martin and =
James for a sanity check before posting to the list. 

cheers, 

-ken 

 12. =
 Message Prioritization

  Overload control can require =
a SIP server to prioritize requests and
  select requests to be =
rejected or redirected.  The selection is 
   largely a =
matter of local policy of the SIP server, the overall
  network, =
and the services it provides.  As a general rule, SIP =
server
  should prioritize requests for ongoing dialogs over =
requests that set
  up a new dialog.  Targeting requests =
for ongoing dialogs may prevent
  users from modifying or =
terminating an ongoing dialog.

  While there are many =
factors which can affect the prioritization of
  SIP requests, =
the Resource-Priority header field [RFC4412] is a prime
  =
candidate for marking the prioritization of SIP requests. =
 Depending
  on the particular network and the services it =
offers, a particular
  namespace and priority value in the RPH =
it could indicate i) a high
  priority request, which should be =
preserved if possible during
  overload, ii) a low priority =
request, which should be dropped during
  overload, or iii) a =
label, which has no impact on message
  prioritization in this =
network.  The action =
taken is 
  =
 determined by the characteristics defined for the set of priority =
values 
  =
 of a Namespace (e.g., preemption versus queuing) as well as =
the 
  =
 local policies defined for the various Namespaces supported by =
the 
  =
 server.  An example local policy may even include exemptions =
from 
  =
 network management control. 

  We note that =
[RFC4412] allows the presence of multiple RPH entries   
   per SIP =
request.  Local policy would determine which Namespace and 
   Priority =
tuple are used to prioritize requests.  However, for the sake =
of 
  =
 simplicity, a default position should be the use of the first RPH =
entry to 
  =
 determine the priority of the SIP request. 

  Another =
scenario that should be considered is the presence of Back 
   to Back =
User Agents (B2BUA) that may strip out the RPH from the 
   upstream =
SIP request.  Operators or Administrators may choose to 
   insert =
their own RPH to support downstream prioritization of the SIP 
   request. =
 This RPH inserted by the B2BUA may conform to a 
   Namespace =
set defined in [RPH4412], or it may reflect a new 
   Namespace =
set. 
  =

sip-overload mailing =
list

Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 13:40:56 -0000

This is a multipart message in MIME format.
--=_alternative 004B268285257877_=
Content-Type: text/plain; charset="US-ASCII"

ken carlberg  wrote on 04/19/2011 08:43:31 AM:

> 
> you can't have it both ways.  you cannot say that the Namespaces in 
> rfc4412 are the ones to be used, but that their defined 
> characteristics (either being queuing or preemption) are inappropriate.
> 
Ken,

Consider the circuit switched models from which the RPH concept was 
derived.

With queueing, we queue for trunks, we queue for radio resources.  But we 
do NOT QUEUE in response to SS7 congestion (just a higher level protection 
from being dropped), nor do we queue in response to call gapping or other 
network management controls (just exempt from them).  That does not in any 
way diminish the nature of the HPC (High Probability of Completion) 
marking as inherently "queuing based".

Similarly, in the circuit switched version, MLPP preempts established 
sessions. But it DOES NOT preempt SS7 processing, or network call gapping. 
 That does not in any way diminish the nature of MLPP as "preemption 
based".

Same here.

Using more appropriate (than queuing or preemption) techniques to address 
priority in response to SIP server overload (e.g., exemption from load 
shedding) in no way diminishes the nature of the Namespace as "queuing 
based" or "preemption based".

Janet
--=_alternative 004B268285257877_=
Content-Type: text/html; charset="US-ASCII"

ken carlberg <carlberg@g11.org.uk> wrote on
04/19/2011 08:43:31 AM:

> 

> you can't have it both ways.  you cannot say that the Namespaces
in 

> rfc4412 are the ones to be used, but that their defined 

> characteristics (either being queuing or preemption) are inappropriate.

> 

Ken,

Consider the circuit switched models from which the
RPH concept was derived.

With queueing, we queue for trunks, we queue for radio
resources.  But we do NOT QUEUE in response to SS7 congestion (just
a higher level protection from being dropped), nor do we queue in response
to call gapping or other network management controls (just exempt from
them).  That does not in any way diminish the nature of the HPC (High
Probability of Completion) marking as inherently "queuing based".

Similarly, in the circuit switched version, MLPP preempts
established sessions. But it DOES NOT preempt SS7 processing, or network
call gapping.  That does not in any way diminish the nature of MLPP
as "preemption based".

Same here.

Using more appropriate (than queuing or preemption)
techniques to address priority in response to SIP server overload (e.g.,
exemption from load shedding) in no way diminishes the nature of the Namespace
as "queuing based" or "preemption based".

Janet
--=_alternative 004B268285257877_=--

From keith.drage@alcatel-lucent.com  Tue Apr 19 06:44:04 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7BB7BE06CE for ; Tue, 19 Apr 2011 06:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.862
X-Spam-Level: 
X-Spam-Status: No, score=-106.862 tagged_above=-999 required=5 tests=[AWL=1.386, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R+gwgMTMQ01 for ; Tue, 19 Apr 2011 06:43:53 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfc.amsl.com (Postfix) with ESMTP id 2EBC4E0613 for ; Tue, 19 Apr 2011 06:43:53 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3JDhEgC020653 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 15:43:35 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 19 Apr 2011 15:43:02 +0200
From: "DRAGE, Keith (Keith)" 
To: ken carlberg 
Date: Tue, 19 Apr 2011 15:43:01 +0200
Thread-Topic: [sip-overload] draft-ietf-soc-overload-design-05
Thread-Index: Acv+lPyXU44feN1+RLOTPGaQ5BjI4QAAdhKw
Message-ID: 
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>   <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>  <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>
In-Reply-To: <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21EC517ECFRMRSSXCHMBSC3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: "sip-overload@ietf.org" 
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 13:44:04 -0000

--_000_EDC0A1AE77C57744B664A310A0B23AE21EC517ECFRMRSSXCHMBSC3d_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

With regard to your comment on 1), I believe nothing extra is required. Any=
one setting up multiple namespaces has to define at each entity that is req=
uired to understand them how they are treated in relationship to each other=
. That is part of the implementation. That will define which namespaces exi=
st, and which are used at the receiving entity to give any form of priority=
 handling. There is no reason for SIP overload to alter that relationship i=
n any way, shape, or form.

On 2), I do not believe your comment is correct. The fact that a namespace =
is a pre-emption namespace is not an invitation to pre-empt all other calls=
 until you get your call through, even under situations of no overload. It =
merely states that calls can be pre-empted when this namespace is used. The=
 same applies for priority. Usually the algorithm for handling these DOES N=
OT SAY - handle all calls with this namespace until there are none left, an=
d then move onto others. It deals with things like percentage of traffic an=
d so on. So what I am saying is that the RPH is not a guarantee to override=
 all other traffic, whether overload exists or not.

Regards

Keith

________________________________
From: ken carlberg [mailto:carlberg@g11.org.uk]
Sent: 19 April 2011 14:23
To: DRAGE, Keith (Keith)
Cc: Janet Gunn; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05

On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:

My confirmation was on what Janet wrote, rather than the original text.

Two comments.

1)         Any statement about some specific RPH being taken as a default a=
re inappropriate. If you are using RPH you must handle them in the way you =
already know. If you do not know about an RPH value, then you have to ignor=
e it (and possibly delete it in the outgoing INVITE depending on your polic=
y). There are certainly use cases where multiple RPH values can exist, cove=
ring different aspects of priority on the same request. It may be the secon=
d one that is received that defines the priority in regard to the handling =
in the SIP server itself (as opposed to priority of giving a media stream o=
r whatever).

or it may be the first, or the last.  I'll concede the difficulty in statin=
g the first "recognized/supported" RPH is the one to be used.  But I think =
one is deferring the problem that arises with no position taken at all.  Th=
e primary point that I wanted to make was that the possibility of multiple =
RPHs may exist.  I'm fine with removing the text of choosing a default RPH =
in that instance.

2)         In a case of load shedding, I suspect that the discussion on whe=
ther either priority or pre-emption are relevant depend on whether you are =
using them to represent the request to the original target server that indi=
cated overload, or to some other server. I believe that in the case of repr=
esenting to the original targetted server it is inappropriate. It is making=
 the assumption that some of the existing traffic directed from this server=
 to that server is somehow responsible for the overload, and that is an ent=
irely invalid assumption.

again, the intent of the suggested added text was to point out to the reade=
r that preemption and queuing are *examples* of what has been defined so fa=
r with respect to Namespaces.  What you have stated above makes a case that=
 another Namespace should be defined, otherwise, you one is overloading new=
 characteristics from what has already been defined.

-ken

Regards

Keith

________________________________
From: ken carlberg [mailto:carlberg@g11.org.uk]
Sent: 19 April 2011 13:39
To: DRAGE, Keith (Keith)
Cc: Janet Gunn; sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05

If your comment is about the original text, then we are in some measure of =
agreement.  If you agree with a position that its incorrect to point out th=
e characteristics for currently defined Namespaces as stated in rfc4412, th=
en we are in disagreement.

-ken

On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:

Janet's statements about RPH align with the way I understand RPH works.

Keith

________________________________
From: sip-overload-bounces@ietf.org [=
mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: 18 April 2011 19:21
To: ken carlberg
Cc: sip-overload-bounces@ietf.org; si=
p-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05

Ken,

First of all, that text is included in quite a few of the soc documents, so=
 if you change it in the design doc, it will need to be changed in the othe=
rs too.

More importantly, I STRONGLY disagree with the statement that  " The action=
 taken is determined by the characteristics defined for the set of priority=
 values of a Namespace (e.g., preemption versus queuing) ".

 Neither "preemption" nor "queuing" are appropriate responses to a request =
for load shedding.  Either the request is shed, or it is not.  AFAIK, there=
 is no intention to "preempt" another request, nor to change in the order i=
n which the messages respond to load shedding..

In particular, in systems already deployed, SIP messages using the ets/wps =
family of namespaces (which are defined as "queuing based" , and do queue f=
or MEDIA resources) receive exemption from SIP server  overload based shedd=
ing.  They do NOT have any special queuing based behavior  for SIP server r=
esources.  Not do they preempt other SIP requests.

Furthermore, the behavior associated with a particular namespace is highly =
dependant on the particular network.  dsn.flash-override is not going to el=
icit any priority behavior in a civilian or public network.  It will certai=
nly not  preempt anything.  Conversely, ets.0, wps.0  is not going to elici=
t any priority behavior in the DSN network

The statement "An example local policy may even include exemptions from net=
work management control." introduces a new term - " network management cont=
rol" which would need to be defined.  I presume that what you really mean i=
n this context is "exemption from load shedding".  This is already covered =
in i) of the existing text.

I fail to see the reason for your proposed statement "However, for the sake=
 of simplicity, a default position should be the use of the first RPH entry=
 to   determine the priority of the SIP request. "  AFAIK, the order of the=
 headers is not generally relevant to SIP, and I do not see any particular =
need to introduce it here.   Furthermore, a given SIP agent only "understan=
ds" certain namespaces.  It seems highly  counterproductive to suggest that=
 a SIP server, by default, should "use" a namespace it doesn't understand (=
just because it is "first") , and ignore the one(s) it does understand (jus=
t because not "first").

Even if you change the statement to read "the first RPH entry it understand=
s", you would need a "default behavior" to go with the "default namespace."

As far as I am concerned, if a particular SIP server does NOT have a local =
policy for RPH (both which namespaces are relevant/understood, and the appr=
opriate behavior for each namespace or combination of namespaces), then it =
should simply ignore the RPH namespaces.  This seems consistent with generi=
c SIP behavior with regard to namespaces in general.

I fail to see the significance of the statement about B2BUAs.  ALL SIP serv=
ers, (not just B2BUAs) can and will insert, delete, or change the RPH.

 I also fail to see the need to refer explicitly to Namespaces not defined =
in RFC4412.  There are already a large number of IETF registered RPH namesp=
aces which do not appear in RFC4412 (see RFC 5478 for example) and others h=
ave been proposed (for instance draft-ietf-ecrit-local-emergency-rph-namesp=
ace).  If you are suggesting that specific networks may be using purely "pr=
ivate" RPH namespaces that have never been subject to IETF review, that may=
 well be true in practice, but I don't think it should be introduced into I=
ETF documents- especially ones that are not primarily about RPH.

Janet

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

From:

ken carlberg >

To:

sip-overload@ietf.org

Date:

04/17/2011 03:38 PM

Subject:

[sip-overload] draft-ietf-soc-overload-design-05

________________________________

Hello,

in following up on the discussion point I brought up at the Prague-IETF mee=
ting concerning RPH related text, I've added some suggested text to section=
 12 of draft-ietf-soc-overload-design-05.  The suggested text is bound by t=
he following tags:

The purpose of the new text is to present a more complete picture and point=
 out aspects that others following this effort should be aware of.  I've ke=
pt the rest of the original text for that section as is (ie, I did not remo=
ve any original text).  I've also sent the suggested text to Martin and Jam=
es for a sanity check before posting to the list.

cheers,

-ken

 12.  Message Prioritization

  Overload control can require a SIP server to prioritize requests and
  select requests to be rejected or redirected.  The selection is
   largely a matter of local policy of the SIP server, the overall
  network, and the services it provides.  As a general rule, SIP server
  should prioritize requests for ongoing dialogs over requests that set
  up a new dialog.  Targeting requests for ongoing dialogs may prevent
  users from modifying or terminating an ongoing dialog.

  While there are many factors which can affect the prioritization of
  SIP requests, the Resource-Priority header field [RFC4412] is a prime
  candidate for marking the prioritization of SIP requests.  Depending
  on the particular network and the services it offers, a particular
  namespace and priority value in the RPH it could indicate i) a high
  priority request, which should be preserved if possible during
  overload, ii) a low priority request, which should be dropped during
  overload, or iii) a label, which has no impact on message
  prioritization in this network.   The action taken is
   determined by the characteristics defined for the set of priority values
   of a Namespace (e.g., preemption versus queuing) as well as the
   local policies defined for the various Namespaces supported by the
   server.  An example local policy may even include exemptions from
   network management control.

  We note that [RFC4412] allows the presence of multiple RPH entries
   per SIP request.  Local policy would determine which Namespace and
   Priority tuple are used to prioritize requests.  However, for the sake o=
f
   simplicity, a default position should be the use of the first RPH entry =
to
   determine the priority of the SIP request.

  Another scenario that should be considered is the presence of Back
   to Back User Agents (B2BUA) that may strip out the RPH from the
   upstream SIP request.  Operators or Administrators may choose to
   insert their own RPH to support downstream prioritization of the SIP
   request.  This RPH inserted by the B2BUA may conform to a
   Namespace set defined in [RPH4412], or it may reflect a new
   Namespace set.

  For a number of reasons, responses should not be targeted in order to
  reduce SIP server load.  Responses cannot be rejected and would have
  to be dropped.  This triggers the retransmission of the request plus
  the response, leading to even more load.  In addition, the request
  associated with a response has already been processed and dropping
  the response will waste the efforts that have been spent on the
  request.  Most importantly, rejecting a request effectively also
  removes the request and the response.  If no requests are passed
  along there will be no responses coming back in return.

  Overload control does not change the retransmission behavior of SIP.
  Retransmissions are triggered using procedures defined in RFC 3261
  [RFC3261] and not subject to throttling.
_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

--_000_EDC0A1AE77C57744B664A310A0B23AE21EC517ECFRMRSSXCHMBSC3d_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

With regard to your comment on 1), I
believe nothing extra is required. Anyone setting up multiple namespaces ha=
s to
define at each entity that is required to understand them how they are trea=
ted
in relationship to each other. That is part of the implementation. That wil=
l
define which namespaces exist, and which are used at the receiving entity t=
o
give any form of priority handling. There is no reason for SIP overload to
alter that relationship in any way, shape, or form.

On 2), I do not believe your comment i=
s
correct. The fact that a namespace is a pre-emption namespace is not an
invitation to pre-empt all other calls until you get your call through, eve=
n
under situations of no overload. It merely states that calls can be pre-emp=
ted when
this namespace is used. The same applies for priority. Usually the algorith=
m
for handling these DOES NOT SAY – handle all calls with this namespac=
e until
there are none left, and then move onto others. It deals with things like
percentage of traffic and so on. So what I am saying is that the RPH is not=
 a
guarantee to override all other traffic, whether overload exists or not. 

Regards

Keith

From:=

ken carlberg [mailto:carlberg@g11.org.uk] 

Sent: 19 April 2011 14:23
To: DRAGE, Keith (Keith)

Cc: Janet Gunn;
sip-overload@ietf.org

Subject: Re: [sip-overload]
draft-ietf-soc-overload-design-05

On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:=

My confirmation was on what Janet wrot=
e,
rather than the original text.

 =

Two comments.

 =

1)      =

Any statement about some specific RPH being taken as a default are
inappropriate. If you are using RPH you must handle them in the way you alr=
eady
know. If you do not know about an RPH value, then you have to ignore it (an=
d
possibly delete it in the outgoing INVITE depending on your policy). There =
are
certainly use cases where multiple RPH values can exist, covering different
aspects of priority on the same request. It may be the second one that is
received that defines the priority in regard to the handling in the SIP ser=
ver
itself (as opposed to priority of giving a media stream or whatever).

or it may be the first, or the last.  I'll concede the difficu=
lty
in stating the first "recognized/supported" RPH is the one to be
used.  But I think one is deferring the problem that arises with no
position taken at all.  The primary point that I wanted to make was th=
at
the possibility of multiple RPHs may exist.  I'm fine with removing th=
e
text of choosing a default RPH in that instance.

2)      =

In a case of load shedding, I suspect that the discussion on whether either
priority or pre-emption are relevant depend on whether you are using them t=
o
represent the request to the original target server that indicated overload=
, or
to some other server. I believe that in the case of representing to the
original targetted server it is inappropriate. It is making the assumption =
that
some of the existing traffic directed from this server to that server is
somehow responsible for the overload, and that is an entirely invalid
assumption.

again, the intent of the suggested added text was to point out to t=
he
reader that preemption and queuing are *examples* of what has been defined =
so
far with respect to Namespaces.  What you have stated above makes a ca=
se
that another Namespace should be defined, otherwise, you one is overloading=
 new
characteristics from what has already been defined.  

-ken

Regards

 =

Keith<=
/o:p>

 =

From:=
 ken
carlberg [mailto:carlberg@g11.org.uk]&n=
bsp;

Sent: 19 April 2011 13:39

To: DRAGE, Keith (Keith)

Cc: Janet Gunn; sip-overload@ietf.org

Subject: Re: [sip-overload]
draft-ietf-soc-overload-design-05

If your comment is about the original text, then we are in some mea=
sure
of agreement.  If you agree with a position that its incorrect to poin=
t
out the characteristics for currently defined Namespaces as stated in rfc44=
12,
then we are in disagreement.

-ken

On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:

Janet’s statements about RPH ali=
gn with
the way I understand RPH works.

 =

Keith<=
/o:p>

 =

From:=
 sip-overload-bounces@ietf.org=
 [mailto:sip-overload-bounces@iet=
f.org] On
Behalf Of Janet =
P Gunn

Sent: 18 April 2011 19:21

To: ken carlberg

Cc: sip-overload-bounces@ietf.org=
; sip-overload@ietf.org

Subject: Re: [sip-overload]
draft-ietf-soc-overload-design-05

Ken, <=
br>

First
of all, that text is included in quite a few of the soc documents, so if yo=
u
change it in the design doc, it will need to be changed in the others too.<=
/span> 

More
importantly, I STRONGLY disagree with the statement that  " The
action taken is determined by the characteristics defined for the set of
priority values of a Namespace (e.g., preemption versus queuing) ". 

 Neither
"preemption" nor "queuing" are appropriate responses to=
 a
request for load shedding.  Either the request is shed, or it is not.
 AFAIK, there is no intention to "preempt" another request, =
nor
to change in the order in which the messages respond to load shedding.. &nb=
sp; 

In
particular, in systems already deployed, SIP messages using the ets/wps fam=
ily
of namespaces (which are defined as "queuing based" , and do queu=
e
for MEDIA resources) receive exemption from SIP server  overload based
shedding.  They do NOT have any special queuing based behavior  f=
or
SIP server resources.  Not do they preempt other SIP requests.<=
/font> 

Furthermore,
the behavior associated with a particular namespace is highly dependant on =
the
particular network.  dsn.flash-override is not going to elicit any
priority behavior in a civilian or public network.  It will certainly =
not
 preempt anything.  Conversely, ets.0, wps.0  is not going t=
o
elicit any priority behavior in the DSN network 

The
statement "An example local policy may even include exemptions from
network management control." introduces a new term - " network
management control" which would need to be defined.  I presume th=
at
what you really mean in this context is "exemption from load
shedding".  This is already covered in i) of the existing text. 

I fail
to see the reason for your proposed statement "However, for the sake o=
f
simplicity, a default position should be the use of the first RPH entry to
  determine the priority of the SIP request. "  AFAIK, the o=
rder
of the headers is not generally relevant to SIP, and I do not see any
particular need to introduce it here.   Furthermore, a given SIP agent
only "understands" certain namespaces.  It seems highly
 counterproductive to suggest that a SIP server, by default, should
"use" a namespace it doesn't understand (just because it is
"first") , and ignore the one(s) it does understand (just because=
 not
"first"). =

Even
if you change the statement to read "the first RPH entry it
understands", you would need a "default behavior" to go with=
 the
"default namespace." 

As far
as I am concerned, if a particular SIP server does NOT have a local policy =
for
RPH (both which namespaces are relevant/understood, and the appropriate
behavior for each namespace or combination of namespaces), then it should
simply ignore the RPH namespaces.  This seems consistent with generic =
SIP
behavior with regard to namespaces in general. 

I fail
to see the significance of the statement about B2BUAs.  ALL SIP server=
s,
(not just B2BUAs) can and will insert, delete, or change the RPH. 

 I
also fail to see the need to refer explicitly to Namespaces not defined in
RFC4412.  There are already a large number of IETF registered RPH
namespaces which do not appear in RFC4412 (see RFC 5478 for example) and ot=
hers
have been proposed (for instance
draft-ietf-ecrit-local-emergency-rph-namespace).  If you are suggestin=
g
that specific networks may be using purely "private" RPH namespac=
es
that have never been subject to IETF review, that may well be true in pract=
ice,
but I don't think it should be introduced into IETF documents- especially o=
nes
that are not primarily about RPH. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please de=
lete
without copying and kindly advise us by e-mail of the mistake in delivery.<=
span
class=3Dapple-converted-space> 

NOTE: Regardless of content, this e-mail shall not operate to bind CSC to a=
ny
order or other contract unless pursuant to explicit written agreement or
government initiative expressly permitting the use of e-mail for such purpo=
se. 

  From:

  ken carlberg <carlberg@g11.org.uk>

  To:

  =
sip-overload@ietf.org

  Date:

  04/17/2011 03:38 PM

  Subject:=

  [sip-overload]
  draft-ietf-soc-overload-design-05

Hello, 

in following up on the discussion point I brought up at the Prague-IETF mee=
ting
concerning RPH related text, I've added some suggested text to section 12 o=
f draft-ietf-soc-overload-design-05.  The sug=
gested
text is bound by the following tags: 

<insert text><=
/font> 

</insert text> 

The purpose of the new text=
 is to
present a more complete picture and point out aspects that others following
this effort should be aware of.  I've kept the rest of the original te=
xt
for that section as is (ie, I did not remove any original text).  I've
also sent the suggested text to Martin and James for a sanity check before
posting to the list. =
;

cheers, 

-ken 

 12.  Message Prioritization

  Overload control can require a SIP server to prioritize requests and=

  select requests to be rejected or redirected.  The selection is=

   largely a matter of local policy of the SIP server, the overal=
l

  network, and the services it provides.  As a general rule, SIP
server

  should prioritize requests for ongoing dialogs over requests that se=
t

  up a new dialog.  Targeting requests for ongoing dialogs may
prevent

  users from modifying or terminating an ongoing dialog.

  While there are many factors which can affect the prioritization of<=
br>
  SIP requests, the Resource-Priority header field [RFC4412] is a prim=
e

  candidate for marking the prioritization of SIP requests.
 Depending

  on the particular network and the services it offers, a particular
  namespace and priority value in the RPH it could indicate i) a high<=
br>
  priority request, which should be preserved if possible during

  overload, ii) a low priority request, which should be dropped during=

  overload, or iii) a label, which has no impact on message

  prioritization in this network.&=
nbsp; <insert text> The action taken i=
s 

   determined by the characteristics defined for the set of prior=
ity
values 

   of a Namespace (e.g., preemption versus queuing) as well as th=
e 

   local policies defined for the various Namespaces supported by=
 the 

   server.  An example local policy may even include exempti=
ons
from 

   network management control. 

  We note that [RFC4412] allows the presence of multiple RPH entries

   per SIP request.  Local policy would determine which
Namespace and 

   Priority tuple are used to prioritize requests.  However,=
 for
the sake of 

   simplicity, a default position should be the use of the first =
RPH
entry to 

   determine the priority of the SIP request. 

  Another scenario that should be considered is the presence of Back 

   to Back User Agents (B2BUA) that may strip out the RPH from th=
e 

   upstream SIP request.  Operators or Administrators may ch=
oose
to 

   insert their own RPH to support downstream prioritization of t=
he
SIP 

   request.  This RPH inserted by the B2BUA may conform to a=

   Namespace set defined in [RPH4412], or it may reflect a new 

   Namespace set. 

   </ins=
ert
text>

  For a number of reasons, responses should not be targeted in order t=
o

  reduce SIP server load.  Responses cannot be rejected and would
have

  to be dropped.  This triggers the retransmission of the request
plus

  the response, leading to even more load.  In addition, the requ=
est

  associated with a response has already been processed and dropping
  the response will waste the efforts that have been spent on the

  request.  Most importantly, rejecting a request effectively als=
o

  removes the request and the response.  If no requests are passe=
d

  along there will be no responses coming back in return.

  Overload control does not change the retransmission behavior of SIP.=

  Retransmissions are triggered using procedures defined in RFC 3261
  [RFC3261] and not subject to throttling. 

__=
_____________________________________________

sip-overload mailing list

sip=
-overload@ietf.org

https://www.=
ietf.org/mailman/listinfo/sip-overload

--_000_EDC0A1AE77C57744B664A310A0B23AE21EC517ECFRMRSSXCHMBSC3d_--

From carlberg@g11.org.uk  Tue Apr 19 07:30:57 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F24D6E0756 for ; Tue, 19 Apr 2011 07:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWa79e4qllX4 for ; Tue, 19 Apr 2011 07:30:54 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfc.amsl.com (Postfix) with ESMTP id E5E97E0754 for ; Tue, 19 Apr 2011 07:30:52 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=OZI0hiRZA0x46gI9KEPkOEFnHWSWNAgOwNE/1b4GuuEynUzFISV7nsUWcSulGyi9/FePmXnXhX6fyGMmMh8saZluyIdSOHnOUIabTNE6KH3kWPIYThPGByrJ/IQxJeFe;
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:63971 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1QCBwv-0007Ag-KE; Tue, 19 Apr 2011 14:30:42 +0000
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-76-646216471
From: ken carlberg 
In-Reply-To: 
Date: Tue, 19 Apr 2011 10:30:47 -0400
Message-Id: <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>   <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>  <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk> 
To: "DRAGE, Keith (Keith)" 
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: "sip-overload@ietf.org" 
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 14:30:57 -0000

--Apple-Mail-76-646216471
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Apr 19, 2011, at 9:43 AM, DRAGE, Keith (Keith) wrote:

> With regard to your comment on 1), I believe nothing extra is =
required. Anyone setting up multiple namespaces has to define at each =
entity that is required to understand them how they are treated in =
relationship to each other. That is part of the implementation. That =
will define which namespaces exist, and which are used at the receiving =
entity to give any form of priority handling. There is no reason for SIP =
overload to alter that relationship in any way, shape, or form.

this is somewhat scenario dependent.  but I don't think we are gaining =
any traction, so I'll stop here.

> On 2), I do not believe your comment is correct. The fact that a =
namespace is a pre-emption namespace is not an invitation to pre-empt =
all other calls until you get your call through, even under situations =
of no overload. It merely states that calls can be pre-empted when this =
namespace is used. The same applies for priority. Usually the algorithm =
for handling these DOES NOT SAY =96 handle all calls with this namespace =
until there are none left, and then move onto others. It deals with =
things like percentage of traffic and so on. So what I am saying is that =
the RPH is not a guarantee to override all other traffic, whether =
overload exists or not.

the preemption-capable systems I've worked on in the past *must* preempt =
or tear down state when there are no available resources -- either =
established calls (or flows) or call/session establishment.  I guess =
there are various scenarios and variations of implementations that one =
can consider, but I think that continues down an endless series of =
possibilities that never lead to a definitive answer.

I think the subject has been beaten to a pulp.  And to a large degree, =
we have gone much further into topics than perhaps was necessary.  The =
purpose of the suggested new next was to broaden the picture and bring =
up topics that are attributed to the RPH.  The only position that was =
taken in the text was to suggest in the form of a "should" the use of =
the first RPH (which I meant to be the first "recognized/supported" =
RPH).  But I conceded that i was fine to remove that position.

I'll stop here and leave it to the co-authors/co-chairs to decide how to =
proceed.

-ken

> Regards
> =20
> Keith
> =20
> From: ken carlberg [mailto:carlberg@g11.org.uk]=20
> Sent: 19 April 2011 14:23
> To: DRAGE, Keith (Keith)
> Cc: Janet Gunn; sip-overload@ietf.org
> Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
> =20
> =20
> On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:
>=20
>=20
> My confirmation was on what Janet wrote, rather than the original =
text.
> =20
> Two comments.
> =20
> 1)         Any statement about some specific RPH being taken as a =
default are inappropriate. If you are using RPH you must handle them in =
the way you already know. If you do not know about an RPH value, then =
you have to ignore it (and possibly delete it in the outgoing INVITE =
depending on your policy). There are certainly use cases where multiple =
RPH values can exist, covering different aspects of priority on the same =
request. It may be the second one that is received that defines the =
priority in regard to the handling in the SIP server itself (as opposed =
to priority of giving a media stream or whatever).
> =20
> or it may be the first, or the last.  I'll concede the difficulty in =
stating the first "recognized/supported" RPH is the one to be used.  But =
I think one is deferring the problem that arises with no position taken =
at all.  The primary point that I wanted to make was that the =
possibility of multiple RPHs may exist.  I'm fine with removing the text =
of choosing a default RPH in that instance.
>=20
>=20
> 2)         In a case of load shedding, I suspect that the discussion =
on whether either priority or pre-emption are relevant depend on whether =
you are using them to represent the request to the original target =
server that indicated overload, or to some other server. I believe that =
in the case of representing to the original targetted server it is =
inappropriate. It is making the assumption that some of the existing =
traffic directed from this server to that server is somehow responsible =
for the overload, and that is an entirely invalid assumption.
> =20
> again, the intent of the suggested added text was to point out to the =
reader that preemption and queuing are *examples* of what has been =
defined so far with respect to Namespaces.  What you have stated above =
makes a case that another Namespace should be defined, otherwise, you =
one is overloading new characteristics from what has already been =
defined. =20
> =20
> -ken
> =20
>=20
>=20
> Regards
> =20
> Keith
> =20
> From: ken carlberg [mailto:carlberg@g11.org.uk]=20
> Sent: 19 April 2011 13:39
> To: DRAGE, Keith (Keith)
> Cc: Janet Gunn; sip-overload@ietf.org
> Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
> =20
> If your comment is about the original text, then we are in some =
measure of agreement.  If you agree with a position that its incorrect =
to point out the characteristics for currently defined Namespaces as =
stated in rfc4412, then we are in disagreement.
> =20
> -ken
> =20
> =20
> =20
> On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:
>=20
>=20
>=20
> Janet=92s statements about RPH align with the way I understand RPH =
works.
> =20
> Keith
> =20
> From: sip-overload-bounces@ietf.org =
[mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
> Sent: 18 April 2011 19:21
> To: ken carlberg
> Cc: sip-overload-bounces@ietf.org; sip-overload@ietf.org
> Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
> =20
>=20
> Ken,=20
>=20
> First of all, that text is included in quite a few of the soc =
documents, so if you change it in the design doc, it will need to be =
changed in the others too.=20
>=20
> More importantly, I STRONGLY disagree with the statement that  " The =
action taken is determined by the characteristics defined for the set of =
priority values of a Namespace (e.g., preemption versus queuing) ".=20
>=20
>  Neither "preemption" nor "queuing" are appropriate responses to a =
request for load shedding.  Either the request is shed, or it is not.  =
AFAIK, there is no intention to "preempt" another request, nor to change =
in the order in which the messages respond to load shedding..  =20
>=20
> In particular, in systems already deployed, SIP messages using the =
ets/wps family of namespaces (which are defined as "queuing based" , and =
do queue for MEDIA resources) receive exemption from SIP server  =
overload based shedding.  They do NOT have any special queuing based =
behavior  for SIP server resources.  Not do they preempt other SIP =
requests.=20
>=20
> Furthermore, the behavior associated with a particular namespace is =
highly dependant on the particular network.  dsn.flash-override is not =
going to elicit any priority behavior in a civilian or public network.  =
It will certainly not  preempt anything.  Conversely, ets.0, wps.0  is =
not going to elicit any priority behavior in the DSN network=20
>=20
> The statement "An example local policy may even include exemptions =
from network management control." introduces a new term - " network =
management control" which would need to be defined.  I presume that what =
you really mean in this context is "exemption from load shedding".  This =
is already covered in i) of the existing text.=20
>=20
> I fail to see the reason for your proposed statement "However, for the =
sake of simplicity, a default position should be the use of the first =
RPH entry to   determine the priority of the SIP request. "  AFAIK, the =
order of the headers is not generally relevant to SIP, and I do not see =
any particular need to introduce it here.   Furthermore, a given SIP =
agent only "understands" certain namespaces.  It seems highly  =
counterproductive to suggest that a SIP server, by default, should "use" =
a namespace it doesn't understand (just because it is "first") , and =
ignore the one(s) it does understand (just because not "first").=20
>=20
> Even if you change the statement to read "the first RPH entry it =
understands", you would need a "default behavior" to go with the =
"default namespace."=20
>=20
> As far as I am concerned, if a particular SIP server does NOT have a =
local policy for RPH (both which namespaces are relevant/understood, and =
the appropriate behavior for each namespace or combination of =
namespaces), then it should simply ignore the RPH namespaces.  This =
seems consistent with generic SIP behavior with regard to namespaces in =
general.=20
>=20
> I fail to see the significance of the statement about B2BUAs.  ALL SIP =
servers, (not just B2BUAs) can and will insert, delete, or change the =
RPH.=20
>=20
>  I also fail to see the need to refer explicitly to Namespaces not =
defined in RFC4412.  There are already a large number of IETF registered =
RPH namespaces which do not appear in RFC4412 (see RFC 5478 for example) =
and others have been proposed (for instance =
draft-ietf-ecrit-local-emergency-rph-namespace).  If you are suggesting =
that specific networks may be using purely "private" RPH namespaces that =
have never been subject to IETF review, that may well be true in =
practice, but I don't think it should be introduced into IETF documents- =
especially ones that are not primarily about RPH.=20
>=20
> Janet
>=20
> 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.=20
> 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.=20
>=20
>=20
>=20
>=20
> From:
> ken carlberg 
> To:
> sip-overload@ietf.org
> Date:
> 04/17/2011 03:38 PM
> Subject:
> [sip-overload] draft-ietf-soc-overload-design-05
> =20
>=20
>=20
>=20
> Hello,=20
>=20
> in following up on the discussion point I brought up at the =
Prague-IETF meeting concerning RPH related text, I've added some =
suggested text to section 12 of draft-ietf-soc-overload-design-05.  The =
suggested text is bound by the following tags:=20
> =20
> =20
>=20
> The purpose of the new text is to present a more complete picture and =
point out aspects that others following this effort should be aware of.  =
I've kept the rest of the original text for that section as is (ie, I =
did not remove any original text).  I've also sent the suggested text to =
Martin and James for a sanity check before posting to the list.=20
>=20
> cheers,=20
>=20
> -ken=20
>=20
>=20
>  12.  Message Prioritization
>=20
>   Overload control can require a SIP server to prioritize requests and
>   select requests to be rejected or redirected.  The selection is=20
>    largely a matter of local policy of the SIP server, the overall
>   network, and the services it provides.  As a general rule, SIP =
server
>   should prioritize requests for ongoing dialogs over requests that =
set
>   up a new dialog.  Targeting requests for ongoing dialogs may prevent
>   users from modifying or terminating an ongoing dialog.
>=20
>   While there are many factors which can affect the prioritization of
>   SIP requests, the Resource-Priority header field [RFC4412] is a =
prime
>   candidate for marking the prioritization of SIP requests.  Depending
>   on the particular network and the services it offers, a particular
>   namespace and priority value in the RPH it could indicate i) a high
>   priority request, which should be preserved if possible during
>   overload, ii) a low priority request, which should be dropped during
>   overload, or iii) a label, which has no impact on message
>   prioritization in this network.   The action taken is=20=

>    determined by the characteristics defined for the set of priority =
values=20
>    of a Namespace (e.g., preemption versus queuing) as well as the=20
>    local policies defined for the various Namespaces supported by the=20=

>    server.  An example local policy may even include exemptions from=20=

>    network management control.=20
>  =20
>   We note that [RFC4412] allows the presence of multiple RPH entries  =20=

>    per SIP request.  Local policy would determine which Namespace and=20=

>    Priority tuple are used to prioritize requests.  However, for the =
sake of=20
>    simplicity, a default position should be the use of the first RPH =
entry to=20
>    determine the priority of the SIP request.=20
>=20
>   Another scenario that should be considered is the presence of Back=20=

>    to Back User Agents (B2BUA) that may strip out the RPH from the=20
>    upstream SIP request.  Operators or Administrators may choose to=20
>    insert their own RPH to support downstream prioritization of the =
SIP=20
>    request.  This RPH inserted by the B2BUA may conform to a=20
>    Namespace set defined in [RPH4412], or it may reflect a new=20
>    Namespace set.=20
>    
>=20
>   For a number of reasons, responses should not be targeted in order =
to
>   reduce SIP server load.  Responses cannot be rejected and would have
>   to be dropped.  This triggers the retransmission of the request plus
>   the response, leading to even more load.  In addition, the request
>   associated with a response has already been processed and dropping
>   the response will waste the efforts that have been spent on the
>   request.  Most importantly, rejecting a request effectively also
>   removes the request and the response.  If no requests are passed
>   along there will be no responses coming back in return.
>=20
>   Overload control does not change the retransmission behavior of SIP.
>   Retransmissions are triggered using procedures defined in RFC 3261
>   [RFC3261] and not subject to throttling.=20
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>=20
>=20
>=20
>=20
> =20
> =20

--Apple-Mail-76-646216471
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

On Apr 19, 2011, at 9:43 AM, DRAGE, =
Keith (Keith) wrote:

With regard =
to your comment on 1), I believe nothing extra is required. Anyone =
setting up multiple namespaces has to define at each entity that is =
required to understand them how they are treated in relationship to each =
other. That is part of the implementation. That will define which =
namespaces exist, and which are used at the receiving entity to give any =
form of priority handling. There is no reason for SIP overload to alter =
that relationship in any way, shape, or =
form.

this is somewhat scenario dependent.  but I don't think we are =
gaining any traction, so I'll stop here.

On 2), I do =
not believe your comment is correct. The fact that a namespace is a =
pre-emption namespace is not an invitation to pre-empt all other calls =
until you get your call through, even under situations of no overload. =
It merely states that calls can be pre-empted when this namespace is =
used. The same applies for priority. Usually the algorithm for handling =
these DOES NOT SAY =96 handle all calls with this namespace until there =
are none left, and then move onto others. It deals with things like =
percentage of traffic and so on. So what I am saying is that the RPH is =
not a guarantee to override all other traffic, whether overload exists =
or =
not.

the preemption-capable systems I've worked on in the past *must* =
preempt or tear down state when there are no available resources -- =
either established calls (or flows) or call/session establishment. =
 I guess there are various scenarios and variations of =
implementations that one can consider, but I think that continues down =
an endless series of possibilities that never lead to a definitive =
answer.

I think the subject has been beaten to =
a pulp.  And to a large degree, we have gone much further into =
topics than perhaps was necessary.  The purpose of the suggested =
new next was to broaden the picture and bring up topics that are =
attributed to the RPH.  The only position that was taken in the =
text was to suggest in the form of a "should" the use of the first RPH =
(which I meant to be the first "recognized/supported" RPH).  But I =
conceded that i was fine to remove that =
position.

I'll stop here and leave it to the =
co-authors/co-chairs to decide how to =
proceed.

-ken

=

 ken carlberg =
[mailto:carlberg@g11.org.uk] 
Sent: 19 April 2011 =
14:23
To: DRAGE, Keith =
(Keith)
Cc: Janet Gunn; sip-overload@ietf.org
Subject: Re: [sip-overload] =
draft-ietf-soc-overload-design-05
On Apr 19, =
2011, at 9:03 AM, DRAGE, Keith (Keith) =
wrote:
My =
confirmation was on what Janet wrote, rather than the original =
text.
Two =
comments.

or it may be the first, or the last.  I'll concede the =
difficulty in stating the first "recognized/supported" RPH is the one to =
be used.  But I think one is deferring the problem that arises with =
no position taken at all.  The primary point that I wanted to make =
was that the possibility of multiple RPHs may exist.  I'm fine with =
removing the text of choosing a default RPH in that =
instance.

again, the intent of the suggested added text was to point out =
to the reader that preemption and queuing are *examples* of what has =
been defined so far with respect to Namespaces.  What you have =
stated above makes a case that another Namespace should be defined, =
otherwise, you one is overloading new characteristics from what has =
already been defined. =

-ken 

 ken carlberg [mailto:carlberg@g11.org.uk] 
Sent: 19 April 2011 =
13:39
To: DRAGE, Keith =
(Keith)
Cc: Janet Gunn; sip-overload@ietf.org
Subject: Re: [sip-overload] =
draft-ietf-soc-overload-design-05
If your comment is about the original text, then we are in some =
measure of agreement.  If you agree with a position that its =
incorrect to point out the characteristics for currently defined =
Namespaces as stated in rfc4412, then we are in =
disagreement.
<=
div style=3D"margin-top: 0cm; margin-right: 0cm; margin-bottom: =
0.0001pt; margin-left: 0cm; font-size: 12pt; font-family: 'Times New =
Roman'; ">On Apr 19, 2011, at 6:04 AM, DRAGE, Keith =
(Keith) =
wrote:
Janet=92s statements about RPH align with the way I =
understand RPH =
works.
From:sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@=
ietf.org] On Behalf Of Janet P =
Gunn
Sent: 18 April 2011 =
19:21
To: ken carlberg
Cc: sip-overload-bounces@ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] =
draft-ietf-soc-overload-design-05

 Neither "preemption" nor "queuing" are appropriate =
responses to a request for load shedding.  Either the request is =
shed, or it is not.  AFAIK, there is no intention to "preempt" =
another request, nor to change in the order in which the messages =
respond to load shedding..   

In =
particular, in systems already deployed, SIP messages using the ets/wps =
family of namespaces (which are defined as "queuing based" , and do =
queue for MEDIA resources) receive exemption from SIP server =
 overload based shedding.  They do NOT have any special =
queuing based behavior  for SIP server resources.  Not do they =
preempt other SIP requests. 

The =
statement "An example local policy may even include exemptions from =
network management control." introduces a new term - " network =
management control" which would need to be defined.  I presume that =
what you really mean in this context is "exemption from load shedding". =
 This is already covered in i) of the existing =
text. 

I =
fail to see the reason for your proposed statement "However, for the =
sake of simplicity, a default position should be the use of the first =
RPH entry to   determine the priority of the SIP request. " =
 AFAIK, the order of the headers is not generally relevant to SIP, =
and I do not see any particular need to introduce it here.   =
Furthermore, a given SIP agent only "understands" certain namespaces. =
 It seems highly  counterproductive to suggest that a SIP =
server, by default, should "use" a namespace it doesn't understand (just =
because it is "first") , and ignore the one(s) it does understand (just =
because not "first"). 

As =
far as I am concerned, if a particular SIP server does NOT have a local =
policy for RPH (both which namespaces are relevant/understood, and the =
appropriate behavior for each namespace or combination of namespaces), =
then it should simply ignore the RPH namespaces.  This seems =
consistent with generic SIP behavior with regard to namespaces in =
general. 

I =
fail to see the significance of the statement about B2BUAs.  ALL =
SIP servers, (not just B2BUAs) can and will insert, delete, or change =
the RPH. 

 I also fail to see the need to refer explicitly to =
Namespaces not defined in RFC4412.  There are already a large =
number of IETF registered RPH namespaces which do not appear in RFC4412 =
(see RFC 5478 for example) and others have been proposed (for instance =
draft-ietf-ecrit-local-emergency-rph-namespace).  If you are =
suggesting that specific networks may be using purely "private" RPH =
namespaces that have never been subject to IETF review, that may well be =
true in practice, but I don't think it should be introduced into IETF =
documents- especially ones that are not primarily about =
RPH. 

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. 

[sip-overload] =
draft-ietf-soc-overload-design-05
ken carlberg <04/17/2011 03:38 =
PM

Hello, 

in following up on =
the discussion point I brought up at the Prague-IETF meeting concerning =
RPH related text, I've added some suggested text to section 12 of  
<insert text> 
</insert text> 

The purpose of the new text =
is to present a more complete picture and point out aspects that others =
following this effort should be aware of.  I've kept the rest of =
the original text for that section as is (ie, I did not remove any =
original text).  I've also sent the suggested text to Martin and =
James for a sanity check before posting to the list. 

cheers, 

-ken 

 12. =
 Message Prioritization

  Overload control can require =
a SIP server to prioritize requests and
  select requests to be =
rejected or redirected.  The selection is 
   largely a =
matter of local policy of the SIP server, the overall
  network, =
and the services it provides.  As a general rule, SIP =
server
  should prioritize requests for ongoing dialogs over =
requests that set
  up a new dialog.  Targeting requests =
for ongoing dialogs may prevent
  users from modifying or =
terminating an ongoing dialog.

  While there are many =
factors which can affect the prioritization of
  SIP requests, =
the Resource-Priority header field [RFC4412] is a prime
  =
candidate for marking the prioritization of SIP requests. =
 Depending
  on the particular network and the services it =
offers, a particular
  namespace and priority value in the RPH =
it could indicate i) a high
  priority request, which should be =
preserved if possible during
  overload, ii) a low priority =
request, which should be dropped during
  overload, or iii) a =
label, which has no impact on message
  prioritization in this =
network.  The action =
taken is 
  =
 determined by the characteristics defined for the set of priority =
values 
  =
 of a Namespace (e.g., preemption versus queuing) as well as =
the 
  =
 local policies defined for the various Namespaces supported by =
the 
  =
 server.  An example local policy may even include exemptions =
from 
  =
 network management control. 

  We note that =
[RFC4412] allows the presence of multiple RPH entries   
   per SIP =
request.  Local policy would determine which Namespace and 
   Priority =
tuple are used to prioritize requests.  However, for the sake =
of 
  =
 simplicity, a default position should be the use of the first RPH =
entry to 
  =
 determine the priority of the SIP request. 

  Another =
scenario that should be considered is the presence of Back 
   to Back =
User Agents (B2BUA) that may strip out the RPH from the 
   upstream =
SIP request.  Operators or Administrators may choose to 
   insert =
their own RPH to support downstream prioritization of the SIP 
   request. =
 This RPH inserted by the B2BUA may conform to a 
   Namespace =
set defined in [RPH4412], or it may reflect a new 
   Namespace =
set. 
  =

sip-overload mailing =
list

Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
MIME-Version: 1.0
To: sip-overload@ietf.org
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>			<69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>		<578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>	 <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk>
In-Reply-To: <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 14:59:56 -0000

On 04/19/2011 09:30 AM, ken carlberg wrote:
> I think the subject has been beaten to a pulp. And to a large degree, we
> have gone much further into topics than perhaps was necessary. The
> purpose of the suggested new next was to broaden the picture and bring
> up topics that are attributed to the RPH. The only position that was
> taken in the text was to suggest in the form of a "should" the use of
> the first RPH (which I meant to be the first "recognized/supported"
> RPH). But I conceded that i was fine to remove that position.
[...]

As the editor of draft-ietf-sip-overload-control, I have read this
thread with interest.

So, the question now is: what, if any, from this thread carries over
into the draft-ietf-sip-overload-control draft?  I am certainly not
up to verse with RPH as some of the members of this working group
are, so I will depend on them to point out any text that should be
modified in draft-ietf-sip-overload-control.

For the sake of completeness, here is what
draft-ietf-sip-overload-control has to say about prioritizing
requests containing the RPH header:

    A SIP client SHOULD honor the local policy for prioritizing SIP
    requests such as policies based on the content of the Resource-
    Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value)
    RPH contents may indicate high priority requests that should be
    preserved as much as possible during overload.  The RPH contents can
    also indicate a low-priority request that is eligible to be dropped
    during times of overload.  Other indicators, such as the SOS URN
    [RFC5031] indicating an emergency request, may also be used for
    prioritization.

Do we deem this to be enough?

Thanks,

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

From jgunn6@csc.com  Tue Apr 19 08:26:11 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3786CE0758; Tue, 19 Apr 2011 08:26:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NKE5ZaDI493; Tue, 19 Apr 2011 08:26:10 -0700 (PDT)
Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by ietfc.amsl.com (Postfix) with ESMTP id BA13FE0756; Tue, 19 Apr 2011 08:26:09 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-8.tower-64.messagelabs.com!1303226667!119622003!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 2243 invoked from network); 19 Apr 2011 15:24:31 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-8.tower-64.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Apr 2011 15:24:31 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p3JFORC5000540; Tue, 19 Apr 2011 11:24:27 -0400
In-Reply-To: <4DADA3E8.6080409@bell-labs.com>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>	  <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>	 <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>	 <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk> <4DADA3E8.6080409@bell-labs.com>
To: "Vijay K. Gurbani" 
MIME-Version: 1.0
X-KeepSent: 90D7BCEF:193A9527-85257877:0054915A; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1  CCH2 April 23, 2009
From: Janet P Gunn 
Message-ID: 
Date: Tue, 19 Apr 2011 11:24:24 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 04/19/2011 11:23:18 AM, Serialize complete at 04/19/2011 11:23:18 AM
Content-Type: multipart/alternative; boundary="=_alternative 0054A2F785257877_="
Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 15:26:11 -0000

This is a multipart message in MIME format.
--=_alternative 0054A2F785257877_=
Content-Type: text/plain; charset="US-ASCII"

Vijay,

What is there now is fine with me. I see no need for change.

Janet

sip-overload-bounces@ietf.org wrote on 04/19/2011 11:02:00 AM:

> [image removed] 
> 
> Re: [sip-overload] draft-ietf-soc-overload-design-05
> 
> Vijay K. Gurbani 
> 
> to:
> 
> sip-overload
> 
> 04/19/2011 11:00 AM
> 
> Sent by:
> 
> sip-overload-bounces@ietf.org
> 
> On 04/19/2011 09:30 AM, ken carlberg wrote:
> > I think the subject has been beaten to a pulp. And to a large degree, 
we
> > have gone much further into topics than perhaps was necessary. The
> > purpose of the suggested new next was to broaden the picture and bring
> > up topics that are attributed to the RPH. The only position that was
> > taken in the text was to suggest in the form of a "should" the use of
> > the first RPH (which I meant to be the first "recognized/supported"
> > RPH). But I conceded that i was fine to remove that position.
> [...]
> 
> As the editor of draft-ietf-sip-overload-control, I have read this
> thread with interest.
> 
> So, the question now is: what, if any, from this thread carries over
> into the draft-ietf-sip-overload-control draft?  I am certainly not
> up to verse with RPH as some of the members of this working group
> are, so I will depend on them to point out any text that should be
> modified in draft-ietf-sip-overload-control.
> 
> For the sake of completeness, here is what
> draft-ietf-sip-overload-control has to say about prioritizing
> requests containing the RPH header:
> 
>     A SIP client SHOULD honor the local policy for prioritizing SIP
>     requests such as policies based on the content of the Resource-
>     Priority header (RPH, RFC4412 [RFC4412]).  Specific 
(namespace.value)
>     RPH contents may indicate high priority requests that should be
>     preserved as much as possible during overload.  The RPH contents can
>     also indicate a low-priority request that is eligible to be dropped
>     during times of overload.  Other indicators, such as the SOS URN
>     [RFC5031] indicating an emergency request, may also be used for
>     prioritization.
> 
> Do we deem this to be enough?
> 
> Thanks,
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

--=_alternative 0054A2F785257877_=
Content-Type: text/html; charset="US-ASCII"

Vijay,

What is there now is fine with me. I see no need for change.

Janet

sip-overload-bounces@ietf.org wrote on 04/19/2011
11:02:00 AM:

> [image removed] 

> 

> Re: [sip-overload] draft-ietf-soc-overload-design-05

> 

> Vijay K. Gurbani 

> 

> to:

> 

> sip-overload

> 

> 04/19/2011 11:00 AM

> 

> Sent by:

> 

> sip-overload-bounces@ietf.org

> 

> On 04/19/2011 09:30 AM, ken carlberg wrote:

> > I think the subject has been beaten to a pulp. And to a large
degree, we

> > have gone much further into topics than perhaps was necessary.
The

> > purpose of the suggested new next was to broaden the picture
and bring

> > up topics that are attributed to the RPH. The only position that
was

> > taken in the text was to suggest in the form of a "should"
the use of

> > the first RPH (which I meant to be the first "recognized/supported"

> > RPH). But I conceded that i was fine to remove that position.

> [...]

> 

> As the editor of draft-ietf-sip-overload-control, I have read this

> thread with interest.

> 

> So, the question now is: what, if any, from this thread carries over

> into the draft-ietf-sip-overload-control draft?  I am certainly
not

> up to verse with RPH as some of the members of this working group

> are, so I will depend on them to point out any text that should be

> modified in draft-ietf-sip-overload-control.

> 

> For the sake of completeness, here is what

> draft-ietf-sip-overload-control has to say about prioritizing

> requests containing the RPH header:

> 

>     A SIP client SHOULD honor the local policy for prioritizing
SIP

>     requests such as policies based on the content of the
Resource-

>     Priority header (RPH, RFC4412 [RFC4412]).  Specific
(namespace.value)

>     RPH contents may indicate high priority requests that
should be

>     preserved as much as possible during overload.  The
RPH contents can

>     also indicate a low-priority request that is eligible
to be dropped

>     during times of overload.  Other indicators, such
as the SOS URN

>     [RFC5031] indicating an emergency request, may also
be used for

>     prioritization.

> 

> Do we deem this to be enough?

> 

> Thanks,

> 

> - vijay

> -- 

> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent

> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com

> Web:   http://ect.bell-labs.com/who/vkg/

> _______________________________________________

> sip-overload mailing list

> sip-overload@ietf.org

> https://www.ietf.org/mailman/listinfo/sip-overload

--=_alternative 0054A2F785257877_=--

From jmpolk@cisco.com  Tue Apr 19 09:32:28 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3C1FE07D7 for ; Tue, 19 Apr 2011 09:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.399
X-Spam-Level: 
X-Spam-Status: No, score=-111.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYPNko7vPZpm for ; Tue, 19 Apr 2011 09:32:27 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id A632AE07C0 for ; Tue, 19 Apr 2011 09:32:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=14779; q=dns/txt; s=iport; t=1303230746; x=1304440346; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=QLvOBqRhR+Rx9SwMmCn2+Lxv6v5wDFZQBkHozuiFyy8=; b=MP74eWX5wx5mHZ5LGGFO0etIe0WOvp/wtfvgIHH5eoLK08rHCPnBdwVX cgyiHxfKpNBiKlxMidoiYpapSOFsL+oBZreWpeiCN2q65zt/bRBbNJjn2 2TvMkstLSj5sF005iQWKH1vuoughmBY9OERB9xzf2meqeBIakwJEbkPrC I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOa3rU2rRDoI/2dsb2JhbAClLHenfJxnhXEEhWc
X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="683955335"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 19 Apr 2011 16:32:25 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3JGWP9d021586; Tue, 19 Apr 2011 16:32:25 GMT
Message-Id: <201104191632.p3JGWP9d021586@mtv-core-3.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 19 Apr 2011 11:32:23 -0500
To: "DRAGE, Keith (Keith)" , ken carlberg 
From: "James M. Polk" 
In-Reply-To: 
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>   <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>  <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: "sip-overload@ietf.org" 
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 16:32:28 -0000

At 08:43 AM 4/19/2011, DRAGE, Keith (Keith) wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
>=20
>boundary=3D"_000_EDC0A1AE77C57744B664A310A0B23AE21EC517ECFRMRSSXCHMBSC3d_"
>
>With regard to your comment on 1), I believe=20
>nothing extra is required. Anyone setting up=20
>multiple namespaces has to define at each entity=20
>that is required to understand them how they are=20
>treated in relationship to each other. That is=20
>part of the implementation. That will define=20
>which namespaces exist, and which are used at=20
>the receiving entity to give any form of=20
>priority handling. There is no reason for SIP=20
>overload to alter that relationship in any way, shape, or form.
>
>On 2), I do not believe your comment is correct.=20
>The fact that a namespace is a pre-emption=20
>namespace is not an invitation to pre-empt all=20
>other calls until you get your call through,=20
>even under situations of no overload. It merely=20
>states that calls can be pre-empted when this=20
>namespace is used. The same applies for=20
>priority. Usually the algorithm for handling=20
>these DOES NOT SAY =96 handle all calls with this=20
>namespace until there are none left, and then=20
>move onto others. It deals with things like=20
>percentage of traffic and so on. So what I am=20
>saying is that the RPH is not a guarantee to override all other traffic,

it might not be, but within an RPH namespace that=20
is understood, there is the explicit ability=20
(based on whether it is configured to do so or=20
not) to have the priority-value determine which=20
SIP requests get processed moved ahead of (or=20
before) lower priority-value marked requests (or=20
those without an understandable (or no)=20
namespace). Janet called this thrashing - and=20
said it is bad. This is one of the purposes of=20
4412, in times of congestion, to elevate certain=20
marked requests above others in the processing=20
queue. Section 8 of 4412 has the guidance of=20
this. I'm not reading in this thread any=20
consideration of that function - which really=20
should be included (or explained why it isn't).

James

>whether overload exists or not.
>
>Regards
>
>Keith
>
>
>----------
>From: ken carlberg [mailto:carlberg@g11.org.uk]
>Sent: 19 April 2011 14:23
>To: DRAGE, Keith (Keith)
>Cc: Janet Gunn; sip-overload@ietf.org
>Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
>
>
>On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:
>
>
>My confirmation was on what Janet wrote, rather than the original text.
>
>Two comments.
>
>1)         Any statement about some specific RPH=20
>being taken as a default are inappropriate. If=20
>you are using RPH you must handle them in the=20
>way you already know. If you do not know about=20
>an RPH value, then you have to ignore it (and=20
>possibly delete it in the outgoing INVITE=20
>depending on your policy). There are certainly=20
>use cases where multiple RPH values can exist,=20
>covering different aspects of priority on the=20
>same request. It may be the second one that is=20
>received that defines the priority in regard to=20
>the handling in the SIP server itself (as=20
>opposed to priority of giving a media stream or whatever).
>
>or it may be the first, or the last.  I'll=20
>concede the difficulty in stating the first=20
>"recognized/supported" RPH is the one to be=20
>used.  But I think one is deferring the problem=20
>that arises with no position taken at all.  The=20
>primary point that I wanted to make was that the=20
>possibility of multiple RPHs may exist.  I'm=20
>fine with removing the text of choosing a default RPH in that instance.
>
>
>2)         In a case of load shedding, I suspect=20
>that the discussion on whether either priority=20
>or pre-emption are relevant depend on whether=20
>you are using them to represent the request to=20
>the original target server that indicated=20
>overload, or to some other server. I believe=20
>that in the case of representing to the original=20
>targetted server it is inappropriate. It is=20
>making the assumption that some of the existing=20
>traffic directed from this server to that server=20
>is somehow responsible for the overload, and=20
>that is an entirely invalid assumption.
>
>again, the intent of the suggested added text=20
>was to point out to the reader that preemption=20
>and queuing are *examples* of what has been=20
>defined so far with respect to Namespaces.  What=20
>you have stated above makes a case that another=20
>Namespace should be defined, otherwise, you one=20
>is overloading new characteristics from what has already been defined.
>
>-ken
>
>
>
>Regards
>
>Keith
>
>
>----------
>From: ken carlberg [mailto:carlberg@g11.org.uk]
>Sent: 19 April 2011 13:39
>To: DRAGE, Keith (Keith)
>Cc: Janet Gunn; sip-overload@ietf.org
>Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
>
>If your comment is about the original text, then=20
>we are in some measure of agreement.  If you=20
>agree with a position that its incorrect to=20
>point out the characteristics for currently=20
>defined Namespaces as stated in rfc4412, then we are in disagreement.
>
>-ken
>
>
>
>On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:
>
>
>
>Janet=92s statements about RPH align with the way I understand RPH works.
>
>Keith
>
>
>----------
>From:=20
>sip-overload-bounces@ietf.org=20
>[mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
>Sent: 18 April 2011 19:21
>To: ken carlberg
>Cc:=20
>sip-overload-bounces@ietf.org;=20
>sip-overload@ietf.org
>Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
>
>
>Ken,
>
>First of all, that text is included in quite a=20
>few of the soc documents, so if you change it in=20
>the design doc, it will need to be changed in the others too.
>
>More importantly, I STRONGLY disagree with the=20
>statement that  " The action taken is determined=20
>by the characteristics defined for the set of=20
>priority values of a Namespace (e.g., preemption versus queuing) ".
>
>  Neither "preemption" nor "queuing" are=20
> appropriate responses to a request for load=20
> shedding.  Either the request is shed, or it is=20
> not.  AFAIK, there is no intention to "preempt"=20
> another request, nor to change in the order in=20
> which the messages respond to load shedding..
>
>In particular, in systems already deployed, SIP=20
>messages using the ets/wps family of namespaces=20
>(which are defined as "queuing based" , and do=20
>queue for MEDIA resources) receive exemption=20
>from SIP server  overload based shedding.  They=20
>do NOT have any special queuing based=20
>behavior  for SIP server resources.  Not do they preempt other SIP=
 requests.
>
>Furthermore, the behavior associated with a=20
>particular namespace is highly dependant on the=20
>particular network.  dsn.flash-override is not=20
>going to elicit any priority behavior in a=20
>civilian or public network.  It will certainly=20
>not  preempt anything.  Conversely, ets.0,=20
>wps.0  is not going to elicit any priority behavior in the DSN network
>
>The statement "An example local policy may even=20
>include exemptions from network management=20
>control." introduces a new term - " network=20
>management control" which would need to be=20
>defined.  I presume that what you really mean in=20
>this context is "exemption from load=20
>shedding".  This is already covered in i) of the existing text.
>
>I fail to see the reason for your proposed=20
>statement "However, for the sake of simplicity,=20
>a default position should be the use of the=20
>first RPH entry to   determine the priority of=20
>the SIP request. "  AFAIK, the order of the=20
>headers is not generally relevant to SIP, and I=20
>do not see any particular need to introduce it=20
>here.   Furthermore, a given SIP agent only=20
>"understands" certain namespaces.  It seems=20
>highly  counterproductive to suggest that a SIP=20
>server, by default, should "use" a namespace it=20
>doesn't understand (just because it is "first")=20
>, and ignore the one(s) it does understand (just because not "first").
>
>Even if you change the statement to read "the=20
>first RPH entry it understands", you would need=20
>a "default behavior" to go with the "default namespace."
>
>As far as I am concerned, if a particular SIP=20
>server does NOT have a local policy for RPH=20
>(both which namespaces are relevant/understood,=20
>and the appropriate behavior for each namespace=20
>or combination of namespaces), then it should=20
>simply ignore the RPH namespaces.  This seems=20
>consistent with generic SIP behavior with regard to namespaces in general.
>
>I fail to see the significance of the statement=20
>about B2BUAs.  ALL SIP servers, (not just=20
>B2BUAs) can and will insert, delete, or change the RPH.
>
>  I also fail to see the need to refer=20
> explicitly to Namespaces not defined in=20
> RFC4412.  There are already a large number of=20
> IETF registered RPH namespaces which do not=20
> appear in RFC4412 (see RFC 5478 for example)=20
> and others have been proposed (for instance=20
> draft-ietf-ecrit-local-emergency-rph-namespace).=20
>    If you are suggesting that specific networks=20
> may be using purely "private" RPH namespaces=20
> that have never been subject to IETF review,=20
> that may well be true in practice, but I don't=20
> think it should be introduced into IETF=20
> documents- especially ones that are not primarily about RPH.
>
>Janet
>
>This is a PRIVATE message. If you are not the=20
>intended recipient, please delete without=20
>copying and kindly advise us by e-mail of the mistake in delivery.
>NOTE: Regardless of content, this e-mail shall=20
>not operate to bind CSC to any order or other=20
>contract unless pursuant to explicit written=20
>agreement or government initiative expressly=20
>permitting the use of e-mail for such purpose.
>
>
>
>From:
>ken carlberg <carlberg@g11.org.uk>
>To:
>sip-overload@ietf.org
>Date:
>04/17/2011 03:38 PM
>Subject:
>[sip-overload] draft-ietf-soc-overload-design-05
>
>
>
>
>
>Hello,
>
>in following up on the discussion point I=20
>brought up at the Prague-IETF meeting concerning=20
>RPH related text, I've added some suggested text=20
>to section 12 of=20
>draft-ietf-soc-overload-design-05.  The=20
>suggested text is bound by the following tags:
>
>
>
>The purpose of the new text is to present a more=20
>complete picture and point out aspects that=20
>others following this effort should be aware=20
>of.  I've kept the rest of the original text for=20
>that section as is (ie, I did not remove any=20
>original text).  I've also sent the suggested=20
>text to Martin and James for a sanity check before posting to the list.
>
>cheers,
>
>-ken
>
>
>  12.  Message Prioritization
>
>   Overload control can require a SIP server to prioritize requests and
>   select requests to be rejected or redirected.  The selection is
>    largely a matter of local policy of the SIP server, the overall
>   network, and the services it provides.  As a general rule, SIP server
>   should prioritize requests for ongoing dialogs over requests that set
>   up a new dialog.  Targeting requests for ongoing dialogs may prevent
>   users from modifying or terminating an ongoing dialog.
>
>   While there are many factors which can affect the prioritization of
>   SIP requests, the Resource-Priority header field [RFC4412] is a prime
>   candidate for marking the prioritization of SIP requests.  Depending
>   on the particular network and the services it offers, a particular
>   namespace and priority value in the RPH it could indicate i) a high
>   priority request, which should be preserved if possible during
>   overload, ii) a low priority request, which should be dropped during
>   overload, or iii) a label, which has no impact on message
>   prioritization in this network.   The action taken is
>    determined by the characteristics defined for the set of priority=
 values
>    of a Namespace (e.g., preemption versus queuing) as well as the
>    local policies defined for the various Namespaces supported by the
>    server.  An example local policy may even include exemptions from
>    network management control.
>
>   We note that [RFC4412] allows the presence of multiple RPH entries
>    per SIP request.  Local policy would determine which Namespace and
>    Priority tuple are used to prioritize requests.  However, for the sake=
 of
>    simplicity, a default position should be the=20
> use of the first RPH entry to
>    determine the priority of the SIP request.
>
>   Another scenario that should be considered is the presence of Back
>    to Back User Agents (B2BUA) that may strip out the RPH from the
>    upstream SIP request.  Operators or Administrators may choose to
>    insert their own RPH to support downstream prioritization of the SIP
>    request.  This RPH inserted by the B2BUA may conform to a
>    Namespace set defined in [RPH4412], or it may reflect a new
>    Namespace set.
>    
>
>   For a number of reasons, responses should not be targeted in order to
>   reduce SIP server load.  Responses cannot be rejected and would have
>   to be dropped.  This triggers the retransmission of the request plus
>   the response, leading to even more load.  In addition, the request
>   associated with a response has already been processed and dropping
>   the response will waste the efforts that have been spent on the
>   request.  Most importantly, rejecting a request effectively also
>   removes the request and the response.  If no requests are passed
>   along there will be no responses coming back in return.
>
>   Overload control does not change the retransmission behavior of SIP.
>   Retransmissions are triggered using procedures defined in RFC 3261
>   [RFC3261] and not subject to throttling.
>_______________________________________________
>sip-overload mailing list
>sip-overload@ietf.org
>https://www.ietf.org/mailman/listinfo/sip-overload
>
>
>
>
>
>_______________________________________________
>sip-overload mailing list
>sip-overload@ietf.org
>https://www.ietf.org/mailman/listinfo/sip-overload

From jgunn6@csc.com  Tue Apr 19 11:04:10 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C1700E0832; Tue, 19 Apr 2011 11:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WirWBff0GyfR; Tue, 19 Apr 2011 11:04:09 -0700 (PDT)
Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by ietfc.amsl.com (Postfix) with ESMTP id 7A196E0702; Tue, 19 Apr 2011 11:04:09 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-5.tower-87.messagelabs.com!1303236247!4442073!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 13522 invoked from network); 19 Apr 2011 18:04:08 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-5.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Apr 2011 18:04:08 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p3JI47cY026322; Tue, 19 Apr 2011 14:04:07 -0400
In-Reply-To: <201104191632.p3JGWP9d021586@mtv-core-3.cisco.com>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>	  <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>	 <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>	 <201104191632.p3JGWP9d021586@mtv-core-3.cisco.com>
To: "James M. Polk" 
MIME-Version: 1.0
X-KeepSent: 44845051:E121E247-85257877:00619C7C; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1  CCH2 April 23, 2009
From: Janet P Gunn 
Message-ID: 
Date: Tue, 19 Apr 2011 14:04:10 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 04/19/2011 02:02:58 PM, Serialize complete at 04/19/2011 02:02:58 PM
Content-Type: multipart/alternative; boundary="=_alternative 0063434585257877_="
Cc: sip-overload-bounces@ietf.org, "sip-overload@ietf.org" 
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 18:04:10 -0000

This is a multipart message in MIME format.
--=_alternative 0063434585257877_=
Content-Type: text/plain; charset="US-ASCII"

sip-overload-bounces@ietf.org wrote on 04/19/2011 12:32:23 PM:

> Re: [sip-overload] draft-ietf-soc-overload-design-05
> 
> James M. Polk 

> 
> it might not be, but within an RPH namespace that 
> is understood, there is the explicit ability 
> (based on whether it is configured to do so or 
> not) to have the priority-value determine which 
> SIP requests get processed moved ahead of (or 
> before) lower priority-value marked requests (or 
> those without an understandable (or no) 
> namespace). Janet called this thrashing - and 
> said it is bad. This is one of the purposes of 
> 4412, in times of congestion, to elevate certain 
> marked requests above others in the processing 
> queue. Section 8 of 4412 has the guidance of 
> this. I'm not reading in this thread any 
> consideration of that function - which really 
> should be included (or explained why it isn't).
> 
> James

James,

It is "thrashing" because there are two separate servers involved.  There 
are SIP messages on server A, which are intended to go to server B, but 
server B is in overload, and is asking server A to reduce the number of 
messages it is sending to server B.

I do not think it is practical (from a timing perspective) for an 
MLPP-marked SIP message on server A (in the queue for server B) on server 
A to 
a) figure out if the message being processed on server B is preemtable
and 
b) send a message to server B to preemept processing of that message
before server B finishes processing THAT (preemptable) message.

Furthermore, I don't think that approach helps the MLPP-marked SIP message 
on server A as much as just saying "this SIP message is exempt from being 
shed".

Once the MLPP-marked SIP message has been transmitted to server B, it can 
preemept anything it is entitled to, as far as I am concerned.

Same with ets and queuing.  You can do all the queue manipulation you 
want, once the ets-marked SIP message has been transmitted to server B 
(though I personally don't think it is worth the processing effort, given 
Server B is already in, or close to, overload). 

 But as long as the ets-marked SIP message is sitting on server A (in the 
queue for server B), it is a lot more beneficial to say "this ets-marked 
SIP message will not be shed" than to say "lets move this ets-marked SIP 
message to the front of the queue, where it STILL might be shed".  Whether 
you are dealing with percent based, or rate based load shedding, there is 
no particular advantage to being "first in line" at an arbitrary point in 
time. 

Being "exempt from shedding" is much more valuable.

Janet
--=_alternative 0063434585257877_=
Content-Type: text/html; charset="US-ASCII"

sip-overload-bounces@ietf.org wrote on 04/19/2011
12:32:23 PM:

> Re: [sip-overload] draft-ietf-soc-overload-design-05

> 

> James M. Polk 

> 

> it might not be, but within an RPH namespace that 

> is understood, there is the explicit ability 

> (based on whether it is configured to do so or 

> not) to have the priority-value determine which 

> SIP requests get processed moved ahead of (or 

> before) lower priority-value marked requests (or 

> those without an understandable (or no) 

> namespace). Janet called this thrashing - and 

> said it is bad. This is one of the purposes of 

> 4412, in times of congestion, to elevate certain 

> marked requests above others in the processing 

> queue. Section 8 of 4412 has the guidance of 

> this. I'm not reading in this thread any 

> consideration of that function - which really 

> should be included (or explained why it isn't).

> 

> James

James,

It is "thrashing" because there are two
separate servers involved.  There are SIP messages on server A, which
are intended to go to server B, but server B is in overload, and is asking
server A to reduce the number of messages it is sending to server B.

I do not think it is practical (from a timing perspective)
for an MLPP-marked SIP message on server A (in the queue for server B)
on server A to 

a) figure out if the message being processed on server
B is preemtable

and 

b) send a message to server B to preemept processing
of that message

before server B finishes processing THAT (preemptable)
message.

Furthermore, I don't think that approach helps the
MLPP-marked SIP message on server A as much as just saying "this SIP
message is exempt from being shed".

Once the MLPP-marked SIP message has been transmitted
to server B, it can preemept anything it is entitled to, as far as I am
concerned.

Same with ets and queuing.  You can do all the
queue manipulation you want, once the ets-marked SIP message has been transmitted
to server B (though I personally don't think it is worth the processing
effort, given Server B is already in, or close to, overload). 

 But as long as the ets-marked SIP message is
sitting on server A (in the queue for server B), it is a lot more beneficial
to say "this ets-marked SIP message will not be shed" than to
say "lets move this ets-marked SIP message to the front of the queue,
where it STILL might be shed".  Whether you are dealing with
percent based, or rate based load shedding, there is no particular advantage
to being "first in line" at an arbitrary point in time. 

Being "exempt from shedding" is much more
valuable.

Janet
--=_alternative 0063434585257877_=--

From carlberg@g11.org.uk  Tue Apr 19 12:20:42 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9B701E07D2 for ; Tue, 19 Apr 2011 12:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level: 
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcjKvd+kDuqx for ; Tue, 19 Apr 2011 12:20:41 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfc.amsl.com (Postfix) with ESMTP id 51770E0675 for ; Tue, 19 Apr 2011 12:20:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=WqugQbsw3E8Z6LffwujcvKeCkxSSNuDPzYBz8AxORKLGDD5r38a0PzmW1Ua/XUWyOV2ExcIkVOjV4aee5hLTtbITJTn0iE47zLLo3eqF8pXEgSf+nRKWM6/iUk5SW68h;
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:49858 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1QCGTL-0003kw-IC; Tue, 19 Apr 2011 19:20:28 +0000
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-78-663604564
From: ken carlberg 
In-Reply-To: 
Date: Tue, 19 Apr 2011 15:20:35 -0400
Message-Id: <16AE0F76-193C-45B1-AC98-D9624EC8B0B6@g11.org.uk>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>	  <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>	 <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>	 <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk> <4DADA3E8.6080409@bell-labs.com> 
To: Janet P Gunn 
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 19:20:42 -0000

--Apple-Mail-78-663604564
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Vijay,

from my perspective, what you have concerning =
draft-ietf-sip-overload-control is a reasonably good start. =20

However, given that this thread has required quite a lot of additional =
points being raised with a fair amount of detail (whether one agrees =
with a particular position or not), then what you have would seem to be =
insufficient in terms of an explanation of related issues and possible =
suggested path(s) forward.

cheers,

-ken

On Apr 19, 2011, at 11:24 AM, Janet P Gunn wrote:

>=20
> Vijay,=20
>=20
> What is there now is fine with me. I see no need for change.=20
>=20
> Janet=20
>=20
> sip-overload-bounces@ietf.org wrote on 04/19/2011 11:02:00 AM:
>=20
> > [image removed]=20
> >=20
> > Re: [sip-overload] draft-ietf-soc-overload-design-05=20
> >=20
> > Vijay K. Gurbani=20
> >=20
> > to:=20
> >=20
> > sip-overload=20
> >=20
> > 04/19/2011 11:00 AM=20
> >=20
> > Sent by:=20
> >=20
> > sip-overload-bounces@ietf.org=20
> >=20
> > On 04/19/2011 09:30 AM, ken carlberg wrote:
> > > I think the subject has been beaten to a pulp. And to a large =
degree, we
> > > have gone much further into topics than perhaps was necessary. The
> > > purpose of the suggested new next was to broaden the picture and =
bring
> > > up topics that are attributed to the RPH. The only position that =
was
> > > taken in the text was to suggest in the form of a "should" the use =
of
> > > the first RPH (which I meant to be the first =
"recognized/supported"
> > > RPH). But I conceded that i was fine to remove that position.
> > [...]
> >=20
> > As the editor of draft-ietf-sip-overload-control, I have read this
> > thread with interest.
> >=20
> > So, the question now is: what, if any, from this thread carries over
> > into the draft-ietf-sip-overload-control draft?  I am certainly not
> > up to verse with RPH as some of the members of this working group
> > are, so I will depend on them to point out any text that should be
> > modified in draft-ietf-sip-overload-control.
> >=20
> > For the sake of completeness, here is what
> > draft-ietf-sip-overload-control has to say about prioritizing
> > requests containing the RPH header:
> >=20
> >     A SIP client SHOULD honor the local policy for prioritizing SIP
> >     requests such as policies based on the content of the Resource-
> >     Priority header (RPH, RFC4412 [RFC4412]).  Specific =
(namespace.value)
> >     RPH contents may indicate high priority requests that should be
> >     preserved as much as possible during overload.  The RPH contents =
can
> >     also indicate a low-priority request that is eligible to be =
dropped
> >     during times of overload.  Other indicators, such as the SOS URN
> >     [RFC5031] indicating an emergency request, may also be used for
> >     prioritization.
> >=20
> > Do we deem this to be enough?
> >=20
> > Thanks,
> >=20
> > - vijay
> > --=20
> > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> > Email: vkg@{bell-labs.com,acm.org} / =
vijay.gurbani@alcatel-lucent.com
> > Web:   http://ect.bell-labs.com/who/vkg/
> > _______________________________________________
> > sip-overload mailing list
> > sip-overload@ietf.org
> > https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

--Apple-Mail-78-663604564
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Vijay,

from my perspective, what you have concerning draft-ietf-sip-overload-control is a reasonably good start.  

However, given that this thread has required quite a lot of additional points being raised with a fair amount of detail (whether one agrees with a particular position or not), then what you have would seem to be insufficient in terms of an explanation of related issues and possible suggested path(s) forward.

cheers,

-ken

On Apr 19, 2011, at 11:24 AM, Janet P Gunn wrote:

Vijay,

What is there now is fine with me. I see no need for change.

Janet

sip-overload-bounces@ietf.org wrote on 04/19/2011
11:02:00 AM:

> [image removed] 

> 

> Re: [sip-overload] draft-ietf-soc-overload-design-05

> 

> Vijay K. Gurbani 

> 

> to:

> 

> sip-overload

> 

> 04/19/2011 11:00 AM

> 

> Sent by:

> 

> sip-overload-bounces@ietf.org

> 

> On 04/19/2011 09:30 AM, ken carlberg wrote:

> > I think the subject has been beaten to a pulp. And to a large
degree, we

> > have gone much further into topics than perhaps was necessary.
The

> > purpose of the suggested new next was to broaden the picture
and bring

> > up topics that are attributed to the RPH. The only position that
was

> > taken in the text was to suggest in the form of a "should"
the use of

> > the first RPH (which I meant to be the first "recognized/supported"

> > RPH). But I conceded that i was fine to remove that position.

> [...]

> 

> As the editor of draft-ietf-sip-overload-control, I have read this

> thread with interest.

> 

> So, the question now is: what, if any, from this thread carries over

> into the draft-ietf-sip-overload-control draft?  I am certainly
not

> up to verse with RPH as some of the members of this working group

> are, so I will depend on them to point out any text that should be

> modified in draft-ietf-sip-overload-control.

> 

> For the sake of completeness, here is what

> draft-ietf-sip-overload-control has to say about prioritizing

> requests containing the RPH header:

> 

>     A SIP client SHOULD honor the local policy for prioritizing
SIP

>     requests such as policies based on the content of the
Resource-

>     Priority header (RPH, RFC4412 [RFC4412]).  Specific
(namespace.value)

>     RPH contents may indicate high priority requests that
should be

>     preserved as much as possible during overload.  The
RPH contents can

>     also indicate a low-priority request that is eligible
to be dropped

>     during times of overload.  Other indicators, such
as the SOS URN

>     [RFC5031] indicating an emergency request, may also
be used for

>     prioritization.

> 

> Do we deem this to be enough?

> 

> Thanks,

> 

> - vijay

> -- 

> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent

> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)

> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com

> Web:   http://ect.bell-labs.com/who/vkg/

> _______________________________________________

> sip-overload mailing list

> sip-overload@ietf.org

> https://www.ietf.org/mailman/listinfo/sip-overload

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

--Apple-Mail-78-663604564--

From jmpolk@cisco.com  Tue Apr 19 13:35:46 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 209E6E0874; Tue, 19 Apr 2011 13:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ot3+U3eIm+xc; Tue, 19 Apr 2011 13:35:45 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id C7383E086F; Tue, 19 Apr 2011 13:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4706; q=dns/txt; s=iport; t=1303245344; x=1304454944; h=message-id:date:to:from:subject:cc:mime-version; bh=r/aKWLnLbMvC2GSx9Be/QW68kXSKO0MvNVx+UB/8shM=; b=c/PV0L3VtcA7AEnOsNEVDPmoL0ClEtTEoPUbn6q6ojJkqACKLJ11grpw GOFInmR2SPAmM6/xh4fS9xmtF2Ukp1Szh60YV5R/FEtrPLDQ9UiAKxfez 8UPi80ByMUU30J0VdaFsbhzMy60uZxbyTHeWpnuzRoflhCYRmQzOrz1t+ A=;
X-IronPort-AV: E=Sophos;i="4.64,241,1301875200"; d="scan'208";a="297892192"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 19 Apr 2011 20:35:43 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JKZgDm003367; Tue, 19 Apr 2011 20:35:42 GMT
Message-Id: <201104192035.p3JKZgDm003367@mtv-core-2.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 19 Apr 2011 15:35:40 -0500
To: Janet P Gunn , "James M. Polk" 
From: "James M. Polk" 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sip-overload-bounces@ietf.org, "sip-overload@ietf.org" 
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2011 20:35:46 -0000

At 03:10 PM 4/19/2011, James M. Polk wrote:
>At 01:04 PM 4/19/2011, Janet P Gunn wrote:

Janet

in-line

>>sip-overload-bounces@ietf.org wrote on 04/19/2011 12:32:23 PM:
>>
>> > Re: [sip-overload] draft-ietf-soc-overload-design-05
>> >
>> > James M. Polk
>>
>> >
>> > it might not be, but within an RPH namespace that
>> > is understood, there is the explicit ability
>> > (based on whether it is configured to do so or
>> > not) to have the priority-value determine which
>> > SIP requests get processed moved ahead of (or
>> > before) lower priority-value marked requests (or
>> > those without an understandable (or no)
>> > namespace). Janet called this thrashing - and
>> > said it is bad. This is one of the purposes of
>> > 4412, in times of congestion, to elevate certain
>> > marked requests above others in the processing
>> > queue. Section 8 of 4412 has the guidance of
>> > this. I'm not reading in this thread any
>> > consideration of that function - which really
>> > should be included (or explained why it isn't).
>> >
>> > James
>>
>>James,
>>
>>It is "thrashing" because there are two separate servers 
>>involved.  There are SIP messages on server A, which are intended 
>>to go to server B, but server B is in overload, and is asking 
>>server A to reduce the number of messages it is sending to server B.

[the following is assuming 4412 is configured on server A]

ok, so server A should prioritize the SIP requests according to the 
namespace.priority-value that server A lists as highest priority and 
send those requests first - or without delaying, as will happen to 
the less prioritized or non-prioritized SIP requests. That's what 
4412 says to do. If it becomes the case that the overload condition 
exists such that Server B can only receive RPH marked SIP requests, 
then that's how it is to be configured (where Server A processes 
requests according to RPH).

>>I do not think it is practical (from a timing perspective) for an 
>>MLPP-marked

RFC 4412 is written far wider than just for MLPP and ets - for those 
of you that aren't picking that up.

>>SIP message on server A (in the queue for server B) on server A to
>>a) figure out if the message being processed on server B is preemtable
>>and
>>b) send a message to server B to preemept processing of that message
>>before server B finishes processing THAT (preemptable) message.

how does this work in non-MLPP (and non-ets) environments?

>>Furthermore, I don't think that approach helps the MLPP-marked SIP 
>>message on server A as much as just saying "this SIP message is 
>>exempt from being shed".
>>
>>Once the MLPP-marked SIP message has been transmitted to server B, 
>>it can preemept anything it is entitled to, as far as I am concerned.

But that isn't up to server A (by itself) to decide, as you seem to imply.

>>Same with ets and queuing.  You can do all the queue manipulation 
>>you want, once the ets-marked SIP message has been transmitted to 
>>server B (though I personally don't think it is worth the 
>>processing effort, given Server B is already in, or close to, overload).

If server B is an ETS enabled server, and it has not reached overload 
- it should receive ets marked SIP requests before any other 
requests, right? Why wouldn't that be the case?

>>  But as long as the ets-marked SIP message is sitting on server A 
>> (in the queue for server B), it is a lot more beneficial to say 
>> "this ets-marked SIP message will not be shed" than to say "lets 
>> move this ets-marked SIP message to the front of the queue, where 
>> it STILL might be shed".

I don't get where you say "where it STILL might be shed" ? Why would 
it be shed? The most likely (i.e., practical) way of looking at ets 
is that not very many SIP requests will be so marked, therefore there 
shouldn't be very many requests sitting in server B's processing queue.

>>Whether you are dealing with percent based, or rate based load 
>>shedding, there is no particular advantage to being "first in line" 
>>at an arbitrary point in time.

I disagree - especially when the first in line gets processed next.

>>Being "exempt from shedding" is much more valuable.

you're suggesting a second layer of complexity to SOC and reducing 
the behavior of normal 4412 operation in the process by having an 
upstream server hold a SIP request for a downstream server in times 
of near overload where there is a message prioritization mechanism in 
place. Your solution would seem to ignore the prioritization 
mechanism altogether - so why would it be there in the first place?

James

>>Janet

From volker.hilt@alcatel-lucent.com  Tue Apr 19 18:09:53 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 154B8E076F for ; Tue, 19 Apr 2011 18:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjY7y8rY8-sK for ; Tue, 19 Apr 2011 18:09:51 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 17619E072C for ; Tue, 19 Apr 2011 18:09:51 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3K19odM017159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Apr 2011 20:09:50 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3K19oYd016643 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 19 Apr 2011 20:09:50 -0500
Received: from [135.244.35.16] (135.3.63.241) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 19 Apr 2011 20:09:50 -0500
Message-ID: <4DAE325C.2090308@alcatel-lucent.com>
Date: Tue, 19 Apr 2011 21:09:48 -0400
From: Volker Hilt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: 
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>			<69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>		<578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>	 <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk>
In-Reply-To: <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2011 01:09:53 -0000

Based on the discussion in this thread, I will keep the original text of 
the design draft (i.e., leave the message prioritization section unchanged).

Thanks,

Volker

On 4/19/2011 10:30 AM, ken carlberg wrote:
>
> On Apr 19, 2011, at 9:43 AM, DRAGE, Keith (Keith) wrote:
>
>> With regard to your comment on 1), I believe nothing extra is
>> required. Anyone setting up multiple namespaces has to define at each
>> entity that is required to understand them how they are treated in
>> relationship to each other. That is part of the implementation. That
>> will define which namespaces exist, and which are used at the
>> receiving entity to give any form of priority handling. There is no
>> reason for SIP overload to alter that relationship in any way, shape,
>> or form.
>
> this is somewhat scenario dependent. but I don't think we are gaining
> any traction, so I'll stop here.
>
>> On 2), I do not believe your comment is correct. The fact that a
>> namespace is a pre-emption namespace is not an invitation to pre-empt
>> all other calls until you get your call through, even under situations
>> of no overload. It merely states that calls can be pre-empted when
>> this namespace is used. The same applies for priority. Usually the
>> algorithm for handling these DOES NOT SAY � handle all calls with this
>> namespace until there are none left, and then move onto others. It
>> deals with things like percentage of traffic and so on. So what I am
>> saying is that the RPH is not a guarantee to override all other
>> traffic, whether overload exists or not.
>
> the preemption-capable systems I've worked on in the past *must* preempt
> or tear down state when there are no available resources -- either
> established calls (or flows) or call/session establishment. I guess
> there are various scenarios and variations of implementations that one
> can consider, but I think that continues down an endless series of
> possibilities that never lead to a definitive answer.
>
> I think the subject has been beaten to a pulp. And to a large degree, we
> have gone much further into topics than perhaps was necessary. The
> purpose of the suggested new next was to broaden the picture and bring
> up topics that are attributed to the RPH. The only position that was
> taken in the text was to suggest in the form of a "should" the use of
> the first RPH (which I meant to be the first "recognized/supported"
> RPH). But I conceded that i was fine to remove that position.
>
> I'll stop here and leave it to the co-authors/co-chairs to decide how to
> proceed.
>
> -ken
>
>
>
>> Regards
>> Keith
>> ------------------------------------------------------------------------
>> *From:*ken carlberg [mailto:carlberg@g11.org.uk]
>> *Sent:*19 April 2011 14:23
>> *To:*DRAGE, Keith (Keith)
>> *Cc:*Janet Gunn;sip-overload@ietf.org 
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>> On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:
>>
>>
>> My confirmation was on what Janet wrote, rather than the original text.
>> Two comments.
>> 1) Any statement about some specific RPH being taken as a default are
>> inappropriate. If you are using RPH you must handle them in the way
>> you already know. If you do not know about an RPH value, then you have
>> to ignore it (and possibly delete it in the outgoing INVITE depending
>> on your policy). There are certainly use cases where multiple RPH
>> values can exist, covering different aspects of priority on the same
>> request. It may be the second one that is received that defines the
>> priority in regard to the handling in the SIP server itself (as
>> opposed to priority of giving a media stream or whatever).
>> or it may be the first, or the last. I'll concede the difficulty in
>> stating the first "recognized/supported" RPH is the one to be used.
>> But I think one is deferring the problem that arises with no position
>> taken at all. The primary point that I wanted to make was that the
>> possibility of multiple RPHs may exist. I'm fine with removing the
>> text of choosing a default RPH in that instance.
>>
>>
>> 2) In a case of load shedding, I suspect that the discussion on
>> whether either priority or pre-emption are relevant depend on whether
>> you are using them to represent the request to the original target
>> server that indicated overload, or to some other server. I believe
>> that in the case of representing to the original targetted server it
>> is inappropriate. It is making the assumption that some of the
>> existing traffic directed from this server to that server is somehow
>> responsible for the overload, and that is an entirely invalid assumption.
>> again, the intent of the suggested added text was to point out to the
>> reader that preemption and queuing are *examples* of what has been
>> defined so far with respect to Namespaces. What you have stated above
>> makes a case that another Namespace should be defined, otherwise, you
>> one is overloading new characteristics from what has already been
>> defined.
>> -ken
>>
>>
>> Regards
>> Keith
>> ------------------------------------------------------------------------
>> *From:*ken carlberg [mailto:carlberg@g11.org.uk]
>> *Sent:*19 April 2011 13:39
>> *To:*DRAGE, Keith (Keith)
>> *Cc:*Janet Gunn;sip-overload@ietf.org 
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>> If your comment is about the original text, then we are in some
>> measure of agreement. If you agree with a position that its incorrect
>> to point out the characteristics for currently defined Namespaces as
>> stated in rfc4412, then we are in disagreement.
>> -ken
>> On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:
>>
>>
>>
>> Janet�s statements about RPH align with the way I understand RPH works.
>> Keith
>> ------------------------------------------------------------------------
>> *From:*sip-overload-bounces@ietf.org
>> [mailto:sip-overload-bounces@ietf.org]*On
>> Behalf Of*Janet P Gunn
>> *Sent:*18 April 2011 19:21
>> *To:*ken carlberg
>> *Cc:*sip-overload-bounces@ietf.org
>> ;sip-overload@ietf.org
>> 
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>>
>>
>> Ken,
>>
>> First of all, that text is included in quite a few of the soc
>> documents, so if you change it in the design doc, it will need to be
>> changed in the others too.
>>
>> More importantly, I STRONGLY disagree with the statement that "The
>> action taken is determined by the characteristics defined for the set
>> of priority values of a Namespace (e.g., preemption versus queuing)".
>>
>> Neither "preemption" nor "queuing" are appropriate responses to a
>> request for load shedding. Either the request is shed, or it is not.
>> AFAIK, there is no intention to "preempt" another request, nor to
>> change in the order in which the messages respond to load shedding..
>>
>> In particular, in systems already deployed, SIP messages using the
>> ets/wps family of namespaces (which are defined as "queuing based" ,
>> and do queue for MEDIA resources) receive exemption from SIP server
>> overload based shedding. They do NOT have any special queuing based
>> behavior for SIP server resources. Not do they preempt other SIP requests.
>>
>> Furthermore, the behavior associated with a particular namespace is
>> highly dependant on the particular network. dsn.flash-override is not
>> going to elicit any priority behavior in a civilian or public network.
>> It will certainly not preempt anything. Conversely, ets.0, wps.0 is
>> not going to elicit any priority behavior in the DSN network
>>
>> The statement "An example local policy may even include exemptions
>> from network management control." introduces a new term - " network
>> management control" which would need to be defined. I presume that
>> what you really mean in this context is "exemption from load
>> shedding". This is already covered in i) of the existing text.
>>
>> I fail to see the reason for your proposed statement "However, for the
>> sake of simplicity, a default position should be the use of the first
>> RPH entry to determine the priority of the SIP request. " AFAIK, the
>> order of the headers is not generally relevant to SIP, and I do not
>> see any particular need to introduce it here. Furthermore, a given SIP
>> agent only "understands" certain namespaces. It seems highly
>> counterproductive to suggest that a SIP server, by default, should
>> "use" a namespace it doesn't understand (just because it is "first") ,
>> and ignore the one(s) it does understand (just because not "first").
>>
>> Even if you change the statement to read "the first RPH entry it
>> understands", you would need a "default behavior" to go with the
>> "default namespace."
>>
>> As far as I am concerned, if a particular SIP server does NOT have a
>> local policy for RPH (both which namespaces are relevant/understood,
>> and the appropriate behavior for each namespace or combination of
>> namespaces), then it should simply ignore the RPH namespaces. This
>> seems consistent with generic SIP behavior with regard to namespaces
>> in general.
>>
>> I fail to see the significance of the statement about B2BUAs. ALL SIP
>> servers, (not just B2BUAs) can and will insert, delete, or change the RPH.
>>
>> I also fail to see the need to refer explicitly to Namespaces not
>> defined in RFC4412. There are already a large number of IETF
>> registered RPH namespaces which do not appear in RFC4412 (see RFC 5478
>> for example) and others have been proposed (for instance
>> draft-ietf-ecrit-local-emergency-rph-namespace). If you are suggesting
>> that specific networks may be using purely "private" RPH namespaces
>> that have never been subject to IETF review, that may well be true in
>> practice, but I don't think it should be introduced into IETF
>> documents- especially ones that are not primarily about RPH.
>>
>> 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:
>> 	
>> ken carlberg >
>> To:
>> 	
>> sip-overload@ietf.org 
>> Date:
>> 	
>> 04/17/2011 03:38 PM
>> Subject:
>> 	
>> [sip-overload] draft-ietf-soc-overload-design-05
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> Hello,
>>
>> in following up on the discussion point I brought up at the
>> Prague-IETF meeting concerning RPH related text, I've added some
>> suggested text to section 12 ofdraft-ietf-soc-overload-design-05. The
>> suggested text is bound by the following tags:
>> 
>> 
>>
>> The purpose of the new text is to present a more complete picture and
>> point out aspects that others following this effort should be aware
>> of. I've kept the rest of the original text for that section as is
>> (ie, I did not remove any original text). I've also sent the suggested
>> text to Martin and James for a sanity check before posting to the list.
>>
>> cheers,
>>
>> -ken
>>
>>
>> 12. Message Prioritization
>>
>> Overload control can require a SIP server to prioritize requests and
>> select requests to be rejected or redirected. The selection is
>> largely a matter of local policy of the SIP server, the overall
>> network, and the services it provides. As a general rule, SIP server
>> should prioritize requests for ongoing dialogs over requests that set
>> up a new dialog. Targeting requests for ongoing dialogs may prevent
>> users from modifying or terminating an ongoing dialog.
>>
>> While there are many factors which can affect the prioritization of
>> SIP requests, the Resource-Priority header field [RFC4412] is a prime
>> candidate for marking the prioritization of SIP requests. Depending
>> on the particular network and the services it offers, a particular
>> namespace and priority value in the RPH it could indicate i) a high
>> priority request, which should be preserved if possible during
>> overload, ii) a low priority request, which should be dropped during
>> overload, or iii) a label, which has no impact on message
>> prioritization in this network.The action taken is
>> determined by the characteristics defined for the set of priority values
>> of a Namespace (e.g., preemption versus queuing) as well as the
>> local policies defined for the various Namespaces supported by the
>> server. An example local policy may even include exemptions from
>> network management control.
>>
>> We note that [RFC4412] allows the presence of multiple RPH entries
>> per SIP request. Local policy would determine which Namespace and
>> Priority tuple are used to prioritize requests. However, for the sake of
>> simplicity, a default position should be the use of the first RPH entry to
>> determine the priority of the SIP request.
>>
>> Another scenario that should be considered is the presence of Back
>> to Back User Agents (B2BUA) that may strip out the RPH from the
>> upstream SIP request. Operators or Administrators may choose to
>> insert their own RPH to support downstream prioritization of the SIP
>> request. This RPH inserted by the B2BUA may conform to a
>> Namespace set defined in [RPH4412], or it may reflect a new
>> Namespace set.
>> 
>>
>> For a number of reasons, responses should not be targeted in order to
>> reduce SIP server load. Responses cannot be rejected and would have
>> to be dropped. This triggers the retransmission of the request plus
>> the response, leading to even more load. In addition, the request
>> associated with a response has already been processed and dropping
>> the response will waste the efforts that have been spent on the
>> request. Most importantly, rejecting a request effectively also
>> removes the request and the response. If no requests are passed
>> along there will be no responses coming back in return.
>>
>> Overload control does not change the retransmission behavior of SIP.
>> Retransmissions are triggered using procedures defined in RFC 3261
>> [RFC3261] and not subject to throttling.
>> _______________________________________________
>> sip-overload mailing list
>> sip-overload@ietf.org 
>> https://www.ietf.org/mailman/listinfo/sip-overload
>>
>>
>>
>

From keith.drage@alcatel-lucent.com  Wed Apr 20 08:18:01 2011
Return-Path: 
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E42EAE0676 for ; Wed, 20 Apr 2011 08:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.303
X-Spam-Level: 
X-Spam-Status: No, score=-104.303 tagged_above=-999 required=5 tests=[AWL=-1.254, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlvNoBRVY9ty for ; Wed, 20 Apr 2011 08:18:00 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfc.amsl.com (Postfix) with ESMTP id C75C4E0761 for ; Wed, 20 Apr 2011 08:17:55 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3KFHb11009572 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 20 Apr 2011 17:17:53 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 20 Apr 2011 17:17:50 +0200
From: "DRAGE, Keith (Keith)" 
To: "Hilt, Volker (Volker)" , "sip-overload@ietf.org" 
Date: Wed, 20 Apr 2011 17:17:49 +0200
Thread-Topic: [sip-overload] draft-ietf-soc-overload-design-05
Thread-Index: Acv+96muGIQV1gvhRCuzo9ndQhaE/wAdm3dQ
Message-ID: 
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>   <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>  <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk>  <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk> <4DAE325C.2090308@alcatel-lucent.com>
In-Reply-To: <4DAE325C.2090308@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Apr 2011 15:18:02 -0000

OK

Keith

> -----Original Message-----
> From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org=
]
> On Behalf Of Volker Hilt
> Sent: 20 April 2011 02:10
> To: sip-overload@ietf.org
> Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
>
> Based on the discussion in this thread, I will keep the original text of
> the design draft (i.e., leave the message prioritization section
> unchanged).
>
> Thanks,
>
> Volker
>
>
>
> On 4/19/2011 10:30 AM, ken carlberg wrote:
> >
> > On Apr 19, 2011, at 9:43 AM, DRAGE, Keith (Keith) wrote:
> >
> >> With regard to your comment on 1), I believe nothing extra is
> >> required. Anyone setting up multiple namespaces has to define at each
> >> entity that is required to understand them how they are treated in
> >> relationship to each other. That is part of the implementation. That
> >> will define which namespaces exist, and which are used at the
> >> receiving entity to give any form of priority handling. There is no
> >> reason for SIP overload to alter that relationship in any way, shape,
> >> or form.
> >
> > this is somewhat scenario dependent. but I don't think we are gaining
> > any traction, so I'll stop here.
> >
> >> On 2), I do not believe your comment is correct. The fact that a
> >> namespace is a pre-emption namespace is not an invitation to pre-empt
> >> all other calls until you get your call through, even under situations
> >> of no overload. It merely states that calls can be pre-empted when
> >> this namespace is used. The same applies for priority. Usually the
> >> algorithm for handling these DOES NOT SAY - handle all calls with this
> >> namespace until there are none left, and then move onto others. It
> >> deals with things like percentage of traffic and so on. So what I am
> >> saying is that the RPH is not a guarantee to override all other
> >> traffic, whether overload exists or not.
> >
> > the preemption-capable systems I've worked on in the past *must* preemp=
t
> > or tear down state when there are no available resources -- either
> > established calls (or flows) or call/session establishment. I guess
> > there are various scenarios and variations of implementations that one
> > can consider, but I think that continues down an endless series of
> > possibilities that never lead to a definitive answer.
> >
> > I think the subject has been beaten to a pulp. And to a large degree, w=
e
> > have gone much further into topics than perhaps was necessary. The
> > purpose of the suggested new next was to broaden the picture and bring
> > up topics that are attributed to the RPH. The only position that was
> > taken in the text was to suggest in the form of a "should" the use of
> > the first RPH (which I meant to be the first "recognized/supported"
> > RPH). But I conceded that i was fine to remove that position.
> >
> > I'll stop here and leave it to the co-authors/co-chairs to decide how t=
o
> > proceed.
> >
> > -ken
> >
> >
> >
> >> Regards
> >> Keith
> >> ----------------------------------------------------------------------=
-
> -
> >> *From:*ken carlberg [mailto:carlberg@g11.org.uk]
> >> *Sent:*19 April 2011 14:23
> >> *To:*DRAGE, Keith (Keith)
> >> *Cc:*Janet Gunn;sip-overload@ietf.org 
> >> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
> >> On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:
> >>
> >>
> >> My confirmation was on what Janet wrote, rather than the original text=
.
> >> Two comments.
> >> 1) Any statement about some specific RPH being taken as a default are
> >> inappropriate. If you are using RPH you must handle them in the way
> >> you already know. If you do not know about an RPH value, then you have
> >> to ignore it (and possibly delete it in the outgoing INVITE depending
> >> on your policy). There are certainly use cases where multiple RPH
> >> values can exist, covering different aspects of priority on the same
> >> request. It may be the second one that is received that defines the
> >> priority in regard to the handling in the SIP server itself (as
> >> opposed to priority of giving a media stream or whatever).
> >> or it may be the first, or the last. I'll concede the difficulty in
> >> stating the first "recognized/supported" RPH is the one to be used.
> >> But I think one is deferring the problem that arises with no position
> >> taken at all. The primary point that I wanted to make was that the
> >> possibility of multiple RPHs may exist. I'm fine with removing the
> >> text of choosing a default RPH in that instance.
> >>
> >>
> >> 2) In a case of load shedding, I suspect that the discussion on
> >> whether either priority or pre-emption are relevant depend on whether
> >> you are using them to represent the request to the original target
> >> server that indicated overload, or to some other server. I believe
> >> that in the case of representing to the original targetted server it
> >> is inappropriate. It is making the assumption that some of the
> >> existing traffic directed from this server to that server is somehow
> >> responsible for the overload, and that is an entirely invalid
> assumption.
> >> again, the intent of the suggested added text was to point out to the
> >> reader that preemption and queuing are *examples* of what has been
> >> defined so far with respect to Namespaces. What you have stated above
> >> makes a case that another Namespace should be defined, otherwise, you
> >> one is overloading new characteristics from what has already been
> >> defined.
> >> -ken
> >>
> >>
> >> Regards
> >> Keith
> >> ----------------------------------------------------------------------=
-
> -
> >> *From:*ken carlberg [mailto:carlberg@g11.org.uk]
> >> *Sent:*19 April 2011 13:39
> >> *To:*DRAGE, Keith (Keith)
> >> *Cc:*Janet Gunn;sip-overload@ietf.org 
> >> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
> >> If your comment is about the original text, then we are in some
> >> measure of agreement. If you agree with a position that its incorrect
> >> to point out the characteristics for currently defined Namespaces as
> >> stated in rfc4412, then we are in disagreement.
> >> -ken
> >> On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:
> >>
> >>
> >>
> >> Janet's statements about RPH align with the way I understand RPH works=
.
> >> Keith
> >> ----------------------------------------------------------------------=
-
> -
> >> *From:*sip-overload-bounces@ietf.org
> >> [mailto:sip-overload-
> bounces@ietf.org]*On
> >> Behalf Of*Janet P Gunn
> >> *Sent:*18 April 2011 19:21
> >> *To:*ken carlberg
> >> *Cc:*sip-overload-bounces@ietf.org
> >> ;sip-overload@ietf.org
> >> 
> >> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
> >>
> >>
> >> Ken,
> >>
> >> First of all, that text is included in quite a few of the soc
> >> documents, so if you change it in the design doc, it will need to be
> >> changed in the others too.
> >>
> >> More importantly, I STRONGLY disagree with the statement that "The
> >> action taken is determined by the characteristics defined for the set
> >> of priority values of a Namespace (e.g., preemption versus queuing)".
> >>
> >> Neither "preemption" nor "queuing" are appropriate responses to a
> >> request for load shedding. Either the request is shed, or it is not.
> >> AFAIK, there is no intention to "preempt" another request, nor to
> >> change in the order in which the messages respond to load shedding..
> >>
> >> In particular, in systems already deployed, SIP messages using the
> >> ets/wps family of namespaces (which are defined as "queuing based" ,
> >> and do queue for MEDIA resources) receive exemption from SIP server
> >> overload based shedding. They do NOT have any special queuing based
> >> behavior for SIP server resources. Not do they preempt other SIP
> requests.
> >>
> >> Furthermore, the behavior associated with a particular namespace is
> >> highly dependant on the particular network. dsn.flash-override is not
> >> going to elicit any priority behavior in a civilian or public network.
> >> It will certainly not preempt anything. Conversely, ets.0, wps.0 is
> >> not going to elicit any priority behavior in the DSN network
> >>
> >> The statement "An example local policy may even include exemptions
> >> from network management control." introduces a new term - " network
> >> management control" which would need to be defined. I presume that
> >> what you really mean in this context is "exemption from load
> >> shedding". This is already covered in i) of the existing text.
> >>
> >> I fail to see the reason for your proposed statement "However, for the
> >> sake of simplicity, a default position should be the use of the first
> >> RPH entry to determine the priority of the SIP request. " AFAIK, the
> >> order of the headers is not generally relevant to SIP, and I do not
> >> see any particular need to introduce it here. Furthermore, a given SIP
> >> agent only "understands" certain namespaces. It seems highly
> >> counterproductive to suggest that a SIP server, by default, should
> >> "use" a namespace it doesn't understand (just because it is "first") ,
> >> and ignore the one(s) it does understand (just because not "first").
> >>
> >> Even if you change the statement to read "the first RPH entry it
> >> understands", you would need a "default behavior" to go with the
> >> "default namespace."
> >>
> >> As far as I am concerned, if a particular SIP server does NOT have a
> >> local policy for RPH (both which namespaces are relevant/understood,
> >> and the appropriate behavior for each namespace or combination of
> >> namespaces), then it should simply ignore the RPH namespaces. This
> >> seems consistent with generic SIP behavior with regard to namespaces
> >> in general.
> >>
> >> I fail to see the significance of the statement about B2BUAs. ALL SIP
> >> servers, (not just B2BUAs) can and will insert, delete, or change the
> RPH.
> >>
> >> I also fail to see the need to refer explicitly to Namespaces not
> >> defined in RFC4412. There are already a large number of IETF
> >> registered RPH namespaces which do not appear in RFC4412 (see RFC 5478
> >> for example) and others have been proposed (for instance
> >> draft-ietf-ecrit-local-emergency-rph-namespace). If you are suggesting
> >> that specific networks may be using purely "private" RPH namespaces
> >> that have never been subject to IETF review, that may well be true in
> >> practice, but I don't think it should be introduced into IETF
> >> documents- especially ones that are not primarily about RPH.
> >>
> >> 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:
> >>
> >> ken carlberg >
> >> To:
> >>
> >> sip-overload@ietf.org 
> >> Date:
> >>
> >> 04/17/2011 03:38 PM
> >> Subject:
> >>
> >> [sip-overload] draft-ietf-soc-overload-design-05
> >>
> >> ----------------------------------------------------------------------=
-
> -
> >>
> >>
> >>
> >>
> >> Hello,
> >>
> >> in following up on the discussion point I brought up at the
> >> Prague-IETF meeting concerning RPH related text, I've added some
> >> suggested text to section 12 ofdraft-ietf-soc-overload-design-05. The
> >> suggested text is bound by the following tags:
> >> 
> >> 
> >>
> >> The purpose of the new text is to present a more complete picture and
> >> point out aspects that others following this effort should be aware
> >> of. I've kept the rest of the original text for that section as is
> >> (ie, I did not remove any original text). I've also sent the suggested
> >> text to Martin and James for a sanity check before posting to the list=
.
> >>
> >> cheers,
> >>
> >> -ken
> >>
> >>
> >> 12. Message Prioritization
> >>
> >> Overload control can require a SIP server to prioritize requests and
> >> select requests to be rejected or redirected. The selection is
> >> largely a matter of local policy of the SIP server, the overall
> >> network, and the services it provides. As a general rule, SIP server
> >> should prioritize requests for ongoing dialogs over requests that set
> >> up a new dialog. Targeting requests for ongoing dialogs may prevent
> >> users from modifying or terminating an ongoing dialog.
> >>
> >> While there are many factors which can affect the prioritization of
> >> SIP requests, the Resource-Priority header field [RFC4412] is a prime
> >> candidate for marking the prioritization of SIP requests. Depending
> >> on the particular network and the services it offers, a particular
> >> namespace and priority value in the RPH it could indicate i) a high
> >> priority request, which should be preserved if possible during
> >> overload, ii) a low priority request, which should be dropped during
> >> overload, or iii) a label, which has no impact on message
> >> prioritization in this network.The action taken is
> >> determined by the characteristics defined for the set of priority
> values
> >> of a Namespace (e.g., preemption versus queuing) as well as the
> >> local policies defined for the various Namespaces supported by the
> >> server. An example local policy may even include exemptions from
> >> network management control.
> >>
> >> We note that [RFC4412] allows the presence of multiple RPH entries
> >> per SIP request. Local policy would determine which Namespace and
> >> Priority tuple are used to prioritize requests. However, for the sake
> of
> >> simplicity, a default position should be the use of the first RPH entr=
y
> to
> >> determine the priority of the SIP request.
> >>
> >> Another scenario that should be considered is the presence of Back
> >> to Back User Agents (B2BUA) that may strip out the RPH from the
> >> upstream SIP request. Operators or Administrators may choose to
> >> insert their own RPH to support downstream prioritization of the SIP
> >> request. This RPH inserted by the B2BUA may conform to a
> >> Namespace set defined in [RPH4412], or it may reflect a new
> >> Namespace set.
> >> 
> >>
> >> For a number of reasons, responses should not be targeted in order to
> >> reduce SIP server load. Responses cannot be rejected and would have
> >> to be dropped. This triggers the retransmission of the request plus
> >> the response, leading to even more load. In addition, the request
> >> associated with a response has already been processed and dropping
> >> the response will waste the efforts that have been spent on the
> >> request. Most importantly, rejecting a request effectively also
> >> removes the request and the response. If no requests are passed
> >> along there will be no responses coming back in return.
> >>
> >> Overload control does not change the retransmission behavior of SIP.
> >> Retransmissions are triggered using procedures defined in RFC 3261
> >> [RFC3261] and not subject to throttling.
> >> _______________________________________________
> >> sip-overload mailing list
> >> sip-overload@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/sip-overload
> >>
> >>
> >>
> >
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

From phil.m.williams@bt.com  Thu Apr 28 01:42:31 2011
Return-Path: 
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A60E06EA for ; Thu, 28 Apr 2011 01:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.805
X-Spam-Level: 
X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hss+5zUe-8Y5 for ; Thu, 28 Apr 2011 01:42:30 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFAE06DD for ; Thu, 28 Apr 2011 01:42:29 -0700 (PDT)
Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 28 Apr 2011 09:42:28 +0100
Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 28 Apr 2011 09:42:28 +0100
Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.1.221]) by EVMHT05-UKBR.domain1.systemhost.net ([193.113.108.58]) with mapi; Thu, 28 Apr 2011 09:42:28 +0100
From: 
To: 
Date: Thu, 28 Apr 2011 09:42:17 +0100
Thread-Topic: Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
Thread-Index: AcwFgC3R6VQLQZV2Q7+mAbReuc9w7A==
Message-ID: 
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-puzzleid: {50F5D2B8-BC25-4A1F-986C-C4BBA644DA19}
x-cr-hashedpuzzle: BLBx C7Vf DW7N DyLg Ej4u EuAV Fc+X GmKg HlrM IAh8 IPDt J1vl J7CP Kj9m K1NZ MHcC; 1; cwBpAHAALQBvAHYAZQByAGwAbwBhAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {50F5D2B8-BC25-4A1F-986C-C4BBA644DA19}; cABoAGkAbAAuAG0ALgB3AGkAbABsAGkAYQBtAHMAQABiAHQALgBjAG8AbQA=; Thu, 28 Apr 2011 08:42:17 GMT; UAByAG8AcABvAHMAYQBsADoAIABTAHUAcABwAG8AcgB0ACAAZgBvAHIAIAB0AGgAZQAgAHIAZQBzAHQAcgBpAGMAdABpAG8AbgAgAGEAbABnAG8AcgBpAHQAaABtAHMAIABzAGgAbwB1AGwAZAAgAGIAZQAgAG0AYQBuAGQAYQB0AG8AcgB5ACAAZgBvAHIAIABjAGwAaQBlAG4AdABzACAAKABkAHIAYQBmAHQALQBpAGUAdABmAC0AcwBvAGMALQBvAHYAZQByAGwAbwBhAGQALQBjAG8AbgB0AHIAbwBsAC0AMAAyACkA
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A42034FB7EMV04UKBRdoma_"
MIME-Version: 1.0
Subject: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2011 08:42:31 -0000

--_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A42034FB7EMV04UKBRdoma_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SIP support for 3 restriction algorithms at client sources defined in soc-o=
verload-control-02 is beneficial for the flexibility that it provides to po=
tentially support a wide range of server overload controls and network appl=
ications. However, making proportional restriction, termed a 'loss-based' a=
lgorithm, mandatory for clients would severely limit the usefulness of this=
 approach.

I will summarise the reasons for this and why this algorithm has limited us=
e in future generations of networks below.

Practical issues
-----------------------
If client system suppliers are only required to support proportional restri=
ction, then realistically it is likely that that is the only algorithm that=
 will be provided by default, and the other algorithms will be seen as char=
geable enhancements, making it difficult or expensive to deploy them.

But, of the two functional ends of a closed adaptive overload control, it i=
s the algorithm on the overloaded server that derives the control parameter=
 that is not standardised and has dependency on node architecture, whereas =
the 3 client restriction algorithms are less subject to design variation, h=
ave been around for a long time, and are already widely deployed. Therefore=
 we would expect it to be less contentious to standardise these methods wit=
hin SIP, but in any case we would expect less sensitivity to design variati=
ons.

It is not realistic to envisage a situation whereby an overloaded server su=
pports several different client restriction algorithms simultaneously, beca=
use of the complexity in design of the algorithm, and because even if a uni=
que solution is guaranteed, there will be issues of both speed of convergen=
ce to that solution, stability, and the need for the server capacity amongs=
t upstream clients to be allocated in a predictable and precise way. This h=
as implications for capacity guarantees, particularly at network boundaries=
 (see below).

If support for the 3 different restriction algorithms (or at least the 2 in=
 which we are interested) is mandated by the IETF rather than being optiona=
l, then a server subject to overload can guarantee that the sending entitie=
s will all use the same restriction algorithms, and can behave as predicted=
.

Performance imitations
----------------------------------
The main performance limitation of proportional restriction is that it is v=
ulnerable to sudden increases on the offered load at client sources, since =
the mean admitted rate after control is proportional to the mean arrival ra=
te before control until an adaptation of the control parameter is made. But=
 there will always be a delay to this control adaptation (at least in the c=
losed loop method implied by the current specification), both because of th=
e need for waiting sufficiently long at the overloaded server in order to o=
btain statistically accurate estimates before an adaptation is made, and th=
e time and number of received messages required to distribute control to th=
e clients. This vulnerability is worse when the number of clients is 'large=
' with a high capacity relative to the server. In contrast, a maximum rate-=
based control is generally not so vulnerable to short term surges in load.

The need to support precise capacity guarantees
------------------------------------------------------------------------
It is common practice for agreements concerning capacity to be provided at =
network operator boundaries [from now on I'll use SP or Service Provider as=
 a generic term encompassing Operators etc], and in many realistic applicat=
ions this is essential (I recall that his requirement is absent from the or=
iginal list of SIP overload control requirements?). It is also possible to =
want to provide guarantees to sub-streams of SP traffic.

These guarantees must be practically useful, so that they can form the basi=
s of a service level agreement between SPs. I.e. they must be simple enough=
 to be easily understood by all parties, and above all they must be clear a=
nd precise in the sense that the behaviour of the capacity is predictable/d=
eterministic (in a stochastic sense). SPs are not interested in technicalit=
ies of restriction algorithms, but will want the policies to be defined in =
terms of traffic characteristics that are straightforward to interpret and =
agree.

Clearly the policies must also be efficient in the sense that imply that th=
e available capacity can be fully utilised. I suggest that these are most e=
asily expressed as a guaranteed minimum rate and a precise way in which 'sp=
are' capacity not being used by a client originated stream is distributed o=
ver the other SPs, e.g. in terms of maximum rates determined by agreed prop=
ortions of the available unused allowances. Of course other policies are po=
ssible (but they may be less precise or more complex). Whatever policies ar=
e chosen, realising this is an inherent part of the server overload control=
, but the difficulty and complexity is dependent upon the method of call re=
striction is the clients.

With proportional restriction, note that the percentages have nothing direc=
tly to do with the proportions of server capacity allocated to different cl=
ients. So there is no natural and simple way to map between the parameters =
of the agreement and the control parameters. If the same control level were=
 applied to all client traffic, then the changes in the offered traffic fro=
m one client will always imply changes to the traffic admitted by another, =
(and in particular this applies to sudden large increases). To apply maximu=
m rate-based guarantees would require monitoring of the received rate from =
each source separately in order that the offered traffic can be derived imp=
licitly and thereby percentages derived for each specific source.

In contrast, with a rate-based restriction, it is much simpler to implement=
 policies defined in terms of maximum rates, even though these are adapted =
according to minimum guarantees and use of unused allowances in a precise a=
nd predictable way.

Comments please!

Phil Williams

--_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A42034FB7EMV04UKBRdoma_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

SIP support for 3 restriction algorithms at client sources defined in =
soc-overload-control-02 is beneficial for the flexibility that it provides =
to potentially support a wide range of server overload controls and network=
 applications. However, making proportional
restriction, termed a 'loss-based' algorithm, mandatory for clients would s=
everely limit the usefulness of this approach.

I will summarise the reasons for this and why this algorithm has limit=
ed use in future generations of networks below.

Practical issues
-----------------------
If client system suppliers are only required to support proportional r=
estriction, then realistically it is likely that that is the only algorithm=
 that will be provided by default, and the other algorithms will be seen as=
 chargeable enhancements, making
it difficult or expensive to deploy them.

But, of the two functional ends of a closed adaptive overload control,=
 it is the algorithm on the overloaded server that derives the control para=
meter that is not standardised and has dependency on node architecture, whe=
reas the 3 client restriction algorithms
are less subject to design variation, have been around for a long time, and=
 are already widely deployed. Therefore we would expect it to be less conte=
ntious to standardise these methods within SIP, but in any case we would ex=
pect less sensitivity to design
variations.

It is not realistic to envisage a situation whereby an overloaded serv=
er supports several different client restriction algorithms simultaneously,=
 because of the complexity in design of the algorithm, and because even if =
a unique solution is guaranteed,
there will be issues of both speed of convergence to that solution, stabili=
ty, and the need for the server capacity amongst upstream clients to be all=
ocated in a predictable and precise way. This has implications for capacity=
 guarantees, particularly at network
boundaries (see below).

If support for the 3 different restriction algorithms (or at least the=
 2 in which we are interested) is mandated by the IETF rather than being op=
tional, then a server subject to overload can guarantee that the sending en=
tities will all use the same restriction
algorithms, and can behave as predicted.

Performance imitations
----------------------------------
The main performance limitation of proportional restriction is that it=
 is vulnerable to sudden increases on the offered load at client sources, s=
ince the mean admitted rate after control is proportional to the mean arriv=
al rate before control until an
adaptation of the control parameter is made. But there will always be a del=
ay to this control adaptation (at least in the closed loop method implied b=
y the current specification), both because of the need for waiting sufficie=
ntly long at the overloaded server
in order to obtain statistically accurate estimates before an adaptation is=
 made, and the time and number of received messages required to distribute =
control to the clients. This vulnerability is worse when the number of clie=
nts is 'large' with a high capacity
relative to the server. In contrast, a maximum rate-based control is genera=
lly not so vulnerable to short term surges in load.

The need to support precise capacity guarantees
----------------------------------------------------------------------=
--
It is common practice for agreements concerning capacity to be provide=
d at network operator boundaries [from now on I'll use SP or Service Provid=
er as a generic term encompassing Operators etc], and in many realistic app=
lications this is essential (I recall
that his requirement is absent from the original list of SIP overload contr=
ol requirements?). It is also possible to want to provide guarantees to sub=
-streams of SP traffic. 

These guarantees must be practically useful, so that they can form the=
 basis of a service level agreement between SPs. I.e. they must be simple e=
nough to be easily understood by all parties, and above all they must be cl=
ear and precise in the sense that
the behaviour of the capacity is predictable/deterministic (in a stochastic=
 sense). SPs are not interested in technicalities of restriction algorithms=
, but will want the policies to be defined in terms of traffic characterist=
ics that are straightforward to
interpret and agree.

Clearly the policies must also be efficient in the sense that imply th=
at the available capacity can be fully utilised. I suggest that these are m=
ost easily expressed as a guaranteed minimum rate and a precise way in whic=
h 'spare' capacity not being used
by a client originated stream is distributed over the other SPs, e.g. in te=
rms of maximum rates determined by agreed proportions of the available unus=
ed allowances. Of course other policies are possible (but they may be less =
precise or more complex). Whatever
policies are chosen, realising this is an inherent part of the server overl=
oad control, but the difficulty and complexity is dependent upon the method=
 of call restriction is the clients.

With proportional restriction, note that the percentages have nothing =
directly to do with the proportions of server capacity allocated to differe=
nt clients. So there is no natural and simple way to map between the parame=
ters of the agreement and the control
parameters. If the same control level were applied to all client traffic, t=
hen the changes in the offered traffic from one client will always imply ch=
anges to the traffic admitted by another, (and in particular this applies t=
o sudden large increases). To apply
maximum rate-based guarantees would require monitoring of the received rate=
 from each source separately in order that the offered traffic can be deriv=
ed implicitly and thereby percentages derived for each specific source.

In contrast, with a rate-based restriction, it is much simpler to impl=
ement policies defined in terms of maximum rates, even though these are ada=
pted according to minimum guarantees and use of unused allowances in a prec=
ise and predictable way.

Comments please!

Phil Williams

--_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A42034FB7EMV04UKBRdoma_--

From salvatore.loreto@ericsson.com  Thu Apr 28 10:54:28 2011
Return-Path: 
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54E9E0689 for ; Thu, 28 Apr 2011 10:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.47
X-Spam-Level: 
X-Spam-Status: No, score=-106.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8vUwcmGmbE2 for ; Thu, 28 Apr 2011 10:54:27 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 96121E0670 for ; Thu, 28 Apr 2011 10:54:27 -0700 (PDT)
X-AuditID: c1b4fb39-b7cc5ae000006f6d-47-4db9a9d2b0e0
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BE.1C.28525.2D9A9BD4; Thu, 28 Apr 2011 19:54:26 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 28 Apr 2011 19:54:26 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 75E622360; Thu, 28 Apr 2011 20:54:26 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A44F508E6; Thu, 28 Apr 2011 20:54:26 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A42005043C; Thu, 28 Apr 2011 20:54:25 +0300 (EEST)
Message-ID: <4DB9A9D1.8050908@ericsson.com>
Date: Thu, 28 Apr 2011 19:54:25 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: "sip-overload@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: Volker Hilt 
Subject: [sip-overload] minutes from SoC session IETF80
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Apr 2011 17:54:29 -0000

Hi there,

below the notes from the SoC session during the IETF80 meeting in Prague.
(I have already uploaded this initial version to ietf proceeding site)

Please review them and submit any correction to the chairs by May 11.
The chairs have to send the notes toproceedings@ietf.org  by May18th.

(many thanks to Partha for taking notes during the meeting)

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

WG status update (by Volker)
+ status of SIP draft-ietf-soc-overload-design
-----------------

SIP Overload control : Vijay Presented the slides
---------------------

Vijay looks for more draft review in the list.

Robert: Ask for the text whether oc_algo is first time only or not
Vijay: The intent of oc_algo was send in the first time on the contact of the server and not subsequent time
Partha: Need more Guidelines when oc_algo re-negotiation has to happen.
Vijay: Look for draft and provide text if required.

Victor: Whether oc_algo negotiate in the reliable response
Vijay: it is not explicitly mentioned.

Kadriel: whether it is agreed for multiple algorithm
Vijay: Yes, it is agreed upon
Kadriedl: wants to re-open for the single algorithm
Roberts: Ask to open the mailing alias discussion
Janet: want to have "rate" based not to be excluded (jabber) -

Keith:  restrict 100 trying from response
Robert: It may increase complexity in the implementation
Hadriel: The text should not mandate but allowed to have

Load control Event package (Presenter: Arate Koike)
-------------------------
Some people expressed the need to refine the texts in
section 9 (RFC5390 requirements).

Avalanche restart overload  (Presenter: Arate Koike)
------------------------
Hadriel: Let register has restart-timer instead of subscribe as it is register avalanche. SUBSCRIBE may not go to Registrar.
Partha: SUBSCRIBE message itself may overload

Open discussion:
Hadriel: Mention this problem may not be solved by the proposed mechanism.
Partha: The problem solved by Avalanche is in the boot up time only.
Hadriel, Robert: Outbound proxy RFC has timer to solve the issue and it is not generic
Partha: Agreed, It will not solve all the problem
Robert: Discuss in dispatch

From volker.hilt@alcatel-lucent.com  Thu Apr 28 19:06:16 2011
Return-Path: 
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3C4E0731 for ; Thu, 28 Apr 2011 19:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.359
X-Spam-Level: 
X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC96MEhMw79k for ; Thu, 28 Apr 2011 19:06:15 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 73290E0715 for ; Thu, 28 Apr 2011 19:06:15 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3T26EVU025668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Apr 2011 21:06:14 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3T26EFc013043 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 28 Apr 2011 21:06:14 -0500
Received: from [135.104.20.65] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 28 Apr 2011 21:06:14 -0500
Message-ID: <4DBA1D11.7030001@alcatel-lucent.com>
Date: Thu, 28 Apr 2011 22:06:09 -0400
From: Volker Hilt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: 
References: 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2011 02:06:16 -0000

Phil,

> SIP support for 3 restriction algorithms at client sources defined in
> soc-overload-control-02 is beneficial for the flexibility that it
> provides to potentially support a wide range of server overload controls
> and network applications. However, making proportional restriction,
> termed a 'loss-based' algorithm, mandatory for clients would severely
> limit the usefulness of this approach.
> I will summarise the reasons for this and why this algorithm has limited
> use in future generations of networks below.
> Practical issues
> -----------------------
> If client system suppliers are only required to support proportional
> restriction, then realistically it is likely that that is the only
> algorithm that will be provided by default, and the other algorithms
> will be seen as chargeable enhancements, making it difficult or
> expensive to deploy them.
> But, of the two functional ends of a closed adaptive overload control,
> it is the algorithm on the overloaded server that derives the control
> parameter that is not standardised and has dependency on node
> architecture, whereas the 3 client restriction algorithms are less
> subject to design variation, have been around for a long time, and are
> already widely deployed. Therefore we would expect it to be less
> contentious to standardise these methods within SIP, but in any case we
> would expect less sensitivity to design variations.
> It is not realistic to envisage a situation whereby an overloaded server
> supports several different client restriction algorithms simultaneously,
> because of the complexity in design of the algorithm, and because even
> if a unique solution is guaranteed, there will be issues of both speed
> of convergence to that solution, stability, and the need for the server
> capacity amongst upstream clients to be allocated in a predictable and
> precise way. This has implications for capacity guarantees, particularly
> at network boundaries (see below).
> If support for the 3 different restriction algorithms (or at least the 2
> in which we are interested) is mandated by the IETF rather than being
> optional, then a server subject to overload can guarantee that the
> sending entities will all use the same restriction algorithms, and can
> behave as predicted.

So you are arguing that a client should always implement the full set of 
restriction algorithms (e.g., loss, rate and window)?

If we would mandate that, we would loose the possibility to extend the 
feedback types at a later point. And, of course, we add the complexity 
of requiring clients to implement multiple algorithms that to the same.

> Performance imitations
> ----------------------------------
> The main performance limitation of proportional restriction is that it
> is vulnerable to sudden increases on the offered load at client sources,
> since the mean admitted rate after control is proportional to the mean
> arrival rate before control until an adaptation of the control parameter
> is made. But there will always be a delay to this control adaptation (at
> least in the closed loop method implied by the current specification),
> both because of the need for waiting sufficiently long at the overloaded
> server in order to obtain statistically accurate estimates before an
> adaptation is made, and the time and number of received messages
> required to distribute control to the clients.

Can you please point us to results that show this behavior?

I'd also recommend to look at the results of the SIP overload control 
design team that has investigated this problem.

> This vulnerability is
> worse when the number of clients is 'large' with a high capacity
> relative to the server. In contrast, a maximum rate-based control is
> generally not so vulnerable to short term surges in load.

A rate based mechanism needs to split its capacity across upstream 
neighbors. If new clients arrive, the split has to be adjusted. In 
particular if you are dealing with a large set of clients some of which 
may be inactive for some time, this requires a quick readjustment of the 
allocated capacity. This topic has been discussion in the design 
considerations draft.

> The need to support precise capacity guarantees
> ------------------------------------------------------------------------
> It is common practice for agreements concerning capacity to be provided
> at network operator boundaries [from now on I'll use SP or Service
> Provider as a generic term encompassing Operators etc], and in many
> realistic applications this is essential (I recall that his requirement
> is absent from the original list of SIP overload control requirements?).
> It is also possible to want to provide guarantees to sub-streams of SP
> traffic.
> These guarantees must be practically useful, so that they can form the
> basis of a service level agreement between SPs. I.e. they must be simple
> enough to be easily understood by all parties, and above all they must
> be clear and precise in the sense that the behaviour of the capacity is
> predictable/deterministic (in a stochastic sense). SPs are not
> interested in technicalities of restriction algorithms, but will want
> the policies to be defined in terms of traffic characteristics that are
> straightforward to interpret and agree.
> Clearly the policies must also be efficient in the sense that imply that
> the available capacity can be fully utilised. I suggest that these are
> most easily expressed as a guaranteed minimum rate and a precise way in
> which 'spare' capacity not being used by a client originated stream is
> distributed over the other SPs, e.g. in terms of maximum rates
> determined by agreed proportions of the available unused allowances. Of
> course other policies are possible (but they may be less precise or more
> complex). Whatever policies are chosen, realising this is an inherent
> part of the server overload control, but the difficulty and complexity
> is dependent upon the method of call restriction is the clients.
> With proportional restriction, note that the percentages have nothing
> directly to do with the proportions of server capacity allocated to
> different clients. So there is no natural and simple way to map between
> the parameters of the agreement and the control parameters. If the same
> control level were applied to all client traffic, then the changes in
> the offered traffic from one client will always imply changes to the
> traffic admitted by another, (and in particular this applies to sudden
> large increases). To apply maximum rate-based guarantees would require
> monitoring of the received rate from each source separately in order
> that the offered traffic can be derived implicitly and thereby
> percentages derived for each specific source.
> In contrast, with a rate-based restriction, it is much simpler to
> implement policies defined in terms of maximum rates, even though these
> are adapted according to minimum guarantees and use of unused allowances
> in a precise and predictable way.

I don't think overload control is the right tool to police SLAs.

Let's assume for a second you are in fact using overload control for 
this purpose and are configuring your overload control rates to match 
your SLAs. Say you have two servers A and B (each with capacity 500 
req/s) and four upstream neighbors. The SLA with each of them is that 
you accept 250 req/s.

If one of your servers goes down, your capacity is cut in half. If you 
have configured overload control to honor you SLAs, your remaining 
server will melt down within ms. Your only choice to survive this 
situation is to use overload control and cut the rates below the SLA.

Thanks,

Volker (as individual)

> Comments please!
> Phil Williams

From ecnoel@research.att.com  Fri Apr 29 05:54:30 2011
Return-Path: 
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AE7E074D for ; Fri, 29 Apr 2011 05:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.359
X-Spam-Level: 
X-Spam-Status: No, score=-101.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1So3mL-0yGL for ; Fri, 29 Apr 2011 05:54:27 -0700 (PDT)
Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by ietfa.amsl.com (Postfix) with ESMTP id C2602E064B for ; Fri, 29 Apr 2011 05:54:26 -0700 (PDT)
Received: from njfpsrvexg6.research.att.com (njfpsrvexg6.research.att.com [135.207.177.28]) by mail-green.research.att.com (Postfix) with ESMTP id A10DF84A6; Fri, 29 Apr 2011 08:54:25 -0400 (EDT)
Received: from njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b]) by njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b%10]) with mapi; Fri, 29 Apr 2011 08:55:50 -0400
From: "NOEL, ERIC C (ERIC C)" 
To: Volker Hilt , "sip-overload@ietf.org" 
Date: Fri, 29 Apr 2011 08:56:32 -0400
Thread-Topic: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
Thread-Index: AcwGEjm3TMkzlAWkQzeVk25eMD75YAAV2Ymg
Message-ID: <2F8FB48C17221643AD77FA295756D2A71E23562CF2@njfpsrvexg6.research.att.com>
References:  <4DBA1D11.7030001@alcatel-lucent.com>
In-Reply-To: <4DBA1D11.7030001@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2011 12:54:31 -0000

Volker,=20

Wrt Phil's comment on vulnerability to sudden increases on the offered load=
 at client sources, I believe the paper from Arthur Berger in IEEE Transact=
ions on Automatic Control Vol 36, No2, February 1991 titled "Overload Contr=
ol Using Rate Control: Selecting Token Bank Capacity for Robustness to Arri=
val Rates" supports that observation.

In that paper, Figure 3 compares rate control to call gapping and to percen=
t blocking. As offered load increases, rate control is the only algorithm t=
hat controls load close to the target. Basically Phil's point.

Because it is a copyrighted document, I do not think I can broadcast on dis=
tribution list. However, if you cannot get a copy of the paper let me know =
and I will assist you.

Thanks,

Eric Noel=20
LMTS
AT&T Labs, Inc.=20
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
ecnoel@att.com

-----Original Message-----
From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] =
On Behalf Of Volker Hilt
Sent: Thursday, April 28, 2011 10:06 PM
To: sip-overload@ietf.org
Subject: Re: [sip-overload] Proposal: Support for the restriction algorithm=
s should be mandatory for clients (draft-ietf-soc-overload-control-02)

Phil,

> SIP support for 3 restriction algorithms at client sources defined in
> soc-overload-control-02 is beneficial for the flexibility that it
> provides to potentially support a wide range of server overload controls
> and network applications. However, making proportional restriction,
> termed a 'loss-based' algorithm, mandatory for clients would severely
> limit the usefulness of this approach.
> I will summarise the reasons for this and why this algorithm has limited
> use in future generations of networks below.
> Practical issues
> -----------------------
> If client system suppliers are only required to support proportional
> restriction, then realistically it is likely that that is the only
> algorithm that will be provided by default, and the other algorithms
> will be seen as chargeable enhancements, making it difficult or
> expensive to deploy them.
> But, of the two functional ends of a closed adaptive overload control,
> it is the algorithm on the overloaded server that derives the control
> parameter that is not standardised and has dependency on node
> architecture, whereas the 3 client restriction algorithms are less
> subject to design variation, have been around for a long time, and are
> already widely deployed. Therefore we would expect it to be less
> contentious to standardise these methods within SIP, but in any case we
> would expect less sensitivity to design variations.
> It is not realistic to envisage a situation whereby an overloaded server
> supports several different client restriction algorithms simultaneously,
> because of the complexity in design of the algorithm, and because even
> if a unique solution is guaranteed, there will be issues of both speed
> of convergence to that solution, stability, and the need for the server
> capacity amongst upstream clients to be allocated in a predictable and
> precise way. This has implications for capacity guarantees, particularly
> at network boundaries (see below).
> If support for the 3 different restriction algorithms (or at least the 2
> in which we are interested) is mandated by the IETF rather than being
> optional, then a server subject to overload can guarantee that the
> sending entities will all use the same restriction algorithms, and can
> behave as predicted.

So you are arguing that a client should always implement the full set of=20
restriction algorithms (e.g., loss, rate and window)?

If we would mandate that, we would loose the possibility to extend the=20
feedback types at a later point. And, of course, we add the complexity=20
of requiring clients to implement multiple algorithms that to the same.

> Performance imitations
> ----------------------------------
> The main performance limitation of proportional restriction is that it
> is vulnerable to sudden increases on the offered load at client sources,
> since the mean admitted rate after control is proportional to the mean
> arrival rate before control until an adaptation of the control parameter
> is made. But there will always be a delay to this control adaptation (at
> least in the closed loop method implied by the current specification),
> both because of the need for waiting sufficiently long at the overloaded
> server in order to obtain statistically accurate estimates before an
> adaptation is made, and the time and number of received messages
> required to distribute control to the clients.

Can you please point us to results that show this behavior?

I'd also recommend to look at the results of the SIP overload control=20
design team that has investigated this problem.

> This vulnerability is
> worse when the number of clients is 'large' with a high capacity
> relative to the server. In contrast, a maximum rate-based control is
> generally not so vulnerable to short term surges in load.

A rate based mechanism needs to split its capacity across upstream=20
neighbors. If new clients arrive, the split has to be adjusted. In=20
particular if you are dealing with a large set of clients some of which=20
may be inactive for some time, this requires a quick readjustment of the=20
allocated capacity. This topic has been discussion in the design=20
considerations draft.

> The need to support precise capacity guarantees
> ------------------------------------------------------------------------
> It is common practice for agreements concerning capacity to be provided
> at network operator boundaries [from now on I'll use SP or Service
> Provider as a generic term encompassing Operators etc], and in many
> realistic applications this is essential (I recall that his requirement
> is absent from the original list of SIP overload control requirements?).
> It is also possible to want to provide guarantees to sub-streams of SP
> traffic.
> These guarantees must be practically useful, so that they can form the
> basis of a service level agreement between SPs. I.e. they must be simple
> enough to be easily understood by all parties, and above all they must
> be clear and precise in the sense that the behaviour of the capacity is
> predictable/deterministic (in a stochastic sense). SPs are not
> interested in technicalities of restriction algorithms, but will want
> the policies to be defined in terms of traffic characteristics that are
> straightforward to interpret and agree.
> Clearly the policies must also be efficient in the sense that imply that
> the available capacity can be fully utilised. I suggest that these are
> most easily expressed as a guaranteed minimum rate and a precise way in
> which 'spare' capacity not being used by a client originated stream is
> distributed over the other SPs, e.g. in terms of maximum rates
> determined by agreed proportions of the available unused allowances. Of
> course other policies are possible (but they may be less precise or more
> complex). Whatever policies are chosen, realising this is an inherent
> part of the server overload control, but the difficulty and complexity
> is dependent upon the method of call restriction is the clients.
> With proportional restriction, note that the percentages have nothing
> directly to do with the proportions of server capacity allocated to
> different clients. So there is no natural and simple way to map between
> the parameters of the agreement and the control parameters. If the same
> control level were applied to all client traffic, then the changes in
> the offered traffic from one client will always imply changes to the
> traffic admitted by another, (and in particular this applies to sudden
> large increases). To apply maximum rate-based guarantees would require
> monitoring of the received rate from each source separately in order
> that the offered traffic can be derived implicitly and thereby
> percentages derived for each specific source.
> In contrast, with a rate-based restriction, it is much simpler to
> implement policies defined in terms of maximum rates, even though these
> are adapted according to minimum guarantees and use of unused allowances
> in a precise and predictable way.

I don't think overload control is the right tool to police SLAs.

Let's assume for a second you are in fact using overload control for=20
this purpose and are configuring your overload control rates to match=20
your SLAs. Say you have two servers A and B (each with capacity 500=20
req/s) and four upstream neighbors. The SLA with each of them is that=20
you accept 250 req/s.

If one of your servers goes down, your capacity is cut in half. If you=20
have configured overload control to honor you SLAs, your remaining=20
server will melt down within ms. Your only choice to survive this=20
situation is to use overload control and cut the rates below the SLA.

Thanks,

Volker (as individual)

> Comments please!
> Phil Williams
_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload

From SBharrat@sonusnet.com  Fri Apr 29 07:09:56 2011
Return-Path: 
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1665DE074D for ; Fri, 29 Apr 2011 07:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.359
X-Spam-Level: 
X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RMKZHQQoKVb for ; Fri, 29 Apr 2011 07:09:51 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D9E075B for ; Fri, 29 Apr 2011 07:09:49 -0700 (PDT)
Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p3TE9xU9024239;  Fri, 29 Apr 2011 10:09:59 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Apr 2011 10:07:31 -0400
Message-ID: <637C77B6763BB54ABF989B6B21D53235045F8DB2@sonusmail05.sonusnet.com>
In-Reply-To: <2F8FB48C17221643AD77FA295756D2A71E23562CF2@njfpsrvexg6.research.att.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
Thread-Index: AcwGEjm3TMkzlAWkQzeVk25eMD75YAAV2YmgAAG7yWA=
References: <4DBA1D11.7030001@alcatel-lucent.com> <2F8FB48C17221643AD77FA295756D2A71E23562CF2@njfpsrvexg6.research.att.com>
From: "Bharrat, Shaun" 
To: "NOEL, ERIC C (ERIC C)" , "Volker Hilt" , 
Subject: Re: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2011 14:09:56 -0000

> In that paper, Figure 3 compares rate control to call gapping and to
> percent blocking. As offered load increases, rate control is the only
> algorithm that controls load close to the target. Basically Phil's
> point.

All:

As a VOIP gateway/SBC vendor in some large networks, we have seen this
effect. For the cases I have been involved in, it has happened when=20
the network design has nodes arranged not is a strict hierarchy but
rather in a mesh where there are multiple paths between any two
particular
nodes and the paths are of different lengths. (As a degenerate case,
assume both A->C, and A->B->C).=20

For these cases, we needed to implement rate (versus loss) control (at B

in the example) since the input load at B towards C could dramatically=20
increase when A notices the distress at C for the direct A->C calls.=20
(The load at B towards A can increase for a lot of reasons but this one
happens coincident with trying to control load towards C.)

That said, it wasn't feasible to implement rate control advertisements
from C. That possibility was amply discussed in the draft and on this
email list and we agree with the conclusions. Another concern is the=20
addition of any complexity to the processing at C in order to track and
distribute rates per source... after all, this is the *overloaded* box.

In the end, what appears to work better (details are different but the
concept
is roughly right) is that the downstream (overloaded) node reports a
simple desired loss percentage, and the upstream uses that to *compute*
a rate towards the overloaded peer (100 -loss percentage)*(previous rate
towards that peer). In effect, the upstream node limits itself to the
loss percentage applied to the rate that produced that loss percentage.

Whether this is "allowed" by the overload draft was discussed last on
7/19/2010
	> -----Original Message-----
	> From: Volker Hilt [mailto:volker.hilt@alcatel-lucent.com]
	> Sent: Monday, July 19, 2010 5:48 AM
	> To: Bharrat, Shaun
	> Cc: sip-overload@ietf.org
	> Subject: Re: [sip-overload] SIP overload control draft -
sender
	> behavior

but it appears there wasn't a conclusion to this.=20

Cheers,
Shaun

> -----Original Message-----
> From: sip-overload-bounces@ietf.org [mailto:sip-overload-
> bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C)
> Sent: Friday, April 29, 2011 8:57 AM
> To: Volker Hilt; sip-overload@ietf.org
> Subject: Re: [sip-overload] Proposal: Support for the restriction
> algorithms should be mandatory for clients (draft-ietf-soc-overload-
> control-02)
>=20
> Volker,
>=20
> Wrt Phil's comment on vulnerability to sudden increases on the offered
> load at client sources, I believe the paper from Arthur Berger in IEEE
> Transactions on Automatic Control Vol 36, No2, February 1991 titled
> "Overload Control Using Rate Control: Selecting Token Bank Capacity
for
> Robustness to Arrival Rates" supports that observation.
>=20
> In that paper, Figure 3 compares rate control to call gapping and to
> percent blocking. As offered load increases, rate control is the only
> algorithm that controls load close to the target. Basically Phil's
> point.
>=20
> Because it is a copyrighted document, I do not think I can broadcast
on
> distribution list. However, if you cannot get a copy of the paper let
> me know and I will assist you.
>=20
> Thanks,
>=20
> Eric Noel
> LMTS
> AT&T Labs, Inc.
> Rethink Possible
>=20
> Network Design and Performance Analysis
> 200 South Laurel Avenue, D5-3D19
> Middletown, NJ 07748
> P: 732.420.4174
> ecnoel@att.com
>=20
>=20
> -----Original Message-----
> From: sip-overload-bounces@ietf.org [mailto:sip-overload-
> bounces@ietf.org] On Behalf Of Volker Hilt
> Sent: Thursday, April 28, 2011 10:06 PM
> To: sip-overload@ietf.org
> Subject: Re: [sip-overload] Proposal: Support for the restriction
> algorithms should be mandatory for clients (draft-ietf-soc-overload-
> control-02)
>=20
> Phil,
>=20
> > SIP support for 3 restriction algorithms at client sources defined
in
> > soc-overload-control-02 is beneficial for the flexibility that it
> > provides to potentially support a wide range of server overload
> controls
> > and network applications. However, making proportional restriction,
> > termed a 'loss-based' algorithm, mandatory for clients would
severely
> > limit the usefulness of this approach.
> > I will summarise the reasons for this and why this algorithm has
> limited
> > use in future generations of networks below.
> > Practical issues
> > -----------------------
> > If client system suppliers are only required to support proportional
> > restriction, then realistically it is likely that that is the only
> > algorithm that will be provided by default, and the other algorithms
> > will be seen as chargeable enhancements, making it difficult or
> > expensive to deploy them.
> > But, of the two functional ends of a closed adaptive overload
> control,
> > it is the algorithm on the overloaded server that derives the
control
> > parameter that is not standardised and has dependency on node
> > architecture, whereas the 3 client restriction algorithms are less
> > subject to design variation, have been around for a long time, and
> are
> > already widely deployed. Therefore we would expect it to be less
> > contentious to standardise these methods within SIP, but in any case
> we
> > would expect less sensitivity to design variations.
> > It is not realistic to envisage a situation whereby an overloaded
> server
> > supports several different client restriction algorithms
> simultaneously,
> > because of the complexity in design of the algorithm, and because
> even
> > if a unique solution is guaranteed, there will be issues of both
> speed
> > of convergence to that solution, stability, and the need for the
> server
> > capacity amongst upstream clients to be allocated in a predictable
> and
> > precise way. This has implications for capacity guarantees,
> particularly
> > at network boundaries (see below).
> > If support for the 3 different restriction algorithms (or at least
> the 2
> > in which we are interested) is mandated by the IETF rather than
being
> > optional, then a server subject to overload can guarantee that the
> > sending entities will all use the same restriction algorithms, and
> can
> > behave as predicted.
>=20
> So you are arguing that a client should always implement the full set
> of
> restriction algorithms (e.g., loss, rate and window)?
>=20
> If we would mandate that, we would loose the possibility to extend the
> feedback types at a later point. And, of course, we add the complexity
> of requiring clients to implement multiple algorithms that to the
same.
>=20
> > Performance imitations
> > ----------------------------------
> > The main performance limitation of proportional restriction is that
> it
> > is vulnerable to sudden increases on the offered load at client
> sources,
> > since the mean admitted rate after control is proportional to the
> mean
> > arrival rate before control until an adaptation of the control
> parameter
> > is made. But there will always be a delay to this control adaptation
> (at
> > least in the closed loop method implied by the current
> specification),
> > both because of the need for waiting sufficiently long at the
> overloaded
> > server in order to obtain statistically accurate estimates before an
> > adaptation is made, and the time and number of received messages
> > required to distribute control to the clients.
>=20
> Can you please point us to results that show this behavior?
>=20
> I'd also recommend to look at the results of the SIP overload control
> design team that has investigated this problem.
>=20
> > This vulnerability is
> > worse when the number of clients is 'large' with a high capacity
> > relative to the server. In contrast, a maximum rate-based control is
> > generally not so vulnerable to short term surges in load.
>=20
> A rate based mechanism needs to split its capacity across upstream
> neighbors. If new clients arrive, the split has to be adjusted. In
> particular if you are dealing with a large set of clients some of
which
> may be inactive for some time, this requires a quick readjustment of
> the
> allocated capacity. This topic has been discussion in the design
> considerations draft.
>=20
> > The need to support precise capacity guarantees
> >
---------------------------------------------------------------------
> ---
> > It is common practice for agreements concerning capacity to be
> provided
> > at network operator boundaries [from now on I'll use SP or Service
> > Provider as a generic term encompassing Operators etc], and in many
> > realistic applications this is essential (I recall that his
> requirement
> > is absent from the original list of SIP overload control
> requirements?).
> > It is also possible to want to provide guarantees to sub-streams of
> SP
> > traffic.
> > These guarantees must be practically useful, so that they can form
> the
> > basis of a service level agreement between SPs. I.e. they must be
> simple
> > enough to be easily understood by all parties, and above all they
> must
> > be clear and precise in the sense that the behaviour of the capacity
> is
> > predictable/deterministic (in a stochastic sense). SPs are not
> > interested in technicalities of restriction algorithms, but will
want
> > the policies to be defined in terms of traffic characteristics that
> are
> > straightforward to interpret and agree.
> > Clearly the policies must also be efficient in the sense that imply
> that
> > the available capacity can be fully utilised. I suggest that these
> are
> > most easily expressed as a guaranteed minimum rate and a precise way
> in
> > which 'spare' capacity not being used by a client originated stream
> is
> > distributed over the other SPs, e.g. in terms of maximum rates
> > determined by agreed proportions of the available unused allowances.
> Of
> > course other policies are possible (but they may be less precise or
> more
> > complex). Whatever policies are chosen, realising this is an
inherent
> > part of the server overload control, but the difficulty and
> complexity
> > is dependent upon the method of call restriction is the clients.
> > With proportional restriction, note that the percentages have
nothing
> > directly to do with the proportions of server capacity allocated to
> > different clients. So there is no natural and simple way to map
> between
> > the parameters of the agreement and the control parameters. If the
> same
> > control level were applied to all client traffic, then the changes
in
> > the offered traffic from one client will always imply changes to the
> > traffic admitted by another, (and in particular this applies to
> sudden
> > large increases). To apply maximum rate-based guarantees would
> require
> > monitoring of the received rate from each source separately in order
> > that the offered traffic can be derived implicitly and thereby
> > percentages derived for each specific source.
> > In contrast, with a rate-based restriction, it is much simpler to
> > implement policies defined in terms of maximum rates, even though
> these
> > are adapted according to minimum guarantees and use of unused
> allowances
> > in a precise and predictable way.
>=20
> I don't think overload control is the right tool to police SLAs.
>=20
> Let's assume for a second you are in fact using overload control for
> this purpose and are configuring your overload control rates to match
> your SLAs. Say you have two servers A and B (each with capacity 500
> req/s) and four upstream neighbors. The SLA with each of them is that
> you accept 250 req/s.
>=20
> If one of your servers goes down, your capacity is cut in half. If you
> have configured overload control to honor you SLAs, your remaining
> server will melt down within ms. Your only choice to survive this
> situation is to use overload control and cut the rates below the SLA.
>=20
> Thanks,
>=20
> Volker (as individual)
>=20
>=20
>=20
>=20
> > Comments please!
> > Phil Williams
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

From volker.hilt@alcatel-lucent.com  Fri Apr 29 09:42:47 2011
Return-Path: 
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64BDE06EA for ; Fri, 29 Apr 2011 09:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.359
X-Spam-Level: 
X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQh0U+1j4WRV for ; Fri, 29 Apr 2011 09:42:43 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B4665E069F for ; Fri, 29 Apr 2011 09:42:43 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p3TGgg7w019279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Apr 2011 11:42:43 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3TGggdm023658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Apr 2011 11:42:42 -0500
Received: from [135.112.131.41] (135.3.63.242) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Fri, 29 Apr 2011 11:42:42 -0500
Message-ID: <4DBAEA7B.2020203@alcatel-lucent.com>
Date: Fri, 29 Apr 2011 12:42:35 -0400
From: Volker Hilt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "NOEL, ERIC C (ERIC C)" 
References:  <4DBA1D11.7030001@alcatel-lucent.com> <2F8FB48C17221643AD77FA295756D2A71E23562CF2@njfpsrvexg6.research.att.com>
In-Reply-To: <2F8FB48C17221643AD77FA295756D2A71E23562CF2@njfpsrvexg6.research.att.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: "sip-overload@ietf.org" 
Subject: Re: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2011 16:42:47 -0000

Eric,

what makes you think the problems described in this paper apply to SIP 
overload control? None of the simulations (including yours) did show 
problems with loss-based control. Do you have results that replicate 
these issues in a SIP network? What is missing?

Volker

On 4/29/2011 8:56 AM, NOEL, ERIC C (ERIC C) wrote:
> Volker,
>
> Wrt Phil's comment on vulnerability to sudden increases on the
> offered load at client sources, I believe the paper from Arthur
> Berger in IEEE Transactions on Automatic Control Vol 36, No2,
> February 1991 titled "Overload Control Using Rate Control: Selecting
> Token Bank Capacity for Robustness to Arrival Rates" supports that
> observation.
>
> In that paper, Figure 3 compares rate control to call gapping and to
> percent blocking. As offered load increases, rate control is the only
> algorithm that controls load close to the target. Basically Phil's
> point.
>
> Because it is a copyrighted document, I do not think I can broadcast
> on distribution list. However, if you cannot get a copy of the paper
> let me know and I will assist you.
>
> Thanks,
>
> Eric Noel LMTS AT&T Labs, Inc. Rethink Possible
>
> Network Design and Performance Analysis 200 South Laurel Avenue,
> D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com
>
>
> -----Original Message----- From: sip-overload-bounces@ietf.org
> [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt Sent:
> Thursday, April 28, 2011 10:06 PM To: sip-overload@ietf.org Subject:
> Re: [sip-overload] Proposal: Support for the restriction algorithms
> should be mandatory for clients (draft-ietf-soc-overload-control-02)
>
> Phil,
>
>> SIP support for 3 restriction algorithms at client sources defined
>> in soc-overload-control-02 is beneficial for the flexibility that
>> it provides to potentially support a wide range of server overload
>> controls and network applications. However, making proportional
>> restriction, termed a 'loss-based' algorithm, mandatory for clients
>> would severely limit the usefulness of this approach. I will
>> summarise the reasons for this and why this algorithm has limited
>> use in future generations of networks below. Practical issues
>> ----------------------- If client system suppliers are only
>> required to support proportional restriction, then realistically it
>> is likely that that is the only algorithm that will be provided by
>> default, and the other algorithms will be seen as chargeable
>> enhancements, making it difficult or expensive to deploy them. But,
>> of the two functional ends of a closed adaptive overload control,
>> it is the algorithm on the overloaded server that derives the
>> control parameter that is not standardised and has dependency on
>> node architecture, whereas the 3 client restriction algorithms are
>> less subject to design variation, have been around for a long time,
>> and are already widely deployed. Therefore we would expect it to be
>> less contentious to standardise these methods within SIP, but in
>> any case we would expect less sensitivity to design variations. It
>> is not realistic to envisage a situation whereby an overloaded
>> server supports several different client restriction algorithms
>> simultaneously, because of the complexity in design of the
>> algorithm, and because even if a unique solution is guaranteed,
>> there will be issues of both speed of convergence to that solution,
>> stability, and the need for the server capacity amongst upstream
>> clients to be allocated in a predictable and precise way. This has
>> implications for capacity guarantees, particularly at network
>> boundaries (see below). If support for the 3 different restriction
>> algorithms (or at least the 2 in which we are interested) is
>> mandated by the IETF rather than being optional, then a server
>> subject to overload can guarantee that the sending entities will
>> all use the same restriction algorithms, and can behave as
>> predicted.
>
> So you are arguing that a client should always implement the full set
> of restriction algorithms (e.g., loss, rate and window)?
>
> If we would mandate that, we would loose the possibility to extend
> the feedback types at a later point. And, of course, we add the
> complexity of requiring clients to implement multiple algorithms that
> to the same.
>
>> Performance imitations ---------------------------------- The main
>> performance limitation of proportional restriction is that it is
>> vulnerable to sudden increases on the offered load at client
>> sources, since the mean admitted rate after control is proportional
>> to the mean arrival rate before control until an adaptation of the
>> control parameter is made. But there will always be a delay to this
>> control adaptation (at least in the closed loop method implied by
>> the current specification), both because of the need for waiting
>> sufficiently long at the overloaded server in order to obtain
>> statistically accurate estimates before an adaptation is made, and
>> the time and number of received messages required to distribute
>> control to the clients.
>
> Can you please point us to results that show this behavior?
>
> I'd also recommend to look at the results of the SIP overload
> control design team that has investigated this problem.
>
>> This vulnerability is worse when the number of clients is 'large'
>> with a high capacity relative to the server. In contrast, a maximum
>> rate-based control is generally not so vulnerable to short term
>> surges in load.
>
> A rate based mechanism needs to split its capacity across upstream
> neighbors. If new clients arrive, the split has to be adjusted. In
> particular if you are dealing with a large set of clients some of
> which may be inactive for some time, this requires a quick
> readjustment of the allocated capacity. This topic has been
> discussion in the design considerations draft.
>
>> The need to support precise capacity guarantees
>> ------------------------------------------------------------------------
>>
>>
It is common practice for agreements concerning capacity to be provided
>> at network operator boundaries [from now on I'll use SP or Service
>> Provider as a generic term encompassing Operators etc], and in
>> many realistic applications this is essential (I recall that his
>> requirement is absent from the original list of SIP overload
>> control requirements?). It is also possible to want to provide
>> guarantees to sub-streams of SP traffic. These guarantees must be
>> practically useful, so that they can form the basis of a service
>> level agreement between SPs. I.e. they must be simple enough to be
>> easily understood by all parties, and above all they must be clear
>> and precise in the sense that the behaviour of the capacity is
>> predictable/deterministic (in a stochastic sense). SPs are not
>> interested in technicalities of restriction algorithms, but will
>> want the policies to be defined in terms of traffic characteristics
>> that are straightforward to interpret and agree. Clearly the
>> policies must also be efficient in the sense that imply that the
>> available capacity can be fully utilised. I suggest that these are
>> most easily expressed as a guaranteed minimum rate and a precise
>> way in which 'spare' capacity not being used by a client originated
>> stream is distributed over the other SPs, e.g. in terms of maximum
>> rates determined by agreed proportions of the available unused
>> allowances. Of course other policies are possible (but they may be
>> less precise or more complex). Whatever policies are chosen,
>> realising this is an inherent part of the server overload control,
>> but the difficulty and complexity is dependent upon the method of
>> call restriction is the clients. With proportional restriction,
>> note that the percentages have nothing directly to do with the
>> proportions of server capacity allocated to different clients. So
>> there is no natural and simple way to map between the parameters of
>> the agreement and the control parameters. If the same control level
>> were applied to all client traffic, then the changes in the offered
>> traffic from one client will always imply changes to the traffic
>> admitted by another, (and in particular this applies to sudden
>> large increases). To apply maximum rate-based guarantees would
>> require monitoring of the received rate from each source separately
>> in order that the offered traffic can be derived implicitly and
>> thereby percentages derived for each specific source. In contrast,
>> with a rate-based restriction, it is much simpler to implement
>> policies defined in terms of maximum rates, even though these are
>> adapted according to minimum guarantees and use of unused
>> allowances in a precise and predictable way.
>
> I don't think overload control is the right tool to police SLAs.
>
> Let's assume for a second you are in fact using overload control for
> this purpose and are configuring your overload control rates to
> match your SLAs. Say you have two servers A and B (each with capacity
> 500 req/s) and four upstream neighbors. The SLA with each of them is
> that you accept 250 req/s.
>
> If one of your servers goes down, your capacity is cut in half. If
> you have configured overload control to honor you SLAs, your
> remaining server will melt down within ms. Your only choice to
> survive this situation is to use overload control and cut the rates
> below the SLA.
>
> Thanks,
>
> Volker (as individual)
>
>
>
>
>> Comments please! Phil Williams
> _______________________________________________ sip-overload mailing
> list sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

From ecnoel@research.att.com  Fri Apr 29 11:00:27 2011
Return-Path: 
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293F1E06C0 for ; Fri, 29 Apr 2011 11:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.359
X-Spam-Level: 
X-Spam-Status: No, score=-101.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFmxu2WY741I for ; Fri, 29 Apr 2011 11:00:26 -0700 (PDT)
Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by ietfa.amsl.com (Postfix) with ESMTP id D80A7E069F for ; Fri, 29 Apr 2011 11:00:25 -0700 (PDT)
Received: from njfpsrvexg6.research.att.com (njfpsrvexg6.research.att.com [135.207.177.28]) by mail-green.research.att.com (Postfix) with ESMTP id 0EBE4844E; Fri, 29 Apr 2011 14:00:25 -0400 (EDT)
Received: from njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b]) by njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b%10]) with mapi; Fri, 29 Apr 2011 14:01:50 -0400
From: "NOEL, ERIC C (ERIC C)" 
To: Volker Hilt 
Date: Fri, 29 Apr 2011 14:02:30 -0400
Thread-Topic: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
Thread-Index: AcwGjKxHgRUA/3g8R6OLbzHuwqQjYQAAEktg
Message-ID: <2F8FB48C17221643AD77FA295756D2A71E23562E69@njfpsrvexg6.research.att.com>
References:  <4DBA1D11.7030001@alcatel-lucent.com> <2F8FB48C17221643AD77FA295756D2A71E23562CF2@njfpsrvexg6.research.att.com> <4DBAEA7B.2020203@alcatel-lucent.com>
In-Reply-To: <4DBAEA7B.2020203@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sip-overload@ietf.org" 
Subject: Re: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2011 18:00:27 -0000

Volker,

I believe the issue is independent of SIP, if the offered load at client "s=
ignificantly" surges over a period of time period "much shorter" than the o=
verloaded server feedback period, then applying % blocking at the client wi=
ll not work "as well as" applying rate control.

Within the scope of our simulation models, that would be equivalent to the =
transients associated with step like offered load we looked at.  But if I r=
emember well, we never looked at the controlled load out of the clients, we=
 always focused on the overloaded element goodput and we all implemented pe=
rcent blocking in the client.

Unfortunately, I have not run simulations to compare both throttling method=
s so I can only provide qualitative statements.=20

Though, note that I always assumed the feedback period from the overloaded =
element to be short enough to nullify the issue, hence ignoring the issue.

Thanks,

Eric Noel=20
LMTS
AT&T Labs, Inc.=20
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
ecnoel@att.com

-----Original Message-----
From: Volker Hilt [mailto:volker.hilt@alcatel-lucent.com]=20
Sent: Friday, April 29, 2011 12:43 PM
To: NOEL, ERIC C (ERIC C)
Cc: sip-overload@ietf.org
Subject: Re: [sip-overload] Proposal: Support for the restriction algorithm=
s should be mandatory for clients (draft-ietf-soc-overload-control-02)

Eric,

what makes you think the problems described in this paper apply to SIP=20
overload control? None of the simulations (including yours) did show=20
problems with loss-based control. Do you have results that replicate=20
these issues in a SIP network? What is missing?

Volker

On 4/29/2011 8:56 AM, NOEL, ERIC C (ERIC C) wrote:
> Volker,
>
> Wrt Phil's comment on vulnerability to sudden increases on the
> offered load at client sources, I believe the paper from Arthur
> Berger in IEEE Transactions on Automatic Control Vol 36, No2,
> February 1991 titled "Overload Control Using Rate Control: Selecting
> Token Bank Capacity for Robustness to Arrival Rates" supports that
> observation.
>
> In that paper, Figure 3 compares rate control to call gapping and to
> percent blocking. As offered load increases, rate control is the only
> algorithm that controls load close to the target. Basically Phil's
> point.
>
> Because it is a copyrighted document, I do not think I can broadcast
> on distribution list. However, if you cannot get a copy of the paper
> let me know and I will assist you.
>
> Thanks,
>
> Eric Noel LMTS AT&T Labs, Inc. Rethink Possible
>
> Network Design and Performance Analysis 200 South Laurel Avenue,
> D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com
>
>
> -----Original Message----- From: sip-overload-bounces@ietf.org
> [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt Sent:
> Thursday, April 28, 2011 10:06 PM To: sip-overload@ietf.org Subject:
> Re: [sip-overload] Proposal: Support for the restriction algorithms
> should be mandatory for clients (draft-ietf-soc-overload-control-02)
>
> Phil,
>
>> SIP support for 3 restriction algorithms at client sources defined
>> in soc-overload-control-02 is beneficial for the flexibility that
>> it provides to potentially support a wide range of server overload
>> controls and network applications. However, making proportional
>> restriction, termed a 'loss-based' algorithm, mandatory for clients
>> would severely limit the usefulness of this approach. I will
>> summarise the reasons for this and why this algorithm has limited
>> use in future generations of networks below. Practical issues
>> ----------------------- If client system suppliers are only
>> required to support proportional restriction, then realistically it
>> is likely that that is the only algorithm that will be provided by
>> default, and the other algorithms will be seen as chargeable
>> enhancements, making it difficult or expensive to deploy them. But,
>> of the two functional ends of a closed adaptive overload control,
>> it is the algorithm on the overloaded server that derives the
>> control parameter that is not standardised and has dependency on
>> node architecture, whereas the 3 client restriction algorithms are
>> less subject to design variation, have been around for a long time,
>> and are already widely deployed. Therefore we would expect it to be
>> less contentious to standardise these methods within SIP, but in
>> any case we would expect less sensitivity to design variations. It
>> is not realistic to envisage a situation whereby an overloaded
>> server supports several different client restriction algorithms
>> simultaneously, because of the complexity in design of the
>> algorithm, and because even if a unique solution is guaranteed,
>> there will be issues of both speed of convergence to that solution,
>> stability, and the need for the server capacity amongst upstream
>> clients to be allocated in a predictable and precise way. This has
>> implications for capacity guarantees, particularly at network
>> boundaries (see below). If support for the 3 different restriction
>> algorithms (or at least the 2 in which we are interested) is
>> mandated by the IETF rather than being optional, then a server
>> subject to overload can guarantee that the sending entities will
>> all use the same restriction algorithms, and can behave as
>> predicted.
>
> So you are arguing that a client should always implement the full set
> of restriction algorithms (e.g., loss, rate and window)?
>
> If we would mandate that, we would loose the possibility to extend
> the feedback types at a later point. And, of course, we add the
> complexity of requiring clients to implement multiple algorithms that
> to the same.
>
>> Performance imitations ---------------------------------- The main
>> performance limitation of proportional restriction is that it is
>> vulnerable to sudden increases on the offered load at client
>> sources, since the mean admitted rate after control is proportional
>> to the mean arrival rate before control until an adaptation of the
>> control parameter is made. But there will always be a delay to this
>> control adaptation (at least in the closed loop method implied by
>> the current specification), both because of the need for waiting
>> sufficiently long at the overloaded server in order to obtain
>> statistically accurate estimates before an adaptation is made, and
>> the time and number of received messages required to distribute
>> control to the clients.
>
> Can you please point us to results that show this behavior?
>
> I'd also recommend to look at the results of the SIP overload
> control design team that has investigated this problem.
>
>> This vulnerability is worse when the number of clients is 'large'
>> with a high capacity relative to the server. In contrast, a maximum
>> rate-based control is generally not so vulnerable to short term
>> surges in load.
>
> A rate based mechanism needs to split its capacity across upstream
> neighbors. If new clients arrive, the split has to be adjusted. In
> particular if you are dealing with a large set of clients some of
> which may be inactive for some time, this requires a quick
> readjustment of the allocated capacity. This topic has been
> discussion in the design considerations draft.
>
>> The need to support precise capacity guarantees
>> ------------------------------------------------------------------------
>>
>>
It is common practice for agreements concerning capacity to be provided
>> at network operator boundaries [from now on I'll use SP or Service
>> Provider as a generic term encompassing Operators etc], and in
>> many realistic applications this is essential (I recall that his
>> requirement is absent from the original list of SIP overload
>> control requirements?). It is also possible to want to provide
>> guarantees to sub-streams of SP traffic. These guarantees must be
>> practically useful, so that they can form the basis of a service
>> level agreement between SPs. I.e. they must be simple enough to be
>> easily understood by all parties, and above all they must be clear
>> and precise in the sense that the behaviour of the capacity is
>> predictable/deterministic (in a stochastic sense). SPs are not
>> interested in technicalities of restriction algorithms, but will
>> want the policies to be defined in terms of traffic characteristics
>> that are straightforward to interpret and agree. Clearly the
>> policies must also be efficient in the sense that imply that the
>> available capacity can be fully utilised. I suggest that these are
>> most easily expressed as a guaranteed minimum rate and a precise
>> way in which 'spare' capacity not being used by a client originated
>> stream is distributed over the other SPs, e.g. in terms of maximum
>> rates determined by agreed proportions of the available unused
>> allowances. Of course other policies are possible (but they may be
>> less precise or more complex). Whatever policies are chosen,
>> realising this is an inherent part of the server overload control,
>> but the difficulty and complexity is dependent upon the method of
>> call restriction is the clients. With proportional restriction,
>> note that the percentages have nothing directly to do with the
>> proportions of server capacity allocated to different clients. So
>> there is no natural and simple way to map between the parameters of
>> the agreement and the control parameters. If the same control level
>> were applied to all client traffic, then the changes in the offered
>> traffic from one client will always imply changes to the traffic
>> admitted by another, (and in particular this applies to sudden
>> large increases). To apply maximum rate-based guarantees would
>> require monitoring of the received rate from each source separately
>> in order that the offered traffic can be derived implicitly and
>> thereby percentages derived for each specific source. In contrast,
>> with a rate-based restriction, it is much simpler to implement
>> policies defined in terms of maximum rates, even though these are
>> adapted according to minimum guarantees and use of unused
>> allowances in a precise and predictable way.
>
> I don't think overload control is the right tool to police SLAs.
>
> Let's assume for a second you are in fact using overload control for
> this purpose and are configuring your overload control rates to
> match your SLAs. Say you have two servers A and B (each with capacity
> 500 req/s) and four upstream neighbors. The SLA with each of them is
> that you accept 250 req/s.
>
> If one of your servers goes down, your capacity is cut in half. If
> you have configured overload control to honor you SLAs, your
> remaining server will melt down within ms. Your only choice to
> survive this situation is to use overload control and cut the rates
> below the SLA.
>
> Thanks,
>
> Volker (as individual)
>
>
>
>
>> Comments please! Phil Williams
> _______________________________________________ sip-overload mailing
> list sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>From:	ken carlberg <carlberg@g11.org.uk>
<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>To:=	sip-overload@ietf.org
<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Date:	04/17/2011 03:38 PM
<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Subject:	[sip-overload] draft-ietf-soc-overload-design-05<= /span>

From:	ken carlberg <carlberg@g11.org.uk>
To:	sip-overload@ietf.org
Date:	04/17/2011 03:38 PM
Subject:	[sip-overload] draft-ietf-soc-overload-design-05

From:	Volker Hilt <volker.hilt@alcatel-lucent.com>
To:	Janet P Gunn/USA/CSC@CSC
Cc:	"sip-overload@ietf.org" <sip-overload@ietf.org>
Date:	04/18/2011 09:23 PM
Subject:	Re: [sip-overload] draft-ietf-soc-overload-design-05

From:	ken carlberg <carlberg@g11.org.uk>
To:	sip-overload@= ietf.org
Date:	04/17/2011 03:38 PM
Subject:=	[sip-overload] draft-ietf-soc-overload-design-05

From:	ken carlberg <carlberg@g11.org.uk>
To:	= sip-overload@ietf.org
Date:	04/17/2011 03:38 PM
Subject:=	[sip-overload] draft-ietf-soc-overload-design-05