Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpcc05!hpcuhb!hpda!hpcupt1!hpindwa!alp
From: alp@hpindwa.cup.hp.com (Arnold Patton)
Newsgroups: comp.protocols.tcp-ip
Subject: Questions on TCP shutdown and RFC-793
Message-ID: <36540017@hpindwa.cup.hp.com>
Date: 8 Dec 90 00:33:40 GMT
Organization: Hewlett-Packard, Cupertino CA
Lines: 76


I have two questions concerning the implementation of TCP and the
interpretation of RFC-793, specifically concerning connection
shutdown.

Question #1:

In step 8, on page 75, RFC-793 states that:

  "If the FIN bit is set, signal the user 'connection closing' and
   return any pending RECEIVEs with same message, advance RCV.NXT
   over the FIN, and send an acknowledgment for the FIN.  Note that
   FIN implies PUSH for any segment text not yet delivered to the
   user."

Notice that the RFC does not mention checking the current RCV.NXT
value against the FIN sequence number.  If one were to interpret this
literally, then it would seem that one would accept the FIN and change
states even if there were still holes in the TCP reassembly queue due
to lost or dropped packets (assuming that we are doing the right thing
and not accepting only in-order packets).  If that is the intent of
the RFC, then the statement about PUSHing any text not yet delivered
is ambiguous or at least not detailed enough, since it is possible to
have data both before and after a hole in the reassembly queue.  Do we
push only the data before the hole?  Or do we push all the data and
ignore the hole?

It seems to me that this was not the intent of the RFC, and that the
assumption was being made that there would not be any holes in the
reassembly queue (which is normally the case) when the FIN is
received.  In my understanding, the FIN handshake was intended to
insure that all data has been received by both sides.  The "literal
interpretation" above would defeat this attribute of the FIN handshake.
I thought that perhaps HOSTS RFC (RFC 1122) had clarified RFC-793's
statement, but it does not.  In fact, when I checked a copy of the BSD
4.3 TCP code, it appears that they indeed accept the FIN no matter
what!  (However, I haven't tested the actual behavior of the code, and
I may have overlooked something.  It would be difficult to believe
that the BSD code would behave this way.)

Also, if you do not accept the FIN right away, what do you do with it?
Options seem to be either set some state vector or to drop the FIN
packet and to pick it up in a retransmission after your reassembly
queue has been filled.  The second option would cause a delay in
waiting for the retranmitted FIN, and has a potential danger in that
if the retransmitted FIN is dropped in between (say at a gateway), the
remote connection half may time out.  However, the first option also
has the preformance penalty of always needing to check against this
new state vector to see if we should accept the FIN now.

Does the standard really intend some sort of bizarre behavior here?
Or does someone know of a reference in the standards which clarifies
things?  What behavior do BSD SOCKETS and other ULPs based on TCP
expect?  Or have I missed the boat entirely and overlooked something
in RFC-793?

Question #2:

This question also regards TCP connection shutdown implementations.

I thought that I read somewhere (I thought it was HOSTS RFC) that if
you get a FIN without an ACK of FIN while you are in the FINWAIT1
state that you should reply with a FIN, ACK of FIN packet (not just
ACK of FIN as RFC-793 states), but I can no longer find the reference.

I can see why you might want to do this, but I think it would work either
way.

Was I just imagining things?  Or does someone know of such a reference?
If you could pass it on to me, it'd be much appreciated.

-------------------------------------------------------------------------------
 Arnold Lee Patton    | MPE/XL Networking Engineer | I wonder how much time is
 Hewlett-Packard  Co. | alp@hpindwa.cup.hp.com     | spent figuring out clever
                      |                            | notes for this space.
-------------------------------------------------------------------------------