hi,

> For now, I beleive NetBSD requires a conservative strategy: one
> where we have a SACK that is correct in all cases. I'd even give
> up DSACK to be sure that the SACK-only functionality is
> fully RFC-conformant and correct.
> 
> Sending one less SACK block than the absolute maximum, in the (rare?)
> case of a peer that will do SACK, but not timestamps, fits my definition
> of "conservative", as it eliminates some corner-case logic.

from rfc:
	The data receiver SHOULD include as many distinct SACK blocks as
	possible in the SACK option. 

> On that note: just by quickly skimming the code, I can no longer
> quickly convince myself that tcp_update_sack_list() is fully
> conformant with RFC-2018 .  The original FreeBSDBSD code comments that:

quickly skimming?  i thought you reviewed the code before commit. :-)

YAMAMOTO Takashi