DIME WG IETF 92 WEDNESDAY, March 25, 2015 0900-1130 Morning Session I (150 mins) Oak Chairs: Jouni Korhonen Lionel Morand Jabber room log: http://jabber.ietf.org/logs/dime ----------------------------------------------------------------------------- 0900 - 0915 (20 min) Preliminaries Presenter: Lionel Audio/Video & Remote Presentation Debugging Note Well Note Takers - Jean-Jacques Trottin, Jean Mahoney Jabber scribe - Jim Agenda bash Document Status o draft-ietf-dime-group-signaling-04 - expired, but lots of comments. Marco and Lionel will update draft and send out for WGLC in 2 weeks o draft-ietf-dime-congestion-flow-attributes-01 - waiting Proto write-up o draft-ietf-dime-ovli-08 - waiting Proto write-upG, IANA assignment done o draft-ietf-dime-e2e-sec-req-02 - going to WGLC Martin Dolly - e2e is interesting. In hallway conversations in 3GPP, there are no discussions of its usage. Do you know of any groups that will deploy this? This would be useful roaming between carriers. Jouni - I don't know of anyone requesting this. This work started years ago. Lionel - we've received informal requests from GSMA. Network between roaming partners. We will need to protect overload control. We need this mechanism over roaming interfaces. Steve Donovan - I commented on the doc this week on the list. I suggested adding a couple of requirements - must not encrypt routing headers, and identifying headers that must not be encrypted. Lionel - thanks for the review. I'll take a look at them. Can we start WGLC? Jouni - yes. Martin - o draft-ietf-dime-agent-overload-01 - in WG o draft-ietf-dime-doic-rate-control-01 - in WG Lionel - please comment on these new working group items. o draft-campbell-dime-load-considerations-01 - to be presented by Steve. o 4over6-provisioning-05 - adopt as working group item started in January - no comments, so adopted. Next step is WGLC. o draft-donovan-dime-drmp-00 - to be presented by Steve today. ----------------------------------------------------------------------------- 0915 - 0930 (15 min) Diameter Agent Overload Presenter: Steve Donovan Presentation: http://www.ietf.org/proceedings/92/slides/slides-92-dime-2.pptx Draft: draft-ietf-dime-agent-overload Steve presented. Slide 1 - Title Slide 2 - Agenda Slide 3 - New Report Type Slide 4 - Interaction with Host and Realm report types Slide 5 - Attribution Slide 6 - Abatement Algorithm Selection Martin - Slide 7 - Question: Application Scope Slide 8 - Representative Use Cases Slide 9 - Message nomenclature 1st paren - source. 2nd paren - features Slide 10 - Message nomenclature Slide 11 - Message nomenclature Slide 12 - Message nomenclature Slide 13 - Single Agent, All Nodes Support Peer Slide 14 - Single Agent Error on the slide - should be loss algorithm with %. This illustrates most of the concepts. Slide 15 - Notes Martin - that was single agent... Steve - I have other cases Slide 16 - A1 does not support Peer Slide 17 - A1 supports DOIC, does not support Peer Slide 18 - A1 Does not support DOIC Slide 19 - C does not support peer Slide 20 - C does not support peer Slide 21 - Agent chain - All nodes support peer Slide 22 - Agent Chain - A2 overloaded Martin - the interconnect between home and roaming carriers is between 2 agents and assumes topology hiding. If there is an overload at the server in the network, you won't get info on which servers are overloaded? Have you considered that? Steve - not yet. This assumes single domain. Topology hiding has been outside of scope. First ask about the impacts of topology hiding for DOIC, then agent. It's a DOIC question. This agent here will have to consume all the OL reports, aggregate them. Martin - in the pure DOIC sense, we weren't talking about agent processing, but here we are. Steve - question for the chairs - is this part of dime working group responsibility? If so, in this doc? or in another doc for multi-domain environment? Lionel - we've talked about it for DOIC. There is no definition of topology hiding or how it is provided. It's vendor specific and up to agent implementation. It's why it wasn't included in DOIC. We would have to clarify how and why to provide topology hiding. Martin - not to draw analogies with SIP, but in early 2000s in SIP discussions - the box in the middle didn't exist. Then they recognized that SBCs existed. I'm happy either way. There's precedence to recognize that this occurs. This meeting, dispatch had a discussion about not providing IP address of carrier's server for privacy and protection. It's worth discussing. It's a realistic scenario. Lionel - we have an agent in the middle and it can do magic. If we want to go into the topology hiding details, we have to define it. Needs to be included in 3GPP topic. Depends on application. What info to pass over roaming interfaces? Work would not be done in IETF but 3GPP. Martin - I'd like to hear from others. In 3GPP, it'll will go to SA2 and it's hell. I'd rather it discussed in IETF. Steve - in order to talk about topology hiding we need to define it here, but not as part of the agent overload spec. Lionel - we have to assume info is .... can be stated in the doc. Steve - If policy says topology information needs to be stripped, needs to be stripped. I'm not sure it needs to be captured. If you don't want to forward AVPs due to security, don't. We can talk offline, Martin, about bringing something forward. JJ (??) - Back to slide 14 - Steve - It doesn't change how DOIC works, but you have to put source ID in the requests and answers. You don't need to do it for the host report. Lionel - only applies for the negotiation of peer (?) Slide 23 - Agent Chain - A11 does not support peer Slide 24 - Agent Chain - A11 does not support peer Slide 25 - Long Agent Chain Slide 26 - Long Agent Chain Slide 27 - Long Agent Chain - Agent doesn't support DOIC Slide 28 - Long Agent Chain - Agent doesn't support DOIC Steve - there's an error here. This AVP should not be here. Slide 29 - Next Steps Lionel - does it work like DOIC for the app or for all the apps? Have both? Steve - That would be a middle ground. Add a AVP to allow wildcard for all-app support. ?? - I prefer to use app specific. Steve - you don't want an agent to send for all applications. Lionel - who has reviewed? (3 hands) Who will volunteer to review? Martin - I will. Janet - I will try, no promises. ----------------------------------------------------------------------------- 0930 - 0945 (15 min) Diameter Overload Rate Control Presenter: Steve Donovan Presentation: http://www.ietf.org/proceedings/92/slides/slides-92-dime-3.pptx Draft: draft-ietf-dime-doc-rate-control Slide 1 - Title Slide 2 - Status Slide 3 - Dependency Slide 4 - Question - Report type support ?? - it makes sense to use in ... reports because sometimes you have a server... Steve - wouldn't the server send a host report? ?? - configuration. It can control the rate better. Steve - I can see the case for host rather than realm. But rate can be used in all 3 report types. Slide 5 - Question: Algorithm Applicability Steve - SIP doesn't have concept of report types. Should the algorithm be updated? Lionel - there's no differentiation yet. Steve - right. We'll leave that for follow-on discussion. Slide 6 - Next Steps Steve - overload and load are separate things. There's no link between rate and overload. Martin - I agree. You use load to redistribute traffic prior to overload. If you are in overload, redistributing can be dangerous - it moves the problem around. Lionel - when we talk about rates, what does it mean to downstream nodes? Martin - Within SIP, there was an extensive perf models done - to come up with same result. There's a difference in behavior between rate and loss algorithms when it comes to protecting against storms - rate is better than loss. Steve - rate is MPS, load is % resource consumption. There's correlation, but not a tight coupling. Lionel - Who is willing to review? Jouni, Lionel, same batch of people. ----------------------------------------------------------------------------- 0945 - 1000 (15 min) Architectural Considerations for Diameter Load Information Presenter: Steve Donovan Presentation: http://www.ietf.org/proceedings/92/slides/slides-92-dime-1.pptx Draft: draft-campbell-dime-load-considerations Slide 1 - Title Steve - Ben is in mmusic meeting as RAI AD. I'll be replacing him. This doc doesn't propose a solution. just what should be considered. JJ contributed significantly to this doc. Slide 2 - What is Diameter Load Steve - last hop agents can't pick the server sometimes so load info isn't useful. Slide 3 - Topology of Load Steve - I consider this an open question Slide 4 - Topology of Load Slide 5 - Load Topology Preliminary Recommendations Slide 6 - Scope of Load Information Martin - it would be useful to have use cases for the questions. Steve - we've started that. Slide 7 - Scope of Load Information Preliminary Recommendations Steve - focus on single node case initially. Others are follow-on work. Load applies to an app, not all apps. Could have an AVP that specifies one or all apps. Lionel - one or all apps, do you expect change of behavior of the recipient? Steve - the node doesn't have to have different queues for different apps - implementations can be easier. Slide 8 - Precedence between Load and Overload JJ - When overload appears at some point, how to distribute traffic? There may be some aspects between load and overload. Steve - to restate your question - if an agent is routing requests to 5 servers, one becomes overloaded, will use load info to redistribute. Correct? Slide 9 - Load Information Semantics Steve - don't need to decide now Slide 10 - Negotiation Slide 11 - Negotiation Preliminary Recommendations Slide 12 - Transporting Load Slide 13 - Transporting Load Preliminary Recommendations Slide 14 - Frequency of Sending Load Information Martin - keep it as simple as possible. Stay away from negotiation. Sending it every message is ok. Minimize the processing of the info. Lionel - the recipient can ... keeping the flexibility lets the recipient choose. The recipient can sample. Steve - the recipient is depending on the sender always sending it. Lionel - yes Slide 15 - Frequency of Sending Load Information Slide 16 - Frequency of Sending Load Information Steve - sender always sends, recipient can decide on sampling. Slide 17 - Summary of Preliminary Recommendations Lionel - need to decide on load info for endpoints. Source id may or may not be required. Steve - it's required either way. Slide 18 - Next Steps Steve - this doc dies and another doc that defines how it works incorporates this. JJ - this is info only. I won't say it immediately dies. It asks questions. Need to work on normative part in parallel. This is critical for considerations. Steve - I mean that the document doesn't go to RFC. Others may think that it is published as info RFC. Lionel - we had the same discussion at the last meeting. It could be merged. Comes from the DOIC requirements draft. It's related. There's a need from working group PoV. Do you agree to adopt the topic as working group item? Room - 8 hands support Room - 0 do not support Lionel - Should we adopt doc as a working group doc? But not progressed to RFC but reused. Kathleen, as AD - that sounds like a fine approach. Lionel - take as a working group doc, remove TBDs, decide what to keep. Steve - we could have multiple mechanism drafts to chose from. JJ - Steve - could have an appendix in the normative doc. Lionel - there's not a normative doc, not like 3GPP. Who's in favor of doc? Room - 8 people for Room - 0 people against ----------------------------------------------------------------------------- 1000 - 1015 (15 min) Diameter Routing Message Priority Presenter: Steve Donovan Presentation: http://www.ietf.org/proceedings/92/slides/slides-92-dime-0.pptx Draft: draft-donovan-dime-drmp Slide 1 - Title Slide 2 - Problem Statement Slide 3 - DRMP Use Cases Slide 4 - Design Questions - 1 Janet - since there is no associated bearer, preemption and priority aren't relevant. Exception from throttling should be the primary priority treatment. Martin - per hop behavior ... indicator can be used for that kind of admission - out of box quicker. Steve - we're talking about diameter signaling. Packets are orthogonal to this. Janet - agree with Martin - but do not need to assign each namespace as one or the other. Steve - namespace defines the following: priority values and preemption behavior. If we want to stay with single priority definition we can. In SIP, the multiple namespaces - the signaling can traverse different administrative domains with different priorities. Janet - yes leverage the SIP work. just not the queuing vs preempt id. Martin - for diameter - it's simple to have binary - normal and priority, don't think we need to differentiate. In SIP, the namespace influences the bearer setup. Steve - that's fair. Janet - agree with Martin. Slide 5 - Design Questions - 2 Lionel as individual - alternative - if you use AVP, you need to parse to find the AVP, which is painful. Using command flag is not appropriate unless it's a general mechanism. Steve - that's the assumption. Lionel - if you are indicating set of priority - rely on .... sharing the info. If message has priority 1, need to ensure that the appropriate priority is applied. Steve - policy would have to be on per user basis. Lionel - need this info as soon as... 6a... priority info in the network - as soon as possible before the overload info. Need to set up the filter before. Profile that you will use. Done by provisioning. Send an index value. Steve - that boils down to priority with each message. The client can send in advance what the priority levels are. Lionel - if the purpose is to prioritize one message over another. Steve - if you are going to use command code, that's a per transaction basis. The client has to understand how to set the priority - won't be in this draft. Some policy - database lookup, whatever. Martin - agree. Baked into trust model and local policy. It should be normal or high priority. If there's more than that, we should discuss. Outside the envelope as possible specified. So it can be looked at quickly. Steve - one bit in command flag would be enough. But extensibility plays into this. Jouni as individual - this was discussed before - could we use transport layer?For instance SCTP using PPID. Steve - we had talked about this. Issue with transport layer is you can't differentiate message types. TCP - it's on a per-connection basis. ?? - use combo solution. Also define AVPs. I have an emergency call. In overload scenarios I can go around. Steve - can give the advantage to agent so it doesn't have to look at AVP. Slide 6 - Design Questions - 3 Slide 7 - Question 4 Martin - you will mark priority on every message. Bullet 2 is an app. A server processes messages within established transaction before new ones. Steve - if we went with 2, the you don't have to mark it. Decreases the overhead. Martin - stateless agent - if it marks on every message. Steve - there's no such entity. Martin - within the stack. If you have it in the command bit, the recipient knows the priority before msg is priority. Steve - if you use command bits - it's per message basis. If not then it doesn't need to be per message. You can use the fact you have state Slide 8 - Next Steps Lionel - we just initiated the conversation on the doc. Will initiate discussion on the mailing list. ----------------------------------------------------------------------------- 1015 - Next Steps / AOB Presenters: WG Chairs & ADs Lionel - Kathleen is the new AD. Kathleen - give a report to SAAG - request assistance for this problem. Get some movement there. Lionel - a lot of activities around e2e based mechanism, but we don't have .... need to rely on something developed by someone else. A new mechanism. Need to provide our requirements on e2e. Kathleen - some interest in Jose. A new effort on Jose (refers here to CBOR), may form a charter. GSMA (?) Tight timeline. Need everything yesterday. Feeding requirements would help. Lionel - question for Jouni - is Jose still valid? Jouni - I'm not sticking to it. Let's get reqs done. Just happened to use JSON. Lionel - add milestone.... Will confirm working group adoption. Anything else? Lionel - we can set up conference call at any time