Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: What seems to be a glitch in the TCP spec.
Message-ID: <8902261649.AA02266@vax.ftp.com>
Date: 26 Feb 89 16:49:29 GMT
References: <8902252239.AA28962@eleazar.dartmouth.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 49


   Solution (4), honoring the ACK and window of a pkt rcvd just to the
   left of the receive window, seems to be the defacto standard.  As I'm
   sure you know, BSD TCP does this.  So do the TCPs developed locally.

   Philip Koch
   (Philip.Koch@Dartmouth.EDU)

If this is the case, I wish that the Sun and HP TCP mungers hadn't chosen to
change their bsd-derived code to exact conformance with pg. 69 of RFC 793.

   From: Thomas Narten <narten@purdue.edu>

   Did you stumble across this example in an actual case?  It strikes me
   that it should not happen under "normal" conditions.  The keyword is
   "retransmit".  The above scenario has B piggybacking the window update
   on a retransmission.  But this implies 1)  B's retransmit timer has
   fired before the ACK for the first transmission has returned, or 2) B,
   aware that the cost per packet is higher than the cost per character,
   thinks it can get ahead by including some of the already transmitted data.

My problem is indeed a real-world one, observable with an X-windows server
running on the PC and communicating with HP-UX 9000/350 and Sun 3/50
X clients.  The Sun is running 3.5, I don't know the HP release, I can
obtain it if anyone (are support people listening?) is interested.

   Rather than a glitch in the spec, wouldn't this qualify as feature of
   case 2?  Which RFCs suggest retransmitting the first segment of
   un-acked data (if present) when sending window updates and ACKs?

Yes, it is a feature of case 2 (I am retransmitting the data before the
timer fires).  There are complicated reasons (most historical, relating
to the PCIP ancestry of the TCP implementation) why it is much easier
to do this, so we always have.  I freely admit to doing something that
wasn't proven (right or wrong) by anyone else, but 793 doesn't tell me
not to, either.

I am willing to accept "don't include window updates or acks with retransmits",
(my solution (2)) if this is the consensus, but I have seen some significant
support for checking the window and ack if the segment is only slightly
obsolete, or even regardless of SEG.SEQ.  Many implementers have faced this
issue, but the answers they chose haven't been published.  I want to air the
issue because we have unhappy users, and the fact that 793 allows the glitch
means that they won't be the last people bitten by it.  We may well have to
implement separate window update segments anyway, just because of relative
company sizes...

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