[bmwg] the potential falsifying effect of storing the requests in a large queue -- Re: WG Adoption Call: Stateful NATxy Gateways using RFC 4814

[Gabor LENCSE <[e-mail]>]

Dear Al,

Let me answer to this part now:

> It seems plausible that the connection tracking table might be larger 
> than the number of successful connections established when setting-up 
> connections at the maximum rate, R. In other words, a derating factor 
> (like the alpha factor you use during connection validation) on 
> Initiator sending rate
>
> r=R*alpha
>
> might result in counting a larger number of successful connection 
> tracking table entries. I can imagine that there might be a queue to 
> establish connections, and rate R does not exhaust the queue, but at 
> R+beta the queue overflows and some connections attempts fail, there 
> might still be unoccupied space in the connection tracking table.
>
I am not sure if you thought the same thing, but it reminded me an old 
experience at the time of writing the draft for RFC 8219.

As for DNS64 benchmarking, 1s second timeout was allowed (and 
individually checked) for every single query. Some of the tested DNS64 
server implementations were able to store the requests and thus exhibit 
somewhat higher performance. E.g. using in a 60s long test, answering 
the requests in 61 seconds may give more than 1% extra performance. This 
is not very bad, but using much shorter tests (e.g. 10s long) could 
result in more cheating. Please see all the details in:

G. Lencse, M. Georgescu, and Y. Kadobayashi, "Benchmarking Methodology 
for DNS64 Servers", /Computer Communications/ (Elsevier), vol. 109, no. 
1, pp. 162-175, September 1, 2017, DOI: 10.1016/j.comcom.2017.06.004
Revised version in PDF 
<http://www.hit.bme.hu/~lencse/publications/ECC-2017-B-M-DNS64-revised.pdf> 
(the link gives you the revised version of the paper)

(Table 3 shows results for rather extreme cases, e.g. 5 seconds trial 
duration and 5 seconds timeout.)

The same thing may happen here, too. For example, I used a relatively 
low number of connections (4M) to speed up experimenting with Jool, when 
I tested, how connection validation works. Please see the results here:

https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-transition-scalability#section-3.6

It is deliberate from the data, that the filling of the connection 
tracking table lasted less than 10 seconds (4,000,000/478,417) and I 
used 500ms (that is 0.5s) global timeout.

If Jool is able to enqueue a high number of requests then the measured 
values may be somewhat false.

Of course, this effect is negligible, when the timeout is at least two 
order of magnitude less than the time needed to fill all the connections 
into the connection tracking table.

Best regards,

Gábor