What is the Right Action about window shrinking by zero window advertisement?(tcp_input.c)

[cys]

Hi.

e.g.)
pkt 1 2 3 4 5 6 sent(snd_wnd=6)

receiver sent ACK 2 with snd_wnd=0(pkt 1 received successfully)

because rcv buffer is full, pkt 2,3,4, dropped.

sender go into persist mode.

when pkt 5, 6 arrived, rcv buffer is now empty. So receiver send ACK2
with snd_wnd=4 (4 = 6-2 : 6 is receiver buffer size, 2 is pkt 5&6)

Will sender retransmit packet 2,3,4,5,6...?(without Fast Retransmit or
Rtx timeout?)

>From above scenario, pkt 2,3,4 dropped due to "receiver congestion"
not "network congestion". Can TCP distinguish between them?

> 1. (Preferred) accept the shrunk window.  In this case, TCP should not
> send beyond the new window RHS (SND.UNA+SND.WND-1) but should retransmit
> normally up to that point.
--snip--
> Setting SND.NXT to SND.UNA is a BSD implementation convenience.  The RFC
> does not do this.  For BSD, SND.MAX contains the "old" value of SND.NXT
> (I believe).  SND.MAX can always be used to distinguish new data tx from
> retx - useful for things like RTTM, some ECN updates, etc.

I think above cluase means that TCP can't distinguish. And TCP assume
pkt 2,3,4,5,6 is lost& retransmit.(am I right?)

Thank you in advance.

Subject: Re: [e2e] Question about managing window(rfc1122, 4.2.2.16)
On 10/21/05, Steve Arden <steve.arden at neterion.com> wrote:
> (off-list reply)
>
> Hi there,
>
> I believe some of the confusion is because RFC1122 allows two broad
> classes of behaviour:
>
> 1. (Preferred) accept the shrunk window.  In this case, TCP should not
> send beyond the new window RHS (SND.UNA+SND.WND-1) but should retransmit
> normally up to that point.
>
> 2. Ignore the shrunk window and keep the old window RHS.  This is not
> ideal but is permitted.  Hence everything is SHOULD, SHOULD NOT and MAY
> instead of MUST and MUST NOT.
>
> Because #2 is allowed, and because the window update heuristic may
> filter out shrinks anyway, no TCP stack can count on window shrinks
> "working".  If the window is shrunk and not grown again, the connection
> may timeout.
>
> Roughly speaking, the only real obligation for a sending TCP is not to
> crash, and to eventually recover if the window reopens before timeout
> occurs.
>
> > >RFC1122
> > >However, a sending TCP MUST be robust against window shrinking, which
> > may >cause the "useable window" (see Section 4.2.3.4) to become
> > negative.
> >
> >
> > >If this happens, the sender SHOULD NOT send new data,
> > What is the "new data"?? data beyond SND.UNA+SND.WND?
> > When does sender start transmit new data?
>
> New data is anything that has not yet been sent, ie anything beyond
> SND.NXT (or SND.MAX depending on the implementation).
>
> Keep in mind that Stevens, especially vol2, documents the BSD TCP
> implementation not the standards.  BSD differs from the standards
> occasionally for implementation convenience.
>
> In the case of window shrinks and retransmits, BSD adjust SND.NXT back
> to the window limit or the next byte to retransmit.  It records the high
> watermark in SND.MAX.  The RFCs (at least up to 2581) do not do this.
> They leave SND.NXT at the highest byte sent.
>
> This is exactly equivelant, only the variables are defined differently.
> So if the RFCs refer to SND.NXT, the BSD equivelant is SND.MAX in some
> situations.
>
> > >but SHOULD retransmit normally the old unacknowledged data
> > >between SND.UNA and SND.UNA+SND.WND.
> > >The sender MAY also retransmit old data beyond SND.UNA+SND.WND, but
> > >SHOULD NOT time out the connection if data beyond the right window
> > edge
> > >is not acknowledged. If the window shrinks to zero, the TCP
> > >MUST probe it in the standard way (see next Section).
> >
> > Does above cluase mean that TCP can transmit data "before" probing or
> > going to persist mode??
> >
> > If it is(transmit some pkts before probing), how it can be possible?
> > SND.WND is already 0, isn't it?
>
> No, it does not send packets then probe (well actually that is not
> prohibited but it does not make sense).
>
> The intend (for the preferred behaviour - #1 above) is that TCP either
> probes or retransmits data based on the new window.  If the window has
> shrunk to zero it probes.  If it has shrunk (below SND.NXT) but is
> non-zero, it should stop sending new data and should retransmit data up
> to the new window as timeouts occur.
>
> This text:
>        The sender MAY also retransmit old data beyond SND.UNA+SND.WND,
>        but SHOULD NOT time out the connection if data beyond the right
>        window edge is not acknowledged.
> is there to allow the (non-preferred) behaviour of ignoring the window
> shrink (#2 above).
>
> > If it It isn't, what is the old unacknowledged data?
> > TCP already set SND.NXT to SND.UNA. And I think TCP can't distinguish it.
>
> Setting SND.NXT to SND.UNA is a BSD implementation convenience.  The RFC
> does not do this.  For BSD, SND.MAX contains the "old" value of SND.NXT
> (I believe).  SND.MAX can always be used to distinguish new data tx from
> retx - useful for things like RTTM, some ECN updates, etc.
>
>
> Hope this helps.
>
> --
>
> Steve Arden
> Neterion Corporation
> steve.arden at neterion.com
>
>
>

--
cys