Setting congestion window on loss detection

hiren panchasara 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
loss scenarios.

Cheers,
Hiren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-transport/attachments/20151030/3257513b/attachment.bin>


More information about the freebsd-transport mailing list