In message <1110942499.132341.1244.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi writes:

[...]

>> 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. 

SHOULD is not MUST, and we have other constraints.  But that said,
if we can do it safely and very low-risk, on a today-ish timeframe, I
won't object.


>> 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. :-)

Sigh... I was looking for a polite way to say that, after another
comparison to the FreeBSD code (which does explain itself on a quick
glance), that portion of our (Kentaro's) code could be clearer.