From salvatore.loreto@ericsson.com Mon Aug 1 06:16:15 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 1C61C11E80A0 for ; Mon, 1 Aug 2011 06:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qyekCgHuZRTd for ; Mon, 1 Aug 2011 06:16:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2043711E8091 for ; Mon, 1 Aug 2011 06:16:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-2c-4e36a721f719 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 43.20.20773.127A63E4; Mon, 1 Aug 2011 15:16:18 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 1 Aug 2011 15:16:17 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 88ECD245F; Mon, 1 Aug 2011 16:16:17 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4F9CA51273; Mon, 1 Aug 2011 16:16:17 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E70E351195; Mon, 1 Aug 2011 16:16:16 +0300 (EEST) Message-ID: <4E36A720.7070506@ericsson.com> Date: Mon, 1 Aug 2011 16:16:16 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 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: SoC meeting at IETF81 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: Mon, 01 Aug 2011 13:16:15 -0000 Hi there, here the minutes draft version from SoC meeting at IETF81. Please review the minutes and send any correction to the chairs by Monday August 25th, as the "proceeding submission cutoff" is Friday August 29th. Special thank to Keith and Shida to collect the notes during the meetings. cheers /Sal --- Salvatore Loreto www.sloreto.com ============================ SoC note from the meeting Tuesday, July 26th, 2011 15:20 - 17:00 Afternoon Session II Note Taker : Keith Drage and Shida Schubert ============================ *Action Items* =============== - Chairs: Update the milestones based on what is realistic to happen in terms of date. - Vijay: updates the draft based on the way forward by end of August. - Eric Noel and other: to submit a new draft - Hadriel and Paul will provide comments on overload-package draft on ML. - Event package draft needs to describe how the mechanism plays out for inter/intra-provider scenario. - It was suggested that Paul submit additional requirements to be added to rate-based algorithm draft on ML. Administrative/Agenda bash (Chairs - 10m) ======================================================================== Overload design is in RFC editors queue. Have adopted load control event package as WG item. Goals and milestones will be reviewed by the chairs to reflect what is likely to happen. Update on overload design. In AD review. Summary of review results. Thanks to all reviews. SIP Overload Control (Vijay - 50m) ======================================================================= (draft-ietf-soc-overload-control-02) Main issue identified at agenda bash: Close open issues on type of feedback. Summary of where are we at. There are 3 classes of algorithm and they all give similar results. Certain algorithms are easier to implement. - Confusion among definition of client/server. - All entities participating will play both roles. Proposal made on list to support all three. Disadvantage of forcing implementations to implement all 3 even if they want only one. Advantage is that no negotiation is needed. Shida: Is rate-based mandatory to implement? Vijay: No. Volker: Client needs to implement all 3, server only one. Hadriel: Clarification requested on server versus client. Hadriel: Proxy needs to implement all three because it is both client and server. Dale: What do you mean by sender/receiver/server/client. Volker: Upstream entity needs to implement all 3. Robert: Most boxes will have to be both. Second proposal is to have one mandatory to implement feedback type and then negotiate additional ones if desired. Keith: What do you need to implement for rate-only and loss-only? Vijay: For loss-only the base spec, for rate-only you need to implement both. Paul: From the sevice provider's point of view, rate-base is better, but it is difficult to have implementors to implement both. But better than previous proposals with 3 algorithms. Volker: Loss-base makes more sense for the Internet, Rate-base seems more suitable for managed network. *Possible additional solution* is to take the windows mechanism out, and make loss based part of this spec. Plus additional document to make rate based a specified mechanism. This to use loss only, one has to implement only loss based. To use rate based, one must implement both loss based and rate based. The main document is mandatory to implement. Paul: Comparison of getting vendors to implement and test two mechanisms versus only one mechanism. *HUM* for which result was to use additional solution above. Way Forward slide presented by Vijay. Need authors for the additional i-d for the rate based one: Eric Noel as one of the possible editors. A new milestone will not be introduced for the additional draft. Chairs: What about the milestone for the rate-base draft? Robert: Two drafts for one milestone is fine, no new milestone is needed. Chairs: When would the update be expected? Vijay: By the end of August. SIP Load Control Event Package (Arata Koike - 20m) ============================================================================= (draft-ietf-soc-load-control-event-package-00) Requirement 1: Paul: Requirements set did not match what it had been evaluated against. Also the requirements set is not complete either. Paul: Question on "throttle too much or too little". Answer that it may exhibit oscillatory behaviour. Requirement 2: Paul: Static side is inflexible from a service provider viewpoint. Volker as Chair: Do we need to go through the whole requirements? Rober: Get comments from those who read the draft Open mic for comments: Paul: Will email comments. Hadriel: General comments on interprovider aspects which seems unlikely to him to work from a security perspective. Filter values and some other things are tricky to do. Back to first point: How much is focussed on interprovider versus intraprovider. Arata: Covers both. Key focus in the intraprovider. Hadriel: Key problem is how to target some of these subscriptions, so how do you identify edge proxies and how they push the subscription on. Edge proxy etc. would not usually have URI to subscribe etc, proxy inside the network won't be exposed. Arata: All based on configuration so you can do anything. Hadriel: It's ultimately a provisioning and doing the provisioning in-band of the path to be prioritized is not a good idea.(Hadriel) Arata: We don't exclude filter be exchanged out-of-band.(Arata) Paul: If there are both algorithm (feedback/filter) in effect, which one wins? Volker: Tighter one should win. Sol: How will the filter be honored? Arata: Algorithm is not be defined here. Paul: Supportive of approach being advocated - looks good, robust and scalable. How does it interplay with existing priority mechanisms in the system. Hadriel: Summarised this as a provisioning mechanism, and therefore done out of band. Many times done on different protocol so done on different ports. Sohal: ATM had flow control mechanism and ATM forum kept open the solution for flow control and did not define one. This was a mess. Question of whether this defines an algorithm. Chair asked that Hadriel and Paul send the comments for overload package on the ML. Open Discussion (All - 20m) ====================================================================== Paul: Knows not describing algorithms, but based on requirement here will presumably draw from RFC 3550. Need to bolster requirements to implement the rate based mechanism. Volker: The requirements (RFC5390) are independent of an algorithm. (Volker) Paul: Think additional specific requirements are needed for rate-based mechanism, where should it be added? Salvatore as Chair: Probably best to include it (additional requirements) in the draft that will describe the rate-based algorithm; send them to the list. Janet: Should address inter-provider cases. Volker: Should describe how they play out in both scenarios for inter and intra-provider. Paul: Have you looked at how this mechanism will apply on IMS etc.? Martin: ATIS is looking at this. (Martin) From jgunn6@csc.com Mon Aug 1 14:49:22 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 4BF971F0C57 for ; Mon, 1 Aug 2011 14:49:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GYtvXk9R9tu for ; Mon, 1 Aug 2011 14:49:20 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 28CFC1F0C4E for ; Mon, 1 Aug 2011 14:49:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-85.messagelabs.com!1312235365!19221039!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 18991 invoked from network); 1 Aug 2011 21:49:26 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2011 21:49:26 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p71LnOUb031077 for ; Mon, 1 Aug 2011 17:49:25 -0400 To: sip-overload@ietf.org MIME-Version: 1.0 X-KeepSent: 770C7530:23B82EE2-852578DF:0077D577; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP1 SHF139 March 01, 2011 From: Janet P Gunn Message-ID: Date: Mon, 1 Aug 2011 17:49:22 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 08/01/2011 05:47:43 PM, Serialize complete at 08/01/2011 05:47:43 PM Content-Type: multipart/alternative; boundary="=_alternative 0077DF93852578DF_=" Subject: [sip-overload] Fw: minutes: SoC meeting at IETF81 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: Mon, 01 Aug 2011 21:49:22 -0000 This is a multipart message in MIME format. --=_alternative 0077DF93852578DF_= Content-Type: text/plain; charset="US-ASCII" ----- Forwarded by Janet P Gunn/USA/CSC on 08/01/2011 05:48 PM ----- From: Janet P Gunn/USA/CSC To: Salvatore Loreto Date: 08/01/2011 02:33 PM Subject: Re: [sip-overload] minutes: SoC meeting at IETF81 A minor correction, as my comment was taken out of context- hardly surprising as I was using streaming audio and jabber, and by the time my jabber message was noticed the conversation had moved on. My comment was in response to " Hadriel: General comments on interprovider aspects which seems > unlikely to him to work from a security perspective. Filter values > and some other things are tricky to do. Back to first point: How > much is focussed on interprovider versus intraprovider. > > Arata: Covers both. Key focus in the intraprovider." I said that, if the focus is on "intraprovider", then the notation for Req 12 ("The mechanism should work between servers in different domains.") should probably be "N", or "Not Applicable". It should not be "yes" as in the presentation slides. Janet sip-overload-bounces@ietf.org wrote on 08/01/2011 09:16:16 AM: > From: > > Salvatore Loreto > > To: > > "sip-overload@ietf.org" > > Cc: > > Volker Hilt > > Date: > > 08/01/2011 09:19 AM > > Subject: > > [sip-overload] minutes: SoC meeting at IETF81 > > Hi there, > > here the minutes draft version from SoC meeting at IETF81. > Please review the minutes and send any correction to the chairs by > Monday August 25th, > as the "proceeding submission cutoff" is Friday August 29th. > > Special thank to Keith and Shida to collect the notes during the meetings. > > > cheers > /Sal > > --- > Salvatore Loreto > www.sloreto.com > > > > > ============================ > SoC note from the meeting > > Tuesday, July 26th, 2011 > 15:20 - 17:00 Afternoon Session II > Note Taker : Keith Drage and Shida Schubert > > ============================ > > *Action Items* > =============== > - Chairs: Update the milestones based on what is realistic to > happen in terms of date. > - Vijay: updates the draft based on the way forward by end of August. > - Eric Noel and other: to submit a new draft > - Hadriel and Paul will provide comments on overload-package draft on ML. > - Event package draft needs to describe how the mechanism plays > out for inter/intra-provider scenario. > - It was suggested that Paul submit additional requirements to be > added to rate-based algorithm draft on ML. > > > > > Administrative/Agenda bash (Chairs - 10m) > ======================================================================== > > Overload design is in RFC editors queue. > > Have adopted load control event package as WG item. > > Goals and milestones will be reviewed by the chairs to reflect what > is likely to happen. > > Update on overload design. In AD review. Summary of review results. > Thanks to all reviews. > > > > SIP Overload Control (Vijay - 50m) > ======================================================================= > (draft-ietf-soc-overload-control-02) > > Main issue identified at agenda bash: Close open issues on type of feedback. > > Summary of where are we at. There are 3 classes of algorithm and > they all give similar results. Certain algorithms are easier to implement. > - Confusion among definition of client/server. > - All entities participating will play both roles. > > Proposal made on list to support all three. Disadvantage of forcing > implementations to implement all 3 even if they want only one. > Advantage is that no negotiation is needed. > > Shida: Is rate-based mandatory to implement? > Vijay: No. > > Volker: Client needs to implement all 3, server only one. > > Hadriel: Clarification requested on server versus client. > > Hadriel: Proxy needs to implement all three because it is both > client and server. > > Dale: What do you mean by sender/receiver/server/client. > > Volker: Upstream entity needs to implement all 3. > > Robert: Most boxes will have to be both. > > Second proposal is to have one mandatory to implement feedback type > and then negotiate additional ones if desired. > > Keith: What do you need to implement for rate-only and loss-only? > Vijay: For loss-only the base spec, for rate-only you need to implement both. > > > Paul: From the sevice provider's point of view, rate-base is better, > but it is difficult to have implementors to implement both. But > better than previous proposals with 3 algorithms. > > Volker: Loss-base makes more sense for the Internet, Rate-base seems > more suitable for managed network. > > > *Possible additional solution* is to take the windows mechanism out, > and make loss based part of this spec. Plus additional document to > make rate based a specified mechanism. This to use loss only, one > has to implement only loss based. To use rate based, one must > implement both loss based and rate based. The main document is > mandatory to implement. > > Paul: Comparison of getting vendors to implement and test two > mechanisms versus only one mechanism. > > *HUM* for which result was to use additional solution above. Way > Forward slide presented by Vijay. > > Need authors for the additional i-d for the rate based one: Eric > Noel as one of the possible editors. > > A new milestone will not be introduced for the additional draft. > > Chairs: What about the milestone for the rate-base draft? > Robert: Two drafts for one milestone is fine, no new milestone is needed. > > Chairs: When would the update be expected? > Vijay: By the end of August. > > > > SIP Load Control Event Package (Arata Koike - 20m) > ============================================================================= > (draft-ietf-soc-load-control-event-package-00) > > Requirement 1: > > Paul: Requirements set did not match what it had been evaluated > against. Also the requirements set is not complete either. > > Paul: Question on "throttle too much or too little". > > Answer that it may exhibit oscillatory behaviour. > > Requirement 2: > > Paul: Static side is inflexible from a service provider viewpoint. > > > Volker as Chair: Do we need to go through the whole requirements? > Rober: Get comments from those who read the draft > > > Open mic for comments: > > Paul: Will email comments. > > Hadriel: General comments on interprovider aspects which seems > unlikely to him to work from a security perspective. Filter values > and some other things are tricky to do. Back to first point: How > much is focussed on interprovider versus intraprovider. > > Arata: Covers both. Key focus in the intraprovider. > > > Hadriel: Key problem is how to target some of these subscriptions, > so how do you identify edge proxies and how they push the subscription on. > Edge proxy etc. would not usually have URI to subscribe etc, proxy > inside the network won't be exposed. > > > Arata: All based on configuration so you can do anything. > > > Hadriel: It's ultimately a provisioning and doing the provisioning > in-band of the path to be prioritized is not a good idea.(Hadriel) > Arata: We don't exclude filter be exchanged out-of-band.(Arata) > > Paul: If there are both algorithm (feedback/filter) in effect, whichone wins? > Volker: Tighter one should win. > > > Sol: How will the filter be honored? > Arata: Algorithm is not be defined here. > > > Paul: Supportive of approach being advocated - looks good, robust > and scalable. How does it interplay with existing priority > mechanisms in the system. > > Hadriel: Summarised this as a provisioning mechanism, and therefore > done out of band. Many times done on different protocol so done on > different ports. > > Sohal: ATM had flow control mechanism and ATM forum kept open the > solution for flow control and did not define one. This was a mess. > Question of whether this defines an algorithm. > > > Chair asked that Hadriel and Paul send the comments for overload > package on the ML. > > > > Open Discussion (All - 20m) > ====================================================================== > > Paul: Knows not describing algorithms, but based on requirement here > will presumably draw from RFC 3550. Need to bolster requirements to > implement the rate based mechanism. > > Volker: The requirements (RFC5390) are independent of an algorithm. (Volker) > > Paul: Think additional specific requirements are needed for rate- > based mechanism, where should it be added? > Salvatore as Chair: Probably best to include it (additional > requirements) in the draft that will describe the rate-based > algorithm; send them to the list. > > Janet: Should address inter-provider cases. > Volker: Should describe how they play out in both scenarios for > inter and intra-provider. > > Paul: Have you looked at how this mechanism will apply on IMS etc.? > Martin: ATIS is looking at this. (Martin) > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 0077DF93852578DF_= Content-Type: text/html; charset="US-ASCII"

