--Yia77v5a8fyVHJSl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 08, 2004 at 01:53:58PM -0800, Jonathan Stone wrote:
>=20
> In message <75109204-31CC-11D9-ACC4-000A957650EC@shagadelic.org>Jason Tho=
rpe wr
> ites
>=20
> >Basically, systems that have this bug implement a delayed ACK policy of=
=20
> >"ACK every 2 maximum-sized segments", and more or less count bytes=20
> >until they've received "2 * MSS" since their last transmitted ACK.
>=20
> [snip text of Jason's scenario]
>=20
> Yes, but if you get packet loss (e. g., due to congestion from
> multiple flows crossing the router onto one or other subnet), then the
> stretch-ACK bug breaks Fast Recovery, and you incur full slow
> timeouts. Which sounds to me more like what Bill was seeing.

=46rom what I understand of the stretch-ACK bug, it would be important if=
=20
the receiving OS has it. The receiving OS in this scenario is NetBSD, so I=
=20
am not clear if it will matter.

Note: as best I can tell from looking at the committs to FreeBSD, the fix=
=20
that got pulled into FreeBSD 4.5 was in fact a fix to not delay an ACK if=
=20
the last window advertizement was 0. In this case, the ACK gets sent now=20
so that the other side can start sending again. While this case can be=20
important for rapid input & output, I don't think it impacts what I was=20
seeing.

However the fact is that FreeBSD seems to have had the same New Reno code
we have and found it to be broken & then fixed it. I think we should care.=
=20
:-) Does anyone else?

Take care,

Bill

--Yia77v5a8fyVHJSl
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBj/q7Wz+3JHUci9cRAh0KAJ4ugNOhX8tOzQ7aiuTBbvR5pu0vmgCfSAqV
j2ygrecygPAByuiTzAvwGHA=
=Yc8U
-----END PGP SIGNATURE-----

--Yia77v5a8fyVHJSl--