Date: Mon, 16 Nov 2015 21:22:24 +0000 From: Jonathan Looney <jlooney@juniper.net> To: hiren panchasara <hiren@strugglingcoder.info> Cc: FreeBSD Transports <transport@FreeBSD.org>, Randall Stewart <rrs@netflix.com> Subject: Re: Maintaining dupack counter per hole (was: The trouble with sack..) Message-ID: <D26FAC0C.4B8E0%jlooney@juniper.net> In-Reply-To: <20151116204145.GX29829@strugglingcoder.info> References: <DA8A5844-8F11-42D5-B923-3F329203B867@netflix.com> <20151030062423.GB5261@strugglingcoder.info> <D258E1AC.4A234%jlooney@juniper.net> <20151116180644.GU29829@strugglingcoder.info> <D26F88C5.4B837%jlooney@juniper.net> <20151116204145.GX29829@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/16/15, 3:41 PM, "hiren panchasara" <hiren@strugglingcoder.info> wrote: >On 11/16/15 at 07:19P, Jonathan Looney wrote: >>This somewhat makes sense. And, it looks like you are charging all >> existing holes for each ACK that doesn't cover them (regardless of the >> fact that it isn't really a "duplicate ACK" in this case). That also >> generally makes sense. > >Why do you say those are not duplicate acks? I know this goes into now >the definition of a duplicate ack what what we mean by that but to me, >this is *the* benefit we get from SACK that we can identify these guys >as duplicate acks. Right. What is a duplicate ACK? Actually, SACK lets us differentiate between these ACKs. Without SACK, we would see three ACKs for the same segment. We wouldn't know that the receiver actually had received three later segments. However, with SACK, we have more information about what the remote side actually received and we can (and should) use that to make intelligent decisions about what to retransmit and when. I say these aren't duplicate ACKs because the are selectively ACKing different data. I know the code considers them "duplicate" because the ACK field in the TCP header is unchanged. But, the SACK option gives us further information. >>=20 >>If we instead reset the counter for a hole anytime the hole was partially >> ACKd (including being split), we would retransmit less aggressively. In >> this example, that would probably be good. >>=20 >> A middle-ground is to charge all holes every time we receive an ACK that >> does not partially ACK the hole. If a hole is partially ACKd, neither >> charge the ACK with a strike nor reset the counter. > >This is the idea I don't agree to. SACK which partially acks does tell >us something important and IMO it'd be bad if don't consider that >information and strike the counter. [...] >So, coming back to your example, it's a valid problem. But this is >not a valid solution for it. Why not? I don't have much invested in the idea. But, I'd like to understand your reasoning. >When you know that you are introducing some >degree of reordering as a sender (as your example shows), the dupack >threshold should be bumped up to that degree. That's fine. Anything that lets us use the SACK data to make intelligent decisions. My main argument is that a fixed "retransmit after X ACKs" rule is insufficient, whether applied on a per-hole or per-tcpcb basis. > Now, linux does this with some smart heuristics. It tracks per > connection degree of reordering that dupack threshold is always set to > that for any point in time. I am wondering it something like that'd > help. OR at least, a sockopt that anyone can set (much simpler than > coming up with heuristics logic for the first pass) for their dupack > threshold. This would probably help your case very much. A sockopt would be simpler, but I don't think it helps my example unless I implement user-space logic to track reordering (which seems like it would be hard to do well). This is why I like the idea of changing the way we count strikes. I don't think it is as good as the Linux heuristics sound, or even as the Google RACK algorithm may be. But, I think we could improve on the strike-counting code to make our SACK performance better than what we have now (even after we fix the bugs ;-) ). Jonathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D26FAC0C.4B8E0%jlooney>