DIME WG IETF 89 THURSDAY, March 6, 2014 0900-1130 Morning Session I (150 mins) Richmond/Chelsea/Tower -------------------------------------------------------------------- 09:00 - 09:10, Preliminaries (10 minutes) Presentation: http://www.ietf.org/proceedings/89/agenda/agenda-89-dime Presenter: Jouni Korhonen Note well presented. Note taker: Jean Mahoney Jabber scribe: Alan DeKok Jabber log: http://www.ietf.org/jabber/logs/dime/2014-03-06.html Agenda presented - no one had changes. Document Status: draft-ietf-dime-e2e-sec-req-01 -> About ready -> WGLC Status hasn't changed since last meeting. There are still editor's notes in the doc that need to be resolved. draft-ietf-dime-group-signaling-03 -> in WG Authors have indicated that they want to go to WGLC. draft-ietf-dime-ovli-01 -> in WG Hope to get the -02 out soon. draft-ietf-dime-pmip6-lr-18 -> AUTH48 Pending comments from Glen Zorn. Has an RFC number. draft-ietf-dime-rfc4005bis-14 -> AUTH48 Has an RFC number. -------------------------------------------------------------------- Diameter Congestion and Filter Attributes (15 minutes) Draft: https://datatracker.ietf.org/doc/draft-bertz-dime-congestion-flow-attributes/ Presentation: http://tools.ietf.org/agenda/89/slides/slides-89-dime-0.pdf Presenter: Brent Hirschman Brent presented. There were no objections in the room to making the draft a working group document. Ben Campbell and Marco Liebsch volunteered to review. Lionel suggested that TCP ECE and CWR filters be added and that the document clarify how nodes use the AVPs. ACTION: Ben and Marco to review draft-bertz-dime-congestion-flow-attributes. ACTION: Author to add ECE filters and to clarify how specific Diameter nodes use the AVPs. ACTION: Chairs to ask the mailing list if the draft should be adopted as a working group document. ACTION: Benoit and chairs to discuss whether the charter needs to be updated to cover the work. ACTION: Chairs will handle turning the draft into a working group document. -------------------------------------------------------------------- Diameter Group Signaling, Marco (20 minutes) https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/ Presentation: http://www.ietf.org/proceedings/89/slides/slides-89-dime-2.ppt Presenter: Marco Liebsch Marco presented. Marco asked the room for comments on constrained permission considerations and how to handle relays and stateless agents. Matthew Holdridge felt that the draft could be clearer on how/where accounting should be handled. ACTION: Authors to solicit feedback on the mailing list. -------------------------------------------------------------------- draft-donovan-dime-agent-overload, draft-donovan-doc-rate-control The discussion on these drafts centered around whether they should be included in the base DOIC draft or separate. Ben Campbell argued for including agent-overload since there are RFC7068 requirements for agents. Maria Cruz didn't think it needed to be included and raised concerns about it delaying the base draft, stating that 3GPP won't be taking the base draft into R12. It needed to be more stable. ACTION: Chairs to ask mailing list for working group adoption of draft-donovan-dime-agent-overload, draft-donovan-doc-rate-control -------------------------------------------------------------------- Issue Tracker discussion Discussion focused on a more efficient use of the issue tracker. ACTION: An issue should be sent to the mailing list first to determine if it is an issue that needs to be tracked. ACTION: When entering a ticket, provide a prefix to identify the draft in the title. ACTION: When consensus is reached, the ticket should be updated with the agreed-to text and then closed. The document should then be updated. ACTION: Mailing list participants should use either text format or snip the length of their responses. -------------------------------------------------------------------- Diameter Overload Indication Conveyance, Jouni/Steve (80 minutes) draft: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ Presentation: http://www.ietf.org/proceedings/89/slides/slides-89-dime-1.pptx Presenter: Jouni Determining overload for the realm - Jouni, Ben and Steve agreed that determining overload for a realm is an implementation issue. Dave wanted to know how a client should resolve contradictory reports from agents. Work is still being done on that issue. Report types - there was consensus that Host and Realm report types needed to be retained. Ben suggested that if a node sent a Realm report, it needed to be an absolute authority for the realm. Dave did not agree that agents needed to be authoritative and felt that clients should be able to make their own decisions on conflicting realm reports, which Lionel disagreed with. Maria Cruz agreed with both proposals because it would be deployment dependent. Steve said that the draft should provide guidance that a sender of the realm report should be an authority and that realm reports should not contradict. It should provide guidance on what the client should do if does receive different realm reports. Ben pointed out that, in the case where a realm was sending overload reports, individual servers could send Reductions of 0% in their reports to provide more information to clients. ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a proposal on whether to remove or to incorporate. ACTION: Next version of DOIC will keep Host and Realm and leave Realm-Routed-Request an open issue. ACTION: Clarify precedence of the host and realm report types and what actions to take when they are received. Errors sent to a noncompliant client - the group discussed which RFC6733 error to send to clients that do not support DOIC. ACTION: Look at sending UNABLE_TO_COMPLY versus UNABLE_TO_DELIVER to an non-DOIC client. ACTION: Working group to clarify what base Diameter errors mean, maybe in an informational draft. Host report scope (all, single) - This discussion centered around whether a host report should apply to all reacting nodes or a single one. Although there is a 3GPP requirement to single out a node that is generating heavy traffic, it was proposed that this be considered an extension to the base draft. It was also noted that the "reacting node" terminology needed to be clarified. ACTION: Propose on the mailing list that the type 0 Overload report should be an extension to the base draft. OC-Supported-Features Handling The room quickly supported the proposal presented. ACTION: Post to the mailing list the OC-Supported-Features Handling proposal, (Reacting node advertises all supported algorithms; Reporting node responds with the single algorithm it will be using; Handling of other feature bits is defined in the extension drafts) which had consensus at the meeting. OC-OLR Handling ACTION: Send to the mailing list the proposed closing of the OC-OLR handling issue with the second bullet (Single OC-OLR AVP used by all abatement algorithms with the meaning of the overload report indicated in the OC-Supported-Features AVP.) ACTION: Put text in the draft to recommend that algorithms should not be changed on the fly. Definition of overload control endpoints - Ben said that any node that supports DOIC is an end point. The solution should be able to work with agents and without them. Steve pointed out that you can have a DOIC association between a client and an agent and the same client and a server. Whether the clients and servers needed to know the existence of agents needed to be determined. Ben did not want to set up a system where behavior varied depending on the next hop because in most cases, the node doesn't know what the next hop is. End-to-end Definition - Steve proposed doing a side-by-side comparison of end-to-end and hop-by-hop behavior with gap analysis, and pros/cons. Ben and Jean-Jacques felt that the terminology needed to be clarified. ACTION: Clarify terminology for "reacting nodes". ACTION: Ben and Steve to summarize on the mailing list what was agreed on at the meeting. ********* DETAILED NOTES ********************* -------------------------------------------------------------------- Diameter Congestion and Filter Attributes (15 minutes) Draft: https://datatracker.ietf.org/doc/draft-bertz-dime-congestion-flow-attributes/ Presentation: http://tools.ietf.org/agenda/89/slides/slides-89-dime-0.pdf Presenter: Brent Hirschman Brent presented. Slide 1 - Diameter Congestion and Filter Attributes First presented in Orlando. Slide 5 - Questions for Consideration Brent - I don't feel it's necessary to add TCP ECE and CWR filters, but can add it if the working group feels that it should be. When do we add Classifier support for ECN for RTP over UDP (RFC 6679)? Only covers TCP right now. What can we do to progress the draft? Jouni - Are you asking for adoption? Brent - Yes Jouni - It's not in the charter explicitly but it's in scope of AAA in the charter. Who's read the draft? Room - A few hands Jouni - Who is interested in reviewing? Ben Campbell, Marco Liebsch raised their hands. Jouni - Anyone against working group adoption? Room - No objections Lionel Morand from floor - ECE would be an added value. Brent - ECE reflects it back. We've put in places to detect and report it in the ECN. The main node is EnodeB. We don't think we need it, but it's not hard to add through. Lionel - We should have one RFC to deal with congestion. We can add ECE. If you don't want to use it, it's there for someone else. The draft needs to say how specific nodes will use the AVPs. I don't know if they are sent by the server or client. For instance, the draft doesn't say how to use flow-counts. But on principle, the document is ok. Jouni - is it good enough for a basis the working group? Dave Dolson - Would the PCRF have to check for it and prioritize? Brent - Not necessarily. 3GPP is defining how to collect the accounts. Our proposal is that the EnodeB would collect the ECN count info and report through Diameter to a collection node like an OCS node. The collector would report to the PCRF, which would tell the gateway to implement rules on throttling, etc. Dave - It's a policy application, not a configuration? Brent - You may have flows congested for different reasons. You may have a lot of flows, basically lots of customers just browsing, which causes congestion. You want to handle roaming flows differently. Dave - I understand. Jouni - As individual I see value in this. AD? Do we need to change charter? Benoit Claise - I have to check the charter. We'll handle it offline. It's just process. Jouni - We'll make the call on the mailing list. Lionel - We'll take care of updating the doc to make it a working group document. ACTION: Chairs to ask the mailing list if the draft should be adopted as a working group document. ACTION: Benoit and chairs to discuss whether the charter needs to be updated to cover the work. ACTION: Chairs will handle turning the draft into a working group document. -------------------------------------------------------------------- Diameter Group Signaling, Marco (20 minutes) https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/ Presentation: http://www.ietf.org/proceedings/89/slides/slides-89-dime-2.ppt Presenter: Marco Liebsch Slide 5 - Permission Considerations Marco - we want comments on constrained permission considerations. Slide 10 - Presence of Proxy Agents Marco - How do we handle relays and stateless agents? Slide 11 - Open Discussion Items Marco - have made a decision that implicit discovery is a fallback only. Explicit discovery will be supported. Matthew Holdridge (Sonus) - Is there any accounting specification for Session-Group-ID? Marco - This is a guideline that does not address particular applications. It covers how to enable existing applications and commands to handle groups of sessions. How to do accounting or charging is not documented. Matthew - Add a paragraph to say how/where accounting should be handled. Lionel from floor - it's in the beginning of the draft but maybe it's not clear enough. Apps can reuse these AVPs. The use will be defined by the application. Refer to this draft when you want to extend your application. The information here should be generic enough to be reused whatever the application. The state machine was removed from the draft because it was app-specific. Marco - if there's something to be documented, we appreciate feedback on that. Lionel - who has read the draft? Ben raised his hand (maybe someone else in the back) Lionel - we will solicit feedback on the mailing list. Please review. Will use the issue tracker. After reviews and feedback incorporated, we can do WGLC. ACTION: Authors to solicit feedback on the mailing list. -------------------------------------------------------------------- draft-donovan-dime-agent-overload, draft-donovan-doc-rate-control Jouni - before we start with next presentation, there are a couple of individual drafts - agent overload and rate control. Steve? Steve Donovan - On agent overload, I think we got interest in doing the work last meeting. As for rate control, my co-author couldn't be here. ATT is interested in going forward with it. We want to understand how extensibility will work. I ask that we make these working group items. I don't want them to detract from the base draft, and we can give them later milestones. Ben - I would like to see the agent overload in the base draft, unless base draft is ready to move forward and agent overload isn't ready. Rate control feels like an extension. I support both as working group items. Jouni - has anyone read the drafts? Room - many hands up Jouni - Who will work on it? Matthew, Lionel, Steve, Ben, (other hands were raised) Jouni - The usual suspects. We can add it to the milestones. We can decide on whether to add agent overload to the base quickly. It can't interfere with the base spec completion. Lionel from floor - How to ensure how it will not delay? Ben - handling agent overload is one of the requirements of RFC7068. Jouni - we don't have to meet it all the requirements. Keith Drage - You have to ask if it can be separately packaged and can the base doc stand alone? Explain why it fits in the scope. Ben - I agree with Keith. I believe it does fit into the scope. I would like to see the base have as much of the solution as possible. The only good reason not to do it is timing. Maria Cruz Bartolome - I don't think it means that needs to be in the same doc. 3GPP won't take it for Release 12. We need something stable in the base doc. Agent overload can be a separate working group doc. Focus on the base doc. The base doc has already received 1000 emails. Ben - I don't disagree, but the working group can work on docs in parallel. I don't think it has to slow down the base draft. Jouni - people are ok into taking these docs into the overload umbrella with the main focus of getting the base doc out. We'll ask for adoption on the mailing list soon (within next week). -------------------------------------------------------------------- Issue Tracker discussion Jouni - How do we use the issue tracker even more? When we have reached consensus, update the ticket and close the ticket. Then we can take the result to the document. If folks are not happy with the new version, the ticket can be reopened or a new ticket generated. Ben - Some folks have been adding the issue into the tracker first and then taking it to the list. Maybe we should comment on the list first to see if there is an issue, then create a ticket. Jouni - Agree, but that's the judgement of the person opening the ticket. Lionel - I agree with Ben - first share the issues on the list and then open a ticket if there's an issue. Ben - having lots of open tickets is cumbersome to track. Lionel - Also, in emails, use text format or clip the email. If you can't see your post immediately after sending, it was too large and we had to approve it manually. Marco - There are different drafts being tracked in the tracker, I recommend adding a prefix to note the draft. Lionel - you can add it to the title. -------------------------------------------------------------------- Diameter Overload Indication Conveyance, Jouni/Steve (80 minutes) draft: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ Presentation: http://www.ietf.org/proceedings/89/slides/slides-89-dime-1.pptx Presenter: Jouni Slide 6 - Issue for Realm scoped reports Jouni - How you determine overload for a realm is an implementation issue. The draft does not have to define how to get it. Ben - A node can determine a realm's load by looking at traffic, but we can't be assured that we can know it in all cases. It's deployment related - you can have master agents, or agents talking to each other to determine state. Trying to specify how to do it in the draft will be pointless. Dave - How does a client resolve contradictory reports from agents? Use the agent that reports that things are good? Steve - yes and no. We're specifying the behavior now. I have a proposal a few slides down. If the agents are talking to each other and sending overload information, then the client selects the first one and that's definitive for the realm. Slide 7 - Behavior proposal for realm-scoped reports Slide 4 - Realm-Routed-Request and Realm report types Steve - Need to determine which of the 3 report types we'll support - certainly Host, and Realm that will represent all the traffic for realm. Remove Realm-Routed-Requests. Lionel from floor - …. Agree to put in draft that the Realm report must contain the right info for the client. Like sessions bindings for DRA, you don't care how it's done, just that it is. Ben - From Dave's comment, I've used the term scope authority. Any device that sends a OR has to be an absolute authority. If no one node can know, it can't send a realm report. In Dave's case, that would be an error. If we report realm, we don't want to find another path to that realm. On the 3 report types, I agree we need Host and whole Realm. I propose that Steve and I discuss offline and come up with a proposal on Realm-Routed-Request. ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a proposal on whether to remove or to incorporate. Lionel - to summarize what you said, we can go for 2 types and see if we need the 3rd. Ben - I agree for host and realm reports, keep Realm-Routed-Request open. Lionel - need to publish next version. working assumption is keep 2. Keep 3rd open. ACTION: Next version of DOIC will keep Host and Realm and leave Realm-Routed-Request an open issue. Ben - not a big deal. Lionel - can clarify in new version. Ben - One other point - we forget to talk about apps. For realm report - is for… Jean-Jacques - We should be cautious about multiplying reports for the client. I'm not sure we can conclude today. It's not easy. We are diverging. How is it acquired in the network? Client and server are not to be aware of the internal network. We would be dependent on what's between. Dave - I don't agree that the agents need to be authoritative or agree on authority. If the agents can agree, they can send the same value. If they are not coupled, then the client can make its own decision based on the realm data. It would not be an error. Lionel from floor - there's nothing in the draft about realm-routed requests. We have a host report, and for the realm - any request for the realm. From an operator point of view, I'm against having the client make the decision. You cannot say that a realm is both blue and red - it needs to be consistent. Just send host reports. You will never send realm if you can't use it. The client could be in the home or visiting domain. I agree with Ben, we need to cover how to handle inconsistent info in the draft. MCruz - I agree with both proposals. A realm is a realm, true. I agree with David, we could have uncoupled agents. The agent is chosen for each request and the view of overload is different. Coupled, coordinated agents can provide info on the whole realm. Or the client is given host info. On the three report types - I don't see the difference between realm and realm-routed-request. If the destination host is present and we have received host report - it gets precedence. The host information is available or it's not. Just keep the 2 of them. Jouni - There was precedence in the draft. On the decoupled agents presenting the same realm, would you reach the same or different set of servers? MCruz - both can happen, depends on deployment. We can propose basic scenarios in the draft, the rest is deployment-dependent that can't be covered easily. Steve - good discussion. We need text. A few thoughts - If something is sending a realm-scoped report, it needs to be the authority. We have to cover the case of receiving different values, but also provide guidance that it shouldn't happen. There will always be more than one entity sending a realm-routed-request report. It needs to reach all clients. Need to define what happens to the client. To Jean-Jacques's point - I'm proposing 2 report types but changing the definition of the realm type. Ben - If we close one issue in this meeting, we'll be happy. We agree we should only have 2 types, and we disagree on the definition of realm type. We can talk about needing a third type. There are unfortunate deficiencies in how routing maps to the deployments. Realm doesn't mean realm necessarily … When we have a partitioned situation, selection is based on configured connections or agent logic. We don't have a way to talk about those things, and making assumptions around that is scary. When people deploy, clients don't know they are talking to agents. A host report from agents can be made to report. Sending a realm report is dangerous. Dave - I agree with you - deployment should not be split. What it means for a realm to be overloaded from the client point of view - it could mean path, agent, or hosts. If an agent can get messages through and another can't - they could be providing different views of the same situation. There's load on the realm for all the CPUs. The path perspective has not been covered either. Ben - the agent overload draft will cover it. If the paths behind the agent are congested, the client can't tell it. Dave - Different agents can have different perspective? Ben - if the agent's doesn't know, then the agent report type is safer to use. Lionel at the floor - I agree with Ben (laughter, applause). When we say realm, it's not about the realm it … Need to ensure that info to a given client will allow it to know what to do with the next request. Enough info to the client so that the client knows how to deal with the realm. It was already proposed on the mailing list. From the client perspective, if there are no overload reports, then nothing. If realm report, the client applies to anything in realm. For host, it's specific for that host. This principle is ok and a good clarification is needed in the draft. It doesn't say what to do right now in the draft. Jean-Jacques - the most accurate info is the host info. And the client has to rely on this. Lionel - when no host, what do you do? Jean-Jacques - Use Realm-routing-request. It's a proposal on the table. Lionel - the question is, if you have only a realm report and you need to send to a specific specific host, do you apply realm or not? Jean-Jacques - If I have host info, do I need realm? If we solve agent overload and host, I think we're covered. Ben - agent overload use case - roaming, 2 admin domains won't share host info. The overload of realm and server may be different. Realm capacity may be low because a server is down but the rest of the servers are fine. If I have host, I use that first, but a problem with that is that we don't send Not-overloaded reports. We can send reports with reduction of 0%, we can think about that. I don't want to engineer at the mic. MCruz - Lionel's use case - realm plus host. Host takes precedence. If we don't have host, we don't have to do anything. Need to study those cases. Focus on the base draft. Generic case. Slide 8 - Behavior of Agent acting as reacting node Jouni - Still need to study what the error should be. One approach is to update the base specification. Ben - The 3rd bullet is only for noncompliant clients. Short of another bis draft, you cannot tell a non-compliant client to do something. We have to pick something in 6733, but they are not very good. Jouni - you could define behavior. Lionel from floor - we can try to use UNABLE_TO_COMPLY as a mechanism. It's about the clients receiving this info. TOO_BUSY is not invalid. Jouni - The server sends application answer with TOO_BUSY. Here the agent sends the error, it has different ABNF. Steve - the server would never see the request. The agent is throttling the request Jouni - needs to be defined. Ben - I'll back away of my previous statement - it would be good for the working group to go into what the errors mean. We see lots of different assumptions on what do to with these errors with our customers. General purpose clarifications would be useful. Steve - We have one or 2 choices - UNABLE_TO_COMPLY is the default. What if we create a response type that the client doesn't understand? Ben - I think the client would treat it as the base error. Lionel - which is UNABLE_TO_COMPLY. Jean-Jacques - Brining in info will modify client behavior. Not easy to introduce info. Too busy with realm question. The other question is the host case. We want to avoid rerouting - don't want the client to reroute if received from specific host. Ben - may look at UNABLE_TO_DELIVER. That might be the closest error. Slide 9 - Host report scope (all, single) Ben - I think the terminology is off. Only one reacting node gets a report, it may be an agent with lots of clients behind it. Jouni - do we need to indicate that? Ben - if the agent is the reacting node, does it send to one or all downstream nodes? Using the term "reacting node" here causes confusion. When the agent is a reacting node, it receives one overload report. Is that agent allowed to apply to other clients? Jouni - only that single one. Ben - I was thinking the other way. The agent should reduce all traffic to the host. Otherwise the agent keeps a lot of state. And the server would have to send a report for every client. Steve - My interpretation is that the overload report was global when the agent receives it. if we make the assumption that it applies just to single client, the agent will have to maintain state but the server will be sending the same thing to all the clients. Jouni - for single or all hosts, we can put in the draft. Steve - The agent would have to understand if the server was asking for a global reduction or if the overload report should be sent to specific client(s). Jean-Jacques - consider the target network. … we are free on the server side - it can decide to have global handling of clients or for specific clients. It's should be left to the implementation. In some circumstances, the agent has to act on behalf of the client. Can optimize the agent with the global report. It's an extension that covers the agents apart from base. Look at client and server impacts when dealing with agents. Minimize impact on target network. Keith - if you have a misbehaving entity, deal with it by other means. Steve - I strongly disagree that target network is just clients and servers. We need to cover all diameter nodes. Ben - if we have a network of clients and servers, or a network with clients, agents and servers, it's the same either way if our overload report applies to all nodes. Your relation is server to multiple clients - it doesn't create an additional burden on server. For a misbehaving client - one client sending a whole bunch of traffic - it may not be the right way to handle that. I've had customers and product management ask for that though. The node may not be misbehaving but just sending lots of traffic. Lionel - I"m against special handling misbehaving clients. It's ok to use the general mechanism with them. It's outside initial scope. Report the overload of a host or realm. It's a different topic. It could be handled at the connection level. Done in several ways. Its part of the discussion but misbehaving clients shouldn't be in scope. Ben - if we have a constituency that wants to use the overload mechanism to deal with it, it should be studied separately. Steve - Ulrich pointed out that 3GPP said that a server should be able to control individual clients. If that requirement goes away, we don't need this. I'm find with that. We've added a requirement midstream. MCruz - Should highlight when we need to make a distinction. We've already identified the client. There are certain situations that won't be covered. If the agent is a reacting node for a client - and the client is not compliant with DOIC or topology hiding. I sent a proposal to the list this morning. For reacting agent, make it apply to all clients to try to reduce complexity Ben - I'm seeing disagreement on endpoint concept. In my view, you cannot assume that the message gets to a particular client. One common deployment model is that the agents are reacting nodes, but the clients are DOIC compliant and are also reacting nodes for the agents. Unless we have a way to tell the agent to send a different message to a client. I don't think type 0 works. Lionel - we can propose on the list and deal with it in an extension. Steve - agree. Lionel - a new report type could be a way to handle this. ACTION: Propose on the mailing list that the type 0 Overload report should be an extension to the base draft. Slide 10 - OC-Supported-Features Handling Ben - I support the proposal Jean-Jacques - I support Jouni - room has rough consensus Ben - we closed one! Lionel - we'll put the agreement on the mailing list. ACTION: Post to the mailing list the OC-Supported-Features Handling proposal, (Reacting node advertises all supported algorithms; Reporting node responds with the single algorithm it will be using; Handling of other feature bits is defined in the extension drafts) which had consensus at the meeting. Slide 11 - OC-OLR Handling Lionel - I don't have an opinion. We have a single indication. Ben - I've been arguing that the OLR should describe what it is - I don't care if it's in the OLR or outside. It's only an issue of elegance. I'd like to have it in the report, so I can just look in the OLR for it. It can clarify the an algorithm's sub AVPs. Keith - you seem to be building in flexibility to change algorithm on the fly. Ben - no I'm not. I figure that algorithms will change when administrators change configurations. Can put in text to recommend this. But we're stateless, should give guidelines not to change algorithms on the fly. Our default algorithm is cheap, but for algorithms that have state, changing them becomes expensive. Jean-Jacques - What are we choosing? Steve - second bullet ACTION: Send to the mailing list the proposed closing of the OC-OLR handling issue with the second bullet (Single OC-OLR AVP used by all abatement algorithms with the meaning of the overload report indicated in the OC-Supported-Features AVP.) Slide 12 - Definition of overload control endpoints Jouni - need a conclusion here Ben - There are different assumptions people have made which are the root of many disagreements. I think both - I want hop-by-hop and end-to-end. A device that supports DOIC is an end point. I want to work with agents and without them. Jouni - Would you have two DOIC sessions - client-agent, client-server? Steve - That's one way to model it. If you model that a DOIC association is between a reacting and reporting node for the report type. YOu can have two separate associations - host report, realm report. Need to think about agent overload make sure it works for it as well. Do clients need know other end is an agent? Do Servers? Would need to add to the supported features negotiation, identify you are talking with an agent. Don't know if it's needed. In the agent overload case and the client doesn't support DOIC, what does the agent do? More questions than answers here. Jouni - this becomes more topical with e2e security. Ben - these are AVPs that can be modified. The case where the client has association with agent and server at same time is complicated, and is not in the draft. I don't want to set up a system where there is different behavior depending on the next hop because in the real world you don't know. If the agent supports DOIC, it's a B2BUA. If it supports it for some sessions but not others, then it is complicated. If an agent is going to support DOIC, then it must handle clients and servers. If does not want to do that, it shouldn't support DOIC at all, and let DOIC have only server-client associations. Slide 13 - End-to-end Definition Jean-Jacques - … Steve - I propose that we do a side-by-side comparison of end-to-end and hop-by-hop, do a gap analysis, list pros/cons. Ben - I think Jean-Jacques said that terminology needs to be clarified. I agree. Lionel - need to find the wording. If we agree at the DOIC association models. -------------------------------------------------------------------- 11:20 - 11:30 Next Steps: WG Chairs & ADs (10 minutes) WG Goals/Milestones status, next steps Lionel - need to share on mailing list what we agreed in this meeting as soon as possible. And Ben and steve to summarize on mailing list. ACTION: Ben and Steve to summarize on the mailing list.