On Wed, 2018-03-07 at 23:39 +0200, Ilpo Järvinen wrote:
>
> The problem I'm trying to fix is due to window increasing (of
> course,
> dupacks could also be masked because of decrease but that's something
> I've never seen to occur in practice) so I tried to make you happy
> and
> change my fix t
On Wed, 7 Mar 2018, Eric Dumazet wrote:
> > Currently non-SACK senders cannot identify almost any duplicate ACKs
> > because the window keeps updating for almost all ACKs. As a result,
> > non-SACK senders end up doing loss recovery only with RTO. RTO
> > recovery
> > without SACK is quite anno
Thanks for taking a look.
On Wed, 7 Mar 2018, Eric Dumazet wrote:
> On Wed, 2018-03-07 at 14:59 +0200, Ilpo Järvinen wrote:
> > Currently, the TCP code is overly eager to update window on
> > every ACK. It makes some of the ACKs that the receiver should
> > sent as dupACKs look like they update wi
On Wed, 2018-03-07 at 22:09 +0200, Ilpo Järvinen wrote:
> Thanks for taking a look.
>
> On Wed, 7 Mar 2018, Eric Dumazet wrote:
> > On Wed, 2018-03-07 at 14:59 +0200, Ilpo Järvinen wrote:
> > > Currently, the TCP code is overly eager to update window on
> > > every ACK. It makes some of the ACKs t
On Wed, 2018-03-07 at 14:59 +0200, Ilpo Järvinen wrote:
> Currently, the TCP code is overly eager to update window on
> every ACK. It makes some of the ACKs that the receiver should
> sent as dupACKs look like they update window update that are
> not considered real dupACKs by the non-SACK sender-s
Currently, the TCP code is overly eager to update window on
every ACK. It makes some of the ACKs that the receiver should
sent as dupACKs look like they update window update that are
not considered real dupACKs by the non-SACK sender-side code.
Make sure that when an ofo segment is received, no ch
