============================ 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)