netdev - Re: [PATCH] RFC2988bis + taking RTT sample from 3WHS for the passive open side

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTinnROK1MNAbWJWEdQa8-h_K9yN531gxdp__r_Tf55e9Lg@mail.gmail.com>
Date:	Wed, 8 Jun 2011 15:06:26 -0700
From:	Jerry Chu <hkchu@...gle.com>
To:	Hagen Paul Pfeifer <hagen@...u.net>
Cc:	David Miller <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>, tsunanet@...il.com,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] RFC2988bis + taking RTT sample from 3WHS for the passive
 open side

Hi Hagen,

On Wed, Jun 8, 2011 at 2:16 PM, Hagen Paul Pfeifer <hagen@...u.net> wrote:
> Hello Jerry
>
> * Jerry Chu | 2011-06-08 11:04:22 [-0700]:
>
>>+       /* Cut cwnd down to 1 per RFC5681 if SYN or SYN-ACK has been
>>+        * retransmitted. In light of RFC2988bis' more aggressive 1sec
>>+        * initRTO, we only reset cwnd when more than 1 SYN/SYN-ACK
>>+        * retransmission has occurred.
>>+        */
>>+       if (tp->total_retrans > 1)
>>+               tp->snd_cwnd = 1;
>>+       else
>>+               tp->snd_cwnd = tcp_init_cwnd(tp, dst);
>
> Is this behavior somewhere documented? In RFC2988bis I cannot find something
> similar.

See my 5/20/11 mail on this subject. The short answer is, no, it's not
part of RFC2988bis. The long answer is, when we (Vern, Mark and I)
were working
on RFC2988bis we shared a common design goal to minimize the negative
impact to those paths with RTT > 1sec as much as possible.

RFC3390 and later RFC5681 have the following clause:
"... Further, if the SYN or SYN/ACK is lost, the initial window used by a
sender after a correctly transmitted SYN MUST be one segment
consisting of at most SMSS bytes."

Unfortunately, with initRTO reduced to 1sec, unless the stack can reliably
detect spurious retransmissions of SYN or SYN-ACK, the paths with RTT >
1sec may be penalized unnecessarily with initcwnd = 1 if the stack
implementation follows the above clause faithfully. We can't really amend
the clause as part of RFC2988bis because it doesn't belong there, as the
latter only covers RTO computation, not the congestion control algorithm.
In the end Vern/Mark suggested me to add the amendment to the IW10
proposal I was working on (now becomes draft-ietf-tcpm-initcwnd-01.txt)
So I did, with following paragraph:
"...
   Furthermore, RFC 3390 and RFC 5681 [RFC5681] state that

         "If the SYN or SYN/ACK is lost, the initial window used by a
         sender after a correctly transmitted SYN MUST be one segment
         consisting of MSS bytes."

   The proposed change to reduce the default RTO to 1 second [PACS11]
   increases the chance for spurious SYN or SYN/ACK retransmission, thus
   unnecessarily penalizing connections with RTT > 1 second if their
   initial window is reduced to 1 segment. For this reason, it is
   RECOMMENDED that implementations refrain from resetting the initial
   window to 1 segment, unless either there have been multiple SYN or
   SYN/ACK retransmissions, or true loss detection has been made."

The patch follows the intent of the co-authors. It also moves the
implementation closer to the spec. Without the patch the existing
implementation will reduce ssthresh (active open side only), but not the
cwnd upon SYN or SYN-ACK retransmission.

Best,

Jerry

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