Subject: [bmwg] draft-lencse-bmwg-benchmarking-stateful -- Re: bmwg Digest, Vol 199, Issue 15

From: Gabor LENCSE <[email-masked]>
Date: Tue, 1 Jun 2021 22:02:06 +0200

Dear Sudhin,

Thank you very much for your comment. Please see my answer inline.

On 5/25/2021 2:03 PM, Sudhin wrote:

[...]

>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 24 May 2021 13:51:44 +0200
> From: Edwin Cordeiro <[email-masked]>
> To: [email-masked], [email-masked]
> Subject: [bmwg] draft-lencse-bmwg-benchmarking-stateful
> Message-ID:
>    <CAERpkxBMxSsMZhSPHrRAptZkxyFPmMZfj=[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
> Dear authors of draft-lencse-bmwg-benchmarking-stateful,
>
> I agree with the motivation and ideas of the draft and I support its
> adoption.
>
> I recommend that the TCP considerations for such benchmarking methodology
> should not be left for a future document, as TCP still is the most used
> protocol. So, the details on TCP difficulties and an extension of this
> benchmark to consider TCP, should be in the scope of this document.
>
> Sudhin>>> Appreciate your feedback. Since the test focus on the Mac 
> addresses, the transport layer is beyond the scope of the 
> draft.(payload can be udp or tcp)
>
Yes, I agree with you that RFC 2544 tests focus on data link layer or 
network layer packet forwarding performance, however, in this special 
case transport layer is also involved in the sense that the connections 
are identified by using the five tuple of protocol number (TCP or UDP), 
source IP address, source port number, destination IP address, 
destination port number. The question is, whether using TCP or UDP makes 
a significant difference in the performance of the DUT. And currently I 
cannot answer to this question.

I am not sure how stateful NATxy gateways handle the different fields of 
TCP/UDP headers. If I were the implementer of such devices, I would try 
to do it as simple as possible. Identify the connection using the five 
tuple in a uniform way ( = the same way with UDP as with TCP ), handle 
some timeout, and that's all.  But they might look into some further 
fields of the TCP header, too. And then the behavior of the DUT may be 
different using TCP than using UDP as transport protocol.

We are aware of at least one difference, as we have mentioned it in 
Section 6:

    Stateful NATxy solutions handle TCP and UDP differently, e.g.
    iptables uses 30s timeout for UDP and 60s timeout for TCP.  Thus
    benchmarking results produced using UDP do not necessarily
    characterize the performance of a NATxy gateway well enough, when
    they are used for forwarding Internet traffic.  As for the given
    example, timeout values of the DUT may be adjusted, but it requires
    extra consideration.

Source: 
https://datatracker.ietf.org/doc/html/draft-lencse-bmwg-benchmarking-stateful#section-6

Best regards,

Gábor