netdev - Re: [PATCH v4] Proportional Rate Reduction for TCP.

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] [day] [month] [year] [list]

Date:	Wed, 24 Aug 2011 19:43:24 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	nanditad@...gle.com
Cc:	netdev@...r.kernel.org, therbert@...gle.com, mattmathis@...gle.com,
	ycheng@...gle.com
Subject: Re: [PATCH v4] Proportional Rate Reduction for TCP.

From: Nandita Dukkipati <nanditad@...gle.com>
Date: Sun, 21 Aug 2011 23:21:57 -0700

> This patch implements Proportional Rate Reduction (PRR) for TCP.
> PRR is an algorithm that determines TCP's sending rate in fast
> recovery. PRR avoids excessive window reductions and aims for
> the actual congestion window size at the end of recovery to be as
> close as possible to the window determined by the congestion control
> algorithm. PRR also improves accuracy of the amount of data sent
> during loss recovery.
> 
> The patch implements the recommended flavor of PRR called PRR-SSRB
> (Proportional rate reduction with slow start reduction bound) and
> replaces the existing rate halving algorithm. PRR improves upon the
> existing Linux fast recovery under a number of conditions including:
>   1) burst losses where the losses implicitly reduce the amount of
> outstanding data (pipe) below the ssthresh value selected by the
> congestion control algorithm and,
>   2) losses near the end of short flows where application runs out of
> data to send.
> 
> As an example, with the existing rate halving implementation a single
> loss event can cause a connection carrying short Web transactions to
> go into the slow start mode after the recovery. This is because during
> recovery Linux pulls the congestion window down to packets_in_flight+1
> on every ACK. A short Web response often runs out of new data to send
> and its pipe reduces to zero by the end of recovery when all its packets
> are drained from the network. Subsequent HTTP responses using the same
> connection will have to slow start to raise cwnd to ssthresh. PRR on
> the other hand aims for the cwnd to be as close as possible to ssthresh
> by the end of recovery.
> 
> A description of PRR and a discussion of its performance can be found at
> the following links:
> - IETF Draft:
>     http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
> - IETF Slides:
>     http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
>     http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
> - Paper to appear in Internet Measurements Conference (IMC) 2011:
>     Improving TCP Loss Recovery
>     Nandita Dukkipati, Matt Mathis, Yuchung Cheng
> 
> Signed-off-by: Nandita Dukkipati <nanditad@...gle.com>

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