Subject: [Dime] diameter overload control requirements review

From: jouni korhonen <[email-masked]>
Date: Thu, 22 Nov 2012 16:28:12 +0200

Hi,

I have briefly reviewed draft-ietf-dime-overload-req-00 again. Sorry for
the extended delay! Some comments beflow:

Section 2.3.  Interconnect Scenario

 o Explain IPX and provide appropriate references so that the reader
   can get the context.

Section 4. Existing Mechanisms

 o I would also add DPR with Disconnect-Cause=DO_NOT_WANT_TO_TALK_TO_YOU
   discussion here. IMHO it is also valid mechanism, though a bit cruel.

Section 5.2.  Problems with Explicit Mechanisms

 o See the DPR above.

 o Then a flow of mind/thinking.. since protocol level errors like
   DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY are delivered using
   a specific CCF, why cannot we just put overload whatever information
   there? That would be a better than nothing approach to tackle a class
   of overload cases. Basically one could add AVPs that describe specifically
   why DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY took place and 
   what need to be done to get over that situation. And these errors can
   be sent by any intermediate Diameter node, not just the end points. I
   think we need to cover these errors a bit better than just saying they
   are no usable. (the additional data falls into *[AVP] wildcard in the
   error response and is understood by the receiver or then not..)

6.1.  Overload in Mobile Data Networks

 o I'd like to see quite a few references here.. 23.002, 29.272, 29.002,
   IR.92, ..

 o PCC and IMS seem to have been skipped here (except indirectly covered by
  VoLTE).

Section 7. Solution Requirements

 o Req 2: I would also add here that the solution MUST NOT have assumptions
   on how some applications are _implemented_ today compared how they are
   specified.

 o Req13: related to this, I would also have some text here or on some other
   requirement regarding the additional size overhead introduced by the
   overload mechanism. That must also be taken into account.

 o Req18: How do you prevent other from benefiting? Say, the others do the
   work and the ones that do not still get the benefit network not being
   overloaded in general.. and they do not need to move a limb.

 o Req21: I see the intention but how do you qualify some node meets the
   requirement? To me this requirement equals to implicit mechanisms i.e.
   the other end does not really respond so it probably i having issues.
   Typically the other ends start resending, which just worsens the
   situation, right?

 o Req28: The lack of e2e security makes this requirement hard to meet. 
   Also, would this mean we need a way to prove the authenticity of the
   provided overload information? What would be the cost of that?

Section 9. Security Considerations

 o Quite a few of these vulnerabilities boil down to the fact that we
   cannot prove the ownership & authenticity of the provided overload
   control information. I would state that there..

- JOuni

---

From: jouni korhonen <[email-masked]>
Date: Thu, 22 Nov 2012 20:37:35 +0200

> I have briefly reviewed draft-ietf-dime-overload-req-00 again. Sorry for
                                                      ^^^
meant -01

- Jouni

[snip]

---

From: Eric McMurry <[email-masked]>
Date: Mon, 26 Nov 2012 19:17:43 -0600

Thanks Jouni!  Comments are greatly appreciated.

commentary inline.

> o Explain IPX and provide appropriate references so that the reader

Is that level of detail necessary to get the use case across?  Perhaps you have some text you would like to include here?

>   discussion here. IMHO it is also valid mechanism, though a bit cruel.

agree, I'll add that to the discussion.  I think BUSY may be a better disconnect cause for this case though, right?  The effects are the same either way.

> Section 5.2.  Problems with Explicit Mechanisms

yep

>   error response and is understood by the receiver or then not..)

I agree that work needs to be done on the error responses.  I don't think that would be sufficient to cover overload control though and I have been thinking of this as a different problem.  The lack of information on the error responses that can be used for overload control is only one of the issues with them.  A separate effort to fix those would be worthwhile.

> o I'd like to see quite a few references here.. 23.002, 29.272, 29.002,

Well, those will certainly send anyone not familiar with 3GPP stuff down a rat hole...

thanks for pointing that section out.  I had forgotten that there was still a note in there about needing citations.