----- Forwarded by Janet P Gunn/USA/CSC on 08/01/2011 05:48 PM -----
From: Janet P Gunn/USA/CSC
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
Date: 08/01/2011 02:33 PM
Subject: Re: [sip-overload] minutes: SoC meeting at IETF81




A minor correction, as my comment was taken out of context- hardly surprising as I was using streaming audio and jabber, and by the time my jabber message was noticed the conversation had moved on.

My comment was in response to
" Hadriel: General comments on interprovider aspects which seems
> unlikely to him to work from a security perspective. Filter values
> and some other things are tricky to do. Back to first point: How
> much is focussed on interprovider versus intraprovider.
>
> Arata: Covers both. Key focus in the intraprovider."
I said that, if the focus is on "intraprovider", then the  notation for Req 12  ("The mechanism should work between servers in different domains.") should probably be "N", or "Not Applicable".  It should not be "yes" as in the presentation slides.

Janet



sip-overload-bounces@ietf.org wrote on 08/01/2011 09:16:16 AM:

> From:
>
> Salvatore Loreto <salvatore.loreto@ericsson.com>
>
> To:
>
> "sip-overload@ietf.org" <sip-overload@ietf.org>
>
> Cc:
>
> Volker Hilt <volker.hilt@alcatel-lucent.com>
>
> Date:
>
> 08/01/2011 09:19 AM
>
> Subject:
>
> [sip-overload] minutes: SoC meeting at IETF81
>
> Hi there,
>
> here the minutes draft version from SoC meeting at IETF81.
> Please review the minutes and send any correction to the chairs by
> Monday August 25th,
> as the "proceeding submission cutoff" is Friday August 29th.
>
> Special thank to Keith and Shida to collect the notes during the meetings.
>
>
> cheers
> /Sal
>
> ---
> Salvatore Loreto
> www.sloreto.com
>
>
>
>
> ============================
> SoC note from the meeting
>
>    Tuesday, July 26th, 2011
>    15:20 - 17:00 Afternoon Session II
>    Note Taker : Keith Drage and Shida Schubert
>
> ============================
>
> *Action Items*
> ===============
>   - Chairs: Update the milestones based on what is realistic to
> happen in terms of date.
>   - Vijay: updates the draft based on the way forward by end of August.
>   - Eric Noel and other: to submit a new draft
>   - Hadriel and Paul will provide comments on overload-package draft on ML.
>   - Event package draft needs to describe how the mechanism plays
> out for inter/intra-provider scenario.
>   - It was suggested that Paul submit additional requirements to be
> added to rate-based algorithm draft on ML.
>
>
>
>
> Administrative/Agenda bash                                (Chairs - 10m)
> ========================================================================
>
> Overload design is in RFC editors queue.
>
> Have adopted load control event package as WG item.
>
> Goals and milestones will be reviewed by the chairs to reflect what
> is likely to happen.
>
> Update on overload design. In AD review. Summary of review results.
> Thanks to all reviews.
>
>
>
> SIP Overload Control                                      (Vijay - 50m)
> =======================================================================
> (draft-ietf-soc-overload-control-02)
>
> Main issue identified at agenda bash: Close open issues on type of feedback.
>
> Summary of where are we at. There are 3 classes of algorithm and
> they all give similar results. Certain algorithms are easier to implement.
> - Confusion among definition of client/server.
> - All entities participating will play both roles.
>
> Proposal made on list to support all three. Disadvantage of forcing
> implementations to implement all 3 even if they want only one.
> Advantage is that no negotiation is needed.
>
> Shida: Is rate-based mandatory to implement?
> Vijay: No.
>
> Volker: Client needs to implement all 3, server only one.
>
> Hadriel: Clarification requested on server versus client.
>
> Hadriel: Proxy needs to implement all three because it is both
> client and server.
>
> Dale: What do you mean by sender/receiver/server/client.
>
> Volker: Upstream entity needs to implement all 3.
>
> Robert: Most boxes will have to be both.
>
> Second proposal is to have one mandatory to implement feedback type
> and then negotiate additional ones if desired.
>
> Keith: What do you need to implement for rate-only and loss-only?
> Vijay: For loss-only the base spec, for rate-only you need to implement both.
>
>
> Paul: From the sevice provider's point of view, rate-base is better,
> but it is difficult to have implementors to implement both. But
>        better than previous proposals with 3 algorithms.
>
> Volker: Loss-base makes more sense for the Internet, Rate-base seems
> more suitable for managed network.
>
>
> *Possible additional solution* is to take the windows mechanism out,
> and make loss based part of this spec. Plus additional document to
> make rate based a specified mechanism. This to use loss only, one
> has to implement only loss based. To use rate based, one must
> implement both loss based and rate based. The main document is
> mandatory to implement.
>
> Paul: Comparison of getting vendors to implement and test two
> mechanisms versus only one mechanism.
>
> *HUM* for which result was to use additional solution above. Way
> Forward slide presented by Vijay.
>
> Need authors for the additional i-d for the rate based one: Eric
> Noel as one of the possible editors.
>
> A new milestone will not be introduced for the additional draft.
>
> Chairs: What about the milestone for the rate-base draft?
> Robert: Two drafts for one milestone is fine, no new milestone is needed.
>
> Chairs: When would the update be expected?
> Vijay: By the end of August.
>
>
>
> SIP Load Control Event Package                            (Arata Koike - 20m)
> =============================================================================
> (draft-ietf-soc-load-control-event-package-00)
>
> Requirement 1:
>
> Paul: Requirements set did not match what it had been evaluated
> against. Also the requirements set is not complete either.
>
> Paul: Question on "throttle too much or too little".
>
> Answer that it may exhibit oscillatory behaviour.
>
> Requirement 2:
>
> Paul: Static side is inflexible from a service provider viewpoint.
>
>
> Volker as Chair: Do we need to go through the whole requirements?
> Rober: Get comments from those who read the draft
>
>
> Open mic for comments:
>
> Paul: Will email comments.
>
> Hadriel: General comments on interprovider aspects which seems
> unlikely to him to work from a security perspective. Filter values
> and some other things are tricky to do. Back to first point: How
> much is focussed on interprovider versus intraprovider.
>
> Arata: Covers both. Key focus in the intraprovider.
>
>
> Hadriel: Key problem is how to target some of these subscriptions,
> so how do you identify edge proxies and how they push the subscription on.
> Edge proxy etc. would not usually have URI to subscribe etc, proxy
> inside the network won't be exposed.
>
>
> Arata: All based on configuration so you can do anything.
>
>
> Hadriel: It's ultimately a provisioning and doing the provisioning
> in-band of the path to be prioritized is not a good idea.(Hadriel)
> Arata: We don't exclude filter be exchanged out-of-band.(Arata)
>
> Paul: If there are both algorithm (feedback/filter) in effect, whichone wins?
> Volker: Tighter one should win.
>
>
> Sol: How will the filter be honored?
> Arata: Algorithm is not be defined here.
>
>
> Paul: Supportive of approach being advocated - looks good, robust
> and scalable. How does it interplay with existing priority
> mechanisms in the system.
>
> Hadriel: Summarised this as a provisioning mechanism, and therefore
> done out of band. Many times done on different protocol so done on
> different ports.
>
> Sohal: ATM had flow control mechanism and ATM forum kept open the
> solution for flow control and did not define one. This was a mess.
> Question of whether this defines an algorithm.
>
>
> Chair asked that Hadriel and Paul send the comments for overload
> package on the ML.
>
>
>
> Open Discussion                                            (All - 20m)
> ======================================================================
>
> Paul: Knows not describing algorithms, but based on requirement here
> will presumably draw from RFC 3550. Need to bolster requirements to
> implement the rate based mechanism.
>
> Volker: The requirements (RFC5390) are independent of an algorithm. (Volker)
>
> Paul: Think additional specific requirements are needed for rate-
> based  mechanism, where should it be added?
> Salvatore as Chair: Probably best to include it (additional
> requirements) in the draft that will describe the rate-based
> algorithm; send them to the list.
>
> Janet: Should address inter-provider cases.
> Volker: Should describe how they play out in both scenarios for
> inter and intra-provider.
>
> Paul: Have you looked at how this mechanism will apply on IMS etc.?
> Martin: ATIS is looking at this. (Martin)
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
--=_alternative 0077DF93852578DF_=-- From salvatore.loreto@ericsson.com Wed Aug 3 00:50:25 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 A78D121F8B2E for ; Wed, 3 Aug 2011 00:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 dYf4etQGJq9z for ; Wed, 3 Aug 2011 00:50:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 25BDA21F8777 for ; Wed, 3 Aug 2011 00:50:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a9-4e38fdc9a42a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.D1.20773.9CDF83E4; Wed, 3 Aug 2011 09:50:33 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 3 Aug 2011 09:50:32 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9BE802461 for ; Wed, 3 Aug 2011 10:50:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 62F525129D for ; Wed, 3 Aug 2011 10:50:32 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1DF6350A15 for ; Wed, 3 Aug 2011 10:50:32 +0300 (EEST) Message-ID: <4E38FDC7.8030604@ericsson.com> Date: Wed, 3 Aug 2011 10:50:31 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4E36A720.7070506@ericsson.com> In-Reply-To: <4E36A720.7070506@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [sip-overload] minutes v2: SoC meeting at IETF81 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, 03 Aug 2011 07:50:25 -0000 Hi there, here the second version of the minutes from SoC meeting at IETF81. Thanks a lot to Janet to provide feedback/correction. Please review the minutes and send any correction to the chairs by Monday August 25th, as the "proceeding submission cutoff" is Friday August 29th. Special thank to Keith and Shida to collect the notes during the meetings. cheers /Sal --- Salvatore Loreto www.sloreto.com ============================ SoC note from the meeting Tuesday, July 26th, 2011 15:20 - 17:00 Afternoon Session II Note Taker : Keith Drage and Shida Schubert ============================ *Action Items* =============== - Chairs: Update the milestones based on what is realistic to happen in terms of date. - Vijay: updates the draft based on the way forward by end of August. - Eric Noel and other: to submit a new draft - Hadriel and Paul will provide comments on overload-package draft on ML. - Event package draft needs to describe how the mechanism plays out for inter/intra-provider scenario. - It was suggested that Paul submit additional requirements to be added to rate-based algorithm draft on ML. Administrative/Agenda bash (Chairs - 10m) ======================================================================== Overload design is in RFC editors queue. Have adopted load control event package as WG item. Goals and milestones will be reviewed by the chairs to reflect what is likely to happen. Update on overload design. In AD review. Summary of review results. Thanks to all reviews. SIP Overload Control (Vijay - 50m) ======================================================================= (draft-ietf-soc-overload-control-02) Main issue identified at agenda bash: Close open issues on type of feedback. Summary of where are we at. There are 3 classes of algorithm and they all give similar results. Certain algorithms are easier to implement. - Confusion among definition of client/server. - All entities participating will play both roles. Proposal made on list to support all three. Disadvantage of forcing implementations to implement all 3 even if they want only one. Advantage is that no negotiation is needed. Shida: Is rate-based mandatory to implement? Vijay: No. Volker: Client needs to implement all 3, server only one. Hadriel: Clarification requested on server versus client. Hadriel: Proxy needs to implement all three because it is both client and server. Dale: What do you mean by sender/receiver/server/client. Volker: Upstream entity needs to implement all 3. Robert: Most boxes will have to be both. Second proposal is to have one mandatory to implement feedback type and then negotiate additional ones if desired. Keith: What do you need to implement for rate-only and loss-only? Vijay: For loss-only the base spec, for rate-only you need to implement both. Paul: From the sevice provider's point of view, rate-base is better, but it is difficult to have implementors to implement both. But better than previous proposals with 3 algorithms. Volker: Loss-base makes more sense for the Internet, Rate-base seems more suitable for managed network. *Possible additional solution* is to take the windows mechanism out, and make loss based part of this spec. Plus additional document to make rate based a specified mechanism. This to use loss only, one has to implement only loss based. To use rate based, one must implement both loss based and rate based. The main document is mandatory to implement. Paul: Comparison of getting vendors to implement and test two mechanisms versus only one mechanism. *HUM* for which result was to use additional solution above. Way Forward slide presented by Vijay. Need authors for the additional i-d for the rate based one: Eric Noel as one of the possible editors. A new milestone will not be introduced for the additional draft. Chairs: What about the milestone for the rate-base draft? Robert: Two drafts for one milestone is fine, no new milestone is needed. Chairs: When would the update be expected? Vijay: By the end of August. SIP Load Control Event Package (Arata Koike - 20m) ============================================================================= (draft-ietf-soc-load-control-event-package-00) Requirement 1: Paul: Requirements set did not match what it had been evaluated against. Also the requirements set is not complete either. Paul: Question on "throttle too much or too little". Answer that it may exhibit oscillatory behaviour. Requirement 2: Paul: Static side is inflexible from a service provider viewpoint. Volker as Chair: Do we need to go through the whole requirements? Rober: Get comments from those who read the draft Open mic for comments: Paul: Will email comments. Hadriel: General comments on interprovider aspects which seems unlikely to him to work from a security perspective. Filter values and some other things are tricky to do. Back to first point: How much is focussed on interprovider versus intraprovider. Arata: Covers both. Key focus in the intraprovider. Janet: if the focus is on "intraprovider", then the notation for Req 12 ("The mechanism should work between servers in different domains.") should probably be "N", or "Not Applicable". It should not be "yes" as in the presentation slides. Hadriel: Key problem is how to target some of these subscriptions, so how do you identify edge proxies and how they push the subscription on. Edge proxy etc. would not usually have URI to subscribe etc, proxy inside the network won't be exposed. Arata: All based on configuration so you can do anything. Hadriel: It's ultimately a provisioning and doing the provisioning in-band of the path to be prioritized is not a good idea.(Hadriel) Arata: We don't exclude filter be exchanged out-of-band.(Arata) Paul: If there are both algorithm (feedback/filter) in effect, which one wins? Volker: Tighter one should win. Sol: How will the filter be honored? Arata: Algorithm is not be defined here. Paul: Supportive of approach being advocated - looks good, robust and scalable. How does it interplay with existing priority mechanisms in the system. Hadriel: Summarised this as a provisioning mechanism, and therefore done out of band. Many times done on different protocol so done on different ports. Sohal: ATM had flow control mechanism and ATM forum kept open the solution for flow control and did not define one. This was a mess. Question of whether this defines an algorithm. Chair asked that Hadriel and Paul send the comments for overload package on the ML. Open Discussion (All - 20m) ====================================================================== Paul: Knows not describing algorithms, but based on requirement here will presumably draw from RFC 3550. Need to bolster requirements to implement the rate based mechanism. Volker: The requirements (RFC5390) are independent of an algorithm. (Volker) Paul: Think additional specific requirements are needed for rate-based mechanism, where should it be added? Salvatore as Chair: Probably best to include it (additional requirements) in the draft that will describe the rate-based algorithm; send them to the list. Janet: Should address inter-provider cases. Volker: Should describe how they play out in both scenarios for inter and intra-provider. Paul: Have you looked at how this mechanism will apply on IMS etc.? Martin: ATIS is looking at this. (Martin) From phil.m.williams@bt.com Tue Aug 23 08:44:59 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 C365621F85F2 for ; Tue, 23 Aug 2011 08:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.971 X-Spam-Level: X-Spam-Status: No, score=-2.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+tujV7ZtUB7 for ; Tue, 23 Aug 2011 08:44:59 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id BFF5521F85CE for ; Tue, 23 Aug 2011 08:44:58 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 23 Aug 2011 16:46:06 +0100 Received: from EVMHT02-UKBR.domain1.systemhost.net (193.113.108.43) by EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 23 Aug 2011 16:46:05 +0100 Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.1.167]) by EVMHT02-UKBR.domain1.systemhost.net ([193.113.108.43]) with mapi; Tue, 23 Aug 2011 16:46:05 +0100 From: To: Date: Tue, 23 Aug 2011 16:45:55 +0100 Thread-Topic: Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity Thread-Index: Acxhq768aXwRR+/ZR8icaOn+l4FJjQ== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A5C57E13CEMV04UKBRdoma_" MIME-Version: 1.0 Subject: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity 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, 23 Aug 2011 15:44:59 -0000 --_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A5C57E13CEMV04UKBRdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I have proposed to the authors of draft-ietf-soc-load-control-event-package= -01 that Notifications of partial updates to control restriction parameters= and validity (only) should be supported. Currently the spec explicitly sta= tes that they are not, in 5.7.(Notifier Generation of NOTIFY Requests): ...This event package does not support notifications that contain deltas to= previous information or partial information. This proposal is fine with Charles Shen, so we agreed to open it up for gen= eral views. My reasoning follows. It would be common practice for updates to specific load control events to = be made frequently by changing the control restriction parameter informatio= n only (e.g. rate, percent), but not other rule elements, such as call-iden= tity. This will typically be because the utilisation of a resource subject = to overload depends upon dynamic unknowns such as holding time and the rela= tive distribution of offered load over subscribing SIP entities. The update= s could originate manually or be determined automatically. The latter is re= ferred to already in 4.2.(Filter Computation): ...it may be preferable to employ a dynamic load computation algorithm whic= h adapts to current network status, rather than using a purely static mecha= nism. The filter content computation algorithm is out of scope of this doc= ument. [Note: A rate-based control would generally need a lower frequency of updat= es even when adaptive than say a loss-based method because of the dependenc= e of the proportional method upon offered rates]. Another factor usually not known precisely or computed automatically is the= duration of the load control event. Therefore it would also be common for = the validity to change frequently. Not allowing partial updates could be a significant limitation to performan= ce when realised, since it makes such updates unnecessarily verbose. It wou= ld be a small enhancement to allow deltas which change the rate, win, or pe= rcent values of the action element, and the validity. They can be associate= d to the complete rule through the rule id. Regards, Phil Williams --_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A5C57E13CEMV04UKBRdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
I have proposed to the authors of draft-ietf-soc-load-control-event-pa= ckage-01 that Notifications of partial updates to control restriction param= eters and validity (only) should be supported. Currently the spec explicitl= y states that they are not, in 5.7.(Notifier Generation of NOTIFY Requests):
 
