Date: Wed, 19 Dec 2018 21:21:57 +0000 From: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> To: "hiren@strugglingcoder.info" <hiren@strugglingcoder.info> Cc: "freebsd-transport@freebsd.org" <freebsd-transport@freebsd.org> Subject: possible RFC6675 compute_pipe counting issue. Message-ID: <SN4PR0601MB3728CD36E28E1D473715F51586BE0@SN4PR0601MB3728.namprd06.prod.outlook.com>
next in thread | raw e-mail | index | archive | help
Hi Hiren, I'm trying to reactivate my old Lost Retransmission Detection patch. And I found your 2015 patch around sacked_bytes (RFC6675) here https://github.com/rscheff/freebsd/commit/d3c29dd43ff23e293d5988258493015fb= 4a072ba (The line ~389 in tcp_sack.c) But I think the code is problematic in two reasons: a) very thin clients, which may only send SACK deltas instead of full excer= pts of the scoreboard (e.g. only a sack block covering the most recent rece= ived data) b) whenever the receiver scoreboard has more discontinuous entries than wha= t a single ACK can carry as SACK fields (typically 3, possibly 4 or as litt= le as one). However, these will overestimate the outstanding data (pipe). (a) A cheating receiver sending multiple, identical sack blocks could game = the sender, though, as the check is done on a ack sack block by block check= , rather than when the scoreboard is updated... Reason: Your patch only looks at the SACK data contained in the most recent= ACK, rather than proper accounting of the non-sack holes in the scoreboard= . When I improved Aris PRR code, I did the accounting when the scoreboard is = being updated; sacked_bytes need to exclude any snd.una move to the right, = but should be similar: https://github.com/rscheff/freebsd/commit/4a4877478fe55e8ebdfa0daf9a2be4b21= 2d07cde As PRR needs a proper value for the delivered delta bytes per ACK, it shoul= d be simple to keep track of the correct value for the SACKed bytes (not ho= les) in the scoreboard too... Obviously, this can not be that much of an issue, as RFC6675 pipe is disabl= ed by default, and would underestimate the number of sacked bytes at the re= ceiver, unless the receiver has malicious intent... Any thoughts? Best regards, Richard =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SN4PR0601MB3728CD36E28E1D473715F51586BE0>