[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4C5CF805-D1A6-4DC1-B48F-F3D145C54C58@netapp.com>
Date: Fri, 21 Feb 2014 08:16:36 +0000
From: "Zimmermann, Alexander" <Alexander.Zimmermann@...app.com>
To: "raffaello@....abdn.ac.uk" <raffaello@....abdn.ac.uk>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"ziaul.hossain@...n.ac.uk" <ziaul.hossain@...n.ac.uk>,
Fairhurst Gorry <gorry@....abdn.ac.uk>
Subject: Re: [PATCH 1/1] TCP NewCWV for Linux
Hi,
Am 20.02.2014 um 20:28 schrieb Raffaello@....abdn.ac.uk:
> Hi,
>
> This is a patch for newcwv a TCP sender-side modification,
> currently a work item at TCPM (TCP Maintenance and Minor extensions)
> at the IETF:
>
> http://tools.ietf.org/search/draft-ietf-tcpm-newcwv-05
>
> newcwv aims to supersede CWV (RFC2861) to provide better
> congestion control for rate-limited applications that use TCP.
>
> We implemented it as a module that uses tcp_congestion_ops.
This implies that we cannot use NewCWV w/ any other CC algo than
NewReno. Please correct me if I’m wrong, but this is not what we
(finally) would like to have. The NewCWV implementation should be
CC independent.
Alex
> The main changes are in "cong_avoid" before Reno cwnd control
> and at the start and end of Fast Retransmit:
>
> 1) Before Reno algorithm we estimate at each ACK our pipeACK
> (update_pipeack) and decide to increase or not cwnd based on pipeack.
>
> 2) At the start of FR we reset cwnd based on pipeACK, while
> at the end we further reduce pipeACK by the number of retransmissions.
>
> I posted it here for you consideration to be included in net-next.
>
> ---
Download attachment "signature.asc" of type "application/pgp-signature" (204 bytes)
Powered by blists - more mailing lists