> o PCC and IMS seem to have been skipped here (except indirectly covered by

I can add a bit more here.  You are wanting to beef up the info showing how much use of Diameter (and subsequently, the impact of overload) there is in mobile networks? 

>   on how some applications are _implemented_ today compared how they are

sounds reasonable.  Are you thinking about relays here? I think it is still relevant question wether a pure relay is an element that will ever be used.

>   overload mechanism. That must also be taken into account.

doesn't this get captured by the not introducing substantial additional work bit?  it seems to be a derivative.  If the size overhead is large, that would introduce additional work, right?

>   overloaded in general.. and they do not need to move a limb.

this one is tricky.  It comes straight from the SIP overload control requirements (RFC 5390) so perhaps someone from that group can better answer this (Janet, Eric?).  I believe that the goal is not to prevent benefit to elements that do not support the mechanism.  Rather, it is to require the mechanism attempt to treat those elements fairly with respect to the elements that do support the mechanism.

One hopes that having some elements in a network that do support an overload control mechanism will benefit all of the network.

>   Typically the other ends start resending, which just worsens the

An overload control mechanism will have to consider and handle this case and the requirement is more for the mechanism than a node that implements it.  It would be possible to design a mechanism that did just what you are suggesting and started resending, which would indeed cause a worsening of the situation.  I think this requirement is there to ensure that a compliant mechanism has considered this and that it specifies rational behavior when this happens.

>   provided overload information? What would be the cost of that?

perhaps someone should work on e2e security ;-)

I agree this would be difficult for e2e overload signaling.  It's important though because the potential harm from attacks goes up substantially with an overload control mechanism in place.  A single malicious message could deny large amounts of service.

>   control information. I would state that there..

okay, I will add some text to that effect in the summary.

> 
> - JOuni
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: jouni korhonen <[email-masked]>
Date: Tue, 27 Nov 2012 13:32:57 +0200

Eric,

See responses inline.

> Is that level of detail necessary to get the use case across?  Perhaps you have some text you would like to include here?

I would only say something along the lines:

   IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that provides
   roaming interconnection network between mobile operators and service
   providers. The IPX is also used to transport Diameter signaling between
   operators [IR.88].

Feel free to modify & shorten.

> agree, I'll add that to the discussion.  I think BUSY may be a better disconnect cause for this case though, right?  The effects are the same either way.

Ok.

> I agree that work needs to be done on the error responses.  I don't think that would be sufficient to cover overload control though and I have been thinking of this as a different problem.  The lac…

This would be good to point out.

> I can add a bit more here.  You are wanting to beef up the info showing how much use of Diameter (and subsequently, the impact of overload) there is in mobile networks? 

Something towards that direction. I could/would add more weight to our
requirements doc.

> sounds reasonable.  Are you thinking about relays here? I think it is still relevant question wether a pure relay is an element that will ever be used.

Actually I was not thinking about relays. Just in general. It is so
easy to draw conclusions with the few implementations one is familiar
with.

> doesn't this get captured by the not introducing substantial additional work bit?  it seems to be a derivative.  If the size overhead is large, that would introduce additional work, right?

Could be. I am fine whatever you do here.. or choose not to do.

> One hopes that having some elements in a network that do support an overload control mechanism will benefit all of the network.

Right. Maybe someone who contributed to SIP overload can shift their
ideas & reasoning on this requirement into this document?

> An overload control mechanism will have to consider and handle this case and the requirement is more for the mechanism than a node that implements it.  It would be possible to design a mechanism th…

Ok.

> I agree this would be difficult for e2e overload signaling.  It's important though because the potential harm from attacks goes up substantially with an overload control mechanism in place.  A sing…

Maybe we just need to point out the lack of e2e security and its implications
regarding this requirement? That's like one sentence or so.

> okay, I will add some text to that effect in the summary.

\o/

- Jouni

---

From: Eric McMurry <[email-masked]>
Date: Tue, 27 Nov 2012 11:22:57 -0600

Thanks Jouni.

inline.

On Nov 27, 2012, at 5:32 , jouni korhonen <[email-masked]> wrote:

[...]

> Feel free to modify & shorten.

Thanks!

> This would be good to point out.

ack.  will do.

> Something towards that direction. I could/would add more weight to our

okay

> easy to draw conclusions with the few implementations one is familiar

okay

> regarding this requirement? That's like one sentence or so.

okay