Setting congestion window on loss detection
hiren at strugglingcoder.info
Sat Oct 31 00:33:25 UTC 2015
On 10/12/15 at 10:19P, hiren panchasara wrote:
> On 10/07/15 at 12:54P, hiren panchasara wrote:
> > Found this issue about a month ago and started a discussion on -net:
> > https://lists.freebsd.org/pipermail/freebsd-net/2015-September/043249.html
> > I feel this forum is a better place to discuss this further now.
> > Problem: We set cwnd to 1mss when we detect loss via arrivals of 3 dupacks.
> > That is wrong as we severely underutilizing network capacity by doing
> > so.
> > Next question is, what should we set cwnd to?
> > RFC6675 (TCP SACK) suggests following on detecting loss:
> > ssthresh = cwnd = (FlightSize / 2)
> > RFC5681 (TCP Congestion control) suggest:
> > ssthresh = max (FlightSize / 2, 2*SMSS)
> > cwnd = (ssthresh + 3*SMSS)
> > (Here, FlightSize is bytes in flight.)
> > OR should we let whatever congestion control (CC) algo in control decide
> > that value?
> I also tried to look at what Linux does. It has PRR (Proportional Rate
> Reduction) RFC 6937 (something I plan to work on after these initial
> needed fixes/improvements) in place. Looking back pre-PRR code, linux
> seems to be doing following:
> cwnd = min(cwnd, FlightSize)
> Here, cwnd in the equation is adjusted as per rate-halving
> (draft-mathis-tcp-ratehalving-00) which says "the window is reduced by
> sending one data segment for each two segments which are acknowledged".
> (I am not very familiar with linux code so please correct me if that's
> not the case.)
> Basically, I think any of these approaches is better than what we have in
> the tree right now.
As suggested by Randall on the transport group call, I'd go ahead and
see if following RFC6675 gives us any better results with different
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 603 bytes
Desc: not available
More information about the freebsd-transport