Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!A.ISI.EDU!CERF
From: CERF@A.ISI.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: What seems to be a glitch in the TCP spec.
Message-ID: <[A.ISI.EDU]25-Feb-89.12:14:49.CERF>
Date: 25 Feb 89 17:14:00 GMT
References: <8902240134.AA05182@vax.ftp.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 23

James,

thanks for taking time to describe the "glitch" scenario carefully.
The reasoning behind the advice to ignore the "old" packet is
that it isn't clear how old the ACK and WINDOW information is.
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. 

In general, the probe is needed - I don;t think there is any debate
on that point. The question is whether your slightly relaxed rules
for processing ACKs and WINDOWs is a net gain or opens the door to
new glitches. Intuition suggests that your "hack" [I don't mean
this in any pejorative sense] probably does more good than harm,
though I confess it feels slightly more pragmatic than my
puritanical attitudes allow me to enjoy.

Let's see what the reactions are from other practitioners.

Vint Cerf