Minutes for DIME at IETF-92
minutes-92-dime-1

DIME WG IETF 92
WEDNESDAY, March 25, 2015
0900-1130  Morning Session I (150 mins)
Oak

Chairs:
Jouni Korhonen <jouni.korhonen at broadcom.com>
Lionel Morand <lionel.morand at orange.com>

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 - <couldn't hear the comment>

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 - <missed the comment>

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.

<ran out of time for the rest of the slides.>

JJ (??) - Back to slide 14 - <missed it>

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. <missed why>

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 - <missed>

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 <missed>

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?

<silence>

Lionel - we can set up conference call at any time