At 02:18 PM 3/14/2005, Kentaro A. Kurahone wrote:
>On Tue, Mar 15, 2005 at 06:57:56AM +0900, YAMAMOTO Takashi wrote:
> > hi,
> >
> > > > - send SACKs regardless of TF_ACKNOW.
> > > > - don't clear rcv_sack_num when transmitting.
> > >
> > > 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.
> >
> > 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.

That's still wrong.  rcv_sack_num should only be cleared when there
are no out-of-order packets (in other words, the reassmebly queue
is empty).

I think rcv_sack_num should be renamed timeq_count and be maintained by
tcp_reass.  It is simply the number of ipqe elements in the timeq.  I
don't see a reason for rcv_sack_block to exist either.  That information
is in the first three elements of timeq (and is why timeq exists).

snd_holes should be able to cache the starting mbuf that contains first
byte of data after the hole and the offset in that mbuf to it.  This is
analogous to t_lastm and t_lastoff.

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.