Re: [bmwg] WG Adoption Call: Stateful NATxy Gateways using RFC 4814

[Gabor LENCSE <[e-mail]>]

Dear Al,

Thank you very much for review and comments. Please see my answers inline.

On 7/21/2022 1:50 AM, MORTON JR., AL wrote:
[...]
>
> The current procedure intends to validate the connection table 
> capacity at the maximum establishment rate, R.That’s a good thing to 
> do.I think the procedure needs a section where you configure the idle 
> connection time-out to be sufficiently long that all the previously 
> established connections are still in the table.
>
Yes. We addressed the question of timeout in Section 4.4 
https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful#section-4.4

As here the validation is performed in the real test phase, the relevant 
part if Section 4.4 is as follows:

    The second extreme situation can be achieved by

    *  enumerating all the possible source port number destination port
       number combinations in the preliminary phase and

    *  setting the UDP timeout of the NATxy gateway to a value higher
       than the length of the preliminary phase plus the gap between the
       two phases plus the length of the real test phase.

Is it enough if we add a sentence to the "Notes" of Section 4.6 that 
refers to Section 4.4 regarding the timeout?

I recommend this one:

    *  Please refer toSection 4.4  <https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful#section-4.4>  regarding the setting of the proper
       timeout value in the case of the "second extreme situation".

It would go just before the one you cite below.

> We need access to the idle time-out in the DUT, to be sure timers are 
> not expiring during a test when you are sending validation frames a 
> rate less than R, r=R*alpha (where alpha < 1). Or at least we need to 
> know the time-out value. We might have to test for it.
>
> *The order of four tuple selection is arbitrary provided that all
>
> four tuples MUST be used.
>
> This stipulation of arbitrary order means that the earliest connection 
> **might be tested last** in the validation phase. The connection 
> time-out duration MUST take this into account.
>
Yes, it is true. The above condition guarantees the high enough timeout 
for the worst case, if a connection is established at the very beginning 
of the preliminary phase and it is validated at the very end of the real 
test phase.

As for your further comments, I will need to think about them a little 
bit more as some of them seem to be quite tricky. :-)

I try to answer at least some of them before our meeting on Tuesday.

Best regards,

Gábor