Subject: Re: CVS [email-masked]: linux

From: Andi Kleen <[email-masked]>
Date: Mon, 18 Jan 1999 22:17:17 +0100

On Sun, Jan 17, 1999 at 10:39:18PM -0800, David S. Miller wrote:
>    Date: Sun, 17 Jan 1999 13:07:20 +0100
>    From: Andi Kleen <[email-masked]>
> 
>    If I understand RFC2018.8 (Data Receiver Reneging) correctly they
>    require reporting the last received sack block (even if it was
>    discarded) so that the sender has the best possible idea about
>    'forward process' on the connection. Linux violates that currently.
> 
> I still don't understand.  If we discard it, why should we report a
> SACK about it?  It sounds to me like the RFC is asking us to
> acknowledge data not in our queue, that simply does not make any
> sense.

A SACK is not a real ack, the 2018 requires that all data is kept
in the retransmit queue until it is acked by the "classic" ack field.

> 
> I might be missing something critical, if so please help me
> understand.
> 
> But how I see it right now the RFC simply makes no sense.

I am not sure if I understand the intentions of the RFC correctly,
but for me it looks the authors valued the information about forward progress
(to update the neighbour entry?) as more important as the delay the
additional SACK may cause (the sender will eat an timeout to clear the 
SACK flags in the retransmit queue). I assume they had some good reasons
to specify that, but maybe that is a good question for the tcpimpl group
cc'ed there, maybe someone there can shed light on this. 

-Andi

---

From: "William Li" <[email-masked]>
Date: Tue, 19 Jan 1999 10:08:12 -0800

On Jan 18, 10:17pm, Andi Kleen wrote:
> Subject: Re: CVS [email-masked]: linux

> > acknowledge data not in our queue, that simply does not make any

What I understand is that a receiver discard the data but must SACK it. The
discard part is because the receiver runs out resource (receiver buf), the
SACK part is to notify the sender that it should not retransmit this
data right away.

> -Andi
>-- End of excerpt from Andi Kleen

-- 
William Li
[email-masked]/650-933-3751

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 19 Jan 1999 16:46:06 -0800 (PST)

> additional SACK may cause (the sender will eat an timeout to clear the  SACK
> flags in the retransmit queue). I assume they had some good reasons to
> specify that, but maybe that is a good question for the tcpimpl group cc'ed
> there, maybe someone there can shed light on this. 

One reason may be consistency.  Suppose a TCP stack decides to free up
segments in the receive queue.  But it has already sent ACKs with SACK
info for those segments.  For the newly received segments, which are
going to be dicarded, it is more consistent to SACK them also.

Also, for those implementations which make use of the SACK info to
determine the number of segments in the pipe, not SACK'ing the received
but discarded segments may disrupt their calculations.  Granted, ACKs can
be lost.  But if they are not lost, SACK info can help the sender to
make more intelligent choice.  An intelligent sender may keep a count on
the SACK'ed segments.  Since the RFC requires that those received but
discarded segment will only elicit one SACK block, it may make an
intelligent choice to retransmit a SACK'ed segment by looking at the
SACK count pattern.  So a timeout may not be needed.

To me, SACK info is an aid for a sender to make intelligent choices
in sending.  Receiving a segment but failing to SACK it takes away some
of the benefits of SACK.

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 19 Jan 1999 16:46:06 -0800 (PST)

K. Poon.
							[email-masked]