Re: [PATCH 1/1] tcp: Wrong timeout for SYN segments

On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:

On Tue, Aug 21, 2012 at 4:29 PM, Alex Bergmann <alex@linlab.net
<mailto:alex@linlab.net>> wrote:

    Hi David,

    I'm not 100% sure, but it looks like I found an RFC mismatch with the
    current default values of the TCP implementation.

    Alex

     From 8b854a525eb45f64ad29dfab16f9d9f681e84495 Mon Sep 17 00:00:00 2001
    From: Alexander Bergmann <alex@linlab.net <mailto:alex@linlab.net>>
    Date: Wed, 22 Aug 2012 00:29:08 +0200
    Subject: [PATCH 1/1] tcp: Wrong timeout for SYN segments

    Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
    RFC6298 (former RFC2988bis). This introduced a gap with RFC1122 that
    defines a minimum retransmission window for SYN segments of at least
    180secs.

    Prior to 9ad7c049 the timeout was defined with 189secs. Now we have only
    a timeout of 63secs.

             ((2 << 5) - 1) * 3 secs = 189 secs
             ((2 << 5) - 1) * 1 secs = 63 secs

    To fulfill the MUST constraint in RFC1122 section 4.2.3.5 about R2 for
    SYN segments, the values of TCP_SYN_RETRIES and TCP_SYNACK_RETRIES must
    be changed to 7 reties.

             ((2 << 7) - 1) * 1 secs = 255 secs

    This would result in an ETIMEDOUT of 4 minutes 15 seconds.


This issue occurred to me right after I submitted the patch for RFC6298.
I did not commit any more change because RFC compliance aside, 180secs
just seem like eternity in the Internet age.

