Current (0.7.5) situation
Nodes do load management by accepting a lot of requests; on average, the bandwidth requirement of those requests falls within the available bandwidth limit. The node will only accept requests as long as it can complete *all* outstanding requests within some specified time period. That is, if node A accepts a request from B, it guarantees that within the next n seconds, it will have the bandwidth available to complete it.
The problem is that because of the low success rate, that period is long (90 seconds, iirc). If it were shorter, then the node would have too few requests outstanding, and too often too many of them would fail and it would have nothing useful to do with the bandwidth.
So instead we have a long bandwidth allocation window, which results in latency usually being high for serving a request.
Bulk / low-latency flag
So, with the new proposed (binary) flag, in bulk mode nothing would change from the current (0.7.5) situation, but there is a difference when using the low-latency flag.
In low-latency mode, the node would only accept the request if it had the bandwidth available to handle it within a much shorter window (let's say 5 seconds as opposed to 90). Then when a low-latency request did succeed, it would get preferential treatment and the success would be handled before outstanding data transmission on bulk requests.
An example:
case 1
* A sends B a low-latency request (meaning that A is asking for priority treatment for that request)
* B tries to serve that request from A within some short time period .
* B serves the request to A faster
Or alternatively:
case 2
* A sends B a low-latency request (meaning that A is asking for priority treatment for that request)
* B tries to serve that request from A within some short time period .
* B rejects the request, because B doesn't have the bandwidth available within that short time period
* A is forced to route the request to some less optimal node that can serve the low-latency request
* Some node N finally serves the low-latency-request from A
The tradeoff in using low-latency requests is that B has an increased likelihood of immediately rejecting the request because B doesn't have the bandwidth available for it. B may have enough bandwidth somewhere in a maximum time period of 90 seconds, but not within the next 5 seconds. Assuming that B is the best node for serving the request from node A, it will be more common that A has to try a different (presumably less optimal) route for the a low-latency request.
So setting the low-latency flag should cause the network to route faster, but less optimally. This will increase network overhead (more nodes will have to be queried for the data), and decrease the chance of finding the data. But, for data that is readily findable and where latency matters (like messaging apps), it should return results faster.
