[sip-overload] Fw: minutes: SoC meeting at IETF81

[Janet P Gunn <[e-mail]>]

----- Forwarded by Janet P Gunn/USA/CSC on 08/01/2011 05:48 PM -----

From:
Janet P Gunn/USA/CSC
To:
Salvatore Loreto <[e-mail]>
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



[e-mail] wrote on 08/01/2011 09:16:16 AM:

> From:
> 
> Salvatore Loreto <[e-mail]>
> 
> To:
> 
> "[e-mail]" <[e-mail]>
> 
> Cc:
> 
> Volker Hilt <[e-mail]>
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload