9 files changed, 154 insertions, 19 deletions
diff --git a/website/_config.yml b/website/_config.yml
index dc44945bc..5f1cbbdeb 100644
--- a/website/_config.yml
+++ b/website/_config.yml
@@ -44,3 +44,6 @@ authors:
   mpratt:
     name: Michael Pratt
     email: mpratt@google.com
+  nybidari:
+    name: Nayana Bidari
+    email: nybidari@google.com
diff --git a/website/archive.key b/website/archive.key
index 1a91698bf..8946884a7 100644
--- a/website/archive.key
+++ b/website/archive.key
@@ -11,19 +11,19 @@ lzqkT3VSMXieImTASosK5L5Q8rryvgCeI9tQLn9EpYFCtU3LXvVgTreGNEEjMOnL
 dR7yOU+Fs775stn6ucqmdYarx7CvKUrNAhgEeHMonLe1cjYScF7NfLO1GIrQKJR2
 DE0f+uJZ52inOkO8ufh3WVQJSYszuS3HCY7w5oj1aP38k/y9zZdZvVvwAWZaiqBQ
 iwjVs6Kub76VVZZhRDf4iYs8k1Zh64nXdfQt250d8U5yMPF3wIJ+c1yhxwARAQAB
-tCpUaGUgZ1Zpc29yIEF1dGhvcnMgPGd2aXNvci1ib3RAZ29vZ2xlLmNvbT6JAlQE
-EwEKAD4WIQRvHfheOnHCSRjnJ9VvxtVU4yvZQwUCXSZ4BgIbAwUJA8JnAAULCQgH
-AgYVCgkICwIEFgIDAQIeAQIXgAAKCRBvxtVU4yvZQ5WFD/9VZXMW5I2rKV+2gTHT
-CsW74kZVi1VFdAVYiUJZXw2jJNtcg3xdgBcscYPyecyka/6TS2q7q2fOGAzCZkcR
-e3lLzkGAngMlZ7PdHAE0PDMNFaeMZW0dxNH68vn7AiA1y2XwENnxVec7iXQH6aX5
-xUNg2OCiv5f6DJItHc/Q4SvFUi8QK7TT/GYE1RJXVJlLqfO6y4V8SeqfM+FHpHZM
-gzrwdTgsNiEm4lMjWcgb2Ib4i2JUVAjIRPfcpysiV5E7c3SPXyu4bOovKKlbhiJ1
-Q1M9M0zHik34Kjf4YNO1EW936j7Msd181CJt5Bl9XvlhPb8gey/ygpIvcicLx6M5
-lRJTy4z1TtkmtZ7E8EbJZWoPTaHlA6hoMtGeE35j3vMZN1qZYaYt26eFOxxhh7PA
-J0h1lS7T2O8u1c2JKhKvajtdmbqbJgI8FRhVsMoVBnqDK5aE9MOAso36OibfweEL
-8iV2z8JnBpWtbbUEaWro4knPtbLJbQFvXVietm3cFsbGg+DMIwI6x6HcU91IEFYI
-Sv4orK7xgLuM+f6dxo/Wel3ht18dg3x3krBLALTYBidRfnQYYR3sTfLquB8b5WaY
-o829L2Bop9GBygdLevkHHN5It6q8CVpn0H5HEJMNaDOX1LcPbf0CKwkkAVCBd9YZ
-eAX38ds9LliK7XPXdC4c+zEkGA==
-=x8TG
+tCpUaGUgZ1Zpc29yIEF1dGhvcnMgPGd2aXNvci1ib3RAZ29vZ2xlLmNvbT6JAk4E
+EwEKADgCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQRvHfheOnHCSRjnJ9Vv
+xtVU4yvZQwUCYO4TxQAKCRBvxtVU4yvZQ9UoEACLPV7CnEA2bjCPi0NCWB/Mo1WL
+evqv7Wv7vmXzI1K9DrqOhxuamQW75SVXg1df0hTJWbKFmDAip6NEC2Rg5P+A8hHj
+nW/VG+q4ZFT662jDhnXQiO9L7EZzjyqNF4yWYzzgnqEu/SmGkDLDYiUCcGBqS2oE
+EQfk7RHJSLMJXAnNDH7OUDgrirSssg/dlQ5uAHA9Au80VvC5fsTKza8b3Aydw3SV
+iB8/Yuikbl8wKbpSGiXtR4viElXjNips0+mBqaUk2xpqSBrsfN+FezcInVXaXFeq
+xtpq2/3M3DYbqCRjqeyd9wNi92FHdOusNrK4MYe0pAYbGjc65BwH+F0T4oJ8ZSJV
+lIt+FZ0MqM1T97XadybYFsJh8qvajQpZEPL+zzNncc4f1d80e7+lwIZV/al0FZWW
+Zlp7TpbeO/uW+lHs5W14YKwaQVh1whapKXTrATipNOOSCw2hnfrT8V7Hy55QWaGZ
+f4/kfy929EeCP16d/LqOClv0j0RBr6NhRBQ0l/BE/mXjJwIk6nKwi+Yi4ek1ARi6
+AlCMLn9AZF7aTGpvCiftzIrlyDfVZT5IX03TayxRHZ4b1Rj8eyJaHcjI49u83gkr
+4LGX08lEawn9nxFSx4RCg2swGiYw5F436wwwAIozqJuDASeTa3QND3au5v0oYWnl
+umDySUl5wPaAaALgzA==
+=5/8T
 -----END PGP PUBLIC KEY BLOCK-----
