[Galaxy S III Android Development] harunjo:
v39-beta4

v39-beta4

-tweak pegasusq hotplug become more aggressive

-net: force dst_default_metrics to const section

Submitter:Eric Dumazet

-switch do_fsync() to fget_light()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

-Proportional Rate Reduction for TCP.

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.

Proportional Rate Reduction for TCP

Abstract: Packet losses increase latency for Web users.

Fast recovery is a key mechanism for TCP to recover from packet losses.

In this paper, we explore some of the weaknesses of the standard algorithm described in RFC 3517 and the non-standard algorithms implemented in Linux.

We ?nd that these algorithms deviate from their intended behavior in the real world due to the combined e?ect of short ?ows, application stalls, burst losses, acknowledgment (ACK) loss and reordering, and stretch ACKs. Linux su?ers from excessive congestion window reductions while RFC 3517 transmits large bursts under high losses, both of which harm the rest of the ?ow and increase Web latency. Our primary contribution is a new design to control transmission in fast recovery called proportional rate reduction (PRR). PRR recovers from losses quickly, smoothly and accurately by pacing out retransmissions across received ACKs. In addition to PRR, we evaluate the TCP early retransmit (ER) algorithm which lowers the duplicate acknowledgment threshold for short transfers, and show that delaying early retransmissions for a short interval is e?ective in avoiding spurious retransmissions in the presence of a small degree of reordering. PRR and ER reduce the TCP latency of connections experiencing losses by 3-10% depending on the response size. Based on our instrumentation on Google Web and YouTube servers in U.S. and India, we also present key statistics on the nature of TCP retransmissions.

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@google.com>

Signed-off-by: David S. Miller <davem@davemloft.net>

ported by faux123

https://github.com/faux123/samsung_hercules/commit/03d220ca1ed3135e977b3732591fc40e020d57d1