Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: What seems to be a glitch in the TCP spec.
Message-ID: <8902261709.AA02291@vax.ftp.com>
Date: 26 Feb 89 17:09:00 GMT
References: <[A.ISI.EDU]25-Feb-89.12:14:49.CERF>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35


   From: CERF@A.ISI.EDU

   ....
   We were concerned about disorderly arrivals in which window information
   is delivered in reverse of the order sent (e.g. opening the window
   and then closing it again). If we follow your rule 4, is there a
   scenario in which disorderly arrival leaves A believing the window
   is closed when it isn't? Of course, in that case, the probe mechanism
   should provide more up to date information. 

As I see it, there have always been cases where disorderly arrival of window
updates can leave one host believing the window is closed when it should't.
Consider the unidirectional case:

1.		Seq 100, Ack 200, Data 50, Window 4096 ->

2.	    <-	Seq 200, Ack 150, Data 0, Window 0

3.	    <-	Seq 200, Ack 150, Data 0, Window 50

If 3 arrives before 2, and the sender doesn't have more data ready to go
before 2 shows up, the window looks closed.  Of course, it shrank to get
there, but there are enough TCPs that shrink the window that the sender
will probably manage to deal with it.  Probes will restart the data flow
just fine, but with a glitch.

Part of the problem is that X may be the first widely-used application to
provide a fast, intermittent bi-directional load to TCP.  The remainder is
because PC interfaces have to offer 1-segment windows to survive when talking
to faster hosts.  When the window is 2*MSS or more, this is much less likely
to happen.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901