(See my past post on this at
http://marc.info/?l=linux-netdev&m=130759078118866&w=2)

Okay, I missed that post during my search about the current situation.

Thanks,
Alex

Jerry


    Signed-off-by: Alexander Bergmann <alex@linlab.net
    <mailto:alex@linlab.net>>
    ---
      include/net/tcp.h |    4 ++--
      1 files changed, 2 insertions(+), 2 deletions(-)

    diff --git a/include/net/tcp.h b/include/net/tcp.h
    index 1f000ff..7eaae19 100644
    --- a/include/net/tcp.h
    +++ b/include/net/tcp.h
    @@ -98,10 +98,10 @@ extern void tcp_time_wait(struct sock *sk, int
    state, int timeo);
                                      * 15 is ~13-30min depending on RTO.
                                      */

    -#define TCP_SYN_RETRIES         5      /* number of times to retry
    active opening a
    +#define TCP_SYN_RETRIES         7      /* number of times to retry
    active opening a
                                      * connection: ~180sec is RFC
    minimum   */

    -#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive
    opening a
    +#define TCP_SYNACK_RETRIES 7   /* number of times to retry passive
    opening a
                                      * connection: ~180sec is RFC
    minimum   */

      #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy
    TIME-WAIT
    --
    1.7.8.6

    --
    To unsubscribe from this list: send the line "unsubscribe netdev" in
    the body of a message to majordomo@vger.kernel.org
    <mailto:majordomo@vger.kernel.org>
    More majordomo info at http://vger.kernel.org/majordomo-info.html

-- 
|. _ | _ |_   _  _ _|_
||| ||(_||_).| |(/_ |
email/sip/xmpp: alex@linlab.net
phone/enum: +49 2871 2355378

On Thu, 2012-08-23 at 13:58 +0200, Alex Bergmann wrote:

On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:

quoted

This issue occurred to me right after I submitted the patch for RFC6298.
I did not commit any more change because RFC compliance aside, 180secs
just seem like eternity in the Internet age.

(See my past post on this at
http://marc.info/?l=linux-netdev&m=130759078118866&w=2)

Okay, I missed that post during my search about the current situation.

I would suggest to increase TCP_SYN_RETRIES from 5 to 6.

180 secs is eternity, but 31 secs is too small.

Can you repost a v2, only changing TCP_SYN_RETRIES ?

I would suggest to increase TCP_SYN_RETRIES from 5 to 6.

180 secs is eternity, but 31 secs is too small.

Wasn't the intention of the long delay to allow a system
acting as a router to reboot?
I suspect that is why it (and some other TCP timers)
are in minutes.

	David

On 08/23/2012 02:15 PM, Eric Dumazet wrote:

On Thu, 2012-08-23 at 13:58 +0200, Alex Bergmann wrote:

quoted

On 08/22/2012 06:41 PM, H.K. Jerry Chu wrote:

quoted

quoted

This issue occurred to me right after I submitted the patch for RFC6298.
I did not commit any more change because RFC compliance aside, 180secs
just seem like eternity in the Internet age.

(See my past post on this at
http://marc.info/?l=linux-netdev&m=130759078118866&w=2)

Okay, I missed that post during my search about the current situation.

I would suggest to increase TCP_SYN_RETRIES from 5 to 6.

180 secs is eternity, but 31 secs is too small.

Can you repost a v2, only changing TCP_SYN_RETRIES ?

I hope the description is good enough.

Alex

From be551f82499112e4775b6d579d58967510b6d492 Mon Sep 17 00:00:00 2001

From: Alexander Bergmann <redacted>
Date: Thu, 23 Aug 2012 14:33:35 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.[1]

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

[1] RFC 1122 - 4.2.3.5 TCP Connection Failures

Signed-off-by: Alexander Bergmann <redacted>
---
 include/net/tcp.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..f309e93 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h

@@ -98,7 +98,7 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
                                 * 15 is ~13-30min depending on RTO.
                                 */
 
-#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
+#define TCP_SYN_RETRIES         6      /* number of times to retry active opening a
                                 * connection: ~180sec is RFC minimum   */
 
 #define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a

-- 
1.7.8.6

On Thu, 2012-08-23 at 14:37 +0200, Alex Bergmann wrote:

Acked-by: Eric Dumazet <edumazet@google.com>

A change of the comment might be good, to help future readers.

On Thu, 2012-08-23 at 13:35 +0100, David Laight wrote:

quoted

I would suggest to increase TCP_SYN_RETRIES from 5 to 6.

180 secs is eternity, but 31 secs is too small.

Wasn't the intention of the long delay to allow a system
acting as a router to reboot?
I suspect that is why it (and some other TCP timers)
are in minutes.

One could argue that if an application really wants to connect to a
peer, it should probably handle failures and retries.

But for unaware (basic ?) applications, the 3 -> 1 change reduced by a 3
factor the timeout. So a transient network failure has now more
chance to impact them.

Not all applications run inside a browser or under human control...

Acked-by: Eric Dumazet <edumazet@google.com>

A change of the comment might be good, to help future readers.

Okay, I've also changed the comments of SYN and SYNACK retries. 

Alex

From 11a292b1cff772f930a02fda02d5b741f8ea5033 Mon Sep 17 00:00:00 2001

From: Alexander Bergmann <redacted>
Date: Fri, 24 Aug 2012 14:09:49 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.

  "However, the values of R1 and R2 may be different for SYN
  and data segments.  In particular, R2 for a SYN segment MUST
  be set large enough to provide retransmission of the segment
  for at least 3 minutes.  The application can close the
  connection (i.e., give up on the open attempt) sooner, of
  course."

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

The comments for SYN and SYNACK retries have also been updated to
describe the current settings.

Signed-off-by: Alexander Bergmann <redacted>
---
 include/net/tcp.h |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..d43d6b3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h

@@ -98,11 +98,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
                                 * 15 is ~13-30min depending on RTO.
                                 */
 
-#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
-                                * connection: ~180sec is RFC minimum   */
+#define TCP_SYN_RETRIES         6      /*
+                                * This is how many retries it does to active
+                                * opening a connection.
+                                * RFC1122 says the minimum retry MUST be at
+                                * least 180secs. Nevertheless this value is
+                                * corresponding to 63secs of retransmission
+                                * with the current initial RTO.
+                                */
 
-#define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a
-                                * connection: ~180sec is RFC minimum   */
+#define TCP_SYNACK_RETRIES 5   /* 
+                                * This is how may retries it does to passive
+                                * opening a connection. 
+                                * This is corresponding to 31secs of 
+                                * retransmission with the current initial RTO.
+                                */
 
 #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
                                  * state, about 60 seconds     */

-- 
1.7.8.6

From: Eric Dumazet <redacted>
Date: Thu, 23 Aug 2012 14:49:45 +0200

On Thu, 2012-08-23 at 14:37 +0200, Alex Bergmann wrote:

quoted

From be551f82499112e4775b6d579d58967510b6d492 Mon Sep 17 00:00:00 2001
From: Alexander Bergmann <redacted>
Date: Thu, 23 Aug 2012 14:33:35 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.[1]

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

[1] RFC 1122 - 4.2.3.5 TCP Connection Failures

Signed-off-by: Alexander Bergmann <redacted>
---
 include/net/tcp.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..f309e93 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h

@@ -98,7 +98,7 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
                                 * 15 is ~13-30min depending on RTO.
                                 */
 
-#define TCP_SYN_RETRIES         5      /* number of times to retry active opening a
+#define TCP_SYN_RETRIES         6      /* number of times to retry active opening a
                                 * connection: ~180sec is RFC minimum   */
 
 #define TCP_SYNACK_RETRIES 5   /* number of times to retry passive opening a

Acked-by: Eric Dumazet <edumazet@google.com>

A change of the comment might be good, to help future readers.

Alex, this patch doesn't apply, it was completely corrupted by your email
client.

Make a fresh submission, with this fixed.  But before you do, email the
patch to yourself and make sure you can actually apply the patch you
receive in your inbox.  Because that's exactly what I'm going to have
to do.

Thanks.

On Fri, Aug 24, 2012 at 01:42:31PM -0400, David Miller wrote:

Alex, this patch doesn't apply, it was completely corrupted by your email
client.

Make a fresh submission, with this fixed.  But before you do, email the
patch to yourself and make sure you can actually apply the patch you
receive in your inbox.  Because that's exactly what I'm going to have
to do.

Sorry I messed it up the last time. This time I've double checked as 
you suggested. I'll keep that in mind.

From 11a292b1cff772f930a02fda02d5b741f8ea5033 Mon Sep 17 00:00:00 2001

From: Alexander Bergmann <redacted>
Date: Fri, 24 Aug 2012 14:09:49 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.

  "However, the values of R1 and R2 may be different for SYN
  and data segments.  In particular, R2 for a SYN segment MUST
  be set large enough to provide retransmission of the segment
  for at least 3 minutes.  The application can close the
  connection (i.e., give up on the open attempt) sooner, of
  course."

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

The comments for SYN and SYNACK retries have also been updated to
describe the current settings.

Signed-off-by: Alexander Bergmann <redacted>
---
 include/net/tcp.h |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 1f000ff..d43d6b3 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h

@@ -98,11 +98,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
 				 * 15 is ~13-30min depending on RTO.
 				 */
 
-#define TCP_SYN_RETRIES	 5	/* number of times to retry active opening a
-				 * connection: ~180sec is RFC minimum	*/
+#define TCP_SYN_RETRIES	 6	/*
+				 * This is how many retries it does to active
+				 * opening a connection.
+				 * RFC1122 says the minimum retry MUST be at
+				 * least 180secs. Nevertheless this value is
+				 * corresponding to 63secs of retransmission
+				 * with the current initial RTO.
+				 */
 
-#define TCP_SYNACK_RETRIES 5	/* number of times to retry passive opening a
-				 * connection: ~180sec is RFC minimum	*/
+#define TCP_SYNACK_RETRIES 5	/* 
+				 * This is how may retries it does to passive
+				 * opening a connection. 
+				 * This is corresponding to 31secs of 
+				 * retransmission with the current initial RTO.
+				 */
 
 #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
 				  * state, about 60 seconds	*/

-- 
1.7.8.6

From: Alexander Bergmann <redacted>
Date: Fri, 24 Aug 2012 14:09:49 +0200
Subject: [PATCH 1/1] tcp: Increase timeout for SYN segments

Commit 9ad7c049 changed the initRTO from 3secs to 1sec in accordance to
RFC6298 (former RFC2988bis). This reduced the time till the last SYN
retransmission packet gets sent from 93secs to 31secs.

RFC1122 is stating that the retransmission should be done for at least 3
minutes, but this seems to be quite high.

  "However, the values of R1 and R2 may be different for SYN
  and data segments.  In particular, R2 for a SYN segment MUST
  be set large enough to provide retransmission of the segment
  for at least 3 minutes.  The application can close the
  connection (i.e., give up on the open attempt) sooner, of
  course."

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

The comments for SYN and SYNACK retries have also been updated to
describe the current settings.

Signed-off-by: Alexander Bergmann <redacted>
---

Acked-by: Eric Dumazet <edumazet@google.com>

Hi,

On Saturday 25 August 2012, Alexander Bergmann wrote:

This patch increases the value of TCP_SYN_RETRIES to the value of 6,
providing a retransmission window of 63secs.

The comments for SYN and SYNACK retries have also been updated to
describe the current settings.

wouldn't it be nice, if the description of the corresponding sysctls in 
Documentation/networking/ip-sysctl.txt could be updated too?

Cheers
Carsten

On Sat, Aug 25, 2012 at 1:48 AM, Alexander Bergmann [off-list ref] wrote:

IMHO 31secs seem a little short. Why not change it to 6 as well because 63
secs still beats 93secs with 3sec initRTO and 5 retries.

Jerry

+                                */

 #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
                                  * state, about 60 seconds     */
--
1.7.8.6

On Tue, 2012-08-28 at 21:34 -0700, H.K. Jerry Chu wrote:

IMHO 31secs seem a little short. Why not change it to 6 as well because 63
secs still beats 93secs with 3sec initRTO and 5 retries.

Jerry

My rationale was that such increase were going to amplify SYN attacks
impact by 20% (if we count number of useless SYNACK sent)

If the active side sends SYN packets for 180 seconds, do we really want
to also send SYNACKS for additional 100 seconds ?

Sure, RFC numbers are what they are, but in practice, I doubt someone
will really miss the extra SYNACK sent after ~32 seconds, since it would
matter only for the last SYN attempted.

Eric,

On Wed, Aug 29, 2012 at 1:51 AM, Eric Dumazet [off-list ref] wrote:

On Tue, 2012-08-28 at 21:34 -0700, H.K. Jerry Chu wrote:

quoted

IMHO 31secs seem a little short. Why not change it to 6 as well because 63
secs still beats 93secs with 3sec initRTO and 5 retries.

Jerry

My rationale was that such increase were going to amplify SYN attacks
impact by 20% (if we count number of useless SYNACK sent)

IMHO the main damage caused by SYN attack is DOS resulted from bogus
SYNs clogging the listener queue. I guess you've had numbers showing
that generating so many SYNACKs in response to bogus SYNs can be costly
too. But each bogus SYN that expires earlier will open up space sooner in the
listener queue for more bogus SYN so I'm not sure which one can induced
more damage.

Also if syn-cookie is enabled, it will dwarf the cost from
retransmitting SYN-ACK,
right?

If the active side sends SYN packets for 180 seconds, do we really want
to also send SYNACKS for additional 100 seconds ?

You have a good point. (I remember some folks in the past even question with
retransmitting SYN why SYN-ACK retransmit is necessary, other than for expedient
recovery purpose.)

But it probably matter slightly more for TCP Fast Open (the server
side patch has
been completed and will be posted soon, after I finish breaking it up
into smaller
pieces for ease of review purpose), when a full socket will be created with data
passed to the app upon a valid SYN+data. Dropping a fully functioning socket
won't be the same as dropping a request_sock unknown to the app and letting
the other side retransmitting SYN (w/o data this time).

Sure, RFC numbers are what they are, but in practice, I doubt someone
will really miss the extra SYNACK sent after ~32 seconds, since it would
matter only for the last SYN attempted.

I'd slightly prefer 1 extra retry plus longer wait time just to make
TCP Fast Open
a little more robust (even though the app protocol is required to be
idempotent).
But this is not a showstopper.

Thanks,

Jerry

On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:

But it probably matter slightly more for TCP Fast Open (the server
side patch has
been completed and will be posted soon, after I finish breaking it up
into smaller
pieces for ease of review purpose), when a full socket will be created with data
passed to the app upon a valid SYN+data. Dropping a fully functioning socket
won't be the same as dropping a request_sock unknown to the app and letting
the other side retransmitting SYN (w/o data this time).

quoted

Sure, RFC numbers are what they are, but in practice, I doubt someone
will really miss the extra SYNACK sent after ~32 seconds, since it would
matter only for the last SYN attempted.

I'd slightly prefer 1 extra retry plus longer wait time just to make
TCP Fast Open
a little more robust (even though the app protocol is required to be
idempotent).
But this is not a showstopper.

Thats very good points indeed, thanks.

Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
was validated.

This way, we increase reliability without amplifying the effect of wild
SYN packets.

From: Eric Dumazet <redacted>
Date: Thu, 30 Aug 2012 06:12:30 -0700

On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:

quoted

But it probably matter slightly more for TCP Fast Open (the server
side patch has
been completed and will be posted soon, after I finish breaking it up
into smaller
pieces for ease of review purpose), when a full socket will be created with data
passed to the app upon a valid SYN+data. Dropping a fully functioning socket
won't be the same as dropping a request_sock unknown to the app and letting
the other side retransmitting SYN (w/o data this time).

quoted

Sure, RFC numbers are what they are, but in practice, I doubt someone
will really miss the extra SYNACK sent after ~32 seconds, since it would
matter only for the last SYN attempted.

I'd slightly prefer 1 extra retry plus longer wait time just to make
TCP Fast Open
a little more robust (even though the app protocol is required to be
idempotent).
But this is not a showstopper.

Thats very good points indeed, thanks.

Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
was validated.

This way, we increase reliability without amplifying the effect of wild
SYN packets.

Can we come to a final conclusion on this last point and arrive at a final
patch?

Thanks.

On Thu, Aug 30, 2012 at 6:12 AM, Eric Dumazet [off-list ref] wrote:

On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:

quoted

But it probably matter slightly more for TCP Fast Open (the server
side patch has
been completed and will be posted soon, after I finish breaking it up
into smaller
pieces for ease of review purpose), when a full socket will be created with data
passed to the app upon a valid SYN+data. Dropping a fully functioning socket
won't be the same as dropping a request_sock unknown to the app and letting
the other side retransmitting SYN (w/o data this time).

quoted

Sure, RFC numbers are what they are, but in practice, I doubt someone
will really miss the extra SYNACK sent after ~32 seconds, since it would
matter only for the last SYN attempted.

I'd slightly prefer 1 extra retry plus longer wait time just to make
TCP Fast Open
a little more robust (even though the app protocol is required to be
idempotent).
But this is not a showstopper.

Thats very good points indeed, thanks.

Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
was validated.

This way, we increase reliability without amplifying the effect of wild
SYN packets.

Ok, will use sysctl_tcp_synack_retries + 1 in tcp_fastopen_synack_timer() of my
upcoming TCP Fast Open server patch (hope to submit today).

Jerry

On Thu, Aug 30, 2012 at 9:45 AM, David Miller [off-list ref] wrote:

From: Eric Dumazet <redacted>
Date: Thu, 30 Aug 2012 06:12:30 -0700

quoted

On Wed, 2012-08-29 at 10:25 -0700, H.K. Jerry Chu wrote:

quoted

But it probably matter slightly more for TCP Fast Open (the server
side patch has
been completed and will be posted soon, after I finish breaking it up
into smaller
pieces for ease of review purpose), when a full socket will be created with data
passed to the app upon a valid SYN+data. Dropping a fully functioning socket
won't be the same as dropping a request_sock unknown to the app and letting
the other side retransmitting SYN (w/o data this time).

quoted

Sure, RFC numbers are what they are, but in practice, I doubt someone
will really miss the extra SYNACK sent after ~32 seconds, since it would
matter only for the last SYN attempted.

I'd slightly prefer 1 extra retry plus longer wait time just to make
TCP Fast Open
a little more robust (even though the app protocol is required to be
idempotent).
But this is not a showstopper.

Thats very good points indeed, thanks.

Maybe we can increase SYNACK max retrans only if the FastOpen SYN cookie
was validated.

This way, we increase reliability without amplifying the effect of wild
SYN packets.

Can we come to a final conclusion on this last point and arrive at a final
patch?

Thanks.

Acked-by: H.K. Jerry Chu <redacted>