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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > > -- cys _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
