Right. We have good pseudo-code for "how" the fee is changed. But no examples for what criteria are used to calculate "what they think the transaction fee should be." For example, how does a gateway implement this function:
int desiredFeePerTransaction (NetworkState s);
That's really up to them. I would say pretty much the only criterion is that transaction fees not be so high that they are a barrier to use and, ideally, not so low that they frequently need to be raised to control spam.
Do they raise the fee if "too many" transactions go through? Or do they raise if a lot of spam is coming through? For that matter, how do you identify a transaction as spam? The rationale given for the necessity of XRP is that it is "to prevent spam." I agree that spam is an issue. The first thing I would want to do is create a thousand self issued currencies called "BIGDIK" with an incrementing numbed appended to the end. How do we prevent this? How does a gateway recognize this as spam? Is it a manual process performed by the gateway operator poring over server logs? Is there a community website that gateway operators visit to hear the latest and greatest on how to combat spam?
You don't need to try to figure out if specific transactions are spammy or not. You just have to look at whether the total volume of transactions is within what the system can handle and also whether the cost of a transaction isn't unreasonably low when compared to the actual costs associated with processing a transaction.
A lot of talk has been given on the consensus model and the need for XRPs to prevent spam but nothing has been said on the exact methodology that a gateway will use to determine what an appropriate transaction fee will be, or even if the fee needs to change.
If the fee is so high that transactions are discouraged that the system could handle, it should be changed. If the fee is so low that the network is consistently overloaded and has to raise the fee dynamically, it should be changed.
Are you saying that bandwidth is the sole criteria for determining the fees? I don't see how that prevents spam at all.
Transaction spam is not like email spam. It doesn't annoy human beings directly. But it does cost bandwidth and reduce the remaining capacity of the network. The criteria is basically to make sure that transactions that cost more money to process (in terms of bandwidth and storage) than they are worth are discouraged without having to resort to dynamic changes in the transaction fee (because that makes fee and transaction clearing times less predictable).