Subject: [bmwg] Rx Window question - Benchmarking Methodology for Network Security Device Performance

From: "Brian Monkman" <[email-masked]>
Date: Wed, 13 Feb 2019 04:43:53 -0500

Folks,

We are making some changes to the draft before we submit it for review.
These changes have resulted from our proof of concept testing.

One question is the Receive Window size. Currently in the draft it is 32k.
This appears to be too small for the real world. While researching what we
should use, we determined that there does not appear to be anything
approaching a defacto standard or even a good solid reference.

We have determined that the default receive window size for Windows
operating system is 64k. While many Linux variants use 128k.

So, my question to use is this.. What do you think should be used? The way I
see it our choices are:

1.	64k
2.	128k
3.	64k or 128k (choice made by the tester and documented if the results
are made public)

Thoughts or alternate suggestions anyone?

Thank you in advance.

Brian

---------

Brian Monkman

Executive Director, NetSecOPEN

Office: +1-717-610-0808 

Fax: +1-717-506-0460

Mobile: +1-717-462-5422

https://www.netsecopen.org

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 13 Feb 2019 13:47:46 +0000

Hi Brian,
Thanks for following up on this point.
64k is likely to be a "safer" answer than 32k.

It's important to consider that you are setting the
Max Receive Window size limit in octets.

I think we simply want to ensure that none of the
TCP connections are operating in a Rcv Window-limited
state.

The (max)buffering in the Firewall and the link speeds
are critical factors you need to determine if a
Max Rcv Window size is sufficient to avoid limiting the connections.
Then calculate the Bandwidth-Delay Product:
https://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl
(scroll down a bit).

The Bottom Line: you don't want the TCP streams to
operate in a "receive window-limited"  mode.
It's probably best to give connections more window than they need,
and also not try to tune to a specific window size exactly.

The congestion control algorithm, etc., also matters.
All the relevant TCP options need to be specified in the
report.

hope this helps,
Al

From: bmwg [mailto:[email-masked]] On Behalf Of Brian Monkman
Sent: Wednesday, February 13, 2019 4:44 AM
To: [email-masked]
Cc: 'Bala Balarajah' <[email-masked]>
Subject: [bmwg] Rx Window question - Benchmarking Methodology for Network Security Device Performance

Folks,

We are making some changes to the draft before we submit it for review. These changes have resulted from our proof of concept testing.

One question is the Receive Window size. Currently in the draft it is 32k. This appears to be too small for the real world. While researching what we should use, we determined that there does not appear to be anything approaching a defacto standard or even a good solid reference.

We have determined that the default receive window size for Windows operating system is 64k. While many Linux variants use 128k.

So, my question to use is this.... What do you think should be used? The way I see it our choices are:

  1.  64k
  2.  128k
  3.  64k or 128k (choice made by the tester and documented if the results are made public)

Thank you in advance.

Brian

---------
Brian Monkman

https://www.netsecopen.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.netsecopen.org&d=DwQFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=MUT1uFtEFACP5dPictqITC0x73ATrx-6JiMM27LUEec&s=psg1BM6BBwPGSBmCvxknTKCUncFWebs8hJVUHuc42mA&e=>

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Feb 2019 15:06:46 +0000

Hi,

For our end-to-end performance work, we commonly cite the ESnet guidance on tuning:
https://fasterdata.es.net/host-tuning/

It's interesting that firewall buffering is mentioned below; in general the higher volume research data transfers over R&E networks recommend routing around the campus "business" firewall and applying security policy more appropriately to the science/research traffic.  Generally following the "Science DMZ" approach, as per https://fasterdata.es.net/science-dmz/.

I'm not sure what the benchmarking document in this WG considers in scope, but it would be interesting to be able to test a commercial firewall's ability to pass a small number of high throughput, high pps flows while also performing more detailed inspection on tens of thousands of "business" traffic flows (web, email, ...).  The inability for many commercial firewalls to do that well is exactly why ESnet published their Science DMZ model.

Tim

On 13 Feb 2019, at 13:47, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,
Thanks for following up on this point.
64k is likely to be a “safer” answer than 32k.

It’s important to consider that you are setting the
Max Receive Window size limit in octets.

The Bottom Line: you don’t want the TCP streams to
operate in a “receive window-limited”  mode.
It’s probably best to give connections more window than they need,
and also not try to tune to a specific window size exactly.

hope this helps,
Al

To: [email-masked]<mailto:[email-masked]>

Folks,

So, my question to use is this…. What do you think should be used? The way I see it our choices are:

  1.  64k
  2.  128k

Thank you in advance.

Brian

---------
Brian Monkman

_______________________________________________
bmwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bmwg

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 13 Feb 2019 15:20:41 +0000

Thanks for your comments, Tim.

I also think that handling “a small number of high throughput,
high pps flows while also performing more detailed inspection
on tens of thousands of "business" traffic flows (web, email, ...)”
is a use case worth considering in this work. It certainly
applies beyond the science and/or research communities.

We may wish to include WAN delay emulation, to see this
testing in a very practical light. TCP’s flow-control loop
encourages this: it would be overly optimistic to operate
all the TCP tests with single millisecond RTT.

Al
(as a participant, I forgot to remove my hat in this thread,
please consider it *off* throughout)

From: Tim Chown [mailto:[email-masked]]
Sent: Wednesday, February 13, 2019 10:07 AM
To: MORTON, ALFRED C (AL) <[email-masked]>
Cc: Brian Monkman <[email-masked]>; [email-masked]; Bala Balarajah <[email-masked]>
Subject: Re: [bmwg] Rx Window question - Benchmarking Methodology for Network Security Device Performance

Hi,

For our end-to-end performance work, we commonly cite the ESnet guidance on tuning:
https://fasterdata.es.net/host-tuning/<https://urldefense.proofpoint.com/v2/url?u=https-3A__fasterdata.es.net_host-2Dtuning_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Xh7g-ElysG8YNTvMEgaaUhBRqNYroResNGfodBzAK-c&s=W6aLsZtM-DFRR85CzBZYx1fxFU_2Y_O3sCvJb0ZXEcA&e=>

It's interesting that firewall buffering is mentioned below; in general the higher volume research data transfers over R&E networks recommend routing around the campus "business" firewall and applying security policy more appropriately to the science/research traffic.  Generally following the "Science DMZ" approach, as per https://fasterdata.es.net/science-dmz/<https://urldefense.proofpoint.com/v2/url?u=https-3A__fasterdata.es.net_science-2Ddmz_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Xh7g-ElysG8YNTvMEgaaUhBRqNYroResNGfodBzAK-c&s=pgHa-sAbGqhN1g__RKi_D8KVEltq-ZxGcJDe9ECMXu0&e=>.

Tim

Hi Brian,

https://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.slashroot.in_linux-2Dnetwork-2Dtcp-2Dperformance-2Dtuning-2Dsysctl&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Xh7g-ElysG8YNTvMEgaaUhBRqNYroResNGfodBzAK-c&s=JPniL1dH3uZYuMpHpu_Esv5lOPPpfzswKq9sPtU23FQ&e=>
(scroll down a bit).

hope this helps,
Al

Cc: 'Bala Balarajah' <[email-masked]<mailto:[email-masked]>>

Folks,

  1.  64k
  2.  128k

Thank you in advance.

Brian

---------
Brian Monkman

_______________________________________________
bmwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bmwg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bmwg&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=Xh7g-ElysG8YNTvMEgaaUhBRqNYroResNGfodBzAK-c&s=oJIewY-1p0gAhvP81Yn97wY0_SglurguW34y5HSsVUo&e=>