From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 11:52:40 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 694FF16A41F for ; Fri, 21 Oct 2005 11:52:40 +0000 (GMT) (envelope-from yschoi@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7758A43D4C for ; Fri, 21 Oct 2005 11:52:39 +0000 (GMT) (envelope-from yschoi@gmail.com) Received: by xproxy.gmail.com with SMTP id i29so64728wxd for ; Fri, 21 Oct 2005 04:52:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Ujkng3qOIakrr4T/2+CsXAnE3An6H96UFbAC1rc6HWK6n5zECoDwbdfKKTGSXqiG8r25Cf8m9IfZ9gxrXNCYBM0nySw4jHhBi6KJRchubl2UqZAxdyS2TStrW9OqSERI3tqGyMFXq1XpB8TlgWoDnRQ12A+p5jY+LqP16nFUXiU= Received: by 10.70.53.10 with SMTP id b10mr1730031wxa; Fri, 21 Oct 2005 04:52:38 -0700 (PDT) Received: by 10.70.92.1 with HTTP; Fri, 21 Oct 2005 04:52:38 -0700 (PDT) Message-ID: <5a8ce9ca0510210452j274fe919g5c589f2eaf919ff5@mail.gmail.com> Date: Fri, 21 Oct 2005 20:52:38 +0900 From: cys To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: What is the Right Action about window shrinking by zero window advertisement?(tcp_input.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 11:52:40 -0000 Hi. e.g.) pkt 1 2 3 4 5 6 sent(snd_wnd=3D6) receiver sent ACK 2 with snd_wnd=3D0(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=3D4 (4 =3D 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 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 i= t. > > 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@neterion.com > > > -- cys