netdev - Re: [PATCH v2 net-next] tcp: Fix CWV being too strict on thin streams

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: <1443371580.3273.9.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Sun, 27 Sep 2015 09:33:00 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Bendik Rønning Opstad <bro.devel@...il.com>,
	David Miller <davem@...emloft.net>
Cc:	Neal Cardwell <ncardwell@...gle.com>, netdev@...r.kernel.org,
	Bendik Rønning Opstad 
	<bro.devel+kernel@...il.com>
Subject: Re: [PATCH v2 net-next] tcp: Fix CWV being too strict on thin
 streams

On Wed, 2015-09-23 at 18:49 +0200, Bendik Rønning Opstad wrote:
> Application limited streams such as thin streams, that transmit small
> amounts of payload in relatively few packets per RTT, can be prevented
> from growing the CWND when in congestion avoidance. This leads to
> increased sojourn times for data segments in streams that often transmit
> time-dependent data.
> 
> Currently, a connection is considered CWND limited only after having
> successfully transmitted at least one packet with new data, while at the
> same time failing to transmit some unsent data from the output queue
> because the CWND is full. Applications that produce small amounts of
> data may be left in a state where it is never considered to be CWND
> limited, because all unsent data is successfully transmitted each time
> an incoming ACK opens up for more data to be transmitted in the send
> window.
> 
> Fix by always testing whether the CWND is fully used after successful
> packet transmissions, such that a connection is considered CWND limited
> whenever the CWND has been filled. This is the correct behavior as
> specified in RFC2861 (section 3.1).
> 
> Cc: Andreas Petlund <apetlund@...ula.no>
> Cc: Carsten Griwodz <griff@...ula.no>
> Cc: Jonas Markussen <jonassm@....uio.no>
> Cc: Kenneth Klette Jonassen <kennetkl@....uio.no>
> Cc: Mads Johannessen <madsjoh@....uio.no>
> Signed-off-by: Bendik Rønning Opstad <bro.devel+kernel@...il.com>
> ---
> Changes in v2:
>  - Instead of updating tp->is_cwnd_limited after failing to send
>    any packets, test whether CWND is full after successfull packet
>    transmissions.
>  - Updating commit message according to changes.
> 
>  net/ipv4/tcp_output.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 4cd0b50..57a586f 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1827,7 +1827,7 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb,
>  
>  	/* Ok, it looks like it is advisable to defer. */
>  
> -	if (cong_win < send_win && cong_win < skb->len)
> +	if (cong_win < send_win && cong_win <= skb->len)
>  		*is_cwnd_limited = true;
>  
>  	return true;
> @@ -2060,7 +2060,6 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
>  
>  		cwnd_quota = tcp_cwnd_test(tp, skb);
>  		if (!cwnd_quota) {
> -			is_cwnd_limited = true;
>  			if (push_one == 2)
>  				/* Force out a loss probe pkt. */
>  				cwnd_quota = 1;
> @@ -2142,6 +2141,7 @@ repair:
>  		/* Send one loss probe per tail loss episode. */
>  		if (push_one != 2)
>  			tcp_schedule_loss_probe(sk);
> +		is_cwnd_limited |= (tcp_packets_in_flight(tp) >= tp->snd_cwnd);
>  		tcp_cwnd_validate(sk, is_cwnd_limited);
>  		return false;
>  	}

David, any idea of what happened to Bendik patch ?

https://patchwork.ozlabs.org/patch/521765

Do we need to re-submit or something ?

Thanks !


--
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