...This event package does not support = notifications that contain deltas to previous information or partial inform= ation.
 
This proposal is fine with Charles Shen, so we agreed to open it up fo= r general views. My reasoning follows.
 
It would be common practice for updates to specific load control event= s to be made frequently by changing the control restriction parameter infor= mation only (e.g. rate, percent), but not other rule elements, such as call= -identity. This will typically be because the utilisation of a resource subject to overload depends upon dyna= mic unknowns such as holding time and the relative distribution of offered = load over subscribing SIP entities. The updates could originate manually or= be determined automatically. The latter is referred to already in 4.2.(Filter Computation):
 
...it may be preferable to employ a dyn= amic load computation algorithm which adapts to current network status, rat= her than using a purely static mechanism.  The filter content computat= ion algorithm is out of scope of this document.
 
[Note: A rate-based control would generally need a lower frequency of = updates even when adaptive than say a loss-based method because of the depe= ndence of the proportional method upon offered rates].
 
Another factor usually not known precisely or computed automatically i= s the duration of the load control event. Therefore it would also be common= for the validity to change frequently.
 
Not allowing partial updates could be a significant limitation to perf= ormance when realised, since it makes such updates unnecessarily verbose. I= t would be a small enhancement to allow deltas which change the rate, win, = or percent values of the action element, and the validity. They can be associated to the complete rule thro= ugh the rule id.
 
