Subject: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Sat, 3 Nov 2012 17:35:53 +0100

I have a few comments below.

>3. Diameter Node Behavior
...
>   OPEN ISSUE: SIP Overload Control includes a sequence parameter to
>   ensure that out-of-order messages do not cause the receiver to act on
>   state that is no longer accurate.  Is message reordering a concern in
>   Diameter?  That is, do we need to include sequence numbers in the
>   messages to ensure that the receiver does not act on stale state
>   information?  Because Diameter uses only reliable, in-order
>   transports, it seems that this isn't likely to be an issue.  Is there
>   room for a race when multiple connections are in use?

When using multiple streams in SCTP newer packets can overtake older ones if sent on different streams. But is is likely to be only at few seconds out-of-order, so I don't think it matters for load information.

>3.2. Diameter Client and Diameter Server Behavior
...
>   In order to allow recipients of overload information to perform
>   certain performance optimizations, we also define a new command flag,
>   called 'O'verload.  This bit, when set, indicates that the message
>   contains at least one Load-Info AVP with a non-zero Overload-Metric
>   -- in other words, the sending node is overloaded for at least one
>   context.  See Section 7.4 for the definition of the 'O'verload bit.

I don't think the O bit will be useful at all. In some diameter stacks it would be easiest to just insert Load-Info AVPs in all answers, thereby making the potential O-bit optimization useless.

>3.4. Proactive Load and Overload Communication
...
>   Similarly, in order to provide
>   peers the proper data for load distribution, nodes SHOULD send DWR
>   messages to a peer if the load information most recently sent to that
>   peer has changed by more than 20% and is more than 5 seconds old.

Doesn't the 5 seconds conflicts with RFC3539 section 3.4.1 which calls of minimum DW interval to be 6 seconds ?

Also, how was the values 20% and 5 seconds chosen?

>5.4. Overload-Info-Scope AVP
...

Is there any overwhelming reason for using this format? It would be more in the spirit of diameter to used a grouped AVP for this

Finally, I don't like the use of the words "drop" and "loss". I have seen at least one implementation that thinks diameter nodes can silently discard requests, and has therefore implemented timer-based retransmits instead of link-failure-based retransmits. Perhaps a note in the introduction that the word drop is to mean "respond with an error".