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

On Tue, Mar 15, 2005 at 10:42:41AM +0900, Noritoshi Demizu wrote:
> > > I'm unsure about "send SACKs regardless of TF_ACKNOW".  Is there any
> > > specific reason why you want to do this?  It's implicit that we'll
> > > be sending an ACK back when we have SACK information (as in, we recei=
ved
> > > something out of order so we will be sending a Dup-Ack back), so I
> > > guess that the check isn't strictly neccecary, but...
> >
> > TF_ACKNOW will be cleared once we send an ACK.
> > however, we can still need to send (the same) SACK for the next segment.
>=20
> Let me show a couple of examples.
[snip]

Yeah, I see what the issue is now.

> By the way, I think TCP_SACK_MAX (declared in tcp_var.h) should be 4.

Yes, but I was working under the assumption that if a flow is SACK capable,
it will more than likely also be using the timestamp option.  It's trivial
enough to checdk for it, I suppose.

--=20
Kentaro A. Kurahone
SIGUSR1 Research and Development

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)

iQIVAwUBQjad3mfp+SLSG+tuAQK2rQ/+MoAt8o6dJQsSodZFBeup5ylWCFs+/Fvv
A0H1V59IF1e+rezltqFEcylpiUx+tiZEsasHWNNRcv7UpZ884K4l1EdqBg6WIwKS
FSPxBa73MUdMHGBUJ9r6miGeFldVOZFW3PXvpV7MTwZyzAezCiR6D+OBARcSd0/A
zCQsT6ILKN6S8Y+X/iSW8suMnlsAlnZQY3z7QizBmiyHbTk6vipN4doVnrMT3yhJ
pu7rq4HIoX10YIAEgqhQ8uJtH4YYonNB+R6pVsUgcjOdMFcR3LXquZQHxoP4pPVF
hwHZNN3udx3YQaL+tif+PjUy6hRK7OsnJfCYo8Xh9YrYBAeeW9jYe5gXBheElGdw
nzZBrk6NrItNmYoKKb2r8ABc3OjsVSKmT6gP8qucwulgb+EUSxl9jp9scKL96Zus
dXAlny/6ixOVmKNrRWZIcMz5YgiPzIyCW3yY6nTqi4BnoDZZ7DJf5wZmEfBY9KGC
f7neILNigLRcdY+xxrwXO0srEdOa//QgK7LxKshXNak/zvYnEWXgzf+DHEfhG86L
uO0sRwrhjmSRshJEwVYbGHNem/Z6w8DOape/3HF8eeKG7am6XAYoW446wGMDa40/
BjrhP/OQ4NnK2JcPMgz0iE9BI/IKvBo2MGOcPbKxm/UWC+ej9mg8Q1cUHfpVagow
vY7FvYbWvDI=
=mRYa
-----END PGP SIGNATURE-----

--ReaqsoxgOBHFXBhH--