diff --git a/website/assets/images/2021-08-31-rack-figure1.png b/website/assets/images/2021-08-31-rack-figure1.png
new file mode 100644
index 000000000..6d9fdb147
--- /dev/null
+++ b/website/assets/images/2021-08-31-rack-figure1.png
diff --git a/website/assets/images/2021-08-31-rack-figure2.png b/website/assets/images/2021-08-31-rack-figure2.png
new file mode 100644
index 000000000..c2043ecae
--- /dev/null
+++ b/website/assets/images/2021-08-31-rack-figure2.png
diff --git a/website/assets/images/2021-08-31-rack-figure3.png b/website/assets/images/2021-08-31-rack-figure3.png
new file mode 100644
index 000000000..e8b689f33
--- /dev/null
+++ b/website/assets/images/2021-08-31-rack-figure3.png
diff --git a/website/blog/2019-11-18-security-basics.md b/website/blog/2019-11-18-security-basics.md
index b6cf57a77..938605cc2 100644
--- a/website/blog/2019-11-18-security-basics.md
+++ b/website/blog/2019-11-18-security-basics.md
@@ -188,11 +188,11 @@ for direct access to some files. And most files will be remotely accessed
 through the Gofers, in which case no FDs are donated to the Sentry.
 
 The Sentry itself is only allowed access to specific
