DIME WG IETF 88; 150 min THURSDAY, November 7, 2013; 0900-1130 Morning Session I =========================================================================== 09:00 Agenda and WG update 10 min Presenters: Chairs: Jouni Korhonen, Lionel Morand Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-dime-3.pptx Note Taker: Jean Mahoney Jabber Scribe: Alan DeKok, Alessandro Amirante Slide - Note Well Slide - Intellectual Property Slide - Agenda Jouni - any feedback on the agenda? No comments on the agenda Slide - RFC Editor's Queue - draft-ietf-dime-rfc4005bis (WAD GoA::RevID) Jouni - Lionel is editing and will be submitting a new version. Lionel - we can submit this version, but if we don't hear from Glen and the doc enters Auth-48 - Benoit Claise - There's a small change that we agree on, there are no answers from Glen. Just submit a new version. I propose that if the doc goes in Auth-48 and it needs changes, the document shepherd can take over. LC is not done yet? Lionel - Yes, it was done. We heard from Gen-ART and SecDir. There is only one remaining issue. Benoit - Right. Please post it. See if Glen replies. If not, the document shepherd will take over. Keith Drage - if the doc is still with IESG, then update it now. Benoit - That's what he wants to do. Slide - Documents in WG process Jouni - app-deisgn-guide will move forward soon. =========================================================================== 09:10 Group Signaling 15 min Draft: draft-ietf-dime-group-signaling Presenter: Marco Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-dime-4.pptx Marco presented. slide - 2nd Revision What's New...? (pg 7) Marco - question to the working group on 'group-ownership' - Should Session-Group-Id follow the format of the Session-Id AVP and identify the node that created the group? Or is a flag sufficient? Jouni - wait until end of the presentation. slide - Next steps Lionel - any questions? who has read the draft? Room - 2 hands raised. Lionel - Any volunteers to review? I think it's stable. After the next version is out, we need more reviews. The draft needs to reflect working group consensus. Room - Ben Campbell and Steve Donovan volunteered to review. ACTION: Ben Campbell and Steve Donovan to review draft-ietf-dime-group-signaling. =========================================================================== 09:25 Diameter End-to-End Security 15 min Draft: draft-ietf-dime-e2e-sec-req Presenter: Hannes Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-dime-2.pptx Jouni presented. slide - Open issue #1 - Capability/Policy Discovery Jouni - I want feedback here. Steve Donovan - Are these requirements or implementation questions? Jouni - the selected protected AVPs … Steve - i thought it was there. Is out-of-band - is that a requirement? Jouni - good point, I don't have the answer. If you have a good proposal? Steve - Organize the document into requirements and implementation sections. slide - Open issue #2 - Command-Line Support Jouni - this is a funny requirement, I don't know why Hannes put it here. I don't see this as a requirement. It's obvious. slide - Next steps Jouni - please review the draft. Lionel - We should submit this draft to SecDir after we get comments from the working group. Room - Alan deKok volunteered to review the draft. Ben Campbell - The folks working on overload need to look at this doc. Lionel - it's a key issue for the dime working group. Everyone should be interested. Diameter is used in SMS for instance. We should have a way to provide integrity and confidentiality. We don't have a mechanism for it. =========================================================================== 09:40 15 min Draft: draft-bertz-dime-congestion-flow-attributes-01 Presenter: Lyle Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-dime-1.pptx Brent Hirshmann presented. slide - Questions for Consideration Lionel, from the floor - I think the dime working group won't be able to answer the TCP question. Which working group would? IETF, 3GPP? Brent - it's why we're here. If know one has any suggestions, we won't put them in. I've attended tcp and rmcat to learn more and broaden my exposure. Lionel - maybe we can figure out the working group. We can discuss this point with you after the meeting. If they aren't included we can consider in our working group. Slide - ECN Specific AVPs Lionel - … be careful using the … AVP, I'll put on the list. Has someone read the doc? Room - Only one person has read it. Lionel - Will ask on the mailing list for additional reviews. ACTION: Chairs to ask on mailing list for additional reviews of draft-bertz-dime-congestion-flow-attributes. ACTION: Chairs to determine which working group can answer TCP question. ACTION: Depending on answer to TCP question, determine if draft-bertz-dime-congestion-flow-attributes can be adopted as a working group document. Jouni - 3GPP is a potential consumer, do you have timing constraints? Brent - they are finishing release 12. This won't be in 12. Hopefully it will be reconsidered for R13. There was a concern about legacy routers. This impacts the new SDN approach to virtualized networks. Those routers are more generic. Can go in faster in those environments. Keith - Where is this presented in 3GPP? Brent - SA2 =========================================================================== 09:55 Design team output 65 min Draft: draft-docdt-dime-ovli Presenter: Jouni Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-dime-5.pptx Jouni presented. Jouni - Who outside of design team has read the doc? Room - 3 people slide - Background Jouni - will close the mailing list to move decision to dime working group mailing list. slide - Main Solution Principles, cont'd Ben - to clarify on endpoint principle, it's easy to confuse overload endpoints with diameter endpoints. An overload endpoint can be an agent. slide - Decisions Steve - we have a compliance statement of what's in/out of the doc. Where we are not compliant, we need to be explicit as to why. Jouni - there's a list in the appendix. Alan - what about latency? I don't see it addressed. There's the latency between server receiving and a client being told to back off. The server should prioritize sending overload info over regular processing. Jouni - good point. Propose text. Steve - I don't know how you would do better than what's in the draft - we use piggybacking. Alan - there is latency, and it's good to call it out in the doc. Be aware of it. Ben - We've discussed recovery from overload. We'll apply hysteresis so you don't come back from overload and then overload again. It's appropriate to add this in there. Keith - This is based on SIP work, and it was extensively analyzed and mechanisms tested over there. The feedback is continuous. You don't wait until you are overloaded to start sending it. Ben - We're thinking the definition is that the server is wanting traffic reduced, not that the server is actually overloaded. Jouni - may need to be stressed in text. Enhance text on that. ACTION: Enhance text to clarify that servers should not wait until they are actually overloaded to send overload information. Alan DeKok - The doc shouldn't get into the details of overload algorithms. It would useful to talk about it a bit. Overload signaling is continuous? What does that mean? Every response? Every 10 seconds? How do you ramp traffic down/up? Having guidance would be useful. Steve - That's what's missing - section 5.5. We need to get to that. We've talked about the algorithm. to just describe it. How frequently should the report send a overload report. That's the biggest hole in the draft. slide - Open Issues and parts under discussion in -01 Ben - There's an ongoing email thread on "Inserting throttling information into requests." Lionel - there's a slide Ben - it's an optimization or it could be another draft. Jouni - [something about the mail list discussion that the html was too big or something] slide - Issue: Extensibility and capability announcement Ben - on the negotiation part - I'm not in disagreement. There are open questions if the reacting node sends all it understands. Or if we have situations where the server side - picks one in advance. The extension itself has to document how it is done. Joni - If your implementation understands 5 different ones, but the admin could turn on only one. Lionel - The key is to pick one, indicate one was selected before … the text should be flexible. The client can announce to the server. Capability vector - flexibility on how expressed. For one algorithm, you may have to say exactly what you want. The safer way - capability exchange … Not perfect. Send everything in the request, and in the answer, say what you want. Keith - are there use cases? Do we have use cases for more than 2 algorithms - default and one other? Jouni - 640 kb is enough. Anything to extend the protocol. Keith - can we keep negotiation simple? Jouni - If it doesn't fit in the this framework, write another proposal. We want it simple. Steve - There have been 3 algorithms discussed. Whether they will all be defined and deployed. The feature vector will be used for other things. Need bits for them - agent overload for instance. Ben - back to Keith's' questions - I've heard of 4 algorithm. The fundamental difference is that the default doesn't guarantee spike prevention. Others talk about rate limiting and sliding windows. In the actual deployment, there would be a default algorithm and one or two algorithm for an anti-spike guarantee. If we starting discussing them here and now - things would be thrown in the room. Ben - going to group rather than bit field there may be different parameters. Lionel - Will it add a timestamp? Jouni - we've discussed it. Lionel - AVP would be a group AVP. Determine if we need to add more than the flag. Jouni - we discussed this. When something changes on capabilities. Comparing the timestamps, you can see if it changed. Lionel - valid for the newer version. default? Lionel - for default you don't have anything. It doesn't hurt to define now. Ben - the root of it is that these capabilities announcements create state. The other end has to remember. W'e talked about what is the life of the state. If the are agents, then you can't do it by connection. Nor life of transaction since there is no state at all. We've talked about state of the session. I think we're thinking - you remember the state until you hear otherwise. Use a sequence number or timestamp here. The receiver can determine if there has been a capability change. It needs more thought, having a sequence number or etag or hash or timestamp or something to determine change would be handy. Lionel - how to document this in this draft? We're just describing the loss algorithm and you don't need an indicator. Ben - it's not about the algorithm, it's about the capabilities. Lionel - but you would have a new value in the flag. Ben - having a sequence number provides a shortcut to further example. Do I want to keep re-parsing a message? Jouni - We need to lay a good foundation for future work. Ben - This is the extension mechanism. We need to think about it. A sequence number or timestamp may be useful for replay attack prevention. slide - Issue: Destination-Realm and -Host routed requests details ACTION: Review Ben's proposal on the design team list. Ben - I sent an example, nothing normative, and put in the appendix. After review, we may add it to main text. slide - Proposals under discussion: throttling information into requests Jouni - I haven't followed this discussion. Need to discuss still. Steve - I don't have a strong opinion yet. It addresses the … requirement. The server can understand which requests have survived a throttling action. If the client doesn't support the extension, the server can treat differently - can throw those out first. Lionel from floor - It's an optimization, it's not required in the baseline. slide - Next step Ben - It's up to chairs on adopting this as a working group item. Does this give us the best path forward? Some working groups want to have the open issues closed before adopting a draft as a working item. Jouni - We dont have a competing doc. Ben - I'll object to that statement. Keith - Is this the best doc to start with? Ask that question. Need to avoid confusing the mailing list. Make the call on -01. Then put to the list what the changes will go into -01. Lionel as chair - In this working group, a doc can become a working group item if there is sufficient review of the doc, and the doc is stable enough. Steve - I'm not convinced -01 is stable enough. There are sections not written. Prefer to see -02 text before adopting as working group doc. Lionel as chair - with approval of changes here and then fixed? Steve - if what we have presented today goes into -02, I'm good for those pieces. But we haven't addressed behavior or reporters and reactors. I'm comfortable if what we've talked about will go in. But there are questions we haven't addressed. Things could veer. Ben - Based on that point. In part, the behavior section is not there and it is core. How long will it take to create 02? If it's next week. Sure. But more than a week, then we're up against what Martin is standing in line for. We have 2-3 other competing drafts. The roach draft was far along to completion, if you agree on its content. This draft is further from complete, but has a broader base of support. Keith - Is the doc in WGLC as apposed to adoption? What isn't there? Ben - reasonable stability. Keith - but that's not an IETF requirement for working group adoption. Is the doc in sufficient detail? We can get working group consensus on text that will be added. Is the text there sufficient? Martin Dolly - We should not let process get in the way of progress. CG4 has no CRs. We are waiting for this group. We need a working group doc before Thanksgiving so we can generate CRs. The doc has to be ready before the next meeting in Jan. This capability is needed for VoLTE. This is the best doc for moving forward based on consensus. Eric McMurry - I agree with everything that has been said. -01 is mainly definitions and is empty. Hard to evaluate. Steve - What does 3GPP need? A name of a doc that can be referenced? Or that the doc has content? I don't know the process. With what's in the doc today, you couldn't do much. If you need a pointer, that's easy. If you need behavior for application-level specification, there is not enough there yet. Just having -01 won't help. We need -02. If -02 comes out next week, we can meet Thanksgiving. Lionel - 3GPP needs a working group doc. If we need several weeks for a working group doc, we're too late. We need people to commit to work on the doc, and update the draft so that it is stabilized by the next 3GPP meeting. To start the process, we need a working group doc. Keith - I've been dealing with dependencies since R5. Need to say there's a working group draft. Need to ack that the design team doc is the doc going forward. Michelle? - We recommend … to left for discussion. If there are concerns about the basics. I would raise concerns. Agree what is in the document already. Ben - Thanksgiving is 3 weeks from today. If a two week call on the list starts Monday, it will complete. What can 3GPP get from the draft? There's major structural pieces. For the default algorithm - there's not much disagreement - need words for it. To not completely agree with Michelle - there are some issues that may be divisive. We will have divisive choices anyway. If the goal is to meet the deadline, I would support adopting this. If -02 comes in a small number of days. If people are not comfortable with what's there, don't agree. But I don't hear disagreement. Lionel - this doc has basic principles. We have to document open issues. From the 3GPP's perspective, the doc needs to be finalized in March. 3GPP only references working group docs. Kalyani Bogineni - There's not enough time to do -02. Big features take multiple releases in 3GPP. VoLTE is a new technology. As we roll things out, overload control is sensitive. Should start with O1. There will always be differences. It has to keep moving. Keith - I don't know why Thanksgiving is a problem to adopting 01. I assume you will issue a call to the list. And us people can respond before Thanksgiving. In parallel, talk about what you want in -02. Steve - We need to go in the direction the design team has set. I'm uncomfortable with -01 for a couple reasons - only the design team has reviewed. We've had a late change to its fundamentals. There are some capabilities - one has been pulled out. Capability Negotiation - and the default algorithm. If we don't have those two we don't have a working solution. Let's accept -01 based one what Jouni presented. I expect it to go in that direction. I reserve the right to complain if -02 goes in a different direction. Lionel - to conclude on accepting this doc. The working group will commit to work on this, and we can modify content. LC allows people outside of working group to comment. There will not be a commitment to work on individual drafts. Martin - are you ready to ask the question? Ben - Who in the room hasn't been involved in design team? Room - 7-8 people raised hands Keith - the design team doesn't have formal status. You are trying to endorse the design team. It needs to go into the working group. Ben/eric - that's what Ben was trying to say. Lionel - there were 10 people involved, unlike individual contributions. Asking for the adoption of this doc as a working group. Eric - To ben's point, put it to the list. Only 2 people outside of the design team have read it. Make the call. Jouni - If you want to adopt -01 as working group doc, raise hands. I don't like hums. Hands up - lots of hands Jouni - Against? Room - no hands. Jouni - We will ask the mailing list. ACTION: Chairs to ask the mailing list whether the design team document should be adopted as a working group item. ACTION: Chairs to close the design team. Lionel - it was tough, thanks a lot to everyone involved on the design team. =========================================================================== 11:00 15 min Draft: draft-donovan-dime-agent-overload Presenter: Steve Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-dime-0.pptx Steve Donovan presented. Ben - to clarify - there's two ways to think about it - report something behind overload. Report that the agent is overloaded. This is when the agent is overloaded, not necessarily anything behind it. slide - Question 1 Steve - do we need to address this? Martin - we've talked internally - yes, it needs to be addressed. Steve - Anyone disagree. Room - No disagreement Ben - I agree, but the people who disagreed on it are not here. Need to ask the list. lionel - it was part of the requirements. The only question was to address the specific case of the agent. Steve - there was a person who asserted that it wasn't part of the requirements. I just wanted to be clear here. slide - Behavior Ben - this is base Diameter behavior. In cases of TOO-BUSY, there's text, if you have multiple peers that can handle the request, and one has sent a TOO-BUSY, you send to others. In the base. Lionel from floor - agree with the second point except - you mean this abatement would be peer connection. Ben - to amplify - if you have chaining agents, if you can select a peer to send to. Don't have control over intermediaries. It's about an overloaded peer. If not, you can't do anything. slide - Question 2 Steve - I think it it could go into base draft. Ben - speaking for myself, people wanted more analysis and didn't want to make it base specification contingent. There's no new code path here. A client will have to treat an agent report the same way it treats a server report if server was a peer. Has to handle it anyway. Not much added complexity to the client. It doesn't impact servers. It adds complexity for agents. It's easy to understand. The extension is agent support type. Not going into -01 or -02, once it's resolved, but can merge it into the base if the base is still around to modify. Martin - This is needed. A compromise - proceed as an extension and then decide in January before London to incorporate or not. Ensure that the base is not delayed due to incorporation. Lionel, from floor - We can do more, the load control can be done. I don't know how to deal with … Explicit overload sent back. You rely on both. If this should be standalone. … AVP as proposed init.. Steve - this is part of the reactive side. You are saying that you need to drop requests. As apposed to load, where you say, I can handle this much. Lionel - To separate - Steve - Load is useful for non-agent situations. Lionel - in your peer table, you take it into consideration. It's my understanding. You may also have explicitly - I'm overloaded different than load. Both at connection level. Maybe keep it separate and provide load info. We have something at connection level. Add load AVPs. Steve - that's another way to address. I want to keep overload together and load together, but I understand. Ben - I agree with Steve. Agree with Lionel that the mechanisms are similar. Maybe merge load in later, it doesn't slow anything down. I had intended to write a load draft before this meeting. I will try to do that. It will look a lot like this. But it is helpful to think about them separately. It may make sense to merge them. Keith - it's premature to answer that question right? (nods…) Steve - it would be good to ask if it should be working group doc. Ben - who has read it. Room - 4 hands Lionel - if we have 2 working group docs, we would have to work on both at the same time. I don't want to delay the base doc. If we are willing to work on both, ok. Prioritize the base doc. Keith - it's premature to make it a working group doc. Decide later to merge in. Need to priority on base doc. It doesn't preclude work on this. Eric - I agree. I point out that there is not a restriction to having multiple working group docs. Lionel, chair - There is. To ensure the AD can progress the doc fast enough. Focus on the base. Eric - by your argument, you could fold this into the base. Ben - we didn't have agreement that we should work on it and is covered by requirements. Asked if anyone read it, I'm not sure it's had wide review. If it gets folded in, doesn't matter. I hope it doesn't mean that we can't talk about it until London, then couldn't fold it in. Lionel - Discussing the doc is ok. If it's a working group doc, the AD can ask about the progress, we can use the tracker. Kalyani - I support the base line. If there disagreement ... We want a baseline doc to be finished. Ben - I'm falling to that side. There are dependencies in this draft on the base. We've been talking about extending the algorithm. This is an extension report. We need understand our extension mechanisms. Lionel - We can say there was interest. Follow up on the mailing list. Would it be acceptable to wait for next round - defer working group adoption for now? Steve - that's reasonable. Martin's point - if not merged in, then it becomes a working group doc later. Martin - Incorporate in the January timeframe or make it a working group item. Ben - People outside design team should look at it. Martin - If the chairs could reach out to SIP overload design team to look at it. Once adding another algorithm. They've done have extensive testing. Lionel - I don't trust SIP people. The design team will be closed. Ask for proactive work. We need to work on with this doc as soon as possible. Needs to be strong doc for 3GPP discussion. Ask for people to be proactive on mailing list. Keith - virtual interims are easy to arrange. Does need 2 weeks notice though. You aren't constrained by Thanksgiving. End of meeting.