Regards,
 
Phil Williams
 
 --_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A5C57E13CEMV04UKBRdoma_-- From wwwrun@rfc-editor.org Wed Aug 31 14:35:48 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 1C20821F8E7B; Wed, 31 Aug 2011 14:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP-yn6iAsePv; Wed, 31 Aug 2011 14:35:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A26D521F8E2E; Wed, 31 Aug 2011 14:35:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A538398C24E; Wed, 31 Aug 2011 14:36:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110831213657.A538398C24E@rfc-editor.org> Date: Wed, 31 Aug 2011 14:36:57 -0700 (PDT) Cc: sip-overload@ietf.org, rfc-editor@rfc-editor.org Subject: [sip-overload] RFC 6357 on Design Considerations for Session Initiation Protocol (SIP) Overload Control 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, 31 Aug 2011 21:35:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6357 Title: Design Considerations for Session Initiation Protocol (SIP) Overload Control Author: V. Hilt, E. Noel, C. Shen, A. Abdelal Status: Informational Stream: IETF Date: August 2011 Mailbox: volker.hilt@alcatel-lucent.com, eric.noel@att.com, charles@cs.columbia.edu, aabdelal@sonusnet.com Pages: 25 Characters: 64252 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-soc-overload-design-08.txt URL: http://www.rfc-editor.org/rfc/rfc6357.txt Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the SIP Overload Control Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC