Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!PURDUE.EDU!narten
From: narten@PURDUE.EDU (Thomas Narten)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: What seems to be a glitch in the TCP spec.
Message-ID: <8902252108.AA07657@percival.cs.purdue.edu>
Date: 25 Feb 89 21:08:51 GMT
References: <8902240134.AA05182@vax.ftp.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30

>Consider the following situation:  A TCP connection is carrying
>intermittent, bidirectional traffic.  Host A has just sent a burst
>which filled host B's window.  B has enough data for a small segment,
>piggybacking the Ack and indicating a window of 0.  A replies with an
>Ack, just as B's application consumes the data and B sends a segment
>to re-open the window.  B's implementor has chosen to retransmit the
>first segment of un-acked data (if any) with window updates and Acks
>(B's cost/packet is much larger than the cost/byte).  A's implementor
>has exactly followed pg. 69 of RFC 793, which says to discard segments
>with obsolete data before checking the Ack or Window values.

James:

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.

Case 1 implies the retransmit timer is broken (in which case said
scenario is the least of your worries) or that the transmission path
is lossy (again, probably more serious than the described problem).

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?

Thomas