--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 15, 2005 at 06:57:56AM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> > > - send SACKs regardless of TF_ACKNOW.
> > > - don't clear rcv_sack_num when transmitting.
> >=20
> > Also now that I think about it, since the SACK information needs to
> > be in time sequence, we should clear out the sack block list (receiver)
> > each time we send SACK information.
>=20
> what do you mean by "SACK information"?
> if it's about the order of SACK blocks in the SACK option,
> they should be in time order regardless of
> whether tcp_output clears rcv_sack_num or not.

I meant to say that we should avoid sending SACK blocks when we aren't
in a loss episode.  rcv_sack_num is cleared out on a in sequence packet
so the case I was worried about won't happen.
=20
> rfc says:
> "If sent at all, SACK options SHOULD be included in all ACKs which do
> not ACK the highest sequence number in the data receiver's queue."
>=20
> by clearing rcv_sack_num in tcp_output,
> currently we include SACK option only for the first transmit
> after tcp_update_sack_list.
> i don't think it's a correct behaviour, esp. when a connection has
> enough flow for both directions.

Ah, I see what you're getting at.  Yeah, not clearing it out when we send
the ACK off is the correct thing to do.

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

--4Ckj6UjgE2iN1+kY
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQIVAwUBQjYNyGfp+SLSG+tuAQJx+BAAjjAJas6jfT/49MoA/48wgBvEOczxwsnk
2XLpPOS3yjjlfa0liB+1+/hFp6V6YuImtRXPNLlCsBFz7SoSnTC4eDuHLb6+c78V
258lmbxJfOZ5Ib+rmsSZzWGEs08ddMk+IZfa70fL64k/Hz51+rMI5y5IN3My1H9A
AVxzArifh3Mt1M2H0cDGyvSMunl25K/kZ8R8ee3OJPS7+Ktxbla04F7bWQeFMRzh
ysFyG3pF3rDpIsUgtqUJy4tVOBimQV/j2CJ6TYCHBBdcciCkHfXKp1K4+StQJnRQ
BaXuAjjLQkZt0RZDaUdVH26Qu+Ug+wNv5oCdY1OEmV8cOQI/Dh6wCevZPdjRovqJ
LAWiSLJgSoIgjfR1kPLTJokwbYEsXk8RwEksrM0dn75PYfvc5voDxBoRWsgtey5R
+p63M5mzU4J/swPDsLmT75NzS0ENjcJGfd4EiajWfCyhVYoTL/Kv7SPfbPdc57+b
hNS7tFzmyFOEJR/iiH/CUNHOmbch+5JaTrvKEDnFhyRdVZlzIz+zYlQKtr4srEI3
8TfrhyIf9Cpm2Dsx3m09/rH0ppRlIH8CkmyY4ulkVgmazGGIOmx0dsMscbGhWVt/
FXyw2Ts7Z2WhTiy67CtSWJ3aLRTRTSu546ryExbsfP/5SPQHlUOvhVLPcWBiW8Xj
dwMbvlzc2tc=
=H8pU
-----END PGP SIGNATURE-----

--4Ckj6UjgE2iN1+kY--