Re: [Dime] Review of

[Eric McMurry <[e-mail]>]

On Jul 25, 2013, at 14:50 , Alan DeKok <[e-mail]> wrote:

> Eric McMurry wrote:
>> I understand your point about out of band.  That would make sense for several reasons.  However, using the existing protocol is highly desirable since it is already in place and can support this.
> 
> Using the existing protocol is fine.  I'm just wary of overloading a
> link-layer QoS protocol, and turning into a multi-hop routing protocol.
> 
> It would be better (IMHO) to signal routing changes independent from
> link changes.

I'm still a bit lost here.  This signaling piggybacks directly in Diameter messages and doesn't define any link or transport protocols.  It does not signal link changes or routing changes.  Can you point me to the language in the draft that is giving that impression?

> 
>> so having the introduction of the new bit in the higher level behavior section was the source of confusion?
> 
> Yes.  If the first use of "overload metric" assumes you know the
> meaning, it's confusing.  e.g. Section 1.3 says:
> 
>  ... Overload-Metric (which is input to the negotiated
>  load abatement algorithm).
> 
> It might as well be called "foo".  It's an opaque input parameter,
> with no meaning, and no context.
> 
> I find it clearer to lay out the document by introducing a concept,
> defining it, giving a hint as to how it's used, and then later using it
> in a more complex context.
> 
>> yes, Diameter clients are different.  They tend to be sophisticated servers doing a number of functions with Diameter being used for some of their control signaling.  Their other functions usually require the use of other protocols and they may have to consider information in making overload control decisions that servers do not have.  The requirements draft may be helpful for describing the problem domain for this (http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-09)
> 
> I scanned it.  I'll take a deeper look.

understood.  It was a good review for a scan.  I wasn't complaining, just trying to answer your question.

> 
>> As far as what to do with it, not specifying that was intentional.  What to do with load information is implementation specific.
> 
> Then I'm not sure why this document is useful.  It would seem to be
> useful to describe both the data, and how the data is used.

There is more than one thing going on here.  I was talking about the load information used for proactive mitigation.  The document also describes overload control information which has more constraints on its usage.

> 
>>> This section is a bit opaque to me.  It's not clear *why* these
>>> calculations are being done.  I presume it's taking a convolution of the
>>> suggested load distribution with the servers current load.  But it's not
>>> clear.
>> 
>> this example just uses the load information to scale SRV weights, so you have the gist of it.  It is non-normative and just an example of how load information can be used.  Perhaps some of the discussed name changing will help illustrate that the load information usage is different than the reactive overload control information.
> 
> I was looking for an English explanation of what was going on.  Right
> now, the calculation looks a lot like:
> 
> A = 5
> B = 6
> C = 10
> 
> D = A * B / C + 2*A
> E = D^A + C
> 
> ??? OK, that's nice.  WHY is this being done?  What does it mean?

Does the text in 3.4 talking about proactive mitigation help with this?

> 
>> you're not the only one to think that :-)  we have to pick a default algorithm to use and drop has the nice characteristic of being quite simple.  What actually happens here is up for debate.
> 
> Traffic is bursty.  Let's say a server gets a burst of 100Mbps
> traffic.  It signals to the client "drop traffic by 90%".  By the time
> the message makes it to the client, the burst is over.  Traffic is down
> to 5Mbps.  So the client happily caps it at .5Mbps, which is not what
> the server wanted.
> 
> Signaling a percentage drop is meaningless, because it's taken at a
> time on the server.  The client doesn't know when that measurement was
> done on the server.
> 
> So either you signal "percentage drop AND (servers' load OR server
> time)", or you just signal "limit traffic to X bps".  Both have the same
> effect.  The second is simpler.

This depends entirely on the traffic mix and the number of clients.  In some cases it is true, in others (i.e. less bursty traffic, large numbers of clients, ...), it is not.  I don't disagree that rate based control would be better in many instances.  It requires more consideration for the types of use cases and topologies that are expected to be typical (similar to what happened in SIP overload as Janet pointed out).  Of course, either one may not be appropriate in some cases, which is why it's extensible.  Thanks for the vote on rate based.  I think there will be more discussion on this coming from several folks.