SACK retransmits multiple segments respond to single dupack

[Mohan Srinivasan]

Hi,

Which release are you experimenting with ? There was a bug 
in 5.3 that would cause SACK to burst multiple segments on
a dupack reception. But that was fixed both in -current
and in RELENG_5 (1.100.2.3 and 1.102). From what I see,
the fix was never MFC'ed to RELENG_5_3. 

Referencing the code in -current,

dupack handling starts at line tcp_input.c:1797. When SACK
recovery is first set up, upon reception of 3 dupacks, we
set cwnd to 3 (line 1867) and call tcp_output(), which would
cause 3 segments from the scoreboard to be retransmitted.
BTW, this value can be changed (to 1) with the sysctl 
tcp_sack_recovery_initburst. Once SACK recovery is set up,
subsequent reception of dupacks will goto line 1826, which
should cause just one segment to be transmitted.

If you look at tcp_output(), you'll notice that before sending
data (while in sack recovery), we compute the amount of 
retransmitted data in the scoreboard and the amount of 
new data sent in the recovery phase and use this value to 
adjust cwnd down. This is the change that I referenced above
that's missing in RELENG_5_3.

mohan

--- Daikichi Osuga <osuga at nim.yrp.nttdocomo.co.jp> wrote:

> Hello,
> 
> I had experiments with FreeBSD SACK implementation.
> FreeBSD SACK retransmits multiple segments respond to single dupack.
> It breaks "packet conservation principle".
> 
> In OpenBSD SACK implementation,
> retransmission from SACK hole is limited to single segment.
> "sack_rxmit" and "sendalot" are exclusive. 
> 
> I think solution is introducing mechanism to estimate amount of outstanding segments.
> For example, "pipe" alogorithm is well known.
> http://www.icir.org/floyd/talks/sf-sacks-96.pdf
> 
> Regards,
> --
> Daikichi Osuga
> 
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>