Date: Thu, 12 Mar 2015 01:37:16 +1100 From: Lawrence Stewart <lstewart@room52.net> To: tcpm@ietf.org Cc: Grenville Armitage <garmitage@swin.edu.au> Subject: TCP window updates combined with dup acks sent in response to packet loss Message-ID: <5500531C.1000109@room52.net>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------090509000204080901010707
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
[BCCed to freebsd-net@freebsd.org]
Hi all,
Please consider the code below from FreeBSD 10.1's TCP input processing:
/*
* In ESTABLISHED state: drop duplicate ACKs; ACK out of range
* ACKs. If the ack is in the range
* tp->snd_una < th->th_ack <= tp->snd_max
* then advance tp->snd_una to th->th_ack and drop
* data from the retransmission queue. If this ACK reflects
* more up to date window information we update our window
information.
*/
case TCPS_ESTABLISHED:
case TCPS_FIN_WAIT_1:
case TCPS_FIN_WAIT_2:
case TCPS_CLOSE_WAIT:
case TCPS_CLOSING:
case TCPS_LAST_ACK:
if (SEQ_GT(th->th_ack, tp->snd_max)) {
TCPSTAT_INC(tcps_rcvacktoomuch);
goto dropafterack;
}
if ((tp->t_flags & TF_SACK_PERMIT) &&
((to.to_flags & TOF_SACK) ||
!TAILQ_EMPTY(&tp->snd_holes)))
tcp_sack_doack(tp, &to, th->th_ack);
/* Run HHOOK_TCP_ESTABLISHED_IN helper hooks. */
hhook_run_tcp_est_in(tp, th, &to);
if (SEQ_LEQ(th->th_ack, tp->snd_una)) {
if (tlen == 0 && tiwin == tp->snd_wnd) {
TCPSTAT_INC(tcps_rcvdupack);
<dupack processing omitted>
Now for a dupack to be treated as such for the purposes of triggering
fast retransmit/fast recovery, the dupack must not update the window as
per the "tiwin == tp->snd_wnd" condition above, which has existed since
at least BSD 4.4 (I didn't bother looking further back in history).
Grenville (CCed) has encountered proof of this condition forcing
connections to recover via RTO when legitimate dupacks sent in response
to a packet loss also contain a window update.
In the example tcpdump excerpt attached, the advertised receive window
is growing as the Linux receiver side app reads data from the socket
buffer while the dupacks are generated. The FreeBSD sender side sees
them as window updates and processes them as such, bypassing the dupack
processing code. The send window is consumed and because only dup acks
are returning, UNA is not advanced and so the connection stalls,
requiring two RTOs to recover from the 2 dropped packets.
With SACK in the mix as is the case for the provided example, it seems
obvious to me that the existence of SACK blocks could and should be used
to realise that a window update combined with a dupack is not a pure
window update and therefore should be processed by the dupack handling
code for fast retransmit/fast recovery purposes.
For connections without SACK, is there any existing guidance on how to
deal with this? My Google fu and skimming of the RFCs that seemed
relevant to this matter turned up nothing, and so I'm imagining a
potential algorithm for inferring if a window update can count as a
dupack for fast retransmit/fast recovery purposes or not. Wanted to get
some input from others before spending any more time on it though.
Cheers,
Lawrence
--------------090509000204080901010707
Content-Type: text/plain; charset=us-ascii;
name="dupackwndupdate.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="dupackwndupdate.txt"
MDA6MDA6MDAuMDAwMjQxIElQIDE3Mi4xNi4xMC42MC41MTY3NyA+IDE3Mi4xNi4xMS42My44
MjogRmxhZ3MgWy5dLCBhY2sgMTA4ODM0LCB3aW4gNzczNCwgb3B0aW9ucyBbbm9wLG5vcCxU
UyB2YWwgMjY0ODYxOTEgZWNyIDQxODMxOTQyNzhdLCBsZW5ndGggMAowMDowMDowMC4wMDAy
MTYgSVAgMTcyLjE2LjEwLjYwLjUxNjc3ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFncyBbLl0s
IGFjayAxMDg4MzQsIHdpbiA3ODI0LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAyNjQ4NjE5
MSBlY3IgNDE4MzE5NDI3OCxub3Asbm9wLHNhY2sgMSB7MTEwMjgyOjExMTczMH1dLCBsZW5n
dGggMAowMDowMDowMC4wMDgwMjUgSVAgMTcyLjE2LjEwLjYwLjUxNjc3ID4gMTcyLjE2LjEx
LjYzLjgyOiBGbGFncyBbLl0sIGFjayAxMDg4MzQsIHdpbiA3OTE1LCBvcHRpb25zIFtub3As
bm9wLFRTIHZhbCAyNjQ4NjE5OSBlY3IgNDE4MzE5NDI3OCxub3Asbm9wLHNhY2sgMiB7MTEz
MTc4OjExNDYyNn1bfHRjcF0+CjAwOjAwOjAwLjAwMDIzMyBJUCAxNzIuMTYuMTAuNjAuNTE2
NzcgPiAxNzIuMTYuMTEuNjMuODI6IEZsYWdzIFsuXSwgYWNrIDEwODgzNCwgd2luIDgwMDUs
IG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDI2NDg2MjAwIGVjciA0MTgzMTk0Mjc4LG5vcCxu
b3Asc2FjayAyIHsxMTMxNzg6MTE2MDc0fVt8dGNwXT4KMDA6MDA6MDAuMDAwMjQ4IElQIDE3
Mi4xNi4xMC42MC41MTY3NyA+IDE3Mi4xNi4xMS42My44MjogRmxhZ3MgWy5dLCBhY2sgMTA4
ODM0LCB3aW4gODA5Niwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjY0ODYyMDAgZWNyIDQx
ODMxOTQyNzgsbm9wLG5vcCxzYWNrIDIgezExMzE3ODoxMTc1MjJ9W3x0Y3BdPgowMDowMDow
MC4wMDAyMTcgSVAgMTcyLjE2LjEwLjYwLjUxNjc3ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFn
cyBbLl0sIGFjayAxMDg4MzQsIHdpbiA4MTg2LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAy
NjQ4NjIwMCBlY3IgNDE4MzE5NDI3OCxub3Asbm9wLHNhY2sgMiB7MTEzMTc4OjExODk3MH1b
fHRjcF0+CjAwOjAwOjAwLjAwMDI2OSBJUCAxNzIuMTYuMTAuNjAuNTE2NzcgPiAxNzIuMTYu
MTEuNjMuODI6IEZsYWdzIFsuXSwgYWNrIDEwODgzNCwgd2luIDgyNzcsIG9wdGlvbnMgW25v
cCxub3AsVFMgdmFsIDI2NDg2MjAwIGVjciA0MTgzMTk0Mjc4LG5vcCxub3Asc2FjayAyIHsx
MTMxNzg6MTIwNDE4fVt8dGNwXT4KMDA6MDA6MDAuMDAwMjQyIElQIDE3Mi4xNi4xMC42MC41
MTY3NyA+IDE3Mi4xNi4xMS42My44MjogRmxhZ3MgWy5dLCBhY2sgMTA4ODM0LCB3aW4gODM2
Nywgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgMjY0ODYyMDEgZWNyIDQxODMxOTQyNzgsbm9w
LG5vcCxzYWNrIDIgezExMzE3ODoxMjE4NjZ9W3x0Y3BdPgowMDowMDowMC4wMDAyNTAgSVAg
MTcyLjE2LjEwLjYwLjUxNjc3ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFncyBbLl0sIGFjayAx
MDg4MzQsIHdpbiA4NDU4LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAyNjQ4NjIwMSBlY3Ig
NDE4MzE5NDI3OCxub3Asbm9wLHNhY2sgMiB7MTEzMTc4OjEyMzMxNH1bfHRjcF0+CjAwOjAw
OjAwLjAwMDIwOSBJUCAxNzIuMTYuMTAuNjAuNTE2NzcgPiAxNzIuMTYuMTEuNjMuODI6IEZs
YWdzIFsuXSwgYWNrIDEwODgzNCwgd2luIDg1NDgsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFs
IDI2NDg2MjAxIGVjciA0MTgzMTk0Mjc4LG5vcCxub3Asc2FjayAyIHsxMTMxNzg6MTI0NzYy
fVt8dGNwXT4KMDA6MDA6MDAuMDAwMjYzIElQIDE3Mi4xNi4xMC42MC41MTY3NyA+IDE3Mi4x
Ni4xMS42My44MjogRmxhZ3MgWy5dLCBhY2sgMTA4ODM0LCB3aW4gODYzOSwgb3B0aW9ucyBb
bm9wLG5vcCxUUyB2YWwgMjY0ODYyMDEgZWNyIDQxODMxOTQyNzgsbm9wLG5vcCxzYWNrIDIg
ezExMzE3ODoxMjYyMTB9W3x0Y3BdPgowMDowMDowMC4wMDAyNDQgSVAgMTcyLjE2LjEwLjYw
LjUxNjc3ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFncyBbLl0sIGFjayAxMDg4MzQsIHdpbiA4
NzI5LCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCAyNjQ4NjIwMiBlY3IgNDE4MzE5NDI3OCxu
b3Asbm9wLHNhY2sgMiB7MTEzMTc4OjEyNzY1OH1bfHRjcF0+CjAwOjAwOjAwLjAwMDI0MyBJ
UCAxNzIuMTYuMTAuNjAuNTE2NzcgPiAxNzIuMTYuMTEuNjMuODI6IEZsYWdzIFsuXSwgYWNr
IDEwODgzNCwgd2luIDg4MjAsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDI2NDg2MjAyIGVj
ciA0MTgzMTk0Mjc4LG5vcCxub3Asc2FjayAyIHsxMTMxNzg6MTI5MTA2fVt8dGNwXT4KMDA6
MDA6MDAuMDAwMjE4IElQIDE3Mi4xNi4xMC42MC41MTY3NyA+IDE3Mi4xNi4xMS42My44Mjog
RmxhZ3MgWy5dLCBhY2sgMTA4ODM0LCB3aW4gODkxMCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2
YWwgMjY0ODYyMDIgZWNyIDQxODMxOTQyNzgsbm9wLG5vcCxzYWNrIDIgezExMzE3ODoxMzA1
NTR9W3x0Y3BdPgowMDowMDowMC4yODI3NjkgSVAgMTcyLjE2LjExLjYzLjgyID4gMTcyLjE2
LjEwLjYwLjUxNjc3OiBGbGFncyBbLl0sIHNlcSAxMDg4MzQ6MTEwMjgyLCBhY2sgMTAwLCB3
aW4gMTA0MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgNDE4MzE5NDYzMiBlY3IgMjY0ODYy
MDJdLCBsZW5ndGggMTQ0OAowMDowMDowMC4wMDIyODQgSVAgMTcyLjE2LjEwLjYwLjUxNjc3
ID4gMTcyLjE2LjExLjYzLjgyOiBGbGFncyBbLl0sIGFjayAxMTE3MzAsIHdpbiA5MDAxLCBv
cHRpb25zIFtub3Asbm9wLFRTIHZhbCAyNjQ4NjQ4NyBlY3IgNDE4MzE5NDYzMixub3Asbm9w
LHNhY2sgMSB7MTEzMTc4OjEzMDU1NH1dLCBsZW5ndGggMAowMDowMDowMC4zMzE0MjggSVAg
MTcyLjE2LjExLjYzLjgyID4gMTcyLjE2LjEwLjYwLjUxNjc3OiBGbGFncyBbLl0sIHNlcSAx
MTE3MzA6MTEzMTc4LCBhY2sgMTAwLCB3aW4gMTA0MCwgb3B0aW9ucyBbbm9wLG5vcCxUUyB2
YWwgNDE4MzE5NDk2NiBlY3IgMjY0ODY0ODddLCBsZW5ndGggMTQ0OAo=
--------------090509000204080901010707--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5500531C.1000109>