Subject: [Dime] DOIC 05 Issues

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Nov 2014 23:18:51 -1000

Hi,

I've done a new review of version 05 (not 04) of the DOIC draft, as it was in the GitHub a of Saturday morning. I have some editorial comments I think can be dealt with offline, but I think the following comments probably need some group discussion.

Thanks!

Ben.
--------------------------------------

-- section 3, and other places:

We are inconsistent on what we mean by abatement, especially in terms of abating across a set or stream of messages, vs applying abatement to a message. I think we want the idea of applying abatement, or an abatement "treatment" to a message or a set of messages means that we have made that message or set of messages a _candidate_ for throttling or diversion, based on the abatement algorithm. That's not the same thing as saying that a message was rejected or diverted.

We have places in the draft where we use it this way, but other places (e.g. in the "loss" definition", where we say that we apply an abatement treatment when we actually reject or divert.

So I think if we say, for example, if we apply abatement using the loss algorithm and a 20% reduction, to a set, we mean that set has 20% of the messages rejected or diverted. If we say we apply it to a single message, we mean that message has a 20% chance of being rejected...

-- section 3.2:

We say the first node in the path that supports DOIC inserts OC-S-F. We have enough cases where insertion (or modification) may occur elsewhere that I think we'd be better off saying "A node that supports DOIC inserts..." without worrying about where it is in the path.

The description of how a node indicates support for "loss" is not completely consistent with section 5.

In general, I think this section tries to over specify when and why an agent might insert, modify, or remove OC-S-F. We've discussed that any agent doing these things can probably be considered a proxy, and we can't really control when a proxy might do these things.

The 5th paragraph describes the way the reporting node selects the algorithm as being the "one exception" from having nodes indicate everything they support. I think there may be other exceptions in future extensions--such things should be left to the extension definitions.

-- 3.3, third paragraph from end: "The method used for that abatement is dependent on the abatement algorithm" 

I think the algorithm decides how many requests are abated, not _how_ they are abated. We could think of the algorithm as a selection mechanism.

-- 3.4, last paragraph:

Why do we assume all extensions must be announced? What if we had an extension that added some new AVP that is safe to ignore, would we have to have a feature bit for it?

-- 4.1.1, 5th paragraph:

Do we expect the feature sets to differ between applications,  or do we envision supporting some feature for some transactions but not others in the _same_ application?

-- 4.1.2, 2nd paragraph:

The text only requires the reacting node to include OC-S-F if the reacting node included it. Didn't we decide to always require the reporting node to explicitly indicate the selected algorithm?

-- 4.1.2, paragraph 4: "subsequent answer messages"

We say the reporting node acts "accordingly  for the subsequent answer messages it initiates". This is really per-transaction, right? Do we have a rule that prevents a reactor from changing its support between transactions? Does the reporter care about anything except what came in this transaction?

Do we need guidance about changing algorithms when not overloaded?

-- 4.1.3, paragraph 1:

The text implies that agents SHOULD act on behalf of non supporting nodes. I think that's entirely an implementation and deployment choice. I suggest we change this to MAY.

-- 4.2.1.3, paragraph 6: "...MUST determine if the OLR is a retransmission or an update ..."

That doesn't sound right. The sequence number was supposed to be an optimization to allow the reactor to ignore certain reports. There's no reason it couldn't do this by simply treating each report as if it were an update. If that's not true, then we've broken something.

-- 4.2.1.4, paragraph 3:

Is there any reason not to just always start the sequence number at 1 (or 0)?

-- ... paragraph 4: " the new sequence number MUST be greater than any sequence number in an active (unexpired) overload report previously sent by the reporting node"

Any report? Or just any matching report? I.e. What if there are reports of different types? How does this work if the reporting node is an agent in some cases and a server in others?

-- 4.2.2, last paragraph:

Can we elaborate on what it means to end abatement in a "controlled fashion"?

-- 4.2.3, 2nd paragraph

The text says you SHOULD keep resending an OLR in response to requests that match the related OCS. I'm afraid people will read that to limit sending OLRs to requests that match the report-type.

-- ..., paragraph 9: " RECOMMENDED that the reporting node always explicitly indicates the end of a overload condition"

I still disagree with this. We want to make the reporter end the overload condition in a timely manner. Why do we care how, as long as it's timely?

-- 6.5, first paragraph:

The default duration should be a value we think we be very common. 5s seems a bit short.

-- 6.6, definition of "host report"

This does not include the "node has some other local knowledge of the server selection" case that I thought had been discussed. (I thought we were going to have this section refer to the definition of host-routed and realm-routed requests, rather than restate things? )

-- 6.7, last paragraph: "The default value of the OC-Reduction-Percentage AVP is 0.  When the OC-Reduction-Percentage AVP is not present in the overload report, the default value applies"

This is inconsistent with the definition of the loss algorithm, which says the AVPS must always be included. Some other algorithm might make it optional, and two such algorithms might have different details, so I suggest we leave this up to algorithm definitions, and don't mention it here.

-- 6.8, last paragraph, last sentence:

I thought we agreed to remove all guidance for use of the M-Bit, and just refer to 6733 rules.

-- 8.2:

We probably need a bit more detail about what goes into the registry, especially for the 2nd one. I assume we don't mean for the verbose description of report types, for example, to go in. It would help to list the information elements that we expect to actually show in the registries.