summaryrefslogtreecommitdiff
path: root/net/atm
diff options
context:
space:
mode:
authorAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>2005-09-30 00:17:15 (GMT)
committerDavid S. Miller <davem@davemloft.net>2005-09-30 00:17:15 (GMT)
commit09e9ec87111ba818d8171262b15ba4c357eb1d27 (patch)
tree1ca234c19a12ca88879441d10b83fe317a586d2f /net/atm
parent01ff367e62f0474e4d39aa5812cbe2a30d96e1e9 (diff)
downloadlinux-fsl-qoriq-09e9ec87111ba818d8171262b15ba4c357eb1d27.tar.xz
[TCP]: Don't over-clamp window in tcp_clamp_window()
From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Handle better the case where the sender sends full sized frames initially, then moves to a mode where it trickles out small amounts of data at a time. This known problem is even mentioned in the comments above tcp_grow_window() in tcp_input.c, specifically: ... * The scheme does not work when sender sends good segments opening * window and then starts to feed us spagetti. But it should work * in common situations. Otherwise, we have to rely on queue collapsing. ... When the sender gives full sized frames, the "struct sk_buff" overhead from each packet is small. So we'll advertize a larger window. If the sender moves to a mode where small segments are sent, this ratio becomes tilted to the other extreme and we start overrunning the socket buffer space. tcp_clamp_window() tries to address this, but it's clamping of tp->window_clamp is a wee bit too aggressive for this particular case. Fix confirmed by Ion Badulescu. Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/atm')
0 files changed, 0 insertions, 0 deletions