-[whitelisted syscalls](https://github.com/google/gvisor/blob/master/runsc/config/config.go).
+[allowlisted syscalls](https://github.com/google/gvisor/blob/master/runsc/config/config.go).
 Without networking, the Sentry needs 53 host syscalls in order to function, and
-with networking, it uses an additional 15[^8]. By limiting the whitelist to only
+with networking, it uses an additional 15[^8]. By limiting the allowlist to only
 these needed syscalls, we radically reduce the amount of host OS attack surface.
-If any attempts are made to call something outside the whitelist, it is
+If any attempts are made to call something outside the allowlist, it is
 immediately blocked and the sandbox is killed by the Host OS.
 
 ### Sentry/Gofer Interface:
@@ -281,6 +281,8 @@ other ways the community can contribute to help make gVisor safe, fast and
 stable.
 <br>
 <br>
+**Updated (2021-07-14):** this post was updated to use more inclusive language.
+<br>
 
 --------------------------------------------------------------------------------
 
diff --git a/website/blog/2021-08-31-gvisor-rack.md b/website/blog/2021-08-31-gvisor-rack.md
new file mode 100644
index 000000000..e7d4582e4
--- /dev/null
+++ b/website/blog/2021-08-31-gvisor-rack.md
@@ -0,0 +1,120 @@
+# gVisor RACK
+
+gVisor has implemented the [RACK](https://datatracker.ietf.org/doc/html/rfc8985)
+(Recent ACKnowledgement) TCP loss-detection algorithm in our network stack,
+which improves throughput in the presence of packet loss and reordering.
+
+TCP is a connection-oriented protocol that detects and recovers from loss by
+retransmitting packets. [RACK](https://datatracker.ietf.org/doc/html/rfc8985) is
+one of the recent loss-detection methods implemented in Linux and BSD, which
+helps in identifying packet loss quickly and accurately in the presence of
+packet reordering and tail losses.
+
+## Background
+
+The TCP congestion window indicates the number of unacknowledged packets that
+can be sent at any time. When packet loss is identified, the congestion window
+is reduced depending on the type of loss. The sender will recover from the loss
+after all the packets sent before reducing the congestion window are
+acknowledged. If the loss is identified falsely by the connection, then the
+connection enters loss recovery unnecessarily, resulting in sending fewer
+packets.
+
+Packet loss is identified mainly in two ways:
+
+1.  Three duplicate acknowledgments, which will result in either
+    [Fast](https://datatracker.ietf.org/doc/html/rfc2001#section-4) or
+    [SACK](https://datatracker.ietf.org/doc/html/rfc6675) recovery. The
+    congestion window is reduced depending on the type of congestion control
+    algorithm. For example, in the
+    [Reno](https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_Tahoe_and_Reno)
+    algorithm it is reduced to half.
+2.  RTO (Retransmission Timeout) which will result in Timeout recovery. The
+    congestion window is reduced to one
+    [MSS](https://en.wikipedia.org/wiki/Maximum_segment_size).
+
+Both of these cases result in reducing the congestion window, with RTO being
+more expensive. Most of the existing algorithms do not detect packet reordering,
+which get incorrectly identified as packet loss, resulting in an RTO.
+Furthermore, the loss of an ACK at the end of a sequence (known as "tail loss")
+will also trigger RTO and slow down future transmissions unnecessarily. RACK
+helps us to identify loss accurately in all these scenarios, and will avoid
+entering RTO.
+
+## Implementation of RACK
+
+Implementation of RACK requires support for:
+
+1.  Per-packet transmission timestamps: RACK detects loss depending on the
+    transmission times of the packet and the timestamp at which ACK was
+    received.
+2.  SACK and ability to detect DSACK: Selective Acknowledgement and Duplicate
+    SACK are used to adjust the timer window after which a packet can be marked
+    as lost.
+
+### Packet Reordering
+
+Packet reordering commonly occurs when different packets take different paths
+through a network. The diagram below shows the transmission of four packets
+which get reordered in transmission, and the resulting TCP behavior with and
+without RACK.
+
+![Figure 1](/assets/images/2021-08-31-rack-figure1.png "Packet reordering.")
+
+In the above example, the sender sees three duplicate acknowledgments. Without
+RACK, this is identified falsely as packet loss, and the congestion window will
+be reduced after entering Fast/SACK recovery.
+
+To detect packet reordering, RACK uses a reorder window, bounded between
+[[RTT](https://en.wikipedia.org/wiki/Round-trip_delay)/4, RTT]. The reorder
+timer is set to expire after _RTT+reorder\_window_. A packet is marked as lost
+when the packets following it were acknowledged using SACK and the reorder timer
+expires. The reorder window is increased when a DSACK is received (which
+indicates that there is a higher degree of reordering).
+
+### Tail Loss
+
+Tail loss occurs when the packets are lost at the end of data transmission. The
+diagram below shows an example of tail loss when the last three packets are
+lost, and how it is handled with and without RACK.
+
+![Figure 2](/assets/images/2021-08-31-rack-figure2.png "Tail loss figure 2.")
+
+For tail losses, RACK uses a Tail Loss Probe (TLP), which relies on a timer for
+the last packet sent. The TLP timer is set to _2 \* RTT,_ after which a probe is
+sent. The probe packet will allow the connection one more chance to detect a
+loss by triggering ACK feedback to avoid entering RTO. In the above example, the
+loss is recovered without entering the RTO.
+
+TLP will also help in cases where the ACK was lost but all the packets were
+received by the receiver. The below diagram shows that the ACK received for the
+probe packet avoided the RTO.
+
+![Figure 3](/assets/images/2021-08-31-rack-figure3.png "Tail loss figure 3.")
+
+If there was some loss, then the ACK for the probe packet will have the SACK
+blocks, which will be used to detect and retransmit the lost packets.
+
+In gVisor, we have support for
+[NewReno](https://datatracker.ietf.org/doc/html/rfc6582) and SACK loss recovery
+methods. We
+[added support for RACK](https://github.com/google/gvisor/issues/5243) recently,
+and it is the default when SACK is enabled. After enabling RACK, our internal
+benchmarks in the presence of reordering and tail losses and the data we took
+from internal users inside Google have shown ~50% reduction in the number of
+RTOs.
+
+While RACK has improved one aspect of TCP performance by reducing the timeouts
+in the presence of reordering and tail losses, in gVisor we plan to implement
+the undoing of congestion windows and
+[BBRv2](https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control)
+(once there is an RFC available) to further improve TCP performance in less
+ideal network conditions.
+
+If you haven’t already, try gVisor. The instructions to get started are in our
+[Quick Start](https://gvisor.dev/docs/user_guide/quick_start/docker/). You can
+also get involved with the gVisor community via our
+[Gitter channel](https://gitter.im/gvisor/community),
+[email list](https://groups.google.com/forum/#!forum/gvisor-users),
+[issue tracker](https://gvisor.dev/issue/new), and
+[Github repository](https://github.com/google/gvisor).
diff --git a/website/blog/BUILD b/website/blog/BUILD
index 17beb721f..0384b9ba9 100644
--- a/website/blog/BUILD
+++ b/website/blog/BUILD
@@ -49,6 +49,16 @@ doc(
     permalink = "/blog/2020/10/22/platform-portability/",
 )
 
+doc(
+    name = "gvisor-rack",
+    src = "2021-08-31-gvisor-rack.md",
+    authors = [
+        "nybidari",
+    ],
+    layout = "post",
+    permalink = "/blog/2021/08/31/gvisor-rack/",
+)
+
 docs(
     name = "posts",
     deps = [
diff --git a/website/cmd/server/main.go b/website/cmd/server/main.go
index 707a3a8f8..1e5b56fbb 100644
--- a/website/cmd/server/main.go
+++ b/website/cmd/server/main.go
@@ -258,7 +258,7 @@ const pprofFixedPrefix = "https://storage.googleapis.com/"
 // allowedBuckets enforces constraints on the pprof target.
 //
 // If the continuous integration system is changed in the future to use
-// additional buckets, they may be whitelisted here. See registerProfile.
+// additional buckets, they may be allowed here. See registerProfile.
 var allowedBuckets = map[string]bool{
 	"gvisor-buildkite": true,
 }